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: <COL125-W9C067B1E6DCE004F961AFE6360@phx.gbl>

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 <module>
    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 [<function _BuildGlobalFunction at 0x018E0A70>, <function _Shi

pFunction at 0x0197B630>] 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130831/0fef1f3b/attachment.html>

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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/1c916139/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/c9a50385/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/c9a50385/attachment.sig>

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: <COL125-W1086E3676EF77327AB0E5AE6350@phx.gbl>
References: <COL125-W1086E3676EF77327AB0E5AE6350@phx.gbl>
Message-ID: <COL125-W46C0D8C8AD28462324A034E6370@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/f5a63be2/attachment.html>

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: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>
References: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>
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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>
References: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>
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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>,
	<5223BAA3.8040404@lcwb.coop>
Message-ID: <COL125-W2615CE8CCC5D51D31320DCE6370@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/cbd7e67e/attachment.html>

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: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>,
	<5223B78E.5000901@lcwb.coop>
Message-ID: <COL125-W200AF3158789481D4902AE6370@phx.gbl>

 > 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 <stdio.h>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/f7447ee4/attachment.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/ab7bee3f/attachment.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/0196a06f/attachment.html>

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: <COL125-W24A4F9E2065D02C025737EE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/2934d6c7/attachment.html>

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: <COL125-W4020A8B78D129E0227A1D3E6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/525e92f1/attachment.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
References: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/25a9c7b9/attachment.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
Message-ID: <COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/51d644b2/attachment.html>

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: <COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/ec7c76c6/attachment.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
Message-ID: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>

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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/6bae5f6d/attachment.html>

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: <COL125-W381613F44F7FEC390B275FE6310@phx.gbl>

> "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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/f6d844e9/attachment.html>

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: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
Message-ID: <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu>

On Sep 3, 2013, at 1:50 PM, Jay K <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/8629f095/attachment.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
	<275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu>
Message-ID: <D99C229C-EC8E-4DAF-A307-406798AE98AF@gmail.com>

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 <hosking at cs.purdue.edu> wrote:

> On Sep 3, 2013, at 1:50 PM, Jay K <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/61ba75de/attachment.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/ca71444d/attachment.html>

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? <dragisha at m3w.org> 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: <COL125-W7F4609891FF26930595E7E6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>,
	<20130904064212.318CF1A2080@async.async.caltech.edu>
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>
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
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 12pt=3B
>font-family:Calibri
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> that can be<br>successfully assigned to this range=2C with or without<br>a=
> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>t integer=2C which would then<br>successfully pass into the identical subra=
>nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>ngreal is target-dependent and knowledge<br>of it should only exist in the =
>backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>on what you are saying=2C<br>the frontend should generate range checks befo=
>re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>ded.<br><br><br>The frontend has some of those optimizations already -- con=
>verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
>rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
>_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
>t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> restriction=2C do not handle out-of-range situations correctly.  Things<br=
>>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
>n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>culated integer and send your program off in<br>&gt=3B never-never land.  I=
>n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
>t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>&gt=3B      Mika<br></div> 		 	   		  </div></body>
></html>=
>
>--_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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>,
	<20130904064212.318CF1A2080@async.async.caltech.edu>
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>
	<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
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 12pt=3B
>> font-family:Calibri
>> }
>> --></style></head>
>> <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>> perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>> compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>> r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>> bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>> from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
>> that can be<br>successfully assigned to this range=2C with or without<br>a=
>> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>> ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>> r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>> .<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>> s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>> teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>> systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>> t integer=2C which would then<br>successfully pass into the identical subra=
>> nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>> ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>> ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>> nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>> ngreal is target-dependent and knowledge<br>of it should only exist in the =
>> backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>> s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>> on what you are saying=2C<br>the frontend should generate range checks befo=
>> re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>> br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>> us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>> ) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
>> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>> =2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>> ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>> sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>> t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>> ded.<br><br><br>The frontend has some of those optimizations already -- con=
>> verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>> r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>> cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>> krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>> itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>> 2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
>> rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>> ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>> t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
>> _10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>> =3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>> re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>> =3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
>> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>> =3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>> &gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>> t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>> hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>> is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>> on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
>> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>> a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
>> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>> =2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>> gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>> d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
>> t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
>> restriction=2C do not handle out-of-range situations correctly.  Things<br=
>>> &gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>> ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>> n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
>> n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>> culated integer and send your program off in<br>&gt=3B never-never land.  I=
>> n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
>> t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
>> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>> ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>> &gt=3B      Mika<br></div> 		 	   		  </div></body>
>> </html>=
>> 
>> --_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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
Message-ID: <COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>

> 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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly.  Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land.  I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B      Mika<br></div> 		 	   		  </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/462bf6e6/attachment.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>,
	<53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu>
Message-ID: <COL125-W30A8A3A5562C1EDEB2631DE6320@phx.gbl>

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
> >> 
> >> <html>
> >> <head>
> >> <style><!--
> >> .hmmessage P
> >> {
> >> margin:0px=3B
> >> padding:0px
> >> }
> >> body.hmmessage
> >> {
> >> font-size: 12pt=3B
> >> font-family:Calibri
> >> }
> >> --></style></head>
> >> <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >> perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >> compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >> r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >> bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >> from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> >> that can be<br>successfully assigned to this range=2C with or without<br>a=
> >> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >> ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >> r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >> .<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >> s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >> teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >> systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >> t integer=2C which would then<br>successfully pass into the identical subra=
> >> nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >> ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >> ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >> nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >> ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >> backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >> s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >> on what you are saying=2C<br>the frontend should generate range checks befo=
> >> re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >> br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >> us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >> ) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> >> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >> =2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >> ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >> sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >> t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >> ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >> verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >> r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >> cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >> krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >> itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >> 2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >> rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >> ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >> t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >> _10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >> re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> >> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >> &gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >> t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >> hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >> is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >> on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> >> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >> a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> >> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >> =2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >> gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >> d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
> >> t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> >> restriction=2C do not handle out-of-range situations correctly.  Things<br=
> >>> &gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >> ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >> n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
> >> n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >> culated integer and send your program off in<br>&gt=3B never-never land.  I=
> >> n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
> >> t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> >> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >> ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >> &gt=3B      Mika<br></div> 		 	   		  </div></body>
> >> </html>=
> >> 
> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/e69d7b8a/attachment.html>

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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
Message-ID: <FAC40CE4-7278-4DBE-8478-FB58A3E0CFC6@cs.purdue.edu>

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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 12pt=3B
> > >font-family:Calibri
> > >}
> > >--></style></head>
> > ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> > >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> > >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> > >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> > >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> > >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> > >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> > >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> > >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> > >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> > >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> > >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> > >t integer=2C which would then<br>successfully pass into the identical subra=
> > >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> > >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> > >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> > >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> > >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> > >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> > >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> > >on what you are saying=2C<br>the frontend should generate range checks befo=
> > >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> > >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> > >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> > >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> > >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> > >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> > >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> > >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> > >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> > >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> > >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> > >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> > >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> > >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> > >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> > >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> > >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> > >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> > >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> > >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> > >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> > >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> > >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> > >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> > >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> > >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> > >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> > >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> > >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> > >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> > >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> > >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> > >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > > restriction=2C do not handle out-of-range situations correctly. Things<br=
> > >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> > >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> > >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> > >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> > >culated integer and send your program off in<br>&gt=3B never-never land. I=
> > >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> > >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> > >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> > >&gt=3B Mika<br></div> </div></body>
> > ></html>=
> > >
> > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/dc682103/attachment.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
Message-ID: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>

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 <jay.krell at cornell.edu> 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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly. Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land. I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B Mika<br></div> </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/75907132/attachment.html>

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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
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<mailto:antony.hosking at gmail.com>
Date: Wed, 4 Sep 2013 13:31:01 -0400
CC: mika at async.caltech.edu<mailto:mika at async.caltech.edu>; m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
To: jay.krell at cornell.edu<mailto: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 <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:jay.krell at cornell.edu>
> Date: Wed, 4 Sep 2013 09:32:17 -0700
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto: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<mailto: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<mailto: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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<mailto:krell at cornell.edu><br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<mailto:mika at async.caltech.edu><br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=<http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=>
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly. Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land. I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B Mika<br></div> </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/6347c7b2/attachment.html>

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 <jay.krell at cornell.edu>
Para: m3devel <m3devel at elegosoft.com> 
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/c101bbd1/attachment.html>

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: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
References: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
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: <DUB123-DS399A346355DAF9A7179C2DD330@phx.gbl>

> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/ce5f54ae/attachment.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextLiteral.m3
Type: application/octet-stream
Size: 2989 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment-0001.obj>
-------------- 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" <rodney_bates at lcwb.coop> 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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	, , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, ,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>, ,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>,
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>,
	<522894AE.2070708@lcwb.coop>
Message-ID: <COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>

> > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130906/717f435d/attachment.html>

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: <COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, , ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, ,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>, ,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>,
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>,
	<522894AE.2070708@lcwb.coop>
	<COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>
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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
	<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" <rodney_bates at lcwb.coop> 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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>
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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
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 <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> 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 <mailto:jay.krell at cornell.edu>
>      > Date: Wed, 4 Sep 2013 09:32:17 -0700
>      > From:mika at async.caltech.edu <mailto:mika at async.caltech.edu>
>      > CC:m3devel at elegosoft.com <mailto: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 <mailto: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 <mailto: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
>      > >
>      > ><html>
>      > ><head>
>      > ><style><!--
>      > >.hmmessage P
>      > >{
>      > >margin:0px=3B
>      > >padding:0px
>      > >}
>      > >body.hmmessage
>      > >{
>      > >font-size: 12pt=3B
>      > >font-family:Calibri
>      > >}
>      > >--></style></head>
>      > ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>      > >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>      > >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>      > >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>      > >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>      > >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
>      > > that can be<br>successfully assigned to this range=2C with or without<br>a=
>      > > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>      > >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>      > >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>      > >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>      > >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>      > >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>      > >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>      > >t integer=2C which would then<br>successfully pass into the identical subra=
>      > >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>      > >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>      > >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>      > >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>      > >ngreal is target-dependent and knowledge<br>of it should only exist in the =
>      > >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>      > >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>      > >on what you are saying=2C<br>the frontend should generate range checks befo=
>      > >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>      > >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>      > >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>      > >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>      > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
>      > > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>      > >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>      > >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>      > >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>      > >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>      > >ded.<br><br><br>The frontend has some of those optimizations already -- con=
>      > >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>      > >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>      > >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>      > >krell at cornell.edu <mailto:krell at cornell.edu><br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>      > >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>      > >2 -0700<br>&gt=3B From: mika at async.caltech.edu <mailto:mika at async.caltech.edu><br>&gt=3B <br>&gt=3B Jay K w=
>      > >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>      > >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>      > >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= <http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=>
>      > >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>      > >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>      > >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>      > >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
>      > > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>      > >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>      > >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>      > >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>      > >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>      > >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>      > >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
>      > > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>      > >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
>      > > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>      > >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>      > >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>      > >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
>      > >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
>      > > restriction=2C do not handle out-of-range situations correctly. Things<br=
>      > >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>      > >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>      > >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
>      > >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>      > >culated integer and send your program off in<br>&gt=3B never-never land. I=
>      > >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
>      > >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
>      > > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>      > >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>      > >&gt=3B Mika<br></div> </div></body>
>      > ></html>=
>      > >
>      > >--_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: <COL125-W36B92A717EB8CB6AB9F4FE63E0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/346eb3a3/attachment.html>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/cdd75883/attachment.html>

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: <COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e8b98569/attachment.html>

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: <COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>
Message-ID: <COL125-W2746FAC87FA8A581DEC519E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/46d49968/attachment.html>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/14da7926/attachment.html>

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: <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/c90c2b25/attachment.html>

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: <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>
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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/aec3bc5c/attachment.html>

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>,
	<COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/0a9918a0/attachment.html>

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>,
	, <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/a8d1e82d/attachment.html>

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: <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>
Message-ID: <COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>




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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/6aea76fb/attachment.html>

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: <COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	, , <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>, ,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>,
	<COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>
Message-ID: <COL125-W926998DB3C41EE40D30CDE63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/5c57efd8/attachment.html>

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: <E77CF3D2-F038-431F-9E40-45603E412E10@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e5b580f7/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e5b580f7/attachment.sig>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130911/e644c3ba/attachment.html>

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: <COL125-W377B6B0382F8A56E87FBE3E63A0@phx.gbl>

 > 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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130912/4cd0a3ca/attachment.html>

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 <hosking at cs.purdue.edu>
> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130913/65c5665a/attachment.html>

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: <COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>

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 <hosking at cs.purdue.edu>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130913/ed0a02d4/attachment.html>

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: <COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>
References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu>, ,
	<0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu>,
	<COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>
Message-ID: <COL125-W31A90CEFFD8AF54C9A4FC7E6260@phx.gbl>

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 <hosking at cs.purdue.edu>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130916/f98023c2/attachment.html>

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: <COL125-W8DA9831289A06846E85D3E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/112dbcd1/attachment.html>

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: <COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>
Message-ID: <COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/f61c9135/attachment.html>

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: <COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
	<20130917180001.GA10942@zoho.com>
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>,
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>,
	<20130917183309.GB10942@zoho.com>
Message-ID: <COL125-W125C4652B5002A18F52362E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/8b97323a/attachment.html>

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: <COL125-W125C4652B5002A18F52362E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
	<20130917180001.GA10942@zoho.com>
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
	<20130917183309.GB10942@zoho.com>
	<COL125-W125C4652B5002A18F52362E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>,
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>,
	<20130917183309.GB10942@zoho.com>,
	<COL125-W125C4652B5002A18F52362E6270@phx.gbl>,
	<20130918081502.GA12109@zoho.com>
Message-ID: <COL125-W15C286DC87B74DF439B8D0E6200@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130918/3539d807/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/281c08b8/attachment.html>

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: <E77787D2-38EE-47C3-826B-60EEC812715E@cs.purdue.edu>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0002.html>

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: <COL125-W11AAB02B9854886CC46455E6210@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f5d9bdb4/attachment.html>

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: <COL125-W11AAB02B9854886CC46455E6210@phx.gbl>
References: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu>,
	<COL125-W11AAB02B9854886CC46455E6210@phx.gbl>
Message-ID: <COL125-W473762148B02FDA2664853E6230@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130921/c1135bc3/attachment.html>

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: <COL125-W367F8F53E285CBACE5BF34E62C0@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/31f4ba8f/attachment.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/0a31e51a/attachment.html>

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: <COL125-W3649993E2E6FEBD3958EBDE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/0904774a/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/27fc6081/attachment.html>

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: <COL125-W24D5B1B93A98B50B16724DE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/95adb71d/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/b68a00ee/attachment.html>

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: <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/85364fb4/attachment.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
Message-ID: <COL125-W43DD9362FB7D0484F6BF3FE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/b0a36105/attachment.html>

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: <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>
Message-ID: <COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4aebcbc0/attachment.html>

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: <COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>,
	<COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>
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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/bea8ff8a/attachment.html>

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>,
	, <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>, ,
	<COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL125-W354C017BCE3DBB44B3E208E62C0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4b47b241/attachment.html>

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: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/5486de0b/attachment.html>

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: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>
References: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>
Message-ID: <COL125-W81026C2BD32B62CB2FCD9E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4bfcf52c/attachment.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>,
	<523F261E.609@lcwb.coop>
Message-ID: <COL125-W249527410A9C462177DFF2E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/e09c2785/attachment.html>

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: <COL125-W249527410A9C462177DFF2E62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>, ,
	<523F261E.609@lcwb.coop>,
	<COL125-W249527410A9C462177DFF2E62C0@phx.gbl>
