Re: [squeak-dev] Numbered primitives in images

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Numbered primitives in images

David T. Lewis
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] Numbered primitives in images

Randal L. Schwartz
 
>>>>> "David" == David T Lewis <[hidden email]> writes:

David> Question for Subbu: Is this an important issue may affect a large number
David> of Scratch users? In other words, are there kids trying to run Scratch,
David> and their Scratch image stops working properly after Squeak gets updated
David> to use a new VM?

As I recall, one of the interesting things about Scratch is that while
it was only "officially" supported on OSX and Windows, the user community
had figured out that it was just Squeak, and could be run with a Squeak
VM on other platforms, particularly Linux.

David> And a thought for the vm-dev list: I don't know if there might be a
David> technical solution to this, but it might be possible to use a strategy
David> in which the some of the old primitive lookups are preserved (at least
David> for the range 207 through 225) if and only if the image format is
David> pre-closures. Follow ups to this on vm-only.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] Numbered primitives in images

johnmci

Well I did build the official macintosh VM for Scratch, it uses fewer plugins, and
has some special handling for "Quit"  

Personally I think if they are running scratch without the MIT supplied VM
they need to use a VM created before such and such a date.

On 2010-01-16, at 8:33 AM, Randal L. Schwartz wrote:

>
>>>>>> "David" == David T Lewis <[hidden email]> writes:
>
> David> Question for Subbu: Is this an important issue may affect a large number
> David> of Scratch users? In other words, are there kids trying to run Scratch,
> David> and their Scratch image stops working properly after Squeak gets updated
> David> to use a new VM?
>
> As I recall, one of the interesting things about Scratch is that while
> it was only "officially" supported on OSX and Windows, the user community
> had figured out that it was just Squeak, and could be run with a Squeak
> VM on other platforms, particularly Linux.
>
> David> And a thought for the vm-dev list: I don't know if there might be a
> David> technical solution to this, but it might be possible to use a strategy
> David> in which the some of the old primitive lookups are preserved (at least
> David> for the range 207 through 225) if and only if the image format is
> David> pre-closures. Follow ups to this on vm-only.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] Numbered primitives in images

Bert Freudenberg
In reply to this post by Randal L. Schwartz

On 16.01.2010, at 17:33, Randal L. Schwartz wrote:

>
>
>>>>>> "David" == David T Lewis <[hidden email]> writes:
>
> David> Question for Subbu: Is this an important issue may affect a large number
> David> of Scratch users? In other words, are there kids trying to run Scratch,
> David> and their Scratch image stops working properly after Squeak gets updated
> David> to use a new VM?
>
> As I recall, one of the interesting things about Scratch is that while
> it was only "officially" supported on OSX and Windows, the user community
> had figured out that it was just Squeak, and could be run with a Squeak
> VM on other platforms, particularly Linux.

The new 1.4 release is officially supported:

http://info.scratch.mit.edu/Linux_installer

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Numbered primitives in images

K. K. Subramaniam
In reply to this post by David T. Lewis
 
On Saturday 16 January 2010 08:25:02 pm David T. Lewis wrote:
>Sorry I was not able to reply earlier. The change was intentional,
>but the effect on Scratch was not.
Thanks David, for the explanation. Scratch is just a canary in the coal mine.
Conventional wisdom lead me to believe that 3.10 to 3.11 would be a normal
upgrade path with bugs fixed, code refactored and performance enhanced.

> 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?
My concern is that if 3.11 is not backward compatible with 3.10 and break
images this way, people porting projects like Scratch to new platforms will
start forking VM for their project. Fixes that go into one fork may not get
into the main trunk.

Is this a good time to open up a 4.x branch and push the closure changes into
that branch? 3.11 is still on beta so we still have time.

Subbu