*Development Direction*

[Mark Haniford]

I have no idea of the technical difficulties getting Slate running on the
Strongtalk VM, but that would be one helluva a system, and totally different
from anything else out there.

On 9/27/06, Brian Rice <water at tunes.org> wrote:
>
> I suppose it's time for me to chime in.
>
> On Sep 27, 2006, at 6:51 PM, Josh Scholar wrote:
>
> > I've been interested in implementing a dynamic language with full type
> > feedback optimization...
> >
> > I looked at squeak and decided that the VM code is unredeemable.  It's
> > a complete mess, badly designed, not at all object oriented at its
> > base, unprofessional, disorganized and developed by too many people
> > over the years.  It's so bad that I think it's almost impossible to
> > do simple things like adding a new field to a type that used by
> > primitives. They didn't use such modern advances as structures in
> > the C
> > code.
> >
> > The original idea of Squeak, to write Smalltalk in Smalltalk was a
> > hack
> > that only lasted long enough to debug the first version of the VM.
> > After that, the emulation code rotted, no longer works, and cannot be
> > resurrected.  There are semantic differences between the Smalltalk
> > emulation and the C compiled code that cannot be bridged.
> >
> > So while it should be possible to port classes over from Squeak, I
> > wouldn't dare try to switch the VM over.  Certainly not with a
> > populated image...
>
> The "clean" Slate project (at http://slate.tunes.org ) set out to
> implement a system with these problems fixed, and references the
> Strongtalk system with good reason. We did make a better C-
> translation dialect that we refer to as Pidgin - it is much more
> idiomatic and does generate C structure types and uses them. The
> source code is extremely clean and concise - the VM is separated
> modularly into a bytecode interpreter, object memory, garbage
> collector, and supporting primitive operations. Each module has an
> understandable interface and can be replaced easily. Interpreters can
> be used as processes and could potentially be usable for OS-level
> thread managers.
>
> However, we never had the kind of attention paid to the VM which
> would complete the dynamic inlining. But more importantly, the
> libraries were *designed* with an inlining compiler in mind (and we
> used the Strongtalk collection libraries as a template), so there is
> a tremendous method-call overhead with even simple operations, making
> Slate much slower than Squeak right now, even if its libraries are
> much more powerful and well-factored. Hence, I would also like to
> participate in this discussion and hopefully partner with someone to
> bring these advances to Slate. Without them, the project is just not
> very useful.
>
> > The images are another problem.  When I stopped following a year
> > ago or
> > so, there was no way to create a clean image, and my attempts to run
> > each of the many image walkers failed. I love the process and data
> > persistence of Smalltalk images, but the Squeak project shows just how
> > pernicious it is to have a system with no ability to start clean.
>
> There is a Squeak image bootstrap package now, and Spoon also has a
> solution for this. Granted, they are difficult to work with. Slate
> does bootstrap images from scratch (even via make-rule), albeit not
> in an incredibly flexible way. That said, we can make everything from
> a "3+4" image up to a full one with development support by changing
> the code-sources specification list.
>
> > Just try to find out what each object and process in a Squeak image
> > does... and good luck with that! However I do think that someone had
> > written a special VM to help solve that problem - one which weeded out
> > objects that weren't used in a specific run, or which ported objects
> > from a different image as needed, with user interaction for each
> > object.
>
> Craig Latta's Squeak-based Spoon project includes tools for doing
> that thing, for example using bit-flags to trace whether methods were
> called.
>
> > My own project hasn't gotten far enough to make public yet, but I
> > decided on Ruby as much better starting point because the code is
> > readable and pretty clean - an amazing accomplishment for a project
> > written in C.
>
> Unfortunately, Ruby's grammar is problematic, as conversations I've
> had with some MetaRuby contributors has indicated.
>
> --
> -Brian
> http://tunes.org/~water/brice.vcf
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /archives/slate/attachments/20060927/8f8acad3/attachment-0001.htm