Message-ID: <COL125-W3548CB6DE5FB87C5CAC4C6E62D0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/2e075345/attachment.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/53dd4628/attachment.html>

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: <COL125-W34601DABB46B56667360CCE62D0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/dff29dc0/attachment.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/36f11445/attachment.html>

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: <COL125-W358C850017F82255BA7F3E62D0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/735ba621/attachment.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/2213b1ef/attachment.html>

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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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> [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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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 <module>
>      import pylib
>    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
>      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> To: rcolebur at scires.com <mailto:rcolebur at scires.com>; m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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 <mailto: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 <mailto:m3commit at elegosoft.com>
>> From:rcoleburn at elego.de <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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> 
> [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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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 <module>
>      import pylib
>    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
>      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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 <mailto: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 
>> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
>> <mailto: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: <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/28d63d12/attachment.html>

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: <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>
Message-ID: <COL125-W41324369F235E2956CC830E62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/b4aa5fa9/attachment.html>

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: <COL125-W41324369F235E2956CC830E62E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>,
	<COL125-W41324369F235E2956CC830E62E0@phx.gbl>
Message-ID: <COL125-W4AE33276CFB5380175A44E62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/ff51c8a2/attachment.html>

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: <COL125-W9334DAC3EB3D7A40EF58CE62F0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/03642f34/attachment.html>

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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
> To: rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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>
> > [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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <module>
> > import pylib
> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> > 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 <mailto: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<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com<mailto:rcolebur at scires.com> <mailto:rcolebur at scires.com>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <mailto: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
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/93f7d9ee/attachment.html>

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: <COL125-W4B226CB9F547B7585DD2FE62F0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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>


> > [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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <module>

> > import pylib

> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

> > 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 <mailto: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 <mailto:jay.krell at cornell.edu>

> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>;


> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <mailto: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 

> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de


> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/a42359e1/attachment.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
> To: rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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>
> > [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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <module>
> > import pylib
> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> > 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 <mailto: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<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com<mailto:rcolebur at scires.com> <mailto:rcolebur at scires.com>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <mailto: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
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/3905a16d/attachment.html>

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: <COL125-W25EAB4A48034365CDFEE8AE6280@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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>


> > [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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <module>

> > import pylib

> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

> > 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 <mailto: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 <mailto:jay.krell at cornell.edu>

> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>;


> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <mailto: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 

> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de


> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130926/b14619a1/attachment.html>

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               --  <builtin>
_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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130929/036a6a68/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130929/46854e27/attachment.html>

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: <COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>

 > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/dc75a452/attachment.html>

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: <COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/31ed83f4/attachment.html>

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>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
	<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" <rcolebur at SCIRES.COM> 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" <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/d5f8412b/attachment.html>

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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/a42ce480/attachment.html>

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" <rcolebur at SCIRES.COM> 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" <rcolebur at SCIRES.COM> 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" <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/809c6d41/attachment.html>

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>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
	<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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/88924d05/attachment.html>

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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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<http://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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/a34ceb89/attachment.html>

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: <COL125-W9C067B1E6DCE004F961AFE6360@phx.gbl>

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 <module>
    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 [<function _BuildGlobalFunction at 0x018E0A70>, <function _Shi

pFunction at 0x0197B630>] 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130831/0fef1f3b/attachment-0001.html>

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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/1c916139/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/c9a50385/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/c9a50385/attachment-0001.sig>

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: <COL125-W1086E3676EF77327AB0E5AE6350@phx.gbl>
References: <COL125-W1086E3676EF77327AB0E5AE6350@phx.gbl>
Message-ID: <COL125-W46C0D8C8AD28462324A034E6370@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/f5a63be2/attachment-0001.html>

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: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>
References: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>
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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>
References: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>
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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>,
	<5223BAA3.8040404@lcwb.coop>
Message-ID: <COL125-W2615CE8CCC5D51D31320DCE6370@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/cbd7e67e/attachment-0001.html>

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: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>,
	<5223B78E.5000901@lcwb.coop>
Message-ID: <COL125-W200AF3158789481D4902AE6370@phx.gbl>

 > 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 <stdio.h>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/f7447ee4/attachment-0001.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/ab7bee3f/attachment-0001.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/0196a06f/attachment-0001.html>

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: <COL125-W24A4F9E2065D02C025737EE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/2934d6c7/attachment-0001.html>

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: <COL125-W4020A8B78D129E0227A1D3E6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/525e92f1/attachment-0001.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
References: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/25a9c7b9/attachment-0001.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
Message-ID: <COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/51d644b2/attachment-0001.html>

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: <COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/ec7c76c6/attachment-0001.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
Message-ID: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>

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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/6bae5f6d/attachment-0001.html>

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: <COL125-W381613F44F7FEC390B275FE6310@phx.gbl>

> "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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/f6d844e9/attachment-0001.html>

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: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
Message-ID: <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu>

On Sep 3, 2013, at 1:50 PM, Jay K <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/8629f095/attachment-0001.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
	<275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu>
Message-ID: <D99C229C-EC8E-4DAF-A307-406798AE98AF@gmail.com>

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 <hosking at cs.purdue.edu> wrote:

> On Sep 3, 2013, at 1:50 PM, Jay K <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/61ba75de/attachment-0001.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/ca71444d/attachment-0001.html>

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? <dragisha at m3w.org> 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: <COL125-W7F4609891FF26930595E7E6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>,
	<20130904064212.318CF1A2080@async.async.caltech.edu>
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>
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
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 12pt=3B
>font-family:Calibri
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> that can be<br>successfully assigned to this range=2C with or without<br>a=
> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>t integer=2C which would then<br>successfully pass into the identical subra=
>nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>ngreal is target-dependent and knowledge<br>of it should only exist in the =
>backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>on what you are saying=2C<br>the frontend should generate range checks befo=
>re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>ded.<br><br><br>The frontend has some of those optimizations already -- con=
>verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
>rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
>_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
>t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> restriction=2C do not handle out-of-range situations correctly.  Things<br=
>>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
>n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>culated integer and send your program off in<br>&gt=3B never-never land.  I=
>n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
>t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>&gt=3B      Mika<br></div> 		 	   		  </div></body>
></html>=
>
>--_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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>,
	<20130904064212.318CF1A2080@async.async.caltech.edu>
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>
	<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
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 12pt=3B
>> font-family:Calibri
>> }
>> --></style></head>
>> <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>> perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>> compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>> r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>> bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>> from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
>> that can be<br>successfully assigned to this range=2C with or without<br>a=
>> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>> ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>> r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>> .<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>> s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>> teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>> systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>> t integer=2C which would then<br>successfully pass into the identical subra=
>> nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>> ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>> ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>> nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>> ngreal is target-dependent and knowledge<br>of it should only exist in the =
>> backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>> s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>> on what you are saying=2C<br>the frontend should generate range checks befo=
>> re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>> br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>> us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>> ) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
>> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>> =2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>> ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>> sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>> t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>> ded.<br><br><br>The frontend has some of those optimizations already -- con=
>> verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>> r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>> cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>> krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>> itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>> 2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
>> rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>> ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>> t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
>> _10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>> =3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>> re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>> =3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
>> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>> =3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>> &gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>> t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>> hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>> is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>> on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
>> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>> a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
>> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>> =2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>> gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>> d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
>> t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
>> restriction=2C do not handle out-of-range situations correctly.  Things<br=
>>> &gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>> ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>> n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
>> n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>> culated integer and send your program off in<br>&gt=3B never-never land.  I=
>> n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
>> t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
>> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>> ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>> &gt=3B      Mika<br></div> 		 	   		  </div></body>
>> </html>=
>> 
>> --_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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
Message-ID: <COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>

> 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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly.  Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land.  I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B      Mika<br></div> 		 	   		  </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/462bf6e6/attachment-0001.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>,
	<53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu>
Message-ID: <COL125-W30A8A3A5562C1EDEB2631DE6320@phx.gbl>

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
> >> 
> >> <html>
> >> <head>
> >> <style><!--
> >> .hmmessage P
> >> {
> >> margin:0px=3B
> >> padding:0px
> >> }
> >> body.hmmessage
> >> {
> >> font-size: 12pt=3B
> >> font-family:Calibri
> >> }
> >> --></style></head>
> >> <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >> perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >> compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >> r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >> bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >> from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> >> that can be<br>successfully assigned to this range=2C with or without<br>a=
> >> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >> ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >> r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >> .<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >> s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >> teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >> systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >> t integer=2C which would then<br>successfully pass into the identical subra=
> >> nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >> ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >> ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >> nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >> ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >> backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >> s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >> on what you are saying=2C<br>the frontend should generate range checks befo=
> >> re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >> br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >> us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >> ) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> >> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >> =2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >> ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >> sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >> t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >> ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >> verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >> r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >> cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >> krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >> itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >> 2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >> rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >> ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >> t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >> _10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >> re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> >> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >> &gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >> t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >> hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >> is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >> on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> >> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >> a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> >> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >> =2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >> gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >> d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
> >> t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> >> restriction=2C do not handle out-of-range situations correctly.  Things<br=
> >>> &gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >> ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >> n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
> >> n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >> culated integer and send your program off in<br>&gt=3B never-never land.  I=
> >> n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
> >> t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> >> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >> ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >> &gt=3B      Mika<br></div> 		 	   		  </div></body>
> >> </html>=
> >> 
> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/e69d7b8a/attachment-0001.html>

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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
Message-ID: <FAC40CE4-7278-4DBE-8478-FB58A3E0CFC6@cs.purdue.edu>

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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 12pt=3B
> > >font-family:Calibri
> > >}
> > >--></style></head>
> > ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> > >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> > >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> > >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> > >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> > >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> > >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> > >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> > >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> > >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> > >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> > >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> > >t integer=2C which would then<br>successfully pass into the identical subra=
> > >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> > >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> > >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> > >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> > >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> > >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> > >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> > >on what you are saying=2C<br>the frontend should generate range checks befo=
> > >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> > >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> > >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> > >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> > >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> > >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> > >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> > >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> > >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> > >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> > >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> > >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> > >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> > >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> > >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> > >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> > >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> > >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> > >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> > >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> > >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> > >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> > >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> > >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> > >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> > >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> > >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> > >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> > >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> > >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> > >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> > >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> > >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > > restriction=2C do not handle out-of-range situations correctly. Things<br=
> > >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> > >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> > >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> > >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> > >culated integer and send your program off in<br>&gt=3B never-never land. I=
> > >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> > >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> > >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> > >&gt=3B Mika<br></div> </div></body>
> > ></html>=
> > >
> > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/dc682103/attachment-0001.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
Message-ID: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>

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 <jay.krell at cornell.edu> 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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly. Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land. I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B Mika<br></div> </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/75907132/attachment-0001.html>

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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
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<mailto:antony.hosking at gmail.com>
Date: Wed, 4 Sep 2013 13:31:01 -0400
CC: mika at async.caltech.edu<mailto:mika at async.caltech.edu>; m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
To: jay.krell at cornell.edu<mailto: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 <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:jay.krell at cornell.edu>
> Date: Wed, 4 Sep 2013 09:32:17 -0700
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto: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<mailto: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<mailto: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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<mailto:krell at cornell.edu><br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<mailto:mika at async.caltech.edu><br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=<http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=>
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly. Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land. I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B Mika<br></div> </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/6347c7b2/attachment-0001.html>

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 <jay.krell at cornell.edu>
Para: m3devel <m3devel at elegosoft.com> 
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/c101bbd1/attachment-0001.html>

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: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
References: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
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: <DUB123-DS399A346355DAF9A7179C2DD330@phx.gbl>

> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/ce5f54ae/attachment-0001.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextLiteral.m3
Type: application/octet-stream
Size: 2989 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment-0003.obj>
-------------- 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" <rodney_bates at lcwb.coop> 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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	, , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, ,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>, ,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>,
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>,
	<522894AE.2070708@lcwb.coop>
Message-ID: <COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>

> > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130906/717f435d/attachment-0001.html>

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: <COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, , ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, ,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>, ,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>,
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>,
	<522894AE.2070708@lcwb.coop>
	<COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>
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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
	<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" <rodney_bates at lcwb.coop> 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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>
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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
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 <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> 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 <mailto:jay.krell at cornell.edu>
>      > Date: Wed, 4 Sep 2013 09:32:17 -0700
>      > From:mika at async.caltech.edu <mailto:mika at async.caltech.edu>
>      > CC:m3devel at elegosoft.com <mailto: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 <mailto: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 <mailto: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
>      > >
>      > ><html>
>      > ><head>
>      > ><style><!--
>      > >.hmmessage P
>      > >{
>      > >margin:0px=3B
>      > >padding:0px
>      > >}
>      > >body.hmmessage
>      > >{
>      > >font-size: 12pt=3B
>      > >font-family:Calibri
>      > >}
>      > >--></style></head>
>      > ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>      > >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>      > >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>      > >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>      > >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>      > >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
>      > > that can be<br>successfully assigned to this range=2C with or without<br>a=
>      > > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>      > >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>      > >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>      > >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>      > >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>      > >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>      > >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>      > >t integer=2C which would then<br>successfully pass into the identical subra=
>      > >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>      > >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>      > >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>      > >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>      > >ngreal is target-dependent and knowledge<br>of it should only exist in the =
>      > >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>      > >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>      > >on what you are saying=2C<br>the frontend should generate range checks befo=
>      > >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>      > >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>      > >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>      > >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>      > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
>      > > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>      > >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>      > >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>      > >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>      > >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>      > >ded.<br><br><br>The frontend has some of those optimizations already -- con=
>      > >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>      > >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>      > >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>      > >krell at cornell.edu <mailto:krell at cornell.edu><br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>      > >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>      > >2 -0700<br>&gt=3B From: mika at async.caltech.edu <mailto:mika at async.caltech.edu><br>&gt=3B <br>&gt=3B Jay K w=
>      > >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>      > >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>      > >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= <http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=>
>      > >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>      > >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>      > >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>      > >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
>      > > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>      > >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>      > >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>      > >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>      > >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>      > >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>      > >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
>      > > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>      > >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
>      > > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>      > >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>      > >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>      > >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
>      > >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
>      > > restriction=2C do not handle out-of-range situations correctly. Things<br=
>      > >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>      > >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>      > >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
>      > >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>      > >culated integer and send your program off in<br>&gt=3B never-never land. I=
>      > >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
>      > >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
>      > > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>      > >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>      > >&gt=3B Mika<br></div> </div></body>
>      > ></html>=
>      > >
>      > >--_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: <COL125-W36B92A717EB8CB6AB9F4FE63E0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/346eb3a3/attachment-0001.html>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/cdd75883/attachment-0001.html>

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: <COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e8b98569/attachment-0001.html>

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: <COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>
Message-ID: <COL125-W2746FAC87FA8A581DEC519E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/46d49968/attachment-0001.html>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/14da7926/attachment-0001.html>

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: <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/c90c2b25/attachment-0001.html>

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: <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>
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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/aec3bc5c/attachment-0001.html>

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>,
	<COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/0a9918a0/attachment-0001.html>

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>,
	, <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/a8d1e82d/attachment-0001.html>

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: <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>
Message-ID: <COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>




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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/6aea76fb/attachment-0001.html>

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: <COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	, , <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>, ,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>,
	<COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>
Message-ID: <COL125-W926998DB3C41EE40D30CDE63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/5c57efd8/attachment-0001.html>

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: <E77CF3D2-F038-431F-9E40-45603E412E10@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e5b580f7/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e5b580f7/attachment-0001.sig>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130911/e644c3ba/attachment-0001.html>

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: <COL125-W377B6B0382F8A56E87FBE3E63A0@phx.gbl>

 > 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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130912/4cd0a3ca/attachment-0001.html>

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 <hosking at cs.purdue.edu>
> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130913/65c5665a/attachment-0001.html>

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: <COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>

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 <hosking at cs.purdue.edu>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130913/ed0a02d4/attachment-0001.html>

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: <COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>
References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu>, ,
	<0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu>,
	<COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>
Message-ID: <COL125-W31A90CEFFD8AF54C9A4FC7E6260@phx.gbl>

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 <hosking at cs.purdue.edu>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130916/f98023c2/attachment-0001.html>

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: <COL125-W8DA9831289A06846E85D3E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/112dbcd1/attachment-0001.html>

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: <COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>
Message-ID: <COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/f61c9135/attachment-0001.html>

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: <COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
	<20130917180001.GA10942@zoho.com>
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>,
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>,
	<20130917183309.GB10942@zoho.com>
Message-ID: <COL125-W125C4652B5002A18F52362E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/8b97323a/attachment-0001.html>

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: <COL125-W125C4652B5002A18F52362E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
	<20130917180001.GA10942@zoho.com>
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
	<20130917183309.GB10942@zoho.com>
	<COL125-W125C4652B5002A18F52362E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>,
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>,
	<20130917183309.GB10942@zoho.com>,
	<COL125-W125C4652B5002A18F52362E6270@phx.gbl>,
	<20130918081502.GA12109@zoho.com>
Message-ID: <COL125-W15C286DC87B74DF439B8D0E6200@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130918/3539d807/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/281c08b8/attachment-0001.html>

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: <E77787D2-38EE-47C3-826B-60EEC812715E@cs.purdue.edu>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0003.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0004.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0005.html>

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: <COL125-W11AAB02B9854886CC46455E6210@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f5d9bdb4/attachment-0001.html>

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: <COL125-W11AAB02B9854886CC46455E6210@phx.gbl>
References: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu>,
	<COL125-W11AAB02B9854886CC46455E6210@phx.gbl>
Message-ID: <COL125-W473762148B02FDA2664853E6230@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130921/c1135bc3/attachment-0001.html>

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: <COL125-W367F8F53E285CBACE5BF34E62C0@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/31f4ba8f/attachment-0001.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/0a31e51a/attachment-0001.html>

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: <COL125-W3649993E2E6FEBD3958EBDE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/0904774a/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/27fc6081/attachment-0001.html>

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: <COL125-W24D5B1B93A98B50B16724DE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/95adb71d/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/b68a00ee/attachment-0001.html>

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: <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/85364fb4/attachment-0001.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
Message-ID: <COL125-W43DD9362FB7D0484F6BF3FE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/b0a36105/attachment-0001.html>

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: <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>
Message-ID: <COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4aebcbc0/attachment-0001.html>

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: <COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>,
	<COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>
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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/bea8ff8a/attachment-0001.html>

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>,
	, <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>, ,
	<COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL125-W354C017BCE3DBB44B3E208E62C0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4b47b241/attachment-0001.html>

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: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/5486de0b/attachment-0001.html>

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: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>
References: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>
Message-ID: <COL125-W81026C2BD32B62CB2FCD9E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4bfcf52c/attachment-0001.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>,
	<523F261E.609@lcwb.coop>
Message-ID: <COL125-W249527410A9C462177DFF2E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/e09c2785/attachment-0001.html>

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: <COL125-W249527410A9C462177DFF2E62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>, ,
	<523F261E.609@lcwb.coop>,
	<COL125-W249527410A9C462177DFF2E62C0@phx.gbl>
Message-ID: <COL125-W3548CB6DE5FB87C5CAC4C6E62D0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/2e075345/attachment-0001.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/53dd4628/attachment-0001.html>

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: <COL125-W34601DABB46B56667360CCE62D0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/dff29dc0/attachment-0001.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/36f11445/attachment-0001.html>

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: <COL125-W358C850017F82255BA7F3E62D0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/735ba621/attachment-0001.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/2213b1ef/attachment-0001.html>

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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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> [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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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 <module>
>      import pylib
>    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
>      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> To: rcolebur at scires.com <mailto:rcolebur at scires.com>; m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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 <mailto: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 <mailto:m3commit at elegosoft.com>
>> From:rcoleburn at elego.de <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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> 
> [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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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 <module>
>      import pylib
>    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
>      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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 <mailto: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 
>> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
>> <mailto: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: <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/28d63d12/attachment-0001.html>

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: <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>
Message-ID: <COL125-W41324369F235E2956CC830E62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/b4aa5fa9/attachment-0001.html>

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: <COL125-W41324369F235E2956CC830E62E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>,
	<COL125-W41324369F235E2956CC830E62E0@phx.gbl>
Message-ID: <COL125-W4AE33276CFB5380175A44E62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/ff51c8a2/attachment-0001.html>

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: <COL125-W9334DAC3EB3D7A40EF58CE62F0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/03642f34/attachment-0001.html>

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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
> To: rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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>
> > [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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <module>
> > import pylib
> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> > 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 <mailto: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<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com<mailto:rcolebur at scires.com> <mailto:rcolebur at scires.com>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <mailto: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
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/93f7d9ee/attachment-0001.html>

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: <COL125-W4B226CB9F547B7585DD2FE62F0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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>


> > [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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <module>

> > import pylib

> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

> > 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 <mailto: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 <mailto:jay.krell at cornell.edu>

> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>;


> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <mailto: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 

> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de


> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/a42359e1/attachment-0001.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
> To: rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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>
> > [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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <module>
> > import pylib
> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> > 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 <mailto: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<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com<mailto:rcolebur at scires.com> <mailto:rcolebur at scires.com>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <mailto: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
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/3905a16d/attachment-0001.html>

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: <COL125-W25EAB4A48034365CDFEE8AE6280@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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>


> > [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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <module>

> > import pylib

> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

> > 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 <mailto: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 <mailto:jay.krell at cornell.edu>

> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>;


> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <mailto: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 

> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de


> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130926/b14619a1/attachment-0001.html>

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               --  <builtin>
_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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130929/036a6a68/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130929/46854e27/attachment-0001.html>

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: <COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>

 > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/dc75a452/attachment-0001.html>

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: <COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/31ed83f4/attachment-0001.html>

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>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
	<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" <rcolebur at SCIRES.COM> 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" <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/d5f8412b/attachment-0001.html>

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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/a42ce480/attachment-0001.html>

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" <rcolebur at SCIRES.COM> 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" <rcolebur at SCIRES.COM> 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" <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/809c6d41/attachment-0001.html>

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>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
	<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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/88924d05/attachment-0001.html>

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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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<http://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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/a34ceb89/attachment-0001.html>

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: <COL125-W9C067B1E6DCE004F961AFE6360@phx.gbl>

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 <module>
    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 [<function _BuildGlobalFunction at 0x018E0A70>, <function _Shi

pFunction at 0x0197B630>] 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130831/0fef1f3b/attachment-0002.html>

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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/1c916139/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/c9a50385/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/c9a50385/attachment-0002.sig>

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: <COL125-W1086E3676EF77327AB0E5AE6350@phx.gbl>
References: <COL125-W1086E3676EF77327AB0E5AE6350@phx.gbl>
Message-ID: <COL125-W46C0D8C8AD28462324A034E6370@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/f5a63be2/attachment-0002.html>

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: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>
References: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>
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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>
References: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>
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: <COL125-W38F5D310997E823A6839B6E6370@phx.gbl>,
	<5223BAA3.8040404@lcwb.coop>
Message-ID: <COL125-W2615CE8CCC5D51D31320DCE6370@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/cbd7e67e/attachment-0002.html>

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: <COL125-W18B299F7DA7634B65D4617E6360@phx.gbl>,
	<5223B78E.5000901@lcwb.coop>
Message-ID: <COL125-W200AF3158789481D4902AE6370@phx.gbl>

 > 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 <stdio.h>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/f7447ee4/attachment-0002.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/ab7bee3f/attachment-0002.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/0196a06f/attachment-0002.html>

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: <COL125-W24A4F9E2065D02C025737EE6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/2934d6c7/attachment-0002.html>

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: <COL125-W4020A8B78D129E0227A1D3E6310@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/525e92f1/attachment-0002.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
References: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/25a9c7b9/attachment-0002.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
Message-ID: <COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/51d644b2/attachment-0002.html>

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: <COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/ec7c76c6/attachment-0002.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
Message-ID: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>

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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/6bae5f6d/attachment-0002.html>

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: <COL125-W381613F44F7FEC390B275FE6310@phx.gbl>

> "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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/f6d844e9/attachment-0002.html>

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: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
Message-ID: <275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu>

On Sep 3, 2013, at 1:50 PM, Jay K <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/8629f095/attachment-0002.html>

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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
	<275323F2-7BDE-43FA-B610-4F8A8CC243D1@cs.purdue.edu>
Message-ID: <D99C229C-EC8E-4DAF-A307-406798AE98AF@gmail.com>

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 <hosking at cs.purdue.edu> wrote:

> On Sep 3, 2013, at 1:50 PM, Jay K <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/61ba75de/attachment-0002.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/ca71444d/attachment-0002.html>

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? <dragisha at m3w.org> 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: <COL125-W7F4609891FF26930595E7E6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>,
	<20130904064212.318CF1A2080@async.async.caltech.edu>
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>
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
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 12pt=3B
>font-family:Calibri
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> that can be<br>successfully assigned to this range=2C with or without<br>a=
> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>t integer=2C which would then<br>successfully pass into the identical subra=
>nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>ngreal is target-dependent and knowledge<br>of it should only exist in the =
>backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>on what you are saying=2C<br>the frontend should generate range checks befo=
>re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>ded.<br><br><br>The frontend has some of those optimizations already -- con=
>verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
>rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
>_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
>t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> restriction=2C do not handle out-of-range situations correctly.  Things<br=
>>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
>n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>culated integer and send your program off in<br>&gt=3B never-never land.  I=
>n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
>t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>&gt=3B      Mika<br></div> 		 	   		  </div></body>
></html>=
>
>--_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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>,
	<20130904064212.318CF1A2080@async.async.caltech.edu>
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>
	<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
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 12pt=3B
>> font-family:Calibri
>> }
>> --></style></head>
>> <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>> perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>> compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>> r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>> bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>> from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
>> that can be<br>successfully assigned to this range=2C with or without<br>a=
>> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>> ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>> r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>> .<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>> s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>> teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>> systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>> t integer=2C which would then<br>successfully pass into the identical subra=
>> nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>> ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>> ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>> nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>> ngreal is target-dependent and knowledge<br>of it should only exist in the =
>> backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>> s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>> on what you are saying=2C<br>the frontend should generate range checks befo=
>> re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>> br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>> us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>> ) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
>> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>> =2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>> ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>> sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>> t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>> ded.<br><br><br>The frontend has some of those optimizations already -- con=
>> verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>> r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>> cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>> krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>> itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>> 2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
>> rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>> ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>> t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
>> _10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>> =3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>> re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>> =3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
>> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>> =3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>> &gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>> t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>> hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>> is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>> on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
>> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>> a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
>> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>> =2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>> gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>> d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
>> t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
>> restriction=2C do not handle out-of-range situations correctly.  Things<br=
>>> &gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>> ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>> n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
>> n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>> culated integer and send your program off in<br>&gt=3B never-never land.  I=
>> n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
>> t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
>> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>> ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>> &gt=3B      Mika<br></div> 		 	   		  </div></body>
>> </html>=
>> 
>> --_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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
Message-ID: <COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>

> 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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly.  Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land.  I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B      Mika<br></div> 		 	   		  </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/462bf6e6/attachment-0002.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>,
	<53DFD466-65B0-4DB7-901B-94985F8DF07A@cs.purdue.edu>
Message-ID: <COL125-W30A8A3A5562C1EDEB2631DE6320@phx.gbl>

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
> >> 
> >> <html>
> >> <head>
> >> <style><!--
> >> .hmmessage P
> >> {
> >> margin:0px=3B
> >> padding:0px
> >> }
> >> body.hmmessage
> >> {
> >> font-size: 12pt=3B
> >> font-family:Calibri
> >> }
> >> --></style></head>
> >> <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >> perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >> compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >> r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >> bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >> from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> >> that can be<br>successfully assigned to this range=2C with or without<br>a=
> >> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >> ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >> r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >> .<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >> s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >> teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >> systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >> t integer=2C which would then<br>successfully pass into the identical subra=
> >> nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >> ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >> ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >> nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >> ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >> backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >> s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >> on what you are saying=2C<br>the frontend should generate range checks befo=
> >> re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >> br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >> us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >> ) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> >> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >> =2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >> ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >> sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >> t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >> ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >> verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >> r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >> cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >> krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >> itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >> 2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >> rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >> ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >> t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >> _10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >> re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> >> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >> &gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >> t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >> hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >> is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >> on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> >> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >> a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> >> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >> =2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >> gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >> d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
> >> t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> >> restriction=2C do not handle out-of-range situations correctly.  Things<br=
> >>> &gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >> ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >> n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
> >> n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >> culated integer and send your program off in<br>&gt=3B never-never land.  I=
> >> n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
> >> t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> >> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >> ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >> &gt=3B      Mika<br></div> 		 	   		  </div></body>
> >> </html>=
> >> 
> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/e69d7b8a/attachment-0002.html>

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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
Message-ID: <FAC40CE4-7278-4DBE-8478-FB58A3E0CFC6@cs.purdue.edu>

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 <jay.krell at cornell.edu> 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 <jay.krell at cornell.edu> 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
> > >
> > ><html>
> > ><head>
> > ><style><!--
> > >.hmmessage P
> > >{
> > >margin:0px=3B
> > >padding:0px
> > >}
> > >body.hmmessage
> > >{
> > >font-size: 12pt=3B
> > >font-family:Calibri
> > >}
> > >--></style></head>
> > ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> > >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> > >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> > >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> > >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> > >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> > >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> > >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> > >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> > >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> > >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> > >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> > >t integer=2C which would then<br>successfully pass into the identical subra=
> > >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> > >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> > >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> > >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> > >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> > >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> > >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> > >on what you are saying=2C<br>the frontend should generate range checks befo=
> > >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> > >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> > >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> > >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> > >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> > >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> > >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> > >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> > >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> > >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> > >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> > >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> > >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> > >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> > >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> > >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> > >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> > >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> > >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> > >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> > >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> > >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> > >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> > >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> > >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> > >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> > >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> > >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> > >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> > >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> > >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> > >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> > >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > > restriction=2C do not handle out-of-range situations correctly. Things<br=
> > >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> > >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> > >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> > >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> > >culated integer and send your program off in<br>&gt=3B never-never land. I=
> > >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> > >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> > >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> > >&gt=3B Mika<br></div> </div></body>
> > ></html>=
> > >
> > >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/dc682103/attachment-0002.html>

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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
Message-ID: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>

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 <jay.krell at cornell.edu> 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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly. Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land. I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B Mika<br></div> </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/75907132/attachment-0002.html>

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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
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<mailto:antony.hosking at gmail.com>
Date: Wed, 4 Sep 2013 13:31:01 -0400
CC: mika at async.caltech.edu<mailto:mika at async.caltech.edu>; m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
To: jay.krell at cornell.edu<mailto: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 <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:jay.krell at cornell.edu>
> Date: Wed, 4 Sep 2013 09:32:17 -0700
> From: mika at async.caltech.edu<mailto:mika at async.caltech.edu>
> CC: m3devel at elegosoft.com<mailto: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<mailto: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<mailto: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
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 12pt=3B
> >font-family:Calibri
> >}
> >--></style></head>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> > that can be<br>successfully assigned to this range=2C with or without<br>a=
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >t integer=2C which would then<br>successfully pass into the identical subra=
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >on what you are saying=2C<br>the frontend should generate range checks befo=
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >krell at cornell.edu<mailto:krell at cornell.edu><br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >2 -0700<br>&gt=3B From: mika at async.caltech.edu<mailto:mika at async.caltech.edu><br>&gt=3B <br>&gt=3B Jay K w=
> >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=<http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=>
> >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
> > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
> >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> > restriction=2C do not handle out-of-range situations correctly. Things<br=
> >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
> >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >culated integer and send your program off in<br>&gt=3B never-never land. I=
> >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
> >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >&gt=3B Mika<br></div> </div></body>
> ></html>=
> >
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/6347c7b2/attachment-0002.html>

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 <jay.krell at cornell.edu>
Para: m3devel <m3devel at elegosoft.com> 
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/c101bbd1/attachment-0002.html>

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: <COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>
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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
References: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
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: <DUB123-DS399A346355DAF9A7179C2DD330@phx.gbl>

> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/ce5f54ae/attachment-0002.html>

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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextLiteral.m3
Type: application/octet-stream
Size: 2989 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment-0005.obj>
-------------- 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" <rodney_bates at lcwb.coop> 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: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>,
	, , <90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, ,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>, ,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>,
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>,
	<522894AE.2070708@lcwb.coop>
Message-ID: <COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>

> > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130906/717f435d/attachment-0002.html>

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: <COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>
References: <COL125-W26213B9DB4DA605B5472FEE6310@phx.gbl>, , ,
	<90685107-E39F-4E65-B7E3-DC7D15CBAA8B@gmail.com>, ,
	<COL125-W33801B6F40D23CC7E40274E6310@phx.gbl>, ,
	<1A519E82-E632-4AD6-B593-B8EBE45B7EC4@cs.purdue.edu>,
	<COL125-W28FCA1BFBBAB89F3CFF11FE6310@phx.gbl>,
	<522894AE.2070708@lcwb.coop>
	<COL125-W1542FD1CF8FD2C98804C7BE63C0@phx.gbl>
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: <COL125-W42AE013EACF4590B24633EE6310@phx.gbl>
	<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" <rodney_bates at lcwb.coop> 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: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>
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: <COL125-W51C648FC395C737F775FACE6320@phx.gbl>
References: <COL125-W12D194FAA718D95C8BB189E6320@phx.gbl>, ,
	<20130904064212.318CF1A2080@async.async.caltech.edu>,
	<COL125-W7F4609891FF26930595E7E6320@phx.gbl>,
	<20130904163217.C90041A2080@async.async.caltech.edu>
	<COL125-W294C680A01FF0C9A0A64ADE6320@phx.gbl>,
	<95F99D4E-62B0-43C7-84DD-38742E5D25FF@gmail.com>
	<COL125-W51C648FC395C737F775FACE6320@phx.gbl>
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 <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> 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 <mailto:jay.krell at cornell.edu>
>      > Date: Wed, 4 Sep 2013 09:32:17 -0700
>      > From:mika at async.caltech.edu <mailto:mika at async.caltech.edu>
>      > CC:m3devel at elegosoft.com <mailto: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 <mailto: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 <mailto: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
>      > >
>      > ><html>
>      > ><head>
>      > ><style><!--
>      > >.hmmessage P
>      > >{
>      > >margin:0px=3B
>      > >padding:0px
>      > >}
>      > >body.hmmessage
>      > >{
>      > >font-size: 12pt=3B
>      > >font-family:Calibri
>      > >}
>      > >--></style></head>
>      > ><body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
>      > >perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
>      > >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
>      > >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
>      > >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
>      > >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
>      > > that can be<br>successfully assigned to this range=2C with or without<br>a=
>      > > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
>      > >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
>      > >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
>      > >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
>      > >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
>      > >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
>      > >systems will fail here.<br>32bit Posix would continue to round to some 32bi=
>      > >t integer=2C which would then<br>successfully pass into the identical subra=
>      > >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
>      > >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
>      > >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
>      > >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
>      > >ngreal is target-dependent and knowledge<br>of it should only exist in the =
>      > >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
>      > >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
>      > >on what you are saying=2C<br>the frontend should generate range checks befo=
>      > >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
>      > >br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
>      > >us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
>      > >) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
>      > >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
>      > > + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
>      > >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
>      > >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
>      > >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
>      > >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
>      > >ded.<br><br><br>The frontend has some of those optimizations already -- con=
>      > >verting<br>from a smaller range to a larger range needs no check.<br><br><b=
>      > >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
>      > >cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
>      > >krell at cornell.edu <mailto:krell at cornell.edu><br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
>      > >itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
>      > >2 -0700<br>&gt=3B From: mika at async.caltech.edu <mailto:mika at async.caltech.edu><br>&gt=3B <br>&gt=3B Jay K w=
>      > >rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
>      > >ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
>      > >t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6= <http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=>
>      > >_10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
>      > >=3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
>      > >re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
>      > >=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
>      > > Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
>      > >=3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
>      > >&gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
>      > >t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
>      > >hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
>      > >is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
>      > >on as saying "integer"=2C not "INTEGER". That is=2C<br>&gt=3B "integer" is=
>      > > the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
>      > >a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
>      > > Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
>      > >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=
>      > >gt=3B and when the implementation can no longer accomplish that=2C it shoul=
>      > >d signal a <br>&gt=3B runtime error. <br>&gt=3B <br>&gt=3B It happens tha=
>      > >t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
>      > > restriction=2C do not handle out-of-range situations correctly. Things<br=
>      > >>&gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
>      > >ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
>      > >n think that's right. Of<br>&gt=3B course it's not as bad as it might be i=
>      > >n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
>      > >culated integer and send your program off in<br>&gt=3B never-never land. I=
>      > >n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point. Bu=
>      > >t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
>      > > what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
>      > >ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
>      > >&gt=3B Mika<br></div> </div></body>
>      > ></html>=
>      > >
>      > >--_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: <COL125-W36B92A717EB8CB6AB9F4FE63E0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/346eb3a3/attachment-0002.html>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/cdd75883/attachment-0002.html>

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: <COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e8b98569/attachment-0002.html>

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: <COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF168E8@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W1158695626B5322AEA4BA7E63E0@phx.gbl>
Message-ID: <COL125-W2746FAC87FA8A581DEC519E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/46d49968/attachment-0002.html>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/14da7926/attachment-0002.html>

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: <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/c90c2b25/attachment-0002.html>

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: <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>
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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/aec3bc5c/attachment-0002.html>

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>,
	<COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/0a9918a0/attachment-0002.html>

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>,
	, <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/a8d1e82d/attachment-0002.html>

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: <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>
Message-ID: <COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>




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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/6aea76fb/attachment-0002.html>

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: <COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF1695D@ATLEX04-SRV.SCIRES.LOCAL>,
	, , <COL125-W36E3A0ED94A0042422A8A0E63E0@phx.gbl>, ,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169D0@ATLEX04-SRV.SCIRES.LOCAL>,
	,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF169E0@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W52CDDEF48730B6FAE6DE03E63E0@phx.gbl>,
	<COL125-W45A463BA75FF1DF88F818E63E0@phx.gbl>
Message-ID: <COL125-W926998DB3C41EE40D30CDE63E0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 631, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/5c57efd8/attachment-0002.html>

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: <E77CF3D2-F038-431F-9E40-45603E412E10@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e5b580f7/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130908/e5b580f7/attachment-0002.sig>

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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130911/e644c3ba/attachment-0002.html>

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: <COL125-W377B6B0382F8A56E87FBE3E63A0@phx.gbl>

 > 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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130912/4cd0a3ca/attachment-0002.html>

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 <hosking at cs.purdue.edu>
> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130913/65c5665a/attachment-0002.html>

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: <COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>

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 <hosking at cs.purdue.edu>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130913/ed0a02d4/attachment-0002.html>

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: <COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>
References: <201309131145.r8DBjPr0026042@niagara.cs.purdue.edu>, ,
	<0217BD82-3165-4F92-B221-536F5710A83D@cs.purdue.edu>,
	<COL125-W567FABBE5C8C1B75CB180E63B0@phx.gbl>
Message-ID: <COL125-W31A90CEFFD8AF54C9A4FC7E6260@phx.gbl>

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 <hosking at cs.purdue.edu>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130916/f98023c2/attachment-0002.html>

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: <COL125-W8DA9831289A06846E85D3E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/112dbcd1/attachment-0002.html>

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: <COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>
Message-ID: <COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/f61c9135/attachment-0002.html>

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: <COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
	<20130917180001.GA10942@zoho.com>
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>,
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>,
	<20130917183309.GB10942@zoho.com>
Message-ID: <COL125-W125C4652B5002A18F52362E6270@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130917/8b97323a/attachment-0002.html>

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: <COL125-W125C4652B5002A18F52362E6270@phx.gbl>
References: <20130917151045.6D7195DEB73@birch.elegosoft.com>
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>
	<20130917180001.GA10942@zoho.com>
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>
	<20130917183309.GB10942@zoho.com>
	<COL125-W125C4652B5002A18F52362E6270@phx.gbl>
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>,
	<COL125-W8DA9831289A06846E85D3E6270@phx.gbl>,
	<20130917180001.GA10942@zoho.com>,
	<COL125-W8626B2BC5AF7AB6A9F5C8E6270@phx.gbl>,
	<20130917183309.GB10942@zoho.com>,
	<COL125-W125C4652B5002A18F52362E6270@phx.gbl>,
	<20130918081502.GA12109@zoho.com>
Message-ID: <COL125-W15C286DC87B74DF439B8D0E6200@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130918/3539d807/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/281c08b8/attachment-0002.html>

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: <E77787D2-38EE-47C3-826B-60EEC812715E@cs.purdue.edu>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0006.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0007.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f211557a/attachment-0008.html>

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: <COL125-W11AAB02B9854886CC46455E6210@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130919/f5d9bdb4/attachment-0002.html>

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: <COL125-W11AAB02B9854886CC46455E6210@phx.gbl>
References: <83BFF94F-D5D7-441F-9768-6452F3DA3A37@cs.purdue.edu>,
	<COL125-W11AAB02B9854886CC46455E6210@phx.gbl>
Message-ID: <COL125-W473762148B02FDA2664853E6230@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130921/c1135bc3/attachment-0002.html>

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: <COL125-W367F8F53E285CBACE5BF34E62C0@phx.gbl>


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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/31f4ba8f/attachment-0002.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/0a31e51a/attachment-0002.html>

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: <COL125-W3649993E2E6FEBD3958EBDE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/0904774a/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/27fc6081/attachment-0002.html>

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: <COL125-W24D5B1B93A98B50B16724DE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/95adb71d/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/b68a00ee/attachment-0002.html>

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: <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/85364fb4/attachment-0002.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
Message-ID: <COL125-W43DD9362FB7D0484F6BF3FE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/b0a36105/attachment-0002.html>

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: <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>
Message-ID: <COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4aebcbc0/attachment-0002.html>

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: <COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CC4A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>,
	<COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>
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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/bea8ff8a/attachment-0002.html>

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>,
	, <COL125-W189C845BD71BF59BBC77ADE62C0@phx.gbl>, ,
	<COL125-W3101E08794BBCEF905C44AE62C0@phx.gbl>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF5CF2CCF2@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL125-W354C017BCE3DBB44B3E208E62C0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4b47b241/attachment-0002.html>

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: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/5486de0b/attachment-0002.html>

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: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>
References: <COL125-W16EAA63B276BA49D32F0A1E62C0@phx.gbl>
Message-ID: <COL125-W81026C2BD32B62CB2FCD9E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/4bfcf52c/attachment-0002.html>

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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>
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: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>,
	<523F261E.609@lcwb.coop>
Message-ID: <COL125-W249527410A9C462177DFF2E62C0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130922/e09c2785/attachment-0002.html>

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: <COL125-W249527410A9C462177DFF2E62C0@phx.gbl>
References: <COL125-W388CD28BAA2BD69C8D63EEE62C0@phx.gbl>, ,
	<523F261E.609@lcwb.coop>,
	<COL125-W249527410A9C462177DFF2E62C0@phx.gbl>
Message-ID: <COL125-W3548CB6DE5FB87C5CAC4C6E62D0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/2e075345/attachment-0002.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/53dd4628/attachment-0002.html>

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: <COL125-W34601DABB46B56667360CCE62D0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/dff29dc0/attachment-0002.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/36f11445/attachment-0002.html>

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: <COL125-W358C850017F82255BA7F3E62D0@phx.gbl>

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

    import pylib

  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

    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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/735ba621/attachment-0002.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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 <module>
    import pylib
  File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
    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<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:m3commit at elegosoft.com>
> From: rcoleburn at elego.de<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/2213b1ef/attachment-0002.html>

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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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> [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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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 <module>
>      import pylib
>    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
>      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> To: rcolebur at scires.com <mailto:rcolebur at scires.com>; m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com <mailto: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 <mailto: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 <mailto:m3commit at elegosoft.com>
>> From:rcoleburn at elego.de <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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> 
> [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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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 <module>
>      import pylib
>    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
>      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com <mailto: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 <mailto: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 
>> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
>> <mailto: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: <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/28d63d12/attachment-0002.html>

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: <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>
Message-ID: <COL125-W41324369F235E2956CC830E62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/b4aa5fa9/attachment-0002.html>

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: <COL125-W41324369F235E2956CC830E62E0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF2EA3A@ATLEX04-SRV.SCIRES.LOCAL>,
	, <COL125-W32BE88CA71F0200C558D6FE62E0@phx.gbl>,
	<COL125-W41324369F235E2956CC830E62E0@phx.gbl>
Message-ID: <COL125-W4AE33276CFB5380175A44E62E0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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> 
> > [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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <module>
> >      import pylib
> >    File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> >      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 <mailto: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 <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>; 
> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>; 
> > m3devel at elegosoft.com <mailto: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 <mailto: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 
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de 
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130924/ff51c8a2/attachment-0002.html>

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: <COL125-W9334DAC3EB3D7A40EF58CE62F0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/03642f34/attachment-0002.html>

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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
> To: rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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>
> > [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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <module>
> > import pylib
> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> > 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 <mailto: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<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com<mailto:rcolebur at scires.com> <mailto:rcolebur at scires.com>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <mailto: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
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/93f7d9ee/attachment-0002.html>

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: <COL125-W4B226CB9F547B7585DD2FE62F0@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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>


> > [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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <module>

> > import pylib

> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

> > 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 <mailto: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 <mailto:jay.krell at cornell.edu>

> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>;


> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <mailto: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 

> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de


> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/a42359e1/attachment-0002.html>

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<mailto:rcolebur at SCIRES.COM>
To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; m3devel at elegosoft.com<mailto: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> [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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto:rcolebur at SCIRES.COM>
> To: rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; m3devel at elegosoft.com<mailto: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<mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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>
> > [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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <module>
> > import pylib
> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>
> > 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 <mailto: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<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>
> > To: rcolebur at scires.com<mailto:rcolebur at scires.com> <mailto:rcolebur at scires.com>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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<mailto:rcolebur at SCIRES.COM> <mailto:rcolebur at SCIRES.COM>
> > To: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu> <mailto:jay.krell at cornell.edu>;
> > m3devel at elegosoft.com<mailto:m3devel at elegosoft.com> <mailto: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 <mailto: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
> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de
> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130925/3905a16d/attachment-0002.html>

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: <COL125-W25EAB4A48034365CDFEE8AE6280@phx.gbl>

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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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>


> > [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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <module>

> > import pylib

> > File "C:\cm3\Sandbox\cm3\scripts\python\pylib.py", line 650, in <module>

> > 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 <mailto: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 <mailto:jay.krell at cornell.edu>

> > To: rcolebur at scires.com <mailto:rcolebur at scires.com>;


> > m3devel at elegosoft.com <mailto: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 <mailto:rcolebur at SCIRES.COM>

> > To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>;


> > m3devel at elegosoft.com <mailto: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 <mailto: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 

> >> <mailto:m3commit at elegosoft.com> From:rcoleburn at elego.de


> >> <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130926/b14619a1/attachment-0002.html>

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               --  <builtin>
_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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130929/036a6a68/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130929/46854e27/attachment-0002.html>

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: <COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>

 > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/dc75a452/attachment-0002.html>

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: <COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF36A61@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/31ed83f4/attachment-0002.html>

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>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
	<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" <rcolebur at SCIRES.COM> 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" <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/d5f8412b/attachment-0002.html>

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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/a42ce480/attachment-0002.html>

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" <rcolebur at SCIRES.COM> 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" <rcolebur at SCIRES.COM> 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" <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/809c6d41/attachment-0002.html>

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>,
	<COL125-W956FAEAC234AF1EB40AC1E6140@phx.gbl>
	<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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/88924d05/attachment-0002.html>

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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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<http://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" <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> 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" <jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>> 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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/a34ceb89/attachment-0002.html>