[Vm-dev] Help/advice tracking down a squeak-vm regression
eliot.miranda at gmail.com
Fri May 11 17:43:37 UTC 2012
On Fri, May 11, 2012 at 6:46 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
> 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.
Alas I've used a few of these for Cog:
I think your change set is the way to go.
> 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]]
> a SortedCollection(
> 'ADPCMCodec privateDecodeMono:'
> 'ADPCMCodec privateDecodeStereo:'
> 'ADPCMCodec privateEncodeMono:'
> 'ADPCMCodec privateEncodeStereo:'
> 'Bitmap compress:toByteArray:'
> 'Bitmap decompress:fromByteArray:at:'
> 'FMSound mixSampleCount:into:startingAt:leftVol:rightVol:'
> 'FileDirectory class primPathNameDelimiter'
> 'FileDirectory primDeleteDirectory:'
> 'FileDirectory primDeleteFileNamed:'
> 'FileDirectory primLookupEntryIn:index:'
> 'FileDirectory primRename:to:'
> 'FileDirectory primSetMacFileNamed:type:creator:'
> 'LoopedSampledSound mixSampleCount:into:startingAt:leftVol:rightVol:'
> 'NetNameResolver class primNameResolverError'
> 'NetNameResolver class primNameResolverStatus'
> 'PluckedSound mixSampleCount:into:startingAt:leftVol:rightVol:'
> 'ReverbSound applyReverbTo:startingAt:count:'
> 'SampledSound class convert8bitSignedFrom:to16Bit:'
> 'SampledSound mixSampleCount:into:startingAt:leftVol:rightVol:'
> 'SerialPort primClosePort:'
> 'SerialPort primReadPort:into:startingAt:count:'
> 'SerialPort primWritePort:from:startingAt:count:'
> 'SimpleMIDIPort class primPortCount'
> 'SimpleMIDIPort class primPortDirectionalityOf:'
> 'SimpleMIDIPort class primPortNameOf:'
> 'SimpleMIDIPort primMIDIClosePort:'
> 'SimpleMIDIPort primMIDIOpenPort:readSemaIndex:interfaceClockRate:'
> 'SimpleMIDIPort primMIDIReadPort:into:'
> 'SimpleMIDIPort primMIDIWritePort:from:at:'
> 'Socket primAcceptFrom:receiveBufferSize:sendBufSize:semaIndex:'
> 'Socket primSocket:connectTo:port:'
> 'Socket primSocket:listenOn:'
> 'Socket primSocket:listenOn:backlogSize:'
> 'Socket primSocket:sendData:startIndex:count:'
> 'Socket primSocket:setPort:'
> 'Socket primSocketAbortConnection:'
> 'Socket primSocketCloseConnection:'
> 'Socket primSocketLocalAddress:'
> 'Socket primSocketLocalPort:'
> 'Socket primSocketRemoteAddress:'
> 'Socket primSocketRemotePort:'
> 'Socket primSocketSendDone:'
> 'SoundPlayer class primSoundAvailableBytes'
> 'SoundPlayer class primSoundPlaySamples:from:startingAt:'
> 'SoundPlayer class primSoundStartBufferSize:rate:stereo:'
> 'SoundPlayer class primSoundStartBufferSize:rate:stereo:semaIndex:'
> 'SoundPlayer class primSoundStop'
> 'SoundRecorder primGetActualRecordingSampleRate'
> 'SoundRecorder primRecordSamplesInto:startingAt:'
> 'SoundRecorder primSetRecordLevel:'
> 'SoundRecorder primStartRecordingDesiredSampleRate:stereo:semaIndex:'
> 'SoundRecorder primStopRecording'
> 'StandardFileStream primAtEnd:'
> 'StandardFileStream primClose:'
> 'StandardFileStream primCloseNoError:'
> 'StandardFileStream primGetPosition:'
> 'StandardFileStream primOpen:writable:'
> 'StandardFileStream primRead:into:startingAt:count:'
> 'StandardFileStream primSetPosition:to:'
> 'StandardFileStream primSize:'
> 'StandardFileStream primSizeNoError:'
> 'StandardFileStream primWrite:from:startingAt:count:'
> 'String class findFirstInString:inSet:startingAt:'
> 'String class indexOfAscii:inString:startingAt:'
> 'String class translate:from:to:table:'
> 'String compare:with:collated:'
> 'String findSubstring:in:startingAt:matchTable:'
> 'WarpBlt warpBitsSmoothing:sourceMap:')
> - 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 archive is at
> > and you can join the list at
> > that you may want to read, as you probably are not CCed on all of the
> > 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
> > problems in VMs and the Scratch image. The discussion now on vm-dev is
> > 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,
> > Dave
> > 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.
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev