<br><br><div class="gmail_quote">On Fri, May 11, 2012 at 6:46 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br></blockquote><div>
<br></div><div>Alas I've used a few of these for Cog:</div><div><br></div><div> #(#(161 #primitiveSetIdentityHash)</div><div> #(169 #primitiveNotIdentical)</div><div> #(175 #primitiveBehaviorHash)</div><div> #(176 #primitiveMaxIdentityHash)</div>
<div> #(185 #primitiveExitCriticalSection)</div><div> #(213 #primitiveContextXray)</div><div> #(214 #primitiveVoidVMState)</div><div> #(215 #primitiveVoidVMStateForMethod)</div><div> #(218 #primitiveDoNamedPrimitiveWithArgs)</div>
<div> #(240 #primitiveUTCMicrosecondClock)</div><div> #(241 #primitiveLocalMicrosecondClock)</div><div> #(242 #primitiveSignalAtUTCMicroseconds)</div><div> #(243 #primitiveUpdateTimezone))</div><div> </div><div>
I think your change set is the way to go.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
Do we have a list of old primitive numbers and their corresponding new named equivalents?<br>
<br>
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:<br>
<br>
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]]<br>
<br>
a SortedCollection(<br>
'ADPCMCodec privateDecodeMono:'<br>
'ADPCMCodec privateDecodeStereo:'<br>
'ADPCMCodec privateEncodeMono:'<br>
'ADPCMCodec privateEncodeStereo:'<br>
'Bitmap compress:toByteArray:'<br>
'Bitmap decompress:fromByteArray:at:'<br>
'FMSound mixSampleCount:into:startingAt:leftVol:rightVol:'<br>
'FileDirectory class primPathNameDelimiter'<br>
'FileDirectory primDeleteDirectory:'<br>
'FileDirectory primDeleteFileNamed:'<br>
'FileDirectory primLookupEntryIn:index:'<br>
'FileDirectory primRename:to:'<br>
'FileDirectory primSetMacFileNamed:type:creator:'<br>
'LoopedSampledSound mixSampleCount:into:startingAt:leftVol:rightVol:'<br>
'NetNameResolver class primNameResolverError'<br>
'NetNameResolver class primNameResolverStatus'<br>
'PluckedSound mixSampleCount:into:startingAt:leftVol:rightVol:'<br>
'ReverbSound applyReverbTo:startingAt:count:'<br>
'SampledSound class convert8bitSignedFrom:to16Bit:'<br>
'SampledSound mixSampleCount:into:startingAt:leftVol:rightVol:'<br>
'SerialPort primClosePort:'<br>
'SerialPort primOpenPort:baudRate:stopBitsType:parityType:dataBits:inFlowControlType:outFlowControlType:xOnByte:xOffByte:'<br>
'SerialPort primReadPort:into:startingAt:count:'<br>
'SerialPort primWritePort:from:startingAt:count:'<br>
'SimpleMIDIPort class primPortCount'<br>
'SimpleMIDIPort class primPortDirectionalityOf:'<br>
'SimpleMIDIPort class primPortNameOf:'<br>
'SimpleMIDIPort primMIDIClosePort:'<br>
'SimpleMIDIPort primMIDIOpenPort:readSemaIndex:interfaceClockRate:'<br>
'SimpleMIDIPort primMIDIReadPort:into:'<br>
'SimpleMIDIPort primMIDIWritePort:from:at:'<br>
'Socket primAcceptFrom:receiveBufferSize:sendBufSize:semaIndex:'<br>
'Socket primSocket:connectTo:port:'<br>
'Socket primSocket:listenOn:'<br>
'Socket primSocket:listenOn:backlogSize:'<br>
'Socket primSocket:sendData:startIndex:count:'<br>
'Socket primSocket:setPort:'<br>
'Socket primSocketAbortConnection:'<br>
'Socket primSocketCloseConnection:'<br>
'Socket primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:'<br>
'Socket primSocketLocalAddress:'<br>
'Socket primSocketLocalPort:'<br>
'Socket primSocketRemoteAddress:'<br>
'Socket primSocketRemotePort:'<br>
'Socket primSocketSendDone:'<br>
'SoundPlayer class primSoundAvailableBytes'<br>
'SoundPlayer class primSoundPlaySamples:from:startingAt:'<br>
'SoundPlayer class primSoundStartBufferSize:rate:stereo:'<br>
'SoundPlayer class primSoundStartBufferSize:rate:stereo:semaIndex:'<br>
'SoundPlayer class primSoundStop'<br>
'SoundRecorder primGetActualRecordingSampleRate'<br>
'SoundRecorder primRecordSamplesInto:startingAt:'<br>
'SoundRecorder primSetRecordLevel:'<br>
'SoundRecorder primStartRecordingDesiredSampleRate:stereo:semaIndex:'<br>
'SoundRecorder primStopRecording'<br>
'StandardFileStream primAtEnd:'<br>
'StandardFileStream primClose:'<br>
'StandardFileStream primCloseNoError:'<br>
'StandardFileStream primGetPosition:'<br>
'StandardFileStream primOpen:writable:'<br>
'StandardFileStream primRead:into:startingAt:count:'<br>
'StandardFileStream primSetPosition:to:'<br>
'StandardFileStream primSize:'<br>
'StandardFileStream primSizeNoError:'<br>
'StandardFileStream primWrite:from:startingAt:count:'<br>
'String class findFirstInString:inSet:startingAt:'<br>
'String class indexOfAscii:inString:startingAt:'<br>
'String class translate:from:to:table:'<br>
'String compare:with:collated:'<br>
'String findSubstring:in:startingAt:matchTable:'<br>
'WarpBlt warpBitsSmoothing:sourceMap:')<br>
<span class="HOEnZb"><font color="#888888"><br>
- Bert -<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 11.05.2012, at 02:06, David T. Lewis wrote:<br>
<br>
><br>
> Hi Miriam,<br>
><br>
> I think that your message did not reach the vm-dev mailing list, so I am<br>
> CCing the list here. There has been some additional discussion on the list<br>
> (list archive is at <a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2012-May/date.html#start" target="_blank">http://lists.squeakfoundation.org/pipermail/vm-dev/2012-May/date.html#start</a><br>
> and you can join the list at <a href="http://lists.squeakfoundation.org/mailman/listinfo/vm-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/vm-dev</a>)<br>
> that you may want to read, as you probably are not CCed on all of the postings.<br>
><br>
> I am glad that you are working on the packaging for Debian, and for sure<br>
> the VM developers and Scratch developers need to be responsible for solving<br>
> problems in VMs and the Scratch image. The discussion now on vm-dev is about<br>
> how we can either update the VM or the Scratch image so that two versions<br>
> of the VM may not be needed.<br>
><br>
> Thanks for the work you are doing,<br>
> Dave<br>
><br>
> On Thu, May 10, 2012 at 09:49:57AM +0200, Miriam Ruiz wrote:<br>
>> 2012/5/10 David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>>:<br>
>><br>
>>> Amos, can you please clarify if further development of the Scratch<br>
>>> image is planned? If yes, then updating the Scratch image may be<br>
>>> the right thing to do. If no, then we can take a harder look at<br>
>>> coming up with a way to produce a backward compatible VM. If neither<br>
>>> of these is feasible, then it will probably be necessary to arrange<br>
>>> a separate source distribution for a Scratch VM.<br>
>><br>
>> Hi!<br>
>><br>
>> Sorry for the delay in answering to this thread. I think that it is a<br>
>> very sensible suggestion you're making. There is one thing I'm<br>
>> concerned about, though: if it is finally necessary to include an<br>
>> aditional older version of the VM in Debian to be able to run Scratch,<br>
>> as other people have suggested earliuer,?who will maintain this VM?<br>
>><br>
>> I mean, I can manage the packaging and some shallow patches if it is<br>
>> necessary, as I do with all my packages, but as I'm not especially<br>
>> proficient with the VM's code not I ever worked with it at a serious<br>
>> level, so there's limits in what I can do. I suppose that Squeak<br>
>> developers won't like to have to maintain two versions of the VM, and<br>
>> the will probably just keep supporting, evolving and solving bugs from<br>
>> the latest. I don't know if Scratch developers are willing or have<br>
>> resources to solve big problems in the VM in case they appear, so that<br>
>> leaves me probably close to being alone in fixing stuff in the VM if<br>
>> something serious appear. I must confess that this perspective kind of<br>
>> scares me.<br>
>><br>
>> To sum up, if we finally have to keep a separate version of the VM for<br>
>> running Scratch (and BYOB and other derivatives), we have to also find<br>
>> out how to handle bugs and improvements in the VM in case that they're<br>
>> needed.<br>
>><br>
>> Greetings,<br>
>> Miry<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>