> Hang on mo'; it's just finally sunk in that you're talking about
> version 3-point-frigging-seven here. That is _so_ last year. June last
> year in fact.
To a significantly large number of people, it is far (vastly,
extremely, infinitely) more important to have a rock-solid out-of-date
platform than one in which all the latest bells and whistles (almost)
work. The 3.7 Unix VM is going to be very important to many of these
people for a long time yet. Delivering a broken 3.7 final (or one that
they cannot reproduce reliably for themselves from scratch) would be
nothing short of irresponsible.
> On Mar 18, 2005, at 11:51, Tim Rowledge wrote:
> >> Is it too late to post these changes to the 3.7 update stream?
> > Not so much too late as irrelevant. They are VMMaker changes and would
> > go into a re-released VMMaker package on SM.
> They would be very, very relevant to anyone trying to make a working VM
> from a 3.7 image and the 3.7 final VM sources. (Including me. I
> normally would refuse to include anything not in the image/update
> stream when building a release VM.)
It's a package. It isn't in the basic image to be updated. Yes, it is
in the -full image but so far as I know updates to that are no
different than those for the -basic. I was under the impression that
packages included in -full are supposed to be updated via SM.
It's certainly possible I've missed something but in general my
expected path for updating VMMaker is to load the more recent version
from SM. For 3.8 or thereabouts I was planning on moving to using an
On Friday 18 March 2005 11:46 am, Ian Piumarta wrote:
> On Mar 18, 2005, at 11:39, Ned Konz wrote:
> > On Friday 18 March 2005 11:16 am, Ian Piumarta wrote:
> >>> What VMMaker version does that correspond to?
> >> The one in 3.7-5898-full.
> > Great. I'll apply my changes to it instead.
> Double great! If you (or anyone) then confirm that they fix the image
> segment loading problem seen by Bert and the Squeaklanders, they'll be
> in my final released source/binary VM and image archives. (Provided
> Bert sees no problem with using them instead of Jens' changeset.)
> Is it too late to post these changes to the 3.7 update stream?
OK, here's the changes.
I have built a VM with them applied to the full image, and with your unix
sources, and verified that it can, in fact, load the SqueakMap package list
(which usually breaks on my system).
I'll note the use of signed versus unsigned might require a bit more
thought. Really want *should* happen is getting an oops address back
is really a squeakOopAddress type. Then when people do math on it it
needs to be looked at carefully. Perhaps a add/subtract method that
will do the
right thing? The danger of piecemeal mod leaves you with an image that
kinda works, but deep down when something says grab the oops address
4 under certain conditions means disaster. mmm really I've thought
about defining that type then turning warnings on, then following the
results, but that means of course cross checking all the platform
dependent code too because they should be getting squeakOopAddress
PS many years ago I put together a change set to alter slang so that if
you returned nothing from a method, or a typecasted value it would
generate the C code as returning
the void or data type. That could rid of the thousand warnings about
routine does not return int but declared as returning int. However as
Tim discovered we do evil things in the
VM external API and say for example setting the error prim result
returns int, when in fact it does not return int. Then people have
coded routines and say return seterror().
On Mar 18, 2005, at 11:39 AM, Ned Konz wrote:
> On Friday 18 March 2005 11:16 am, Ian Piumarta wrote:
>>> What VMMaker version does that correspond to?
>> The one in 3.7-5898-full.
>> 1. It's a 3.7 VM, so the rule says it has to be built from a 3.7
>> image. The final 3.7 VM is built from the final 3.7-full image.
>> 2. Look in configure.ac (or watch the first few lines printed by
>> configure as it runs) and it tells you exactly which image version
>> generated the (bundled) interpreter sources.
> Great. I'll apply my changes to it instead.
> Ned Konz
> http://bike-nomad.com >
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ========================================================================
> I'll note the use of signed versus unsigned might require a bit more
> thought. Really want *should* happen is getting an oops address back
> is really a squeakOopAddress type.
> I've thought about defining that type then turning warnings on, then
> following the results, but that means of course cross checking all the
> platform dependent code too because they should be getting
> squeakOopAddress versus int.
The 64-bit changes I sent to Tim effectively do precisely that.
The one thing I didn't get around to doing before shipping it all to
Tim (which I will retrofit when Tim is done holding the Interpreter/VMM
token) is modify the types slightly to (1) make it absolutely
impossible to mix integers and oops without going through the relevant
conversion function, and (2) fix the current situation where sqInt and
sqLong look similar but behave not quite the way you might expect
relative to each other. (Dan and I are already overdue for some work
on our 64-bit stuff anyway, and this is one thing I need to address
during it. The impact on platform code will be minimal. If Tim
doesn't mind receiving changesets relative to changeset that are still
being pulled forward then I could start on this right away. Otherwise
we're waiting on him, and when VMM is generating a 64-bit Interpreter
correctly I'll just assume the token for day and fix it in-situ.)