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 http://bugs.squeak.org/view.php?id=7454

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 4.4.7.2357 from Squeakvm.org, we get the following error:

lightnin@386-lucid:~/Dropbox/MicroSqueak for Elliot$ squeak msqueak.image Exit to debugger at user request

2004272328 Object>handleExceptionName:context: 2004272236 Object>error: 2004272084 Object>primitiveFailed 2004271940 File>primOpen:writable: 2004271848 File>openReadWrite: 2004271308 >append:toFile: 2004271216 >log: 2004271124 >start 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.

Best, -Amos

On Thu, May 10, 2012 at 3:49 AM, Miriam Ruiz miriam@debian.org wrote:

2012/5/10 David T. Lewis lewis@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.

Hi!

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

Greetings, Miry