[Vm-dev] Re: Numbered primitives in images

Sun Jan 17 18:25:14 UTC 2010

Elliot's idea -- just fix the Scratch image to use the named socket  
prims -- sounds like a winner. It's simple, it doesn't add any  
complexity to the VM's, and it doesn't break anything. And it puts the  
burden on Scratch, where it belongs.

Assuming the named socket primitives do exactly the same things the  
numbered ones did (and it sounds like they do, since the numbered  
prims have been re-directed to the named ones for about a decade :-))  
then nothing should break, right?

Note that Scratch comes bundled with a copy of the Squeak VM, and the  
bundled VM in the current release still has support for the numbered  
socket primitives. So this VM change only matters for future releases  
of Scratch (and the Linux package, which is in active development).

Thanks for thinking about this issue.

	-- John

On Jan 17, 2010, at 7:07 AM, Bert Freudenberg wrote:
> On 17.01.2010, at 02:23, Eliot Miranda wrote:
>> On Sat, Jan 16, 2010 at 11:20 AM, David T. Lewis  
>> <lewis at mail.msen.com> wrote:
>>
>> The issue is now on Mantis:
>>
>>  http://bugs.squeak.org/view.php?id=7454
>>
>> Moving the closure primitives would be difficult at this point, as
>> we have a large installed base of closure-enabled images by now.
>>
>> In principle, it should be possible to update the primitiveTable at
>> run time based on imageFormatVersion, or perhaps as an option to be
>> supplied to the VM at startup time, or a combination of the two.
>>
>> Doing it automatically based on imageFormatVersion would probably
>> work, but has a catch-22 for someone adding closures to an older
>> image (e.g. adding the closure support to Etoys). For that situation
>> you want to be able to turn on closure support even though the image
>> does not yet need them, so perhaps e.g. a "-closures" command line
>> option turn on closure support in that case.
>>
>> Any other ideas?
>>
>> Would it be possible to write a script to replace the numbered  
>> primitives in the Scratch image with named prims and run that  
>> script on a suitable pre-closure VM?  Once the image is saved it  
>> should run on the closure-enabled VMs.
>>
>> Surely this is better than rewriting the primitive table.  I would  
>> think we would want to move away from obsolete interfaces and if  
>> Scratch supports named prims then it works, is compatible with  
>> other Squeaks and avoids hacks.
>
> The Scratch image is from around Squeak 2.5 - you might take a look  
> here:
> http://download.scratch.mit.edu/source-code/ScratchSource1.4.zip
>
> - Bert -
>
>>
>>
>> Dave
>>
>> On Sat, Jan 16, 2010 at 06:56:47PM +0100, Bert Freudenberg wrote:
>> >
>> > Fwd from John Maloney ...
>> >
>> > - Bert -
>> >
>> > Begin forwarded message:
>> > >
>> > > From: John Maloney <jmaloney at media.mit.edu>
>> > > Date: 16. Januar 2010 16:21:59 MEZ
>> > > To: Bert Freudenberg <bert at freudenbergs.de>
>> > > Cc: Ian Piumarta <ian at vpri.org>
>> > > Subject: Re: [Vm-dev] Re: [squeak-dev] Numbered primitives in  
>> images
>> > >
>> > > Hi, Bert.
>> > >
>> > > Thanks for the alert.
>> > >
>> > > Yep, this would be a problem for Scratch. It would prevent  
>> sharing projects on the website. Normally, I would not mind  
>> sticking with an older VM, but that there is also a change in the  
>> sound support on Linux from ALSA to Pulse Audio that we need, and  
>> work on that is still ongoing. So we may need to use a current VM,  
>> at least on Linux.
>> > >
>> > > Any chance there are some other numbered primitives that could  
>> be co-opted for the closure prims? As I recall there were lots of  
>> unused numbered primitives.
>> > >
>> > >     -- John
>> > >
>> > > On Jan 16, 2010, at 9:57 AM, Bert Freudenberg wrote:
>> > >> That may be a problem ...
>> > >>
>> > >> - Bert -
>> > >>
>> > >> Begin forwarded message:
>> > >>>
>> > >>> From: "David T. Lewis" <lewis at mail.msen.com>
>> > >>> Date: 16. Januar 2010 15:55:02 MEZ
>> > >>> To: "K. K. Subramaniam" <subbukk at gmail.com>
>> > >>> Cc: vm-dev at lists.squeakfoundation.org
>> > >>> Subject: [Vm-dev] Re: [squeak-dev] Numbered primitives in  
>> images
>> > >>> Reply-To: Squeak Virtual Machine Development Discussion <vm-dev at lists.squeakfoundation.org 
>> >
>> > >>>
>> > >>>
>> > >>> On Sat, Jan 16, 2010 at 08:16:06AM +0530, K. K. Subramaniam  
>> wrote:
>> > >>>> On Friday 15 January 2010 10:46:45 pm Bert Freudenberg wrote:
>> > >>>>> On 15.01.2010, at 16:58, K. K. Subramaniam wrote:
>> > >>>>>> Scratch 1.4 (Linux) of 30-Nov-2009 on 3.11-3 VM.
>> > >>>>>> Break into Scratch and do "Socket initializeNetwork".
>> > >>>>>
>> > >>>>> So it does not occur in normal operation?
>> > >>>> Only if you define "normal" as "offline" ;-). Any operation  
>> which uses networking
>> > >>>> (url block) goes through this method and it will fail when  
>> run under the
>> > >>>> 3.11.3 VM built from unix-3.11.3-vmm or svn trunk.
>> > >>>>
>> > >>>> BTW, Scratch image is just an example which has numbered  
>> primitives.
>> > >>>>
>> > >>>> The 3.10-4 VM has primitiveObsoleteIndexedPrimitive in slot  
>> 207 in
>> > >>>> platforms/unix/src/vm/interp.c while the 3.11.3 tar.gz and  
>> the trunk contain
>> > >>>> primitiveFail. The change crept in r1935 through vmm-dtl-126.
>> > >>>>
>> > >>>> Is this intentional or an oversight?
>> > >>>
>> > >>> Sorry I was not able to reply earlier. The change was  
>> intentional,
>> > >>> but the effect on Scratch was not.
>> > >>>
>> > >>> Some of the obsolete primitives had to be dropped when we  
>> added the
>> > >>> block closure support. This happened in February 2009  
>> (VMMaker-eem.114
>> > >>> in the SqS/VMMaker). Specifically, we changed from this,  
>> which redirects
>> > >>> the numbered primitives:
>> > >>>
>> > >>>           "Networking Primitives (200-225) - NO LONGER INDEXED"
>> > >>>           (200 225 primitiveObsoleteIndexedPrimitive)
>> > >>>
>> > >>> to this, which reallocates the numbers for closure support  
>> and for
>> > >>> future COG integration:
>> > >>>
>> > >>>           "new closure primitives (were Networking primitives)"
>> > >>>           (200 primitiveClosureCopyWithCopiedValues)
>> > >>>           (201 primitiveClosureValue) "value"
>> > >>>           (202 primitiveClosureValue) "value:"
>> > >>>           (203 primitiveClosureValue) "value:value:"
>> > >>>           (204 primitiveClosureValue) "value:value:value:"
>> > >>>           (205 primitiveClosureValue)  
>> "value:value:value:value:"
>> > >>>           (206 primitiveClosureValueWithArgs)  
>> "valueWithArguments:"
>> > >>>
>> > >>>           (207 209 primitiveFail) "reserved for Cog primitives"
>> > >>>
>> > >>> The obsolete primitive redirection had been in place for at  
>> least five
>> > >>> years, so backward compatibility had been preserved for some  
>> time.
>> > >>>
>> > >>> Question for Subbu: Is this an important issue may affect a  
>> large number
>> > >>> of Scratch users? In other words, are there kids trying to  
>> run Scratch,
>> > >>> and their Scratch image stops working properly after Squeak  
>> gets updated
>> > >>> to use a new VM?
>> > >>>
>> > >>> And a thought for the vm-dev list: I don't know if there  
>> might be a
>> > >>> technical solution to this, but it might be possible to use a  
>> strategy
>> > >>> in which the some of the old primitive lookups are preserved  
>> (at least
>> > >>> for the range 207 through 225) if and only if the image  
>> format is
>> > >>> pre-closures. Follow ups to this on vm-only.
>> > >>>
>> > >>> Dave
>> > >