<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 17.01.2010, at 02:23, Eliot Miranda wrote:</div><blockquote type="cite"><div class="gmail_quote">On Sat, Jan 16, 2010 at 11:20 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The issue is now on Mantis:<br>
<br>
<a href="http://bugs.squeak.org/view.php?id=7454" target="_blank">http://bugs.squeak.org/view.php?id=7454</a><br>
<br>
Moving the closure primitives would be difficult at this point, as<br>
we have a large installed base of closure-enabled images by now.<br>
<br>
In principle, it should be possible to update the primitiveTable at<br>
run time based on imageFormatVersion, or perhaps as an option to be<br>
supplied to the VM at startup time, or a combination of the two.<br>
<br>
Doing it automatically based on imageFormatVersion would probably<br>
work, but has a catch-22 for someone adding closures to an older<br>
image (e.g. adding the closure support to Etoys). For that situation<br>
you want to be able to turn on closure support even though the image<br>
does not yet need them, so perhaps e.g. a "-closures" command line<br>
option turn on closure support in that case.<br>
<br>
Any other ideas?<br></blockquote><div class="gmail_quote"><br></div>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.<div>
<br></div><div>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.</div></div></blockquote><div><br></div><div>The Scratch image is from around Squeak 2.5 - you might take a look here:</div><div><a href="http://download.scratch.mit.edu/source-code/ScratchSource1.4.zip">http://download.scratch.mit.edu/source-code/ScratchSource1.4.zip</a></div><div><br></div><div>- Bert -</div><br><blockquote type="cite"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Dave<br>
<div><div></div><div class="h5"><br>
On Sat, Jan 16, 2010 at 06:56:47PM +0100, Bert Freudenberg wrote:<br>
><br>
> Fwd from John Maloney ...<br>
><br>
> - Bert -<br>
><br>
> Begin forwarded message:<br>
> ><br>
> > From: John Maloney <<a href="mailto:jmaloney@media.mit.edu">jmaloney@media.mit.edu</a>><br>
> > Date: 16. Januar 2010 16:21:59 MEZ<br>
> > To: Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>><br>
> > Cc: Ian Piumarta <<a href="mailto:ian@vpri.org">ian@vpri.org</a>><br>
> > Subject: Re: [Vm-dev] Re: [squeak-dev] Numbered primitives in images<br>
> ><br>
> > Hi, Bert.<br>
> ><br>
> > Thanks for the alert.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > -- John<br>
> ><br>
> > On Jan 16, 2010, at 9:57 AM, Bert Freudenberg wrote:<br>
> >> That may be a problem ...<br>
> >><br>
> >> - Bert -<br>
> >><br>
> >> Begin forwarded message:<br>
> >>><br>
> >>> From: "David T. Lewis" <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>><br>
> >>> Date: 16. Januar 2010 15:55:02 MEZ<br>
> >>> To: "K. K. Subramaniam" <<a href="mailto:subbukk@gmail.com">subbukk@gmail.com</a>><br>
> >>> Cc: <a href="mailto:vm-dev@lists.squeakfoundation.org">vm-dev@lists.squeakfoundation.org</a><br>
> >>> Subject: [Vm-dev] Re: [squeak-dev] Numbered primitives in images<br>
> >>> Reply-To: Squeak Virtual Machine Development Discussion <<a href="mailto:vm-dev@lists.squeakfoundation.org">vm-dev@lists.squeakfoundation.org</a>><br>
> >>><br>
> >>><br>
> >>> On Sat, Jan 16, 2010 at 08:16:06AM +0530, K. K. Subramaniam wrote:<br>
> >>>> On Friday 15 January 2010 10:46:45 pm Bert Freudenberg wrote:<br>
> >>>>> On 15.01.2010, at 16:58, K. K. Subramaniam wrote:<br>
> >>>>>> Scratch 1.4 (Linux) of 30-Nov-2009 on 3.11-3 VM.<br>
> >>>>>> Break into Scratch and do "Socket initializeNetwork".<br>
> >>>>><br>
> >>>>> So it does not occur in normal operation?<br>
> >>>> Only if you define "normal" as "offline" ;-). Any operation which uses networking<br>
> >>>> (url block) goes through this method and it will fail when run under the<br>
> >>>> 3.11.3 VM built from unix-3.11.3-vmm or svn trunk.<br>
> >>>><br>
> >>>> BTW, Scratch image is just an example which has numbered primitives.<br>
> >>>><br>
> >>>> The 3.10-4 VM has primitiveObsoleteIndexedPrimitive in slot 207 in<br>
> >>>> platforms/unix/src/vm/interp.c while the 3.11.3 tar.gz and the trunk contain<br>
> >>>> primitiveFail. The change crept in r1935 through vmm-dtl-126.<br>
> >>>><br>
> >>>> Is this intentional or an oversight?<br>
> >>><br>
> >>> Sorry I was not able to reply earlier. The change was intentional,<br>
> >>> but the effect on Scratch was not.<br>
> >>><br>
> >>> Some of the obsolete primitives had to be dropped when we added the<br>
> >>> block closure support. This happened in February 2009 (VMMaker-eem.114<br>
> >>> in the SqS/VMMaker). Specifically, we changed from this, which redirects<br>
> >>> the numbered primitives:<br>
> >>><br>
> >>> "Networking Primitives (200-225) - NO LONGER INDEXED"<br>
> >>> (200 225 primitiveObsoleteIndexedPrimitive)<br>
> >>><br>
> >>> to this, which reallocates the numbers for closure support and for<br>
> >>> future COG integration:<br>
> >>><br>
> >>> "new closure primitives (were Networking primitives)"<br>
> >>> (200 primitiveClosureCopyWithCopiedValues)<br>
> >>> (201 primitiveClosureValue) "value"<br>
> >>> (202 primitiveClosureValue) "value:"<br>
> >>> (203 primitiveClosureValue) "value:value:"<br>
> >>> (204 primitiveClosureValue) "value:value:value:"<br>
> >>> (205 primitiveClosureValue) "value:value:value:value:"<br>
> >>> (206 primitiveClosureValueWithArgs) "valueWithArguments:"<br>
> >>><br>
> >>> (207 209 primitiveFail) "reserved for Cog primitives"<br>
> >>><br>
> >>> The obsolete primitive redirection had been in place for at least five<br>
> >>> years, so backward compatibility had been preserved for some time.<br>
> >>><br>
> >>> Question for Subbu: Is this an important issue may affect a large number<br>
> >>> of Scratch users? In other words, are there kids trying to run Scratch,<br>
> >>> and their Scratch image stops working properly after Squeak gets updated<br>
> >>> to use a new VM?<br>
> >>><br>
> >>> And a thought for the vm-dev list: I don't know if there might be a<br>
> >>> technical solution to this, but it might be possible to use a strategy<br>
> >>> in which the some of the old primitive lookups are preserved (at least<br>
> >>> for the range 207 through 225) if and only if the image format is<br>
> >>> pre-closures. Follow ups to this on vm-only.<br>
> >>><br>
> >>> Dave<br>
> ><br>
><br>
</div></div></blockquote></div><br>
</blockquote></div><div><br></div><div><br class="Apple-interchange-newline">
</div>
<br></body></html>