<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Yes and no. I was thinking about this too.<BR>
In general this "race" never ends.<BR>
However:<BR>
- right this is first release with LONGINT, and I think there are incompatibilities between head and release esp. wrt "ORD"<BR>
(Had we added e.g. "assignability" and release was just a compatible subset, different; I think it is actually "incompatible".)<BR>
<BR>
- the "race" should actually "slow down" now that I fixed the platform list problem :)<BR>
but still, the "race" isn't guaranteeably gone; there might still be new language features that m3core/libm3 use<BR>
(to be clear, the "front" group needs to be more careful about using more features;<BR>
for example, it would be "useful" for me to use LONGINT in m3back, and then build a non-NT386 hosted compiler, in order to get LONGINT support into NT386, however my preference at the moment is to use Target.Int to "simulate" 64bit arithmetic in the compiler ("constant folding" and such, as it already does for 32bit integers); the compiler basically supports targeting 32bit INTEGER even on a host with only 8 or 16bit INTEGER, as I understand).<BR>
<BR>
<BR>
If I or anyone checks that the exception is gone now in GUI file open dialog, maybe merge those changes too.<BR>
They are pretty small. I haven't touched rd/wr yet (well, they were touched *slightly*).<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Wed, 13 Jan 2010 10:43:03 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal<BR>> <BR>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<BR>> <BR>> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:<BR>> ><BR>> >> Also, in case anyone is interested, the current HEAD fails to <BR>> >> compile the following packages on Windows Vista:<BR>> >> "m3-libs\m3core"<BR>> >> "m3-libs\libm3"<BR>> >> "m3-tools\m3tk"<BR>> >> So some recent changes have caused a problem.<BR>> ><BR>> > Did you bootstrap a new compiler? You will need to bootstrap a <BR>> > compiler before you can compile the revised ORD/VAL definitions.<BR>> <BR>> So if I understand this correctly, should we finally get to release<BR>> 5.8, then this compiler won't be able to compile the current trunk<BR>> head? That is, not unless we merge this change to the release branch?<BR>> <BR>> Anything else that we should do for 5.8?<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR> </body>
</html>