[Vm-dev] Help/advice tracking down a squeak-vm regression

[Bert Freudenberg]

On 08.05.2012, at 14:21, David T. Lewis wrote:

> 
> On Tue, May 08, 2012 at 10:44:26AM +0100, Alex Bradbury wrote:
>> 
>> David and Igor: thanks for your responses. Comments below.
>> 
>> On 7 May 2012 00:28, David T. Lewis <lewis at mail.msen.com> wrote:
>>> If I remember correctly, Scratch derives from a Squeak 3.6 image and uses
>>> a VM of similar vintage. Since the days of Squeak 3.6, there have been
>>> a number of fundamental changes in the Squeak VM. I recall some discussion
>>> of this perhaps a couple of years ago, and I think that the prevailing
>>> view was that it made more sense to bring the Scratch image up to date
>>> with respect to the VM changes, as opposed to trying to make a single
>>> VM that could be backward compatible all the way to Squeak 3.6.
>> 
>> Though the current squeak image did work flawlessly in squeak-vm 4.0?
>> So the upstream view is that this is not officially supported and the
>> correct solution if it no longer works on 4.4 is to just use an older
>> vm?
>> 
>>> From a license point of view, is there any reason that the Scratch VM
>>> and source code could not be distributed on Debian? If this is acceptable,
>>> then I expect that the fastest way to achieve a working distribution would
>>> involve arranging for Scratch to run using a VM at e.g. /usr/bin/scratch,
>>> and Squeak to run with /usr/bin/squeak or /usr/bin/cog.
>> 
>> It does seem that the Ubuntu packages bundles its own
>> scratch_squeak_vm. Either that, or supporting the installation of
>> squeak-vm 4.0 alongside 4.4 might be good options. For my purposes
>> with the Raspberry Pi, I'm probably just going to install and pin the
>> squeeze squeak-vm (4.0) until a better solution comes along.
>> 
>> Alex
> 
> On 8 May 2012 10:44, Alex Bradbury <asb at asbradbury.org> wrote:
>>> Though the current squeak image did work flawlessly in squeak-vm 4.0?
>>> So the upstream view is that this is not officially supported and the
>>> correct solution if it no longer works on 4.4 is to just use an older
>>> vm?
>> 
>> squeak image -> scratch image
>> 
>> Alex
> 
> As far as I know, Scratch images have not worked on standard Squeak VMs
> for a number of years, and Scratch has always relied on shipping its
> own VM. In addition to fundamental changes in the VM itself that have
> taken place in recent years, I believe that the Scratch version of the
> VM also includes a couple of plugins (add-in functionality) that are
> required for Scratch but not included in Squeak.
> 
> I think I see one source of confusion here. I just read the link at
> http://info.scratch.mit.edu/Source_Code and find the following statement:
> 
> "Since Scratch simply uses a stock Squeak virtual machine, we are
>  not distributing the Squeak virtual machine source code. Both the
>  source code and pre-compiled binaries for the Squeak virtual machine
>  are available at www.squeakvm.org."
> 
> Unfortunately, I don't think that this is true, and hopefully someone
> can make a correction to that web page.
> 
> The squeakvm.org code repository along with VMMaker at source.squeak.org
> does contain fully versioned copies of the Squeak VM, presumably including
> all or most of the code in the current Scratch VM (except for the Scratch
> specific plugins). So it would probably be possible to build a working
> Scratch VM using code from the standard Squeak VM repositories. But
> I fear this would take some work on the part of someone who knows
> Scratch well enough to find and build the right versions and put the
> pieces together.
> 
> Dave

Well, actually, Scratch (based on Squeak 2.8 IIRC) worked fine up to the 3.10 VM. E.g. OLPC's Scratch package does not bundle a VM but uses the stock Fedora Squeak VM (3.10).

For a very long time we managed to keep VMs being able to run all Squeak images back to 1.x. The promise was new VM + old image = fine, but new images may require new VMs. Upgrading the VM should not unnecessarily break old images.

So what did we change in 4.x VMs that it does not work anymore? 

If these changes are really unavoidable and incompatible, then we should indeed advise distros to package both 3.x and 4.x VMs.

- Bert -