[squeak-dev] The Inbox: Files-dtl.166.mcz

David T. Lewis lewis at mail.msen.com
Mon Sep 5 03:38:35 UTC 2016

On Mon, Sep 05, 2016 at 02:33:43AM +0200, Eliot Miranda wrote:
> Hi Both,
>     the adoptInstance: code fails on V3 because of compact classes.  One cannot change a 1-word header instance if a compact class into a 1-word header of a non-compact class; there is no room in a 1-word header for the 32-bit non/compact class reference.

Hi Eliot,

Right. You have documented this clearly in VMMaker. It is a reasonable and
expected limitation.

> David, fur give me for broaching what may be an emotionally painful topic.  I have no desire to cause you pain, but IMO this is important.
> We should /NOT/ hamstring code for either Spur or V3 with needless and expensive compatibility.  David, you're going to have to accept that the two will diverge.  Instead, try and think of a mechanism that supports tracking the differences instead of trying to keep the code bases the same. IMO effort put into keeping the two the same is effort wasted.

My initial attempt to do this is http://www.squeaksource.com/TrunkUpdateStreamV3.
For example, to see differences in the Collections package, use Monticello from
trunk Squeak to look at differences in the Collections.V3 package in the
TrunkUpdateStreamV3 repository. The other differences are in Compiler.V3,
Kernel.V3, and System.V3 (along with the trivial difference in Files.V3 that
was the subject of this thread).

My question concerning the Files package arises directly from this. Aside
from a single optimization in Files, all other significant differences
have been contained within the Compiler, Collections, System, and Kernel

> Instead one could put effort into a Spur interpreter VM, 

I do not want to volunteer to start a new VM project until I finish the
last one that I committed to do. I have said this before. And it's really
just not someething that I can take on right now.

> , or tools for automatic patching of Monticello packages with Spur<->V3 differences.

I do not yet have any real insight as to how to automate the patching of Monticello
packages with Spur<->V3 differences. So far I have done it manually with some success,
and I have been able to maintain a functioning update.V3 config map for the V3 trunk
update stream (the update.V3 maps in http://www.squeaksource.com/TrunkUpdateStreamV3).
This has been updated through the 5.1 release cycle, and I may keep it going for a
while longer.

But the automated update stream test (http://build.squeak.org/job/FollowTrunkOnOldV3Image)
fails due to various issues in the trunk stream itself (discussed elsewhere), and my
experience is that the changes in System/Kernel/Collections/Compiler require close
inspection by a human agent. I don't know how to automate this.

I can't help but think this is a topic that might usefully be addressed
with Environments. That is pure hand waving on my part, but it seems like
it might be a natural fit, and potentially better in the long term than
any Monticello patching strategies that we may be able to invent.

I am also intrigued by Juan Vuletich's idea of maintaining a single image
code base for both V3 and Spur, so if Juan can do it it must be possible :-)


> Bert and Yom and others just put significant effort into etoys on Squeak 5.1 (which is Spur).  Bert wrote a V3 format ImageSegment loader entirely in Smalltalk, allowing Spur to load old etoys projects saved on V3.  This is effort well spent.  It rescues old code  and allows it to live again and solves an important compatibility problem (and indeed a Spur format loader could be written to allow V3 to load ImageSegments saved on Spur).

I agree completely.

> In a community with extremely limited resources it is incumbent upon those of us who can to find constructive directions for our efforts if we, as a community, are to make progress.
> Eliot
> _,,,^..^,,,_ (phone)

I have heard this before. It would be "too much work" to keep squeaksource.com
alive, so instead we direct all available resources to migrate everything
to smalltalkhub. It would be "too hard" to keep MVC working, so we should
just abandon it while we work on something else instead. Sorry, but I just
don't buy it.

For various reasons, I cannot put much effort into new projects right now.
But I do want to try to keep existing efforts moving forward, and I hope
this will not be seen as unconstructive.


More information about the Squeak-dev mailing list