[Vm-dev] Help/advice tracking down a squeak-vm regression
amos at scratch.mit.edu
Thu May 10 18:22:29 UTC 2012
> Amos, can you please clarify if further development of the Scratch
> image is planned?
No further development is planned by us.
However, John and I spent a little time looking into this today to see
about an easy fix. I'll pass on my impressions, and let him correct / make
additional suggestions as necessary.
There seem to be (at least) two issues preventing the current version of
Scratch from working with later VMs.
1. The sound primitive changes David mentioned above (thanks for tracking
this down, David!)
Mantis 0007454: Removal of obsolete prim support for closures is a problem
for Scratch images
John felt he could manage fixing this, but not soon. It's probably a couple
hours of work.
2. However, even using an extremely simple image that just writes to a
file, we get errors with later versions of the VM.
Using this image: http://dl.dropbox.com/u/1979035/msqueak.image
on 32 bit Lucid, running Squeak 184.108.40.2067 from Squeakvm.org,
we get the following error:
lightnin at 386-lucid:~/Dropbox/MicroSqueak for Elliot$ squeak msqueak.image
Exit to debugger at user request
2004260548  in ProcessorScheduler>installStartProcess
So there's seems to be an issue with file io that could be causing
problems. It's difficult to know how hard this would be to fix in the
Scratch image, and if there are other issues that would need to be
addressed. If there is a squeak dev with time and interest who could look
around and share their impressions, that would really help get a better
grip on the scale of the problem(s).
So it seems like there are a few ways forward:
1. Make a Scratch compatible VM, as David has suggested.
2. Ask heroic, generous, kind Squeak developers to help change the
Scratch.image to make it compatible with later VMs. They can then
re-release it under the GPL, or give it to us to release as an update to
the source package.
One problem with 1.) is that we won't be able to benefit from further
development of a true 64 bit VM. (Still a possibility in the future I
hope?) If we fork an earlier VM just for Scratch, we can have a working,
easily installable 32 bit package, but all 64 bit users will need to go to
the command line to force the installation of the 32 bit package on their
64 machines. This seems like a significant hurdle for many end users -
especially the kind who would be interested in Scratch. Ideally, we want
them to be able to install Scratch from their normal package manager on
whatever distro they use. But perhaps 1.) is still the best / only
solution, if 2.) isn't feasible.
On Thu, May 10, 2012 at 3:49 AM, Miriam Ruiz <miriam at debian.org> wrote:
> 2012/5/10 David T. Lewis <lewis at mail.msen.com>:
> > Amos, can you please clarify if further development of the Scratch
> > image is planned? If yes, then updating the Scratch image may be
> > the right thing to do. If no, then we can take a harder look at
> > coming up with a way to produce a backward compatible VM. If neither
> > of these is feasible, then it will probably be necessary to arrange
> > a separate source distribution for a Scratch VM.
> Sorry for the delay in answering to this thread. I think that it is a
> very sensible suggestion you're making. There is one thing I'm
> concerned about, though: if it is finally necessary to include an
> aditional older version of the VM in Debian to be able to run Scratch,
> as other people have suggested earliuer,¿who will maintain this VM?
> I mean, I can manage the packaging and some shallow patches if it is
> necessary, as I do with all my packages, but as I'm not especially
> proficient with the VM's code not I ever worked with it at a serious
> level, so there's limits in what I can do. I suppose that Squeak
> developers won't like to have to maintain two versions of the VM, and
> the will probably just keep supporting, evolving and solving bugs from
> the latest. I don't know if Scratch developers are willing or have
> resources to solve big problems in the VM in case they appear, so that
> leaves me probably close to being alone in fixing stuff in the VM if
> something serious appear. I must confess that this perspective kind of
> scares me.
> To sum up, if we finally have to keep a separate version of the VM for
> running Scratch (and BYOB and other derivatives), we have to also find
> out how to handle bugs and improvements in the VM in case that they're
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev