1. How come it insists on loading external modules when it

has internal ones already loaded (see LargeIntegers, etc.) below:?

Simple: Externals *always* override internals. If there is an external module the system should use the external module.

Cheers, - Andreas

On Mar 18, 2005, at 09:07, Ned Konz wrote:

On Friday 18 March 2005 1:48 am, Bert Freudenberg wrote:

...

The image segment loading bug is a show-stopper - changeset attached.

But I'm not sure that's all the problems we're seeing.

Fixing it a little might be better than not fixing it at all.

Bert: does applying this changeset turn a 3.7-5898 VM that you cannot use into a VM that you can use?

Cheers, Ian

Yes. Project loading will fail on two of our Linux machines without this, now it works. The -mmap workaround only worked on one machine, with the CS applied it isn't even necessary. So, if all agree that it cannot hurt, it definitely helps in our case (which also was reported a few times by other Linux users).

Let me second this. This is a *major* issue for Squeakland-people running on Linux.

Cheers, - Andreas

In message 200503180907.13741.ned@bike-nomad.com Ned Konz ned@bike-nomad.com wrote:

On Friday 18 March 2005 1:48 am, Bert Freudenberg wrote:

...

The image segment loading bug is a show-stopper - changeset attached.

But I'm not sure that's all the problems we're seeing. For one thing, the comparison

oop < endOfMemory

when oop is < 2Gb and endOfMemory is >2Gb will fail. There are similar problems throughout the code.

Exactly the point I was trying to make a week ago; did anyone compile and try the simple testcase I included?

I have some changes that make endOfMemory, youngSpaceStart, etc. into unsigned. I think they're more comprehensive, and still seem to work. You might want to take a look at them.

Will do. I'm trying to make some progress on the 64bit stuff anyway.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Sat under the ozone hole too long.

In message 200503181040.35034.ned@bike-nomad.com Ned Konz ned@bike-nomad.com wrote:

What VMMaker version does that correspond to?

I see significant differences (for instance, in interp.c and in the LargeIntegersPlugin) between the sources generated from VMMaker-tpr.5.mcz (30 Mar 2004) on SqueakSource (repository at http://kilana.unibe.ch:8888/VMMaker) and the generated sources in your src directory.

Whoah, that code is massively out of date; I was never able to get a decent working setup that would save there, then they had problems and I had network problems and then I guess I simply forgot about it. The SM version is the latest for public consumption. Hmm, I'm up to version 13 in my local repository which is (I think) equivalent to VMMaker3-8b2.1.cs from SM.

Right now I'm spending a little time trying to integrate the 64bit stuff and then I'll look at your changes to properly type the main oop values which should be a good step to fixing the >2Gb problems. It might save me some time if you could cast those changes in terms of the sqLong/sqInt etc #defines from the 64bit changes.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Performance is easier to add than clarity.

On Mar 18, 2005, at 10:40, Ned Konz wrote:

On Thursday 17 March 2005 2:08 pm, Ian Piumarta wrote:

...

 svn co http://squeak.hpl.hp.com/svn/squeak/tags/unix-3.7g-6

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.

I see significant differences (for instance, in interp.c and in the LargeIntegersPlugin) between the sources generated from VMMaker-tpr.5.mcz (30 Mar 2004) on SqueakSource (repository at http://kilana.unibe.ch:8888/VMMaker) and the generated sources in your src directory.

I regenerated everything from scratch using the final 3.7 image. Here's what I do:

run the latest X.Y-Z image click on 'update' save the image iff anything VM-related was updated 'clear out' the 'src' directory 'generate all' into the empty 'src' directory quit type 'make clean; make' to build a VM from scratch type 'make dist-src dist-image dist-bin' to archive and release the new VM sources and binary (for the local platform) along with the image that generated it

IOW, whatever is in the latest 3.7 image is definitive for building a 3.7 VM. This is not negotiable. (Other than fixing show-stoppers like the image segment thing, given the fix is so trivial, but then I would also file that fix into my 3.7-5898-full.image before distributing it in a tarball, as above.)

If the released 3.7 full image is generating broken Interpreter or plugins, then either the released image should be fixed (or changes posted to its update stream), or they should be in the 3.8 stream and the 3.8 VM declared the minimum version suitable for anyone encountering problems with 3.7.

Where is the Squeak source code available if someone wants to work on the VM?

3.7-5898-full.image on the FTP site of your choice (given that nothing at all happened when I pressed 'update' in the process described earlier).

I can't find it on SVN or in your tarball.

It's on my download page (3.7-5898 image and changes tarball, which contains the Interpreter sources used to generate the core VM corresponding to the released sources, always).

I'm not about to check images into the repostory. OTOH, my generated 'src' tree is now included in the unix area within the repository (platforms/unix/src), to make life easier for anyone building with those sources. (configure now understands to look in two places for 'src', and to use the one nearest the top of the hierarchy -- corresponding to sources generated outside of the 'platforms/unix' tree, which is where most people will be generating them.)

In my opinion, this is why the VMMaker sources (the Squeak code, possibly in MCZ format) should be versioned along with the C sources in SVN.

The VM sources are stamped with the image version to which they apply (see above re: configure). You can ignore this if you really know what you're doing, but you get to keep all the pieces afterwards.

Attached are the diffs I found.

Thanks -- but I don't think I can do much with them. If they aren't in the 3.7 full image (or updates) then they aren't relevant to building a 3.7 VM. When 3.8 becomes current later today (hopefully), the Interpreter therein will be generated from the most recent 3.8 image and its update stream.

Hope this helps to clear up the process for anyone who wasn't already familiar with it.

Ian

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?

Cheers, Ian

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

As I understand it, this is just the point Ned was trying to make and address. The more places you have to look for particular versions of stuff (SVN source with tag X.Y + SqF image version X.Y-full + SM or other source for VMM package version P.Q + updates through but not passing ABCD + changeset posted to vm-dev on 2005-03-18 by Anonymouse Squeaklander + etc...) to make a compatible whole, the harder it is for anyone and everyone to recreate a VM from scratch.

Just saying "get all the latest stuff" doesn't really work if you're trying to recreate a particular version of the VM.

The simplest useful and scalable thing I can imagine is to say: VM X.Y "final" can be recreated verbatim from scratch by using X.Y final platform sources + X.Y final image + any big fixes subsequently retrofitted to its Interpreter through the X.Y update stream.

Ian

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.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Oxymorons: Religious tolerance

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

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