[Vm-dev] Re: Numbered primitives in images

Sun Jan 17 01:23:04 UTC 2010

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.

>
> 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
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100116/4cfecaec/attachment.htm