On Wed, Jul 23, 2008 at 6:34 AM, Klaus D. Witzel <klaus.witzel at cobss.com>
wrote:

> Hi Eliot,
>
> on Wed, 23 Jul 2008 03:14:51 +0200, you 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.
>>
>
> Terrific !
>
>  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
>>
>
> I've parsed quite a bunch of the .cs files from your directory and found
> only *good* things (since I have not much to compare against when reading
> them with a web browser ;) like for example #methodClass during boot; also
> putting (s := myStream upToEnd) into Parser's loop on
> ReparseAfterSourceEditing; also the new bytecodes which look damned cool !
> :)
>
> Wish I could compare more, against original methods and by using Smalltalk
> tools for example, what 3.9 plus VMMaker did you use (patches?). Can I
> prepare an .image by myself or do you intend to upload a prepared one?


I didn't use a VMMaker in 3.9.  I simply used the modified Qwaq VM to run
all bootstraps.  But I did run the bootstrap in Qwaq internal images,
Croquet 1.0.18 and Squeak3.9-final-7067.

I think at this stage the code is too green for me to upload a prepared
image.  I'd rather people built their own.  That way I can still fix and
change details before things get too frozen.

One example is whether to use indexed inst vars to hold copied values in
BlockClosure, or as I do currently to use an Array.  If using an inst var
closure creation is slower but adding inst vars is easy.  If using indexed
inst vars then either the VM makes it impossible to add inst vars (something
up with which I shall not put) or the code for evaluation is slowed down
because the VM needs to find the size of the closure and the number of named
slots.  So there needs to be a performance evaluation done of each approach.

Another example is temp names for the debugger and for sourceless methods.
 I'm not sure I've got the former right and I broke the latter.  I suspect
that there is a middle ground that solves both of these.

So for now build your own images and contact me with comments, suggestions
fixes etc, either directly or to the blog.  Eventually I'll have to grok
some form of issue tracking (and suggestions are welcome) but for now I'll
keep it cheap and cheerful.


>
> /Klaus
>
>
>  and tying up loose ends (for example I broke decompile with temp names and
>> haven't fixed it).
>>
>> Thanks and enjoy.
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080723/e4d96981/attachment.htm