Thoughts on a concurrent Squeak VM (was: Re: Concurrent Futures)

Igor Stasenko siguctua at gmail.com
Thu Nov 1 00:37:55 UTC 2007


On 01/11/2007, tim Rowledge <tim at rowledge.org> wrote:
>
> On 31-Oct-07, at 9:39 AM, Igor Stasenko wrote:
>
> > On 31/10/2007, Rob Withers <reefedjib at yahoo.com> wrote:
> >> Andreas,
> >>
> >> What about using C++?  There would be some degradation of
> >> performance.
> >> However, there would be the benefit of structuring the VM classes,
> >> of not
> >> having to add VM as an argument everywhere, and it may even be
> >> possible to
> >> subclass Thread so we know where the thread-local storage is.
> >>
> > I'd rather prefer to make modifications to slang to be able to
> > generate VM sources for any target language/platform and keep platform
> > dependent code in image instead in separate file(s). This all to
> > simplify build process and to keep all things together.
>
>
> Hah!
>
> Once upon a time we had platform code 'files' in the image. In
> particular, the Mac files. Everyone else had to go through irritating
> and time consuming gymnastics to build a vm.
>
> You couldn't edit these 'files' sensibly because Squeaks text editing
> ad gc has conniptions when you try to edit large strings.

Heh, then don't put large strings. We all know that such code stinks :)

> The changes
> log got polluted by massive chunks of text with each edit.  It was not
> fun. People complained incessantly about not having  vm code in a
> sourcecode control system.

Huh? What does MC for?
I could complain about keeping one plugin code divided by two
different source control systems. It seems very impractical.

> The they still bitch about not having all
> the vm code that way, about how dreadfull it is to have to actually
> *run squeak* in order to build a vm.
>
Yeah, and i'm the one of them. ;) I wrote a small plugin which
requires a platform dependent code.. To my experience its much easier
to code it in external editor and at some point, after debugging, put
it in some method as string and forget about it.
Then it can be shipped with plugin code rather than shipped in two
different parts with tons of instructions how and where to unpack
sources, what modify in makefiles e.t.c e.t.c..

Ohh, i really don't know.. Maybe we should step aside and use idst for
building new VM?
Ian mentioned previously that he will welcome an efforts in this way.
But this means refactoring all VM code from scratch..

I'm just asking myself, when we could finally get rid of burden of C?

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list