Unix 3.7 gamma VM

On Mar 18, 2005, at 12:09, Tim Rowledge wrote:

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

Ian

In message <[hidden email]>
          Ian Piumarta <[hidden email]> wrote:

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
mcz package.

tim
--
Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim
Useful random insult:- Brain transplant donor.

On Friday 18 March 2005 11:46 am, Ian Piumarta wrote: 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).

--
Ned Konz
http://bike-nomad.com

Ned's Changes...

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  
and add/subtract
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  
versus int.

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:
--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

On Mar 18, 2005, at 12:41, John M McIntosh wrote:

> 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.)

Ian