[Vm-dev] Help/advice tracking down a squeak-vm regression
bert at freudenbergs.de
Fri May 11 13:46:54 UTC 2012
I just checked. Most, if not all of the problems, come from Scratch's use of numbered primitives. They were deprecated in favor of named primitives.
IMHO it would be reasonably simple to re-instate these primitives in the VM. Right now they are simply mapped to primitiveFail. This would get us back the ability to run many old images, unmodified.
The fix for Scratch would be to change all the deprecated primitive calls in the image to the new ones. This is straightforward, though a bit tedious.
Do we have a list of old primitive numbers and their corresponding new named equivalents?
I came up with the following, executed in the Scratch image. Does it look reasonable? Executing the same in Etoys comes up empty, so I would assume these are the methods that need patching:
Smalltalk allSelect: [:m | #((146 147) (150 159) (161 164) (169 185) (190 194) (207 209) (213 220) (223 229) (234 246) (520 569)) anySatisfy: [:i | m primitive between: i first and: i second]]
'FileDirectory class primPathNameDelimiter'
'NetNameResolver class primNameResolverError'
'NetNameResolver class primNameResolverStatus'
'SampledSound class convert8bitSignedFrom:to16Bit:'
'SimpleMIDIPort class primPortCount'
'SimpleMIDIPort class primPortDirectionalityOf:'
'SimpleMIDIPort class primPortNameOf:'
'SoundPlayer class primSoundAvailableBytes'
'SoundPlayer class primSoundPlaySamples:from:startingAt:'
'SoundPlayer class primSoundStartBufferSize:rate:stereo:'
'SoundPlayer class primSoundStartBufferSize:rate:stereo:semaIndex:'
'SoundPlayer class primSoundStop'
'String class findFirstInString:inSet:startingAt:'
'String class indexOfAscii:inString:startingAt:'
'String class translate:from:to:table:'
- Bert -
On 11.05.2012, at 02:06, David T. Lewis wrote:
> Hi Miriam,
> I think that your message did not reach the vm-dev mailing list, so I am
> CCing the list here. There has been some additional discussion on the list
> (list archive is at http://lists.squeakfoundation.org/pipermail/vm-dev/2012-May/date.html#start
> and you can join the list at http://lists.squeakfoundation.org/mailman/listinfo/vm-dev)
> that you may want to read, as you probably are not CCed on all of the postings.
> I am glad that you are working on the packaging for Debian, and for sure
> the VM developers and Scratch developers need to be responsible for solving
> problems in VMs and the Scratch image. The discussion now on vm-dev is about
> how we can either update the VM or the Scratch image so that two versions
> of the VM may not be needed.
> Thanks for the work you are doing,
> On Thu, May 10, 2012 at 09:49:57AM +0200, Miriam Ruiz 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
More information about the Vm-dev