Subject: Re: *Development Direction* - msg#00006

Previous Message by Date:

Re: Personal Changes

On Thu, 2006-09-21 at 12:16 -0700, Brian Rice wrote: > Burning Man was great; my head feels pleasantly rewired. Burning Man has a way of doing that to people. > However, I think I've come to realize that I'm not going to be > happy writing tools for developers, the same developer > community that keeps the status quo. It's irrational, but > seemingly true. Keeping the energy to work on open source projects all the time is hard. You should be proud of the how much was accomplished, and the effort that you and everyone who has contributed put into it. It's definitely best that if the project stops being fun that you probably should let it go to someone else. > I've already started a project to start a business. Unlike previous > ones, this one won't have to be such a damn secret. I'll inform when > it's ready to talk about. Good luck. And have fun. -- Sam Phillips sam@xxxxxxxxxxxxx

Next Message by Date:

Re: *Development Direction*

(Reposted from my google account.) 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

Previous Message by Thread:

Strongtalk VM now open sourced

Sun Microsystem has open sourced the Strongtalk VM.  I remember a few positive references to Strongtalk by some of you, so I thought you might be interested in this news, if you haven't already heard.

Next Message by Thread:

Re: *Development Direction*

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@xxxxxxxxx> 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 theStrongtalk system with good reason. We did make a better C-translation dialect that we refer to as Pidgin - it is much moreidiomatic and does generate C structure types and uses them. The source code is extremely clean and concise - the VM is separatedmodularly into a bytecode interpreter, object memory, garbagecollector, and supporting primitive operations. Each module has anunderstandable interface and can be replaced easily. Interpreters can be used as processes and could potentially be usable for OS-levelthread managers.However, we never had the kind of attention paid to the VM whichwould complete the dynamic inlining. But more importantly, the libraries were *designed* with an inlining compiler in mind (and weused the Strongtalk collection libraries as a template), so there isa tremendous method-call overhead with even simple operations, makingSlate much slower than Squeak right now, even if its libraries are much more powerful and well-factored. Hence, I would also like toparticipate in this discussion and hopefully partner with someone tobring these advances to Slate. Without them, the project is just notvery 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. Slatedoes bootstrap images from scratch (even via make-rule), albeit notin an incredibly flexible way. That said, we can make everything froma "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 werecalled.> 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'vehad with some MetaRuby contributors has indicated. ---Brianhttp://tunes.org/~water/brice.vcf