From jay.krell at cornell.edu Sun Sep 1 00:07:32 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 31 Aug 2013 22:07:32 +0000 Subject: [M3devel] need some help with linker error In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0CD60@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0CD60@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Python 3.x is very incompatible with Python 2.x. That is one of the worst things about Python imho -- they don't take compatibility seriously. Please use 2.x. I'll see if I can form the code to be valid for both 2.x and 3.x but I'm not hopeful. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] need some help with linker error Date: Sat, 31 Aug 2013 21:41:43 +0000 Jay: I am using Python v 3.3.0. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Saturday, August 31, 2013 11:59 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] need some help with linker error What version of Python? Maybe too old? upgrade (i.e. your cmd) needs to include, not skip, mklib. Compare it to the others. The fix was in mklib and your cmd varies in this respect. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com CC: jay.krell at cornell.edu Subject: RE: [M3devel] need some help with linker error Date: Sat, 31 Aug 2013 14:59:21 +0000 Jay: I tried upgrade.py, without success. Here are the results: C:\cm3\Sandbox\scripts\python>python upgrade.py Traceback (most recent call last): File "upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\scripts\python\pylib.py", line 900 PackageDB = (PackageDB or map(lambda(a): a.replace("\n", "").replace('\\', '/').replace("\r", ""), open(PKGSDB))) ^ SyntaxError: invalid syntax I?m not familiar with python, so I?m not in a position to debug what is wrong. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Friday, August 30, 2013 6:07 PM To: Coleburn, Randy Subject: EXT:RE: [M3devel] need some help with linker error RCC_upgradeCM3.cmd looks incorrect. Please try upgrade.py. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu Subject: RE: [M3devel] need some help with linker error Date: Fri, 30 Aug 2013 20:06:13 +0000 No, I ran my batch/CMD scripts, but these are based on what you had described previously as the correct steps. Is there a new dependency or step I need to be aware of? --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Friday, August 30, 2013 3:46 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] need some help with linker error Did you run upgrade.py? - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Fri, 30 Aug 2013 16:12:32 +0000 Subject: Re: [M3devel] need some help with linker error Jay: I appreciate your help. I just updated via CVS to get all your latest changes, but I am still getting the error with non-unique match for _xmm. See below: ? msvcrt.lib m3core.def : warning LNK4022: cannot find unique match for symbol '_xmm' m3core.def : warning LNK4002: __xmm at 41f00000000000000000000000000000 defined in dtoa.obj m3core.def : warning LNK4002: __xmm at 80000000000000008000000000000000 defined in dtoa.obj m3core.def : error LNK2001: unresolved external symbol _xmm m3core.lib : fatal error LNK1120: 1 unresolved externals Can you point me in the right direction to solve this problem? Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, August 27, 2013 11:28 AM To: Rodney M. Bates; m3devel Subject: EXT:Re: [M3devel] need some help with linker error This is fixed now too. Dragisha had introduced heap corruption in FSWin32.m3 trying to improve Unicode support. - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 27 Aug 2013 14:55:13 +0000 Subject: Re: [M3devel] need some help with linker error Hm. That leaves me with: +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 +++ --- building in NT386 --- ignoring ..\src\m3overrides *** *** runtime error: *** Attempt to reference an illegal memory location. *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x14efe0 0x11bdadb SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3 0x14f028 0x76f22d94 0x14f040 0x76f22ce8 0x14f054 0x759bc3d4 0x14f068 0x6302dcc2 0x14f074 0x11bbe02 Cstdlib_I3 + 0x1a2 in ..\src\C\Common\Cstdlib.i3 0x14f088 0x11a7925 DisposeUntracedRef + 0x2c in ..\src\runtime\common\RTAlloc ator.m3 0x14f09c 0x11a1687 DelCriticalSection + 0x2d in ..\src\thread\WIN32\ThreadWin 32.m3 0x14f0b8 0x11a161a CleanMutex + 0x89 in ..\src\thread\WIN32\ThreadWin32.m3 0x14f0ec 0x1196371 PostHandleWeakRefs + 0x2ae in ..\src\runtime\common\RTColl ector.m3 ......... ......... ... more frames ... *** execution of [, ] failed *** Not good. - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 27 Aug 2013 09:07:25 +0000 Subject: Re: [M3devel] need some help with linker error I updated m3-sys/mklib to ignore these. Let me know if there are any more problems. Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 27 Aug 2013 06:43:53 +0000 Subject: Re: [M3devel] need some help with linker error > Is there a chance both are getting linked in? No. There is no chance of this. > Or one from the modula-3 distribution, and one already in some MS-supplied > library? No. There is no chance of this either. I forget how we generate the .def file but we need to exclude names "like" this -- that start _xmm at . These are floating point constants for code that uses sse2. You are targeting 32bit, right? Still, I guess these might occur, with newer compilers. I'll look into it. We already have to code exclude the older forms of floating point constants. - Jay > Date: Mon, 26 Aug 2013 20:03:20 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] need some help with linker error > > This is just a wild guess, but there are two dtoa.c files, in > > m3-libs/m3core/src/Csupport/little-endian/dtoa.c and > m3-libs/m3core/src/Csupport/big-endian/dtoa.c > > No doubt they are alternatives. Is there a chance both are getting linked in? > Or one from the modula-3 distribution, and one already in some MS-supplied > library? > > On 08/26/2013 07:49 PM, Coleburn, Randy wrote: > > Jay: > > > > I?m getting errors trying to rebuild m3core.lib on Win7-64bit. Specifically, see below the error I get from the Microsoft Linker. > > > > The full text of the m3core.lst file is also shown at the end of this message. > > > > msvcrt.lib > > > > m3core.def : warning LNK4022: cannot find unique match for symbol '_xmm' > > > > m3core.def : warning LNK4002: __xmm at 41f00000000000000000000000000000 defined in dtoa.obj > > > > m3core.def : warning LNK4002: __xmm at 80000000000000008000000000000000 defined in dtoa.obj > > > > m3core.def : error LNK2001: unresolved external symbol _xmm > > > > m3core.lib : fatal error LNK1120: 1 unresolved externals > > > > Any ideas on what I should do to resolve this problem? > > > > Thanks, > > > > Randy Coleburn > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 1 05:05:13 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 03:05:13 +0000 Subject: [M3devel] another size/alignment/interop problem.. Message-ID: TYPE FILETIME = RECORD dwLowDateTime : uint32_t; dwHighDateTime: uint32_t; END; BY_HANDLE_FILE_INFORMATION = RECORD dwFileAttributes : uint32_t; ftCreationTime : FILETIME; (* This should be at offset 4 but is 8 on 64bit systems. *) (* the rest omitted *) END; Why doesn't that just work? It works with: TYPE FILETIME = BITS 64 FOR RECORD but imho it should work without that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Sep 1 09:31:47 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Sep 2013 09:31:47 +0200 Subject: [M3devel] Git migration Message-ID: <6433EF8B-83A9-4FEE-A626-ADC25C8C689E@m3w.org> Hi all, I would like to initiate final conversion/migration of repository to Git. As per widely accepted guidelines for such migrations - here is a question to stakeholders (I suppose it means people on this list :) ): Does anybody have any questions/reasonable doubts about this migration? My plan is to collect feedback, prepare workflow equivalents for current CVS workflows, and do all the work "atomically" one day of this September. Please feel free to send your specific concerns/wishes both here and privately to me. TIA, dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Sun Sep 1 09:42:22 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 07:42:22 +0000 Subject: [M3devel] cm3 -DTARGET=foo In-Reply-To: References: Message-ID: I forgot and it is worth reminding everyone: CM3_TARGET=foo cm3 does work in sh/bash/Posix Given config files and everything else. We do have such config files. "everything else" means cooperative cc/ld. At the very least, it is good for "biarch" systems: CM3_TARGET=I386_DARWIN cm3 CM3_TARGET=AMD64_DARWIN cm3 For these cases though, we should probably take a hint from others: cm3 -64 cm3 --64 cm3 -m64 (andy number of dashes, followed by optional m, followed by 32 or 64 guides target toward 32bit or 64bit variant of host or default target) also CM3_TARGET=arbitrary cm3 -boot But there should be a command line option besides the environment. Appe's gcc is also nice, switches like -arch ppc -arch x86 etc. Anyway, not a big deal.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3 -DTARGET=foo Date: Fri, 30 Aug 2013 06:02:41 +0000 I'd like the above to work. Or cm3 -target=foo or -target:foo. The underlying implementation would be "like" -DTARGET=foo. This doesn't work due to the order of evaluation, command line vs. config file vs. -D written to a file. I don't have the change yet. Any objection to the intent? I wonder if it might subtlely reorder things though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Sep 1 23:54:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Sep 2013 16:54:22 -0500 Subject: [M3devel] how to write constants? In-Reply-To: References: Message-ID: <5223B78E.5000901@lcwb.coop> On 08/31/2013 01:17 AM, Jay K wrote: > What is the right way to do this for 64bit systems? I presume you mean so it works on both 32-bit and 64-but? > > other : INT32 = 16_FFFFFFFF; > > > "../src/win32/WinUser.i3", line 1321: warning: value not assignable (range fault) > WS_POPUP : INT32 = 16_80000000; > > "../src/win32/WinVer.i3", line 37: warning: value not assignable (range fault) > VS_FFI_SIGNATURE : INT32 = 16_FEEF04BD; > > > I'm guessing.. > other : INT32 := -1; Yes, assuming this is the same INT32 as the other two cases (a subrange covering 32-bit signed twos-complement. (I couldn't find this declaration, thus nor its INT32 type.) > WS_POPUP = FIRST(INT32) That will work. Ultimately, the buck has to stop being passed, and following more levels of transitive type renaming than I want to count, I see the type defined as [-16_7fffffff-1 .. 16_7fffffff], whose lower bound is the way I would have done it as a ground constant. I see two different BasicCTypes.i3 versions, inside subdirectories 32BITS and 64BITS, but this decl is the same in both. > VS_FFI_SIGNATURE : INT32 = -17890115; (* 16_FEEF04BD *) > Works, but tedious to hand-compute and to double-check consistency with the comment. How about 16_FEEF04BD-16FFFFFFFF-1? Does it seem odd that numbers like this in the upper-half unsigned range are being given to a signed type? > > ? > > - Jay From rodney_bates at lcwb.coop Mon Sep 2 00:07:31 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Sep 2013 17:07:31 -0500 Subject: [M3devel] another size/alignment/interop problem.. In-Reply-To: References: Message-ID: <5223BAA3.8040404@lcwb.coop> On 08/31/2013 10:05 PM, Jay K wrote: > TYPE FILETIME = RECORD > dwLowDateTime : uint32_t; > dwHighDateTime: uint32_t; > END; > > BY_HANDLE_FILE_INFORMATION = RECORD > dwFileAttributes : uint32_t; > ftCreationTime : FILETIME; (* This should be at offset 4 but is 8 on 64bit systems. *) > (* the rest omitted *) > END; > > > Why doesn't that just work? The only explanation I can think of is that the compiler gave record type FILETIME 64-bit alignment. As far as I know, there is nothing in the language that says it is not perfectly within its rights to do so. Why is another question. > It works with: > TYPE FILETIME = BITS 64 FOR RECORD > Which is consistent with the language, if it doesn't refuse altogether. > > but imho it should work without that. > > > - Jay > > From jay.krell at cornell.edu Mon Sep 2 00:46:07 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 22:46:07 +0000 Subject: [M3devel] another size/alignment/interop problem.. In-Reply-To: <5223BAA3.8040404@lcwb.coop> References: , <5223BAA3.8040404@lcwb.coop> Message-ID: We require some degree of C interop, so we require some degree of predictable layout. What we have falls below my expectations, but perhaps if it is explained to me, it won't any longer. Well, I guess we don't really require any predictable layout. I can give up on records for any interop and rely strictly on integer and pointer parameters. Or, well, I can do like for Posix and use a small copying layer and smush out anything vaguely unclear like this... - Jay > Date: Sun, 1 Sep 2013 17:07:31 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] another size/alignment/interop problem.. > > > > On 08/31/2013 10:05 PM, Jay K wrote: > > TYPE FILETIME = RECORD > > dwLowDateTime : uint32_t; > > dwHighDateTime: uint32_t; > > END; > > > > BY_HANDLE_FILE_INFORMATION = RECORD > > dwFileAttributes : uint32_t; > > ftCreationTime : FILETIME; (* This should be at offset 4 but is 8 on 64bit systems. *) > > (* the rest omitted *) > > END; > > > > > > Why doesn't that just work? > > The only explanation I can think of is that the compiler gave record type FILETIME > 64-bit alignment. As far as I know, there is nothing in the language that says it > is not perfectly within its rights to do so. Why is another question. > > > > It works with: > > TYPE FILETIME = BITS 64 FOR RECORD > > > > Which is consistent with the language, if it doesn't refuse altogether. > > > > but imho it should work without that. > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 2 00:51:35 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 22:51:35 +0000 Subject: [M3devel] how to write constants? In-Reply-To: <5223B78E.5000901@lcwb.coop> References: , <5223B78E.5000901@lcwb.coop> Message-ID: > I presume you mean so it works on both 32-bit and 64-bit? There should be no doubt that almost everything should. Yes. > > VS_FFI_SIGNATURE : INT32 = -17890115; (* 16_FEEF04BD *) > > > > Works, but tedious to hand-compute and to double-check consistency with > the comment. How about 16_FEEF04BD-16FFFFFFFF-1? I can try that. I couldn't hand compute it. I gave up and used a reliable calculator: #include int main() { printf("%d\n", 0xFEEF04BD); return 0; } but yeah, something obviously correct by inspection would be nice. Notice that I can't use Word or Long to help compute such constants. I kinda think we need a Word32 interface (and Long should then have been called Word64). > Does it seem odd that numbers like this in the upper-half unsigned range > are being given to a signed type? Sure, but, maybe I'm confused, but we don't have this upper-half in our unsigned types either. I can try foo: UINT32 = 16_FFFFFFFF or 16_FEEF04BD or such. We also had I think negative numbers assigned to unsigned types. - Jay > Date: Sun, 1 Sep 2013 16:54:22 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] how to write constants? > > > > On 08/31/2013 01:17 AM, Jay K wrote: > > What is the right way to do this for 64bit systems? > > I presume you mean so it works on both 32-bit and 64-but? > > > > > other : INT32 = 16_FFFFFFFF; > > > > > > "../src/win32/WinUser.i3", line 1321: warning: value not assignable (range fault) > > WS_POPUP : INT32 = 16_80000000; > > > > "../src/win32/WinVer.i3", line 37: warning: value not assignable (range fault) > > VS_FFI_SIGNATURE : INT32 = 16_FEEF04BD; > > > > > > I'm guessing.. > > other : INT32 := -1; > > Yes, assuming this is the same INT32 as the other two cases (a subrange > covering 32-bit signed twos-complement. (I couldn't find this declaration, > thus nor its INT32 type.) > > > WS_POPUP = FIRST(INT32) > > That will work. Ultimately, the buck has to stop being passed, and > following more levels of transitive type renaming than I want to count, > I see the type defined as [-16_7fffffff-1 .. 16_7fffffff], whose lower > bound is the way I would have done it as a ground constant. > > I see two different BasicCTypes.i3 versions, inside subdirectories > 32BITS and 64BITS, but this decl is the same in both. > > > VS_FFI_SIGNATURE : INT32 = -17890115; (* 16_FEEF04BD *) > > > > Works, but tedious to hand-compute and to double-check consistency with > the comment. How about 16_FEEF04BD-16FFFFFFFF-1? > > Does it seem odd that numbers like this in the upper-half unsigned range > are being given to a signed type? > > > > > ? > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 07:53:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 05:53:56 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Message-ID: I've complained about this before. The frontend keeps track of things in bits in INTEGER. Therefore TextLiteral.MaxBytes is around 512MB. We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. Fixing this mostly but not entirely would be to plumb through LONGINT "everywhere" instead of INTEGER. We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. So we'd have a 60 bit limit instead of a 64bit limit. Fixing it even more would require Target.Int. Thoughts? Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? Do we still require bootstrapping from LONGINT-less compilers? Any lingering doubts as to its syntax and meaning? I still think it should be named INT64. Because in the future I want INT128 and I don't want LONGINT to grow in size. Would it be considered adequate as a replacement for Target.Int? If instead I plumb through Target.Int, any complaints? Target.Int has the following advantages: When we need INT128 in the future, it is a very very very simple and small change. I already extended Target.Int from 64 bits to 72 bits. It works with old frontends. Target.Int has the following disadvantages: no operator overloading so usage is cumbersome slower I still don't fully understand it, e.g. division - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 08:02:52 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 06:02:52 +0000 Subject: [M3devel] TextLiteral.MaxBytes again Message-ID: ok, another question: CONST (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); TYPE T = RTHooks.TextLiteral; REVEAL T = TEXT BRANDED "TextLiteral.T" OBJECT cnt : INTEGER; buf : ARRAY [0..MaxBytes - 1] OF Byte; OVERRIDES ... T is a reference type. Is there a way to state this with no limit? Isn't it already unsafe? You know -- the array is usually smaller and the compiler is only going to check against this large size. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 08:54:45 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 06:54:45 +0000 Subject: [M3devel] FW: rc or windres? In-Reply-To: <20130903064906.DF5CA5DEB73@birch.elegosoft.com> References: <20130903064906.DF5CA5DEB73@birch.elegosoft.com> Message-ID: Anyone else want to tackle this? Windres is what you would likely use in a Cygwin environment. And maybe MinGW. But not an "MS" environment. It isn't the target per-se, it is more about the "host tools". How about config file says: WINDOWS_RESOURCE_COMPILER = "rc" or WINDOWS_RESOURCE_COMPILER = "windres" ? or USE_RC = TRUE vs. USE_WINDRES = TRUE? or maybe we can try running each and use whatever works? I had windres on my path and it ran, and failed. I think because of backslashes in paths. It also ran gcc as part of its work, which I also had in the path. I had these mainly because Cygwin provides cvs/ssh. I'm actually using the Microsoft compiler/linker/rc. I guess supposed AMD64_CYGWIN and AMD64_MINGW are next in line as targets, using the C backend.. Though I also doubt if anyone here uses them. Thank you, - Jay > Date: Tue, 3 Sep 2013 08:49:06 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/09/03 08:49:06 > > Modified files: > cm3/m3-sys/windowsResources/src/: winRes.tmpl > > Log message: > This file uses rc for backend mode 0 and windres otherwise. > Change it to also use rc backend mode C. > This all seems wrong. > windres is a Cygwin tool. > rc is a Microsoft tool. > windres probably works "cross", though that is probably rare. > > This should probably be lifted all the way up to the config files. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 09:12:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 07:12:17 +0000 Subject: [M3devel] why record with two int32's gets alignment 64? In-Reply-To: <20130903060538.433F15DEB73@birch.elegosoft.com> References: <20130903060538.433F15DEB73@birch.elegosoft.com> Message-ID: help? Thanks, - Jay > Date: Tue, 3 Sep 2013 08:05:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/09/03 08:05:38 > > Modified files: > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message: > add BITS 64 FOR on FILETIME > I don't understand the frontend layout rules and I think the fix > might be there instead! > > But hey this did expose tiny missing logic in C backend.. > packed records weren't considered records and weren't being passed/recieved > as parameters/return values succesfully -- the C would fail to compile, nice error mode! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 3 14:13:33 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Sep 2013 08:13:33 -0400 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: References: Message-ID: <67681FED-F7BE-41F6-A1D8-70FCEAE50493@cs.purdue.edu> Who would ever create a text literal that exceeds MaxBytes? Sent from my iPad On Sep 3, 2013, at 2:02 AM, Jay K wrote: > ok, another question: > > > CONST > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > TYPE > T = RTHooks.TextLiteral; > REVEAL > T = TEXT BRANDED "TextLiteral.T" OBJECT > cnt : INTEGER; > buf : ARRAY [0..MaxBytes - 1] OF Byte; > OVERRIDES ... > > > T is a reference type. > Is there a way to state this with no limit? > > > Isn't it already unsafe? > You know -- the array is usually smaller and the compiler is only going to check against this large size. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Sep 3 16:04:43 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 3 Sep 2013 14:04:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0F326@ATLEX04-SRV.SCIRES.LOCAL> Jay: "windowsResources" is very Microsoft-specific, and there is no dependency on cygwin. We put this in to allow for packaging of things like icon files, etc. on Microsoft Windows targets. "rc" is the Microsoft Resource Compiler. I know that I have a number of programs that depend on this package. I haven't looked at your change yet; I just saw the commit log message. --Randy Coleburn -----Original Message----- From: Jay Krell [mailto:jkrell at elego.de] Sent: Tuesday, September 03, 2013 4:49 AM To: m3commit at elegosoft.com Subject: EXT:[M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 13/09/03 08:49:06 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: This file uses rc for backend mode 0 and windres otherwise. Change it to also use rc backend mode C. This all seems wrong. windres is a Cygwin tool. rc is a Microsoft tool. windres probably works "cross", though that is probably rare. This should probably be lifted all the way up to the config files. From jay.krell at cornell.edu Tue Sep 3 18:06:57 2013 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Sep 2013 09:06:57 -0700 Subject: [M3devel] AMD64_NT Message-ID: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> AMD_NT runs, can build itself, is more debuggable than NT386, Juno & formsedit come up. It was a fairly quick straightforward use of the C backend. There is a problem in m3core/Time that hangs mentor startup. The first time I ran cm3ide it brought up IE but hit an out-of-range in socket code. Elego code failed to build due to lack of c:\cygwin (I have c:\cygwin64). There is a problem in exception handling worked around using libcmt.lib instead of msvcr*.dll. The unsafe out of date cloned headers have as usual been a source of bugs. I'll try to get a snapshot out soon. Adventurous folks can try it already. - Jay From jay.krell at cornell.edu Tue Sep 3 18:55:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 16:55:56 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> References: , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> Message-ID: How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? double? That offers I think 53 bits, which is pretty good, but pesky floating point.. A library without infix notation? C and C++ have been using __int64 and long long for this for going on 20 years. And C++ has infix notation for arbitrary types. I guess I will plumb Target.Int through? I've started this before but it got tedious. - Jay CC: m3devel at elegosoft.com From: antony.hosking at gmail.com Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Date: Tue, 3 Sep 2013 08:11:32 -0400 To: jay.krell at cornell.edu Don't plumb LONGINT throughout. I still consider it an abomination. Sent from my iPad On Sep 3, 2013, at 1:53 AM, Jay K wrote: I've complained about this before. The frontend keeps track of things in bits in INTEGER. Therefore TextLiteral.MaxBytes is around 512MB. We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. Fixing this mostly but not entirely would be to plumb through LONGINT "everywhere" instead of INTEGER. We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. So we'd have a 60 bit limit instead of a 64bit limit. Fixing it even more would require Target.Int. Thoughts? Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? Do we still require bootstrapping from LONGINT-less compilers? Any lingering doubts as to its syntax and meaning? I still think it should be named INT64. Because in the future I want INT128 and I don't want LONGINT to grow in size. Would it be considered adequate as a replacement for Target.Int? If instead I plumb through Target.Int, any complaints? Target.Int has the following advantages: When we need INT128 in the future, it is a very very very simple and small change. I already extended Target.Int from 64 bits to 72 bits. It works with old frontends. Target.Int has the following disadvantages: no operator overloading so usage is cumbersome slower I still don't fully understand it, e.g. division - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 3 19:00:08 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Sep 2013 13:00:08 -0400 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> Message-ID: <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Yes, I want to avoid use of LONGINT in the compiler proper. If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. But I still don?t understand the precise use-case that you are proposing. In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? I cannot imaging a text literal that big, ever. On Sep 3, 2013, at 12:55 PM, Jay K wrote: > How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? > double? That offers I think 53 bits, which is pretty good, but pesky floating point.. > A library without infix notation? > C and C++ have been using __int64 and long long for this for going on 20 years. > And C++ has infix notation for arbitrary types. > > > I guess I will plumb Target.Int through? > I've started this before but it got tedious. > > > - Jay > > CC: m3devel at elegosoft.com > From: antony.hosking at gmail.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > Date: Tue, 3 Sep 2013 08:11:32 -0400 > To: jay.krell at cornell.edu > > Don't plumb LONGINT throughout. I still consider it an abomination. > > Sent from my iPad > > On Sep 3, 2013, at 1:53 AM, Jay K wrote: > > I've complained about this before. > > > The frontend keeps track of things in bits in INTEGER. > Therefore TextLiteral.MaxBytes is around 512MB. > > > We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. > > > Fixing this mostly but not entirely would be to plumb through LONGINT > "everywhere" instead of INTEGER. > We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. > So we'd have a 60 bit limit instead of a 64bit limit. > > > Fixing it even more would require Target.Int. > > > Thoughts? > > > Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? > Do we still require bootstrapping from LONGINT-less compilers? > > > Any lingering doubts as to its syntax and meaning? > I still think it should be named INT64. > Because in the future I want INT128 and I don't want LONGINT to grow in size. > > > Would it be considered adequate as a replacement for Target.Int? > > > If instead I plumb through Target.Int, any complaints? > Target.Int has the following advantages: > When we need INT128 in the future, it is a very very very simple and small change. > I already extended Target.Int from 64 bits to 72 bits. > It works with old frontends. > > > Target.Int has the following disadvantages: > no operator overloading so usage is cumbersome > slower > I still don't fully understand it, e.g. division > > > > - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 19:50:01 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 17:50:01 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> References: , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Message-ID: I think it isn't just TextLiteral.MaxBytes. How do I declare an unbouned-ly sized array? At the end of a record? Doesn't matter? For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? - Jay From: hosking at cs.purdue.edu Date: Tue, 3 Sep 2013 13:00:08 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Yes, I want to avoid use of LONGINT in the compiler proper.If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose.But I still don?t understand the precise use-case that you are proposing.In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small?I cannot imaging a text literal that big, ever. On Sep 3, 2013, at 12:55 PM, Jay K wrote:How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? double? That offers I think 53 bits, which is pretty good, but pesky floating point.. A library without infix notation? C and C++ have been using __int64 and long long for this for going on 20 years. And C++ has infix notation for arbitrary types. I guess I will plumb Target.Int through? I've started this before but it got tedious. - Jay CC: m3devel at elegosoft.com From: antony.hosking at gmail.com Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Date: Tue, 3 Sep 2013 08:11:32 -0400 To: jay.krell at cornell.edu Don't plumb LONGINT throughout. I still consider it an abomination. Sent from my iPad On Sep 3, 2013, at 1:53 AM, Jay K wrote: I've complained about this before. The frontend keeps track of things in bits in INTEGER. Therefore TextLiteral.MaxBytes is around 512MB. We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. Fixing this mostly but not entirely would be to plumb through LONGINT "everywhere" instead of INTEGER. We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. So we'd have a 60 bit limit instead of a 64bit limit. Fixing it even more would require Target.Int. Thoughts? Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? Do we still require bootstrapping from LONGINT-less compilers? Any lingering doubts as to its syntax and meaning? I still think it should be named INT64. Because in the future I want INT128 and I don't want LONGINT to grow in size. Would it be considered adequate as a replacement for Target.Int? If instead I plumb through Target.Int, any complaints? Target.Int has the following advantages: When we need INT128 in the future, it is a very very very simple and small change. I already extended Target.Int from 64 bits to 72 bits. It works with old frontends. Target.Int has the following disadvantages: no operator overloading so usage is cumbersome slower I still don't fully understand it, e.g. division - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 19:53:08 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 17:53:08 +0000 Subject: [M3devel] rc vs. windres In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0F326@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0F326@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: > "windowsResources" is very Microsoft-specific, and there is no dependency on cygwin. Yes there is. As the commit says -- the code checks "backend mode" and uses rc for 0, windres otherwise, windres being a Cygwin tool. I changed it so backend mode C also uses rc. I think this probably belongs all the way up in the config files. Keeping in mind that it is a host-configuration aspect, not a target-specific one. We confuse those -- is "NT386GNU" a host or a target, or both? Does the compiler use cygwin1.dll, or the output, or both? In reality, these are separate matters. Cross compilation is rare, people confuse these matters all the time, and it rarely matters. - Jay > From: rcolebur at SCIRES.COM > To: jkrell at elego.de; m3devel at elegosoft.com > Date: Tue, 3 Sep 2013 14:04:43 +0000 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay: > > "windowsResources" is very Microsoft-specific, and there is no dependency on cygwin. > > We put this in to allow for packaging of things like icon files, etc. on Microsoft Windows targets. > > "rc" is the Microsoft Resource Compiler. > > I know that I have a number of programs that depend on this package. > > I haven't looked at your change yet; I just saw the commit log message. > > --Randy Coleburn > > -----Original Message----- > From: Jay Krell [mailto:jkrell at elego.de] > Sent: Tuesday, September 03, 2013 4:49 AM > To: m3commit at elegosoft.com > Subject: EXT:[M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/09/03 08:49:06 > > Modified files: > cm3/m3-sys/windowsResources/src/: winRes.tmpl > > Log message: > This file uses rc for backend mode 0 and windres otherwise. > Change it to also use rc backend mode C. > This all seems wrong. > windres is a Cygwin tool. > rc is a Microsoft tool. > windres probably works "cross", though that is probably rare. > > This should probably be lifted all the way up to the config files. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 3 22:12:32 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Sep 2013 16:12:32 -0400 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Message-ID: <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu> On Sep 3, 2013, at 1:50 PM, Jay K wrote: > I think it isn't just TextLiteral.MaxBytes. > > > How do I declare an unbouned-ly sized array? Can?t do in M3. It?s not type safe. > At the end of a record? > Doesn't matter? > > > For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? Can you really imagine typing a literal that is 512MB in length? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Tue, 3 Sep 2013 13:00:08 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > > Yes, I want to avoid use of LONGINT in the compiler proper. > If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. > But I still don?t understand the precise use-case that you are proposing. > In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? > I cannot imaging a text literal that big, ever. > > On Sep 3, 2013, at 12:55 PM, Jay K wrote: > > How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? > double? That offers I think 53 bits, which is pretty good, but pesky floating point.. > A library without infix notation? > C and C++ have been using __int64 and long long for this for going on 20 years. > And C++ has infix notation for arbitrary types. > > > I guess I will plumb Target.Int through? > I've started this before but it got tedious. > > > - Jay > > CC: m3devel at elegosoft.com > From: antony.hosking at gmail.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > Date: Tue, 3 Sep 2013 08:11:32 -0400 > To: jay.krell at cornell.edu > > Don't plumb LONGINT throughout. I still consider it an abomination. > > Sent from my iPad > > On Sep 3, 2013, at 1:53 AM, Jay K wrote: > > I've complained about this before. > > > The frontend keeps track of things in bits in INTEGER. > Therefore TextLiteral.MaxBytes is around 512MB. > > > We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. > > > Fixing this mostly but not entirely would be to plumb through LONGINT > "everywhere" instead of INTEGER. > We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. > So we'd have a 60 bit limit instead of a 64bit limit. > > > Fixing it even more would require Target.Int. > > > Thoughts? > > > Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? > Do we still require bootstrapping from LONGINT-less compilers? > > > Any lingering doubts as to its syntax and meaning? > I still think it should be named INT64. > Because in the future I want INT128 and I don't want LONGINT to grow in size. > > > Would it be considered adequate as a replacement for Target.Int? > > > If instead I plumb through Target.Int, any complaints? > Target.Int has the following advantages: > When we need INT128 in the future, it is a very very very simple and small change. > I already extended Target.Int from 64 bits to 72 bits. > It works with old frontends. > > > Target.Int has the following disadvantages: > no operator overloading so usage is cumbersome > slower > I still don't fully understand it, e.g. division > > > > - Jay > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 03:48:02 2013 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Sep 2013 18:48:02 -0700 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu> References: <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu> Message-ID: How about in unsafe code? Just untraced ref T? TextLiteral: ok I guess not. Can always break them up and concat them...compiler could do that. I'd like to have m3-sys/mklib just keep everything in memory. Less code & maybe faster. Thanks, - Jay On Sep 3, 2013, at 1:12 PM, Tony Hosking wrote: > On Sep 3, 2013, at 1:50 PM, Jay K wrote: > >> I think it isn't just TextLiteral.MaxBytes. >> >> >> How do I declare an unbouned-ly sized array? > > Can?t do in M3. It?s not type safe. > >> At the end of a record? >> Doesn't matter? >> >> >> For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? > > Can you really imagine typing a literal that is 512MB in length? > >> >> >> - Jay >> >> >> From: hosking at cs.purdue.edu >> Date: Tue, 3 Sep 2013 13:00:08 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? >> >> Yes, I want to avoid use of LONGINT in the compiler proper. >> If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. >> But I still don?t understand the precise use-case that you are proposing. >> In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? >> I cannot imaging a text literal that big, ever. >> >> On Sep 3, 2013, at 12:55 PM, Jay K wrote: >> >> How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? >> double? That offers I think 53 bits, which is pretty good, but pesky floating point.. >> A library without infix notation? >> C and C++ have been using __int64 and long long for this for going on 20 years. >> And C++ has infix notation for arbitrary types. >> >> >> I guess I will plumb Target.Int through? >> I've started this before but it got tedious. >> >> >> - Jay >> >> CC: m3devel at elegosoft.com >> From: antony.hosking at gmail.com >> Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? >> Date: Tue, 3 Sep 2013 08:11:32 -0400 >> To: jay.krell at cornell.edu >> >> Don't plumb LONGINT throughout. I still consider it an abomination. >> >> Sent from my iPad >> >> On Sep 3, 2013, at 1:53 AM, Jay K wrote: >> >> I've complained about this before. >> >> >> The frontend keeps track of things in bits in INTEGER. >> Therefore TextLiteral.MaxBytes is around 512MB. >> >> >> We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. >> >> >> Fixing this mostly but not entirely would be to plumb through LONGINT >> "everywhere" instead of INTEGER. >> We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. >> So we'd have a 60 bit limit instead of a 64bit limit. >> >> >> Fixing it even more would require Target.Int. >> >> >> Thoughts? >> >> >> Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? >> Do we still require bootstrapping from LONGINT-less compilers? >> >> >> Any lingering doubts as to its syntax and meaning? >> I still think it should be named INT64. >> Because in the future I want INT128 and I don't want LONGINT to grow in size. >> >> >> Would it be considered adequate as a replacement for Target.Int? >> >> >> If instead I plumb through Target.Int, any complaints? >> Target.Int has the following advantages: >> When we need INT128 in the future, it is a very very very simple and small change. >> I already extended Target.Int from 64 bits to 72 bits. >> It works with old frontends. >> >> >> Target.Int has the following disadvantages: >> no operator overloading so usage is cumbersome >> slower >> I still don't fully understand it, e.g. division >> >> >> >> - Jay >> >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Mobile +1 765 427 5484 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 08:28:18 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 06:28:18 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? Message-ID: AMD64_NT starting up mentor: *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\EventWireRep.m3", line 89 *** This opens up a big multi-part can of worms. I'm not sure the order to present things. Please bear with me. Background: Time.T is a double/longreal number of seconds since a platform-specific epoch. This cleverly gives I guess pretty good range and precison. On Windows, that is 1601. The underlying system stores 64bit 100s of nanoseconds. This gives both good range and precision. And it works ok with Modula-3. On Posix is presumably 1970. This is all ok. Not controversial. Corralaries: Time.Now on Windows returns around 1.3022747815483961e10. My simple math says that is off by a month but hopefully more precise math says it is exactly correct. We have confusing Modula-3 code and straightforward C code to compute this. That it is within a month seems adequate to backup everything else I'm seeing/saying. events!EventWireRep_M3 [c:\dev2\cm3\m3-comm\events\src\eventwirerep.m3 @ 90] Int32 = BITS 32 FOR [-2147483647-1..2147483647]; TRep = RECORD ts: Int32; objNum: Int32; space: EventSpaceID.T; END; VAR myTs: Int32 := ROUND(Time.Now()); Clearly this is a problem. It runs out "soon" on 32bit Posix systems, it runs out already on Win64, and on Win32, well, it produces garbage one way or another, but no range errors. On AMD64_NT, this reasonably rounds to 13022747815 -- the full integer value of the double fits in a 64bit integer. But it doesn't fit in 32 bits. On I386_NT, this somewhat "correctly" rounds to -2147483648 Hm. Shouldn't it be nearest integer 2147483647?? In either case, see you the problem. Ok, so this is three dilemnas/questions/bugs in one. http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arithmetic_operations.html ROUND(r) is the nearest integer to r; ties are broken according to the constant RoundDefault 1) How should ROUND be defined? Is Modula-3 adequately safe here? What should round of numbers less than FIRST(INTEGER)-1 or greater than LAST(INTEGER) + 1 round to? By the simple definition, they should round to FIRST(INTEGER) and LAST(INTEGER). But is it safe? You know, I can see taking the whole part of the number and losing the fractional part as being ok when desired, but when the whole part doesn't fit, not even when rounded up or down by 1? Doesn't that seem like it should be a range error? 2) What is up with the various implementations? ASSUMING Modula-3 ROUND is defined safely enough, is the integrated NT/x86 backend correct here? On I386_DARWIN: IMPORT IO, Fmt; BEGIN IO.Put(Fmt.Int(ROUND(1.3022747815483961e10)) & "\n"); END Main. We get: 137845760. Wow, that is just wrong. Sure it got the mantissa close, but the exponent is arbitrary seeming. I could chalk this up to a bug in my C backend, but it gets constant folded in the front end. The backend just gets load_integer 137845760. This seems highly incorrect. Maybe bugs in Target.Float? Maybe overflow is being ignored?? I'll look later, another day. 3) What to do? 3a) The frontend seems wrong here, no matter what. 3b) The integrated backend seems at least slightly wrong. 3c) The events code either needs widening, or perhaps this isn't time, but a somewhat arbitrary "fingerprint". Perhaps it can just use MOD?? I will likely verify if it needs to be time or just a reasonably volatile number to cross check sender/reciever and then use MOD. Posix and Win32 systems probably can't talk to each other. Lame. Someone might suggest that Win32 epoch be changed to 1970. I don't think so. 4) can anyone understand and explain the Modula-3 code we have here in Time.m3? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Wed Sep 4 10:06:14 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 4 Sep 2013 10:06:14 +0200 Subject: [M3devel] Git migration In-Reply-To: <6433EF8B-83A9-4FEE-A626-ADC25C8C689E@m3w.org> References: <6433EF8B-83A9-4FEE-A626-ADC25C8C689E@m3w.org> Message-ID: <20130904100614.4c96fb84.wagner@elego.de> On Sun, 1 Sep 2013 09:31:47 +0200 Dragi?a Duri? wrote: > Hi all, > > I would like to initiate final conversion/migration of repository to Git. As per widely accepted guidelines for such migrations - here is a question to stakeholders (I suppose it means people on this list :) ): > > Does anybody have any questions/reasonable doubts about this migration? > > My plan is to collect feedback, prepare workflow equivalents for current CVS workflows, and do all the work "atomically" one day of this September. Please feel free to send your specific concerns/wishes both here and privately to me. Hi everybody, I'd just like to remember that I had created a Wiki page for discussion and information about this project at https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration I think Wikis are very good and productive platforms for collaborative work; so I suggest you use it. If anybody is missing an account or permissions, please contact me or Michael Anderson at elego: wagner at elegosoft.com manderson at elegosoft.com Despite my doubts about the necessity of CVS migration several years ago, I'm now very much in favour of this project. I think git is now established as a useful and well-supported standard VCS tool, and migrating to it will open CM3 up for more active developers. I would really like to take a more active part in the transition, but unfortunately I'm still too busy with other projects to contribute any reasonable amount of time. 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: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Wed Sep 4 18:32:17 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 04 Sep 2013 09:32:17 -0700 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , <20130904064212.318CF1A2080@async.async.caltech.edu> Message-ID: <20130904163217.C90041A2080@async.async.caltech.edu> Jay K writes: >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> If I am understanding properly what is going on I think this means your n= >ew >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >ation. > > >I wish=2C but no=2C it is the same as the others. I see... > > >It is all a bit subtle. As always... > ... > > >I believe=2C based on what you are saying=2C >the frontend should generate range checks before >floor/trunc/ceiling. > >Roughly it should be an error to convert >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. >Plus or minus one though. > > >That is=2C > FLOOR(LAST(INTEGER) + .99999) is ok. > CEILING(FIRST(INTEGER) - .99999) is ok. > ROUND(LAST(INTEGER) - .499999) is ok. > ROUND(FIRST(INTEGER) + .499999) is ok. >=20 > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > >Oh wait. It depends on the relative ranges of float and integer. > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer >needs the checks I describe. But a 53bit mantissa converted to >a 64bit integer=2C no range check is needed. > > >The frontend has some of those optimizations already -- converting >from a smaller range to a larger range needs no check. > > >Agreed? Surely this is not a difficult change? Well, I agree wholeheartedly, yes. >Nor particularly inefficient? > > > > - Jay > > > > >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = >events? >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 >> From: mika at async.caltech.edu >>=20 >> Jay K writes: >> ... >> > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. >> > >> > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= >met=3D >> >ic_operations.html >> > >> > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= >he co=3D >> >nstant RoundDefault >> > >> > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? >> > >> > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 >> > or greater than LAST(INTEGER) + 1 round to?=3D20 >> > >> > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 >> > and LAST(INTEGER). But is it safe? >> > >>=20 >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= >s=2C >> "integer" is the abstract mathematical concept of an integer=2C not the >> Modula-3 data type INTEGER. >>=20 >> I think the intent of the Green Book is that INTEGER should be a range-li= >mited >> form of integer=2C that is=2C it should behave like an integer as much as= > possible=2C >> and when the implementation can no longer accomplish that=2C it should si= >gnal a=20 >> runtime error. =20 >>=20 >> It happens that many existing implementions of Modula-3=2C as an implemen= >tation >> restriction=2C do not handle out-of-range situations correctly. Things >> such as what you describe SHOULD lead to a runtime error=2C value out of = >range. >> Some implementations wrap instead=2C but I don't even think that's right.= > Of >> course it's not as bad as it might be in C where you might be indexing an >> array with the incorrectly calculated integer and send your program off i= >n >> never-never land. In Modula-3 you'll at least get a runtime error at THA= >T >> point. But it's still not right. >>=20 >> If I am understanding properly what is going on I think this means your n= >ew >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >ation. >>=20 >> Mika > = > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
>=3B If I am understanding pro= >perly what is going on I think this means your new
>=3B Modula-3-to-C = >compiler is the most reasonably behaving Modula-3 implementation.

r>I wish=2C but no=2C it is the same as the others.


It is all a = >bit subtle.


Here is what I believe happens:


I386_NT: = >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > that can be
successfully assigned to this range=2C with or without
a= > range check.


m3cc: Posix: The values are in range.
With or w= >ithout a range check=2C the code succeeds.
For a "few" more years.
r>
C backend: Similar.
I'm using the C backend all the time on Darwon= >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = >systems will fail here.
32bit Posix would continue to round to some 32bi= >t integer=2C which would then
successfully pass into the identical subra= >nge -- like I386_NT today.



The backends don't add range chec= >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= >nd at least roughly
the range of longreal.
Possibly the range of a lo= >ngreal is target-dependent and knowledge
of it should only exist in the = >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= >s the same since around the early 1980s.



I believe=2C based = >on what you are saying=2C
the frontend should generate range checks befo= >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= >ive ranges of float and integer.


In particular=2C a 53bit mantis= >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= >ded.


The frontend has some of those optimizations already -- con= >verting
from a smaller range to a larger range needs no check.

r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= >cient?



 =3B- Jay




>=3B To: jay.= >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > the abstract mathematical concept of an integer=2C not the
>=3B Modul= >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > Book is that INTEGER should be a range-limited
>=3B form of integer= >=2C that is=2C it should behave like an integer as much as possible=2C
&= >gt=3B and when the implementation can no longer accomplish that=2C it shoul= >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= >t many existing implementions of Modula-3=2C as an implementation
>=3B= > restriction=2C do not handle out-of-range situations correctly. Things>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= >n think that's right. Of
>=3B course it's not as bad as it might be i= >n C where you might be indexing an
>=3B array with the incorrectly cal= >culated integer and send your program off in
>=3B never-never land. I= >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= >t it's still not right.
>=3B
>=3B If I am understanding properly= > what is going on I think this means your new
>=3B Modula-3-to-C compi= >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= >>=3B Mika
>= > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- From hosking at cs.purdue.edu Wed Sep 4 18:48:46 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 4 Sep 2013 12:48:46 -0400 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <20130904163217.C90041A2080@async.async.caltech.edu> References: , <20130904064212.318CF1A2080@async.async.caltech.edu> <20130904163217.C90041A2080@async.async.caltech.edu> Message-ID: <53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu> So, what is the precise proposal? Fix Target.Float to avoid constant folding in these instances? That seems reasonable to me. On Sep 4, 2013, at 12:32 PM, mika at async.caltech.edu wrote: > Jay K writes: >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >>> If I am understanding properly what is going on I think this means your n= >> ew >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >> ation. >> >> >> I wish=2C but no=2C it is the same as the others. > > I see... > >> >> >> It is all a bit subtle. > > As always... > >> > ... >> >> >> I believe=2C based on what you are saying=2C >> the frontend should generate range checks before >> floor/trunc/ceiling. >> >> Roughly it should be an error to convert >> a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. >> Plus or minus one though. >> >> >> That is=2C >> FLOOR(LAST(INTEGER) + .99999) is ok. >> CEILING(FIRST(INTEGER) - .99999) is ok. >> ROUND(LAST(INTEGER) - .499999) is ok. >> ROUND(FIRST(INTEGER) + .499999) is ok. >> =20 >> >> I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. >> >> >> Oh wait. It depends on the relative ranges of float and integer. >> >> >> In particular=2C a 53bit mantissa longreal converted to a 32bit integer >> needs the checks I describe. But a 53bit mantissa converted to >> a 64bit integer=2C no range check is needed. >> >> >> The frontend has some of those optimizations already -- converting >> from a smaller range to a larger range needs no check. >> >> >> Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > >> Nor particularly inefficient? >> >> >> >> - Jay >> >> >> >> >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = >> events? >>> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 >>> From: mika at async.caltech.edu >>> =20 >>> Jay K writes: >>> ... >>>> >>>> Ok=3D2C so this is three dilemnas/questions/bugs in one. >>>> >>>> >>>> http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= >> met=3D >>>> ic_operations.html >>>> >>>> >>>> ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= >> he co=3D >>>> nstant RoundDefault >>>> >>>> >>>> 1) How should ROUND be defined? Is Modula-3 adequately safe here? >>>> >>>> >>>> What should round of numbers less than FIRST(INTEGER)-1=3D20 >>>> or greater than LAST(INTEGER) + 1 round to?=3D20 >>>> >>>> >>>> By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 >>>> and LAST(INTEGER). But is it safe? >>>> >>> =20 >>> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= >> s=2C >>> "integer" is the abstract mathematical concept of an integer=2C not the >>> Modula-3 data type INTEGER. >>> =20 >>> I think the intent of the Green Book is that INTEGER should be a range-li= >> mited >>> form of integer=2C that is=2C it should behave like an integer as much as= >> possible=2C >>> and when the implementation can no longer accomplish that=2C it should si= >> gnal a=20 >>> runtime error. =20 >>> =20 >>> It happens that many existing implementions of Modula-3=2C as an implemen= >> tation >>> restriction=2C do not handle out-of-range situations correctly. Things >>> such as what you describe SHOULD lead to a runtime error=2C value out of = >> range. >>> Some implementations wrap instead=2C but I don't even think that's right.= >> Of >>> course it's not as bad as it might be in C where you might be indexing an >>> array with the incorrectly calculated integer and send your program off i= >> n >>> never-never land. In Modula-3 you'll at least get a runtime error at THA= >> T >>> point. But it's still not right. >>> =20 >>> If I am understanding properly what is going on I think this means your n= >> ew >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >> ation. >>> =20 >>> Mika >> = >> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >>
>=3B If I am understanding pro= >> perly what is going on I think this means your new
>=3B Modula-3-to-C = >> compiler is the most reasonably behaving Modula-3 implementation.

> r>I wish=2C but no=2C it is the same as the others.


It is all a = >> bit subtle.


Here is what I believe happens:


I386_NT: = >> from any double=2C round will give us
some integer=2C a 32bit integer=2C= >> that can be
successfully assigned to this range=2C with or without
a= >> range check.


m3cc: Posix: The values are in range.
With or w= >> ithout a range check=2C the code succeeds.
For a "few" more years.
> r>
C backend: Similar.
I'm using the C backend all the time on Darwon= >> .
Again=2C Posix: the values are in range.
I386_NT: round will give u= >> s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= >> teger=2C the range check fails.


In a "few" years=2C 64bit Posix = >> systems will fail here.
32bit Posix would continue to round to some 32bi= >> t integer=2C which would then
successfully pass into the identical subra= >> nge -- like I386_NT today.



The backends don't add range chec= >> ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= >> ows enough=2C it should do it.
The frontend knows the range of INTEGER a= >> nd at least roughly
the range of longreal.
Possibly the range of a lo= >> ngreal is target-dependent and knowledge
of it should only exist in the = >> backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= >> s the same since around the early 1980s.



I believe=2C based = >> on what you are saying=2C
the frontend should generate range checks befo= >> re
floor/trunc/ceiling.

Roughly it should be an error to convert<= >> br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= >> us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= >> ) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= >> + .499999) is ok.
 =3B

I'm not sure where "round to even" is= >> =2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= >> ive ranges of float and integer.


In particular=2C a 53bit mantis= >> sa longreal converted to a 32bit integer
needs the checks I describe. Bu= >> t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= >> ded.


The frontend has some of those optimizations already -- con= >> verting
from a smaller range to a larger range needs no check.

> r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= >> cient?



 =3B- Jay




>=3B To: jay.= >> krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= >> itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= >> 2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= >> rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= >> ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= >> t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= >> _10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= >> =3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= >> re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= >> =3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= >> Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= >> =3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= >> >=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= >> t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= >> hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = >> is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= >> on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= >> the abstract mathematical concept of an integer=2C not the
>=3B Modul= >> a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= >> Book is that INTEGER should be a range-limited
>=3B form of integer= >> =2C that is=2C it should behave like an integer as much as possible=2C
&= >> gt=3B and when the implementation can no longer accomplish that=2C it shoul= >> d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= >> t many existing implementions of Modula-3=2C as an implementation
>=3B= >> restriction=2C do not handle out-of-range situations correctly. Things>> >=3B such as what you describe SHOULD lead to a runtime error=2C value o= >> ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= >> n think that's right. Of
>=3B course it's not as bad as it might be i= >> n C where you might be indexing an
>=3B array with the incorrectly cal= >> culated integer and send your program off in
>=3B never-never land. I= >> n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= >> t it's still not right.
>=3B
>=3B If I am understanding properly= >> what is going on I think this means your new
>=3B Modula-3-to-C compi= >> ler is the most reasonably behaving Modula-3 implementation.
>=3B
= >> >=3B Mika
>> = >> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- From jay.krell at cornell.edu Wed Sep 4 19:00:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 17:00:51 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <20130904163217.C90041A2080@async.async.caltech.edu> References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> Message-ID: > Well, I agree wholeheartedly, yes. Tony: can we put in range checks on float to int conversions? I'd be ok with initially: if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 error The "1" isn't quite right, but "0" is also wrong. I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". - Jay > To: jay.krell at cornell.edu > Date: Wed, 4 Sep 2013 09:32:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > Jay K writes: > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > > > > > >I wish=2C but no=2C it is the same as the others. > > I see... > > > > > > >It is all a bit subtle. > > As always... > > > > ... > > > > > >I believe=2C based on what you are saying=2C > >the frontend should generate range checks before > >floor/trunc/ceiling. > > > >Roughly it should be an error to convert > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >Plus or minus one though. > > > > > >That is=2C > > FLOOR(LAST(INTEGER) + .99999) is ok. > > CEILING(FIRST(INTEGER) - .99999) is ok. > > ROUND(LAST(INTEGER) - .499999) is ok. > > ROUND(FIRST(INTEGER) + .499999) is ok. > >=20 > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >needs the checks I describe. But a 53bit mantissa converted to > >a 64bit integer=2C no range check is needed. > > > > > >The frontend has some of those optimizations already -- converting > >from a smaller range to a larger range needs no check. > > > > > >Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > > >Nor particularly inefficient? > > > > > > > > - Jay > > > > > > > > > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >events? > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> Jay K writes: > >> ... > >> > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > >> > > >> > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >met=3D > >> >ic_operations.html > >> > > >> > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >he co=3D > >> >nstant RoundDefault > >> > > >> > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > >> > > >> > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > >> > > >> > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >> > and LAST(INTEGER). But is it safe? > >> > > >>=20 > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >s=2C > >> "integer" is the abstract mathematical concept of an integer=2C not the > >> Modula-3 data type INTEGER. > >>=20 > >> I think the intent of the Green Book is that INTEGER should be a range-li= > >mited > >> form of integer=2C that is=2C it should behave like an integer as much as= > > possible=2C > >> and when the implementation can no longer accomplish that=2C it should si= > >gnal a=20 > >> runtime error. =20 > >>=20 > >> It happens that many existing implementions of Modula-3=2C as an implemen= > >tation > >> restriction=2C do not handle out-of-range situations correctly. Things > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > >range. > >> Some implementations wrap instead=2C but I don't even think that's right.= > > Of > >> course it's not as bad as it might be in C where you might be indexing an > >> array with the incorrectly calculated integer and send your program off i= > >n > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >T > >> point. But it's still not right. > >>=20 > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > >>=20 > >> Mika > > = > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > >
>=3B If I am understanding pro= > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > >compiler is the most reasonably behaving Modula-3 implementation.

>r>I wish=2C but no=2C it is the same as the others.


It is all a = > >bit subtle.


Here is what I believe happens:


I386_NT: = > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > that can be
successfully assigned to this range=2C with or without
a= > > range check.


m3cc: Posix: The values are in range.
With or w= > >ithout a range check=2C the code succeeds.
For a "few" more years.
>r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >systems will fail here.
32bit Posix would continue to round to some 32bi= > >t integer=2C which would then
successfully pass into the identical subra= > >nge -- like I386_NT today.



The backends don't add range chec= > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > >ngreal is target-dependent and knowledge
of it should only exist in the = > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >s the same since around the early 1980s.



I believe=2C based = > >on what you are saying=2C
the frontend should generate range checks befo= > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >ded.


The frontend has some of those optimizations already -- con= > >verting
from a smaller range to a larger range needs no check.

>r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >cient?



 =3B- Jay




>=3B To: jay.= > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > Book is that INTEGER should be a range-limited
>=3B form of integer= > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > restriction=2C do not handle out-of-range situations correctly. Things >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >n think that's right. Of
>=3B course it's not as bad as it might be i= > >n C where you might be indexing an
>=3B array with the incorrectly cal= > >culated integer and send your program off in
>=3B never-never land. I= > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >>=3B Mika
> >= > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 19:22:53 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 17:22:53 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu> References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu>, <53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu> Message-ID: Target.Float is definitely not entire problem, but probably is part of it. Runtime checks are missing also. - Jay > From: hosking at cs.purdue.edu > Date: Wed, 4 Sep 2013 12:48:46 -0400 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > So, what is the precise proposal? Fix Target.Float to avoid constant folding in these instances? That seems reasonable to me. > > On Sep 4, 2013, at 12:32 PM, mika at async.caltech.edu wrote: > > > Jay K writes: > >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >>> If I am understanding properly what is going on I think this means your n= > >> ew > >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >> ation. > >> > >> > >> I wish=2C but no=2C it is the same as the others. > > > > I see... > > > >> > >> > >> It is all a bit subtle. > > > > As always... > > > >> > > ... > >> > >> > >> I believe=2C based on what you are saying=2C > >> the frontend should generate range checks before > >> floor/trunc/ceiling. > >> > >> Roughly it should be an error to convert > >> a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >> Plus or minus one though. > >> > >> > >> That is=2C > >> FLOOR(LAST(INTEGER) + .99999) is ok. > >> CEILING(FIRST(INTEGER) - .99999) is ok. > >> ROUND(LAST(INTEGER) - .499999) is ok. > >> ROUND(FIRST(INTEGER) + .499999) is ok. > >> =20 > >> > >> I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > >> > >> > >> Oh wait. It depends on the relative ranges of float and integer. > >> > >> > >> In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >> needs the checks I describe. But a 53bit mantissa converted to > >> a 64bit integer=2C no range check is needed. > >> > >> > >> The frontend has some of those optimizations already -- converting > >> from a smaller range to a larger range needs no check. > >> > >> > >> Agreed? Surely this is not a difficult change? > > > > Well, I agree wholeheartedly, yes. > > > >> Nor particularly inefficient? > >> > >> > >> > >> - Jay > >> > >> > >> > >> > >>> To: jay.krell at cornell.edu > >>> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >> events? > >>> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >>> From: mika at async.caltech.edu > >>> =20 > >>> Jay K writes: > >>> ... > >>>> > >>>> Ok=3D2C so this is three dilemnas/questions/bugs in one. > >>>> > >>>> > >>>> http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >> met=3D > >>>> ic_operations.html > >>>> > >>>> > >>>> ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >> he co=3D > >>>> nstant RoundDefault > >>>> > >>>> > >>>> 1) How should ROUND be defined? Is Modula-3 adequately safe here? > >>>> > >>>> > >>>> What should round of numbers less than FIRST(INTEGER)-1=3D20 > >>>> or greater than LAST(INTEGER) + 1 round to?=3D20 > >>>> > >>>> > >>>> By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >>>> and LAST(INTEGER). But is it safe? > >>>> > >>> =20 > >>> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >> s=2C > >>> "integer" is the abstract mathematical concept of an integer=2C not the > >>> Modula-3 data type INTEGER. > >>> =20 > >>> I think the intent of the Green Book is that INTEGER should be a range-li= > >> mited > >>> form of integer=2C that is=2C it should behave like an integer as much as= > >> possible=2C > >>> and when the implementation can no longer accomplish that=2C it should si= > >> gnal a=20 > >>> runtime error. =20 > >>> =20 > >>> It happens that many existing implementions of Modula-3=2C as an implemen= > >> tation > >>> restriction=2C do not handle out-of-range situations correctly. Things > >>> such as what you describe SHOULD lead to a runtime error=2C value out of = > >> range. > >>> Some implementations wrap instead=2C but I don't even think that's right.= > >> Of > >>> course it's not as bad as it might be in C where you might be indexing an > >>> array with the incorrectly calculated integer and send your program off i= > >> n > >>> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >> T > >>> point. But it's still not right. > >>> =20 > >>> If I am understanding properly what is going on I think this means your n= > >> ew > >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >> ation. > >>> =20 > >>> Mika > >> = > >> > >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >>
>=3B If I am understanding pro= > >> perly what is going on I think this means your new
>=3B Modula-3-to-C = > >> compiler is the most reasonably behaving Modula-3 implementation.

>> r>I wish=2C but no=2C it is the same as the others.


It is all a = > >> bit subtle.


Here is what I believe happens:


I386_NT: = > >> from any double=2C round will give us
some integer=2C a 32bit integer=2C= > >> that can be
successfully assigned to this range=2C with or without
a= > >> range check.


m3cc: Posix: The values are in range.
With or w= > >> ithout a range check=2C the code succeeds.
For a "few" more years.
>> r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >> .
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >> s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >> teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >> systems will fail here.
32bit Posix would continue to round to some 32bi= > >> t integer=2C which would then
successfully pass into the identical subra= > >> nge -- like I386_NT today.



The backends don't add range chec= > >> ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >> ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >> nd at least roughly
the range of longreal.
Possibly the range of a lo= > >> ngreal is target-dependent and knowledge
of it should only exist in the = > >> backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >> s the same since around the early 1980s.



I believe=2C based = > >> on what you are saying=2C
the frontend should generate range checks befo= > >> re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >> br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >> us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >> ) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > >> + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >> =2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >> ive ranges of float and integer.


In particular=2C a 53bit mantis= > >> sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >> t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >> ded.


The frontend has some of those optimizations already -- con= > >> verting
from a smaller range to a larger range needs no check.

>> r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >> cient?



 =3B- Jay




>=3B To: jay.= > >> krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >> itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >> 2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >> rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >> ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >> t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >> _10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >> =3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >> re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >> =3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > >> Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >> =3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >> >=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >> t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >> hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >> is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >> on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > >> the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >> a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > >> Book is that INTEGER should be a range-limited
>=3B form of integer= > >> =2C that is=2C it should behave like an integer as much as possible=2C
&= > >> gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >> d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >> t many existing implementions of Modula-3=2C as an implementation
>=3B= > >> restriction=2C do not handle out-of-range situations correctly. Things >>> >=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >> ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >> n think that's right. Of
>=3B course it's not as bad as it might be i= > >> n C where you might be indexing an
>=3B array with the incorrectly cal= > >> culated integer and send your program off in
>=3B never-never land. I= > >> n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >> t it's still not right.
>=3B
>=3B If I am understanding properly= > >> what is going on I think this means your new
>=3B Modula-3-to-C compi= > >> ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >> >=3B Mika
> >> = > >> > >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 4 19:54:29 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 4 Sep 2013 13:54:29 -0400 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: But we don?t check integer overflow. Putting a check on all conversions seems onerous and expensive. If the programmer wants the check perhaps they should program it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Sep 4, 2013, at 1:49 PM, Jay K wrote: > I want both. > > > We check subrange assignments. > This seems almost the same thing. > When a programming converts float to int, what do they accept they are losing? > Precision or range or both? > I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. > > > The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. > > > Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? > Our obligation is only type safety? > round/trunc/ceiling can return random numbers and still be type safe? > (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) > > > - Jay > > > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > From: antony.hosking at gmail.com > Date: Wed, 4 Sep 2013 13:31:01 -0400 > CC: mika at async.caltech.edu; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. > > On Sep 4, 2013, at 1:00 PM, Jay K wrote: > > > Well, I agree wholeheartedly, yes. > > > Tony: can we put in range checks on float to int conversions? > I'd be ok with initially: > if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 > error > > The "1" isn't quite right, but "0" is also wrong. > > > I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). > > And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". > > > - Jay > > > > To: jay.krell at cornell.edu > > Date: Wed, 4 Sep 2013 09:32:17 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > > > Jay K writes: > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/plain; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > > > > > > > >I wish=2C but no=2C it is the same as the others. > > > > I see... > > > > > > > > > > >It is all a bit subtle. > > > > As always... > > > > > > > ... > > > > > > > > >I believe=2C based on what you are saying=2C > > >the frontend should generate range checks before > > >floor/trunc/ceiling. > > > > > >Roughly it should be an error to convert > > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > > >Plus or minus one though. > > > > > > > > >That is=2C > > > FLOOR(LAST(INTEGER) + .99999) is ok. > > > CEILING(FIRST(INTEGER) - .99999) is ok. > > > ROUND(LAST(INTEGER) - .499999) is ok. > > > ROUND(FIRST(INTEGER) + .499999) is ok. > > >=20 > > > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > > >needs the checks I describe. But a 53bit mantissa converted to > > >a 64bit integer=2C no range check is needed. > > > > > > > > >The frontend has some of those optimizations already -- converting > > >from a smaller range to a larger range needs no check. > > > > > > > > >Agreed? Surely this is not a difficult change? > > > > Well, I agree wholeheartedly, yes. > > > > >Nor particularly inefficient? > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > >> To: jay.krell at cornell.edu > > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > > >events? > > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > > >> From: mika at async.caltech.edu > > >>=20 > > >> Jay K writes: > > >> ... > > >> > > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > > >> > > > >> > > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > > >met=3D > > >> >ic_operations.html > > >> > > > >> > > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > > >he co=3D > > >> >nstant RoundDefault > > >> > > > >> > > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > > >> > > > >> > > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > > >> > > > >> > > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > > >> > and LAST(INTEGER). But is it safe? > > >> > > > >>=20 > > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > > >s=2C > > >> "integer" is the abstract mathematical concept of an integer=2C not the > > >> Modula-3 data type INTEGER. > > >>=20 > > >> I think the intent of the Green Book is that INTEGER should be a range-li= > > >mited > > >> form of integer=2C that is=2C it should behave like an integer as much as= > > > possible=2C > > >> and when the implementation can no longer accomplish that=2C it should si= > > >gnal a=20 > > >> runtime error. =20 > > >>=20 > > >> It happens that many existing implementions of Modula-3=2C as an implemen= > > >tation > > >> restriction=2C do not handle out-of-range situations correctly. Things > > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > > >range. > > >> Some implementations wrap instead=2C but I don't even think that's right.= > > > Of > > >> course it's not as bad as it might be in C where you might be indexing an > > >> array with the incorrectly calculated integer and send your program off i= > > >n > > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > > >T > > >> point. But it's still not right. > > >>=20 > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > >>=20 > > >> Mika > > > = > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/html; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > >
>=3B If I am understanding pro= > > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > > >compiler is the most reasonably behaving Modula-3 implementation.

> >r>I wish=2C but no=2C it is the same as the others.


It is all a = > > >bit subtle.


Here is what I believe happens:


I386_NT: = > > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > > that can be
successfully assigned to this range=2C with or without
a= > > > range check.


m3cc: Posix: The values are in range.
With or w= > > >ithout a range check=2C the code succeeds.
For a "few" more years.
> >r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > > >systems will fail here.
32bit Posix would continue to round to some 32bi= > > >t integer=2C which would then
successfully pass into the identical subra= > > >nge -- like I386_NT today.



The backends don't add range chec= > > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > > >ngreal is target-dependent and knowledge
of it should only exist in the = > > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > > >s the same since around the early 1980s.



I believe=2C based = > > >on what you are saying=2C
the frontend should generate range checks befo= > > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > > >ded.


The frontend has some of those optimizations already -- con= > > >verting
from a smaller range to a larger range needs no check.

> >r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > > >cient?



 =3B- Jay




>=3B To: jay.= > > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > > Book is that INTEGER should be a range-limited
>=3B form of integer= > > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > > restriction=2C do not handle out-of-range situations correctly. Things > >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > > >n think that's right. Of
>=3B course it's not as bad as it might be i= > > >n C where you might be indexing an
>=3B array with the incorrectly cal= > > >culated integer and send your program off in
>=3B never-never land. I= > > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > > >>=3B Mika
> > >= > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 19:49:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 17:49:02 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: I want both. We check subrange assignments. This seems almost the same thing. When a programming converts float to int, what do they accept they are losing? Precision or range or both? I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? Our obligation is only type safety? round/trunc/ceiling can return random numbers and still be type safe? (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) - Jay Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? From: antony.hosking at gmail.com Date: Wed, 4 Sep 2013 13:31:01 -0400 CC: mika at async.caltech.edu; m3devel at elegosoft.com To: jay.krell at cornell.edu I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. On Sep 4, 2013, at 1:00 PM, Jay K wrote:> Well, I agree wholeheartedly, yes. Tony: can we put in range checks on float to int conversions? I'd be ok with initially: if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 error The "1" isn't quite right, but "0" is also wrong. I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". - Jay > To: jay.krell at cornell.edu > Date: Wed, 4 Sep 2013 09:32:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > Jay K writes: > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > > > > > >I wish=2C but no=2C it is the same as the others. > > I see... > > > > > > >It is all a bit subtle. > > As always... > > > > ... > > > > > >I believe=2C based on what you are saying=2C > >the frontend should generate range checks before > >floor/trunc/ceiling. > > > >Roughly it should be an error to convert > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >Plus or minus one though. > > > > > >That is=2C > > FLOOR(LAST(INTEGER) + .99999) is ok. > > CEILING(FIRST(INTEGER) - .99999) is ok. > > ROUND(LAST(INTEGER) - .499999) is ok. > > ROUND(FIRST(INTEGER) + .499999) is ok. > >=20 > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >needs the checks I describe. But a 53bit mantissa converted to > >a 64bit integer=2C no range check is needed. > > > > > >The frontend has some of those optimizations already -- converting > >from a smaller range to a larger range needs no check. > > > > > >Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > > >Nor particularly inefficient? > > > > > > > > - Jay > > > > > > > > > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >events? > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> Jay K writes: > >> ... > >> > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > >> > > >> > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >met=3D > >> >ic_operations.html > >> > > >> > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >he co=3D > >> >nstant RoundDefault > >> > > >> > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > >> > > >> > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > >> > > >> > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >> > and LAST(INTEGER). But is it safe? > >> > > >>=20 > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >s=2C > >> "integer" is the abstract mathematical concept of an integer=2C not the > >> Modula-3 data type INTEGER. > >>=20 > >> I think the intent of the Green Book is that INTEGER should be a range-li= > >mited > >> form of integer=2C that is=2C it should behave like an integer as much as= > > possible=2C > >> and when the implementation can no longer accomplish that=2C it should si= > >gnal a=20 > >> runtime error. =20 > >>=20 > >> It happens that many existing implementions of Modula-3=2C as an implemen= > >tation > >> restriction=2C do not handle out-of-range situations correctly. Things > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > >range. > >> Some implementations wrap instead=2C but I don't even think that's right.= > > Of > >> course it's not as bad as it might be in C where you might be indexing an > >> array with the incorrectly calculated integer and send your program off i= > >n > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >T > >> point. But it's still not right. > >>=20 > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > >>=20 > >> Mika > > = > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > >
>=3B If I am understanding pro= > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > >compiler is the most reasonably behaving Modula-3 implementation.

>r>I wish=2C but no=2C it is the same as the others.


It is all a = > >bit subtle.


Here is what I believe happens:


I386_NT: = > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > that can be
successfully assigned to this range=2C with or without
a= > > range check.


m3cc: Posix: The values are in range.
With or w= > >ithout a range check=2C the code succeeds.
For a "few" more years.
>r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >systems will fail here.
32bit Posix would continue to round to some 32bi= > >t integer=2C which would then
successfully pass into the identical subra= > >nge -- like I386_NT today.



The backends don't add range chec= > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > >ngreal is target-dependent and knowledge
of it should only exist in the = > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >s the same since around the early 1980s.



I believe=2C based = > >on what you are saying=2C
the frontend should generate range checks befo= > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >ded.


The frontend has some of those optimizations already -- con= > >verting
from a smaller range to a larger range needs no check.

>r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >cient?



 =3B- Jay




>=3B To: jay.= > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > Book is that INTEGER should be a range-limited
>=3B form of integer= > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > restriction=2C do not handle out-of-range situations correctly. Things >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >n think that's right. Of
>=3B course it's not as bad as it might be i= > >n C where you might be indexing an
>=3B array with the incorrectly cal= > >culated integer and send your program off in
>=3B never-never land. I= > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >>=3B Mika
> >= > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielal.benavides at bancoagrario.gov.co Wed Sep 4 21:09:04 2013 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Wed, 4 Sep 2013 19:09:04 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: <1AF4998819C60A40A4CD8C3B6582D3DA294BEFFF@DRG008W8SMBX014.bancoagrario.gov.co> Hi all: Jay, type checking is one thing while range checking is another. Range checking is harder than type checking, that's the point here. If you want range checking with brute force you get a penalty obviously. If you want integer overflow checking is the same thing, perhaps there could be hope in ESC, I haven't asked that. DEC Alpha had a special purpose lobotomized AMD64 like architecture perhaps that provided the hardware needed for that; also see below: http://www.google.com/patents/?vid=USPAT6470373 Thanks in advance De: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] En nombre de Jay K Enviado el: Wednesday, 04 de September de 2013 12:49 p.m. Para: Antony Hosking CC: m3devel Asunto: Re: [M3devel] rounding very large magnitude longreal, time, events? I want both. We check subrange assignments. This seems almost the same thing. When a programming converts float to int, what do they accept they are losing? Precision or range or both? I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? Our obligation is only type safety? round/trunc/ceiling can return random numbers and still be type safe? (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) - Jay ________________________________ Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? From: antony.hosking at gmail.com Date: Wed, 4 Sep 2013 13:31:01 -0400 CC: mika at async.caltech.edu; m3devel at elegosoft.com To: jay.krell at cornell.edu I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. On Sep 4, 2013, at 1:00 PM, Jay K > wrote: > Well, I agree wholeheartedly, yes. Tony: can we put in range checks on float to int conversions? I'd be ok with initially: if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 error The "1" isn't quite right, but "0" is also wrong. I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". - Jay > To: jay.krell at cornell.edu > Date: Wed, 4 Sep 2013 09:32:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > Jay K writes: > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > > > > > >I wish=2C but no=2C it is the same as the others. > > I see... > > > > > > >It is all a bit subtle. > > As always... > > > > ... > > > > > >I believe=2C based on what you are saying=2C > >the frontend should generate range checks before > >floor/trunc/ceiling. > > > >Roughly it should be an error to convert > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >Plus or minus one though. > > > > > >That is=2C > > FLOOR(LAST(INTEGER) + .99999) is ok. > > CEILING(FIRST(INTEGER) - .99999) is ok. > > ROUND(LAST(INTEGER) - .499999) is ok. > > ROUND(FIRST(INTEGER) + .499999) is ok. > >=20 > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >needs the checks I describe. But a 53bit mantissa converted to > >a 64bit integer=2C no range check is needed. > > > > > >The frontend has some of those optimizations already -- converting > >from a smaller range to a larger range needs no check. > > > > > >Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > > >Nor particularly inefficient? > > > > > > > > - Jay > > > > > > > > > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >events? > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> Jay K writes: > >> ... > >> > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > >> > > >> > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >met=3D > >> >ic_operations.html > >> > > >> > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >he co=3D > >> >nstant RoundDefault > >> > > >> > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > >> > > >> > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > >> > > >> > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >> > and LAST(INTEGER). But is it safe? > >> > > >>=20 > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >s=2C > >> "integer" is the abstract mathematical concept of an integer=2C not the > >> Modula-3 data type INTEGER. > >>=20 > >> I think the intent of the Green Book is that INTEGER should be a range-li= > >mited > >> form of integer=2C that is=2C it should behave like an integer as much as= > > possible=2C > >> and when the implementation can no longer accomplish that=2C it should si= > >gnal a=20 > >> runtime error. =20 > >>=20 > >> It happens that many existing implementions of Modula-3=2C as an implemen= > >tation > >> restriction=2C do not handle out-of-range situations correctly. Things > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > >range. > >> Some implementations wrap instead=2C but I don't even think that's right.= > > Of > >> course it's not as bad as it might be in C where you might be indexing an > >> array with the incorrectly calculated integer and send your program off i= > >n > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >T > >> point. But it's still not right. > >>=20 > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > >>=20 > >> Mika > > = > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > >
>=3B If I am understanding pro= > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > >compiler is the most reasonably behaving Modula-3 implementation.

>r>I wish=2C but no=2C it is the same as the others.


It is all a = > >bit subtle.


Here is what I believe happens:


I386_NT: = > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > that can be
successfully assigned to this range=2C with or without
a= > > range check.


m3cc: Posix: The values are in range.
With or w= > >ithout a range check=2C the code succeeds.
For a "few" more years.
>r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >systems will fail here.
32bit Posix would continue to round to some 32bi= > >t integer=2C which would then
successfully pass into the identical subra= > >nge -- like I386_NT today.



The backends don't add range chec= > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > >ngreal is target-dependent and knowledge
of it should only exist in the = > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >s the same since around the early 1980s.



I believe=2C based = > >on what you are saying=2C
the frontend should generate range checks befo= > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >ded.


The frontend has some of those optimizations already -- con= > >verting
from a smaller range to a larger range needs no check.

>r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >cient?



 =3B- Jay




>=3B To: jay.= > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > Book is that INTEGER should be a range-limited
>=3B form of integer= > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > restriction=2C do not handle out-of-range situations correctly. Things >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >n think that's right. Of
>=3B course it's not as bad as it might be i= > >n C where you might be indexing an
>=3B array with the incorrectly cal= > >culated integer and send your program off in
>=3B never-never land. I= > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >>=3B Mika
> >= > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Sep 5 03:40:34 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 5 Sep 2013 02:40:34 +0100 (BST) Subject: [M3devel] AMD64_NT In-Reply-To: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> References: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> Message-ID: <1378345234.54343.YahooMailNeo@web172801.mail.ir2.yahoo.com> Hi all: these are incredible news! DEC SRC, used the same target to cross build Win32 host. I would like to test it on WinXP64ed and then produce boot images for vista and 7. But I want to build it from source if I may please. For instance cross build it from WinXP build it in WinXP64ed, and produce snapshots from there. Trust me I have a good reason for it. If Im may say so, DEC SRC had a philosophy inside M3 implementation that we should persevere. All RT written in Modula-3, please no more C, just in case if needed please; see for instance why we shouldn't have third party libraries, just compiler and that's all. It exposes the need for complex runtimes in RISC compilers, like MicroVax2 (DEC Firefly) and the most complex DEC machine the VAX9000: http://users.ece.utexas.edu/~patt/12s.382N/handouts/class_slides/risc_retrospective.ppt Such that if needs assembly level stuff let's do it but no more C as source format. It's error prone, I prefer cloning over C sources 100% times. C as intermediate rep is another thing clearly. Thanks in advance ________________________________ De: Jay Para: m3devel Enviado: Martes 3 de septiembre de 2013 11:06 Asunto: [M3devel] AMD64_NT AMD_NT runs, can build itself, is more debuggable than NT386, Juno & formsedit come up. It was a fairly quick straightforward use of the C backend. There is a problem in m3core/Time that hangs mentor startup. The first time I ran cm3ide it brought up IE but hit an out-of-range in socket code. Elego code failed to build due to lack of c:\cygwin (I have c:\cygwin64). There is a problem in exception handling worked around using libcmt.lib instead of msvcr*.dll. The unsafe out of date cloned headers have as usual been a source of bugs. I'll try to get a snapshot out soon. Adventurous folks can try it already. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Sep 5 16:26:54 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 05 Sep 2013 09:26:54 -0500 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Message-ID: <522894AE.2070708@lcwb.coop> On 09/03/2013 12:50 PM, Jay K wrote: > I think it isn't just TextLiteral.MaxBytes. > > > How do I declare an unbouned-ly sized array? You use an open array. Then the compiler arranges to store its bound at runtime, using that instead of a static constant when generating bounds checks. In order to avoid big messes in both language definition and implementation, you can create a "ground" open array value only by allocating it in the heap. You can also, in effect, convert a fixed array value (created any way you like) by passing it to a formal of open array type or applying SUBARRAY to it with non-static length. The whole TextLiteral thing is a low-level implementation thing to allow the compiler to construct it statically, yet avoid having to always copy it into the traced heap the first thing at runtime. I haven't looked, but I would bet PM3 always copies a text literal into a heap object before creating a traced reference value pointing to it. Yes, it's unsafe in the sense that the usual array bounds mechanism is just circumvented by making it a fixed array with much larger bound than reality. The code in TextLiteral takes care of enforcing the bounds, instead of the usual compiler-generated mechanism. > At the end of a record? The language does not allow this. It has to be an autonomous object. I have a use-case that would save a lot of space if you could do this. There is big space overhead in separating it into a separate object, which can matter if the average size of the arrays is small. I have often thought about the implications of allowing it. I think the effects on the language would be dire, and would also require a lot of implementation work, including lots of GC additions. This is the same ol' tradeoff. Highly flexible mechanisms are less efficient. > Doesn't matter? > > > For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? > > For legitimate uses, this limit is quite enough. Right off hand, I doubt the old crack of, e.g., entering 4K character passwords, user names, etc., can be used here, because all text values, TextLiteral included, are compiled as immutable objects. Input values would never be stored into an existing text literal. Even if they were, the TextLiteral library code would be checking bounds at runtime. In at least some targets, these are also stored in readonly segments as well. > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: hosking at cs.purdue.edu > Date: Tue, 3 Sep 2013 13:00:08 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > > Yes, I want to avoid use of LONGINT in the compiler proper. > If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. > But I still don?t understand the precise use-case that you are proposing. > In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? > I cannot imaging a text literal that big, ever. > > > > Antony Hosking|Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Mobile+1 765 427 5484 > > > > > From rodney_bates at lcwb.coop Thu Sep 5 16:42:49 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 05 Sep 2013 09:42:49 -0500 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: References: Message-ID: <52289869.4000301@lcwb.coop> There is another issue here. I want TextLiteral.MaxBytes to get a final size and not change. Every time it changes, it creates compatibility problems by orphaning any existing pickle files and any compiled programs that write them. It changes the fingerprint, so a recently-compiled reading program can't find the type in its own list of known types. This also affects network objects when two communicating programs are compiled with different TextLiteral versions. MaxBytes' particular contribution to the type doesn't otherwise matter, because it's artificial, but it still undermines reading pickles. I have been loading up the pickle reading code with hard-coded historical fingerprints of various older versions. But it's a pain to keep doing, tedious to ferret out the values, and it still only helps those who constantly download and compile the latest CM3. At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint and hard-coding the compiler to artificially deliver it , rather than the one computed from the version-of-the day of TextLiteral. But this too would not help those who would rather not constantly download the latest, rebuild the compiler, then recompile their applications. On 09/03/2013 01:02 AM, Jay K wrote: > ok, another question: > > > CONST > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > TYPE > T = RTHooks.TextLiteral; > REVEAL > T = TEXT BRANDED "TextLiteral.T" OBJECT > cnt : INTEGER; > buf : ARRAY [0..MaxBytes - 1] OF Byte; > OVERRIDES ... > > > T is a reference type. > Is there a way to state this with no limit? > > > Isn't it already unsafe? > You know -- the array is usually smaller and the compiler is only going to check against this large size. > > > - Jay From dmuysers at hotmail.com Thu Sep 5 16:56:34 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Thu, 5 Sep 2013 16:56:34 +0200 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Intmore? Message-ID: > The whole TextLiteral thing is a low-level implementation thing to allow the > compiler to construct it statically, yet avoid having to always copy it into > the traced heap the first thing at runtime. I haven't looked, but I would bet > PM3 always copies a text literal into a heap object before creating a traced > reference value pointing to it. For a TextExpr, ie a literal, pm3 generates PROCEDURE Compile (p: P) = VAR uid := SetUID (p); BEGIN CG.Load_addr_of (global_data, literals[uid] + Target.Address.pack, Target.Address.align); END Compile; So it is, in fact, an UNTRACED REF, the GC will know, I guess. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 5 18:05:07 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 5 Sep 2013 12:05:07 -0400 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: <52289869.4000301@lcwb.coop> References: <52289869.4000301@lcwb.coop> Message-ID: <35F457AE-9FD1-4E16-906E-F3CFAB657102@cs.purdue.edu> Here is a modest proposal that should resolve this issue. Declare TextLiteral.T to have a minimal buf: ARRAY [0..0] OF Byte; Then use UNSAFE address arithmetic to access the bytes (TextLiteral.m3 already does the bounds checks explicitly using cnt). Updated TextLiteral.i3 and TextLiteral.m3 attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: TextLiteral.i3 Type: application/octet-stream Size: 1134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TextLiteral.m3 Type: application/octet-stream Size: 2989 bytes Desc: not available URL: -------------- next part -------------- Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Sep 5, 2013, at 10:42 AM, "Rodney M. Bates" wrote: > There is another issue here. I want TextLiteral.MaxBytes to get a final size > and not change. Every time it changes, it creates compatibility problems by > orphaning any existing pickle files and any compiled programs that write them. > It changes the fingerprint, so a recently-compiled reading program can't find the > type in its own list of known types. This also affects network objects when two > communicating programs are compiled with different TextLiteral versions. > > MaxBytes' particular contribution to the type doesn't otherwise matter, because it's > artificial, but it still undermines reading pickles. > > I have been loading up the pickle reading code with hard-coded historical fingerprints > of various older versions. But it's a pain to keep doing, tedious to ferret out the > values, and it still only helps those who constantly download and compile the latest > CM3. > > At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint > and hard-coding the compiler to artificially deliver it , rather than the one computed from > the version-of-the day of TextLiteral. But this too would not help those who would > rather not constantly download the latest, rebuild the compiler, then recompile their > applications. > > On 09/03/2013 01:02 AM, Jay K wrote: >> ok, another question: >> >> >> CONST >> (* DIV BITSIZE should not be here! *) >> (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) >> MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); >> >> TYPE >> T = RTHooks.TextLiteral; >> REVEAL >> T = TEXT BRANDED "TextLiteral.T" OBJECT >> cnt : INTEGER; >> buf : ARRAY [0..MaxBytes - 1] OF Byte; >> OVERRIDES ... >> >> >> T is a reference type. >> Is there a way to state this with no limit? >> >> >> Isn't it already unsafe? >> You know -- the array is usually smaller and the compiler is only going to check against this large size. >> >> >> - Jay > From jay.krell at cornell.edu Fri Sep 6 02:06:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Sep 2013 00:06:41 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <522894AE.2070708@lcwb.coop> References: , , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , , , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>, , <522894AE.2070708@lcwb.coop> Message-ID: > > How do I declare an unbouned-ly sized array? > > You use an open array. Then the compiler arranges to store its bound at runtime, > using that instead of a static constant when generating bounds checks. Sorry, I meant a pointer that I can index arbitrarily far. I think this is just UNTRACED REF T . > . In at least some targets, these are also stored in readonly segments as well. Surely this is all targets these days/years/decades. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Sep 6 22:01:36 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 15:01:36 -0500 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , , , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>, , <522894AE.2070708@lcwb.coop> Message-ID: <522A34A0.50307@lcwb.coop> On 09/05/2013 07:06 PM, Jay K wrote: > > > How do I declare an unbouned-ly sized array? > > > > You use an open array. Then the compiler arranges to store its bound at runtime, > > using that instead of a static constant when generating bounds checks. > > Sorry, I meant a pointer that I can index arbitrarily far. > I think this is just UNTRACED REF T . Ah, do you mean you want to disable the bounds check? Using the ARRAY types of Modula-3, I don't believe you can. I think I recall some kind of compiler option, not so easy to find, that will do this, but I think unselectively for all subscripted array references in, perhaps an entire source file. Based on painful experiences of my own and others, going a long way back, I never do this. For single-character-at-a-time, you can avoid array types altogether something like: Element I of Array A, of elements of type ET: LOOPHOLE(ADR(A[0]) + (I-FIRST(A))*ADRSIZE(ET), UNTRACED REF ET)^ But watch out for sub-adr-sized or non-integral-adr-sized elements! > > > . In at least some targets, these are also stored in readonly segments as well. > > Surely this is all targets these days/years/decades. > > - Jay From rodney_bates at lcwb.coop Fri Sep 6 22:12:55 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 15:12:55 -0500 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: <35F457AE-9FD1-4E16-906E-F3CFAB657102@cs.purdue.edu> References: <52289869.4000301@lcwb.coop> <35F457AE-9FD1-4E16-906E-F3CFAB657102@cs.purdue.edu> Message-ID: <522A3747.7060105@lcwb.coop> On 09/05/2013 11:05 AM, Tony Hosking wrote: > Here is a modest proposal that should resolve this issue. > Declare TextLiteral.T to have a minimal buf: ARRAY [0..0] OF Byte; > Then use UNSAFE address arithmetic to access the bytes (TextLiteral.m3 already does the bounds checks explicitly using cnt). > > Updated TextLiteral.i3 and TextLiteral.m3 attached. > That would address the changing fingerprint problem. The declaration of buf should have a conspicuous and unambiguous "Keep your hands off" comment, with explanation why. > > > > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Mobile +1 765 427 5484 > > > > > > On Sep 5, 2013, at 10:42 AM, "Rodney M. Bates" wrote: > >> There is another issue here. I want TextLiteral.MaxBytes to get a final size >> and not change. Every time it changes, it creates compatibility problems by >> orphaning any existing pickle files and any compiled programs that write them. >> It changes the fingerprint, so a recently-compiled reading program can't find the >> type in its own list of known types. This also affects network objects when two >> communicating programs are compiled with different TextLiteral versions. >> >> MaxBytes' particular contribution to the type doesn't otherwise matter, because it's >> artificial, but it still undermines reading pickles. >> >> I have been loading up the pickle reading code with hard-coded historical fingerprints >> of various older versions. But it's a pain to keep doing, tedious to ferret out the >> values, and it still only helps those who constantly download and compile the latest >> CM3. >> >> At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint >> and hard-coding the compiler to artificially deliver it , rather than the one computed from >> the version-of-the day of TextLiteral. But this too would not help those who would >> rather not constantly download the latest, rebuild the compiler, then recompile their >> applications. >> >> On 09/03/2013 01:02 AM, Jay K wrote: >>> ok, another question: >>> >>> >>> CONST >>> (* DIV BITSIZE should not be here! *) >>> (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) >>> MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); >>> >>> TYPE >>> T = RTHooks.TextLiteral; >>> REVEAL >>> T = TEXT BRANDED "TextLiteral.T" OBJECT >>> cnt : INTEGER; >>> buf : ARRAY [0..MaxBytes - 1] OF Byte; >>> OVERRIDES ... >>> >>> >>> T is a reference type. >>> Is there a way to state this with no limit? >>> >>> >>> Isn't it already unsafe? >>> You know -- the array is usually smaller and the compiler is only going to check against this large size. >>> >>> >>> - Jay >> > From rodney_bates at lcwb.coop Fri Sep 6 22:39:14 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 15:39:14 -0500 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: Message-ID: <522A3D72.1050402@lcwb.coop> On 09/04/2013 01:28 AM, Jay K wrote: > AMD64_NT starting up mentor: > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\EventWireRep.m3", line 89 > *** > > > This opens up a big multi-part can of worms. > I'm not sure the order to present things. > Please bear with me. > > > > Background: > > Time.T is a double/longreal number of seconds since a platform-specific epoch. > This cleverly gives I guess pretty good range and precison. > On Windows, that is 1601. > The underlying system stores 64bit 100s of nanoseconds. > This gives both good range and precision. > And it works ok with Modula-3. > On Posix is presumably 1970. > This is all ok. Not controversial. > > > > Corralaries: > > Time.Now on Windows returns around 1.3022747815483961e10. > My simple math says that is off by a month but hopefully > more precise math says it is exactly correct. > We have confusing Modula-3 code and straightforward C code to compute this. > That it is within a month seems adequate to backup everything > else I'm seeing/saying. > > > events!EventWireRep_M3 [c:\dev2\cm3\m3-comm\events\src\eventwirerep.m3 @ 90] > > Int32 = BITS 32 FOR [-2147483647-1..2147483647]; > TRep = RECORD ts: Int32; objNum: Int32; space: EventSpaceID.T; END; > > VAR myTs: Int32 := ROUND(Time.Now()); > > > Clearly this is a problem. > It runs out "soon" on 32bit Posix systems, it runs out > already on Win64, and on Win32, well, it produces > garbage one way or another, but no range errors. > > > On AMD64_NT, this reasonably rounds to > > 13022747815 -- the full integer value of the double > fits in a 64bit integer. > > But it doesn't fit in 32 bits. > On I386_NT, this somewhat "correctly" rounds to > -2147483648 > > Hm. Shouldn't it be nearest integer 2147483647?? > > > In either case, see you the problem. > > Ok, so this is three dilemnas/questions/bugs in one. > > > http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arithmetic_operations.html > > > ROUND(r) is the nearest integer to r; ties are broken according to the constant RoundDefault > This has an ambiguity. "nearest integer" could refer to the integers of mathematics, or to INTEGER of Modula-3. The lowercase spelling hints the former. I think that makes more sense, too. By the latter interpretation, values would round to LAST(INTEGER) from far beyond. By the former interpretation, if the nearest math integer is > LAST(INTEGER), there should be runtime error of some kind. But we can't rely on the assignment operation and Modula-3's assignability rules to do that, because ROUND would have to have a result type, big enough for all possibilities, a supertype of INTEGER. There is no such type, and we don't want one. (Ever had to cope with Ada's "universal integer" type? If not, you're lucky.) Which leaves making the check part of ROUND itself. > > 1) How should ROUND be defined? Is Modula-3 adequately safe here? > > > What should round of numbers less than FIRST(INTEGER)-1 > or greater than LAST(INTEGER) + 1 round to? > > > By the simple definition, they should round to FIRST(INTEGER) > and LAST(INTEGER). But is it safe? > > > You know, I can see taking the whole part of the number > and losing the fractional part as being ok when desired, > but when the whole part doesn't fit, not even when rounded > up or down by 1? Doesn't that seem like it should be a range error? > > > > 2) What is up with the various implementations? > > > ASSUMING Modula-3 ROUND is defined safely enough, > is the integrated NT/x86 backend correct here? > > > On I386_DARWIN: > > IMPORT IO, Fmt; > > BEGIN > IO.Put(Fmt.Int(ROUND(1.3022747815483961e10)) & "\n"); > END Main. > > > We get: 137845760. > > > Wow, that is just wrong. > Sure it got the mantissa close, but the exponent is arbitrary seeming. > I could chalk this up to a bug in my C backend, > but it gets constant folded in the front end. > The backend just gets load_integer 137845760. > This seems highly incorrect. > Maybe bugs in Target.Float? > Maybe overflow is being ignored?? > I'll look later, another day. > > > > 3) What to do? > > > 3a) The frontend seems wrong here, no matter what. > > 3b) The integrated backend seems at least slightly wrong. > > 3c) The events code either needs widening, or perhaps > this isn't time, but a somewhat arbitrary "fingerprint". > Perhaps it can just use MOD?? I will likely verify if it needs to be > time or just a reasonably volatile number to cross check sender/reciever > and then use MOD. Posix and Win32 systems probably can't talk to each other. Lame. > > > > Someone might suggest that Win32 epoch be changed to 1970. > I don't think so. > > > 4) can anyone understand and explain the Modula-3 code we have here in Time.m3? > > > > Thank you, > - Jay From rodney_bates at lcwb.coop Fri Sep 6 23:03:50 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 16:03:50 -0500 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: <522A4336.7000709@lcwb.coop> On 09/04/2013 12:49 PM, Jay K wrote: > I want both. > > > We check subrange assignments. > This seems almost the same thing. > When a programming converts float to int, what do they accept they are losing? > Precision or range or both? > I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. > > > The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. > Yes, that's always a dilemma. I tend to prefer accepting some constant-time micro-efficiency penalties for more predictable and tractable behavior. > > Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? My definition of safety is that everything that can happen can be defined or understood, using only the high-level concepts of the language, e.g., abstract values of types and operators on them, but not machine-level bits, representations, etc. This is contrary to every textbook and article I have ever read, but the traditional definitions are, IMO, neither of much use nor consistent with what people seem, informally, to mean by it. So what ROUND does could be defined using integers and floating point values. (Some ways of defining it might, however, just refer to bit-level representations.) > Our obligation is only type safety? No, safety is not our only obligation. Thinking only in terms of abstract values, operators could still be poorly defined or defined in ways that are not very meaningful. Right now, ROUND seems not to be defined for these cases. > round/trunc/ceiling can return random numbers and still be type safe? If the random values are members of INTEGER, repeatable, and definable via some rule that doesn't refer to machine-level representations, that would fit my definition of type safe, but that is not sufficient for good language design. As for efficiency, I believe that in this case, either rounding far-out-of-range to a limit of INTEGER or making it a runtime error would require runtime range checks by the implementation anyway. The only difference is what to do when the check fails. Personally, I would like it better if overflows were detected on the arithmetic operators too. This excludes Word.T, which is, I think the only place the language forbids it. > (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) > > > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > From: antony.hosking at gmail.com > Date: Wed, 4 Sep 2013 13:31:01 -0400 > CC: mika at async.caltech.edu; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. > > On Sep 4, 2013, at 1:00 PM, Jay K > wrote: > > > Well, I agree wholeheartedly, yes. > > > Tony: can we put in range checks on float to int conversions? > I'd be ok with initially: > if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 > error > > The "1" isn't quite right, but "0" is also wrong. > > > I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). > > And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". > > > - Jay > > > > To:jay.krell at cornell.edu > > Date: Wed, 4 Sep 2013 09:32:17 -0700 > > From:mika at async.caltech.edu > > CC:m3devel at elegosoft.com > > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > > > Jay K writes: > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/plain; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > > > > > > > >I wish=2C but no=2C it is the same as the others. > > > > I see... > > > > > > > > > > >It is all a bit subtle. > > > > As always... > > > > > > > ... > > > > > > > > >I believe=2C based on what you are saying=2C > > >the frontend should generate range checks before > > >floor/trunc/ceiling. > > > > > >Roughly it should be an error to convert > > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > > >Plus or minus one though. > > > > > > > > >That is=2C > > > FLOOR(LAST(INTEGER) + .99999) is ok. > > > CEILING(FIRST(INTEGER) - .99999) is ok. > > > ROUND(LAST(INTEGER) - .499999) is ok. > > > ROUND(FIRST(INTEGER) + .499999) is ok. > > >=20 > > > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > > >needs the checks I describe. But a 53bit mantissa converted to > > >a 64bit integer=2C no range check is needed. > > > > > > > > >The frontend has some of those optimizations already -- converting > > >from a smaller range to a larger range needs no check. > > > > > > > > >Agreed? Surely this is not a difficult change? > > > > Well, I agree wholeheartedly, yes. > > > > >Nor particularly inefficient? > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > >> To: jay.krell at cornell.edu > > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > > >events? > > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > > >> From: mika at async.caltech.edu > > >>=20 > > >> Jay K writes: > > >> ... > > >> > > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > > >> > > > >> > > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > > >met=3D > > >> >ic_operations.html > > >> > > > >> > > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > > >he co=3D > > >> >nstant RoundDefault > > >> > > > >> > > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > > >> > > > >> > > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > > >> > > > >> > > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > > >> > and LAST(INTEGER). But is it safe? > > >> > > > >>=20 > > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > > >s=2C > > >> "integer" is the abstract mathematical concept of an integer=2C not the > > >> Modula-3 data type INTEGER. > > >>=20 > > >> I think the intent of the Green Book is that INTEGER should be a range-li= > > >mited > > >> form of integer=2C that is=2C it should behave like an integer as much as= > > > possible=2C > > >> and when the implementation can no longer accomplish that=2C it should si= > > >gnal a=20 > > >> runtime error. =20 > > >>=20 > > >> It happens that many existing implementions of Modula-3=2C as an implemen= > > >tation > > >> restriction=2C do not handle out-of-range situations correctly. Things > > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > > >range. > > >> Some implementations wrap instead=2C but I don't even think that's right.= > > > Of > > >> course it's not as bad as it might be in C where you might be indexing an > > >> array with the incorrectly calculated integer and send your program off i= > > >n > > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > > >T > > >> point. But it's still not right. > > >>=20 > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > >>=20 > > >> Mika > > > = > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/html; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > >
>=3B If I am understanding pro= > > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > > >compiler is the most reasonably behaving Modula-3 implementation.

> >r>I wish=2C but no=2C it is the same as the others.


It is all a = > > >bit subtle.


Here is what I believe happens:


I386_NT: = > > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > > that can be
successfully assigned to this range=2C with or without
a= > > > range check.


m3cc: Posix: The values are in range.
With or w= > > >ithout a range check=2C the code succeeds.
For a "few" more years.
> >r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > > >systems will fail here.
32bit Posix would continue to round to some 32bi= > > >t integer=2C which would then
successfully pass into the identical subra= > > >nge -- like I386_NT today.



The backends don't add range chec= > > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > > >ngreal is target-dependent and knowledge
of it should only exist in the = > > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > > >s the same since around the early 1980s.



I believe=2C based = > > >on what you are saying=2C
the frontend should generate range checks befo= > > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > > >ded.


The frontend has some of those optimizations already -- con= > > >verting
from a smaller range to a larger range needs no check.

> >r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > > >cient?



 =3B- Jay




>=3B To: jay.= > > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > > Book is that INTEGER should be a range-limited
>=3B form of integer= > > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > > restriction=2C do not handle out-of-range situations correctly. Things > >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > > >n think that's right. Of
>=3B course it's not as bad as it might be i= > > >n C where you might be indexing an
>=3B array with the incorrectly cal= > > >culated integer and send your program off in
>=3B never-never land. I= > > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > > >>=3B Mika
> > >= > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- > > From jay.krell at cornell.edu Sun Sep 8 05:21:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 03:21:56 +0000 Subject: [M3devel] should C backend output K&R, ANSI C, or C++? Message-ID: Any preferences/rationale for C backend to output: 1) K&R C 2) ANSI C 3) C++ Even gcc now requires a C++ compiler to bootstrap. C++ hypothetically offers us a chance for efficient exception handing. HPUX/HPPA bundled C compiler is K&R only. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 05:48:00 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 03:48:00 +0000 Subject: [M3devel] python build problems Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL> Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 8 05:54:41 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 8 Sep 2013 03:54:41 +0000 Subject: [M3devel] python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 8 06:14:37 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 04:14:37 +0000 Subject: [M3devel] python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: 1. I removed the Cstdint requirement, please try again. Sorry about that. 2. The order of the build is not defined by the list you show. That is an unordered set and it is passed through code to honor the pkginfo.txt information. 2b. Though it looks like upgrade.sh doesn't apply the ordering and just strives to get it right earlier, so you could refer to that. But the Python definitely takes unordered lists and applies the ordering from pkginfo.txt. Look for "Order" in pylib.py if carouse. 3. IF you hit the _xmm error before building mklib.. the workaround will be to bootstrap w/o shared libraries. You didn't report that, and there is code to avoid shared libraries with older tools. - Jay From: jayk123 at hotmail.com To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 8 Sep 2013 03:54:41 +0000 Subject: Re: [M3devel] python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 06:23:48 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 04:23:48 +0000 Subject: [M3devel] python build problems Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL> Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 8 06:39:46 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 8 Sep 2013 04:39:46 +0000 Subject: [M3devel] python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 07:13:10 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 05:13:10 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL> Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 07:19:54 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 05:19:54 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL> Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed ________________________________ From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 8 07:58:57 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 8 Sep 2013 05:58:57 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: sorry, yes, please try again From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:19:54 +0000 Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 8 08:59:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 06:59:05 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: Randy, if you give up, try this? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130907.zip - Jay From: jayk123 at hotmail.com To: rcolebur at scires.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:58:57 +0000 sorry, yes, please try again From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:19:54 +0000 Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 8 09:48:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 07:48:57 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , , , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>, , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>, , , Message-ID: here, more complete: https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-d5.9.0-VC110-20130908.msi https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-d5.9.0-VC110-20130908-symbols.zip https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-d5.9.0-VC110-20130908.zip https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130908.msi https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130908-symbols.zip https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130908.zip - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 8 Sep 2013 06:59:05 +0000 Subject: Re: [M3devel] EXT:RE: python build problems Randy, if you give up, try this? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130907.zip - Jay From: jayk123 at hotmail.com To: rcolebur at scires.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:58:57 +0000 sorry, yes, please try again From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:19:54 +0000 Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Sep 8 10:40:42 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 8 Sep 2013 10:40:42 +0200 Subject: [M3devel] AMD64_NT In-Reply-To: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> References: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> Message-ID: At last some use for all those Win64's laying around! :) Great work!!! -- Dragi?a Duri? dragisha at m3w.org On Sep 3, 2013, at 6:06 PM, Jay wrote: > AMD_NT runs, can build itself, is more debuggable than NT386, Juno & formsedit come up. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rcolebur at SCIRES.COM Wed Sep 11 23:21:06 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 11 Sep 2013 21:21:06 +0000 Subject: [M3devel] still having trouble building on WinXP Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1C355@ATLEX04-SRV.SCIRES.LOCAL> Jay: I've updated my sandbox again to be current with the HEAD branch. My computer is running Windows XP (32 bit), my installed cm3 system is a working edition circa 2008, and I have Python v2.7.3 installed. If I try to upgrade to the latest sources in my Sandbox, I run into trouble. 1. Using the python scripts, I run into a problem right away: C:\cm3\Sandbox\cm3\scripts\python>\Python27\python.exe upgrade.py Traceback (most recent call last): File "upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' 2. If I try my script, or if I try to rebuild manually, I run into an error trying to build "m3back" due to undefined Ctypes.unsigned: new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered Can the dependency on Ctypes.unsigned be removed, or is there a way to fix the error? Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 12 02:38:55 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Sep 2013 00:38:55 +0000 Subject: [M3devel] still having trouble building on WinXP In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1C355@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1C355@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: > Can the dependency on Ctypes.unsigned be removed, or is there a way to fix the error? Is it really still broken? This is trivial. Ctypes.unsigned has been around forever. I could have sworn I commited the trivial fix. I'll look again tonight. It just needs to say: IMPORT Ctypes; TYPE whatever = Ctypes.unsigned or unsigned_int; It is all absolutely trivial. I can't well paste in the definition of Ctypes.unsigned, because it varies between 32bit and 64bit. Ctypes is a portability bridge for 32bit vs. 64bit. 32bit unsigned is Word.T. 64bit unsigned is range 0...2^32-1. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: still having trouble building on WinXP Date: Wed, 11 Sep 2013 21:21:06 +0000 Jay: I?ve updated my sandbox again to be current with the HEAD branch. My computer is running Windows XP (32 bit), my installed cm3 system is a working edition circa 2008, and I have Python v2.7.3 installed. If I try to upgrade to the latest sources in my Sandbox, I run into trouble. 1. Using the python scripts, I run into a problem right away: C:\cm3\Sandbox\cm3\scripts\python>\Python27\python.exe upgrade.py Traceback (most recent call last): File "upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' 2. If I try my script, or if I try to rebuild manually, I run into an error trying to build ?m3back? due to undefined Ctypes.unsigned: new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered Can the dependency on Ctypes.unsigned be removed, or is there a way to fix the error? Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 13 19:44:20 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 13 Sep 2013 13:44:20 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu> Message-ID: <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu> Compilation error in the build last night. Someone to fix? Begin forwarded message: > From: Tony Hosking > Subject: Output from "cron" command > Date: September 13, 2013 7:45:25 AM EDT > To: hosking at cs.purdue.edu > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > GMAKE=gmake > export GMAKE > TAR=gtar > export TAR > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-10-30-05 > LASTREL=5.8.6 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com... > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20130913-063007-WkaiLK/log.txt > > --- > > checkout, compile and test of cm3 ... > 2013.09.13 06:30:07 -- checkout in progress. > [start checkout 2013.09.13 06:30:10] > cd /tmp/build-cm3-20130913-063007-WkaiLK/build > cvs return value: 0 > [end checkout 2013.09.13 06:57:52] > CHECKOUT_RETURN = 0 > -- > 2013.09.13 06:57:56 -- compile in progress. > [start compile 2013.09.13 06:57:56] > compile return value: 1 > [end compile 2013.09.13 07:06:12] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20130913-063007-WkaiLK ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > cleanup_all_but_last_n > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-00-09-00 > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > cleanup_all_but_last_n > cleanup_all_but_last_n > > done with cleanup_all > GMAKE=gmake > export GMAKE > TAR=gtar > export TAR > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-11-08-49 > LASTREL=5.8.6 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com... > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20130913-070852-tWayTR/log.txt > > --- > > checkout, compile and test of cm3 ... > 2013.09.13 07:08:52 -- checkout in progress. > [start checkout 2013.09.13 07:08:54] > cd /tmp/build-cm3-20130913-070852-tWayTR/build > cvs return value: 0 > [end checkout 2013.09.13 07:24:59] > CHECKOUT_RETURN = 0 > -- > 2013.09.13 07:25:05 -- compile in progress. > [start compile 2013.09.13 07:25:05] > compile return value: 1 > [end compile 2013.09.13 07:42:50] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20130913-070852-tWayTR ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > cleanup_all_but_last_n > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-10-30-03 > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > cleanup_all_but_last_n > cleanup_all_but_last_n > > done with cleanup_all > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 13 21:14:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 13 Sep 2013 19:14:00 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu> References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu>, <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu> Message-ID: Logs not very informative. Just started last night? Was succeeding the day before? From: hosking at cs.purdue.edu Date: Fri, 13 Sep 2013 13:44:20 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Fwd: Output from "cron" command Compilation error in the build last night.Someone to fix? Begin forwarded message:From: Tony Hosking Subject: Output from "cron" command Date: September 13, 2013 7:45:25 AM EDT To: hosking at cs.purdue.edu Your "cron" job on niagara.cs.purdue.edu $HOME/cm3/scripts/regression/cron.sh produced the following output: GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-10-30-05 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara release-build" creating log file /tmp/build-cm3-20130913-063007-WkaiLK/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 06:30:07 -- checkout in progress. [start checkout 2013.09.13 06:30:10] cd /tmp/build-cm3-20130913-063007-WkaiLK/build cvs return value: 0 [end checkout 2013.09.13 06:57:52] CHECKOUT_RETURN = 0 -- 2013.09.13 06:57:56 -- compile in progress. [start compile 2013.09.13 06:57:56] compile return value: 1 [end compile 2013.09.13 07:06:12] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-063007-WkaiLK ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-00-09-00 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-11-08-49 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" creating log file /tmp/build-cm3-20130913-070852-tWayTR/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 07:08:52 -- checkout in progress. [start checkout 2013.09.13 07:08:54] cd /tmp/build-cm3-20130913-070852-tWayTR/build cvs return value: 0 [end checkout 2013.09.13 07:24:59] CHECKOUT_RETURN = 0 -- 2013.09.13 07:25:05 -- compile in progress. [start compile 2013.09.13 07:25:05] compile return value: 1 [end compile 2013.09.13 07:42:50] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-070852-tWayTR ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-10-30-03 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 16 07:26:13 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Sep 2013 05:26:13 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu>, , <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu>, Message-ID: Still a problem? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 13 Sep 2013 19:14:00 +0000 Subject: Re: [M3devel] Fwd: Output from "cron" command Logs not very informative. Just started last night? Was succeeding the day before? From: hosking at cs.purdue.edu Date: Fri, 13 Sep 2013 13:44:20 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Fwd: Output from "cron" command Compilation error in the build last night.Someone to fix? Begin forwarded message:From: Tony Hosking Subject: Output from "cron" command Date: September 13, 2013 7:45:25 AM EDT To: hosking at cs.purdue.edu Your "cron" job on niagara.cs.purdue.edu $HOME/cm3/scripts/regression/cron.sh produced the following output: GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-10-30-05 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara release-build" creating log file /tmp/build-cm3-20130913-063007-WkaiLK/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 06:30:07 -- checkout in progress. [start checkout 2013.09.13 06:30:10] cd /tmp/build-cm3-20130913-063007-WkaiLK/build cvs return value: 0 [end checkout 2013.09.13 06:57:52] CHECKOUT_RETURN = 0 -- 2013.09.13 06:57:56 -- compile in progress. [start compile 2013.09.13 06:57:56] compile return value: 1 [end compile 2013.09.13 07:06:12] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-063007-WkaiLK ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-00-09-00 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-11-08-49 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" creating log file /tmp/build-cm3-20130913-070852-tWayTR/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 07:08:52 -- checkout in progress. [start checkout 2013.09.13 07:08:54] cd /tmp/build-cm3-20130913-070852-tWayTR/build cvs return value: 0 [end checkout 2013.09.13 07:24:59] CHECKOUT_RETURN = 0 -- 2013.09.13 07:25:05 -- compile in progress. [start compile 2013.09.13 07:25:05] compile return value: 1 [end compile 2013.09.13 07:42:50] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-070852-tWayTR ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-10-30-03 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 17 18:44:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Sep 2013 16:44:17 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130917151045.6D7195DEB73@birch.elegosoft.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com> Message-ID: The OpenCSW machines can run SPARC64. There are full installs available here: http://modula3.elegosoft.com/cm3/uploaded-archives/ G5 Mac for Darwin/Linux?BSD should also be easy. Maybe I'll set mine up.. - Jay > Date: Tue, 17 Sep 2013 17:10:45 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/09/17 17:10:45 > > Modified files: > cm3/m3-comm/netobj/src/netobjrt/: Tag: devel_unicode StubLib.m3 > > Log message: > Add support for communication involving 64-bit big-endian machines. > Apparently, none existed when this was written. Apparently, nobody > has tried to do this. > > New support not tested for lack of access to such a machine, but > retested with no breakage on 64-LE. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcode at zoho.com Tue Sep 17 20:00:01 2013 From: microcode at zoho.com (microcode at zoho.com) Date: Tue, 17 Sep 2013 18:00:01 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: References: <20130917151045.6D7195DEB73@birch.elegosoft.com> Message-ID: <20130917180001.GA10942@zoho.com> Hi, Looking at the uploaded archives page, can anybody please explain the difference between all these versions and exactly what each one is? 1. Target Platform AMD64_SOLARIS 2. Target Platform I386_SOLARIS 3. Target Platform SOLgnu 4. Target Platform SOLsun 5. Target Platform SPARC32_SOLARIS 6. Target Platform SPARC64_SOLARIS 1 and 2 would seem obvious enough except that the existence of 3 and 4 suggests 1 and 2 may have been built with gcc or Solaris Studio. That means 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 are designed to run on. 5 and 6 would seem obvious except now we're back to wondering whether they were built with gcc or Solaris Studio. I didn't understand Jay's comment below. Do you guys not have Solaris SPARC boxes in your build farm? Thank you. Israel On Tue, Sep 17, 2013 at 04:44:17PM +0000, Jay K wrote: > The OpenCSW machines can run SPARC64. > There are full installs available here: > http://modula3.elegosoft.com/cm3/uploaded-archives/ > > > G5 Mac for Darwin/Linux?BSD should also be easy. Maybe I'll set mine up.. > > > - Jay > > > > Date: Tue, 17 Sep 2013 17:10:45 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/09/17 17:10:45 > > > > Modified files: > > cm3/m3-comm/netobj/src/netobjrt/: Tag: devel_unicode StubLib.m3 > > > > Log message: > > Add support for communication involving 64-bit big-endian machines. > > Apparently, none existed when this was written. Apparently, nobody > > has tried to do this. > > > > New support not tested for lack of access to such a machine, but > > retested with no breakage on 64-LE. > > > -- _ _ ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___ | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._> |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___. From jay.krell at cornell.edu Tue Sep 17 20:24:58 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Sep 2013 18:24:58 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130917180001.GA10942@zoho.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com>, , <20130917180001.GA10942@zoho.com> Message-ID: Historically: SOLgnu was 32bit SPARC on Solaris using gcc; Which linker? I don't know. SOLsun was 32bit SPARC on Solaris using Sun cc But these are essentially identical -- same jmpbuf size, same stack walker (there was one, it is disabled now), same switches to the gcc backend. Just a different command for compiling the little bit of C we have and for linking. The target naming used to be more ad-hoc. The config files can be fairly user edited to switch between cc and gcc. Any of the four AMD64/I386/SPARC32/SPARC64_SOLARIS can be built with cc or gcc. I favor cc. It likely gives us better code, and gives us a little variety-for-demonstrated-portability. There was a period where Sun cc wasn't cost free which is probably why there was some desire for gcc -- plus, if the user has gcc-specific code, they'd want gcc. There isn't a builtin easy way to switch between cc and gcc on a source file by source file basis. "platforms" are kind of overblown in Modula-3 -- far more is the same than is different. Heck, even in gcc, for a given architecture, most targets use the same ABI -- so linux/freebsd/netbsd/openbsd are basically all the same, esp. to the backend (vs. the driver that does pre-#defines..) With the C backend, they are even more the same. - Jay > Date: Tue, 17 Sep 2013 18:00:01 +0000 > From: microcode at zoho.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit big-endian > > Hi, > > Looking at the uploaded archives page, can anybody please explain the > difference between all these versions and exactly what each one is? > > 1. Target Platform AMD64_SOLARIS > 2. Target Platform I386_SOLARIS > 3. Target Platform SOLgnu > 4. Target Platform SOLsun > 5. Target Platform SPARC32_SOLARIS > 6. Target Platform SPARC64_SOLARIS > > 1 and 2 would seem obvious enough except that the existence of 3 and 4 > suggests 1 and 2 may have been built with gcc or Solaris Studio. That means > 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is > 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and > 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 > are designed to run on. 5 and 6 would seem obvious except now we're back to > wondering whether they were built with gcc or Solaris Studio. > > I didn't understand Jay's comment below. Do you guys not have Solaris SPARC > boxes in your build farm? > > Thank you. > > Israel > > On Tue, Sep 17, 2013 at 04:44:17PM +0000, Jay K wrote: > > The OpenCSW machines can run SPARC64. > > There are full installs available here: > > http://modula3.elegosoft.com/cm3/uploaded-archives/ > > > > > > G5 Mac for Darwin/Linux?BSD should also be easy. Maybe I'll set mine up.. > > > > > > - Jay > > > > > > > Date: Tue, 17 Sep 2013 17:10:45 +0000 > > > To: m3commit at elegosoft.com > > > From: rodney at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/09/17 17:10:45 > > > > > > Modified files: > > > cm3/m3-comm/netobj/src/netobjrt/: Tag: devel_unicode StubLib.m3 > > > > > > Log message: > > > Add support for communication involving 64-bit big-endian machines. > > > Apparently, none existed when this was written. Apparently, nobody > > > has tried to do this. > > > > > > New support not tested for lack of access to such a machine, but > > > retested with no breakage on 64-LE. > > > > > > > -- > _ _ > ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___ > | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._> > |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcode at zoho.com Tue Sep 17 20:33:09 2013 From: microcode at zoho.com (microcode at zoho.com) Date: Tue, 17 Sep 2013 18:33:09 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: References: <20130917151045.6D7195DEB73@birch.elegosoft.com> <20130917180001.GA10942@zoho.com> Message-ID: <20130917183309.GB10942@zoho.com> On Tue, Sep 17, 2013 at 06:24:58PM +0000, Jay K wrote: > Historically: > SOLgnu was 32bit SPARC on Solaris using gcc; Which linker? I don't know. > SOLsun was 32bit SPARC on Solaris using Sun cc Ok, that's what I suspected vis a vis gcc/cc but I didn't know what platform. Thanks. So what's the reason for SPARC32_Solaris? > The config files can be fairly user edited to switch between cc and gcc. > Any of the four AMD64/I386/SPARC32/SPARC64_SOLARIS can be built with cc or gcc. > I favor cc. It likely gives us better code, and gives us a little > variety-for-demonstrated-portability. Yes, certainly if you're building on Solaris then Solaris Studio (cc) is the obvious correct choice. So what about 5 and 6 below? Are they built with gcc or Solaris Studio? And is there an issue of not having access to SPARC build hardware? > > > > Looking at the uploaded archives page, can anybody please explain the > > difference between all these versions and exactly what each one is? > > > > 1. Target Platform AMD64_SOLARIS > > 2. Target Platform I386_SOLARIS > > 3. Target Platform SOLgnu > > 4. Target Platform SOLsun > > 5. Target Platform SPARC32_SOLARIS > > 6. Target Platform SPARC64_SOLARIS > > > > 1 and 2 would seem obvious enough except that the existence of 3 and 4 > > suggests 1 and 2 may have been built with gcc or Solaris Studio. That means > > 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is > > 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and > > 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 > > are designed to run on. 5 and 6 would seem obvious except now we're back to > > wondering whether they were built with gcc or Solaris Studio. > > > > I didn't understand Jay's comment below. Do you guys not have Solaris SPARC > > boxes in your build farm? > > > > Thank you. > > > > Israel From jay.krell at cornell.edu Tue Sep 17 23:05:39 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Sep 2013 21:05:39 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130917183309.GB10942@zoho.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com>, , <20130917180001.GA10942@zoho.com>, , <20130917183309.GB10942@zoho.com> Message-ID: SPARC32_SOLARIS is a new name for SOLsun/SOLgnu. Newer targets have followed a fairly "regular" naming scheme: PPC_DARWIN, I386_DARWIN, PPC_LINUX, AMD64_NT. Not sure if it should be PPC or PPC32, SPARC or SPARC32, I386 or X86 or IA32 or what, but ok. I introduced new names for the remaining few old style names: LINUXLIBC6 => I386_LINUX FreeBSD4 => I386_FREEBSD NT386 => I386_NT NT386GNU => I386_CYGWIN NetBSDv2 => I386_NETBSD The old names continue to be supported. We don't really need/want to encode precise versions in the names. See, it used to be there was a roughly one to one processor to OS mapping. So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86. This is no longer the case at all -- pretty much every system, except like AIX and Irix run on at least two processors. Our build infrastructure: Most likely I tested most/everything with gcc, but then settled on Sun cc. User can go and edit the config files if he prefers gcc. We have access to the opencsw machines for Solaris. I had a bunch of machines but I've downsized 1) what I own 2) what I'm running on what I have left. Olaf was the main person maintaining the infrastructure and he has little time. We are very short staffed. There is actually very little target-dependent anywhere in the Modula-3 system at this point. I removed all the rewritten Posix headers for example, replaced with a more portable layer. (i.e. no need to know exact layout and sizes of things). - Jay > Date: Tue, 17 Sep 2013 18:33:09 +0000 > From: microcode at zoho.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit big-endian > > On Tue, Sep 17, 2013 at 06:24:58PM +0000, Jay K wrote: > > Historically: > > SOLgnu was 32bit SPARC on Solaris using gcc; Which linker? I don't know. > > SOLsun was 32bit SPARC on Solaris using Sun cc > > Ok, that's what I suspected vis a vis gcc/cc but I didn't know what > platform. Thanks. So what's the reason for SPARC32_Solaris? > > > > The config files can be fairly user edited to switch between cc and gcc. > > Any of the four AMD64/I386/SPARC32/SPARC64_SOLARIS can be built with cc or gcc. > > I favor cc. It likely gives us better code, and gives us a little > > variety-for-demonstrated-portability. > > Yes, certainly if you're building on Solaris then Solaris Studio (cc) is the > obvious correct choice. > > So what about 5 and 6 below? Are they built with gcc or Solaris Studio? > > And is there an issue of not having access to SPARC build hardware? > > > > > > > Looking at the uploaded archives page, can anybody please explain the > > > difference between all these versions and exactly what each one is? > > > > > > 1. Target Platform AMD64_SOLARIS > > > 2. Target Platform I386_SOLARIS > > > 3. Target Platform SOLgnu > > > 4. Target Platform SOLsun > > > 5. Target Platform SPARC32_SOLARIS > > > 6. Target Platform SPARC64_SOLARIS > > > > > > 1 and 2 would seem obvious enough except that the existence of 3 and 4 > > > suggests 1 and 2 may have been built with gcc or Solaris Studio. That means > > > 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is > > > 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and > > > 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 > > > are designed to run on. 5 and 6 would seem obvious except now we're back to > > > wondering whether they were built with gcc or Solaris Studio. > > > > > > I didn't understand Jay's comment below. Do you guys not have Solaris SPARC > > > boxes in your build farm? > > > > > > Thank you. > > > > > > Israel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcode at zoho.com Wed Sep 18 10:15:02 2013 From: microcode at zoho.com (microcode at zoho.com) Date: Wed, 18 Sep 2013 08:15:02 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: References: <20130917151045.6D7195DEB73@birch.elegosoft.com> <20130917180001.GA10942@zoho.com> <20130917183309.GB10942@zoho.com> Message-ID: <20130918081502.GA12109@zoho.com> On Tue, Sep 17, 2013 at 09:05:39PM +0000, Jay K wrote: > SPARC32_SOLARIS is a new name for SOLsun/SOLgnu. But which? Sun cc or gcc? And then it would seem from your comment there is at least one duplicate download. This is confusing. > Not sure if it should be PPC or PPC32, SPARC or SPARC32, > I386 or X86 or IA32 or what, but ok. With i386, x86, and IA32 everybody understands we're talking about a 32 bit version for Intel. It's just different names for the same thing and nobody expects a compiler other than gcc to have been used to build it. With Solaris SPARC there are a few different things that are important. One is you have a choice of Solaris Studio (cc) or gcc as we said. Then there is 32 v. 64 bit. Counterintuitively 32 bit is better in most situations. Then there is the option of V9 instruction extensions over V8 but still running 32 bit. This is normally the best performance option on 64 bit SPARC boxes. If you want to support V8 boxes then this is another variation, or maybe you build nominal 32 bit V8 and 64 bit V9 versions. That's suboptimal but then one or the other or both will work on most SPARC boxes still running. > The old names continue to be supported. > We don't really need/want to encode precise versions in the names. Understood and I am not questioning the naming conventions except for Solaris where there are really quite a few variations and options that have a big effect on performance and are meaningful when somebody is trying to pick the right one. > See, it used to be there was a roughly one to one processor to OS mapping. > So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86. Yeah, I know. Life was simpler in the old days ;-) > We have access to the opencsw machines for Solaris. That's good news. Thanks for the info. I'm glad to see how much opencsw does for the Solaris community. I keep finding things they help with. > There is actually very little target-dependent anywhere in the Modula-3 system at this point. > I removed all the rewritten Posix headers for example, replaced with a more portable layer. > (i.e. no need to know exact layout and sizes of things). Good news! I guess that means you are using libc instead of syscalls because I know Solaris syscalls are different from linux, etc. I don't know how closely Solaris libc is aligned to Linux or BSD libc... Thanks, Israel From jay.krell at cornell.edu Wed Sep 18 19:03:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Sep 2013 17:03:17 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130918081502.GA12109@zoho.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com>, , <20130917180001.GA10942@zoho.com>, , <20130917183309.GB10942@zoho.com>, , <20130918081502.GA12109@zoho.com> Message-ID: So..historically, with the gcc-backend, we don't have much C code. Just thin wrappers, like: int int Unix__open(const char* a, int b) { return open(a, b); } copying in the case of stat. Errno constants are "instantiated" instead of "inline" extern const Errno_EBADIF = EBADIF; and we use if/else/else instead of switch on them. So that we don't have to duplicate their values for every target, like we used to (porting headache). So I don't think the choice of C compiler made that big a difference. Now we do have a C backend, that nobody is using. So the C compiler becomes more interesting. Also, for a long time, our gcc-backend made every load and store volatile. Hypothetically this tanked performance, but in reality probably only Tony knew, and nobody noticed, then later I noticed. And I fixed it. I compiled with -O2 and -O3, which is noticably slower than not optimizing, and where there were problems, I either fixed them, or disabled a small number of specific optimizations. I believe I found at least one gcc bug therein -- around use of division/mod operator that we use but isn't exposed to C/C++ (maybe Ada??) At least one optimization pass was acknowledged buggy by the gcc maintainers and they removed it themselves (the one that tries to convert structs to scalars, I think.) Our NT386 backend always optimizes some, but never inlines anything. (It is better than the volatized gcc backend.) We are optionally safe, yet compile directly to native. So we should be competitive. We are probably faster in general than any interprter -- Ruby and Python and Perl. Now, things that JIT -- JScript, Java, C# -- they have a good chance of being close behind or ahead in performance. Languages with no safety -- C and C++ -- they are likely faster in general. And again, I do favor Sun cc. Both because it might be faster and it gives me a chance to make our C code portable by testing it on additional C compilers. Our C code has also fairly recently been through the Tru64 compiler. Some of it goes through Visual C++. And maybe some others. I tested the C backend with Sun cc I think. And now Microsoft Visual C++. I should get over to clang... As to which build I produced how, the definitive information is probably the config files in the releases. As to the redundancy, well, people don't want to give up the old names, and I want to provide the new names, so there ends up both. For SPARC instruction set we did bump up to something not ancient. It was needed for atomics, at least, I think. You can see in the config file. https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common?rev=1.7;content-type=text%2Fplain SunXArch = "v8plus" It is difficult to find a balance among: performance convenience prebuilt binaries that works for most everyone right out of the box or easy to build source that works for most everyone portability test matrix (cost) short command lines (convenience) debuggability time but I tried. - Jay > Date: Wed, 18 Sep 2013 08:15:02 +0000 > From: microcode at zoho.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit big-endian > > On Tue, Sep 17, 2013 at 09:05:39PM +0000, Jay K wrote: > > SPARC32_SOLARIS is a new name for SOLsun/SOLgnu. > > But which? Sun cc or gcc? And then it would seem from your comment there is > at least one duplicate download. This is confusing. > > > Not sure if it should be PPC or PPC32, SPARC or SPARC32, > > I386 or X86 or IA32 or what, but ok. > > With i386, x86, and IA32 everybody understands we're talking about a 32 bit > version for Intel. It's just different names for the same thing and nobody > expects a compiler other than gcc to have been used to build it. > > With Solaris SPARC there are a few different things that are important. One > is you have a choice of Solaris Studio (cc) or gcc as we said. Then there is > 32 v. 64 bit. Counterintuitively 32 bit is better in most situations. > Then there is the option of V9 instruction extensions over V8 but still > running 32 bit. This is normally the best performance option on 64 bit SPARC > boxes. If you want to support V8 boxes then this is another variation, or > maybe you build nominal 32 bit V8 and 64 bit V9 versions. That's suboptimal > but then one or the other or both will work on most SPARC boxes still running. > > > The old names continue to be supported. > > We don't really need/want to encode precise versions in the names. > > Understood and I am not questioning the naming conventions except for > Solaris where there are really quite a few variations and options that have > a big effect on performance and are meaningful when somebody is trying to > pick the right one. > > > See, it used to be there was a roughly one to one processor to OS mapping. > > So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86. > > Yeah, I know. Life was simpler in the old days ;-) > > > We have access to the opencsw machines for Solaris. > > That's good news. Thanks for the info. I'm glad to see how much opencsw does > for the Solaris community. I keep finding things they help with. > > > There is actually very little target-dependent anywhere in the Modula-3 system at this point. > > I removed all the rewritten Posix headers for example, replaced with a more portable layer. > > (i.e. no need to know exact layout and sizes of things). > > Good news! I guess that means you are using libc instead of syscalls because > I know Solaris syscalls are different from linux, etc. I don't know how > closely Solaris libc is aligned to Linux or BSD libc... > > Thanks, > > Israel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 19 19:47:09 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Sep 2013 13:47:09 -0400 Subject: [M3devel] Build failure in regressions Message-ID: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu> I get this error: === package m3-sys/mklib === 38479 +++ cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? +++ 38480 --- building in SOLgnu --- 38481 38482 ignoring ../src/m3overrides 38483 38484 new source -> compiling Main.m3 38485 "../src/Main.m3", line 87: unknown qualification ?.? (IMAGE_FILE_MACHINE_AMD64) 38486 NEXT 1 error encountered 38487 38488 NEXT Fatal Error: failed compiling: 38489 38490 NEXT *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? failed *** 38491 compile return value: 1 38492 [end compile 2013.09.19 07:31:22] 38493 *** COMPILE FAILED Does anyone know what this is about? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 19 19:49:57 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Sep 2013 13:49:57 -0400 Subject: [M3devel] Tinderbox build failure Message-ID: Here is the full log: Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 19 19:52:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Sep 2013 17:52:12 +0000 Subject: [M3devel] Build failure in regressions In-Reply-To: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu> References: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu> Message-ID: ah, mklib dependency on updated m3core, understood, I'll fix it later - Jay From: hosking at cs.purdue.edu Date: Thu, 19 Sep 2013 13:47:09 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Build failure in regressions I get this error: === package m3-sys/mklib === 38479 +++ cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? +++ 38480 --- building in SOLgnu --- 38481 38482 ignoring ../src/m3overrides 38483 38484 new source -> compiling Main.m3 38485 "../src/Main.m3", line 87: unknown qualification ?.? (IMAGE_FILE_MACHINE_AMD64) 38486 NEXT 1 error encountered 38487 38488 NEXT Fatal Error: failed compiling: 38489 38490 NEXT *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? failed *** 38491 compile return value: 1 38492 [end compile 2013.09.19 07:31:22] 38493 *** COMPILE FAILED Does anyone know what this is about? Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 21 07:31:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Sep 2013 05:31:10 +0000 Subject: [M3devel] Build failure in regressions In-Reply-To: References: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu>, Message-ID: This should be fixed now. There is still a dependency on m3core being somewhat up to date. If the dependency is still too much, I can recopy the stuff back to mklib like it was there. Or we can skip mklib when not targeting/booting for NT. It is only used for NT targets. I would like to get rid of it, and use native link /lib instead, but mklib also writes the .def files. That should be moved to m3front/m3middle/m3back I think. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 19 Sep 2013 17:52:12 +0000 Subject: Re: [M3devel] Build failure in regressions ah, mklib dependency on updated m3core, understood, I'll fix it later - Jay From: hosking at cs.purdue.edu Date: Thu, 19 Sep 2013 13:47:09 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Build failure in regressions I get this error: === package m3-sys/mklib === 38479 +++ cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? +++ 38480 --- building in SOLgnu --- 38481 38482 ignoring ../src/m3overrides 38483 38484 new source -> compiling Main.m3 38485 "../src/Main.m3", line 87: unknown qualification ?.? (IMAGE_FILE_MACHINE_AMD64) 38486 NEXT 1 error encountered 38487 38488 NEXT Fatal Error: failed compiling: 38489 38490 NEXT *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? failed *** 38491 compile return value: 1 38492 [end compile 2013.09.19 07:31:22] 38493 *** COMPILE FAILED Does anyone know what this is about? Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 04:15:45 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 02:15:45 +0000 Subject: [M3devel] proposal to batch C compilation, and change extensions Message-ID: With Microsoft Visual C++, it is very much faster to say: cl -c 1.c 2.c 3.c 4.c than cl -c 1.c cl -c 2.c cl -c 3.c cl -c 4.c I'm assuming the same pattern works with other compilers, and is generally never slower. This requires the output names followed an assumed pattern -- replace ".c" with ".o" or ".obj". When compiling a single file you can specify an arbitrary output name. When compiling multiple files, you can only specify an output directory. It also requires the same command line switches for compiling each file, i.e. -I, -D, etc. Traditionally this didn't matter much because we have relatively little C. I would like to "fix" this. I would like to change the build to record what all C files need compiling, then compile them all "at once". And for foo.m3 => foo.m3.c => foo.m3.obj or foo.m3.o instead of the current foo.m3 => foo.m3.c -> foo.mo And, might as well do similar for the gcc backend? foo.m3 => foo.mc => foo.m3.o instead of foo.m3 => foo.mc => foo.mo Or, for some purported MS-DOS compatibility (only one dot): foo.m3 => foo_m3.c => foo_m3.obj or foo_m3.o foo.m3 => foo.mc => foo_m3.obj or foo_m3.o Ok? I think nix the MS-DOS part. (Is anyone interested in a DJGPP version?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 05:58:34 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 03:58:34 +0000 Subject: [M3devel] what does it mean to read a UINT8? Message-ID: It appears that this code: b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; generates a read of a full INTEGER, in this case 8 bytes. Now, I know, I could change it to: b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; What were my expectations wrong in the first place? This code was part of getting stack bounds and it'd read the end of the stack to try to ensure it was correct. I removed it. 0:000> g (15bc.116c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for cm3.exe cm3!ThreadWin32__GetStackBounds+0x1e8: 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 ffff=???????????????? 0:000> r rax rax=0000000000290000 0:000> r rsp rsp=000000000028fb60 0:000> dv start_L_275 = 0x00000000`00338de0 end_L_276 = 0x00000000`00338de8 L_501_L_502 = 0n48 used_L_272 = 0x00000000`0028f000 available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 00`00190000 ---" b_L_274 = 0x30 '0' a_L_271 = 0n48 info_L_270 = struct TA669C7A1 _frame = struct ThreadWin32__GetStackBounds_Frame_t 0:000> ?? info_L_270 struct TA669C7A1 +0x000 BaseAddress : 0x00000000`0028f000 "0???" +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr ess 0x00000000`00190000 ---" +0x010 AllocationProtect : 4 +0x014 L_7 : [4] "" +0x018 RegionSize : 0n4096 +0x020 State : 0x1000 +0x024 Protect : 4 +0x028 Type : 0x20000 +0x02c L_8 : [4] "" 0:000> q quit: - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 06:41:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 04:41:14 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20130922043502.1D6F15DEB78@birch.elegosoft.com> References: <20130922043502.1D6F15DEB78@birch.elegosoft.com> Message-ID: Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 22 06:49:29 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 22 Sep 2013 04:49:29 +0000 Subject: [M3devel] problem building mklib on WinXP Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CBD9@ATLEX04-SRV.SCIRES.LOCAL> Jay: I'm getting a compilation error building mklib.exe. See below. --- processing package "m3-sys\mklib" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3 "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) 1 error encountered compilation failed => not building program "mklib.exe" Fatal Error: package build failed WARNING: Encountered an error when processing package "m3-sys\mklib" for "-build". Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 22 06:51:09 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 22 Sep 2013 04:51:09 +0000 Subject: [M3devel] problem building mklib on WinXP In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CBD9@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CBD9@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Right. Tony reported this. Again it is due to m3core being old, but in this case not so old. I updated mklib to contain the definition itself instead of using m3core. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: problem building mklib on WinXP Date: Sun, 22 Sep 2013 04:49:29 +0000 Jay: I'm getting a compilation error building mklib.exe. See below. --- processing package "m3-sys\mklib" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3 "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) 1 error encountered compilation failed => not building program "mklib.exe" Fatal Error: package build failed WARNING: Encountered an error when processing package "m3-sys\mklib" for "-build". Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 22 06:57:01 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL> Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 07:03:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 06:57:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 04:57:12 +0000 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: Message-ID: Hm, bug in the C backend maybe? I'll have to compare against m3cg. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 22 Sep 2013 03:58:34 +0000 Subject: [M3devel] what does it mean to read a UINT8? It appears that this code: b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; generates a read of a full INTEGER, in this case 8 bytes. Now, I know, I could change it to: b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; What were my expectations wrong in the first place? This code was part of getting stack bounds and it'd read the end of the stack to try to ensure it was correct. I removed it. 0:000> g (15bc.116c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for cm3.exe cm3!ThreadWin32__GetStackBounds+0x1e8: 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 ffff=???????????????? 0:000> r rax rax=0000000000290000 0:000> r rsp rsp=000000000028fb60 0:000> dv start_L_275 = 0x00000000`00338de0 end_L_276 = 0x00000000`00338de8 L_501_L_502 = 0n48 used_L_272 = 0x00000000`0028f000 available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 00`00190000 ---" b_L_274 = 0x30 '0' a_L_271 = 0n48 info_L_270 = struct TA669C7A1 _frame = struct ThreadWin32__GetStackBounds_Frame_t 0:000> ?? info_L_270 struct TA669C7A1 +0x000 BaseAddress : 0x00000000`0028f000 "0???" +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr ess 0x00000000`00190000 ---" +0x010 AllocationProtect : 4 +0x014 L_7 : [4] "" +0x018 RegionSize : 0n4096 +0x020 State : 0x1000 +0x024 Protect : 4 +0x028 Type : 0x20000 +0x02c L_8 : [4] "" 0:000> q quit: - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 07:14:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 05:14:15 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 22 07:35:15 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>, , Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL> Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 07:43:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 05:43:15 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>, , , , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 11:10:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 09:10:02 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj Message-ID: darn, AMD4_NT isn't working any longer. It gets here: 0:000> k Child-SP RetAddr Call Site 00000000`002bee90 00000001`3fac0f1f cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221] 00000000`002bef10 00000001`3fa3fe96 cm3!RTHooks__AllocateTracedObj+0x2f [c:\dev2\src\runtime\common\rtallocator.m3 @ 123] 00000000`002bef60 00000001`3fa3f774 cm3!Pathname__Decompose+0x86 [c:\dev2\src\os\win32\pathnamewin32.m3 @ 40] 00000000`002beff0 00000001`3fa3f55f cm3!PathRepr__Root+0xb4 [c:\dev2\src\pathreprcommon.m3 @ 38] 00000000`002bf1c0 00000001`3fae37fc cm3!PathReprCommon_M3+0xcf [c:\dev2\src\pathreprcommon.m3 @ 46] 00000000`002bf380 00000001`3fae3653 cm3!RTLinker__RunMainBody+0x46c [c:\dev2\src\runtime\common\rtlinker.m3 @ 409] 0:000> dv /V 00000000`002bef10 @rsp+0x0080 def_L_96 = 0x00000000`00000000 ... 0:000> u . -10 cm3!RTAllocator__GetTracedObj+0x81 [c:\dev2\src\runtime\common\rtallocator.m3 @217]: ... 00000001`3fac23b9 488b842480000000 mov rax,qword ptr [rsp+80h] 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> u . l1 cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221]: 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> r rax rax=0000000000000000 def is NULL. It comes from here: Pathname__Decompose: ... RTHooks__AllocateTracedObj( (((ADDRESS)(*((ADDRESS*)(INT64_(192)+((ADDRESS)(&M_PathnameWin32_L_33)))))))); M_PathnameWin32_L_33 + 192 is NULL. "_L_33" is an annoying uniquifier from the C backend, sprinkled on far more than needed. global data allocation for M_PathnameWin32 ... 192 16 8 typecell ptr Is that supposed to be statically initialized or filled in by RTLinker? It noticably is not in the constants, but the writables. Help? Debug RTLinker? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 11:53:54 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 09:53:54 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj In-Reply-To: References: Message-ID: hm. indeed. darwin @M3tracelinker shows a few PathnamePosix but nt never shows PathnameWin32. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 22 Sep 2013 09:10:02 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj darn, AMD4_NT isn't working any longer. It gets here: 0:000> k Child-SP RetAddr Call Site 00000000`002bee90 00000001`3fac0f1f cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221] 00000000`002bef10 00000001`3fa3fe96 cm3!RTHooks__AllocateTracedObj+0x2f [c:\dev2\src\runtime\common\rtallocator.m3 @ 123] 00000000`002bef60 00000001`3fa3f774 cm3!Pathname__Decompose+0x86 [c:\dev2\src\os\win32\pathnamewin32.m3 @ 40] 00000000`002beff0 00000001`3fa3f55f cm3!PathRepr__Root+0xb4 [c:\dev2\src\pathreprcommon.m3 @ 38] 00000000`002bf1c0 00000001`3fae37fc cm3!PathReprCommon_M3+0xcf [c:\dev2\src\pathreprcommon.m3 @ 46] 00000000`002bf380 00000001`3fae3653 cm3!RTLinker__RunMainBody+0x46c [c:\dev2\src\runtime\common\rtlinker.m3 @ 409] 0:000> dv /V 00000000`002bef10 @rsp+0x0080 def_L_96 = 0x00000000`00000000 ... 0:000> u . -10 cm3!RTAllocator__GetTracedObj+0x81 [c:\dev2\src\runtime\common\rtallocator.m3 @217]: ... 00000001`3fac23b9 488b842480000000 mov rax,qword ptr [rsp+80h] 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> u . l1 cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221]: 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> r rax rax=0000000000000000 def is NULL. It comes from here: Pathname__Decompose: ... RTHooks__AllocateTracedObj( (((ADDRESS)(*((ADDRESS*)(INT64_(192)+((ADDRESS)(&M_PathnameWin32_L_33)))))))); M_PathnameWin32_L_33 + 192 is NULL. "_L_33" is an annoying uniquifier from the C backend, sprinkled on far more than needed. global data allocation for M_PathnameWin32 ... 192 16 8 typecell ptr Is that supposed to be statically initialized or filled in by RTLinker? It noticably is not in the constants, but the writables. Help? Debug RTLinker? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Sep 22 19:04:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Sep 2013 12:04:30 -0500 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: Message-ID: <523F231E.60107@lcwb.coop> This touches on a mess I have been bothered by for a long time and was getting ready to write about anyway, after spending some time inside pickles and network objects. As I have noted several times on this list, BITS n FOR T, according to the language, has an effect *only when used for an array element or record or object field*. If used for a scalar, the BITS n FOR has no effect. So a compiler is free to put scalars of packed type in anything with at least n bits, including, most plausibly, a whole native word. This could well be an advantage on many targets. But we have bit-twiddling code all over that makes assumptions about what the compiler will do that are neither specified by the language nor documented by our compiler. Presumably, most have at least been experimentally verified for selected cases. But even for a single and unchanging compiler, that is not reliable. People have, sometimes, wrapped a packed field inside a record to get around this, then used an ADR on the field. But we have no rules about how the alignment of a packed field nor of a whole record containing packed fields, so for VAR V: RECORD f: BITS 16 FOR [0..16_FFFF] END ADR(V.f) need not be 16-aligned. For bit counts other than 8, 16, 32, and 64, it hardly makes sense for a field to have alignment other than 8, and for general cases, ADR doesn't have any obvious or predictable definition. The best I can think of would be a static error if the compiler couldn't guarantee it would be at least a multiple of 8. Or, for example, if UINT8 is BITS 8 FOR [0..16_FF], do we know that BITSIZE(LOOPHOLE(x,UNTRACED REF UINT8)^)= 8? What if x is ADR(AScalarVariable), and the scalar has been allocated 64 bits? Or, x could be ADR(V.f)? The meaning of UNTRACED REF UINT16 can't depend on this. Is there some kind of consistency here? Is it endian-dependent? What about the alignment, assumed and/or ensured of these addresses? We have lots of code that just assumes something the writer thought reasonable, but it is far from consistently clear what the reasonable interpretation would be. It would be tricky to get right in general, but we could use some rules, either in the language itself or compiler supplementary documentation, spelling this stuff out. On 09/21/2013 10:58 PM, Jay K wrote: > It appears that this code: > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > generates a read of a full INTEGER, in this case 8 bytes. > > > Now, I know, I could change it to: > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > What were my expectations wrong in the first place? > > > This code was part of getting stack bounds and it'd read > the end of the stack to try to ensure it was correct. > > > I removed it. > > > 0:000> g > (15bc.116c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > *** WARNING: Unable to verify checksum for cm3.exe > cm3!ThreadWin32__GetStackBounds+0x1e8: > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > ffff=???????????????? > 0:000> r rax > rax=0000000000290000 > 0:000> r rsp > rsp=000000000028fb60 > 0:000> dv > start_L_275 = 0x00000000`00338de0 > end_L_276 = 0x00000000`00338de8 > L_501_L_502 = 0n48 > used_L_272 = 0x00000000`0028f000 > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > 00`00190000 ---" > b_L_274 = 0x30 '0' > a_L_271 = 0n48 > info_L_270 = struct TA669C7A1 > _frame = struct ThreadWin32__GetStackBounds_Frame_t > 0:000> ?? info_L_270 > struct TA669C7A1 > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > ess 0x00000000`00190000 ---" > +0x010 AllocationProtect : 4 > +0x014 L_7 : [4] "" > +0x018 RegionSize : 0n4096 > +0x020 State : 0x1000 > +0x024 Protect : 4 > +0x028 Type : 0x20000 > +0x02c L_8 : [4] "" > 0:000> q > quit: > > > - Jay From rodney_bates at lcwb.coop Sun Sep 22 19:17:18 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Sep 2013 12:17:18 -0500 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: Message-ID: <523F261E.609@lcwb.coop> As in my other response, I think you are left entirely too much out in the wind by the language/compiler as to what your expectations should be. In this particular example, it would help to know the type UINT8, and those of 'used', 'info', 'RegionSize', and maybe 'b'. I could make some guesses, but that could turn out a snipe hunt. Do you mean it copies a full INTEGER into b, or just fetches an INTEGER, then extracts from it? What is the alignment of the actual address in the failing case? On 09/21/2013 10:58 PM, Jay K wrote: > It appears that this code: > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > generates a read of a full INTEGER, in this case 8 bytes. > > > Now, I know, I could change it to: > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > What were my expectations wrong in the first place? > > > This code was part of getting stack bounds and it'd read > the end of the stack to try to ensure it was correct. > > > I removed it. > > > 0:000> g > (15bc.116c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > *** WARNING: Unable to verify checksum for cm3.exe > cm3!ThreadWin32__GetStackBounds+0x1e8: > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > ffff=???????????????? > 0:000> r rax > rax=0000000000290000 > 0:000> r rsp > rsp=000000000028fb60 > 0:000> dv > start_L_275 = 0x00000000`00338de0 > end_L_276 = 0x00000000`00338de8 > L_501_L_502 = 0n48 > used_L_272 = 0x00000000`0028f000 > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > 00`00190000 ---" > b_L_274 = 0x30 '0' > a_L_271 = 0n48 > info_L_270 = struct TA669C7A1 > _frame = struct ThreadWin32__GetStackBounds_Frame_t > 0:000> ?? info_L_270 > struct TA669C7A1 > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > ess 0x00000000`00190000 ---" > +0x010 AllocationProtect : 4 > +0x014 L_7 : [4] "" > +0x018 RegionSize : 0n4096 > +0x020 State : 0x1000 > +0x024 Protect : 4 > +0x028 Type : 0x20000 > +0x02c L_8 : [4] "" > 0:000> q > quit: > > > - Jay From jay.krell at cornell.edu Sun Sep 22 19:47:07 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 17:47:07 +0000 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: <523F261E.609@lcwb.coop> References: , <523F261E.609@lcwb.coop> Message-ID: UINT8 is [0..255] I think. I tried "BITS 8 FOR" on it at some point but such things on that family of types (UINT16, UINT32, UINT64) caused compilation errors. (These are all via Ctypes.i3) The pointer before subtraction is 64K-aligned. I don't think the other types should matter. I still have to compare with integrated backend or cm3cg. - Jay > Date: Sun, 22 Sep 2013 12:17:18 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] what does it mean to read a UINT8? > > As in my other response, I think you are left entirely too much > out in the wind by the language/compiler as to what your expectations > should be. In this particular example, it would help to know the type > UINT8, and those of 'used', 'info', 'RegionSize', and maybe 'b'. I > could make some guesses, but that could turn out a snipe hunt. > > Do you mean it copies a full INTEGER into b, or just fetches > an INTEGER, then extracts from it? What is the alignment of > the actual address in the failing case? > > On 09/21/2013 10:58 PM, Jay K wrote: > > It appears that this code: > > > > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > > > > generates a read of a full INTEGER, in this case 8 bytes. > > > > > > Now, I know, I could change it to: > > > > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > > > > What were my expectations wrong in the first place? > > > > > > This code was part of getting stack bounds and it'd read > > the end of the stack to try to ensure it was correct. > > > > > > I removed it. > > > > > > 0:000> g > > (15bc.116c): Access violation - code c0000005 (first chance) > > First chance exceptions are reported before any exception handling. > > This exception may be expected and handled. > > *** WARNING: Unable to verify checksum for cm3.exe > > cm3!ThreadWin32__GetStackBounds+0x1e8: > > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > > ffff=???????????????? > > 0:000> r rax > > rax=0000000000290000 > > 0:000> r rsp > > rsp=000000000028fb60 > > 0:000> dv > > start_L_275 = 0x00000000`00338de0 > > end_L_276 = 0x00000000`00338de8 > > L_501_L_502 = 0n48 > > used_L_272 = 0x00000000`0028f000 > > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > > 00`00190000 ---" > > b_L_274 = 0x30 '0' > > a_L_271 = 0n48 > > info_L_270 = struct TA669C7A1 > > _frame = struct ThreadWin32__GetStackBounds_Frame_t > > 0:000> ?? info_L_270 > > struct TA669C7A1 > > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > > ess 0x00000000`00190000 ---" > > +0x010 AllocationProtect : 4 > > +0x014 L_7 : [4] "" > > +0x018 RegionSize : 0n4096 > > +0x020 State : 0x1000 > > +0x024 Protect : 4 > > +0x028 Type : 0x20000 > > +0x02c L_8 : [4] "" > > 0:000> q > > quit: > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 23 09:20:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Sep 2013 07:20:25 +0000 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: , , <523F261E.609@lcwb.coop>, Message-ID: C addresses some of this very simply and thoroughly: 1) layout of bitfields is implementation independent 2) I think even the ability to declare some bitfields is not guaranteeed, e.g. int a : 33 3) You can't take the address of bitfields. This is the key one I think. 4) Bitfields can only occur in structs/unions, not in typedefs, variables, parameters, return types, etc. - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 17:47:07 +0000 Subject: Re: [M3devel] what does it mean to read a UINT8? UINT8 is [0..255] I think. I tried "BITS 8 FOR" on it at some point but such things on that family of types (UINT16, UINT32, UINT64) caused compilation errors. (These are all via Ctypes.i3) The pointer before subtraction is 64K-aligned. I don't think the other types should matter. I still have to compare with integrated backend or cm3cg. - Jay > Date: Sun, 22 Sep 2013 12:17:18 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] what does it mean to read a UINT8? > > As in my other response, I think you are left entirely too much > out in the wind by the language/compiler as to what your expectations > should be. In this particular example, it would help to know the type > UINT8, and those of 'used', 'info', 'RegionSize', and maybe 'b'. I > could make some guesses, but that could turn out a snipe hunt. > > Do you mean it copies a full INTEGER into b, or just fetches > an INTEGER, then extracts from it? What is the alignment of > the actual address in the failing case? > > On 09/21/2013 10:58 PM, Jay K wrote: > > It appears that this code: > > > > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > > > > generates a read of a full INTEGER, in this case 8 bytes. > > > > > > Now, I know, I could change it to: > > > > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > > > > What were my expectations wrong in the first place? > > > > > > This code was part of getting stack bounds and it'd read > > the end of the stack to try to ensure it was correct. > > > > > > I removed it. > > > > > > 0:000> g > > (15bc.116c): Access violation - code c0000005 (first chance) > > First chance exceptions are reported before any exception handling. > > This exception may be expected and handled. > > *** WARNING: Unable to verify checksum for cm3.exe > > cm3!ThreadWin32__GetStackBounds+0x1e8: > > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > > ffff=???????????????? > > 0:000> r rax > > rax=0000000000290000 > > 0:000> r rsp > > rsp=000000000028fb60 > > 0:000> dv > > start_L_275 = 0x00000000`00338de0 > > end_L_276 = 0x00000000`00338de8 > > L_501_L_502 = 0n48 > > used_L_272 = 0x00000000`0028f000 > > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > > 00`00190000 ---" > > b_L_274 = 0x30 '0' > > a_L_271 = 0n48 > > info_L_270 = struct TA669C7A1 > > _frame = struct ThreadWin32__GetStackBounds_Frame_t > > 0:000> ?? info_L_270 > > struct TA669C7A1 > > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > > ess 0x00000000`00190000 ---" > > +0x010 AllocationProtect : 4 > > +0x014 L_7 : [4] "" > > +0x018 RegionSize : 0n4096 > > +0x020 State : 0x1000 > > +0x024 Protect : 4 > > +0x028 Type : 0x20000 > > +0x02c L_8 : [4] "" > > 0:000> q > > quit: > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Sep 23 23:38:14 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 23 Sep 2013 21:38:14 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E650@ATLEX04-SRV.SCIRES.LOCAL> Jay: My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren't coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 23 23:47:55 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Sep 2013 21:47:55 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E650@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E650@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My ?m3-sys/mklib/src/Main.m3? is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren?t coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Sep 24 01:03:01 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 23 Sep 2013 23:03:01 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> Jay: Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. Do you want me to commit this change via CVS to the repository? Now, that gets me thru stage #1 of the rebuild. In stage #2, the packages and their order that I am attempting to compile are: Packages to be processed: ------------------------ m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3cggen m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3cgcat m3-sys\mklib But, skipping packages: m3cc ---END-of-List--- Things go fine until I get to m3core. I get an internal code generator error. See error below: --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 7 errors encountered Thanks for your continued help, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 5:48 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren't coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 24 01:58:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Sep 2013 23:58:02 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Randy, 1) can you please tell me exactly what release of cm3 you are using so I can go through the bootstrap myself and fix everything? 2) OR, can you please install a newer release and try bootstrapping from that? I uploaded new .msis last week or so. 3) What did you do between "stage 1" and "stage 2"? In stage 1, you did build and ship, not just build, right? And then you copied the new cm3.exe over top of the old? Or to a new install location, and use that for stage 2? You cleaned everything after stage 1? The whole process is subtle and needs to be done just right, very much by design and appropriate, but still somehow tricky to understand and explain. There is a distinct lack of guaranteed compatibility between versions, again, deliberately, and again, a proper bootstrap works ok anyway. We should perhaps do better at version stamping some things though. Thanks, - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 23:03:01 +0000 Jay: Thanks. I?ve applied the edit you suggested and was able to finish the compile for mklib. Do you want me to commit this change via CVS to the repository? Now, that gets me thru stage #1 of the rebuild. In stage #2, the packages and their order that I am attempting to compile are: Packages to be processed: ------------------------ m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3cggen m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3cgcat m3-sys\mklib But, skipping packages: m3cc ---END-of-List--- Things go fine until I get to m3core. I get an internal code generator error. See error below: --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 7 errors encountered Thanks for your continued help, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 5:48 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My ?m3-sys/mklib/src/Main.m3? is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren?t coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Sep 24 03:31:58 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 24 Sep 2013 01:31:58 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E9EE@ATLEX04-SRV.SCIRES.LOCAL> Jay: Re #1, C:\cm3\Sandbox\cm3\scripts\dev\windows>cm3 -version Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2013-09-23 22:52:35 configuration: C:\cm3\bin\cm3.cfg host: NT386 target: NT386 Re #2, I was hoping to get my edition updated. Re #3, I do a purge of the NT386 sandbox folders followed by a build/ship on each package, then at end of stage one I copy the new cm3.exe over the old one in the cm3\bin folder (as long as the stage build was successful). In stage two, I do a purge of NT386 sandbox folders again followed by build/ship of each package, and eventually replace the cm3.exe if the stage is successful. In stage three, I rebuild all packages following the same recipe. I've used this process for years with success, but I've let my implementation on this computer stay backlevel on purpose for compatibility with a production environment I've had to support, but now it is time to get current. Thanks for your help. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 7:58 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Randy, 1) can you please tell me exactly what release of cm3 you are using so I can go through the bootstrap myself and fix everything? 2) OR, can you please install a newer release and try bootstrapping from that? I uploaded new .msis last week or so. 3) What did you do between "stage 1" and "stage 2"? In stage 1, you did build and ship, not just build, right? And then you copied the new cm3.exe over top of the old? Or to a new install location, and use that for stage 2? You cleaned everything after stage 1? The whole process is subtle and needs to be done just right, very much by design and appropriate, but still somehow tricky to understand and explain. There is a distinct lack of guaranteed compatibility between versions, again, deliberately, and again, a proper bootstrap works ok anyway. We should perhaps do better at version stamping some things though. Thanks, - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 23:03:01 +0000 Jay: Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. Do you want me to commit this change via CVS to the repository? Now, that gets me thru stage #1 of the rebuild. In stage #2, the packages and their order that I am attempting to compile are: Packages to be processed: ------------------------ m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3cggen m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3cgcat m3-sys\mklib But, skipping packages: m3cc ---END-of-List--- Things go fine until I get to m3core. I get an internal code generator error. See error below: --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 7 errors encountered Thanks for your continued help, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 5:48 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren't coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Sep 24 03:32:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 23 Sep 2013 20:32:23 -0500 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <5240EBA7.2010909@lcwb.coop> Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? RTAllocator.m3 compiles fine on my AMD64_LINUX machine. On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > Jay: > > Thanks. I?ve applied the edit you suggested and was able to finish the compile for mklib. > > *Do you want me to commit this change via CVS to the repository?* > > Now, that gets me thru stage #1 of the rebuild. > > In stage #2, the packages and their order that I am attempting to compile are: > > Packages to be processed: > > ------------------------ > > m3-win\import-libs > > m3-sys\m3cc > > m3-libs\m3core > > m3-libs\libm3 > > m3-libs\sysutils > > m3-sys\m3middle > > m3-sys\m3objfile > > m3-sys\m3linker > > m3-sys\m3back > > m3-sys\m3cggen > > m3-sys\m3front > > m3-sys\m3quake > > m3-sys\cm3 > > m3-sys\m3cgcat > > m3-sys\mklib > > But, skipping packages: m3cc > > ---END-of-List--- > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > --- processing package "m3-libs\m3core" --- > > --- purging derived files from NT386 --- > > --- cleaning NT386 --- > > ignoring ..\src\m3overrides > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > new source -> compiling RuntimeError.i3 > > new source -> compiling WordRep.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > > new source -> compiling RTHooks.m3 > > new source -> compiling RT0.m3 > > new source -> compiling Compiler.i3 > > new source -> compiling RuntimeError.m3 > > new source -> compiling Compiler.m3 > > new source -> compiling RTAllocator.i3 > > new source -> compiling RTType.i3 > > new source -> compiling RTHeapRep.i3 > > new source -> compiling FloatMode.i3 > > new source -> compiling RTThread.i3 > > new source -> compiling Scheduler.i3 > > new source -> compiling RTOS.i3 > > new source -> compiling RTMisc.i3 > > new source -> compiling Cstdlib.i3 > > new source -> compiling Cstddef.i3 > > new source -> compiling LongRep.i3 > > new source -> compiling Long.i3 > > new source -> compiling BasicCtypes.i3 > > new source -> compiling Ctypes.i3 > > new source -> compiling RTAllocCnts.i3 > > new source -> compiling RTAllocator.m3 > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > 7 errors encountered > > Thanks for your continued help, > > Randy Coleburn > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > *Sent:* Monday, September 23, 2013 5:48 PM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Sorry, you are right I missed it. > > I'll fix it tonight probably. > > > Here it is: > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > - Jay > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > From: rcolebur at SCIRES.COM > To: jay.krell at cornell.edu ; m3devel at elegosoft.com > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > Jay: > > My ?m3-sys/mklib/src/Main.m3? is showing current wrt the HEAD branch in CVS. > > CVS indicates there is no update for me to obtain. > > My file is 850 lines in length. > > Did you commit changes to this file? If you did, they aren?t coming thru for me. > > So, the error persists: > > "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) > > Please advise. > > Thanks, > > Randy Coleburn > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > *Sent:* Sunday, September 22, 2013 1:43 AM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Right. > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > What does cm3 -version print? > > > or that my m3core is too old to be able to perform an upgrade > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > The system is written in itself. An excellent feature. > There are always therefore these problems, and always we should probably gradually require a newer build. > When there isn't a new enough native install, or any at all, a cross build is the solution. > I have "crossed" countless times at this point and can vouch for its viability. > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > - Jay > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > From: rcolebur at SCIRES.COM > To: jay.krell at cornell.edu ; m3devel at elegosoft.com > Date: Sun, 22 Sep 2013 05:35:15 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > I'm not able to use the python scripts due to the following error: > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > Traceback (most recent call last): > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > import pylib > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > if Host.endswith("_NT") or Host == "NT386": > AttributeError: 'NoneType' object has no attribute 'endswith' > > So, I'm working with my CMD files and doing stuff by hand. > > --Randy Coleburn > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > *From:*jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > *Sent:* Sunday, September 22, 2013 1:14 AM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 > > > - Jay > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > From: jay.krell at cornell.edu > To: rcolebur at scires.com ; m3devel at elegosoft.com > Date: Sun, 22 Sep 2013 05:03:17 +0000 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > In the first pass of upgrade, it comes from the install, so can be old..but how old? > After the first pass, it comes from the source tree. > > - Jay > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > From: rcolebur at SCIRES.COM > To: jay.krell at cornell.edu ; m3devel at elegosoft.com > Date: Sun, 22 Sep 2013 04:57:01 +0000 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay: > > Where is the CTypes file coming from? > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > --Randy Coleburn > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > *From:*jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > *Sent:* Sunday, September 22, 2013 12:41 AM > *To:* m3devel; Coleburn, Randy > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > I realize in this case, it is trivial to support older, but... > > - Jay > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 >> To:m3commit at elegosoft.com >> From:rcoleburn at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3CC.i3 >> >> Log message: >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" >> > From rcolebur at SCIRES.COM Tue Sep 24 03:48:57 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 24 Sep 2013 01:48:57 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL> Rodney: For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). Thus, I am running the integrated backend, I believe. I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. Thanks for your insight and help! Thanks, Randy Coleburn -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Monday, September 23, 2013 9:32 PM To: m3devel at elegosoft.com Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? RTAllocator.m3 compiles fine on my AMD64_LINUX machine. On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > Jay: > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > *Do you want me to commit this change via CVS to the repository?* > > Now, that gets me thru stage #1 of the rebuild. > > In stage #2, the packages and their order that I am attempting to compile are: > > Packages to be processed: > > ------------------------ > > m3-win\import-libs > > m3-sys\m3cc > > m3-libs\m3core > > m3-libs\libm3 > > m3-libs\sysutils > > m3-sys\m3middle > > m3-sys\m3objfile > > m3-sys\m3linker > > m3-sys\m3back > > m3-sys\m3cggen > > m3-sys\m3front > > m3-sys\m3quake > > m3-sys\cm3 > > m3-sys\m3cgcat > > m3-sys\mklib > > But, skipping packages: m3cc > > ---END-of-List--- > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > --- processing package "m3-libs\m3core" --- > > --- purging derived files from NT386 --- > > --- cleaning NT386 --- > > ignoring ..\src\m3overrides > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > new source -> compiling RuntimeError.i3 > > new source -> compiling WordRep.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > > new source -> compiling RTHooks.m3 > > new source -> compiling RT0.m3 > > new source -> compiling Compiler.i3 > > new source -> compiling RuntimeError.m3 > > new source -> compiling Compiler.m3 > > new source -> compiling RTAllocator.i3 > > new source -> compiling RTType.i3 > > new source -> compiling RTHeapRep.i3 > > new source -> compiling FloatMode.i3 > > new source -> compiling RTThread.i3 > > new source -> compiling Scheduler.i3 > > new source -> compiling RTOS.i3 > > new source -> compiling RTMisc.i3 > > new source -> compiling Cstdlib.i3 > > new source -> compiling Cstddef.i3 > > new source -> compiling LongRep.i3 > > new source -> compiling Long.i3 > > new source -> compiling BasicCtypes.i3 > > new source -> compiling Ctypes.i3 > > new source -> compiling RTAllocCnts.i3 > > new source -> compiling RTAllocator.m3 > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > 7 errors encountered > > Thanks for your continued help, > > Randy Coleburn > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > *Jay K > *Sent:* Monday, September 23, 2013 5:48 PM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Sorry, you are right I missed it. > > I'll fix it tonight probably. > > > Here it is: > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > m3core/src/win32/winnt.i3 *) > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > - Jay > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- -- > > From: rcolebur at SCIRES.COM > To: jay.krell at cornell.edu ; > m3devel at elegosoft.com > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > Jay: > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > CVS indicates there is no update for me to obtain. > > My file is 850 lines in length. > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > So, the error persists: > > "..\src\Main.m3", line 87: unknown qualification '.' > (IMAGE_FILE_MACHINE_AMD64) > > Please advise. > > Thanks, > > Randy Coleburn > > *From:*jayk123 at hotmail.com > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > *Sent:* Sunday, September 22, 2013 1:43 AM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Right. > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > What does cm3 -version print? > > > or that my m3core is too old to be able to perform an upgrade > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > The system is written in itself. An excellent feature. > There are always therefore these problems, and always we should probably gradually require a newer build. > When there isn't a new enough native install, or any at all, a cross build is the solution. > I have "crossed" countless times at this point and can vouch for its viability. > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > - Jay > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- -- > > From: rcolebur at SCIRES.COM > To: jay.krell at cornell.edu ; > m3devel at elegosoft.com > Date: Sun, 22 Sep 2013 05:35:15 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > "..\src\Main.m3", line 87: unknown qualification '.' > (IMAGE_FILE_MACHINE_AMD64) > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > I'm not able to use the python scripts due to the following error: > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > Traceback (most recent call last): > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > import pylib > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > if Host.endswith("_NT") or Host == "NT386": > AttributeError: 'NoneType' object has no attribute 'endswith' > > So, I'm working with my CMD files and doing stuff by hand. > > --Randy Coleburn > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- -- > > *From:*jayk123 at hotmail.com > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > *Sent:* Sunday, September 22, 2013 1:14 AM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > /Common/Ctypes.i3 > > > - Jay > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- -- > > From: jay.krell at cornell.edu > To: rcolebur at scires.com ; > m3devel at elegosoft.com > Date: Sun, 22 Sep 2013 05:03:17 +0000 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > In the first pass of upgrade, it comes from the install, so can be old..but how old? > After the first pass, it comes from the source tree. > > - Jay > > > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- -- > > From: rcolebur at SCIRES.COM > To: jay.krell at cornell.edu ; > m3devel at elegosoft.com > Date: Sun, 22 Sep 2013 04:57:01 +0000 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay: > > Where is the CTypes file coming from? > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > --Randy Coleburn > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > -------- -- > > *From:*jayk123 at hotmail.com > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > *Sent:* Sunday, September 22, 2013 12:41 AM > *To:* m3devel; Coleburn, Randy > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > I realize in this case, it is trivial to support older, but... > > - Jay > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com >> From:rcoleburn at elego.de >> >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3CC.i3 >> >> Log message: >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" >> > From jay.krell at cornell.edu Tue Sep 24 05:56:58 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Sep 2013 03:56:58 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: NT386 works fine on 64bit Windows.. The AMD64_NT target has a problem currently that I hope to figure out soon.. What version of cm3? A release? A random cvs upd time? - Jay > From: rcolebur at SCIRES.COM > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Tue, 24 Sep 2013 01:48:57 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Rodney: > > For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. > The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). > Thus, I am running the integrated backend, I believe. > > I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. > > That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. > > I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. > > In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). > > After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. > > Thanks for your insight and help! > > Thanks, > Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 23, 2013 9:32 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version > 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? > > I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? > > RTAllocator.m3 compiles fine on my AMD64_LINUX machine. > > > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > Jay: > > > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > > > *Do you want me to commit this change via CVS to the repository?* > > > > Now, that gets me thru stage #1 of the rebuild. > > > > In stage #2, the packages and their order that I am attempting to compile are: > > > > Packages to be processed: > > > > ------------------------ > > > > m3-win\import-libs > > > > m3-sys\m3cc > > > > m3-libs\m3core > > > > m3-libs\libm3 > > > > m3-libs\sysutils > > > > m3-sys\m3middle > > > > m3-sys\m3objfile > > > > m3-sys\m3linker > > > > m3-sys\m3back > > > > m3-sys\m3cggen > > > > m3-sys\m3front > > > > m3-sys\m3quake > > > > m3-sys\cm3 > > > > m3-sys\m3cgcat > > > > m3-sys\mklib > > > > But, skipping packages: m3cc > > > > ---END-of-List--- > > > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > > > Thanks for your continued help, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > > *Jay K > > *Sent:* Monday, September 23, 2013 5:48 PM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Sorry, you are right I missed it. > > > > I'll fix it tonight probably. > > > > > > Here it is: > > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > > m3core/src/win32/winnt.i3 *) > > > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > > > Jay: > > > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > > > CVS indicates there is no update for me to obtain. > > > > My file is 850 lines in length. > > > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > > > So, the error persists: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > Please advise. > > > > Thanks, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com > > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > > *Sent:* Sunday, September 22, 2013 1:43 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Right. > > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > > > > What does cm3 -version print? > > > > > or that my m3core is too old to be able to perform an upgrade > > > > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > > > > The system is written in itself. An excellent feature. > > There are always therefore these problems, and always we should probably gradually require a newer build. > > When there isn't a new enough native install, or any at all, a cross build is the solution. > > I have "crossed" countless times at this point and can vouch for its viability. > > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:35:15 +0000 > > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > > > I'm not able to use the python scripts due to the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > > Traceback (most recent call last): > > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > > import pylib > > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > > if Host.endswith("_NT") or Host == "NT386": > > AttributeError: 'NoneType' object has no attribute 'endswith' > > > > So, I'm working with my CMD files and doing stuff by hand. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 1:14 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > > /Common/Ctypes.i3 > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: jay.krell at cornell.edu > > To: rcolebur at scires.com ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:03:17 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > > In the first pass of upgrade, it comes from the install, so can be old..but how old? > > After the first pass, it comes from the source tree. > > > > - Jay > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 04:57:01 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Where is the CTypes file coming from? > > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 12:41 AM > > *To:* m3devel; Coleburn, Randy > > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > > I realize in this case, it is trivial to support older, but... > > > > - Jay > > > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com > >> From:rcoleburn at elego.de > >> > >> Subject: [M3commit] CVS Update: cm3 > >> > >> CVSROOT: /usr/cvs > >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 > >> > >> Modified files: > >> cm3/m3-sys/m3back/src/: M3CC.i3 > >> > >> Log message: > >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 24 06:21:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Sep 2013 04:21:02 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: Please update m3-sys/m3front/src/misc/CG.m3 and try again. I need to do more testing here though.. I'll try AMD64_DARWIN and I386_DARWIN with "my change" (which is just a partial undo). - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 03:56:58 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 NT386 works fine on 64bit Windows.. The AMD64_NT target has a problem currently that I hope to figure out soon.. What version of cm3? A release? A random cvs upd time? - Jay > From: rcolebur at SCIRES.COM > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Tue, 24 Sep 2013 01:48:57 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Rodney: > > For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. > The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). > Thus, I am running the integrated backend, I believe. > > I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. > > That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. > > I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. > > In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). > > After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. > > Thanks for your insight and help! > > Thanks, > Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 23, 2013 9:32 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version > 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? > > I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? > > RTAllocator.m3 compiles fine on my AMD64_LINUX machine. > > > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > Jay: > > > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > > > *Do you want me to commit this change via CVS to the repository?* > > > > Now, that gets me thru stage #1 of the rebuild. > > > > In stage #2, the packages and their order that I am attempting to compile are: > > > > Packages to be processed: > > > > ------------------------ > > > > m3-win\import-libs > > > > m3-sys\m3cc > > > > m3-libs\m3core > > > > m3-libs\libm3 > > > > m3-libs\sysutils > > > > m3-sys\m3middle > > > > m3-sys\m3objfile > > > > m3-sys\m3linker > > > > m3-sys\m3back > > > > m3-sys\m3cggen > > > > m3-sys\m3front > > > > m3-sys\m3quake > > > > m3-sys\cm3 > > > > m3-sys\m3cgcat > > > > m3-sys\mklib > > > > But, skipping packages: m3cc > > > > ---END-of-List--- > > > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > > > Thanks for your continued help, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > > *Jay K > > *Sent:* Monday, September 23, 2013 5:48 PM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Sorry, you are right I missed it. > > > > I'll fix it tonight probably. > > > > > > Here it is: > > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > > m3core/src/win32/winnt.i3 *) > > > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > > > Jay: > > > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > > > CVS indicates there is no update for me to obtain. > > > > My file is 850 lines in length. > > > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > > > So, the error persists: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > Please advise. > > > > Thanks, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com > > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > > *Sent:* Sunday, September 22, 2013 1:43 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Right. > > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > > > > What does cm3 -version print? > > > > > or that my m3core is too old to be able to perform an upgrade > > > > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > > > > The system is written in itself. An excellent feature. > > There are always therefore these problems, and always we should probably gradually require a newer build. > > When there isn't a new enough native install, or any at all, a cross build is the solution. > > I have "crossed" countless times at this point and can vouch for its viability. > > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:35:15 +0000 > > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > > > I'm not able to use the python scripts due to the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > > Traceback (most recent call last): > > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > > import pylib > > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > > if Host.endswith("_NT") or Host == "NT386": > > AttributeError: 'NoneType' object has no attribute 'endswith' > > > > So, I'm working with my CMD files and doing stuff by hand. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 1:14 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > > /Common/Ctypes.i3 > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: jay.krell at cornell.edu > > To: rcolebur at scires.com ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:03:17 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > > In the first pass of upgrade, it comes from the install, so can be old..but how old? > > After the first pass, it comes from the source tree. > > > > - Jay > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 04:57:01 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Where is the CTypes file coming from? > > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 12:41 AM > > *To:* m3devel; Coleburn, Randy > > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > > I realize in this case, it is trivial to support older, but... > > > > - Jay > > > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com > >> From:rcoleburn at elego.de > >> > >> Subject: [M3commit] CVS Update: cm3 > >> > >> CVSROOT: /usr/cvs > >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 > >> > >> Modified files: > >> cm3/m3-sys/m3back/src/: M3CC.i3 > >> > >> Log message: > >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 24 08:17:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Sep 2013 06:17:41 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>, , , Message-ID: And, my apologies, the upgrade procedure is rather in-place/destructive. You must have backup to try again. I kind of want to fix this. The way make-dist.py works is similar but fixes this -- it builds into new temporary locations. Upgrade could/should do that, and then copy back later on. - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 04:21:02 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Please update m3-sys/m3front/src/misc/CG.m3 and try again. I need to do more testing here though.. I'll try AMD64_DARWIN and I386_DARWIN with "my change" (which is just a partial undo). - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 03:56:58 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 NT386 works fine on 64bit Windows.. The AMD64_NT target has a problem currently that I hope to figure out soon.. What version of cm3? A release? A random cvs upd time? - Jay > From: rcolebur at SCIRES.COM > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Tue, 24 Sep 2013 01:48:57 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Rodney: > > For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. > The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). > Thus, I am running the integrated backend, I believe. > > I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. > > That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. > > I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. > > In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). > > After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. > > Thanks for your insight and help! > > Thanks, > Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 23, 2013 9:32 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version > 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? > > I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? > > RTAllocator.m3 compiles fine on my AMD64_LINUX machine. > > > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > Jay: > > > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > > > *Do you want me to commit this change via CVS to the repository?* > > > > Now, that gets me thru stage #1 of the rebuild. > > > > In stage #2, the packages and their order that I am attempting to compile are: > > > > Packages to be processed: > > > > ------------------------ > > > > m3-win\import-libs > > > > m3-sys\m3cc > > > > m3-libs\m3core > > > > m3-libs\libm3 > > > > m3-libs\sysutils > > > > m3-sys\m3middle > > > > m3-sys\m3objfile > > > > m3-sys\m3linker > > > > m3-sys\m3back > > > > m3-sys\m3cggen > > > > m3-sys\m3front > > > > m3-sys\m3quake > > > > m3-sys\cm3 > > > > m3-sys\m3cgcat > > > > m3-sys\mklib > > > > But, skipping packages: m3cc > > > > ---END-of-List--- > > > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > > > Thanks for your continued help, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > > *Jay K > > *Sent:* Monday, September 23, 2013 5:48 PM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Sorry, you are right I missed it. > > > > I'll fix it tonight probably. > > > > > > Here it is: > > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > > m3core/src/win32/winnt.i3 *) > > > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > > > Jay: > > > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > > > CVS indicates there is no update for me to obtain. > > > > My file is 850 lines in length. > > > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > > > So, the error persists: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > Please advise. > > > > Thanks, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com > > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > > *Sent:* Sunday, September 22, 2013 1:43 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Right. > > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > > > > What does cm3 -version print? > > > > > or that my m3core is too old to be able to perform an upgrade > > > > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > > > > The system is written in itself. An excellent feature. > > There are always therefore these problems, and always we should probably gradually require a newer build. > > When there isn't a new enough native install, or any at all, a cross build is the solution. > > I have "crossed" countless times at this point and can vouch for its viability. > > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:35:15 +0000 > > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > > > I'm not able to use the python scripts due to the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > > Traceback (most recent call last): > > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > > import pylib > > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > > if Host.endswith("_NT") or Host == "NT386": > > AttributeError: 'NoneType' object has no attribute 'endswith' > > > > So, I'm working with my CMD files and doing stuff by hand. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 1:14 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > > /Common/Ctypes.i3 > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: jay.krell at cornell.edu > > To: rcolebur at scires.com ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:03:17 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > > In the first pass of upgrade, it comes from the install, so can be old..but how old? > > After the first pass, it comes from the source tree. > > > > - Jay > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 04:57:01 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Where is the CTypes file coming from? > > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 12:41 AM > > *To:* m3devel; Coleburn, Randy > > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > > I realize in this case, it is trivial to support older, but... > > > > - Jay > > > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com > >> From:rcoleburn at elego.de > >> > >> Subject: [M3commit] CVS Update: cm3 > >> > >> CVSROOT: /usr/cvs > >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 > >> > >> Modified files: > >> cm3/m3-sys/m3back/src/: M3CC.i3 > >> > >> Log message: > >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Sep 25 18:04:09 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 25 Sep 2013 11:04:09 -0500 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <52430979.1040105@lcwb.coop> I can reproduce this symptom on a LINUXLIBC6 system and got a small example constructed. It does not happen on AMD64_LINUX, so is apparently word-size dependent. Jay's revert in CG.ScanTypes makes the problem go away here and elsewhere, so should help Randy get past this one. But it does reintroduce the same symptom on different cases, involving packed fields with bit counts other than 8, 16, 32, and 64. Something seems very wrong, as ScanTypes is, as originally coded, looking for a type whose alignment is <= the requested alignment, not >=. At least some of the requested alignment values are coming from a field commented as "(* minimum alignment in bits *)". But then there are places that ask for 64-bit alignment on all targets. Impossible to satisfy. I will keep my changes local until I get both groups of cases working on both word sizes. On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > --- processing package "m3-libs\m3core" --- > > --- purging derived files from NT386 --- > > --- cleaning NT386 --- > > ignoring ..\src\m3overrides > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > new source -> compiling RuntimeError.i3 > > new source -> compiling WordRep.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > > new source -> compiling RTHooks.m3 > > new source -> compiling RT0.m3 > > new source -> compiling Compiler.i3 > > new source -> compiling RuntimeError.m3 > > new source -> compiling Compiler.m3 > > new source -> compiling RTAllocator.i3 > > new source -> compiling RTType.i3 > > new source -> compiling RTHeapRep.i3 > > new source -> compiling FloatMode.i3 > > new source -> compiling RTThread.i3 > > new source -> compiling Scheduler.i3 > > new source -> compiling RTOS.i3 > > new source -> compiling RTMisc.i3 > > new source -> compiling Cstdlib.i3 > > new source -> compiling Cstddef.i3 > > new source -> compiling LongRep.i3 > > new source -> compiling Long.i3 > > new source -> compiling BasicCtypes.i3 > > new source -> compiling Ctypes.i3 > > new source -> compiling RTAllocCnts.i3 > > new source -> compiling RTAllocator.m3 > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > 7 errors encountered > From jay.krell at cornell.edu Wed Sep 25 18:52:36 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 25 Sep 2013 16:52:36 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <52430979.1040105@lcwb.coop> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL>, <52430979.1040105@lcwb.coop> Message-ID: Using a type with smaller alignment seems probably correct. 1) The original authors were pretty good. 2) So try to come up with a rationale that fits the existing code instead thinking through how we might write it from scratch. (Is this what people call "back filling"?) Really, I can't figure it out either from scratch, but I can maybe guess the thinking behind the existing code. Here is my guess: For example: I want to load a 32bit size 32bit aligned datum. I have available the ability to do load operation against a 32bit size 8 bit aligned datum. I can use that load operation on the more aligned data, as long as 32 mod 8 == 0. For all I care, we could remove bitfields from the language entirely. Make people use sets or bit operations with Word. I don't like that I can't predict the layout of bitfields. They currently introduce endian-dependentness, but we can fix that. But I know the garbage collection runtime uses them for compactness. - Jay > Date: Wed, 25 Sep 2013 11:04:09 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > I can reproduce this symptom on a LINUXLIBC6 system and got a small example > constructed. It does not happen on AMD64_LINUX, so is apparently word-size > dependent. > > Jay's revert in CG.ScanTypes makes the problem go away here and elsewhere, > so should help Randy get past this one. But it does reintroduce the same > symptom on different cases, involving packed fields with bit counts other > than 8, 16, 32, and 64. > > Something seems very wrong, as ScanTypes is, as originally coded, looking > for a type whose alignment is <= the requested alignment, not >=. At least > some of the requested alignment values are coming from a field commented as > "(* minimum alignment in bits *)". But then there are places that ask for > 64-bit alignment on all targets. Impossible to satisfy. > > I will keep my changes local until I get both groups of cases working on both > word sizes. > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Wed Sep 25 23:34:39 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 25 Sep 2013 21:34:39 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF3181D@ATLEX04-SRV.SCIRES.LOCAL> Jay, Rodney, et al: I am pleased to finally report SUCCESS with rebuilding my cm3 on 32-bit Windows XP ! Thanks for the help. I did have to restore my bin, lib, & pkg folders from backup in order to get the rebuild to succeed after the last round of patches. But, it works now. I do have a question though. I'm finding that I have to set an environment variable, CM3_TARGET=NT386; otherwise, the compiler is trying to target I386_NT and since all my target folders in pkg and in the sandbox are NT386, I run into all sorts of problems. If we should be using the new "I386_NT" name instead of "NT386", can I just rename all my NT386 folders to be I386_NT and stop setting the CM3_TARGET variable, or will there be problems with this approach? FYI, here is the version info on my rebuilt compiler (without setting the CM3_TARGET variable): Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2013-09-25 04:53:00 configuration: .\cm3.cfg host: NT386 defaulting to native build: I386_NT target: I386_NT Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, September 24, 2013 2:18 AM To: Coleburn, Randy; Rodney M. Bates; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 And, my apologies, the upgrade procedure is rather in-place/destructive. You must have backup to try again. I kind of want to fix this. The way make-dist.py works is similar but fixes this -- it builds into new temporary locations. Upgrade could/should do that, and then copy back later on. - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 04:21:02 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Please update m3-sys/m3front/src/misc/CG.m3 and try again. I need to do more testing here though.. I'll try AMD64_DARWIN and I386_DARWIN with "my change" (which is just a partial undo). - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 03:56:58 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 NT386 works fine on 64bit Windows.. The AMD64_NT target has a problem currently that I hope to figure out soon.. What version of cm3? A release? A random cvs upd time? - Jay > From: rcolebur at SCIRES.COM > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Tue, 24 Sep 2013 01:48:57 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Rodney: > > For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. > The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). > Thus, I am running the integrated backend, I believe. > > I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. > > That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. > > I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. > > In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). > > After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. > > Thanks for your insight and help! > > Thanks, > Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 23, 2013 9:32 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version > 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? > > I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? > > RTAllocator.m3 compiles fine on my AMD64_LINUX machine. > > > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > Jay: > > > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > > > *Do you want me to commit this change via CVS to the repository?* > > > > Now, that gets me thru stage #1 of the rebuild. > > > > In stage #2, the packages and their order that I am attempting to compile are: > > > > Packages to be processed: > > > > ------------------------ > > > > m3-win\import-libs > > > > m3-sys\m3cc > > > > m3-libs\m3core > > > > m3-libs\libm3 > > > > m3-libs\sysutils > > > > m3-sys\m3middle > > > > m3-sys\m3objfile > > > > m3-sys\m3linker > > > > m3-sys\m3back > > > > m3-sys\m3cggen > > > > m3-sys\m3front > > > > m3-sys\m3quake > > > > m3-sys\cm3 > > > > m3-sys\m3cgcat > > > > m3-sys\mklib > > > > But, skipping packages: m3cc > > > > ---END-of-List--- > > > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > > > Thanks for your continued help, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > > *Jay K > > *Sent:* Monday, September 23, 2013 5:48 PM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Sorry, you are right I missed it. > > > > I'll fix it tonight probably. > > > > > > Here it is: > > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > > m3core/src/win32/winnt.i3 *) > > > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > > > Jay: > > > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > > > CVS indicates there is no update for me to obtain. > > > > My file is 850 lines in length. > > > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > > > So, the error persists: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > Please advise. > > > > Thanks, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com > > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > > *Sent:* Sunday, September 22, 2013 1:43 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Right. > > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > > > > What does cm3 -version print? > > > > > or that my m3core is too old to be able to perform an upgrade > > > > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > > > > The system is written in itself. An excellent feature. > > There are always therefore these problems, and always we should probably gradually require a newer build. > > When there isn't a new enough native install, or any at all, a cross build is the solution. > > I have "crossed" countless times at this point and can vouch for its viability. > > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:35:15 +0000 > > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > > > I'm not able to use the python scripts due to the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > > Traceback (most recent call last): > > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > > import pylib > > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > > if Host.endswith("_NT") or Host == "NT386": > > AttributeError: 'NoneType' object has no attribute 'endswith' > > > > So, I'm working with my CMD files and doing stuff by hand. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 1:14 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > > /Common/Ctypes.i3 > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: jay.krell at cornell.edu > > To: rcolebur at scires.com ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:03:17 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > > In the first pass of upgrade, it comes from the install, so can be old..but how old? > > After the first pass, it comes from the source tree. > > > > - Jay > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 04:57:01 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Where is the CTypes file coming from? > > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 12:41 AM > > *To:* m3devel; Coleburn, Randy > > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > > I realize in this case, it is trivial to support older, but... > > > > - Jay > > > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com > >> From:rcoleburn at elego.de > >> > >> Subject: [M3commit] CVS Update: cm3 > >> > >> CVSROOT: /usr/cvs > >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 > >> > >> Modified files: > >> cm3/m3-sys/m3back/src/: M3CC.i3 > >> > >> Log message: > >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 26 00:34:09 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 25 Sep 2013 22:34:09 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF3181D@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF3181D@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Good. Yes you can rename anything named NT386 to I386_NT. They are the same. I suppose maybe..if you upgrade from an NT386 system, the result should be NT386, and produce NT386 by default. That only explicitly I386_NT or cross (which requires explicit target anyway) should switch to the new name. I'd want any new users/installs to use I386_NT, but perhaps it is rude to switch existing users/installs. Probably what I did is default to the new names unless CM3_TARGET is set. Does upgrade.py and do-cm3-all.py buildship work for you now? - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Wed, 25 Sep 2013 21:34:39 +0000 Jay, Rodney, et al: I am pleased to finally report SUCCESS with rebuilding my cm3 on 32-bit Windows XP ! Thanks for the help. I did have to restore my bin, lib, & pkg folders from backup in order to get the rebuild to succeed after the last round of patches. But, it works now. I do have a question though. I?m finding that I have to set an environment variable, CM3_TARGET=NT386; otherwise, the compiler is trying to target I386_NT and since all my target folders in pkg and in the sandbox are NT386, I run into all sorts of problems. If we should be using the new ?I386_NT? name instead of ?NT386?, can I just rename all my NT386 folders to be I386_NT and stop setting the CM3_TARGET variable, or will there be problems with this approach? FYI, here is the version info on my rebuilt compiler (without setting the CM3_TARGET variable): Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2013-09-25 04:53:00 configuration: .\cm3.cfg host: NT386 defaulting to native build: I386_NT target: I386_NT Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, September 24, 2013 2:18 AM To: Coleburn, Randy; Rodney M. Bates; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 And, my apologies, the upgrade procedure is rather in-place/destructive. You must have backup to try again. I kind of want to fix this. The way make-dist.py works is similar but fixes this -- it builds into new temporary locations. Upgrade could/should do that, and then copy back later on. - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 04:21:02 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Please update m3-sys/m3front/src/misc/CG.m3 and try again. I need to do more testing here though.. I'll try AMD64_DARWIN and I386_DARWIN with "my change" (which is just a partial undo). - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 03:56:58 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 NT386 works fine on 64bit Windows.. The AMD64_NT target has a problem currently that I hope to figure out soon.. What version of cm3? A release? A random cvs upd time? - Jay > From: rcolebur at SCIRES.COM > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Tue, 24 Sep 2013 01:48:57 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Rodney: > > For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. > The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). > Thus, I am running the integrated backend, I believe. > > I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. > > That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. > > I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. > > In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). > > After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. > > Thanks for your insight and help! > > Thanks, > Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 23, 2013 9:32 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version > 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? > > I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? > > RTAllocator.m3 compiles fine on my AMD64_LINUX machine. > > > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > Jay: > > > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > > > *Do you want me to commit this change via CVS to the repository?* > > > > Now, that gets me thru stage #1 of the rebuild. > > > > In stage #2, the packages and their order that I am attempting to compile are: > > > > Packages to be processed: > > > > ------------------------ > > > > m3-win\import-libs > > > > m3-sys\m3cc > > > > m3-libs\m3core > > > > m3-libs\libm3 > > > > m3-libs\sysutils > > > > m3-sys\m3middle > > > > m3-sys\m3objfile > > > > m3-sys\m3linker > > > > m3-sys\m3back > > > > m3-sys\m3cggen > > > > m3-sys\m3front > > > > m3-sys\m3quake > > > > m3-sys\cm3 > > > > m3-sys\m3cgcat > > > > m3-sys\mklib > > > > But, skipping packages: m3cc > > > > ---END-of-List--- > > > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > > > Thanks for your continued help, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > > *Jay K > > *Sent:* Monday, September 23, 2013 5:48 PM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Sorry, you are right I missed it. > > > > I'll fix it tonight probably. > > > > > > Here it is: > > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > > m3core/src/win32/winnt.i3 *) > > > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > > > Jay: > > > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > > > CVS indicates there is no update for me to obtain. > > > > My file is 850 lines in length. > > > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > > > So, the error persists: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > Please advise. > > > > Thanks, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com > > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > > *Sent:* Sunday, September 22, 2013 1:43 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Right. > > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > > > > What does cm3 -version print? > > > > > or that my m3core is too old to be able to perform an upgrade > > > > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > > > > The system is written in itself. An excellent feature. > > There are always therefore these problems, and always we should probably gradually require a newer build. > > When there isn't a new enough native install, or any at all, a cross build is the solution. > > I have "crossed" countless times at this point and can vouch for its viability. > > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:35:15 +0000 > > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > > > I'm not able to use the python scripts due to the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > > Traceback (most recent call last): > > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > > import pylib > > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > > if Host.endswith("_NT") or Host == "NT386": > > AttributeError: 'NoneType' object has no attribute 'endswith' > > > > So, I'm working with my CMD files and doing stuff by hand. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 1:14 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > > /Common/Ctypes.i3 > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: jay.krell at cornell.edu > > To: rcolebur at scires.com ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:03:17 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > > In the first pass of upgrade, it comes from the install, so can be old..but how old? > > After the first pass, it comes from the source tree. > > > > - Jay > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 04:57:01 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Where is the CTypes file coming from? > > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 12:41 AM > > *To:* m3devel; Coleburn, Randy > > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > > I realize in this case, it is trivial to support older, but... > > > > - Jay > > > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com > >> From:rcoleburn at elego.de > >> > >> Subject: [M3commit] CVS Update: cm3 > >> > >> CVSROOT: /usr/cvs > >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 > >> > >> Modified files: > >> cm3/m3-sys/m3back/src/: M3CC.i3 > >> > >> Log message: > >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Sep 26 01:28:05 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 25 Sep 2013 23:28:05 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF31A41@ATLEX04-SRV.SCIRES.LOCAL> Jay: I have not tried the python again; rather I used my CMD scripts that have worked for me in the past. I just had to stop skipping the mklib in the first phase. If you want me to run a test of the python, let me know and I'll first backup what I have. It seems odd to me that the version output of the compiler identifies the host as NT386, but then says it is "defaulting to native build: I386_NT" with "target: I386_NT". (In the past these were the same.) I suppose I'm not clued-in to the new naming conventions, but I can switch to whatever is the new standard. Now, when I take my NT386/I386_NT stuff and try rebuilding on 64-bit Windows-7, will any of these names (host or target) change again? Also, do I need to set any variables to tell the system to use 64-bit vs. 32-bit ? (I may not be expressing this correctly, but my goal is to take my existing 32-bit base and use it to generate a 64-bit base.) If all these naming conventions are documented somewhere, you can just point me to it and I'll look it up. Before I rebuild on 64-bit Win7, I'm first going to rebuild all my developed software using the new compiler and run some tests to make sure everything is working ok. I'll let you know if I run into any problems I can't solve. I'm also going to try and find some time to commit to the repository some of the modules I've developed in the hope that others might find them useful. Thanks, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Wednesday, September 25, 2013 6:34 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Good. Yes you can rename anything named NT386 to I386_NT. They are the same. I suppose maybe..if you upgrade from an NT386 system, the result should be NT386, and produce NT386 by default. That only explicitly I386_NT or cross (which requires explicit target anyway) should switch to the new name. I'd want any new users/installs to use I386_NT, but perhaps it is rude to switch existing users/installs. Probably what I did is default to the new names unless CM3_TARGET is set. Does upgrade.py and do-cm3-all.py buildship work for you now? - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Wed, 25 Sep 2013 21:34:39 +0000 Jay, Rodney, et al: I am pleased to finally report SUCCESS with rebuilding my cm3 on 32-bit Windows XP ! Thanks for the help. I did have to restore my bin, lib, & pkg folders from backup in order to get the rebuild to succeed after the last round of patches. But, it works now. I do have a question though. I'm finding that I have to set an environment variable, CM3_TARGET=NT386; otherwise, the compiler is trying to target I386_NT and since all my target folders in pkg and in the sandbox are NT386, I run into all sorts of problems. If we should be using the new "I386_NT" name instead of "NT386", can I just rename all my NT386 folders to be I386_NT and stop setting the CM3_TARGET variable, or will there be problems with this approach? FYI, here is the version info on my rebuilt compiler (without setting the CM3_TARGET variable): Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2013-09-25 04:53:00 configuration: .\cm3.cfg host: NT386 defaulting to native build: I386_NT target: I386_NT Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, September 24, 2013 2:18 AM To: Coleburn, Randy; Rodney M. Bates; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 And, my apologies, the upgrade procedure is rather in-place/destructive. You must have backup to try again. I kind of want to fix this. The way make-dist.py works is similar but fixes this -- it builds into new temporary locations. Upgrade could/should do that, and then copy back later on. - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 04:21:02 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Please update m3-sys/m3front/src/misc/CG.m3 and try again. I need to do more testing here though.. I'll try AMD64_DARWIN and I386_DARWIN with "my change" (which is just a partial undo). - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 03:56:58 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 NT386 works fine on 64bit Windows.. The AMD64_NT target has a problem currently that I hope to figure out soon.. What version of cm3? A release? A random cvs upd time? - Jay > From: rcolebur at SCIRES.COM > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Tue, 24 Sep 2013 01:48:57 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Rodney: > > For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. > The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). > Thus, I am running the integrated backend, I believe. > > I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. > > That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. > > I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. > > In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). > > After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. > > Thanks for your insight and help! > > Thanks, > Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 23, 2013 9:32 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version > 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? > > I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? > > RTAllocator.m3 compiles fine on my AMD64_LINUX machine. > > > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > Jay: > > > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > > > *Do you want me to commit this change via CVS to the repository?* > > > > Now, that gets me thru stage #1 of the rebuild. > > > > In stage #2, the packages and their order that I am attempting to compile are: > > > > Packages to be processed: > > > > ------------------------ > > > > m3-win\import-libs > > > > m3-sys\m3cc > > > > m3-libs\m3core > > > > m3-libs\libm3 > > > > m3-libs\sysutils > > > > m3-sys\m3middle > > > > m3-sys\m3objfile > > > > m3-sys\m3linker > > > > m3-sys\m3back > > > > m3-sys\m3cggen > > > > m3-sys\m3front > > > > m3-sys\m3quake > > > > m3-sys\cm3 > > > > m3-sys\m3cgcat > > > > m3-sys\mklib > > > > But, skipping packages: m3cc > > > > ---END-of-List--- > > > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > > > Thanks for your continued help, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > > *Jay K > > *Sent:* Monday, September 23, 2013 5:48 PM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Sorry, you are right I missed it. > > > > I'll fix it tonight probably. > > > > > > Here it is: > > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > > m3core/src/win32/winnt.i3 *) > > > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > > > Jay: > > > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > > > CVS indicates there is no update for me to obtain. > > > > My file is 850 lines in length. > > > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > > > So, the error persists: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > Please advise. > > > > Thanks, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com > > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > > *Sent:* Sunday, September 22, 2013 1:43 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Right. > > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > > > > What does cm3 -version print? > > > > > or that my m3core is too old to be able to perform an upgrade > > > > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > > > > The system is written in itself. An excellent feature. > > There are always therefore these problems, and always we should probably gradually require a newer build. > > When there isn't a new enough native install, or any at all, a cross build is the solution. > > I have "crossed" countless times at this point and can vouch for its viability. > > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:35:15 +0000 > > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > > > I'm not able to use the python scripts due to the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > > Traceback (most recent call last): > > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > > import pylib > > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > > if Host.endswith("_NT") or Host == "NT386": > > AttributeError: 'NoneType' object has no attribute 'endswith' > > > > So, I'm working with my CMD files and doing stuff by hand. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 1:14 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > > /Common/Ctypes.i3 > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: jay.krell at cornell.edu > > To: rcolebur at scires.com ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:03:17 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > > In the first pass of upgrade, it comes from the install, so can be old..but how old? > > After the first pass, it comes from the source tree. > > > > - Jay > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 04:57:01 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Where is the CTypes file coming from? > > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 12:41 AM > > *To:* m3devel; Coleburn, Randy > > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > > I realize in this case, it is trivial to support older, but... > > > > - Jay > > > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com > >> From:rcoleburn at elego.de > >> > >> Subject: [M3commit] CVS Update: cm3 > >> > >> CVSROOT: /usr/cvs > >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 > >> > >> Modified files: > >> cm3/m3-sys/m3back/src/: M3CC.i3 > >> > >> Log message: > >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 26 02:26:31 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Sep 2013 00:26:31 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF31A41@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF31A41@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Switching to 64bit Windows won't change anything by default. You can ask for AMD64_NT, but there is a problem with it currently that needs to be fixed. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Wed, 25 Sep 2013 23:28:05 +0000 Jay: I have not tried the python again; rather I used my CMD scripts that have worked for me in the past. I just had to stop skipping the mklib in the first phase. If you want me to run a test of the python, let me know and I?ll first backup what I have. It seems odd to me that the version output of the compiler identifies the host as NT386, but then says it is ?defaulting to native build: I386_NT? with ?target: I386_NT?. (In the past these were the same.) I suppose I?m not clued-in to the new naming conventions, but I can switch to whatever is the new standard. Now, when I take my NT386/I386_NT stuff and try rebuilding on 64-bit Windows-7, will any of these names (host or target) change again? Also, do I need to set any variables to tell the system to use 64-bit vs. 32-bit ? (I may not be expressing this correctly, but my goal is to take my existing 32-bit base and use it to generate a 64-bit base.) If all these naming conventions are documented somewhere, you can just point me to it and I?ll look it up. Before I rebuild on 64-bit Win7, I?m first going to rebuild all my developed software using the new compiler and run some tests to make sure everything is working ok. I?ll let you know if I run into any problems I can?t solve. I?m also going to try and find some time to commit to the repository some of the modules I?ve developed in the hope that others might find them useful. Thanks, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Wednesday, September 25, 2013 6:34 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Good. Yes you can rename anything named NT386 to I386_NT. They are the same. I suppose maybe..if you upgrade from an NT386 system, the result should be NT386, and produce NT386 by default. That only explicitly I386_NT or cross (which requires explicit target anyway) should switch to the new name. I'd want any new users/installs to use I386_NT, but perhaps it is rude to switch existing users/installs. Probably what I did is default to the new names unless CM3_TARGET is set. Does upgrade.py and do-cm3-all.py buildship work for you now? - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Wed, 25 Sep 2013 21:34:39 +0000 Jay, Rodney, et al: I am pleased to finally report SUCCESS with rebuilding my cm3 on 32-bit Windows XP ! Thanks for the help. I did have to restore my bin, lib, & pkg folders from backup in order to get the rebuild to succeed after the last round of patches. But, it works now. I do have a question though. I?m finding that I have to set an environment variable, CM3_TARGET=NT386; otherwise, the compiler is trying to target I386_NT and since all my target folders in pkg and in the sandbox are NT386, I run into all sorts of problems. If we should be using the new ?I386_NT? name instead of ?NT386?, can I just rename all my NT386 folders to be I386_NT and stop setting the CM3_TARGET variable, or will there be problems with this approach? FYI, here is the version info on my rebuilt compiler (without setting the CM3_TARGET variable): Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2013-09-25 04:53:00 configuration: .\cm3.cfg host: NT386 defaulting to native build: I386_NT target: I386_NT Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, September 24, 2013 2:18 AM To: Coleburn, Randy; Rodney M. Bates; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 And, my apologies, the upgrade procedure is rather in-place/destructive. You must have backup to try again. I kind of want to fix this. The way make-dist.py works is similar but fixes this -- it builds into new temporary locations. Upgrade could/should do that, and then copy back later on. - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 04:21:02 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Please update m3-sys/m3front/src/misc/CG.m3 and try again. I need to do more testing here though.. I'll try AMD64_DARWIN and I386_DARWIN with "my change" (which is just a partial undo). - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 24 Sep 2013 03:56:58 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 NT386 works fine on 64bit Windows.. The AMD64_NT target has a problem currently that I hope to figure out soon.. What version of cm3? A release? A random cvs upd time? - Jay > From: rcolebur at SCIRES.COM > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Tue, 24 Sep 2013 01:48:57 +0000 > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Rodney: > > For this situation, I'm compiling on an old 32-bit Windows XP computer targeting NT386. > The computer has Microsoft Visual Studio 2008 Express installed (needed for the linker and the C compiler). > Thus, I am running the integrated backend, I believe. > > I've kept this computer backlevel from the HEAD branch for quite some time because I had to maintain exact synchronization with the build environment for some stuff I've been supporting in production. > > That support requirement has gone away, so I want to update to the latest (and greatest?) compiler and sources. My sandbox is now current wrt the HEAD branch via CVS. > > I've succeeded in making it thru the first stage of the compiler rebuild process, but now in stage #2 I get the error that I reported. > > In the past, I've always been able to update via CVS then rebuild everything, but perhaps I've waited too long in this case, or maybe I've uncovered some bug(s). > > After I get things working on this 32-bit XP machine (see I'm trying to be optimistic), I plan to update on a 64-bit Windows7 computer. I'm not sure though if I can start with my 32-bit implementation and simply rebuild on the 64-bit machine to bump up to 64-bit binaries, or if more adjustment or a different approach is required. > > Thanks for your insight and help! > > Thanks, > Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 23, 2013 9:32 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version > 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? > > I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? > > RTAllocator.m3 compiles fine on my AMD64_LINUX machine. > > > > On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > > Jay: > > > > Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. > > > > *Do you want me to commit this change via CVS to the repository?* > > > > Now, that gets me thru stage #1 of the rebuild. > > > > In stage #2, the packages and their order that I am attempting to compile are: > > > > Packages to be processed: > > > > ------------------------ > > > > m3-win\import-libs > > > > m3-sys\m3cc > > > > m3-libs\m3core > > > > m3-libs\libm3 > > > > m3-libs\sysutils > > > > m3-sys\m3middle > > > > m3-sys\m3objfile > > > > m3-sys\m3linker > > > > m3-sys\m3back > > > > m3-sys\m3cggen > > > > m3-sys\m3front > > > > m3-sys\m3quake > > > > m3-sys\cm3 > > > > m3-sys\m3cgcat > > > > m3-sys\mklib > > > > But, skipping packages: m3cc > > > > ---END-of-List--- > > > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > > > --- processing package "m3-libs\m3core" --- > > > > --- purging derived files from NT386 --- > > > > --- cleaning NT386 --- > > > > ignoring ..\src\m3overrides > > > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > new source -> compiling RuntimeError.i3 > > > > new source -> compiling WordRep.i3 > > > > new source -> compiling Word.i3 > > > > new source -> compiling RTException.i3 > > > > new source -> compiling RTHooks.m3 > > > > new source -> compiling RT0.m3 > > > > new source -> compiling Compiler.i3 > > > > new source -> compiling RuntimeError.m3 > > > > new source -> compiling Compiler.m3 > > > > new source -> compiling RTAllocator.i3 > > > > new source -> compiling RTType.i3 > > > > new source -> compiling RTHeapRep.i3 > > > > new source -> compiling FloatMode.i3 > > > > new source -> compiling RTThread.i3 > > > > new source -> compiling Scheduler.i3 > > > > new source -> compiling RTOS.i3 > > > > new source -> compiling RTMisc.i3 > > > > new source -> compiling Cstdlib.i3 > > > > new source -> compiling Cstddef.i3 > > > > new source -> compiling LongRep.i3 > > > > new source -> compiling Long.i3 > > > > new source -> compiling BasicCtypes.i3 > > > > new source -> compiling Ctypes.i3 > > > > new source -> compiling RTAllocCnts.i3 > > > > new source -> compiling RTAllocator.m3 > > > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR > > *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > > > 7 errors encountered > > > > Thanks for your continued help, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > > *Jay K > > *Sent:* Monday, September 23, 2013 5:48 PM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Sorry, you are right I missed it. > > > > I'll fix it tonight probably. > > > > > > Here it is: > > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from > > m3core/src/win32/winnt.i3 *) > > > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > > > Jay: > > > > My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. > > > > CVS indicates there is no update for me to obtain. > > > > My file is 850 lines in length. > > > > Did you commit changes to this file? If you did, they aren't coming thru for me. > > > > So, the error persists: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > Please advise. > > > > Thanks, > > > > Randy Coleburn > > > > *From:*jayk123 at hotmail.com > > [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > > *Sent:* Sunday, September 22, 2013 1:43 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Right. > > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > > > > What does cm3 -version print? > > > > > or that my m3core is too old to be able to perform an upgrade > > > > > > Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. > > > > > > The system is written in itself. An excellent feature. > > There are always therefore these problems, and always we should probably gradually require a newer build. > > When there isn't a new enough native install, or any at all, a cross build is the solution. > > I have "crossed" countless times at this point and can vouch for its viability. > > We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:35:15 +0000 > > Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > > > Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: > > > > "..\src\Main.m3", line 87: unknown qualification '.' > > (IMAGE_FILE_MACHINE_AMD64) > > > > In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." > > > > Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? > > > > I'm not able to use the python scripts due to the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > > Traceback (most recent call last): > > File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in > > import pylib > > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in > > if Host.endswith("_NT") or Host == "NT386": > > AttributeError: 'NoneType' object has no attribute 'endswith' > > > > So, I'm working with my CMD files and doing stuff by hand. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 1:14 AM > > *To:* Coleburn, Randy; m3devel > > *Subject:* EXT:RE: [M3devel] [M3commit] CVS Update: cm3 > > > > https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C > > /Common/Ctypes.i3 > > > > > > - Jay > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: jay.krell at cornell.edu > > To: rcolebur at scires.com ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 05:03:17 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. > > In the first pass of upgrade, it comes from the install, so can be old..but how old? > > After the first pass, it comes from the source tree. > > > > - Jay > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > From: rcolebur at SCIRES.COM > > To: jay.krell at cornell.edu ; > > m3devel at elegosoft.com > > Date: Sun, 22 Sep 2013 04:57:01 +0000 > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Where is the CTypes file coming from? > > I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. > > If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. > > The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. > > > > --Randy Coleburn > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > ---------------------------------------------------------------------- > > -------- > -- > > > > *From:*jayk123 at hotmail.com > > [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] > > *Sent:* Sunday, September 22, 2013 12:41 AM > > *To:* m3devel; Coleburn, Randy > > *Subject:* EXT:RE: [M3commit] CVS Update: cm3 > > > > Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . > > I realize in this case, it is trivial to support older, but... > > > > - Jay > > > >> Date: Sun, 22 Sep 2013 06:35:02 +0000 To:m3commit at elegosoft.com > >> From:rcoleburn at elego.de > >> > >> Subject: [M3commit] CVS Update: cm3 > >> > >> CVSROOT: /usr/cvs > >> Changes by: rcoleburn at birch. 13/09/22 06:35:02 > >> > >> Modified files: > >> cm3/m3-sys/m3back/src/: M3CC.i3 > >> > >> Log message: > >> fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 29 23:44:24 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 29 Sep 2013 21:44:24 +0000 Subject: [M3devel] caltech-parser test build error Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF369BD@ATLEX04-SRV.SCIRES.LOCAL> I'm getting a build error for "caltech-parser\parserlib\parserlib\test". (See below.) I'm not real familiar with this package, but the problem seems to be a path problem in invoking "ktok.exe". In the output below, the path being requested is: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok.exe I think this path should instead be: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\ktok\NT386\ktok.exe Or, alternately, if one wanted the "ktok.exe" in "bin", the path should be: C:\cm3\bin\ktok.exe The choice of path seems to be coming from a template file, but it isn't dealing properly with the location of the source tree (which could be rooted anywhere desired; mine is rooted at C:\cm3\Sandbox\cm3). Does anyone know if this package builds properly on other systems? If so, perhaps the template needs adjusting for NT386. Otherwise, there is a problem common to all platforms that should be repaired. Here is the output of my attempt to build this package: C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src>cm3 --- building in ..\NT386 --- ignoring ..\src\m3overrides C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Sep 30 00:59:35 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 29 Sep 2013 22:59:35 +0000 Subject: [M3devel] question on File.Status.size Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL> I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. I've run into some new build errors and have a question. It seems the type of File.Status.size has been changed to LONGCARD. I have some code that now fails to build because of this change. I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). So, for example: fs := FS.Status(file); INC(numBytes, fs.size); no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? (Interface File uses open arrays) In my old language definition, it says that: An open array type declaration has the form: TYPE T = ARRAY OF Element where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 30 06:48:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 30 Sep 2013 04:48:41 +0000 Subject: [M3devel] question on File.Status.size In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: > NUMBER(array) to yield a LONGCARD This can't be. Arrays are in-memory data structures. INTEGER/CARDINAL are an appropriate type to hold the size of something fits in memory/address-space. INTEGER is like C's ptrdiff_t. CARDINAL is kind of like C's size_t, except it is half range. Word.T is kind of like C's size_t, except it has no convenient in-fix operators. Files commonly do not fit in memory/address-space. So they arguably should have their size stored in a larger type. I think there is no easy answer here. I would be ok with: - put it back to INTEGER/CARDINAL - expose another way new way to get a LONGCARD - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Sun, 29 Sep 2013 22:59:35 +0000 Subject: [M3devel] question on File.Status.size I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. I've run into some new build errors and have a question. It seems the type of File.Status.size has been changed to LONGCARD. I have some code that now fails to build because of this change. I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). So, for example: fs := FS.Status(file); INC(numBytes, fs.size); no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? (Interface File uses open arrays) In my old language definition, it says that: An open array type declaration has the form: TYPE T = ARRAY OF Element where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Sep 30 15:49:43 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 30 Sep 2013 13:49:43 +0000 Subject: [M3devel] question on File.Status.size In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: <176E8593-3667-4CC6-BFEB-98F3E949F592@SCIRES.COM> I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER? If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. Thanks, Randy Coleburn Sent from my iPhone On Sep 30, 2013, at 12:48 AM, "Jay K" > wrote: > NUMBER(array) to yield a LONGCARD This can't be. Arrays are in-memory data structures. INTEGER/CARDINAL are an appropriate type to hold the size of something fits in memory/address-space. INTEGER is like C's ptrdiff_t. CARDINAL is kind of like C's size_t, except it is half range. Word.T is kind of like C's size_t, except it has no convenient in-fix operators. Files commonly do not fit in memory/address-space. So they arguably should have their size stored in a larger type. I think there is no easy answer here. I would be ok with: - put it back to INTEGER/CARDINAL - expose another way new way to get a LONGCARD - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Sun, 29 Sep 2013 22:59:35 +0000 Subject: [M3devel] question on File.Status.size I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. I've run into some new build errors and have a question. It seems the type of File.Status.size has been changed to LONGCARD. I have some code that now fails to build because of this change. I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). So, for example: fs := FS.Status(file); INC(numBytes, fs.size); no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? (Interface File uses open arrays) In my old language definition, it says that: An open array type declaration has the form: TYPE T = ARRAY OF Element where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 30 17:46:05 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Sep 2013 11:46:05 -0400 Subject: [M3devel] question on File.Status.size In-Reply-To: <176E8593-3667-4CC6-BFEB-98F3E949F592@SCIRES.COM> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL>, <176E8593-3667-4CC6-BFEB-98F3E949F592@SCIRES.COM> Message-ID: <26D73256-5314-4EB1-BB92-64088BA0386C@cs.purdue.edu> Indeed, I wonder if it should be Long.T instead of LONGCARD, because I am uneasy with the assumption that the representation might not change. (I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.) Now, on the other hand, POSIX specifies file sizes to be off_t, which is signed, whereas Long.T is meant to be thought of as unsigned. So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense. On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" wrote: > I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER? > > If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). > > I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. > > Thanks, > Randy Coleburn > > Sent from my iPhone > > On Sep 30, 2013, at 12:48 AM, "Jay K" wrote: > >> > NUMBER(array) to yield a LONGCARD >> >> This can't be. >> Arrays are in-memory data structures. >> INTEGER/CARDINAL are an appropriate type >> to hold the size of something fits in memory/address-space. >> INTEGER is like C's ptrdiff_t. >> CARDINAL is kind of like C's size_t, except it is half range. >> Word.T is kind of like C's size_t, except it has no convenient in-fix operators. >> >> >> Files commonly do not fit in memory/address-space. >> So they arguably should have their size stored >> in a larger type. >> >> >> I think there is no easy answer here. >> >> >> I would be ok with: >> - put it back to INTEGER/CARDINAL >> - expose another way new way to get a LONGCARD >> >> >> - Jay >> >> >> >> >> From: rcolebur at SCIRES.COM >> To: m3devel at elegosoft.com >> Date: Sun, 29 Sep 2013 22:59:35 +0000 >> Subject: [M3devel] question on File.Status.size >> >> I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. >> >> I've run into some new build errors and have a question. >> >> It seems the type of File.Status.size has been changed to LONGCARD. >> >> I have some code that now fails to build because of this change. >> >> I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). >> >> So, for example: >> fs := FS.Status(file); >> INC(numBytes, fs.size); >> no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. >> >> Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? >> (Interface File uses open arrays) >> >> In my old language definition, it says that: >> An open array type declaration has the form: >> TYPE T = ARRAY OF Element >> where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. >> In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. >> >> How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? >> >> Thanks, >> Randy Coleburn >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Sep 30 19:38:36 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 30 Sep 2013 17:38:36 +0000 Subject: [M3devel] question on File.Status.size Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF37B15@ATLEX04-SRV.SCIRES.LOCAL> Whether it is signed or not, to me it only makes sense that both the size of a file and NUMBER(x) are always semantically a CARDINAL type, i.e., >= 0. --Randy Coleburn From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Monday, September 30, 2013 11:46 AM To: Coleburn, Randy Cc: Jay K; m3devel Subject: EXT:Re: [M3devel] question on File.Status.size Indeed, I wonder if it should be Long.T instead of LONGCARD, because I am uneasy with the assumption that the representation might not change. (I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.) Now, on the other hand, POSIX specifies file sizes to be off_t, which is signed, whereas Long.T is meant to be thought of as unsigned. So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense. On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" > wrote: I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER? If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. Thanks, Randy Coleburn Sent from my iPhone On Sep 30, 2013, at 12:48 AM, "Jay K" > wrote: > NUMBER(array) to yield a LONGCARD This can't be. Arrays are in-memory data structures. INTEGER/CARDINAL are an appropriate type to hold the size of something fits in memory/address-space. INTEGER is like C's ptrdiff_t. CARDINAL is kind of like C's size_t, except it is half range. Word.T is kind of like C's size_t, except it has no convenient in-fix operators. Files commonly do not fit in memory/address-space. So they arguably should have their size stored in a larger type. I think there is no easy answer here. I would be ok with: - put it back to INTEGER/CARDINAL - expose another way new way to get a LONGCARD - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Sun, 29 Sep 2013 22:59:35 +0000 Subject: [M3devel] question on File.Status.size I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. I've run into some new build errors and have a question. It seems the type of File.Status.size has been changed to LONGCARD. I have some code that now fails to build because of this change. I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). So, for example: fs := FS.Status(file); INC(numBytes, fs.size); no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? (Interface File uses open arrays) In my old language definition, it says that: An open array type declaration has the form: TYPE T = ARRAY OF Element where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 30 20:25:52 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Sep 2013 14:25:52 -0400 Subject: [M3devel] question on File.Status.size In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF37B15@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF37B15@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <5BF38A01-A76E-4110-BE24-92A36F55E5DC@cs.purdue.edu> Why would size of a file necessarily be CARDINAL if that is not sufficient for the OS. For example, if off_t is not the same as CARDINAL then we have problems supporting POSIX files. Hence the need for LONGCARD. And I don?t understand why the size of a file should relate to NUMBER unless you are assuming that you can allocate an array to hold an entire file?s contents. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Sep 30, 2013, at 1:38 PM, "Coleburn, Randy" wrote: > Whether it is signed or not, to me it only makes sense that both the size of a file and NUMBER(x) are always semantically a CARDINAL type, i.e., >= 0. > --Randy Coleburn > > From: Tony Hosking [mailto:hosking at cs.purdue.edu] > Sent: Monday, September 30, 2013 11:46 AM > To: Coleburn, Randy > Cc: Jay K; m3devel > Subject: EXT:Re: [M3devel] question on File.Status.size > > Indeed, I wonder if it should be Long.T instead of LONGCARD, because I am uneasy with the assumption that the representation might not change. > (I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.) > Now, on the other hand, POSIX specifies file sizes to be off_t, which is signed, whereas Long.T is meant to be thought of as unsigned. > > So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense. > > On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" wrote: > > > I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER? > > If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). > > I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. > > Thanks, > Randy Coleburn > > Sent from my iPhone > > On Sep 30, 2013, at 12:48 AM, "Jay K" wrote: > > > NUMBER(array) to yield a LONGCARD > > This can't be. > Arrays are in-memory data structures. > INTEGER/CARDINAL are an appropriate type > to hold the size of something fits in memory/address-space. > INTEGER is like C's ptrdiff_t. > CARDINAL is kind of like C's size_t, except it is half range. > Word.T is kind of like C's size_t, except it has no convenient in-fix operators. > > > Files commonly do not fit in memory/address-space. > So they arguably should have their size stored > in a larger type. > > > I think there is no easy answer here. > > > I would be ok with: > - put it back to INTEGER/CARDINAL > - expose another way new way to get a LONGCARD > > > - Jay > > > > > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Sun, 29 Sep 2013 22:59:35 +0000 > Subject: [M3devel] question on File.Status.size > > I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. > > I've run into some new build errors and have a question. > > It seems the type of File.Status.size has been changed to LONGCARD. > > I have some code that now fails to build because of this change. > > I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). > > So, for example: > fs := FS.Status(file); > INC(numBytes, fs.size); > no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. > > Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? > (Interface File uses open arrays) > > In my old language definition, it says that: > An open array type declaration has the form: > TYPE T = ARRAY OF Element > where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. > In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. > > How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? > > Thanks, > Randy Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielal.benavides at bancoagrario.gov.co Mon Sep 30 20:14:39 2013 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Mon, 30 Sep 2013 18:14:39 +0000 Subject: [M3devel] question on File.Status.size In-Reply-To: <26D73256-5314-4EB1-BB92-64088BA0386C@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL>, <176E8593-3667-4CC6-BFEB-98F3E949F592@SCIRES.COM> <26D73256-5314-4EB1-BB92-64088BA0386C@cs.purdue.edu> Message-ID: <1AF4998819C60A40A4CD8C3B6582D3DA3F10C855@DRG008W8SMBX014.bancoagrario.gov.co> Hi all: BTW, tis brings back the issue of LONGADDRESS, since such a type would allow implementation of LONGINT subranges ordinal types. The VAX9000 which had a very orthogonal ISA, had the extended address bus and addressing of34 bits, in a 32-bit CPU. So technically, it wouldn't be orthogonal to not implement all ordinal types INTEGER subranges. Modula-3 type systems is orthogonal by definition (at least). It also brings back a proposal I sketched some time ago about of width subtyping LONGINT and WIDECHAR of INTEGER and CHAR types correspondingly . Thanks in advance De: Tony Hosking [mailto:hosking at cs.purdue.edu] Enviado el: Monday, 30 de September de 2013 10:46 a.m. Para: Coleburn, Randy CC: m3devel; Jay K Asunto: Re: [M3devel] question on File.Status.size Indeed, I wonder if it should be Long.T instead of LONGCARD, because I am uneasy with the assumption that the representation might not change. (I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.) Now, on the other hand, POSIX specifies file sizes to be off_t, which is signed, whereas Long.T is meant to be thought of as unsigned. So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense. On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" > wrote: I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER? If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. Thanks, Randy Coleburn Sent from my iPhone On Sep 30, 2013, at 12:48 AM, "Jay K" > wrote: > NUMBER(array) to yield a LONGCARD This can't be. Arrays are in-memory data structures. INTEGER/CARDINAL are an appropriate type to hold the size of something fits in memory/address-space. INTEGER is like C's ptrdiff_t. CARDINAL is kind of like C's size_t, except it is half range. Word.T is kind of like C's size_t, except it has no convenient in-fix operators. Files commonly do not fit in memory/address-space. So they arguably should have their size stored in a larger type. I think there is no easy answer here. I would be ok with: - put it back to INTEGER/CARDINAL - expose another way new way to get a LONGCARD - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Sun, 29 Sep 2013 22:59:35 +0000 Subject: [M3devel] question on File.Status.size I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. I've run into some new build errors and have a question. It seems the type of File.Status.size has been changed to LONGCARD. I have some code that now fails to build because of this change. I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). So, for example: fs := FS.Status(file); INC(numBytes, fs.size); no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? (Interface File uses open arrays) In my old language definition, it says that: An open array type declaration has the form: TYPE T = ARRAY OF Element where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Sep 30 21:58:05 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 30 Sep 2013 19:58:05 +0000 Subject: [M3devel] question on File.Status.size Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF37EAE@ATLEX04-SRV.SCIRES.LOCAL> Sorry for my lack of precision in what I wrote earlier. The point I was trying to make earlier is that the result of NUMBER(), and the size of a file, both are semantically non-negative. Whether that value is stored as a CARDINAL or a LONGCARD (or INTEGER vs LONGINT, even though the value should always be non-negative) is a matter of the range needed. As for the relation between the two wrt files, I was simply noting that the File and FS INTERFACEs in the past dealt with FS.Status.size and NUMBER() both having the same range (with respect to the open arrays passed thru the INTERFACES). Now that FS.Status.size has a greater range (namely, LONGCARD), client code that previously dealt with the smaller range has to be updated. For example, if I'm counting bytes read, I now have a potentially larger number LONGCARD vs CARDINAL to deal with, or if I'm allocating buffers to hold data being read/written, these buffers now have to deal with potentially much greater amount of data, thereby also needing new mechanisms to deal with this much larger data in an efficient way. Thanks, Randy Coleburn From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Monday, September 30, 2013 2:26 PM To: Coleburn, Randy Cc: m3devel Subject: EXT:Re: [M3devel] question on File.Status.size Why would size of a file necessarily be CARDINAL if that is not sufficient for the OS. For example, if off_t is not the same as CARDINAL then we have problems supporting POSIX files. Hence the need for LONGCARD. And I don't understand why the size of a file should relate to NUMBER unless you are assuming that you can allocate an array to hold an entire file's contents. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Sep 30, 2013, at 1:38 PM, "Coleburn, Randy" > wrote: Whether it is signed or not, to me it only makes sense that both the size of a file and NUMBER(x) are always semantically a CARDINAL type, i.e., >= 0. --Randy Coleburn From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Monday, September 30, 2013 11:46 AM To: Coleburn, Randy Cc: Jay K; m3devel Subject: EXT:Re: [M3devel] question on File.Status.size Indeed, I wonder if it should be Long.T instead of LONGCARD, because I am uneasy with the assumption that the representation might not change. (I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.) Now, on the other hand, POSIX specifies file sizes to be off_t, which is signed, whereas Long.T is meant to be thought of as unsigned. So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense. On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" > wrote: I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER? If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. Thanks, Randy Coleburn Sent from my iPhone On Sep 30, 2013, at 12:48 AM, "Jay K" > wrote: > NUMBER(array) to yield a LONGCARD This can't be. Arrays are in-memory data structures. INTEGER/CARDINAL are an appropriate type to hold the size of something fits in memory/address-space. INTEGER is like C's ptrdiff_t. CARDINAL is kind of like C's size_t, except it is half range. Word.T is kind of like C's size_t, except it has no convenient in-fix operators. Files commonly do not fit in memory/address-space. So they arguably should have their size stored in a larger type. I think there is no easy answer here. I would be ok with: - put it back to INTEGER/CARDINAL - expose another way new way to get a LONGCARD - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Sun, 29 Sep 2013 22:59:35 +0000 Subject: [M3devel] question on File.Status.size I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch. I've run into some new build errors and have a question. It seems the type of File.Status.size has been changed to LONGCARD. I have some code that now fails to build because of this change. I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL). So, for example: fs := FS.Status(file); INC(numBytes, fs.size); no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code. Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ? (Interface File uses open arrays) In my old language definition, it says that: An open array type declaration has the form: TYPE T = ARRAY OF Element where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array. In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base. How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 1 00:07:32 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 31 Aug 2013 22:07:32 +0000 Subject: [M3devel] need some help with linker error In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0CD60@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0CD60@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Python 3.x is very incompatible with Python 2.x. That is one of the worst things about Python imho -- they don't take compatibility seriously. Please use 2.x. I'll see if I can form the code to be valid for both 2.x and 3.x but I'm not hopeful. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] need some help with linker error Date: Sat, 31 Aug 2013 21:41:43 +0000 Jay: I am using Python v 3.3.0. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Saturday, August 31, 2013 11:59 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] need some help with linker error What version of Python? Maybe too old? upgrade (i.e. your cmd) needs to include, not skip, mklib. Compare it to the others. The fix was in mklib and your cmd varies in this respect. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com CC: jay.krell at cornell.edu Subject: RE: [M3devel] need some help with linker error Date: Sat, 31 Aug 2013 14:59:21 +0000 Jay: I tried upgrade.py, without success. Here are the results: C:\cm3\Sandbox\scripts\python>python upgrade.py Traceback (most recent call last): File "upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\scripts\python\pylib.py", line 900 PackageDB = (PackageDB or map(lambda(a): a.replace("\n", "").replace('\\', '/').replace("\r", ""), open(PKGSDB))) ^ SyntaxError: invalid syntax I?m not familiar with python, so I?m not in a position to debug what is wrong. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Friday, August 30, 2013 6:07 PM To: Coleburn, Randy Subject: EXT:RE: [M3devel] need some help with linker error RCC_upgradeCM3.cmd looks incorrect. Please try upgrade.py. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu Subject: RE: [M3devel] need some help with linker error Date: Fri, 30 Aug 2013 20:06:13 +0000 No, I ran my batch/CMD scripts, but these are based on what you had described previously as the correct steps. Is there a new dependency or step I need to be aware of? --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Friday, August 30, 2013 3:46 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] need some help with linker error Did you run upgrade.py? - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Fri, 30 Aug 2013 16:12:32 +0000 Subject: Re: [M3devel] need some help with linker error Jay: I appreciate your help. I just updated via CVS to get all your latest changes, but I am still getting the error with non-unique match for _xmm. See below: ? msvcrt.lib m3core.def : warning LNK4022: cannot find unique match for symbol '_xmm' m3core.def : warning LNK4002: __xmm at 41f00000000000000000000000000000 defined in dtoa.obj m3core.def : warning LNK4002: __xmm at 80000000000000008000000000000000 defined in dtoa.obj m3core.def : error LNK2001: unresolved external symbol _xmm m3core.lib : fatal error LNK1120: 1 unresolved externals Can you point me in the right direction to solve this problem? Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, August 27, 2013 11:28 AM To: Rodney M. Bates; m3devel Subject: EXT:Re: [M3devel] need some help with linker error This is fixed now too. Dragisha had introduced heap corruption in FSWin32.m3 trying to improve Unicode support. - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 27 Aug 2013 14:55:13 +0000 Subject: Re: [M3devel] need some help with linker error Hm. That leaves me with: +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 +++ --- building in NT386 --- ignoring ..\src\m3overrides *** *** runtime error: *** Attempt to reference an illegal memory location. *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x14efe0 0x11bdadb SystemError + 0x64 in ..\src\runtime\NT386\RTSignal.m3 0x14f028 0x76f22d94 0x14f040 0x76f22ce8 0x14f054 0x759bc3d4 0x14f068 0x6302dcc2 0x14f074 0x11bbe02 Cstdlib_I3 + 0x1a2 in ..\src\C\Common\Cstdlib.i3 0x14f088 0x11a7925 DisposeUntracedRef + 0x2c in ..\src\runtime\common\RTAlloc ator.m3 0x14f09c 0x11a1687 DelCriticalSection + 0x2d in ..\src\thread\WIN32\ThreadWin 32.m3 0x14f0b8 0x11a161a CleanMutex + 0x89 in ..\src\thread\WIN32\ThreadWin32.m3 0x14f0ec 0x1196371 PostHandleWeakRefs + 0x2ae in ..\src\runtime\common\RTColl ector.m3 ......... ......... ... more frames ... *** execution of [, ] failed *** Not good. - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 27 Aug 2013 09:07:25 +0000 Subject: Re: [M3devel] need some help with linker error I updated m3-sys/mklib to ignore these. Let me know if there are any more problems. Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Tue, 27 Aug 2013 06:43:53 +0000 Subject: Re: [M3devel] need some help with linker error > Is there a chance both are getting linked in? No. There is no chance of this. > Or one from the modula-3 distribution, and one already in some MS-supplied > library? No. There is no chance of this either. I forget how we generate the .def file but we need to exclude names "like" this -- that start _xmm at . These are floating point constants for code that uses sse2. You are targeting 32bit, right? Still, I guess these might occur, with newer compilers. I'll look into it. We already have to code exclude the older forms of floating point constants. - Jay > Date: Mon, 26 Aug 2013 20:03:20 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] need some help with linker error > > This is just a wild guess, but there are two dtoa.c files, in > > m3-libs/m3core/src/Csupport/little-endian/dtoa.c and > m3-libs/m3core/src/Csupport/big-endian/dtoa.c > > No doubt they are alternatives. Is there a chance both are getting linked in? > Or one from the modula-3 distribution, and one already in some MS-supplied > library? > > On 08/26/2013 07:49 PM, Coleburn, Randy wrote: > > Jay: > > > > I?m getting errors trying to rebuild m3core.lib on Win7-64bit. Specifically, see below the error I get from the Microsoft Linker. > > > > The full text of the m3core.lst file is also shown at the end of this message. > > > > msvcrt.lib > > > > m3core.def : warning LNK4022: cannot find unique match for symbol '_xmm' > > > > m3core.def : warning LNK4002: __xmm at 41f00000000000000000000000000000 defined in dtoa.obj > > > > m3core.def : warning LNK4002: __xmm at 80000000000000008000000000000000 defined in dtoa.obj > > > > m3core.def : error LNK2001: unresolved external symbol _xmm > > > > m3core.lib : fatal error LNK1120: 1 unresolved externals > > > > Any ideas on what I should do to resolve this problem? > > > > Thanks, > > > > Randy Coleburn > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 1 05:05:13 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 03:05:13 +0000 Subject: [M3devel] another size/alignment/interop problem.. Message-ID: TYPE FILETIME = RECORD dwLowDateTime : uint32_t; dwHighDateTime: uint32_t; END; BY_HANDLE_FILE_INFORMATION = RECORD dwFileAttributes : uint32_t; ftCreationTime : FILETIME; (* This should be at offset 4 but is 8 on 64bit systems. *) (* the rest omitted *) END; Why doesn't that just work? It works with: TYPE FILETIME = BITS 64 FOR RECORD but imho it should work without that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Sep 1 09:31:47 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Sep 2013 09:31:47 +0200 Subject: [M3devel] Git migration Message-ID: <6433EF8B-83A9-4FEE-A626-ADC25C8C689E@m3w.org> Hi all, I would like to initiate final conversion/migration of repository to Git. As per widely accepted guidelines for such migrations - here is a question to stakeholders (I suppose it means people on this list :) ): Does anybody have any questions/reasonable doubts about this migration? My plan is to collect feedback, prepare workflow equivalents for current CVS workflows, and do all the work "atomically" one day of this September. Please feel free to send your specific concerns/wishes both here and privately to me. TIA, dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Sun Sep 1 09:42:22 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 07:42:22 +0000 Subject: [M3devel] cm3 -DTARGET=foo In-Reply-To: References: Message-ID: I forgot and it is worth reminding everyone: CM3_TARGET=foo cm3 does work in sh/bash/Posix Given config files and everything else. We do have such config files. "everything else" means cooperative cc/ld. At the very least, it is good for "biarch" systems: CM3_TARGET=I386_DARWIN cm3 CM3_TARGET=AMD64_DARWIN cm3 For these cases though, we should probably take a hint from others: cm3 -64 cm3 --64 cm3 -m64 (andy number of dashes, followed by optional m, followed by 32 or 64 guides target toward 32bit or 64bit variant of host or default target) also CM3_TARGET=arbitrary cm3 -boot But there should be a command line option besides the environment. Appe's gcc is also nice, switches like -arch ppc -arch x86 etc. Anyway, not a big deal.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: cm3 -DTARGET=foo Date: Fri, 30 Aug 2013 06:02:41 +0000 I'd like the above to work. Or cm3 -target=foo or -target:foo. The underlying implementation would be "like" -DTARGET=foo. This doesn't work due to the order of evaluation, command line vs. config file vs. -D written to a file. I don't have the change yet. Any objection to the intent? I wonder if it might subtlely reorder things though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Sep 1 23:54:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Sep 2013 16:54:22 -0500 Subject: [M3devel] how to write constants? In-Reply-To: References: Message-ID: <5223B78E.5000901@lcwb.coop> On 08/31/2013 01:17 AM, Jay K wrote: > What is the right way to do this for 64bit systems? I presume you mean so it works on both 32-bit and 64-but? > > other : INT32 = 16_FFFFFFFF; > > > "../src/win32/WinUser.i3", line 1321: warning: value not assignable (range fault) > WS_POPUP : INT32 = 16_80000000; > > "../src/win32/WinVer.i3", line 37: warning: value not assignable (range fault) > VS_FFI_SIGNATURE : INT32 = 16_FEEF04BD; > > > I'm guessing.. > other : INT32 := -1; Yes, assuming this is the same INT32 as the other two cases (a subrange covering 32-bit signed twos-complement. (I couldn't find this declaration, thus nor its INT32 type.) > WS_POPUP = FIRST(INT32) That will work. Ultimately, the buck has to stop being passed, and following more levels of transitive type renaming than I want to count, I see the type defined as [-16_7fffffff-1 .. 16_7fffffff], whose lower bound is the way I would have done it as a ground constant. I see two different BasicCTypes.i3 versions, inside subdirectories 32BITS and 64BITS, but this decl is the same in both. > VS_FFI_SIGNATURE : INT32 = -17890115; (* 16_FEEF04BD *) > Works, but tedious to hand-compute and to double-check consistency with the comment. How about 16_FEEF04BD-16FFFFFFFF-1? Does it seem odd that numbers like this in the upper-half unsigned range are being given to a signed type? > > ? > > - Jay From rodney_bates at lcwb.coop Mon Sep 2 00:07:31 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Sep 2013 17:07:31 -0500 Subject: [M3devel] another size/alignment/interop problem.. In-Reply-To: References: Message-ID: <5223BAA3.8040404@lcwb.coop> On 08/31/2013 10:05 PM, Jay K wrote: > TYPE FILETIME = RECORD > dwLowDateTime : uint32_t; > dwHighDateTime: uint32_t; > END; > > BY_HANDLE_FILE_INFORMATION = RECORD > dwFileAttributes : uint32_t; > ftCreationTime : FILETIME; (* This should be at offset 4 but is 8 on 64bit systems. *) > (* the rest omitted *) > END; > > > Why doesn't that just work? The only explanation I can think of is that the compiler gave record type FILETIME 64-bit alignment. As far as I know, there is nothing in the language that says it is not perfectly within its rights to do so. Why is another question. > It works with: > TYPE FILETIME = BITS 64 FOR RECORD > Which is consistent with the language, if it doesn't refuse altogether. > > but imho it should work without that. > > > - Jay > > From jay.krell at cornell.edu Mon Sep 2 00:46:07 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 22:46:07 +0000 Subject: [M3devel] another size/alignment/interop problem.. In-Reply-To: <5223BAA3.8040404@lcwb.coop> References: , <5223BAA3.8040404@lcwb.coop> Message-ID: We require some degree of C interop, so we require some degree of predictable layout. What we have falls below my expectations, but perhaps if it is explained to me, it won't any longer. Well, I guess we don't really require any predictable layout. I can give up on records for any interop and rely strictly on integer and pointer parameters. Or, well, I can do like for Posix and use a small copying layer and smush out anything vaguely unclear like this... - Jay > Date: Sun, 1 Sep 2013 17:07:31 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] another size/alignment/interop problem.. > > > > On 08/31/2013 10:05 PM, Jay K wrote: > > TYPE FILETIME = RECORD > > dwLowDateTime : uint32_t; > > dwHighDateTime: uint32_t; > > END; > > > > BY_HANDLE_FILE_INFORMATION = RECORD > > dwFileAttributes : uint32_t; > > ftCreationTime : FILETIME; (* This should be at offset 4 but is 8 on 64bit systems. *) > > (* the rest omitted *) > > END; > > > > > > Why doesn't that just work? > > The only explanation I can think of is that the compiler gave record type FILETIME > 64-bit alignment. As far as I know, there is nothing in the language that says it > is not perfectly within its rights to do so. Why is another question. > > > > It works with: > > TYPE FILETIME = BITS 64 FOR RECORD > > > > Which is consistent with the language, if it doesn't refuse altogether. > > > > but imho it should work without that. > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 2 00:51:35 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Sep 2013 22:51:35 +0000 Subject: [M3devel] how to write constants? In-Reply-To: <5223B78E.5000901@lcwb.coop> References: , <5223B78E.5000901@lcwb.coop> Message-ID: > I presume you mean so it works on both 32-bit and 64-bit? There should be no doubt that almost everything should. Yes. > > VS_FFI_SIGNATURE : INT32 = -17890115; (* 16_FEEF04BD *) > > > > Works, but tedious to hand-compute and to double-check consistency with > the comment. How about 16_FEEF04BD-16FFFFFFFF-1? I can try that. I couldn't hand compute it. I gave up and used a reliable calculator: #include int main() { printf("%d\n", 0xFEEF04BD); return 0; } but yeah, something obviously correct by inspection would be nice. Notice that I can't use Word or Long to help compute such constants. I kinda think we need a Word32 interface (and Long should then have been called Word64). > Does it seem odd that numbers like this in the upper-half unsigned range > are being given to a signed type? Sure, but, maybe I'm confused, but we don't have this upper-half in our unsigned types either. I can try foo: UINT32 = 16_FFFFFFFF or 16_FEEF04BD or such. We also had I think negative numbers assigned to unsigned types. - Jay > Date: Sun, 1 Sep 2013 16:54:22 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] how to write constants? > > > > On 08/31/2013 01:17 AM, Jay K wrote: > > What is the right way to do this for 64bit systems? > > I presume you mean so it works on both 32-bit and 64-but? > > > > > other : INT32 = 16_FFFFFFFF; > > > > > > "../src/win32/WinUser.i3", line 1321: warning: value not assignable (range fault) > > WS_POPUP : INT32 = 16_80000000; > > > > "../src/win32/WinVer.i3", line 37: warning: value not assignable (range fault) > > VS_FFI_SIGNATURE : INT32 = 16_FEEF04BD; > > > > > > I'm guessing.. > > other : INT32 := -1; > > Yes, assuming this is the same INT32 as the other two cases (a subrange > covering 32-bit signed twos-complement. (I couldn't find this declaration, > thus nor its INT32 type.) > > > WS_POPUP = FIRST(INT32) > > That will work. Ultimately, the buck has to stop being passed, and > following more levels of transitive type renaming than I want to count, > I see the type defined as [-16_7fffffff-1 .. 16_7fffffff], whose lower > bound is the way I would have done it as a ground constant. > > I see two different BasicCTypes.i3 versions, inside subdirectories > 32BITS and 64BITS, but this decl is the same in both. > > > VS_FFI_SIGNATURE : INT32 = -17890115; (* 16_FEEF04BD *) > > > > Works, but tedious to hand-compute and to double-check consistency with > the comment. How about 16_FEEF04BD-16FFFFFFFF-1? > > Does it seem odd that numbers like this in the upper-half unsigned range > are being given to a signed type? > > > > > ? > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 07:53:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 05:53:56 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Message-ID: I've complained about this before. The frontend keeps track of things in bits in INTEGER. Therefore TextLiteral.MaxBytes is around 512MB. We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. Fixing this mostly but not entirely would be to plumb through LONGINT "everywhere" instead of INTEGER. We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. So we'd have a 60 bit limit instead of a 64bit limit. Fixing it even more would require Target.Int. Thoughts? Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? Do we still require bootstrapping from LONGINT-less compilers? Any lingering doubts as to its syntax and meaning? I still think it should be named INT64. Because in the future I want INT128 and I don't want LONGINT to grow in size. Would it be considered adequate as a replacement for Target.Int? If instead I plumb through Target.Int, any complaints? Target.Int has the following advantages: When we need INT128 in the future, it is a very very very simple and small change. I already extended Target.Int from 64 bits to 72 bits. It works with old frontends. Target.Int has the following disadvantages: no operator overloading so usage is cumbersome slower I still don't fully understand it, e.g. division - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 08:02:52 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 06:02:52 +0000 Subject: [M3devel] TextLiteral.MaxBytes again Message-ID: ok, another question: CONST (* DIV BITSIZE should not be here! *) (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); TYPE T = RTHooks.TextLiteral; REVEAL T = TEXT BRANDED "TextLiteral.T" OBJECT cnt : INTEGER; buf : ARRAY [0..MaxBytes - 1] OF Byte; OVERRIDES ... T is a reference type. Is there a way to state this with no limit? Isn't it already unsafe? You know -- the array is usually smaller and the compiler is only going to check against this large size. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 08:54:45 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 06:54:45 +0000 Subject: [M3devel] FW: rc or windres? In-Reply-To: <20130903064906.DF5CA5DEB73@birch.elegosoft.com> References: <20130903064906.DF5CA5DEB73@birch.elegosoft.com> Message-ID: Anyone else want to tackle this? Windres is what you would likely use in a Cygwin environment. And maybe MinGW. But not an "MS" environment. It isn't the target per-se, it is more about the "host tools". How about config file says: WINDOWS_RESOURCE_COMPILER = "rc" or WINDOWS_RESOURCE_COMPILER = "windres" ? or USE_RC = TRUE vs. USE_WINDRES = TRUE? or maybe we can try running each and use whatever works? I had windres on my path and it ran, and failed. I think because of backslashes in paths. It also ran gcc as part of its work, which I also had in the path. I had these mainly because Cygwin provides cvs/ssh. I'm actually using the Microsoft compiler/linker/rc. I guess supposed AMD64_CYGWIN and AMD64_MINGW are next in line as targets, using the C backend.. Though I also doubt if anyone here uses them. Thank you, - Jay > Date: Tue, 3 Sep 2013 08:49:06 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/09/03 08:49:06 > > Modified files: > cm3/m3-sys/windowsResources/src/: winRes.tmpl > > Log message: > This file uses rc for backend mode 0 and windres otherwise. > Change it to also use rc backend mode C. > This all seems wrong. > windres is a Cygwin tool. > rc is a Microsoft tool. > windres probably works "cross", though that is probably rare. > > This should probably be lifted all the way up to the config files. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 09:12:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 07:12:17 +0000 Subject: [M3devel] why record with two int32's gets alignment 64? In-Reply-To: <20130903060538.433F15DEB73@birch.elegosoft.com> References: <20130903060538.433F15DEB73@birch.elegosoft.com> Message-ID: help? Thanks, - Jay > Date: Tue, 3 Sep 2013 08:05:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/09/03 08:05:38 > > Modified files: > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message: > add BITS 64 FOR on FILETIME > I don't understand the frontend layout rules and I think the fix > might be there instead! > > But hey this did expose tiny missing logic in C backend.. > packed records weren't considered records and weren't being passed/recieved > as parameters/return values succesfully -- the C would fail to compile, nice error mode! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 3 14:13:33 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Sep 2013 08:13:33 -0400 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: References: Message-ID: <67681FED-F7BE-41F6-A1D8-70FCEAE50493@cs.purdue.edu> Who would ever create a text literal that exceeds MaxBytes? Sent from my iPad On Sep 3, 2013, at 2:02 AM, Jay K wrote: > ok, another question: > > > CONST > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > TYPE > T = RTHooks.TextLiteral; > REVEAL > T = TEXT BRANDED "TextLiteral.T" OBJECT > cnt : INTEGER; > buf : ARRAY [0..MaxBytes - 1] OF Byte; > OVERRIDES ... > > > T is a reference type. > Is there a way to state this with no limit? > > > Isn't it already unsafe? > You know -- the array is usually smaller and the compiler is only going to check against this large size. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Sep 3 16:04:43 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 3 Sep 2013 14:04:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0F326@ATLEX04-SRV.SCIRES.LOCAL> Jay: "windowsResources" is very Microsoft-specific, and there is no dependency on cygwin. We put this in to allow for packaging of things like icon files, etc. on Microsoft Windows targets. "rc" is the Microsoft Resource Compiler. I know that I have a number of programs that depend on this package. I haven't looked at your change yet; I just saw the commit log message. --Randy Coleburn -----Original Message----- From: Jay Krell [mailto:jkrell at elego.de] Sent: Tuesday, September 03, 2013 4:49 AM To: m3commit at elegosoft.com Subject: EXT:[M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 13/09/03 08:49:06 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: This file uses rc for backend mode 0 and windres otherwise. Change it to also use rc backend mode C. This all seems wrong. windres is a Cygwin tool. rc is a Microsoft tool. windres probably works "cross", though that is probably rare. This should probably be lifted all the way up to the config files. From jay.krell at cornell.edu Tue Sep 3 18:06:57 2013 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Sep 2013 09:06:57 -0700 Subject: [M3devel] AMD64_NT Message-ID: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> AMD_NT runs, can build itself, is more debuggable than NT386, Juno & formsedit come up. It was a fairly quick straightforward use of the C backend. There is a problem in m3core/Time that hangs mentor startup. The first time I ran cm3ide it brought up IE but hit an out-of-range in socket code. Elego code failed to build due to lack of c:\cygwin (I have c:\cygwin64). There is a problem in exception handling worked around using libcmt.lib instead of msvcr*.dll. The unsafe out of date cloned headers have as usual been a source of bugs. I'll try to get a snapshot out soon. Adventurous folks can try it already. - Jay From jay.krell at cornell.edu Tue Sep 3 18:55:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 16:55:56 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> References: , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> Message-ID: How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? double? That offers I think 53 bits, which is pretty good, but pesky floating point.. A library without infix notation? C and C++ have been using __int64 and long long for this for going on 20 years. And C++ has infix notation for arbitrary types. I guess I will plumb Target.Int through? I've started this before but it got tedious. - Jay CC: m3devel at elegosoft.com From: antony.hosking at gmail.com Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Date: Tue, 3 Sep 2013 08:11:32 -0400 To: jay.krell at cornell.edu Don't plumb LONGINT throughout. I still consider it an abomination. Sent from my iPad On Sep 3, 2013, at 1:53 AM, Jay K wrote: I've complained about this before. The frontend keeps track of things in bits in INTEGER. Therefore TextLiteral.MaxBytes is around 512MB. We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. Fixing this mostly but not entirely would be to plumb through LONGINT "everywhere" instead of INTEGER. We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. So we'd have a 60 bit limit instead of a 64bit limit. Fixing it even more would require Target.Int. Thoughts? Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? Do we still require bootstrapping from LONGINT-less compilers? Any lingering doubts as to its syntax and meaning? I still think it should be named INT64. Because in the future I want INT128 and I don't want LONGINT to grow in size. Would it be considered adequate as a replacement for Target.Int? If instead I plumb through Target.Int, any complaints? Target.Int has the following advantages: When we need INT128 in the future, it is a very very very simple and small change. I already extended Target.Int from 64 bits to 72 bits. It works with old frontends. Target.Int has the following disadvantages: no operator overloading so usage is cumbersome slower I still don't fully understand it, e.g. division - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 3 19:00:08 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Sep 2013 13:00:08 -0400 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> Message-ID: <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Yes, I want to avoid use of LONGINT in the compiler proper. If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. But I still don?t understand the precise use-case that you are proposing. In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? I cannot imaging a text literal that big, ever. On Sep 3, 2013, at 12:55 PM, Jay K wrote: > How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? > double? That offers I think 53 bits, which is pretty good, but pesky floating point.. > A library without infix notation? > C and C++ have been using __int64 and long long for this for going on 20 years. > And C++ has infix notation for arbitrary types. > > > I guess I will plumb Target.Int through? > I've started this before but it got tedious. > > > - Jay > > CC: m3devel at elegosoft.com > From: antony.hosking at gmail.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > Date: Tue, 3 Sep 2013 08:11:32 -0400 > To: jay.krell at cornell.edu > > Don't plumb LONGINT throughout. I still consider it an abomination. > > Sent from my iPad > > On Sep 3, 2013, at 1:53 AM, Jay K wrote: > > I've complained about this before. > > > The frontend keeps track of things in bits in INTEGER. > Therefore TextLiteral.MaxBytes is around 512MB. > > > We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. > > > Fixing this mostly but not entirely would be to plumb through LONGINT > "everywhere" instead of INTEGER. > We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. > So we'd have a 60 bit limit instead of a 64bit limit. > > > Fixing it even more would require Target.Int. > > > Thoughts? > > > Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? > Do we still require bootstrapping from LONGINT-less compilers? > > > Any lingering doubts as to its syntax and meaning? > I still think it should be named INT64. > Because in the future I want INT128 and I don't want LONGINT to grow in size. > > > Would it be considered adequate as a replacement for Target.Int? > > > If instead I plumb through Target.Int, any complaints? > Target.Int has the following advantages: > When we need INT128 in the future, it is a very very very simple and small change. > I already extended Target.Int from 64 bits to 72 bits. > It works with old frontends. > > > Target.Int has the following disadvantages: > no operator overloading so usage is cumbersome > slower > I still don't fully understand it, e.g. division > > > > - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 19:50:01 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 17:50:01 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> References: , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Message-ID: I think it isn't just TextLiteral.MaxBytes. How do I declare an unbouned-ly sized array? At the end of a record? Doesn't matter? For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? - Jay From: hosking at cs.purdue.edu Date: Tue, 3 Sep 2013 13:00:08 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Yes, I want to avoid use of LONGINT in the compiler proper.If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose.But I still don?t understand the precise use-case that you are proposing.In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small?I cannot imaging a text literal that big, ever. On Sep 3, 2013, at 12:55 PM, Jay K wrote:How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? double? That offers I think 53 bits, which is pretty good, but pesky floating point.. A library without infix notation? C and C++ have been using __int64 and long long for this for going on 20 years. And C++ has infix notation for arbitrary types. I guess I will plumb Target.Int through? I've started this before but it got tedious. - Jay CC: m3devel at elegosoft.com From: antony.hosking at gmail.com Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? Date: Tue, 3 Sep 2013 08:11:32 -0400 To: jay.krell at cornell.edu Don't plumb LONGINT throughout. I still consider it an abomination. Sent from my iPad On Sep 3, 2013, at 1:53 AM, Jay K wrote: I've complained about this before. The frontend keeps track of things in bits in INTEGER. Therefore TextLiteral.MaxBytes is around 512MB. We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. Fixing this mostly but not entirely would be to plumb through LONGINT "everywhere" instead of INTEGER. We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. So we'd have a 60 bit limit instead of a 64bit limit. Fixing it even more would require Target.Int. Thoughts? Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? Do we still require bootstrapping from LONGINT-less compilers? Any lingering doubts as to its syntax and meaning? I still think it should be named INT64. Because in the future I want INT128 and I don't want LONGINT to grow in size. Would it be considered adequate as a replacement for Target.Int? If instead I plumb through Target.Int, any complaints? Target.Int has the following advantages: When we need INT128 in the future, it is a very very very simple and small change. I already extended Target.Int from 64 bits to 72 bits. It works with old frontends. Target.Int has the following disadvantages: no operator overloading so usage is cumbersome slower I still don't fully understand it, e.g. division - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 3 19:53:08 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Sep 2013 17:53:08 +0000 Subject: [M3devel] rc vs. windres In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0F326@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF0F326@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: > "windowsResources" is very Microsoft-specific, and there is no dependency on cygwin. Yes there is. As the commit says -- the code checks "backend mode" and uses rc for 0, windres otherwise, windres being a Cygwin tool. I changed it so backend mode C also uses rc. I think this probably belongs all the way up in the config files. Keeping in mind that it is a host-configuration aspect, not a target-specific one. We confuse those -- is "NT386GNU" a host or a target, or both? Does the compiler use cygwin1.dll, or the output, or both? In reality, these are separate matters. Cross compilation is rare, people confuse these matters all the time, and it rarely matters. - Jay > From: rcolebur at SCIRES.COM > To: jkrell at elego.de; m3devel at elegosoft.com > Date: Tue, 3 Sep 2013 14:04:43 +0000 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay: > > "windowsResources" is very Microsoft-specific, and there is no dependency on cygwin. > > We put this in to allow for packaging of things like icon files, etc. on Microsoft Windows targets. > > "rc" is the Microsoft Resource Compiler. > > I know that I have a number of programs that depend on this package. > > I haven't looked at your change yet; I just saw the commit log message. > > --Randy Coleburn > > -----Original Message----- > From: Jay Krell [mailto:jkrell at elego.de] > Sent: Tuesday, September 03, 2013 4:49 AM > To: m3commit at elegosoft.com > Subject: EXT:[M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/09/03 08:49:06 > > Modified files: > cm3/m3-sys/windowsResources/src/: winRes.tmpl > > Log message: > This file uses rc for backend mode 0 and windres otherwise. > Change it to also use rc backend mode C. > This all seems wrong. > windres is a Cygwin tool. > rc is a Microsoft tool. > windres probably works "cross", though that is probably rare. > > This should probably be lifted all the way up to the config files. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 3 22:12:32 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Sep 2013 16:12:32 -0400 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Message-ID: <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu> On Sep 3, 2013, at 1:50 PM, Jay K wrote: > I think it isn't just TextLiteral.MaxBytes. > > > How do I declare an unbouned-ly sized array? Can?t do in M3. It?s not type safe. > At the end of a record? > Doesn't matter? > > > For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? Can you really imagine typing a literal that is 512MB in length? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Tue, 3 Sep 2013 13:00:08 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > > Yes, I want to avoid use of LONGINT in the compiler proper. > If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. > But I still don?t understand the precise use-case that you are proposing. > In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? > I cannot imaging a text literal that big, ever. > > On Sep 3, 2013, at 12:55 PM, Jay K wrote: > > How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? > double? That offers I think 53 bits, which is pretty good, but pesky floating point.. > A library without infix notation? > C and C++ have been using __int64 and long long for this for going on 20 years. > And C++ has infix notation for arbitrary types. > > > I guess I will plumb Target.Int through? > I've started this before but it got tedious. > > > - Jay > > CC: m3devel at elegosoft.com > From: antony.hosking at gmail.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > Date: Tue, 3 Sep 2013 08:11:32 -0400 > To: jay.krell at cornell.edu > > Don't plumb LONGINT throughout. I still consider it an abomination. > > Sent from my iPad > > On Sep 3, 2013, at 1:53 AM, Jay K wrote: > > I've complained about this before. > > > The frontend keeps track of things in bits in INTEGER. > Therefore TextLiteral.MaxBytes is around 512MB. > > > We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. > > > Fixing this mostly but not entirely would be to plumb through LONGINT > "everywhere" instead of INTEGER. > We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. > So we'd have a 60 bit limit instead of a 64bit limit. > > > Fixing it even more would require Target.Int. > > > Thoughts? > > > Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? > Do we still require bootstrapping from LONGINT-less compilers? > > > Any lingering doubts as to its syntax and meaning? > I still think it should be named INT64. > Because in the future I want INT128 and I don't want LONGINT to grow in size. > > > Would it be considered adequate as a replacement for Target.Int? > > > If instead I plumb through Target.Int, any complaints? > Target.Int has the following advantages: > When we need INT128 in the future, it is a very very very simple and small change. > I already extended Target.Int from 64 bits to 72 bits. > It works with old frontends. > > > Target.Int has the following disadvantages: > no operator overloading so usage is cumbersome > slower > I still don't fully understand it, e.g. division > > > > - Jay > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 03:48:02 2013 From: jay.krell at cornell.edu (Jay) Date: Tue, 3 Sep 2013 18:48:02 -0700 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu> References: <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com> <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu> Message-ID: How about in unsafe code? Just untraced ref T? TextLiteral: ok I guess not. Can always break them up and concat them...compiler could do that. I'd like to have m3-sys/mklib just keep everything in memory. Less code & maybe faster. Thanks, - Jay On Sep 3, 2013, at 1:12 PM, Tony Hosking wrote: > On Sep 3, 2013, at 1:50 PM, Jay K wrote: > >> I think it isn't just TextLiteral.MaxBytes. >> >> >> How do I declare an unbouned-ly sized array? > > Can?t do in M3. It?s not type safe. > >> At the end of a record? >> Doesn't matter? >> >> >> For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? > > Can you really imagine typing a literal that is 512MB in length? > >> >> >> - Jay >> >> >> From: hosking at cs.purdue.edu >> Date: Tue, 3 Sep 2013 13:00:08 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? >> >> Yes, I want to avoid use of LONGINT in the compiler proper. >> If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. >> But I still don?t understand the precise use-case that you are proposing. >> In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? >> I cannot imaging a text literal that big, ever. >> >> On Sep 3, 2013, at 12:55 PM, Jay K wrote: >> >> How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets? >> double? That offers I think 53 bits, which is pretty good, but pesky floating point.. >> A library without infix notation? >> C and C++ have been using __int64 and long long for this for going on 20 years. >> And C++ has infix notation for arbitrary types. >> >> >> I guess I will plumb Target.Int through? >> I've started this before but it got tedious. >> >> >> - Jay >> >> CC: m3devel at elegosoft.com >> From: antony.hosking at gmail.com >> Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? >> Date: Tue, 3 Sep 2013 08:11:32 -0400 >> To: jay.krell at cornell.edu >> >> Don't plumb LONGINT throughout. I still consider it an abomination. >> >> Sent from my iPad >> >> On Sep 3, 2013, at 1:53 AM, Jay K wrote: >> >> I've complained about this before. >> >> >> The frontend keeps track of things in bits in INTEGER. >> Therefore TextLiteral.MaxBytes is around 512MB. >> >> >> We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail. >> >> >> Fixing this mostly but not entirely would be to plumb through LONGINT >> "everywhere" instead of INTEGER. >> We would still lose the sign bit and bits vs. bytes would lose us another 3 bits. >> So we'd have a 60 bit limit instead of a 64bit limit. >> >> >> Fixing it even more would require Target.Int. >> >> >> Thoughts? >> >> >> Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back? >> Do we still require bootstrapping from LONGINT-less compilers? >> >> >> Any lingering doubts as to its syntax and meaning? >> I still think it should be named INT64. >> Because in the future I want INT128 and I don't want LONGINT to grow in size. >> >> >> Would it be considered adequate as a replacement for Target.Int? >> >> >> If instead I plumb through Target.Int, any complaints? >> Target.Int has the following advantages: >> When we need INT128 in the future, it is a very very very simple and small change. >> I already extended Target.Int from 64 bits to 72 bits. >> It works with old frontends. >> >> >> Target.Int has the following disadvantages: >> no operator overloading so usage is cumbersome >> slower >> I still don't fully understand it, e.g. division >> >> >> >> - Jay >> >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Mobile +1 765 427 5484 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 08:28:18 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 06:28:18 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? Message-ID: AMD64_NT starting up mentor: *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\EventWireRep.m3", line 89 *** This opens up a big multi-part can of worms. I'm not sure the order to present things. Please bear with me. Background: Time.T is a double/longreal number of seconds since a platform-specific epoch. This cleverly gives I guess pretty good range and precison. On Windows, that is 1601. The underlying system stores 64bit 100s of nanoseconds. This gives both good range and precision. And it works ok with Modula-3. On Posix is presumably 1970. This is all ok. Not controversial. Corralaries: Time.Now on Windows returns around 1.3022747815483961e10. My simple math says that is off by a month but hopefully more precise math says it is exactly correct. We have confusing Modula-3 code and straightforward C code to compute this. That it is within a month seems adequate to backup everything else I'm seeing/saying. events!EventWireRep_M3 [c:\dev2\cm3\m3-comm\events\src\eventwirerep.m3 @ 90] Int32 = BITS 32 FOR [-2147483647-1..2147483647]; TRep = RECORD ts: Int32; objNum: Int32; space: EventSpaceID.T; END; VAR myTs: Int32 := ROUND(Time.Now()); Clearly this is a problem. It runs out "soon" on 32bit Posix systems, it runs out already on Win64, and on Win32, well, it produces garbage one way or another, but no range errors. On AMD64_NT, this reasonably rounds to 13022747815 -- the full integer value of the double fits in a 64bit integer. But it doesn't fit in 32 bits. On I386_NT, this somewhat "correctly" rounds to -2147483648 Hm. Shouldn't it be nearest integer 2147483647?? In either case, see you the problem. Ok, so this is three dilemnas/questions/bugs in one. http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arithmetic_operations.html ROUND(r) is the nearest integer to r; ties are broken according to the constant RoundDefault 1) How should ROUND be defined? Is Modula-3 adequately safe here? What should round of numbers less than FIRST(INTEGER)-1 or greater than LAST(INTEGER) + 1 round to? By the simple definition, they should round to FIRST(INTEGER) and LAST(INTEGER). But is it safe? You know, I can see taking the whole part of the number and losing the fractional part as being ok when desired, but when the whole part doesn't fit, not even when rounded up or down by 1? Doesn't that seem like it should be a range error? 2) What is up with the various implementations? ASSUMING Modula-3 ROUND is defined safely enough, is the integrated NT/x86 backend correct here? On I386_DARWIN: IMPORT IO, Fmt; BEGIN IO.Put(Fmt.Int(ROUND(1.3022747815483961e10)) & "\n"); END Main. We get: 137845760. Wow, that is just wrong. Sure it got the mantissa close, but the exponent is arbitrary seeming. I could chalk this up to a bug in my C backend, but it gets constant folded in the front end. The backend just gets load_integer 137845760. This seems highly incorrect. Maybe bugs in Target.Float? Maybe overflow is being ignored?? I'll look later, another day. 3) What to do? 3a) The frontend seems wrong here, no matter what. 3b) The integrated backend seems at least slightly wrong. 3c) The events code either needs widening, or perhaps this isn't time, but a somewhat arbitrary "fingerprint". Perhaps it can just use MOD?? I will likely verify if it needs to be time or just a reasonably volatile number to cross check sender/reciever and then use MOD. Posix and Win32 systems probably can't talk to each other. Lame. Someone might suggest that Win32 epoch be changed to 1970. I don't think so. 4) can anyone understand and explain the Modula-3 code we have here in Time.m3? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Wed Sep 4 10:06:14 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 4 Sep 2013 10:06:14 +0200 Subject: [M3devel] Git migration In-Reply-To: <6433EF8B-83A9-4FEE-A626-ADC25C8C689E@m3w.org> References: <6433EF8B-83A9-4FEE-A626-ADC25C8C689E@m3w.org> Message-ID: <20130904100614.4c96fb84.wagner@elego.de> On Sun, 1 Sep 2013 09:31:47 +0200 Dragi?a Duri? wrote: > Hi all, > > I would like to initiate final conversion/migration of repository to Git. As per widely accepted guidelines for such migrations - here is a question to stakeholders (I suppose it means people on this list :) ): > > Does anybody have any questions/reasonable doubts about this migration? > > My plan is to collect feedback, prepare workflow equivalents for current CVS workflows, and do all the work "atomically" one day of this September. Please feel free to send your specific concerns/wishes both here and privately to me. Hi everybody, I'd just like to remember that I had created a Wiki page for discussion and information about this project at https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration I think Wikis are very good and productive platforms for collaborative work; so I suggest you use it. If anybody is missing an account or permissions, please contact me or Michael Anderson at elego: wagner at elegosoft.com manderson at elegosoft.com Despite my doubts about the necessity of CVS migration several years ago, I'm now very much in favour of this project. I think git is now established as a useful and well-supported standard VCS tool, and migrating to it will open CM3 up for more active developers. I would really like to take a more active part in the transition, but unfortunately I'm still too busy with other projects to contribute any reasonable amount of time. 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: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Wed Sep 4 18:32:17 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 04 Sep 2013 09:32:17 -0700 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , <20130904064212.318CF1A2080@async.async.caltech.edu> Message-ID: <20130904163217.C90041A2080@async.async.caltech.edu> Jay K writes: >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> If I am understanding properly what is going on I think this means your n= >ew >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >ation. > > >I wish=2C but no=2C it is the same as the others. I see... > > >It is all a bit subtle. As always... > ... > > >I believe=2C based on what you are saying=2C >the frontend should generate range checks before >floor/trunc/ceiling. > >Roughly it should be an error to convert >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. >Plus or minus one though. > > >That is=2C > FLOOR(LAST(INTEGER) + .99999) is ok. > CEILING(FIRST(INTEGER) - .99999) is ok. > ROUND(LAST(INTEGER) - .499999) is ok. > ROUND(FIRST(INTEGER) + .499999) is ok. >=20 > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > >Oh wait. It depends on the relative ranges of float and integer. > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer >needs the checks I describe. But a 53bit mantissa converted to >a 64bit integer=2C no range check is needed. > > >The frontend has some of those optimizations already -- converting >from a smaller range to a larger range needs no check. > > >Agreed? Surely this is not a difficult change? Well, I agree wholeheartedly, yes. >Nor particularly inefficient? > > > > - Jay > > > > >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = >events? >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 >> From: mika at async.caltech.edu >>=20 >> Jay K writes: >> ... >> > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. >> > >> > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= >met=3D >> >ic_operations.html >> > >> > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= >he co=3D >> >nstant RoundDefault >> > >> > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? >> > >> > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 >> > or greater than LAST(INTEGER) + 1 round to?=3D20 >> > >> > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 >> > and LAST(INTEGER). But is it safe? >> > >>=20 >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= >s=2C >> "integer" is the abstract mathematical concept of an integer=2C not the >> Modula-3 data type INTEGER. >>=20 >> I think the intent of the Green Book is that INTEGER should be a range-li= >mited >> form of integer=2C that is=2C it should behave like an integer as much as= > possible=2C >> and when the implementation can no longer accomplish that=2C it should si= >gnal a=20 >> runtime error. =20 >>=20 >> It happens that many existing implementions of Modula-3=2C as an implemen= >tation >> restriction=2C do not handle out-of-range situations correctly. Things >> such as what you describe SHOULD lead to a runtime error=2C value out of = >range. >> Some implementations wrap instead=2C but I don't even think that's right.= > Of >> course it's not as bad as it might be in C where you might be indexing an >> array with the incorrectly calculated integer and send your program off i= >n >> never-never land. In Modula-3 you'll at least get a runtime error at THA= >T >> point. But it's still not right. >>=20 >> If I am understanding properly what is going on I think this means your n= >ew >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >ation. >>=20 >> Mika > = > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
>=3B If I am understanding pro= >perly what is going on I think this means your new
>=3B Modula-3-to-C = >compiler is the most reasonably behaving Modula-3 implementation.

r>I wish=2C but no=2C it is the same as the others.


It is all a = >bit subtle.


Here is what I believe happens:


I386_NT: = >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > that can be
successfully assigned to this range=2C with or without
a= > range check.


m3cc: Posix: The values are in range.
With or w= >ithout a range check=2C the code succeeds.
For a "few" more years.
r>
C backend: Similar.
I'm using the C backend all the time on Darwon= >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = >systems will fail here.
32bit Posix would continue to round to some 32bi= >t integer=2C which would then
successfully pass into the identical subra= >nge -- like I386_NT today.



The backends don't add range chec= >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= >nd at least roughly
the range of longreal.
Possibly the range of a lo= >ngreal is target-dependent and knowledge
of it should only exist in the = >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= >s the same since around the early 1980s.



I believe=2C based = >on what you are saying=2C
the frontend should generate range checks befo= >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= >ive ranges of float and integer.


In particular=2C a 53bit mantis= >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= >ded.


The frontend has some of those optimizations already -- con= >verting
from a smaller range to a larger range needs no check.

r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= >cient?



 =3B- Jay




>=3B To: jay.= >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > the abstract mathematical concept of an integer=2C not the
>=3B Modul= >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > Book is that INTEGER should be a range-limited
>=3B form of integer= >=2C that is=2C it should behave like an integer as much as possible=2C
&= >gt=3B and when the implementation can no longer accomplish that=2C it shoul= >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= >t many existing implementions of Modula-3=2C as an implementation
>=3B= > restriction=2C do not handle out-of-range situations correctly. Things>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= >n think that's right. Of
>=3B course it's not as bad as it might be i= >n C where you might be indexing an
>=3B array with the incorrectly cal= >culated integer and send your program off in
>=3B never-never land. I= >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= >t it's still not right.
>=3B
>=3B If I am understanding properly= > what is going on I think this means your new
>=3B Modula-3-to-C compi= >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= >>=3B Mika
>= > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- From hosking at cs.purdue.edu Wed Sep 4 18:48:46 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 4 Sep 2013 12:48:46 -0400 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <20130904163217.C90041A2080@async.async.caltech.edu> References: , <20130904064212.318CF1A2080@async.async.caltech.edu> <20130904163217.C90041A2080@async.async.caltech.edu> Message-ID: <53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu> So, what is the precise proposal? Fix Target.Float to avoid constant folding in these instances? That seems reasonable to me. On Sep 4, 2013, at 12:32 PM, mika at async.caltech.edu wrote: > Jay K writes: >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >>> If I am understanding properly what is going on I think this means your n= >> ew >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >> ation. >> >> >> I wish=2C but no=2C it is the same as the others. > > I see... > >> >> >> It is all a bit subtle. > > As always... > >> > ... >> >> >> I believe=2C based on what you are saying=2C >> the frontend should generate range checks before >> floor/trunc/ceiling. >> >> Roughly it should be an error to convert >> a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. >> Plus or minus one though. >> >> >> That is=2C >> FLOOR(LAST(INTEGER) + .99999) is ok. >> CEILING(FIRST(INTEGER) - .99999) is ok. >> ROUND(LAST(INTEGER) - .499999) is ok. >> ROUND(FIRST(INTEGER) + .499999) is ok. >> =20 >> >> I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. >> >> >> Oh wait. It depends on the relative ranges of float and integer. >> >> >> In particular=2C a 53bit mantissa longreal converted to a 32bit integer >> needs the checks I describe. But a 53bit mantissa converted to >> a 64bit integer=2C no range check is needed. >> >> >> The frontend has some of those optimizations already -- converting >> from a smaller range to a larger range needs no check. >> >> >> Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > >> Nor particularly inefficient? >> >> >> >> - Jay >> >> >> >> >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = >> events? >>> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 >>> From: mika at async.caltech.edu >>> =20 >>> Jay K writes: >>> ... >>>> >>>> Ok=3D2C so this is three dilemnas/questions/bugs in one. >>>> >>>> >>>> http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= >> met=3D >>>> ic_operations.html >>>> >>>> >>>> ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= >> he co=3D >>>> nstant RoundDefault >>>> >>>> >>>> 1) How should ROUND be defined? Is Modula-3 adequately safe here? >>>> >>>> >>>> What should round of numbers less than FIRST(INTEGER)-1=3D20 >>>> or greater than LAST(INTEGER) + 1 round to?=3D20 >>>> >>>> >>>> By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 >>>> and LAST(INTEGER). But is it safe? >>>> >>> =20 >>> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= >> s=2C >>> "integer" is the abstract mathematical concept of an integer=2C not the >>> Modula-3 data type INTEGER. >>> =20 >>> I think the intent of the Green Book is that INTEGER should be a range-li= >> mited >>> form of integer=2C that is=2C it should behave like an integer as much as= >> possible=2C >>> and when the implementation can no longer accomplish that=2C it should si= >> gnal a=20 >>> runtime error. =20 >>> =20 >>> It happens that many existing implementions of Modula-3=2C as an implemen= >> tation >>> restriction=2C do not handle out-of-range situations correctly. Things >>> such as what you describe SHOULD lead to a runtime error=2C value out of = >> range. >>> Some implementations wrap instead=2C but I don't even think that's right.= >> Of >>> course it's not as bad as it might be in C where you might be indexing an >>> array with the incorrectly calculated integer and send your program off i= >> n >>> never-never land. In Modula-3 you'll at least get a runtime error at THA= >> T >>> point. But it's still not right. >>> =20 >>> If I am understanding properly what is going on I think this means your n= >> ew >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= >> ation. >>> =20 >>> Mika >> = >> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >>
>=3B If I am understanding pro= >> perly what is going on I think this means your new
>=3B Modula-3-to-C = >> compiler is the most reasonably behaving Modula-3 implementation.

> r>I wish=2C but no=2C it is the same as the others.


It is all a = >> bit subtle.


Here is what I believe happens:


I386_NT: = >> from any double=2C round will give us
some integer=2C a 32bit integer=2C= >> that can be
successfully assigned to this range=2C with or without
a= >> range check.


m3cc: Posix: The values are in range.
With or w= >> ithout a range check=2C the code succeeds.
For a "few" more years.
> r>
C backend: Similar.
I'm using the C backend all the time on Darwon= >> .
Again=2C Posix: the values are in range.
I386_NT: round will give u= >> s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= >> teger=2C the range check fails.


In a "few" years=2C 64bit Posix = >> systems will fail here.
32bit Posix would continue to round to some 32bi= >> t integer=2C which would then
successfully pass into the identical subra= >> nge -- like I386_NT today.



The backends don't add range chec= >> ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= >> ows enough=2C it should do it.
The frontend knows the range of INTEGER a= >> nd at least roughly
the range of longreal.
Possibly the range of a lo= >> ngreal is target-dependent and knowledge
of it should only exist in the = >> backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= >> s the same since around the early 1980s.



I believe=2C based = >> on what you are saying=2C
the frontend should generate range checks befo= >> re
floor/trunc/ceiling.

Roughly it should be an error to convert<= >> br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= >> us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= >> ) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= >> + .499999) is ok.
 =3B

I'm not sure where "round to even" is= >> =2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= >> ive ranges of float and integer.


In particular=2C a 53bit mantis= >> sa longreal converted to a 32bit integer
needs the checks I describe. Bu= >> t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= >> ded.


The frontend has some of those optimizations already -- con= >> verting
from a smaller range to a larger range needs no check.

> r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= >> cient?



 =3B- Jay




>=3B To: jay.= >> krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= >> itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= >> 2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= >> rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= >> ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= >> t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= >> _10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= >> =3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= >> re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= >> =3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= >> Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= >> =3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= >> >=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= >> t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= >> hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = >> is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= >> on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= >> the abstract mathematical concept of an integer=2C not the
>=3B Modul= >> a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= >> Book is that INTEGER should be a range-limited
>=3B form of integer= >> =2C that is=2C it should behave like an integer as much as possible=2C
&= >> gt=3B and when the implementation can no longer accomplish that=2C it shoul= >> d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= >> t many existing implementions of Modula-3=2C as an implementation
>=3B= >> restriction=2C do not handle out-of-range situations correctly. Things>> >=3B such as what you describe SHOULD lead to a runtime error=2C value o= >> ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= >> n think that's right. Of
>=3B course it's not as bad as it might be i= >> n C where you might be indexing an
>=3B array with the incorrectly cal= >> culated integer and send your program off in
>=3B never-never land. I= >> n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= >> t it's still not right.
>=3B
>=3B If I am understanding properly= >> what is going on I think this means your new
>=3B Modula-3-to-C compi= >> ler is the most reasonably behaving Modula-3 implementation.
>=3B
= >> >=3B Mika
>> = >> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- From jay.krell at cornell.edu Wed Sep 4 19:00:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 17:00:51 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <20130904163217.C90041A2080@async.async.caltech.edu> References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> Message-ID: > Well, I agree wholeheartedly, yes. Tony: can we put in range checks on float to int conversions? I'd be ok with initially: if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 error The "1" isn't quite right, but "0" is also wrong. I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". - Jay > To: jay.krell at cornell.edu > Date: Wed, 4 Sep 2013 09:32:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > Jay K writes: > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > > > > > >I wish=2C but no=2C it is the same as the others. > > I see... > > > > > > >It is all a bit subtle. > > As always... > > > > ... > > > > > >I believe=2C based on what you are saying=2C > >the frontend should generate range checks before > >floor/trunc/ceiling. > > > >Roughly it should be an error to convert > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >Plus or minus one though. > > > > > >That is=2C > > FLOOR(LAST(INTEGER) + .99999) is ok. > > CEILING(FIRST(INTEGER) - .99999) is ok. > > ROUND(LAST(INTEGER) - .499999) is ok. > > ROUND(FIRST(INTEGER) + .499999) is ok. > >=20 > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >needs the checks I describe. But a 53bit mantissa converted to > >a 64bit integer=2C no range check is needed. > > > > > >The frontend has some of those optimizations already -- converting > >from a smaller range to a larger range needs no check. > > > > > >Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > > >Nor particularly inefficient? > > > > > > > > - Jay > > > > > > > > > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >events? > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> Jay K writes: > >> ... > >> > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > >> > > >> > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >met=3D > >> >ic_operations.html > >> > > >> > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >he co=3D > >> >nstant RoundDefault > >> > > >> > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > >> > > >> > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > >> > > >> > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >> > and LAST(INTEGER). But is it safe? > >> > > >>=20 > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >s=2C > >> "integer" is the abstract mathematical concept of an integer=2C not the > >> Modula-3 data type INTEGER. > >>=20 > >> I think the intent of the Green Book is that INTEGER should be a range-li= > >mited > >> form of integer=2C that is=2C it should behave like an integer as much as= > > possible=2C > >> and when the implementation can no longer accomplish that=2C it should si= > >gnal a=20 > >> runtime error. =20 > >>=20 > >> It happens that many existing implementions of Modula-3=2C as an implemen= > >tation > >> restriction=2C do not handle out-of-range situations correctly. Things > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > >range. > >> Some implementations wrap instead=2C but I don't even think that's right.= > > Of > >> course it's not as bad as it might be in C where you might be indexing an > >> array with the incorrectly calculated integer and send your program off i= > >n > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >T > >> point. But it's still not right. > >>=20 > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > >>=20 > >> Mika > > = > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > >
>=3B If I am understanding pro= > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > >compiler is the most reasonably behaving Modula-3 implementation.

>r>I wish=2C but no=2C it is the same as the others.


It is all a = > >bit subtle.


Here is what I believe happens:


I386_NT: = > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > that can be
successfully assigned to this range=2C with or without
a= > > range check.


m3cc: Posix: The values are in range.
With or w= > >ithout a range check=2C the code succeeds.
For a "few" more years.
>r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >systems will fail here.
32bit Posix would continue to round to some 32bi= > >t integer=2C which would then
successfully pass into the identical subra= > >nge -- like I386_NT today.



The backends don't add range chec= > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > >ngreal is target-dependent and knowledge
of it should only exist in the = > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >s the same since around the early 1980s.



I believe=2C based = > >on what you are saying=2C
the frontend should generate range checks befo= > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >ded.


The frontend has some of those optimizations already -- con= > >verting
from a smaller range to a larger range needs no check.

>r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >cient?



 =3B- Jay




>=3B To: jay.= > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > Book is that INTEGER should be a range-limited
>=3B form of integer= > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > restriction=2C do not handle out-of-range situations correctly. Things >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >n think that's right. Of
>=3B course it's not as bad as it might be i= > >n C where you might be indexing an
>=3B array with the incorrectly cal= > >culated integer and send your program off in
>=3B never-never land. I= > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >>=3B Mika
> >= > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 19:22:53 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 17:22:53 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu> References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu>, <53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu> Message-ID: Target.Float is definitely not entire problem, but probably is part of it. Runtime checks are missing also. - Jay > From: hosking at cs.purdue.edu > Date: Wed, 4 Sep 2013 12:48:46 -0400 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > So, what is the precise proposal? Fix Target.Float to avoid constant folding in these instances? That seems reasonable to me. > > On Sep 4, 2013, at 12:32 PM, mika at async.caltech.edu wrote: > > > Jay K writes: > >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >> Content-Type: text/plain; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >>> If I am understanding properly what is going on I think this means your n= > >> ew > >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >> ation. > >> > >> > >> I wish=2C but no=2C it is the same as the others. > > > > I see... > > > >> > >> > >> It is all a bit subtle. > > > > As always... > > > >> > > ... > >> > >> > >> I believe=2C based on what you are saying=2C > >> the frontend should generate range checks before > >> floor/trunc/ceiling. > >> > >> Roughly it should be an error to convert > >> a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >> Plus or minus one though. > >> > >> > >> That is=2C > >> FLOOR(LAST(INTEGER) + .99999) is ok. > >> CEILING(FIRST(INTEGER) - .99999) is ok. > >> ROUND(LAST(INTEGER) - .499999) is ok. > >> ROUND(FIRST(INTEGER) + .499999) is ok. > >> =20 > >> > >> I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > >> > >> > >> Oh wait. It depends on the relative ranges of float and integer. > >> > >> > >> In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >> needs the checks I describe. But a 53bit mantissa converted to > >> a 64bit integer=2C no range check is needed. > >> > >> > >> The frontend has some of those optimizations already -- converting > >> from a smaller range to a larger range needs no check. > >> > >> > >> Agreed? Surely this is not a difficult change? > > > > Well, I agree wholeheartedly, yes. > > > >> Nor particularly inefficient? > >> > >> > >> > >> - Jay > >> > >> > >> > >> > >>> To: jay.krell at cornell.edu > >>> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >> events? > >>> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >>> From: mika at async.caltech.edu > >>> =20 > >>> Jay K writes: > >>> ... > >>>> > >>>> Ok=3D2C so this is three dilemnas/questions/bugs in one. > >>>> > >>>> > >>>> http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >> met=3D > >>>> ic_operations.html > >>>> > >>>> > >>>> ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >> he co=3D > >>>> nstant RoundDefault > >>>> > >>>> > >>>> 1) How should ROUND be defined? Is Modula-3 adequately safe here? > >>>> > >>>> > >>>> What should round of numbers less than FIRST(INTEGER)-1=3D20 > >>>> or greater than LAST(INTEGER) + 1 round to?=3D20 > >>>> > >>>> > >>>> By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >>>> and LAST(INTEGER). But is it safe? > >>>> > >>> =20 > >>> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >> s=2C > >>> "integer" is the abstract mathematical concept of an integer=2C not the > >>> Modula-3 data type INTEGER. > >>> =20 > >>> I think the intent of the Green Book is that INTEGER should be a range-li= > >> mited > >>> form of integer=2C that is=2C it should behave like an integer as much as= > >> possible=2C > >>> and when the implementation can no longer accomplish that=2C it should si= > >> gnal a=20 > >>> runtime error. =20 > >>> =20 > >>> It happens that many existing implementions of Modula-3=2C as an implemen= > >> tation > >>> restriction=2C do not handle out-of-range situations correctly. Things > >>> such as what you describe SHOULD lead to a runtime error=2C value out of = > >> range. > >>> Some implementations wrap instead=2C but I don't even think that's right.= > >> Of > >>> course it's not as bad as it might be in C where you might be indexing an > >>> array with the incorrectly calculated integer and send your program off i= > >> n > >>> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >> T > >>> point. But it's still not right. > >>> =20 > >>> If I am understanding properly what is going on I think this means your n= > >> ew > >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >> ation. > >>> =20 > >>> Mika > >> = > >> > >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >> Content-Type: text/html; charset="iso-8859-1" > >> Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> > >>
>=3B If I am understanding pro= > >> perly what is going on I think this means your new
>=3B Modula-3-to-C = > >> compiler is the most reasonably behaving Modula-3 implementation.

>> r>I wish=2C but no=2C it is the same as the others.


It is all a = > >> bit subtle.


Here is what I believe happens:


I386_NT: = > >> from any double=2C round will give us
some integer=2C a 32bit integer=2C= > >> that can be
successfully assigned to this range=2C with or without
a= > >> range check.


m3cc: Posix: The values are in range.
With or w= > >> ithout a range check=2C the code succeeds.
For a "few" more years.
>> r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >> .
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >> s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >> teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >> systems will fail here.
32bit Posix would continue to round to some 32bi= > >> t integer=2C which would then
successfully pass into the identical subra= > >> nge -- like I386_NT today.



The backends don't add range chec= > >> ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >> ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >> nd at least roughly
the range of longreal.
Possibly the range of a lo= > >> ngreal is target-dependent and knowledge
of it should only exist in the = > >> backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >> s the same since around the early 1980s.



I believe=2C based = > >> on what you are saying=2C
the frontend should generate range checks befo= > >> re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >> br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >> us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >> ) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > >> + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >> =2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >> ive ranges of float and integer.


In particular=2C a 53bit mantis= > >> sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >> t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >> ded.


The frontend has some of those optimizations already -- con= > >> verting
from a smaller range to a larger range needs no check.

>> r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >> cient?



 =3B- Jay




>=3B To: jay.= > >> krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >> itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >> 2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >> rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >> ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >> t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >> _10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >> =3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >> re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >> =3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > >> Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >> =3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >> >=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >> t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >> hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >> is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >> on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > >> the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >> a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > >> Book is that INTEGER should be a range-limited
>=3B form of integer= > >> =2C that is=2C it should behave like an integer as much as possible=2C
&= > >> gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >> d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >> t many existing implementions of Modula-3=2C as an implementation
>=3B= > >> restriction=2C do not handle out-of-range situations correctly. Things >>> >=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >> ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >> n think that's right. Of
>=3B course it's not as bad as it might be i= > >> n C where you might be indexing an
>=3B array with the incorrectly cal= > >> culated integer and send your program off in
>=3B never-never land. I= > >> n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >> t it's still not right.
>=3B
>=3B If I am understanding properly= > >> what is going on I think this means your new
>=3B Modula-3-to-C compi= > >> ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >> >=3B Mika
> >> = > >> > >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 4 19:54:29 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 4 Sep 2013 13:54:29 -0400 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: But we don?t check integer overflow. Putting a check on all conversions seems onerous and expensive. If the programmer wants the check perhaps they should program it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Sep 4, 2013, at 1:49 PM, Jay K wrote: > I want both. > > > We check subrange assignments. > This seems almost the same thing. > When a programming converts float to int, what do they accept they are losing? > Precision or range or both? > I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. > > > The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. > > > Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? > Our obligation is only type safety? > round/trunc/ceiling can return random numbers and still be type safe? > (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) > > > - Jay > > > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > From: antony.hosking at gmail.com > Date: Wed, 4 Sep 2013 13:31:01 -0400 > CC: mika at async.caltech.edu; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. > > On Sep 4, 2013, at 1:00 PM, Jay K wrote: > > > Well, I agree wholeheartedly, yes. > > > Tony: can we put in range checks on float to int conversions? > I'd be ok with initially: > if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 > error > > The "1" isn't quite right, but "0" is also wrong. > > > I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). > > And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". > > > - Jay > > > > To: jay.krell at cornell.edu > > Date: Wed, 4 Sep 2013 09:32:17 -0700 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > > > Jay K writes: > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/plain; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > > > > > > > >I wish=2C but no=2C it is the same as the others. > > > > I see... > > > > > > > > > > >It is all a bit subtle. > > > > As always... > > > > > > > ... > > > > > > > > >I believe=2C based on what you are saying=2C > > >the frontend should generate range checks before > > >floor/trunc/ceiling. > > > > > >Roughly it should be an error to convert > > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > > >Plus or minus one though. > > > > > > > > >That is=2C > > > FLOOR(LAST(INTEGER) + .99999) is ok. > > > CEILING(FIRST(INTEGER) - .99999) is ok. > > > ROUND(LAST(INTEGER) - .499999) is ok. > > > ROUND(FIRST(INTEGER) + .499999) is ok. > > >=20 > > > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > > >needs the checks I describe. But a 53bit mantissa converted to > > >a 64bit integer=2C no range check is needed. > > > > > > > > >The frontend has some of those optimizations already -- converting > > >from a smaller range to a larger range needs no check. > > > > > > > > >Agreed? Surely this is not a difficult change? > > > > Well, I agree wholeheartedly, yes. > > > > >Nor particularly inefficient? > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > >> To: jay.krell at cornell.edu > > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > > >events? > > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > > >> From: mika at async.caltech.edu > > >>=20 > > >> Jay K writes: > > >> ... > > >> > > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > > >> > > > >> > > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > > >met=3D > > >> >ic_operations.html > > >> > > > >> > > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > > >he co=3D > > >> >nstant RoundDefault > > >> > > > >> > > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > > >> > > > >> > > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > > >> > > > >> > > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > > >> > and LAST(INTEGER). But is it safe? > > >> > > > >>=20 > > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > > >s=2C > > >> "integer" is the abstract mathematical concept of an integer=2C not the > > >> Modula-3 data type INTEGER. > > >>=20 > > >> I think the intent of the Green Book is that INTEGER should be a range-li= > > >mited > > >> form of integer=2C that is=2C it should behave like an integer as much as= > > > possible=2C > > >> and when the implementation can no longer accomplish that=2C it should si= > > >gnal a=20 > > >> runtime error. =20 > > >>=20 > > >> It happens that many existing implementions of Modula-3=2C as an implemen= > > >tation > > >> restriction=2C do not handle out-of-range situations correctly. Things > > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > > >range. > > >> Some implementations wrap instead=2C but I don't even think that's right.= > > > Of > > >> course it's not as bad as it might be in C where you might be indexing an > > >> array with the incorrectly calculated integer and send your program off i= > > >n > > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > > >T > > >> point. But it's still not right. > > >>=20 > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > >>=20 > > >> Mika > > > = > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/html; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > >
>=3B If I am understanding pro= > > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > > >compiler is the most reasonably behaving Modula-3 implementation.

> >r>I wish=2C but no=2C it is the same as the others.


It is all a = > > >bit subtle.


Here is what I believe happens:


I386_NT: = > > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > > that can be
successfully assigned to this range=2C with or without
a= > > > range check.


m3cc: Posix: The values are in range.
With or w= > > >ithout a range check=2C the code succeeds.
For a "few" more years.
> >r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > > >systems will fail here.
32bit Posix would continue to round to some 32bi= > > >t integer=2C which would then
successfully pass into the identical subra= > > >nge -- like I386_NT today.



The backends don't add range chec= > > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > > >ngreal is target-dependent and knowledge
of it should only exist in the = > > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > > >s the same since around the early 1980s.



I believe=2C based = > > >on what you are saying=2C
the frontend should generate range checks befo= > > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > > >ded.


The frontend has some of those optimizations already -- con= > > >verting
from a smaller range to a larger range needs no check.

> >r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > > >cient?



 =3B- Jay




>=3B To: jay.= > > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > > Book is that INTEGER should be a range-limited
>=3B form of integer= > > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > > restriction=2C do not handle out-of-range situations correctly. Things > >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > > >n think that's right. Of
>=3B course it's not as bad as it might be i= > > >n C where you might be indexing an
>=3B array with the incorrectly cal= > > >culated integer and send your program off in
>=3B never-never land. I= > > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > > >>=3B Mika
> > >= > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 4 19:49:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Sep 2013 17:49:02 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: I want both. We check subrange assignments. This seems almost the same thing. When a programming converts float to int, what do they accept they are losing? Precision or range or both? I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? Our obligation is only type safety? round/trunc/ceiling can return random numbers and still be type safe? (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) - Jay Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? From: antony.hosking at gmail.com Date: Wed, 4 Sep 2013 13:31:01 -0400 CC: mika at async.caltech.edu; m3devel at elegosoft.com To: jay.krell at cornell.edu I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. On Sep 4, 2013, at 1:00 PM, Jay K wrote:> Well, I agree wholeheartedly, yes. Tony: can we put in range checks on float to int conversions? I'd be ok with initially: if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 error The "1" isn't quite right, but "0" is also wrong. I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". - Jay > To: jay.krell at cornell.edu > Date: Wed, 4 Sep 2013 09:32:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > Jay K writes: > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > > > > > >I wish=2C but no=2C it is the same as the others. > > I see... > > > > > > >It is all a bit subtle. > > As always... > > > > ... > > > > > >I believe=2C based on what you are saying=2C > >the frontend should generate range checks before > >floor/trunc/ceiling. > > > >Roughly it should be an error to convert > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >Plus or minus one though. > > > > > >That is=2C > > FLOOR(LAST(INTEGER) + .99999) is ok. > > CEILING(FIRST(INTEGER) - .99999) is ok. > > ROUND(LAST(INTEGER) - .499999) is ok. > > ROUND(FIRST(INTEGER) + .499999) is ok. > >=20 > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >needs the checks I describe. But a 53bit mantissa converted to > >a 64bit integer=2C no range check is needed. > > > > > >The frontend has some of those optimizations already -- converting > >from a smaller range to a larger range needs no check. > > > > > >Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > > >Nor particularly inefficient? > > > > > > > > - Jay > > > > > > > > > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >events? > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> Jay K writes: > >> ... > >> > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > >> > > >> > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >met=3D > >> >ic_operations.html > >> > > >> > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >he co=3D > >> >nstant RoundDefault > >> > > >> > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > >> > > >> > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > >> > > >> > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >> > and LAST(INTEGER). But is it safe? > >> > > >>=20 > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >s=2C > >> "integer" is the abstract mathematical concept of an integer=2C not the > >> Modula-3 data type INTEGER. > >>=20 > >> I think the intent of the Green Book is that INTEGER should be a range-li= > >mited > >> form of integer=2C that is=2C it should behave like an integer as much as= > > possible=2C > >> and when the implementation can no longer accomplish that=2C it should si= > >gnal a=20 > >> runtime error. =20 > >>=20 > >> It happens that many existing implementions of Modula-3=2C as an implemen= > >tation > >> restriction=2C do not handle out-of-range situations correctly. Things > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > >range. > >> Some implementations wrap instead=2C but I don't even think that's right.= > > Of > >> course it's not as bad as it might be in C where you might be indexing an > >> array with the incorrectly calculated integer and send your program off i= > >n > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >T > >> point. But it's still not right. > >>=20 > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > >>=20 > >> Mika > > = > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > >
>=3B If I am understanding pro= > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > >compiler is the most reasonably behaving Modula-3 implementation.

>r>I wish=2C but no=2C it is the same as the others.


It is all a = > >bit subtle.


Here is what I believe happens:


I386_NT: = > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > that can be
successfully assigned to this range=2C with or without
a= > > range check.


m3cc: Posix: The values are in range.
With or w= > >ithout a range check=2C the code succeeds.
For a "few" more years.
>r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >systems will fail here.
32bit Posix would continue to round to some 32bi= > >t integer=2C which would then
successfully pass into the identical subra= > >nge -- like I386_NT today.



The backends don't add range chec= > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > >ngreal is target-dependent and knowledge
of it should only exist in the = > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >s the same since around the early 1980s.



I believe=2C based = > >on what you are saying=2C
the frontend should generate range checks befo= > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >ded.


The frontend has some of those optimizations already -- con= > >verting
from a smaller range to a larger range needs no check.

>r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >cient?



 =3B- Jay




>=3B To: jay.= > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > Book is that INTEGER should be a range-limited
>=3B form of integer= > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > restriction=2C do not handle out-of-range situations correctly. Things >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >n think that's right. Of
>=3B course it's not as bad as it might be i= > >n C where you might be indexing an
>=3B array with the incorrectly cal= > >culated integer and send your program off in
>=3B never-never land. I= > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >>=3B Mika
> >= > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielal.benavides at bancoagrario.gov.co Wed Sep 4 21:09:04 2013 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Wed, 4 Sep 2013 19:09:04 +0000 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: <1AF4998819C60A40A4CD8C3B6582D3DA294BEFFF@DRG008W8SMBX014.bancoagrario.gov.co> Hi all: Jay, type checking is one thing while range checking is another. Range checking is harder than type checking, that's the point here. If you want range checking with brute force you get a penalty obviously. If you want integer overflow checking is the same thing, perhaps there could be hope in ESC, I haven't asked that. DEC Alpha had a special purpose lobotomized AMD64 like architecture perhaps that provided the hardware needed for that; also see below: http://www.google.com/patents/?vid=USPAT6470373 Thanks in advance De: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] En nombre de Jay K Enviado el: Wednesday, 04 de September de 2013 12:49 p.m. Para: Antony Hosking CC: m3devel Asunto: Re: [M3devel] rounding very large magnitude longreal, time, events? I want both. We check subrange assignments. This seems almost the same thing. When a programming converts float to int, what do they accept they are losing? Precision or range or both? I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? Our obligation is only type safety? round/trunc/ceiling can return random numbers and still be type safe? (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) - Jay ________________________________ Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? From: antony.hosking at gmail.com Date: Wed, 4 Sep 2013 13:31:01 -0400 CC: mika at async.caltech.edu; m3devel at elegosoft.com To: jay.krell at cornell.edu I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. On Sep 4, 2013, at 1:00 PM, Jay K > wrote: > Well, I agree wholeheartedly, yes. Tony: can we put in range checks on float to int conversions? I'd be ok with initially: if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 error The "1" isn't quite right, but "0" is also wrong. I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". - Jay > To: jay.krell at cornell.edu > Date: Wed, 4 Sep 2013 09:32:17 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > Jay K writes: > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > > > > > >I wish=2C but no=2C it is the same as the others. > > I see... > > > > > > >It is all a bit subtle. > > As always... > > > > ... > > > > > >I believe=2C based on what you are saying=2C > >the frontend should generate range checks before > >floor/trunc/ceiling. > > > >Roughly it should be an error to convert > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > >Plus or minus one though. > > > > > >That is=2C > > FLOOR(LAST(INTEGER) + .99999) is ok. > > CEILING(FIRST(INTEGER) - .99999) is ok. > > ROUND(LAST(INTEGER) - .499999) is ok. > > ROUND(FIRST(INTEGER) + .499999) is ok. > >=20 > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > >needs the checks I describe. But a 53bit mantissa converted to > >a 64bit integer=2C no range check is needed. > > > > > >The frontend has some of those optimizations already -- converting > >from a smaller range to a larger range needs no check. > > > > > >Agreed? Surely this is not a difficult change? > > Well, I agree wholeheartedly, yes. > > >Nor particularly inefficient? > > > > > > > > - Jay > > > > > > > > > >> To: jay.krell at cornell.edu > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > >events? > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> Jay K writes: > >> ... > >> > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > >> > > >> > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > >met=3D > >> >ic_operations.html > >> > > >> > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > >he co=3D > >> >nstant RoundDefault > >> > > >> > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > >> > > >> > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > >> > > >> > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > >> > and LAST(INTEGER). But is it safe? > >> > > >>=20 > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > >s=2C > >> "integer" is the abstract mathematical concept of an integer=2C not the > >> Modula-3 data type INTEGER. > >>=20 > >> I think the intent of the Green Book is that INTEGER should be a range-li= > >mited > >> form of integer=2C that is=2C it should behave like an integer as much as= > > possible=2C > >> and when the implementation can no longer accomplish that=2C it should si= > >gnal a=20 > >> runtime error. =20 > >>=20 > >> It happens that many existing implementions of Modula-3=2C as an implemen= > >tation > >> restriction=2C do not handle out-of-range situations correctly. Things > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > >range. > >> Some implementations wrap instead=2C but I don't even think that's right.= > > Of > >> course it's not as bad as it might be in C where you might be indexing an > >> array with the incorrectly calculated integer and send your program off i= > >n > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > >T > >> point. But it's still not right. > >>=20 > >> If I am understanding properly what is going on I think this means your n= > >ew > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > >ation. > >>=20 > >> Mika > > = > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > >
>=3B If I am understanding pro= > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > >compiler is the most reasonably behaving Modula-3 implementation.

>r>I wish=2C but no=2C it is the same as the others.


It is all a = > >bit subtle.


Here is what I believe happens:


I386_NT: = > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > that can be
successfully assigned to this range=2C with or without
a= > > range check.


m3cc: Posix: The values are in range.
With or w= > >ithout a range check=2C the code succeeds.
For a "few" more years.
>r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > >systems will fail here.
32bit Posix would continue to round to some 32bi= > >t integer=2C which would then
successfully pass into the identical subra= > >nge -- like I386_NT today.



The backends don't add range chec= > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > >ngreal is target-dependent and knowledge
of it should only exist in the = > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > >s the same since around the early 1980s.



I believe=2C based = > >on what you are saying=2C
the frontend should generate range checks befo= > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > >ded.


The frontend has some of those optimizations already -- con= > >verting
from a smaller range to a larger range needs no check.

>r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > >cient?



 =3B- Jay




>=3B To: jay.= > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > Book is that INTEGER should be a range-limited
>=3B form of integer= > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > restriction=2C do not handle out-of-range situations correctly. Things >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > >n think that's right. Of
>=3B course it's not as bad as it might be i= > >n C where you might be indexing an
>=3B array with the incorrectly cal= > >culated integer and send your program off in
>=3B never-never land. I= > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > >>=3B Mika
> >= > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Sep 5 03:40:34 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 5 Sep 2013 02:40:34 +0100 (BST) Subject: [M3devel] AMD64_NT In-Reply-To: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> References: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> Message-ID: <1378345234.54343.YahooMailNeo@web172801.mail.ir2.yahoo.com> Hi all: these are incredible news! DEC SRC, used the same target to cross build Win32 host. I would like to test it on WinXP64ed and then produce boot images for vista and 7. But I want to build it from source if I may please. For instance cross build it from WinXP build it in WinXP64ed, and produce snapshots from there. Trust me I have a good reason for it. If Im may say so, DEC SRC had a philosophy inside M3 implementation that we should persevere. All RT written in Modula-3, please no more C, just in case if needed please; see for instance why we shouldn't have third party libraries, just compiler and that's all. It exposes the need for complex runtimes in RISC compilers, like MicroVax2 (DEC Firefly) and the most complex DEC machine the VAX9000: http://users.ece.utexas.edu/~patt/12s.382N/handouts/class_slides/risc_retrospective.ppt Such that if needs assembly level stuff let's do it but no more C as source format. It's error prone, I prefer cloning over C sources 100% times. C as intermediate rep is another thing clearly. Thanks in advance ________________________________ De: Jay Para: m3devel Enviado: Martes 3 de septiembre de 2013 11:06 Asunto: [M3devel] AMD64_NT AMD_NT runs, can build itself, is more debuggable than NT386, Juno & formsedit come up. It was a fairly quick straightforward use of the C backend. There is a problem in m3core/Time that hangs mentor startup. The first time I ran cm3ide it brought up IE but hit an out-of-range in socket code. Elego code failed to build due to lack of c:\cygwin (I have c:\cygwin64). There is a problem in exception handling worked around using libcmt.lib instead of msvcr*.dll. The unsafe out of date cloned headers have as usual been a source of bugs. I'll try to get a snapshot out soon. Adventurous folks can try it already. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Sep 5 16:26:54 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 05 Sep 2013 09:26:54 -0500 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu> Message-ID: <522894AE.2070708@lcwb.coop> On 09/03/2013 12:50 PM, Jay K wrote: > I think it isn't just TextLiteral.MaxBytes. > > > How do I declare an unbouned-ly sized array? You use an open array. Then the compiler arranges to store its bound at runtime, using that instead of a static constant when generating bounds checks. In order to avoid big messes in both language definition and implementation, you can create a "ground" open array value only by allocating it in the heap. You can also, in effect, convert a fixed array value (created any way you like) by passing it to a formal of open array type or applying SUBARRAY to it with non-static length. The whole TextLiteral thing is a low-level implementation thing to allow the compiler to construct it statically, yet avoid having to always copy it into the traced heap the first thing at runtime. I haven't looked, but I would bet PM3 always copies a text literal into a heap object before creating a traced reference value pointing to it. Yes, it's unsafe in the sense that the usual array bounds mechanism is just circumvented by making it a fixed array with much larger bound than reality. The code in TextLiteral takes care of enforcing the bounds, instead of the usual compiler-generated mechanism. > At the end of a record? The language does not allow this. It has to be an autonomous object. I have a use-case that would save a lot of space if you could do this. There is big space overhead in separating it into a separate object, which can matter if the average size of the arrays is small. I have often thought about the implications of allowing it. I think the effects on the language would be dire, and would also require a lot of implementation work, including lots of GC additions. This is the same ol' tradeoff. Highly flexible mechanisms are less efficient. > Doesn't matter? > > > For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit? > > For legitimate uses, this limit is quite enough. Right off hand, I doubt the old crack of, e.g., entering 4K character passwords, user names, etc., can be used here, because all text values, TextLiteral included, are compiled as immutable objects. Input values would never be stored into an existing text literal. Even if they were, the TextLiteral library code would be checking bounds at runtime. In at least some targets, these are also stored in readonly segments as well. > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: hosking at cs.purdue.edu > Date: Tue, 3 Sep 2013 13:00:08 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? > > Yes, I want to avoid use of LONGINT in the compiler proper. > If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose. > But I still don?t understand the precise use-case that you are proposing. > In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small? > I cannot imaging a text literal that big, ever. > > > > Antony Hosking|Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Mobile+1 765 427 5484 > > > > > From rodney_bates at lcwb.coop Thu Sep 5 16:42:49 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 05 Sep 2013 09:42:49 -0500 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: References: Message-ID: <52289869.4000301@lcwb.coop> There is another issue here. I want TextLiteral.MaxBytes to get a final size and not change. Every time it changes, it creates compatibility problems by orphaning any existing pickle files and any compiled programs that write them. It changes the fingerprint, so a recently-compiled reading program can't find the type in its own list of known types. This also affects network objects when two communicating programs are compiled with different TextLiteral versions. MaxBytes' particular contribution to the type doesn't otherwise matter, because it's artificial, but it still undermines reading pickles. I have been loading up the pickle reading code with hard-coded historical fingerprints of various older versions. But it's a pain to keep doing, tedious to ferret out the values, and it still only helps those who constantly download and compile the latest CM3. At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint and hard-coding the compiler to artificially deliver it , rather than the one computed from the version-of-the day of TextLiteral. But this too would not help those who would rather not constantly download the latest, rebuild the compiler, then recompile their applications. On 09/03/2013 01:02 AM, Jay K wrote: > ok, another question: > > > CONST > (* DIV BITSIZE should not be here! *) > (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) > MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); > > TYPE > T = RTHooks.TextLiteral; > REVEAL > T = TEXT BRANDED "TextLiteral.T" OBJECT > cnt : INTEGER; > buf : ARRAY [0..MaxBytes - 1] OF Byte; > OVERRIDES ... > > > T is a reference type. > Is there a way to state this with no limit? > > > Isn't it already unsafe? > You know -- the array is usually smaller and the compiler is only going to check against this large size. > > > - Jay From dmuysers at hotmail.com Thu Sep 5 16:56:34 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Thu, 5 Sep 2013 16:56:34 +0200 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Intmore? Message-ID: > The whole TextLiteral thing is a low-level implementation thing to allow the > compiler to construct it statically, yet avoid having to always copy it into > the traced heap the first thing at runtime. I haven't looked, but I would bet > PM3 always copies a text literal into a heap object before creating a traced > reference value pointing to it. For a TextExpr, ie a literal, pm3 generates PROCEDURE Compile (p: P) = VAR uid := SetUID (p); BEGIN CG.Load_addr_of (global_data, literals[uid] + Target.Address.pack, Target.Address.align); END Compile; So it is, in fact, an UNTRACED REF, the GC will know, I guess. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 5 18:05:07 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 5 Sep 2013 12:05:07 -0400 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: <52289869.4000301@lcwb.coop> References: <52289869.4000301@lcwb.coop> Message-ID: <35F457AE-9FD1-4E16-906E-F3CFAB657102@cs.purdue.edu> Here is a modest proposal that should resolve this issue. Declare TextLiteral.T to have a minimal buf: ARRAY [0..0] OF Byte; Then use UNSAFE address arithmetic to access the bytes (TextLiteral.m3 already does the bounds checks explicitly using cnt). Updated TextLiteral.i3 and TextLiteral.m3 attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: TextLiteral.i3 Type: application/octet-stream Size: 1134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TextLiteral.m3 Type: application/octet-stream Size: 2989 bytes Desc: not available URL: -------------- next part -------------- Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Sep 5, 2013, at 10:42 AM, "Rodney M. Bates" wrote: > There is another issue here. I want TextLiteral.MaxBytes to get a final size > and not change. Every time it changes, it creates compatibility problems by > orphaning any existing pickle files and any compiled programs that write them. > It changes the fingerprint, so a recently-compiled reading program can't find the > type in its own list of known types. This also affects network objects when two > communicating programs are compiled with different TextLiteral versions. > > MaxBytes' particular contribution to the type doesn't otherwise matter, because it's > artificial, but it still undermines reading pickles. > > I have been loading up the pickle reading code with hard-coded historical fingerprints > of various older versions. But it's a pain to keep doing, tedious to ferret out the > values, and it still only helps those who constantly download and compile the latest > CM3. > > At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint > and hard-coding the compiler to artificially deliver it , rather than the one computed from > the version-of-the day of TextLiteral. But this too would not help those who would > rather not constantly download the latest, rebuild the compiler, then recompile their > applications. > > On 09/03/2013 01:02 AM, Jay K wrote: >> ok, another question: >> >> >> CONST >> (* DIV BITSIZE should not be here! *) >> (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) >> MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); >> >> TYPE >> T = RTHooks.TextLiteral; >> REVEAL >> T = TEXT BRANDED "TextLiteral.T" OBJECT >> cnt : INTEGER; >> buf : ARRAY [0..MaxBytes - 1] OF Byte; >> OVERRIDES ... >> >> >> T is a reference type. >> Is there a way to state this with no limit? >> >> >> Isn't it already unsafe? >> You know -- the array is usually smaller and the compiler is only going to check against this large size. >> >> >> - Jay > From jay.krell at cornell.edu Fri Sep 6 02:06:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Sep 2013 00:06:41 +0000 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: <522894AE.2070708@lcwb.coop> References: , , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , , , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>, , <522894AE.2070708@lcwb.coop> Message-ID: > > How do I declare an unbouned-ly sized array? > > You use an open array. Then the compiler arranges to store its bound at runtime, > using that instead of a static constant when generating bounds checks. Sorry, I meant a pointer that I can index arbitrarily far. I think this is just UNTRACED REF T . > . In at least some targets, these are also stored in readonly segments as well. Surely this is all targets these days/years/decades. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Sep 6 22:01:36 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 15:01:36 -0500 Subject: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more? In-Reply-To: References: , , , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, , , , <1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>, , <522894AE.2070708@lcwb.coop> Message-ID: <522A34A0.50307@lcwb.coop> On 09/05/2013 07:06 PM, Jay K wrote: > > > How do I declare an unbouned-ly sized array? > > > > You use an open array. Then the compiler arranges to store its bound at runtime, > > using that instead of a static constant when generating bounds checks. > > Sorry, I meant a pointer that I can index arbitrarily far. > I think this is just UNTRACED REF T . Ah, do you mean you want to disable the bounds check? Using the ARRAY types of Modula-3, I don't believe you can. I think I recall some kind of compiler option, not so easy to find, that will do this, but I think unselectively for all subscripted array references in, perhaps an entire source file. Based on painful experiences of my own and others, going a long way back, I never do this. For single-character-at-a-time, you can avoid array types altogether something like: Element I of Array A, of elements of type ET: LOOPHOLE(ADR(A[0]) + (I-FIRST(A))*ADRSIZE(ET), UNTRACED REF ET)^ But watch out for sub-adr-sized or non-integral-adr-sized elements! > > > . In at least some targets, these are also stored in readonly segments as well. > > Surely this is all targets these days/years/decades. > > - Jay From rodney_bates at lcwb.coop Fri Sep 6 22:12:55 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 15:12:55 -0500 Subject: [M3devel] TextLiteral.MaxBytes again In-Reply-To: <35F457AE-9FD1-4E16-906E-F3CFAB657102@cs.purdue.edu> References: <52289869.4000301@lcwb.coop> <35F457AE-9FD1-4E16-906E-F3CFAB657102@cs.purdue.edu> Message-ID: <522A3747.7060105@lcwb.coop> On 09/05/2013 11:05 AM, Tony Hosking wrote: > Here is a modest proposal that should resolve this issue. > Declare TextLiteral.T to have a minimal buf: ARRAY [0..0] OF Byte; > Then use UNSAFE address arithmetic to access the bytes (TextLiteral.m3 already does the bounds checks explicitly using cnt). > > Updated TextLiteral.i3 and TextLiteral.m3 attached. > That would address the changing fingerprint problem. The declaration of buf should have a conspicuous and unambiguous "Keep your hands off" comment, with explanation why. > > > > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Mobile +1 765 427 5484 > > > > > > On Sep 5, 2013, at 10:42 AM, "Rodney M. Bates" wrote: > >> There is another issue here. I want TextLiteral.MaxBytes to get a final size >> and not change. Every time it changes, it creates compatibility problems by >> orphaning any existing pickle files and any compiled programs that write them. >> It changes the fingerprint, so a recently-compiled reading program can't find the >> type in its own list of known types. This also affects network objects when two >> communicating programs are compiled with different TextLiteral versions. >> >> MaxBytes' particular contribution to the type doesn't otherwise matter, because it's >> artificial, but it still undermines reading pickles. >> >> I have been loading up the pickle reading code with hard-coded historical fingerprints >> of various older versions. But it's a pain to keep doing, tedious to ferret out the >> values, and it still only helps those who constantly download and compile the latest >> CM3. >> >> At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint >> and hard-coding the compiler to artificially deliver it , rather than the one computed from >> the version-of-the day of TextLiteral. But this too would not help those who would >> rather not constantly download the latest, rebuild the compiler, then recompile their >> applications. >> >> On 09/03/2013 01:02 AM, Jay K wrote: >>> ok, another question: >>> >>> >>> CONST >>> (* DIV BITSIZE should not be here! *) >>> (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *) >>> MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); >>> >>> TYPE >>> T = RTHooks.TextLiteral; >>> REVEAL >>> T = TEXT BRANDED "TextLiteral.T" OBJECT >>> cnt : INTEGER; >>> buf : ARRAY [0..MaxBytes - 1] OF Byte; >>> OVERRIDES ... >>> >>> >>> T is a reference type. >>> Is there a way to state this with no limit? >>> >>> >>> Isn't it already unsafe? >>> You know -- the array is usually smaller and the compiler is only going to check against this large size. >>> >>> >>> - Jay >> > From rodney_bates at lcwb.coop Fri Sep 6 22:39:14 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 15:39:14 -0500 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: Message-ID: <522A3D72.1050402@lcwb.coop> On 09/04/2013 01:28 AM, Jay K wrote: > AMD64_NT starting up mentor: > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\EventWireRep.m3", line 89 > *** > > > This opens up a big multi-part can of worms. > I'm not sure the order to present things. > Please bear with me. > > > > Background: > > Time.T is a double/longreal number of seconds since a platform-specific epoch. > This cleverly gives I guess pretty good range and precison. > On Windows, that is 1601. > The underlying system stores 64bit 100s of nanoseconds. > This gives both good range and precision. > And it works ok with Modula-3. > On Posix is presumably 1970. > This is all ok. Not controversial. > > > > Corralaries: > > Time.Now on Windows returns around 1.3022747815483961e10. > My simple math says that is off by a month but hopefully > more precise math says it is exactly correct. > We have confusing Modula-3 code and straightforward C code to compute this. > That it is within a month seems adequate to backup everything > else I'm seeing/saying. > > > events!EventWireRep_M3 [c:\dev2\cm3\m3-comm\events\src\eventwirerep.m3 @ 90] > > Int32 = BITS 32 FOR [-2147483647-1..2147483647]; > TRep = RECORD ts: Int32; objNum: Int32; space: EventSpaceID.T; END; > > VAR myTs: Int32 := ROUND(Time.Now()); > > > Clearly this is a problem. > It runs out "soon" on 32bit Posix systems, it runs out > already on Win64, and on Win32, well, it produces > garbage one way or another, but no range errors. > > > On AMD64_NT, this reasonably rounds to > > 13022747815 -- the full integer value of the double > fits in a 64bit integer. > > But it doesn't fit in 32 bits. > On I386_NT, this somewhat "correctly" rounds to > -2147483648 > > Hm. Shouldn't it be nearest integer 2147483647?? > > > In either case, see you the problem. > > Ok, so this is three dilemnas/questions/bugs in one. > > > http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arithmetic_operations.html > > > ROUND(r) is the nearest integer to r; ties are broken according to the constant RoundDefault > This has an ambiguity. "nearest integer" could refer to the integers of mathematics, or to INTEGER of Modula-3. The lowercase spelling hints the former. I think that makes more sense, too. By the latter interpretation, values would round to LAST(INTEGER) from far beyond. By the former interpretation, if the nearest math integer is > LAST(INTEGER), there should be runtime error of some kind. But we can't rely on the assignment operation and Modula-3's assignability rules to do that, because ROUND would have to have a result type, big enough for all possibilities, a supertype of INTEGER. There is no such type, and we don't want one. (Ever had to cope with Ada's "universal integer" type? If not, you're lucky.) Which leaves making the check part of ROUND itself. > > 1) How should ROUND be defined? Is Modula-3 adequately safe here? > > > What should round of numbers less than FIRST(INTEGER)-1 > or greater than LAST(INTEGER) + 1 round to? > > > By the simple definition, they should round to FIRST(INTEGER) > and LAST(INTEGER). But is it safe? > > > You know, I can see taking the whole part of the number > and losing the fractional part as being ok when desired, > but when the whole part doesn't fit, not even when rounded > up or down by 1? Doesn't that seem like it should be a range error? > > > > 2) What is up with the various implementations? > > > ASSUMING Modula-3 ROUND is defined safely enough, > is the integrated NT/x86 backend correct here? > > > On I386_DARWIN: > > IMPORT IO, Fmt; > > BEGIN > IO.Put(Fmt.Int(ROUND(1.3022747815483961e10)) & "\n"); > END Main. > > > We get: 137845760. > > > Wow, that is just wrong. > Sure it got the mantissa close, but the exponent is arbitrary seeming. > I could chalk this up to a bug in my C backend, > but it gets constant folded in the front end. > The backend just gets load_integer 137845760. > This seems highly incorrect. > Maybe bugs in Target.Float? > Maybe overflow is being ignored?? > I'll look later, another day. > > > > 3) What to do? > > > 3a) The frontend seems wrong here, no matter what. > > 3b) The integrated backend seems at least slightly wrong. > > 3c) The events code either needs widening, or perhaps > this isn't time, but a somewhat arbitrary "fingerprint". > Perhaps it can just use MOD?? I will likely verify if it needs to be > time or just a reasonably volatile number to cross check sender/reciever > and then use MOD. Posix and Win32 systems probably can't talk to each other. Lame. > > > > Someone might suggest that Win32 epoch be changed to 1970. > I don't think so. > > > 4) can anyone understand and explain the Modula-3 code we have here in Time.m3? > > > > Thank you, > - Jay From rodney_bates at lcwb.coop Fri Sep 6 23:03:50 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Sep 2013 16:03:50 -0500 Subject: [M3devel] rounding very large magnitude longreal, time, events? In-Reply-To: References: , , <20130904064212.318CF1A2080@async.async.caltech.edu>, , <20130904163217.C90041A2080@async.async.caltech.edu> , <95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com> Message-ID: <522A4336.7000709@lcwb.coop> On 09/04/2013 12:49 PM, Jay K wrote: > I want both. > > > We check subrange assignments. > This seems almost the same thing. > When a programming converts float to int, what do they accept they are losing? > Precision or range or both? > I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check. > > > The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation. > Yes, that's always a dilemma. I tend to prefer accepting some constant-time micro-efficiency penalties for more predictable and tractable behavior. > > Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors? My definition of safety is that everything that can happen can be defined or understood, using only the high-level concepts of the language, e.g., abstract values of types and operators on them, but not machine-level bits, representations, etc. This is contrary to every textbook and article I have ever read, but the traditional definitions are, IMO, neither of much use nor consistent with what people seem, informally, to mean by it. So what ROUND does could be defined using integers and floating point values. (Some ways of defining it might, however, just refer to bit-level representations.) > Our obligation is only type safety? No, safety is not our only obligation. Thinking only in terms of abstract values, operators could still be poorly defined or defined in ways that are not very meaningful. Right now, ROUND seems not to be defined for these cases. > round/trunc/ceiling can return random numbers and still be type safe? If the random values are members of INTEGER, repeatable, and definable via some rule that doesn't refer to machine-level representations, that would fit my definition of type safe, but that is not sufficient for good language design. As for efficiency, I believe that in this case, either rounding far-out-of-range to a limit of INTEGER or making it a runtime error would require runtime range checks by the implementation anyway. The only difference is what to do when the check fails. Personally, I would like it better if overflows were detected on the arithmetic operators too. This excludes Word.T, which is, I think the only place the language forbids it. > (round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...) > > > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > From: antony.hosking at gmail.com > Date: Wed, 4 Sep 2013 13:31:01 -0400 > CC: mika at async.caltech.edu; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked. > > On Sep 4, 2013, at 1:00 PM, Jay K > wrote: > > > Well, I agree wholeheartedly, yes. > > > Tony: can we put in range checks on float to int conversions? > I'd be ok with initially: > if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1 > error > > The "1" isn't quite right, but "0" is also wrong. > > > I'd like to see what Java and C# do also (safe/optionally safe languages in good standing). > > And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon". > > > - Jay > > > > To:jay.krell at cornell.edu > > Date: Wed, 4 Sep 2013 09:32:17 -0700 > > From:mika at async.caltech.edu > > CC:m3devel at elegosoft.com > > Subject: Re: [M3devel] rounding very large magnitude longreal, time, events? > > > > Jay K writes: > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/plain; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > > > > > > > >I wish=2C but no=2C it is the same as the others. > > > > I see... > > > > > > > > > > >It is all a bit subtle. > > > > As always... > > > > > > > ... > > > > > > > > >I believe=2C based on what you are saying=2C > > >the frontend should generate range checks before > > >floor/trunc/ceiling. > > > > > >Roughly it should be an error to convert > > >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double. > > >Plus or minus one though. > > > > > > > > >That is=2C > > > FLOOR(LAST(INTEGER) + .99999) is ok. > > > CEILING(FIRST(INTEGER) - .99999) is ok. > > > ROUND(LAST(INTEGER) - .499999) is ok. > > > ROUND(FIRST(INTEGER) + .499999) is ok. > > >=20 > > > > > >I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok. > > > > > > > > >Oh wait. It depends on the relative ranges of float and integer. > > > > > > > > >In particular=2C a 53bit mantissa longreal converted to a 32bit integer > > >needs the checks I describe. But a 53bit mantissa converted to > > >a 64bit integer=2C no range check is needed. > > > > > > > > >The frontend has some of those optimizations already -- converting > > >from a smaller range to a larger range needs no check. > > > > > > > > >Agreed? Surely this is not a difficult change? > > > > Well, I agree wholeheartedly, yes. > > > > >Nor particularly inefficient? > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > >> To: jay.krell at cornell.edu > > >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C = > > >events? > > >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700 > > >> From: mika at async.caltech.edu > > >>=20 > > >> Jay K writes: > > >> ... > > >> > > > >> >Ok=3D2C so this is three dilemnas/questions/bugs in one. > > >> > > > >> > > > >> >http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith= > > >met=3D > > >> >ic_operations.html > > >> > > > >> > > > >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t= > > >he co=3D > > >> >nstant RoundDefault > > >> > > > >> > > > >> >1) How should ROUND be defined? Is Modula-3 adequately safe here? > > >> > > > >> > > > >> > What should round of numbers less than FIRST(INTEGER)-1=3D20 > > >> > or greater than LAST(INTEGER) + 1 round to?=3D20 > > >> > > > >> > > > >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20 > > >> > and LAST(INTEGER). But is it safe? > > >> > > > >>=20 > > >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i= > > >s=2C > > >> "integer" is the abstract mathematical concept of an integer=2C not the > > >> Modula-3 data type INTEGER. > > >>=20 > > >> I think the intent of the Green Book is that INTEGER should be a range-li= > > >mited > > >> form of integer=2C that is=2C it should behave like an integer as much as= > > > possible=2C > > >> and when the implementation can no longer accomplish that=2C it should si= > > >gnal a=20 > > >> runtime error. =20 > > >>=20 > > >> It happens that many existing implementions of Modula-3=2C as an implemen= > > >tation > > >> restriction=2C do not handle out-of-range situations correctly. Things > > >> such as what you describe SHOULD lead to a runtime error=2C value out of = > > >range. > > >> Some implementations wrap instead=2C but I don't even think that's right.= > > > Of > > >> course it's not as bad as it might be in C where you might be indexing an > > >> array with the incorrectly calculated integer and send your program off i= > > >n > > >> never-never land. In Modula-3 you'll at least get a runtime error at THA= > > >T > > >> point. But it's still not right. > > >>=20 > > >> If I am understanding properly what is going on I think this means your n= > > >ew > > >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement= > > >ation. > > >>=20 > > >> Mika > > > = > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_ > > >Content-Type: text/html; charset="iso-8859-1" > > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > > >
>=3B If I am understanding pro= > > >perly what is going on I think this means your new
>=3B Modula-3-to-C = > > >compiler is the most reasonably behaving Modula-3 implementation.

> >r>I wish=2C but no=2C it is the same as the others.


It is all a = > > >bit subtle.


Here is what I believe happens:


I386_NT: = > > >from any double=2C round will give us
some integer=2C a 32bit integer=2C= > > > that can be
successfully assigned to this range=2C with or without
a= > > > range check.


m3cc: Posix: The values are in range.
With or w= > > >ithout a range check=2C the code succeeds.
For a "few" more years.
> >r>
C backend: Similar.
I'm using the C backend all the time on Darwon= > > >.
Again=2C Posix: the values are in range.
I386_NT: round will give u= > > >s a 32bit integer and it will "work"
AMD64_NT: round gives us a 64bit in= > > >teger=2C the range check fails.


In a "few" years=2C 64bit Posix = > > >systems will fail here.
32bit Posix would continue to round to some 32bi= > > >t integer=2C which would then
successfully pass into the identical subra= > > >nge -- like I386_NT today.



The backends don't add range chec= > > >ks.
Mostly or entirely=2C they should not.
As long as the frontend kn= > > >ows enough=2C it should do it.
The frontend knows the range of INTEGER a= > > >nd at least roughly
the range of longreal.
Possibly the range of a lo= > > >ngreal is target-dependent and knowledge
of it should only exist in the = > > >backend. In reality=2C as long as you ignore VAX=2C
roughly everything i= > > >s the same since around the early 1980s.



I believe=2C based = > > >on what you are saying=2C
the frontend should generate range checks befo= > > >re
floor/trunc/ceiling.

Roughly it should be an error to convert<= > > >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.
Pl= > > >us or minus one though.


That is=2C
 =3BFLOOR(LAST(INTEGER= > > >) + .99999) is ok.
 =3BCEILING(FIRST(INTEGER) - .99999) is ok.
&n= > > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.
 =3BROUND(FIRST(INTEGER)= > > > + .499999) is ok.
 =3B

I'm not sure where "round to even" is= > > >=2C so -.5 and +.5 might be ok.


Oh wait. It depends on the relat= > > >ive ranges of float and integer.


In particular=2C a 53bit mantis= > > >sa longreal converted to a 32bit integer
needs the checks I describe. Bu= > > >t a 53bit mantissa converted to
a 64bit integer=2C no range check is nee= > > >ded.


The frontend has some of those optimizations already -- con= > > >verting
from a smaller range to a larger range needs no check.

> >r>Agreed? Surely this is not a difficult change?
Nor particularly ineffi= > > >cient?



 =3B- Jay




>=3B To: jay.= > > >krell at cornell.edu
>=3B Subject: Re: [M3devel] rounding very large magn= > > >itude longreal=2C time=2C events?
>=3B Date: Tue=2C 3 Sep 2013 23:42:1= > > >2 -0700
>=3B From: mika at async.caltech.edu
>=3B
>=3B Jay K w= > > >rites:
>=3B ...
>=3B >=3B
>=3B >=3BOk=3D2C so this is th= > > >ree dilemnas/questions/bugs in one.
>=3B >=3B
>=3B >=3B
&g= > > >t=3B >=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= > > >_10Arithmet=3D
>=3B >=3Bic_operations.html
>=3B >=3B
>= > > >=3B >=3B
>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a= > > >re broken according to the co=3D
>=3B >=3Bnstant RoundDefault
>= > > >=3B >=3B
>=3B >=3B
>=3B >=3B1) How should ROUND be defined?= > > > Is Modula-3 adequately safe here?
>=3B >=3B
>=3B >=3B
>= > > >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20
= > > >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20
>=3B &g= > > >t=3B
>=3B >=3B
>=3B >=3B By the simple definition=3D2C they s= > > >hould round to FIRST(INTEGER)=3D20
>=3B >=3B and LAST(INTEGER). But = > > >is it safe?
>=3B >=3B
>=3B
>=3B No=2C I read the definiti= > > >on as saying "integer"=2C not "INTEGER". That is=2C
>=3B "integer" is= > > > the abstract mathematical concept of an integer=2C not the
>=3B Modul= > > >a-3 data type INTEGER.
>=3B
>=3B I think the intent of the Green= > > > Book is that INTEGER should be a range-limited
>=3B form of integer= > > >=2C that is=2C it should behave like an integer as much as possible=2C
&= > > >gt=3B and when the implementation can no longer accomplish that=2C it shoul= > > >d signal a
>=3B runtime error.
>=3B
>=3B It happens tha= > > >t many existing implementions of Modula-3=2C as an implementation
>=3B= > > > restriction=2C do not handle out-of-range situations correctly. Things > >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o= > > >ut of range.
>=3B Some implementations wrap instead=2C but I don't eve= > > >n think that's right. Of
>=3B course it's not as bad as it might be i= > > >n C where you might be indexing an
>=3B array with the incorrectly cal= > > >culated integer and send your program off in
>=3B never-never land. I= > > >n Modula-3 you'll at least get a runtime error at THAT
>=3B point. Bu= > > >t it's still not right.
>=3B
>=3B If I am understanding properly= > > > what is going on I think this means your new
>=3B Modula-3-to-C compi= > > >ler is the most reasonably behaving Modula-3 implementation.
>=3B
= > > >>=3B Mika
> > >= > > > > > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_-- > > From jay.krell at cornell.edu Sun Sep 8 05:21:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 03:21:56 +0000 Subject: [M3devel] should C backend output K&R, ANSI C, or C++? Message-ID: Any preferences/rationale for C backend to output: 1) K&R C 2) ANSI C 3) C++ Even gcc now requires a C++ compiler to bootstrap. C++ hypothetically offers us a chance for efficient exception handing. HPUX/HPPA bundled C compiler is K&R only. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 05:48:00 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 03:48:00 +0000 Subject: [M3devel] python build problems Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL> Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 8 05:54:41 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 8 Sep 2013 03:54:41 +0000 Subject: [M3devel] python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 8 06:14:37 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 04:14:37 +0000 Subject: [M3devel] python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: 1. I removed the Cstdint requirement, please try again. Sorry about that. 2. The order of the build is not defined by the list you show. That is an unordered set and it is passed through code to honor the pkginfo.txt information. 2b. Though it looks like upgrade.sh doesn't apply the ordering and just strives to get it right earlier, so you could refer to that. But the Python definitely takes unordered lists and applies the ordering from pkginfo.txt. Look for "Order" in pylib.py if carouse. 3. IF you hit the _xmm error before building mklib.. the workaround will be to bootstrap w/o shared libraries. You didn't report that, and there is code to avoid shared libraries with older tools. - Jay From: jayk123 at hotmail.com To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 8 Sep 2013 03:54:41 +0000 Subject: Re: [M3devel] python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 06:23:48 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 04:23:48 +0000 Subject: [M3devel] python build problems Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL> Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 8 06:39:46 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 8 Sep 2013 04:39:46 +0000 Subject: [M3devel] python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 07:13:10 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 05:13:10 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL> Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 8 07:19:54 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 8 Sep 2013 05:19:54 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL> Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed ________________________________ From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn ________________________________ From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 8 07:58:57 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 8 Sep 2013 05:58:57 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: sorry, yes, please try again From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:19:54 +0000 Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 8 08:59:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 06:59:05 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: Randy, if you give up, try this? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130907.zip - Jay From: jayk123 at hotmail.com To: rcolebur at scires.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:58:57 +0000 sorry, yes, please try again From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:19:54 +0000 Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 8 09:48:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Sep 2013 07:48:57 +0000 Subject: [M3devel] EXT:RE: python build problems In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>, , , , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>, , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>, , , Message-ID: here, more complete: https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-d5.9.0-VC110-20130908.msi https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-d5.9.0-VC110-20130908-symbols.zip https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-d5.9.0-VC110-20130908.zip https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130908.msi https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130908-symbols.zip https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130908.zip - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 8 Sep 2013 06:59:05 +0000 Subject: Re: [M3devel] EXT:RE: python build problems Randy, if you give up, try this? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-d5.9.0-VC110-20130907.zip - Jay From: jayk123 at hotmail.com To: rcolebur at scires.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:58:57 +0000 sorry, yes, please try again From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: EXT:RE: python build problems Date: Sun, 8 Sep 2013 05:19:54 +0000 Jay: Thanks for the removal of Cstdint dependency, but now there is a problem with Ctypes.unsigned in m3back: new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed From: Coleburn, Randy Sent: Sunday, September 08, 2013 1:13 AM To: Jay K; m3devel Subject: Re: [M3devel] EXT:RE: python build problems Jay: ok, thanks. I still can't get upgrade.py to work. Since I ran into trouble earlier, I reverted my pkg, bin, and lib folders back to a known good working copy circa 2008. Then, I copied the cm3install\src\config-no-install\cm3.cfg into the bin folder. Now when I try to build, it is defaulting to I386_NT instead of NT386. I guess I can go in and adjust the cm3.cfg to force NT386, but is there something else wrong? Thanks, --Randy From: Jay K [jayk123 at hotmail.com] Sent: Sunday, September 08, 2013 12:39 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems We crossed emails. The order in upgrade.py isn't the order run, it is filtered through pkginfo.txt. m3cgcat is not really needed here. I was using it a lot with the C backend, but no longer. m3bundle's presence here is questionable. It isn't used to build cm3. m3cggen is there for communicating rare but occurring changes to m3cc, so should be filtered out along with m3cc, optionally. mklib is only for NT targets. I would like to remove it, but that isn't trivial -- cm3 should produce the .def files and I guess list every function in every capital I Interface .i3 file. But it works. The unneeded stuff builds ok. - Jay From: rcolebur at SCIRES.COM To: jayk123 at hotmail.com; m3devel at elegosoft.com Subject: RE: python build problems Date: Sun, 8 Sep 2013 04:23:48 +0000 Jay: Thanks for your help. Re #3 below, if I put mklib back in, the order my script gets for the 1st step (front end) is: 1. m3-win\import-libs 2. m3-libs\sysutils 3. m3-sys\m3middle 4. m3-sys\m3objfile 5. m3-sys\m3linker 6. m3-sys\m3back 7. m3-sys\m3cggen 8. m3-sys\m3front 9. m3-sys\m3quake 10. m3-sys\cm3 11. m3-sys\m3cgcat 12. m3-sys\mklib whereas, upgrade.py compiles the following in order for the 1st step (front end): 1. "import-libs" 2. "m3bundle" 3. "m3middle" 4. "m3quake" 5. "m3objfile" 6. "m3linker" 7. "m3back" 8. "m3front" 9. "sysutils" 10. "cm3" 11. "m3cggen" 12. "mklib" 13. "m3cgcat" If Re#2 you say the order in pkginfo.txt is correct, then my script must be interpreting something wrong if the order in upgrade.py is what should be used, or either you have some reason for doing it different in upgrade.py. Please advise. Re#4, are you saying I should try one of these "fixes" or is that something you plan to do? Re#1, I'll hold off further work till you let me know. Also, I'm not sure whether my old cm3 had LONGINT in it or not. Is there an easy way to tell? Thanks, Randy Coleburn From: Jay K [jayk123 at hotmail.com] Sent: Saturday, September 07, 2013 11:54 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: python build problems 1. I'll remove the Cstdint dependency. That is in newer m3core. But you are correctly using an older m3core for the bootstrap. Please give me a bit of time. Maybe tonight. Does your cm3 provide LONGINT? 2. The order is correct in pkginfo.txt. 3. The problem wasn't the order but which you were building. You were missing mklib. You need a newer mklib to fix the "_xmm" problem. Look at upgrade.py or upgrade.sh closely. 4. AttributeError: 'NoneType' object has no attribute 'startswith' Probably due to an older cm3 that doesn't output host/target. Maybe fixable with set CM3_TARGET=I386_NT or NT386 or such. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: python build problems Date: Sun, 8 Sep 2013 03:48:00 +0000 Jay: I'm still having lots of problems. I installed python 2.7 on WinXP-32bit and tried upgrade.py against a working cm3 circa 2008. I get the following error: Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in if Target.startswith("NT386"): AttributeError: 'NoneType' object has no attribute 'startswith' Looking at upgrade.py, it seems the first set of compilations is in the following order: "import-libs", "m3bundle", "m3middle", "m3quake", "m3objfile", "m3linker", "m3back", "m3front", "sysutils", "cm3", "m3cggen", "mklib", "m3cgcat" So, I tried to manually follow this order by cd to each folder, removing the NT386, running cm3, then cm3 -ship. Things go well until I get to m3back, where I get the following error: C:\cm3\Sandbox\cm3\m3-sys\m3back>cm3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling TIntN.i3 new source -> compiling TIntN.m3 new source -> compiling TWordN.i3 new source -> compiling TWordN.m3 new source -> compiling M3x86.i3 new source -> compiling Wrx86.i3 new source -> compiling M3x86Rep.i3 new source -> compiling Codex86.i3 new source -> compiling Stackx86.i3 new source -> compiling M3x86.m3 new source -> compiling M3C.i3 new source -> compiling M3C.m3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) "..\src\M3CC.i3", line 4: undefined (Cstdint.int32_t) "..\src\M3CC.i3", line 6: undefined (Cstdint.uint32_t) 3 errors encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 2: unable to find interface (Cstdint) 1 error encountered new source -> compiling Wrx86.m3 new source -> compiling Stackx86.m3 new source -> compiling Codex86.m3 new source -> compiling M3CC.c new exporters -> recompiling M3C.i3 new exporters -> recompiling M3x86Rep.i3 compilation failed => not building library "m3back.lib" Fatal Error: package build failed Any suggestions on what to do? I need to get a working cm3 on both WinXP and Win7 that is current with the HEAD branch. BTW, it was my understanding that the compilation order was defined in "pkginfo.txt". Has this changed, or is the file not up-to-date? Reason I ask is that my RCC_upgradeCM3.cmd used to work fine and it bases the order on pkginfo.txt, yet you remarked in a previous post that I was leaving something out, plus it seems the order in upgrade.py doesn't match what you find in pkginfo.txt. Please advise. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Sep 8 10:40:42 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 8 Sep 2013 10:40:42 +0200 Subject: [M3devel] AMD64_NT In-Reply-To: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> References: <58F0BCAF-CFEB-424B-8294-AC3A093ED1BF@gmail.com> Message-ID: At last some use for all those Win64's laying around! :) Great work!!! -- Dragi?a Duri? dragisha at m3w.org On Sep 3, 2013, at 6:06 PM, Jay wrote: > AMD_NT runs, can build itself, is more debuggable than NT386, Juno & formsedit come up. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rcolebur at SCIRES.COM Wed Sep 11 23:21:06 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 11 Sep 2013 21:21:06 +0000 Subject: [M3devel] still having trouble building on WinXP Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1C355@ATLEX04-SRV.SCIRES.LOCAL> Jay: I've updated my sandbox again to be current with the HEAD branch. My computer is running Windows XP (32 bit), my installed cm3 system is a working edition circa 2008, and I have Python v2.7.3 installed. If I try to upgrade to the latest sources in my Sandbox, I run into trouble. 1. Using the python scripts, I run into a problem right away: C:\cm3\Sandbox\cm3\scripts\python>\Python27\python.exe upgrade.py Traceback (most recent call last): File "upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' 2. If I try my script, or if I try to rebuild manually, I run into an error trying to build "m3back" due to undefined Ctypes.unsigned: new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered Can the dependency on Ctypes.unsigned be removed, or is there a way to fix the error? Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 12 02:38:55 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Sep 2013 00:38:55 +0000 Subject: [M3devel] still having trouble building on WinXP In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1C355@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1C355@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: > Can the dependency on Ctypes.unsigned be removed, or is there a way to fix the error? Is it really still broken? This is trivial. Ctypes.unsigned has been around forever. I could have sworn I commited the trivial fix. I'll look again tonight. It just needs to say: IMPORT Ctypes; TYPE whatever = Ctypes.unsigned or unsigned_int; It is all absolutely trivial. I can't well paste in the definition of Ctypes.unsigned, because it varies between 32bit and 64bit. Ctypes is a portability bridge for 32bit vs. 64bit. 32bit unsigned is Word.T. 64bit unsigned is range 0...2^32-1. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: still having trouble building on WinXP Date: Wed, 11 Sep 2013 21:21:06 +0000 Jay: I?ve updated my sandbox again to be current with the HEAD branch. My computer is running Windows XP (32 bit), my installed cm3 system is a working edition circa 2008, and I have Python v2.7.3 installed. If I try to upgrade to the latest sources in my Sandbox, I run into trouble. 1. Using the python scripts, I run into a problem right away: C:\cm3\Sandbox\cm3\scripts\python>\Python27\python.exe upgrade.py Traceback (most recent call last): File "upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' 2. If I try my script, or if I try to rebuild manually, I run into an error trying to build ?m3back? due to undefined Ctypes.unsigned: new source -> compiling M3C.m3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered new source -> compiling M3CC.i3 "..\src\M3CC.i3", line 6: undefined (Ctypes.unsigned) 1 error encountered Can the dependency on Ctypes.unsigned be removed, or is there a way to fix the error? Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 13 19:44:20 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 13 Sep 2013 13:44:20 -0400 Subject: [M3devel] Fwd: Output from "cron" command References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu> Message-ID: <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu> Compilation error in the build last night. Someone to fix? Begin forwarded message: > From: Tony Hosking > Subject: Output from "cron" command > Date: September 13, 2013 7:45:25 AM EDT > To: hosking at cs.purdue.edu > > Your "cron" job on niagara.cs.purdue.edu > $HOME/cm3/scripts/regression/cron.sh > > produced the following output: > > GMAKE=gmake > export GMAKE > TAR=gtar > export TAR > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-10-30-05 > LASTREL=5.8.6 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com... > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara release-build" > > creating log file /tmp/build-cm3-20130913-063007-WkaiLK/log.txt > > --- > > checkout, compile and test of cm3 ... > 2013.09.13 06:30:07 -- checkout in progress. > [start checkout 2013.09.13 06:30:10] > cd /tmp/build-cm3-20130913-063007-WkaiLK/build > cvs return value: 0 > [end checkout 2013.09.13 06:57:52] > CHECKOUT_RETURN = 0 > -- > 2013.09.13 06:57:56 -- compile in progress. > [start compile 2013.09.13 06:57:56] > compile return value: 1 > [end compile 2013.09.13 07:06:12] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20130913-063007-WkaiLK ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > cleanup_all_but_last_n > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-00-09-00 > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > cleanup_all_but_last_n > cleanup_all_but_last_n > > done with cleanup_all > GMAKE=gmake > export GMAKE > TAR=gtar > export TAR > TESTHOSTNAME=niagara > WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-11-08-49 > LASTREL=5.8.6 > INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 > INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok > INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok > INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current > CM3_OSTYPE=POSIX > CM3_TARGET=SOLgnu > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSSERVER=birch.elegosoft.com > CM3CVSROOT=birch.elegosoft.com:/usr/cvs > BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz > BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz > CM3CVSUSER= > testing ssh birch.elegosoft.com... > ssh birch.elegosoft.com ok > Building cm3. > Tinderbox Tree: "cm3" > Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" > > creating log file /tmp/build-cm3-20130913-070852-tWayTR/log.txt > > --- > > checkout, compile and test of cm3 ... > 2013.09.13 07:08:52 -- checkout in progress. > [start checkout 2013.09.13 07:08:54] > cd /tmp/build-cm3-20130913-070852-tWayTR/build > cvs return value: 0 > [end checkout 2013.09.13 07:24:59] > CHECKOUT_RETURN = 0 > -- > 2013.09.13 07:25:05 -- compile in progress. > [start compile 2013.09.13 07:25:05] > compile return value: 1 > [end compile 2013.09.13 07:42:50] > COMPILE_RETURN = 1 > *** COMPILE FAILED > removing build tree /tmp/build-cm3-20130913-070852-tWayTR ... > cleaning CM3 workspaces... > /homes/hosking/work/cm3-ws/niagara-* > cleanup_all_but_last_n > cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-10-30-03 > > cleaning regression test log files... > /homes/hosking/tmp/cm3/niagara/cm3-rlog-* > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning m3test log files... > /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr > cleanup_all_but_last_n > cleanup_all_but_last_n > > /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning snapshot files... > /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz > cleanup_all_but_last_n > cleanup_all_but_last_n > > cleaning package reports... > /tmp/cm3-pkg-report-SOLgnu-*.html > cleanup_all_but_last_n > cleanup_all_but_last_n > > done with cleanup_all > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 13 21:14:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 13 Sep 2013 19:14:00 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu> References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu>, <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu> Message-ID: Logs not very informative. Just started last night? Was succeeding the day before? From: hosking at cs.purdue.edu Date: Fri, 13 Sep 2013 13:44:20 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Fwd: Output from "cron" command Compilation error in the build last night.Someone to fix? Begin forwarded message:From: Tony Hosking Subject: Output from "cron" command Date: September 13, 2013 7:45:25 AM EDT To: hosking at cs.purdue.edu Your "cron" job on niagara.cs.purdue.edu $HOME/cm3/scripts/regression/cron.sh produced the following output: GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-10-30-05 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara release-build" creating log file /tmp/build-cm3-20130913-063007-WkaiLK/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 06:30:07 -- checkout in progress. [start checkout 2013.09.13 06:30:10] cd /tmp/build-cm3-20130913-063007-WkaiLK/build cvs return value: 0 [end checkout 2013.09.13 06:57:52] CHECKOUT_RETURN = 0 -- 2013.09.13 06:57:56 -- compile in progress. [start compile 2013.09.13 06:57:56] compile return value: 1 [end compile 2013.09.13 07:06:12] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-063007-WkaiLK ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-00-09-00 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-11-08-49 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" creating log file /tmp/build-cm3-20130913-070852-tWayTR/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 07:08:52 -- checkout in progress. [start checkout 2013.09.13 07:08:54] cd /tmp/build-cm3-20130913-070852-tWayTR/build cvs return value: 0 [end checkout 2013.09.13 07:24:59] CHECKOUT_RETURN = 0 -- 2013.09.13 07:25:05 -- compile in progress. [start compile 2013.09.13 07:25:05] compile return value: 1 [end compile 2013.09.13 07:42:50] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-070852-tWayTR ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-10-30-03 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 16 07:26:13 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 16 Sep 2013 05:26:13 +0000 Subject: [M3devel] Fwd: Output from "cron" command In-Reply-To: References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu>, , <0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu>, Message-ID: Still a problem? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 13 Sep 2013 19:14:00 +0000 Subject: Re: [M3devel] Fwd: Output from "cron" command Logs not very informative. Just started last night? Was succeeding the day before? From: hosking at cs.purdue.edu Date: Fri, 13 Sep 2013 13:44:20 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Fwd: Output from "cron" command Compilation error in the build last night.Someone to fix? Begin forwarded message:From: Tony Hosking Subject: Output from "cron" command Date: September 13, 2013 7:45:25 AM EDT To: hosking at cs.purdue.edu Your "cron" job on niagara.cs.purdue.edu $HOME/cm3/scripts/regression/cron.sh produced the following output: GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-10-30-05 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara release-build" creating log file /tmp/build-cm3-20130913-063007-WkaiLK/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 06:30:07 -- checkout in progress. [start checkout 2013.09.13 06:30:10] cd /tmp/build-cm3-20130913-063007-WkaiLK/build cvs return value: 0 [end checkout 2013.09.13 06:57:52] CHECKOUT_RETURN = 0 -- 2013.09.13 06:57:56 -- compile in progress. [start compile 2013.09.13 06:57:56] compile return value: 1 [end compile 2013.09.13 07:06:12] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-063007-WkaiLK ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-00-09-00 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all GMAKE=gmake export GMAKE TAR=gtar export TAR TESTHOSTNAME=niagara WS=/homes/hosking/work/cm3-ws/niagara-2013-09-13-11-08-49 LASTREL=5.8.6 INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.8.6 INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current CM3_OSTYPE=POSIX CM3_TARGET=SOLgnu BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-bin-min-SOLgnu-5.8.6.tgz BINDISTMIN=/homes/hosking/work/cm3-bin-min-SOLgnu-5.8.6.tgz CM3CVSUSER= testing ssh birch.elegosoft.com... ssh birch.elegosoft.com ok Building cm3. Tinderbox Tree: "cm3" Buildname: "SOLgnu SunOS 5.10 niagara lastok-build" creating log file /tmp/build-cm3-20130913-070852-tWayTR/log.txt --- checkout, compile and test of cm3 ... 2013.09.13 07:08:52 -- checkout in progress. [start checkout 2013.09.13 07:08:54] cd /tmp/build-cm3-20130913-070852-tWayTR/build cvs return value: 0 [end checkout 2013.09.13 07:24:59] CHECKOUT_RETURN = 0 -- 2013.09.13 07:25:05 -- compile in progress. [start compile 2013.09.13 07:25:05] compile return value: 1 [end compile 2013.09.13 07:42:50] COMPILE_RETURN = 1 *** COMPILE FAILED removing build tree /tmp/build-cm3-20130913-070852-tWayTR ... cleaning CM3 workspaces... /homes/hosking/work/cm3-ws/niagara-* cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/work/cm3-ws/niagara-2013-09-11-10-30-03 cleaning regression test log files... /homes/hosking/tmp/cm3/niagara/cm3-rlog-* cleanup_all_but_last_n cleanup_all_but_last_n cleaning m3test log files... /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr cleanup_all_but_last_n cleanup_all_but_last_n /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract cleanup_all_but_last_n cleanup_all_but_last_n cleaning snapshot files... /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz cleanup_all_but_last_n cleanup_all_but_last_n cleaning package reports... /tmp/cm3-pkg-report-SOLgnu-*.html cleanup_all_but_last_n cleanup_all_but_last_n done with cleanup_all -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 17 18:44:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Sep 2013 16:44:17 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130917151045.6D7195DEB73@birch.elegosoft.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com> Message-ID: The OpenCSW machines can run SPARC64. There are full installs available here: http://modula3.elegosoft.com/cm3/uploaded-archives/ G5 Mac for Darwin/Linux?BSD should also be easy. Maybe I'll set mine up.. - Jay > Date: Tue, 17 Sep 2013 17:10:45 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/09/17 17:10:45 > > Modified files: > cm3/m3-comm/netobj/src/netobjrt/: Tag: devel_unicode StubLib.m3 > > Log message: > Add support for communication involving 64-bit big-endian machines. > Apparently, none existed when this was written. Apparently, nobody > has tried to do this. > > New support not tested for lack of access to such a machine, but > retested with no breakage on 64-LE. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcode at zoho.com Tue Sep 17 20:00:01 2013 From: microcode at zoho.com (microcode at zoho.com) Date: Tue, 17 Sep 2013 18:00:01 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: References: <20130917151045.6D7195DEB73@birch.elegosoft.com> Message-ID: <20130917180001.GA10942@zoho.com> Hi, Looking at the uploaded archives page, can anybody please explain the difference between all these versions and exactly what each one is? 1. Target Platform AMD64_SOLARIS 2. Target Platform I386_SOLARIS 3. Target Platform SOLgnu 4. Target Platform SOLsun 5. Target Platform SPARC32_SOLARIS 6. Target Platform SPARC64_SOLARIS 1 and 2 would seem obvious enough except that the existence of 3 and 4 suggests 1 and 2 may have been built with gcc or Solaris Studio. That means 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 are designed to run on. 5 and 6 would seem obvious except now we're back to wondering whether they were built with gcc or Solaris Studio. I didn't understand Jay's comment below. Do you guys not have Solaris SPARC boxes in your build farm? Thank you. Israel On Tue, Sep 17, 2013 at 04:44:17PM +0000, Jay K wrote: > The OpenCSW machines can run SPARC64. > There are full installs available here: > http://modula3.elegosoft.com/cm3/uploaded-archives/ > > > G5 Mac for Darwin/Linux?BSD should also be easy. Maybe I'll set mine up.. > > > - Jay > > > > Date: Tue, 17 Sep 2013 17:10:45 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/09/17 17:10:45 > > > > Modified files: > > cm3/m3-comm/netobj/src/netobjrt/: Tag: devel_unicode StubLib.m3 > > > > Log message: > > Add support for communication involving 64-bit big-endian machines. > > Apparently, none existed when this was written. Apparently, nobody > > has tried to do this. > > > > New support not tested for lack of access to such a machine, but > > retested with no breakage on 64-LE. > > > -- _ _ ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___ | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._> |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___. From jay.krell at cornell.edu Tue Sep 17 20:24:58 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Sep 2013 18:24:58 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130917180001.GA10942@zoho.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com>, , <20130917180001.GA10942@zoho.com> Message-ID: Historically: SOLgnu was 32bit SPARC on Solaris using gcc; Which linker? I don't know. SOLsun was 32bit SPARC on Solaris using Sun cc But these are essentially identical -- same jmpbuf size, same stack walker (there was one, it is disabled now), same switches to the gcc backend. Just a different command for compiling the little bit of C we have and for linking. The target naming used to be more ad-hoc. The config files can be fairly user edited to switch between cc and gcc. Any of the four AMD64/I386/SPARC32/SPARC64_SOLARIS can be built with cc or gcc. I favor cc. It likely gives us better code, and gives us a little variety-for-demonstrated-portability. There was a period where Sun cc wasn't cost free which is probably why there was some desire for gcc -- plus, if the user has gcc-specific code, they'd want gcc. There isn't a builtin easy way to switch between cc and gcc on a source file by source file basis. "platforms" are kind of overblown in Modula-3 -- far more is the same than is different. Heck, even in gcc, for a given architecture, most targets use the same ABI -- so linux/freebsd/netbsd/openbsd are basically all the same, esp. to the backend (vs. the driver that does pre-#defines..) With the C backend, they are even more the same. - Jay > Date: Tue, 17 Sep 2013 18:00:01 +0000 > From: microcode at zoho.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit big-endian > > Hi, > > Looking at the uploaded archives page, can anybody please explain the > difference between all these versions and exactly what each one is? > > 1. Target Platform AMD64_SOLARIS > 2. Target Platform I386_SOLARIS > 3. Target Platform SOLgnu > 4. Target Platform SOLsun > 5. Target Platform SPARC32_SOLARIS > 6. Target Platform SPARC64_SOLARIS > > 1 and 2 would seem obvious enough except that the existence of 3 and 4 > suggests 1 and 2 may have been built with gcc or Solaris Studio. That means > 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is > 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and > 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 > are designed to run on. 5 and 6 would seem obvious except now we're back to > wondering whether they were built with gcc or Solaris Studio. > > I didn't understand Jay's comment below. Do you guys not have Solaris SPARC > boxes in your build farm? > > Thank you. > > Israel > > On Tue, Sep 17, 2013 at 04:44:17PM +0000, Jay K wrote: > > The OpenCSW machines can run SPARC64. > > There are full installs available here: > > http://modula3.elegosoft.com/cm3/uploaded-archives/ > > > > > > G5 Mac for Darwin/Linux?BSD should also be easy. Maybe I'll set mine up.. > > > > > > - Jay > > > > > > > Date: Tue, 17 Sep 2013 17:10:45 +0000 > > > To: m3commit at elegosoft.com > > > From: rodney at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/09/17 17:10:45 > > > > > > Modified files: > > > cm3/m3-comm/netobj/src/netobjrt/: Tag: devel_unicode StubLib.m3 > > > > > > Log message: > > > Add support for communication involving 64-bit big-endian machines. > > > Apparently, none existed when this was written. Apparently, nobody > > > has tried to do this. > > > > > > New support not tested for lack of access to such a machine, but > > > retested with no breakage on 64-LE. > > > > > > > -- > _ _ > ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___ > | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._> > |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcode at zoho.com Tue Sep 17 20:33:09 2013 From: microcode at zoho.com (microcode at zoho.com) Date: Tue, 17 Sep 2013 18:33:09 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: References: <20130917151045.6D7195DEB73@birch.elegosoft.com> <20130917180001.GA10942@zoho.com> Message-ID: <20130917183309.GB10942@zoho.com> On Tue, Sep 17, 2013 at 06:24:58PM +0000, Jay K wrote: > Historically: > SOLgnu was 32bit SPARC on Solaris using gcc; Which linker? I don't know. > SOLsun was 32bit SPARC on Solaris using Sun cc Ok, that's what I suspected vis a vis gcc/cc but I didn't know what platform. Thanks. So what's the reason for SPARC32_Solaris? > The config files can be fairly user edited to switch between cc and gcc. > Any of the four AMD64/I386/SPARC32/SPARC64_SOLARIS can be built with cc or gcc. > I favor cc. It likely gives us better code, and gives us a little > variety-for-demonstrated-portability. Yes, certainly if you're building on Solaris then Solaris Studio (cc) is the obvious correct choice. So what about 5 and 6 below? Are they built with gcc or Solaris Studio? And is there an issue of not having access to SPARC build hardware? > > > > Looking at the uploaded archives page, can anybody please explain the > > difference between all these versions and exactly what each one is? > > > > 1. Target Platform AMD64_SOLARIS > > 2. Target Platform I386_SOLARIS > > 3. Target Platform SOLgnu > > 4. Target Platform SOLsun > > 5. Target Platform SPARC32_SOLARIS > > 6. Target Platform SPARC64_SOLARIS > > > > 1 and 2 would seem obvious enough except that the existence of 3 and 4 > > suggests 1 and 2 may have been built with gcc or Solaris Studio. That means > > 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is > > 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and > > 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 > > are designed to run on. 5 and 6 would seem obvious except now we're back to > > wondering whether they were built with gcc or Solaris Studio. > > > > I didn't understand Jay's comment below. Do you guys not have Solaris SPARC > > boxes in your build farm? > > > > Thank you. > > > > Israel From jay.krell at cornell.edu Tue Sep 17 23:05:39 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Sep 2013 21:05:39 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130917183309.GB10942@zoho.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com>, , <20130917180001.GA10942@zoho.com>, , <20130917183309.GB10942@zoho.com> Message-ID: SPARC32_SOLARIS is a new name for SOLsun/SOLgnu. Newer targets have followed a fairly "regular" naming scheme: PPC_DARWIN, I386_DARWIN, PPC_LINUX, AMD64_NT. Not sure if it should be PPC or PPC32, SPARC or SPARC32, I386 or X86 or IA32 or what, but ok. I introduced new names for the remaining few old style names: LINUXLIBC6 => I386_LINUX FreeBSD4 => I386_FREEBSD NT386 => I386_NT NT386GNU => I386_CYGWIN NetBSDv2 => I386_NETBSD The old names continue to be supported. We don't really need/want to encode precise versions in the names. See, it used to be there was a roughly one to one processor to OS mapping. So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86. This is no longer the case at all -- pretty much every system, except like AIX and Irix run on at least two processors. Our build infrastructure: Most likely I tested most/everything with gcc, but then settled on Sun cc. User can go and edit the config files if he prefers gcc. We have access to the opencsw machines for Solaris. I had a bunch of machines but I've downsized 1) what I own 2) what I'm running on what I have left. Olaf was the main person maintaining the infrastructure and he has little time. We are very short staffed. There is actually very little target-dependent anywhere in the Modula-3 system at this point. I removed all the rewritten Posix headers for example, replaced with a more portable layer. (i.e. no need to know exact layout and sizes of things). - Jay > Date: Tue, 17 Sep 2013 18:33:09 +0000 > From: microcode at zoho.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit big-endian > > On Tue, Sep 17, 2013 at 06:24:58PM +0000, Jay K wrote: > > Historically: > > SOLgnu was 32bit SPARC on Solaris using gcc; Which linker? I don't know. > > SOLsun was 32bit SPARC on Solaris using Sun cc > > Ok, that's what I suspected vis a vis gcc/cc but I didn't know what > platform. Thanks. So what's the reason for SPARC32_Solaris? > > > > The config files can be fairly user edited to switch between cc and gcc. > > Any of the four AMD64/I386/SPARC32/SPARC64_SOLARIS can be built with cc or gcc. > > I favor cc. It likely gives us better code, and gives us a little > > variety-for-demonstrated-portability. > > Yes, certainly if you're building on Solaris then Solaris Studio (cc) is the > obvious correct choice. > > So what about 5 and 6 below? Are they built with gcc or Solaris Studio? > > And is there an issue of not having access to SPARC build hardware? > > > > > > > Looking at the uploaded archives page, can anybody please explain the > > > difference between all these versions and exactly what each one is? > > > > > > 1. Target Platform AMD64_SOLARIS > > > 2. Target Platform I386_SOLARIS > > > 3. Target Platform SOLgnu > > > 4. Target Platform SOLsun > > > 5. Target Platform SPARC32_SOLARIS > > > 6. Target Platform SPARC64_SOLARIS > > > > > > 1 and 2 would seem obvious enough except that the existence of 3 and 4 > > > suggests 1 and 2 may have been built with gcc or Solaris Studio. That means > > > 1 and 2 aren't obvious anymore, nor are 3 or 4. All I can tell from this is > > > 1 and 2 are 64 and 32 bit versions for Solaris Intel and 5 and 6 are 32 and > > > 64 bit versions for Solaris SPARC. I don't know what architecture 3 and 4 > > > are designed to run on. 5 and 6 would seem obvious except now we're back to > > > wondering whether they were built with gcc or Solaris Studio. > > > > > > I didn't understand Jay's comment below. Do you guys not have Solaris SPARC > > > boxes in your build farm? > > > > > > Thank you. > > > > > > Israel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microcode at zoho.com Wed Sep 18 10:15:02 2013 From: microcode at zoho.com (microcode at zoho.com) Date: Wed, 18 Sep 2013 08:15:02 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: References: <20130917151045.6D7195DEB73@birch.elegosoft.com> <20130917180001.GA10942@zoho.com> <20130917183309.GB10942@zoho.com> Message-ID: <20130918081502.GA12109@zoho.com> On Tue, Sep 17, 2013 at 09:05:39PM +0000, Jay K wrote: > SPARC32_SOLARIS is a new name for SOLsun/SOLgnu. But which? Sun cc or gcc? And then it would seem from your comment there is at least one duplicate download. This is confusing. > Not sure if it should be PPC or PPC32, SPARC or SPARC32, > I386 or X86 or IA32 or what, but ok. With i386, x86, and IA32 everybody understands we're talking about a 32 bit version for Intel. It's just different names for the same thing and nobody expects a compiler other than gcc to have been used to build it. With Solaris SPARC there are a few different things that are important. One is you have a choice of Solaris Studio (cc) or gcc as we said. Then there is 32 v. 64 bit. Counterintuitively 32 bit is better in most situations. Then there is the option of V9 instruction extensions over V8 but still running 32 bit. This is normally the best performance option on 64 bit SPARC boxes. If you want to support V8 boxes then this is another variation, or maybe you build nominal 32 bit V8 and 64 bit V9 versions. That's suboptimal but then one or the other or both will work on most SPARC boxes still running. > The old names continue to be supported. > We don't really need/want to encode precise versions in the names. Understood and I am not questioning the naming conventions except for Solaris where there are really quite a few variations and options that have a big effect on performance and are meaningful when somebody is trying to pick the right one. > See, it used to be there was a roughly one to one processor to OS mapping. > So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86. Yeah, I know. Life was simpler in the old days ;-) > We have access to the opencsw machines for Solaris. That's good news. Thanks for the info. I'm glad to see how much opencsw does for the Solaris community. I keep finding things they help with. > There is actually very little target-dependent anywhere in the Modula-3 system at this point. > I removed all the rewritten Posix headers for example, replaced with a more portable layer. > (i.e. no need to know exact layout and sizes of things). Good news! I guess that means you are using libc instead of syscalls because I know Solaris syscalls are different from linux, etc. I don't know how closely Solaris libc is aligned to Linux or BSD libc... Thanks, Israel From jay.krell at cornell.edu Wed Sep 18 19:03:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Sep 2013 17:03:17 +0000 Subject: [M3devel] 64bit big-endian In-Reply-To: <20130918081502.GA12109@zoho.com> References: <20130917151045.6D7195DEB73@birch.elegosoft.com>, , <20130917180001.GA10942@zoho.com>, , <20130917183309.GB10942@zoho.com>, , <20130918081502.GA12109@zoho.com> Message-ID: So..historically, with the gcc-backend, we don't have much C code. Just thin wrappers, like: int int Unix__open(const char* a, int b) { return open(a, b); } copying in the case of stat. Errno constants are "instantiated" instead of "inline" extern const Errno_EBADIF = EBADIF; and we use if/else/else instead of switch on them. So that we don't have to duplicate their values for every target, like we used to (porting headache). So I don't think the choice of C compiler made that big a difference. Now we do have a C backend, that nobody is using. So the C compiler becomes more interesting. Also, for a long time, our gcc-backend made every load and store volatile. Hypothetically this tanked performance, but in reality probably only Tony knew, and nobody noticed, then later I noticed. And I fixed it. I compiled with -O2 and -O3, which is noticably slower than not optimizing, and where there were problems, I either fixed them, or disabled a small number of specific optimizations. I believe I found at least one gcc bug therein -- around use of division/mod operator that we use but isn't exposed to C/C++ (maybe Ada??) At least one optimization pass was acknowledged buggy by the gcc maintainers and they removed it themselves (the one that tries to convert structs to scalars, I think.) Our NT386 backend always optimizes some, but never inlines anything. (It is better than the volatized gcc backend.) We are optionally safe, yet compile directly to native. So we should be competitive. We are probably faster in general than any interprter -- Ruby and Python and Perl. Now, things that JIT -- JScript, Java, C# -- they have a good chance of being close behind or ahead in performance. Languages with no safety -- C and C++ -- they are likely faster in general. And again, I do favor Sun cc. Both because it might be faster and it gives me a chance to make our C code portable by testing it on additional C compilers. Our C code has also fairly recently been through the Tru64 compiler. Some of it goes through Visual C++. And maybe some others. I tested the C backend with Sun cc I think. And now Microsoft Visual C++. I should get over to clang... As to which build I produced how, the definitive information is probably the config files in the releases. As to the redundancy, well, people don't want to give up the old names, and I want to provide the new names, so there ends up both. For SPARC instruction set we did bump up to something not ancient. It was needed for atomics, at least, I think. You can see in the config file. https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common?rev=1.7;content-type=text%2Fplain SunXArch = "v8plus" It is difficult to find a balance among: performance convenience prebuilt binaries that works for most everyone right out of the box or easy to build source that works for most everyone portability test matrix (cost) short command lines (convenience) debuggability time but I tried. - Jay > Date: Wed, 18 Sep 2013 08:15:02 +0000 > From: microcode at zoho.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit big-endian > > On Tue, Sep 17, 2013 at 09:05:39PM +0000, Jay K wrote: > > SPARC32_SOLARIS is a new name for SOLsun/SOLgnu. > > But which? Sun cc or gcc? And then it would seem from your comment there is > at least one duplicate download. This is confusing. > > > Not sure if it should be PPC or PPC32, SPARC or SPARC32, > > I386 or X86 or IA32 or what, but ok. > > With i386, x86, and IA32 everybody understands we're talking about a 32 bit > version for Intel. It's just different names for the same thing and nobody > expects a compiler other than gcc to have been used to build it. > > With Solaris SPARC there are a few different things that are important. One > is you have a choice of Solaris Studio (cc) or gcc as we said. Then there is > 32 v. 64 bit. Counterintuitively 32 bit is better in most situations. > Then there is the option of V9 instruction extensions over V8 but still > running 32 bit. This is normally the best performance option on 64 bit SPARC > boxes. If you want to support V8 boxes then this is another variation, or > maybe you build nominal 32 bit V8 and 64 bit V9 versions. That's suboptimal > but then one or the other or both will work on most SPARC boxes still running. > > > The old names continue to be supported. > > We don't really need/want to encode precise versions in the names. > > Understood and I am not questioning the naming conventions except for > Solaris where there are really quite a few variations and options that have > a big effect on performance and are meaningful when somebody is trying to > pick the right one. > > > See, it used to be there was a roughly one to one processor to OS mapping. > > So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86. > > Yeah, I know. Life was simpler in the old days ;-) > > > We have access to the opencsw machines for Solaris. > > That's good news. Thanks for the info. I'm glad to see how much opencsw does > for the Solaris community. I keep finding things they help with. > > > There is actually very little target-dependent anywhere in the Modula-3 system at this point. > > I removed all the rewritten Posix headers for example, replaced with a more portable layer. > > (i.e. no need to know exact layout and sizes of things). > > Good news! I guess that means you are using libc instead of syscalls because > I know Solaris syscalls are different from linux, etc. I don't know how > closely Solaris libc is aligned to Linux or BSD libc... > > Thanks, > > Israel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 19 19:47:09 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Sep 2013 13:47:09 -0400 Subject: [M3devel] Build failure in regressions Message-ID: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu> I get this error: === package m3-sys/mklib === 38479 +++ cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? +++ 38480 --- building in SOLgnu --- 38481 38482 ignoring ../src/m3overrides 38483 38484 new source -> compiling Main.m3 38485 "../src/Main.m3", line 87: unknown qualification ?.? (IMAGE_FILE_MACHINE_AMD64) 38486 NEXT 1 error encountered 38487 38488 NEXT Fatal Error: failed compiling: 38489 38490 NEXT *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? failed *** 38491 compile return value: 1 38492 [end compile 2013.09.19 07:31:22] 38493 *** COMPILE FAILED Does anyone know what this is about? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 19 19:49:57 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Sep 2013 13:49:57 -0400 Subject: [M3devel] Tinderbox build failure Message-ID: Here is the full log: Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 19 19:52:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Sep 2013 17:52:12 +0000 Subject: [M3devel] Build failure in regressions In-Reply-To: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu> References: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu> Message-ID: ah, mklib dependency on updated m3core, understood, I'll fix it later - Jay From: hosking at cs.purdue.edu Date: Thu, 19 Sep 2013 13:47:09 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Build failure in regressions I get this error: === package m3-sys/mklib === 38479 +++ cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? +++ 38480 --- building in SOLgnu --- 38481 38482 ignoring ../src/m3overrides 38483 38484 new source -> compiling Main.m3 38485 "../src/Main.m3", line 87: unknown qualification ?.? (IMAGE_FILE_MACHINE_AMD64) 38486 NEXT 1 error encountered 38487 38488 NEXT Fatal Error: failed compiling: 38489 38490 NEXT *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? failed *** 38491 compile return value: 1 38492 [end compile 2013.09.19 07:31:22] 38493 *** COMPILE FAILED Does anyone know what this is about? Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 21 07:31:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Sep 2013 05:31:10 +0000 Subject: [M3devel] Build failure in regressions In-Reply-To: References: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu>, Message-ID: This should be fixed now. There is still a dependency on m3core being somewhat up to date. If the dependency is still too much, I can recopy the stuff back to mklib like it was there. Or we can skip mklib when not targeting/booting for NT. It is only used for NT targets. I would like to get rid of it, and use native link /lib instead, but mklib also writes the .def files. That should be moved to m3front/m3middle/m3back I think. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 19 Sep 2013 17:52:12 +0000 Subject: Re: [M3devel] Build failure in regressions ah, mklib dependency on updated m3core, understood, I'll fix it later - Jay From: hosking at cs.purdue.edu Date: Thu, 19 Sep 2013 13:47:09 -0400 To: m3devel at elegosoft.com Subject: [M3devel] Build failure in regressions I get this error: === package m3-sys/mklib === 38479 +++ cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? +++ 38480 --- building in SOLgnu --- 38481 38482 ignoring ../src/m3overrides 38483 38484 new source -> compiling Main.m3 38485 "../src/Main.m3", line 87: unknown qualification ?.? (IMAGE_FILE_MACHINE_AMD64) 38486 NEXT 1 error encountered 38487 38488 NEXT Fatal Error: failed compiling: 38489 38490 NEXT *** execution of cm3 -build -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? $RARGS && cm3 -ship $RARGS -DROOT=?/scratch/hosking/work/cm3-ws/niagara-2013-09-19-10-56-17/cm3? failed *** 38491 compile return value: 1 38492 [end compile 2013.09.19 07:31:22] 38493 *** COMPILE FAILED Does anyone know what this is about? Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 04:15:45 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 02:15:45 +0000 Subject: [M3devel] proposal to batch C compilation, and change extensions Message-ID: With Microsoft Visual C++, it is very much faster to say: cl -c 1.c 2.c 3.c 4.c than cl -c 1.c cl -c 2.c cl -c 3.c cl -c 4.c I'm assuming the same pattern works with other compilers, and is generally never slower. This requires the output names followed an assumed pattern -- replace ".c" with ".o" or ".obj". When compiling a single file you can specify an arbitrary output name. When compiling multiple files, you can only specify an output directory. It also requires the same command line switches for compiling each file, i.e. -I, -D, etc. Traditionally this didn't matter much because we have relatively little C. I would like to "fix" this. I would like to change the build to record what all C files need compiling, then compile them all "at once". And for foo.m3 => foo.m3.c => foo.m3.obj or foo.m3.o instead of the current foo.m3 => foo.m3.c -> foo.mo And, might as well do similar for the gcc backend? foo.m3 => foo.mc => foo.m3.o instead of foo.m3 => foo.mc => foo.mo Or, for some purported MS-DOS compatibility (only one dot): foo.m3 => foo_m3.c => foo_m3.obj or foo_m3.o foo.m3 => foo.mc => foo_m3.obj or foo_m3.o Ok? I think nix the MS-DOS part. (Is anyone interested in a DJGPP version?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 05:58:34 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 03:58:34 +0000 Subject: [M3devel] what does it mean to read a UINT8? Message-ID: It appears that this code: b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; generates a read of a full INTEGER, in this case 8 bytes. Now, I know, I could change it to: b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; What were my expectations wrong in the first place? This code was part of getting stack bounds and it'd read the end of the stack to try to ensure it was correct. I removed it. 0:000> g (15bc.116c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for cm3.exe cm3!ThreadWin32__GetStackBounds+0x1e8: 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 ffff=???????????????? 0:000> r rax rax=0000000000290000 0:000> r rsp rsp=000000000028fb60 0:000> dv start_L_275 = 0x00000000`00338de0 end_L_276 = 0x00000000`00338de8 L_501_L_502 = 0n48 used_L_272 = 0x00000000`0028f000 available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 00`00190000 ---" b_L_274 = 0x30 '0' a_L_271 = 0n48 info_L_270 = struct TA669C7A1 _frame = struct ThreadWin32__GetStackBounds_Frame_t 0:000> ?? info_L_270 struct TA669C7A1 +0x000 BaseAddress : 0x00000000`0028f000 "0???" +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr ess 0x00000000`00190000 ---" +0x010 AllocationProtect : 4 +0x014 L_7 : [4] "" +0x018 RegionSize : 0n4096 +0x020 State : 0x1000 +0x024 Protect : 4 +0x028 Type : 0x20000 +0x02c L_8 : [4] "" 0:000> q quit: - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 06:41:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 04:41:14 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20130922043502.1D6F15DEB78@birch.elegosoft.com> References: <20130922043502.1D6F15DEB78@birch.elegosoft.com> Message-ID: Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 22 06:49:29 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 22 Sep 2013 04:49:29 +0000 Subject: [M3devel] problem building mklib on WinXP Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CBD9@ATLEX04-SRV.SCIRES.LOCAL> Jay: I'm getting a compilation error building mklib.exe. See below. --- processing package "m3-sys\mklib" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3 "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) 1 error encountered compilation failed => not building program "mklib.exe" Fatal Error: package build failed WARNING: Encountered an error when processing package "m3-sys\mklib" for "-build". Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Sep 22 06:51:09 2013 From: jayk123 at hotmail.com (Jay K) Date: Sun, 22 Sep 2013 04:51:09 +0000 Subject: [M3devel] problem building mklib on WinXP In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CBD9@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CBD9@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Right. Tony reported this. Again it is due to m3core being old, but in this case not so old. I updated mklib to contain the definition itself instead of using m3core. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: problem building mklib on WinXP Date: Sun, 22 Sep 2013 04:49:29 +0000 Jay: I'm getting a compilation error building mklib.exe. See below. --- processing package "m3-sys\mklib" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Main.m3 "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) 1 error encountered compilation failed => not building program "mklib.exe" Fatal Error: package build failed WARNING: Encountered an error when processing package "m3-sys\mklib" for "-build". Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 22 06:57:01 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL> Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 07:03:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 06:57:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 04:57:12 +0000 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: Message-ID: Hm, bug in the C backend maybe? I'll have to compare against m3cg. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 22 Sep 2013 03:58:34 +0000 Subject: [M3devel] what does it mean to read a UINT8? It appears that this code: b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; generates a read of a full INTEGER, in this case 8 bytes. Now, I know, I could change it to: b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; What were my expectations wrong in the first place? This code was part of getting stack bounds and it'd read the end of the stack to try to ensure it was correct. I removed it. 0:000> g (15bc.116c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for cm3.exe cm3!ThreadWin32__GetStackBounds+0x1e8: 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 ffff=???????????????? 0:000> r rax rax=0000000000290000 0:000> r rsp rsp=000000000028fb60 0:000> dv start_L_275 = 0x00000000`00338de0 end_L_276 = 0x00000000`00338de8 L_501_L_502 = 0n48 used_L_272 = 0x00000000`0028f000 available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 00`00190000 ---" b_L_274 = 0x30 '0' a_L_271 = 0n48 info_L_270 = struct TA669C7A1 _frame = struct ThreadWin32__GetStackBounds_Frame_t 0:000> ?? info_L_270 struct TA669C7A1 +0x000 BaseAddress : 0x00000000`0028f000 "0???" +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr ess 0x00000000`00190000 ---" +0x010 AllocationProtect : 4 +0x014 L_7 : [4] "" +0x018 RegionSize : 0n4096 +0x020 State : 0x1000 +0x024 Protect : 4 +0x028 Type : 0x20000 +0x02c L_8 : [4] "" 0:000> q quit: - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 07:14:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 05:14:15 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sun Sep 22 07:35:15 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>, , Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL> Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 07:43:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 05:43:15 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>, , , , , <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 11:10:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 09:10:02 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj Message-ID: darn, AMD4_NT isn't working any longer. It gets here: 0:000> k Child-SP RetAddr Call Site 00000000`002bee90 00000001`3fac0f1f cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221] 00000000`002bef10 00000001`3fa3fe96 cm3!RTHooks__AllocateTracedObj+0x2f [c:\dev2\src\runtime\common\rtallocator.m3 @ 123] 00000000`002bef60 00000001`3fa3f774 cm3!Pathname__Decompose+0x86 [c:\dev2\src\os\win32\pathnamewin32.m3 @ 40] 00000000`002beff0 00000001`3fa3f55f cm3!PathRepr__Root+0xb4 [c:\dev2\src\pathreprcommon.m3 @ 38] 00000000`002bf1c0 00000001`3fae37fc cm3!PathReprCommon_M3+0xcf [c:\dev2\src\pathreprcommon.m3 @ 46] 00000000`002bf380 00000001`3fae3653 cm3!RTLinker__RunMainBody+0x46c [c:\dev2\src\runtime\common\rtlinker.m3 @ 409] 0:000> dv /V 00000000`002bef10 @rsp+0x0080 def_L_96 = 0x00000000`00000000 ... 0:000> u . -10 cm3!RTAllocator__GetTracedObj+0x81 [c:\dev2\src\runtime\common\rtallocator.m3 @217]: ... 00000001`3fac23b9 488b842480000000 mov rax,qword ptr [rsp+80h] 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> u . l1 cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221]: 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> r rax rax=0000000000000000 def is NULL. It comes from here: Pathname__Decompose: ... RTHooks__AllocateTracedObj( (((ADDRESS)(*((ADDRESS*)(INT64_(192)+((ADDRESS)(&M_PathnameWin32_L_33)))))))); M_PathnameWin32_L_33 + 192 is NULL. "_L_33" is an annoying uniquifier from the C backend, sprinkled on far more than needed. global data allocation for M_PathnameWin32 ... 192 16 8 typecell ptr Is that supposed to be statically initialized or filled in by RTLinker? It noticably is not in the constants, but the writables. Help? Debug RTLinker? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 22 11:53:54 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 09:53:54 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj In-Reply-To: References: Message-ID: hm. indeed. darwin @M3tracelinker shows a few PathnamePosix but nt never shows PathnameWin32. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 22 Sep 2013 09:10:02 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj darn, AMD4_NT isn't working any longer. It gets here: 0:000> k Child-SP RetAddr Call Site 00000000`002bee90 00000001`3fac0f1f cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221] 00000000`002bef10 00000001`3fa3fe96 cm3!RTHooks__AllocateTracedObj+0x2f [c:\dev2\src\runtime\common\rtallocator.m3 @ 123] 00000000`002bef60 00000001`3fa3f774 cm3!Pathname__Decompose+0x86 [c:\dev2\src\os\win32\pathnamewin32.m3 @ 40] 00000000`002beff0 00000001`3fa3f55f cm3!PathRepr__Root+0xb4 [c:\dev2\src\pathreprcommon.m3 @ 38] 00000000`002bf1c0 00000001`3fae37fc cm3!PathReprCommon_M3+0xcf [c:\dev2\src\pathreprcommon.m3 @ 46] 00000000`002bf380 00000001`3fae3653 cm3!RTLinker__RunMainBody+0x46c [c:\dev2\src\runtime\common\rtlinker.m3 @ 409] 0:000> dv /V 00000000`002bef10 @rsp+0x0080 def_L_96 = 0x00000000`00000000 ... 0:000> u . -10 cm3!RTAllocator__GetTracedObj+0x81 [c:\dev2\src\runtime\common\rtallocator.m3 @217]: ... 00000001`3fac23b9 488b842480000000 mov rax,qword ptr [rsp+80h] 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> u . l1 cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221]: 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> r rax rax=0000000000000000 def is NULL. It comes from here: Pathname__Decompose: ... RTHooks__AllocateTracedObj( (((ADDRESS)(*((ADDRESS*)(INT64_(192)+((ADDRESS)(&M_PathnameWin32_L_33)))))))); M_PathnameWin32_L_33 + 192 is NULL. "_L_33" is an annoying uniquifier from the C backend, sprinkled on far more than needed. global data allocation for M_PathnameWin32 ... 192 16 8 typecell ptr Is that supposed to be statically initialized or filled in by RTLinker? It noticably is not in the constants, but the writables. Help? Debug RTLinker? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Sep 22 19:04:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Sep 2013 12:04:30 -0500 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: Message-ID: <523F231E.60107@lcwb.coop> This touches on a mess I have been bothered by for a long time and was getting ready to write about anyway, after spending some time inside pickles and network objects. As I have noted several times on this list, BITS n FOR T, according to the language, has an effect *only when used for an array element or record or object field*. If used for a scalar, the BITS n FOR has no effect. So a compiler is free to put scalars of packed type in anything with at least n bits, including, most plausibly, a whole native word. This could well be an advantage on many targets. But we have bit-twiddling code all over that makes assumptions about what the compiler will do that are neither specified by the language nor documented by our compiler. Presumably, most have at least been experimentally verified for selected cases. But even for a single and unchanging compiler, that is not reliable. People have, sometimes, wrapped a packed field inside a record to get around this, then used an ADR on the field. But we have no rules about how the alignment of a packed field nor of a whole record containing packed fields, so for VAR V: RECORD f: BITS 16 FOR [0..16_FFFF] END ADR(V.f) need not be 16-aligned. For bit counts other than 8, 16, 32, and 64, it hardly makes sense for a field to have alignment other than 8, and for general cases, ADR doesn't have any obvious or predictable definition. The best I can think of would be a static error if the compiler couldn't guarantee it would be at least a multiple of 8. Or, for example, if UINT8 is BITS 8 FOR [0..16_FF], do we know that BITSIZE(LOOPHOLE(x,UNTRACED REF UINT8)^)= 8? What if x is ADR(AScalarVariable), and the scalar has been allocated 64 bits? Or, x could be ADR(V.f)? The meaning of UNTRACED REF UINT16 can't depend on this. Is there some kind of consistency here? Is it endian-dependent? What about the alignment, assumed and/or ensured of these addresses? We have lots of code that just assumes something the writer thought reasonable, but it is far from consistently clear what the reasonable interpretation would be. It would be tricky to get right in general, but we could use some rules, either in the language itself or compiler supplementary documentation, spelling this stuff out. On 09/21/2013 10:58 PM, Jay K wrote: > It appears that this code: > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > generates a read of a full INTEGER, in this case 8 bytes. > > > Now, I know, I could change it to: > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > What were my expectations wrong in the first place? > > > This code was part of getting stack bounds and it'd read > the end of the stack to try to ensure it was correct. > > > I removed it. > > > 0:000> g > (15bc.116c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > *** WARNING: Unable to verify checksum for cm3.exe > cm3!ThreadWin32__GetStackBounds+0x1e8: > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > ffff=???????????????? > 0:000> r rax > rax=0000000000290000 > 0:000> r rsp > rsp=000000000028fb60 > 0:000> dv > start_L_275 = 0x00000000`00338de0 > end_L_276 = 0x00000000`00338de8 > L_501_L_502 = 0n48 > used_L_272 = 0x00000000`0028f000 > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > 00`00190000 ---" > b_L_274 = 0x30 '0' > a_L_271 = 0n48 > info_L_270 = struct TA669C7A1 > _frame = struct ThreadWin32__GetStackBounds_Frame_t > 0:000> ?? info_L_270 > struct TA669C7A1 > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > ess 0x00000000`00190000 ---" > +0x010 AllocationProtect : 4 > +0x014 L_7 : [4] "" > +0x018 RegionSize : 0n4096 > +0x020 State : 0x1000 > +0x024 Protect : 4 > +0x028 Type : 0x20000 > +0x02c L_8 : [4] "" > 0:000> q > quit: > > > - Jay From rodney_bates at lcwb.coop Sun Sep 22 19:17:18 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Sep 2013 12:17:18 -0500 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: Message-ID: <523F261E.609@lcwb.coop> As in my other response, I think you are left entirely too much out in the wind by the language/compiler as to what your expectations should be. In this particular example, it would help to know the type UINT8, and those of 'used', 'info', 'RegionSize', and maybe 'b'. I could make some guesses, but that could turn out a snipe hunt. Do you mean it copies a full INTEGER into b, or just fetches an INTEGER, then extracts from it? What is the alignment of the actual address in the failing case? On 09/21/2013 10:58 PM, Jay K wrote: > It appears that this code: > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > generates a read of a full INTEGER, in this case 8 bytes. > > > Now, I know, I could change it to: > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > What were my expectations wrong in the first place? > > > This code was part of getting stack bounds and it'd read > the end of the stack to try to ensure it was correct. > > > I removed it. > > > 0:000> g > (15bc.116c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > *** WARNING: Unable to verify checksum for cm3.exe > cm3!ThreadWin32__GetStackBounds+0x1e8: > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > ffff=???????????????? > 0:000> r rax > rax=0000000000290000 > 0:000> r rsp > rsp=000000000028fb60 > 0:000> dv > start_L_275 = 0x00000000`00338de0 > end_L_276 = 0x00000000`00338de8 > L_501_L_502 = 0n48 > used_L_272 = 0x00000000`0028f000 > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > 00`00190000 ---" > b_L_274 = 0x30 '0' > a_L_271 = 0n48 > info_L_270 = struct TA669C7A1 > _frame = struct ThreadWin32__GetStackBounds_Frame_t > 0:000> ?? info_L_270 > struct TA669C7A1 > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > ess 0x00000000`00190000 ---" > +0x010 AllocationProtect : 4 > +0x014 L_7 : [4] "" > +0x018 RegionSize : 0n4096 > +0x020 State : 0x1000 > +0x024 Protect : 4 > +0x028 Type : 0x20000 > +0x02c L_8 : [4] "" > 0:000> q > quit: > > > - Jay From jay.krell at cornell.edu Sun Sep 22 19:47:07 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Sep 2013 17:47:07 +0000 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: <523F261E.609@lcwb.coop> References: , <523F261E.609@lcwb.coop> Message-ID: UINT8 is [0..255] I think. I tried "BITS 8 FOR" on it at some point but such things on that family of types (UINT16, UINT32, UINT64) caused compilation errors. (These are all via Ctypes.i3) The pointer before subtraction is 64K-aligned. I don't think the other types should matter. I still have to compare with integrated backend or cm3cg. - Jay > Date: Sun, 22 Sep 2013 12:17:18 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] what does it mean to read a UINT8? > > As in my other response, I think you are left entirely too much > out in the wind by the language/compiler as to what your expectations > should be. In this particular example, it would help to know the type > UINT8, and those of 'used', 'info', 'RegionSize', and maybe 'b'. I > could make some guesses, but that could turn out a snipe hunt. > > Do you mean it copies a full INTEGER into b, or just fetches > an INTEGER, then extracts from it? What is the alignment of > the actual address in the failing case? > > On 09/21/2013 10:58 PM, Jay K wrote: > > It appears that this code: > > > > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > > > > generates a read of a full INTEGER, in this case 8 bytes. > > > > > > Now, I know, I could change it to: > > > > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > > > > What were my expectations wrong in the first place? > > > > > > This code was part of getting stack bounds and it'd read > > the end of the stack to try to ensure it was correct. > > > > > > I removed it. > > > > > > 0:000> g > > (15bc.116c): Access violation - code c0000005 (first chance) > > First chance exceptions are reported before any exception handling. > > This exception may be expected and handled. > > *** WARNING: Unable to verify checksum for cm3.exe > > cm3!ThreadWin32__GetStackBounds+0x1e8: > > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > > ffff=???????????????? > > 0:000> r rax > > rax=0000000000290000 > > 0:000> r rsp > > rsp=000000000028fb60 > > 0:000> dv > > start_L_275 = 0x00000000`00338de0 > > end_L_276 = 0x00000000`00338de8 > > L_501_L_502 = 0n48 > > used_L_272 = 0x00000000`0028f000 > > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > > 00`00190000 ---" > > b_L_274 = 0x30 '0' > > a_L_271 = 0n48 > > info_L_270 = struct TA669C7A1 > > _frame = struct ThreadWin32__GetStackBounds_Frame_t > > 0:000> ?? info_L_270 > > struct TA669C7A1 > > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > > ess 0x00000000`00190000 ---" > > +0x010 AllocationProtect : 4 > > +0x014 L_7 : [4] "" > > +0x018 RegionSize : 0n4096 > > +0x020 State : 0x1000 > > +0x024 Protect : 4 > > +0x028 Type : 0x20000 > > +0x02c L_8 : [4] "" > > 0:000> q > > quit: > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 23 09:20:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Sep 2013 07:20:25 +0000 Subject: [M3devel] what does it mean to read a UINT8? In-Reply-To: References: , , <523F261E.609@lcwb.coop>, Message-ID: C addresses some of this very simply and thoroughly: 1) layout of bitfields is implementation independent 2) I think even the ability to declare some bitfields is not guaranteeed, e.g. int a : 33 3) You can't take the address of bitfields. This is the key one I think. 4) Bitfields can only occur in structs/unions, not in typedefs, variables, parameters, return types, etc. - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 17:47:07 +0000 Subject: Re: [M3devel] what does it mean to read a UINT8? UINT8 is [0..255] I think. I tried "BITS 8 FOR" on it at some point but such things on that family of types (UINT16, UINT32, UINT64) caused compilation errors. (These are all via Ctypes.i3) The pointer before subtraction is 64K-aligned. I don't think the other types should matter. I still have to compare with integrated backend or cm3cg. - Jay > Date: Sun, 22 Sep 2013 12:17:18 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] what does it mean to read a UINT8? > > As in my other response, I think you are left entirely too much > out in the wind by the language/compiler as to what your expectations > should be. In this particular example, it would help to know the type > UINT8, and those of 'used', 'info', 'RegionSize', and maybe 'b'. I > could make some guesses, but that could turn out a snipe hunt. > > Do you mean it copies a full INTEGER into b, or just fetches > an INTEGER, then extracts from it? What is the alignment of > the actual address in the failing case? > > On 09/21/2013 10:58 PM, Jay K wrote: > > It appears that this code: > > > > > > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^; > > > > > > generates a read of a full INTEGER, in this case 8 bytes. > > > > > > Now, I know, I could change it to: > > > > > > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^; > > > > > > What were my expectations wrong in the first place? > > > > > > This code was part of getting stack bounds and it'd read > > the end of the stack to try to ensure it was correct. > > > > > > I removed it. > > > > > > 0:000> g > > (15bc.116c): Access violation - code c0000005 (first chance) > > First chance exceptions are reported before any exception handling. > > This exception may be expected and handled. > > *** WARNING: Unable to verify checksum for cm3.exe > > cm3!ThreadWin32__GetStackBounds+0x1e8: > > 00000001`3fdf1a78 488b48ff mov rcx,qword ptr [rax-1] ds:00000000`0028 > > ffff=???????????????? > > 0:000> r rax > > rax=0000000000290000 > > 0:000> r rsp > > rsp=000000000028fb60 > > 0:000> dv > > start_L_275 = 0x00000000`00338de0 > > end_L_276 = 0x00000000`00338de8 > > L_501_L_502 = 0n48 > > used_L_272 = 0x00000000`0028f000 > > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000 > > 00`00190000 ---" > > b_L_274 = 0x30 '0' > > a_L_271 = 0n48 > > info_L_270 = struct TA669C7A1 > > _frame = struct ThreadWin32__GetStackBounds_Frame_t > > 0:000> ?? info_L_270 > > struct TA669C7A1 > > +0x000 BaseAddress : 0x00000000`0028f000 "0???" > > +0x008 AllocationBase : 0x00000000`00190000 "--- memory read error at addr > > ess 0x00000000`00190000 ---" > > +0x010 AllocationProtect : 4 > > +0x014 L_7 : [4] "" > > +0x018 RegionSize : 0n4096 > > +0x020 State : 0x1000 > > +0x024 Protect : 4 > > +0x028 Type : 0x20000 > > +0x02c L_8 : [4] "" > > 0:000> q > > quit: > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Sep 23 23:38:14 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 23 Sep 2013 21:38:14 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E650@ATLEX04-SRV.SCIRES.LOCAL> Jay: My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren't coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 23 23:47:55 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Sep 2013 21:47:55 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E650@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E650@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My ?m3-sys/mklib/src/Main.m3? is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren?t coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Sep 24 01:03:01 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 23 Sep 2013 23:03:01 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> Jay: Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. Do you want me to commit this change via CVS to the repository? Now, that gets me thru stage #1 of the rebuild. In stage #2, the packages and their order that I am attempting to compile are: Packages to be processed: ------------------------ m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3cggen m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3cgcat m3-sys\mklib But, skipping packages: m3cc ---END-of-List--- Things go fine until I get to m3core. I get an internal code generator error. See error below: --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 7 errors encountered Thanks for your continued help, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 5:48 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren't coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 24 01:58:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Sep 2013 23:58:02 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Randy, 1) can you please tell me exactly what release of cm3 you are using so I can go through the bootstrap myself and fix everything? 2) OR, can you please install a newer release and try bootstrapping from that? I uploaded new .msis last week or so. 3) What did you do between "stage 1" and "stage 2"? In stage 1, you did build and ship, not just build, right? And then you copied the new cm3.exe over top of the old? Or to a new install location, and use that for stage 2? You cleaned everything after stage 1? The whole process is subtle and needs to be done just right, very much by design and appropriate, but still somehow tricky to understand and explain. There is a distinct lack of guaranteed compatibility between versions, again, deliberately, and again, a proper bootstrap works ok anyway. We should perhaps do better at version stamping some things though. Thanks, - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 23:03:01 +0000 Jay: Thanks. I?ve applied the edit you suggested and was able to finish the compile for mklib. Do you want me to commit this change via CVS to the repository? Now, that gets me thru stage #1 of the rebuild. In stage #2, the packages and their order that I am attempting to compile are: Packages to be processed: ------------------------ m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3cggen m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3cgcat m3-sys\mklib But, skipping packages: m3cc ---END-of-List--- Things go fine until I get to m3core. I get an internal code generator error. See error below: --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 7 errors encountered Thanks for your continued help, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 5:48 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My ?m3-sys/mklib/src/Main.m3? is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren?t coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Sep 24 03:31:58 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 24 Sep 2013 01:31:58 +0000 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E9EE@ATLEX04-SRV.SCIRES.LOCAL> Jay: Re #1, C:\cm3\Sandbox\cm3\scripts\dev\windows>cm3 -version Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2013-09-23 22:52:35 configuration: C:\cm3\bin\cm3.cfg host: NT386 target: NT386 Re #2, I was hoping to get my edition updated. Re #3, I do a purge of the NT386 sandbox folders followed by a build/ship on each package, then at end of stage one I copy the new cm3.exe over the old one in the cm3\bin folder (as long as the stage build was successful). In stage two, I do a purge of NT386 sandbox folders again followed by build/ship of each package, and eventually replace the cm3.exe if the stage is successful. In stage three, I rebuild all packages following the same recipe. I've used this process for years with success, but I've let my implementation on this computer stay backlevel on purpose for compatibility with a production environment I've had to support, but now it is time to get current. Thanks for your help. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 7:58 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Randy, 1) can you please tell me exactly what release of cm3 you are using so I can go through the bootstrap myself and fix everything? 2) OR, can you please install a newer release and try bootstrapping from that? I uploaded new .msis last week or so. 3) What did you do between "stage 1" and "stage 2"? In stage 1, you did build and ship, not just build, right? And then you copied the new cm3.exe over top of the old? Or to a new install location, and use that for stage 2? You cleaned everything after stage 1? The whole process is subtle and needs to be done just right, very much by design and appropriate, but still somehow tricky to understand and explain. There is a distinct lack of guaranteed compatibility between versions, again, deliberately, and again, a proper bootstrap works ok anyway. We should perhaps do better at version stamping some things though. Thanks, - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 23:03:01 +0000 Jay: Thanks. I've applied the edit you suggested and was able to finish the compile for mklib. Do you want me to commit this change via CVS to the repository? Now, that gets me thru stage #1 of the rebuild. In stage #2, the packages and their order that I am attempting to compile are: Packages to be processed: ------------------------ m3-win\import-libs m3-sys\m3cc m3-libs\m3core m3-libs\libm3 m3-libs\sysutils m3-sys\m3middle m3-sys\m3objfile m3-sys\m3linker m3-sys\m3back m3-sys\m3cggen m3-sys\m3front m3-sys\m3quake m3-sys\cm3 m3-sys\m3cgcat m3-sys\mklib But, skipping packages: m3cc ---END-of-List--- Things go fine until I get to m3core. I get an internal code generator error. See error below: --- processing package "m3-libs\m3core" --- --- purging derived files from NT386 --- --- cleaning NT386 --- ignoring ..\src\m3overrides --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling RTHeapRep.i3 new source -> compiling FloatMode.i3 new source -> compiling RTThread.i3 new source -> compiling Scheduler.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling LongRep.i3 new source -> compiling Long.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 7 errors encountered Thanks for your continued help, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 23, 2013 5:48 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Sorry, you are right I missed it. I'll fix it tonight probably. Here it is: CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Date: Mon, 23 Sep 2013 21:38:14 +0000 Jay: My "m3-sys/mklib/src/Main.m3" is showing current wrt the HEAD branch in CVS. CVS indicates there is no update for me to obtain. My file is 850 lines in length. Did you commit changes to this file? If you did, they aren't coming thru for me. So, the error persists: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) Please advise. Thanks, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Sunday, September 22, 2013 1:43 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Right. cvs upd m3-sys/mklib/src/Main.m3 should fix it. I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. What does cm3 -version print? > or that my m3core is too old to be able to perform an upgrade Most likely it will work. mklib I recall is last in the bootstrap phase, so you are 99.99% there. The system is written in itself. An excellent feature. There are always therefore these problems, and always we should probably gradually require a newer build. When there isn't a new enough native install, or any at all, a cross build is the solution. I have "crossed" countless times at this point and can vouch for its viability. We cannot/must not support arbitrarily old. For example, building from the old/stable 3.6 release is probably irrecovably broken by now. Because the system has gone so long with relatively little change, these aspects become hidden to most people and they consider it a problem/bug when they come up, when they are actually perfectly natural results of the system using itself, and incurring any changes. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:35:15 +0000 Subject: Re: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 Based on your response, I guess that as soon as I can get this thing to build, my pkg tree will get updated with the newer Ctypes, but right now I'm stuck on this error in building mklib: "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) In your prior response you stated, "I updated mklib to contain the definition itself instead of using m3core." Does that mean you've fixed the problem, or that I have more work to do, or that my m3core is too old to be able to perform an upgrade? I'm not able to use the python scripts due to the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py Traceback (most recent call last): File "C:\cm3\Sandbox\cm3\scripts\python\upgrade.py", line 4, in import pylib File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' So, I'm working with my CMD files and doing stuff by hand. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 1:14 AM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] [M3commit] CVS Update: cm3 https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 - Jay ________________________________ From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 05:03:17 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 It is cm3/m3-libs/m3core/src/C/Common/Ctypes.i3 in the source tree or \cm3\pkg\m3core\NT386\Ctypes.i3 in an install. In the first pass of upgrade, it comes from the install, so can be old..but how old? After the first pass, it comes from the source tree. - Jay ________________________________ From: rcolebur at SCIRES.COM To: jay.krell at cornell.edu; m3devel at elegosoft.com Date: Sun, 22 Sep 2013 04:57:01 +0000 Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Jay: Where is the CTypes file coming from? I've updated my entire Sandbox via CVS to be current with the head branch, so if CTypes is in there, what I have should be current. If CTypes is coming from somewhere else, then please explain where and what I need to do in order to update. The computer I'm using for this build is a 32-bit WinXP machine. It has Visual Studio Express 2008 installed on it. --Randy Coleburn ________________________________ From: jayk123 at hotmail.com [jayk123 at hotmail.com] on behalf of Jay K [jay.krell at cornell.edu] Sent: Sunday, September 22, 2013 12:41 AM To: m3devel; Coleburn, Randy Subject: EXT:RE: [M3commit] CVS Update: cm3 Fyi, Your CTypes is over 5 years old. It predates Thu May 29 14:43:18 2008 . I realize in this case, it is trivial to support older, but... - Jay > Date: Sun, 22 Sep 2013 06:35:02 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 13/09/22 06:35:02 > > Modified files: > cm3/m3-sys/m3back/src/: M3CC.i3 > > Log message: > fix broken compilation, line 6, change "ctypes.unsigned" to be "ctypes.unsigned_int" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Sep 24 03:32:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 23 Sep 2013 20:32:23 -0500 Subject: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2E74F@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <5240EBA7.2010909@lcwb.coop> Hmm, I'm looking at this. I recently committed a compiler front-end change that made this error go away, for different cases. It's in m3-sys/m3front/src/misc/CG.m3, version 1.15.2.5 in the release and 1.43 in the head. Are you compiling with one of these? I reread it, and my change still looks right to me. The message helpfully gives important information, and ScanTypes seems to be being asked to find an unsigned integer code-generator type that has alignment at least 64, but fits in a 32-bit word. And this for a global variable of type BOOLEAN and size 8 (bits). So the 64-bit alignment request doesn't seem sensible. I can't guess where the 32-bit requirement would have come from. Is it a 32-bit target you are compiling for? RTAllocator.m3 compiles fine on my AMD64_LINUX machine. On 09/23/2013 06:03 PM, Coleburn, Randy wrote: > Jay: > > Thanks. I?ve applied the edit you suggested and was able to finish the compile for mklib. > > *Do you want me to commit this change via CVS to the repository?* > > Now, that gets me thru stage #1 of the rebuild. > > In stage #2, the packages and their order that I am attempting to compile are: > > Packages to be processed: > > ------------------------ > > m3-win\import-libs > > m3-sys\m3cc > > m3-libs\m3core > > m3-libs\libm3 > > m3-libs\sysutils > > m3-sys\m3middle > > m3-sys\m3objfile > > m3-sys\m3linker > > m3-sys\m3back > > m3-sys\m3cggen > > m3-sys\m3front > > m3-sys\m3quake > > m3-sys\cm3 > > m3-sys\m3cgcat > > m3-sys\mklib > > But, skipping packages: m3cc > > ---END-of-List--- > > *Things go fine until I get to m3core. I get an internal code generator error. *See error below: > > --- processing package "m3-libs\m3core" --- > > --- purging derived files from NT386 --- > > --- cleaning NT386 --- > > ignoring ..\src\m3overrides > > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > new source -> compiling RuntimeError.i3 > > new source -> compiling WordRep.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > > new source -> compiling RTHooks.m3 > > new source -> compiling RT0.m3 > > new source -> compiling Compiler.i3 > > new source -> compiling RuntimeError.m3 > > new source -> compiling Compiler.m3 > > new source -> compiling RTAllocator.i3 > > new source -> compiling RTType.i3 > > new source -> compiling RTHeapRep.i3 > > new source -> compiling FloatMode.i3 > > new source -> compiling RTThread.i3 > > new source -> compiling Scheduler.i3 > > new source -> compiling RTOS.i3 > > new source -> compiling RTMisc.i3 > > new source -> compiling Cstdlib.i3 > > new source -> compiling Cstddef.i3 > > new source -> compiling LongRep.i3 > > new source -> compiling Long.i3 > > new source -> compiling BasicCtypes.i3 > > new source -> compiling Ctypes.i3 > > new source -> compiling RTAllocCnts.i3 > > new source -> compiling RTAllocator.m3 > > "..\src\runtime\common\RTAllocator.m3", line 95: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 209: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 231: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 248: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 270: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 303: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > "..\src\runtime\common\RTAllocator.m3", line 324: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.32 s/o/a=8/416/64 > > 7 errors encountered > > Thanks for your continued help, > > Randy Coleburn > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > *Sent:* Monday, September 23, 2013 5:48 PM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Sorry, you are right I missed it. > > I'll fix it tonight probably. > > > Here it is: > CONST IMAGE_FILE_MACHINE_AMD64 = 16_8664 (* from m3core/src/win32/winnt.i3 *) > > and change "WinNT.IMAGE_FILE_MACHINE_AMD64" to just "IMAGE_FILE_MACHINE_AMD64". > > - Jay > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > From: rcolebur at SCIRES.COM > To: jay.krell at cornell.edu ; m3devel at elegosoft.com > Subject: RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > Date: Mon, 23 Sep 2013 21:38:14 +0000 > > Jay: > > My ?m3-sys/mklib/src/Main.m3? is showing current wrt the HEAD branch in CVS. > > CVS indicates there is no update for me to obtain. > > My file is 850 lines in length. > > Did you commit changes to this file? If you did, they aren?t coming thru for me. > > So, the error persists: > > "..\src\Main.m3", line 87: unknown qualification '.' (IMAGE_FILE_MACHINE_AMD64) > > Please advise. > > Thanks, > > Randy Coleburn > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > *Sent:* Sunday, September 22, 2013 1:43 AM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] EXT:RE: [M3commit] CVS Update: cm3 > > Right. > cvs upd m3-sys/mklib/src/Main.m3 should fix it. > > > I know the problem with the Python. It is dependent on newer cm3 that prints "host", rather than, I guess, the sniffing it used to do. I'm not sure I'll fix it. I have to go back and install the older versions and go through the workflow myself and then I can improve/fix it. > > > What doe