Re: [squeak-dev] new blog post plus closure bootstrap code

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

Re: [squeak-dev] new blog post plus closure bootstrap code

David T. Lewis
On Tue, Jul 22, 2008 at 06:14:51PM -0700, Eliot Miranda wrote:

> Hi All,
>     I've made a significant step today in making available the first cut of
> my closure scheme.  There is a new blog post on
> www.mirandabanda.org/cogblogabout the closure bytecodes which at the
> end includes a pointer to the
> bootstrap @ www.mirandabanda.org/files/Cog/Closures0808/Bootstrap/.  The
> bootstrap has been tested on internal Qwaq images, and on Croquet 1.0 and
> Squeak 3.9.  I'd love to hear of other ports, e.g. to 3.10 and to Spoon.
>  I'm interested in bug reports (I haven't yet tested eToys) and code reviews
> and tying up loose ends (for example I broke decompile with temp names and
> haven't fixed it).
I can confirm building a VM from the ClosureVMBootstrap.1.cs change set with
SqueakSource VMMaker-dtl.104 (non-Croquet) on Squeak 3.8 on Linux. It works
fine and I see no issues with backward compatibility for existing images.

I am attaching the changes that were required to merge ClosureVMBootstrap with
a non-Qwaq VMMaker. The changes were as follows:

- Add missing ClassBlockClosure var to ObjectMemory
- Merge class and instance var defs in Interpreter
- Remove large integer stuff from #initializePrimitiveTable (is this for Croquet?)
- Delete (now unused) primitiveObsoleteIndexedPrimitive

The ClassBlockClosure definition in ObjectMemory was probably an accidental
omission from the ClosureVMBootstrap change set, and the remainder of the
changes are a straightforward merge for a different flavor of VMMaker.

I have not yet progressed as far as getting the closure compiler loaded,
but the closure-enabled VM seems to be trouble-free and fully backward
compatible.

Dave




ClosureVMBootstrapPatch-dtl.1.cs (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] new blog post plus closure bootstrap code

Eliot Miranda-2
Hi David,

    I have been tardy in leaving a blog post and important updates unpublished while I've worked on the stack VM and a profiler.  I'll try extra hard this week to update the web site and the code now I have an external user (very exciting!!).

Thanks!!

On Sun, Nov 2, 2008 at 6:31 PM, David T. Lewis <[hidden email]> wrote:
On Tue, Jul 22, 2008 at 06:14:51PM -0700, Eliot Miranda wrote:
> Hi All,
>     I've made a significant step today in making available the first cut of
> my closure scheme.  There is a new blog post on
> www.mirandabanda.org/cogblogabout the closure bytecodes which at the
> end includes a pointer to the
> bootstrap @ www.mirandabanda.org/files/Cog/Closures0808/Bootstrap/.  The
> bootstrap has been tested on internal Qwaq images, and on Croquet 1.0 and
> Squeak 3.9.  I'd love to hear of other ports, e.g. to 3.10 and to Spoon.
>  I'm interested in bug reports (I haven't yet tested eToys) and code reviews
> and tying up loose ends (for example I broke decompile with temp names and
> haven't fixed it).

I can confirm building a VM from the ClosureVMBootstrap.1.cs change set with
SqueakSource VMMaker-dtl.104 (non-Croquet) on Squeak 3.8 on Linux. It works
fine and I see no issues with backward compatibility for existing images.

I am attaching the changes that were required to merge ClosureVMBootstrap with
a non-Qwaq VMMaker. The changes were as follows:

- Add missing ClassBlockClosure var to ObjectMemory
- Merge class and instance var defs in Interpreter
- Remove large integer stuff from #initializePrimitiveTable (is this for Croquet?)
- Delete (now unused) primitiveObsoleteIndexedPrimitive

The ClassBlockClosure definition in ObjectMemory was probably an accidental
omission from the ClosureVMBootstrap change set, and the remainder of the
changes are a straightforward merge for a different flavor of VMMaker.

I have not yet progressed as far as getting the closure compiler loaded,
but the closure-enabled VM seems to be trouble-free and fully backward
compatible.

Dave




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] new blog post plus closure bootstrap code

Bryce Kampjes
In reply to this post by David T. Lewis
David T. Lewis writes:
 > I can confirm building a VM from the ClosureVMBootstrap.1.cs change set with
 > SqueakSource VMMaker-dtl.104 (non-Croquet) on Squeak 3.8 on Linux. It works
 > fine and I see no issues with backward compatibility for existing images.
 >
 > I am attaching the changes that were required to merge ClosureVMBootstrap with
 > a non-Qwaq VMMaker. The changes were as follows:
 
I merged the clousreVMBootstrap into the Exupery VMs. It works with
old style images, I don't think that it's been used for closures yet.

I did this to give the pharo guys a VM with closure bytecodes.

Bryce

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] new blog post plus closure bootstrap code

johnmci
In reply to this post by David T. Lewis
Ok, I noticed that

SystemDictionary>>recreateSpecialObjectsArray   was

        newArray at: 7 put: String.

but is altered to via Eliot's change set to

        newArray at: 7 put: ByteString.

Is that on purpose, or some creeping Croquet change?

On Nov 2, 2008, at 6:31 PM, David T. Lewis wrote:
> I can confirm building a VM from the ClosureVMBootstrap.1.cs change  
> set with
> SqueakSource VMMaker-dtl.104 (non-Croquet) on Squeak 3.8 on Linux.  
> It works
> fine and I see no issues with backward compatibility for existing  
> images.

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




Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: new blog post plus closure bootstrap code

Andreas.Raab
John M McIntosh wrote:

> Ok, I noticed that
>
> SystemDictionary>>recreateSpecialObjectsArray   was
>
>     newArray at: 7 put: String.
>
> but is altered to via Eliot's change set to
>
>     newArray at: 7 put: ByteString.
>
> Is that on purpose, or some creeping Croquet change?

This was done for the m17n changes in 3.8 - if you have the former
variant you are either running 3.7 or earlier or your image is
completely broken. Eliot's change was adding class BlockClosure.

Cheers,
   - Andreas