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

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?

/Klaus

and tying up loose ends (for example I broke decompile with temp names and
haven't fixed it).

Thanks and enjoy.

On Wed, 23 Jul 2008 17:14:38 +0200, Eliot Miranda wrote:

On Wed, Jul 23, 2008 at 6:34 AM, Klaus D. Witzel wrote:

...

... 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.

Hm, then my question should have been: is this modified VM available for the win32's?

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.

Okay. I was reflecting mainly the VM source code changes here. I'll skip them.

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.

Since there where 1-2 questions during recent years, for adding instVars to some subclass of ContextPart, why not?

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.

Performance of loading the array oop from its slot v.s. computing # of named slots? How about just incrementing stackPointer for allocating the closure's slots (as is done for method temps) when the BlockClosure is created. Of course this then needs a base value (like initial IP has).

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.

This was also a problem for the current Decompiler (IIRC Stef posted such an example long time ago).

So for now build your own images and contact me with comments, suggestions
fixes etc, either directly or to the blog.

Will see what is possible by using 3.8 as base (most likely not before Saturday).

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.

Good news Elliot! To what i see, changes you made are not too hard to
merge with Hydra changes. :)

Too bad, i had little time to work with Hydra for last two weeks.

There are little news, except that Hydra able to run Qwaq Forums on
win32, and it does it quite stable.

Yesterday i started writing a CodeGenerator changes overview, i think
i'll finish it tomorrow.

I'm also planned to release an update of Hydra sources and VMMaker
package.. but i postponing release day by day.. because i'm little
nervous, can't really tell the reason..
Maybe because, if these changes, after some evaluation show that VM is
quite stable, this will mean declaring a Hydra VM entering a Beta
stage (on win32 platform only for now).  :)