headers
Igor Stasenko | 1 Nov 01:37
Picon

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

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.
(Continue reading)

Permalink | Reply | 6 comments |
headers
tim Rowledge | 1 Nov 01:51

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


On 31-Oct-07, at 5:37 PM, Igor Stasenko wrote:
>>
>> 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 :)
Do feel free to travel back in time ten years and try to persuade SqC  
to change things.

>
>
>> 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?
And similarly, feel free to travel back in time so that MC can be  
available ten years ago.

>
>
> I'm just asking myself, when we could finally get rid of burden of C?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andreas Raab | 1 Nov 02:00
Picon
Picon

Re: Thoughts on a concurrent Squeak VM

tim Rowledge wrote:
> Yes, we could probably rewrite a lot of code currently in C source files 
> and put it into Slang methods. Yes, we could probably improve Slang (we 
> tried to get some of that done at Interval but ran out of time) to be 
> more friendly. Yes, we could do lots of things. Got time to do them? Or 
> money to pay me/Craig/Andreas/Ian/John/Mike/Bryce/whoever to do it 
> fulltime? That's the kind of thing that would be required to be able to 
> make any major changes

Well, but let's not throw out the baby with the bath water. Improvements 
would be welcome, in particular if they are easy to review and to 
integrate. It is probably unwise to start this as the 
lets-rewrite-the-vm-and-its-tools-from-scratch approach but there are 
plenty of things that we could do better. For example, I would welcome a 
patch that enables the code generator to optionally build the entire VM 
as an object. That'd be a very nice stepping stone towared a 
multi-threaded VM and can probably be done in a fairly incremental way.

Cheers,
  - Andreas
Permalink | Reply | 4 comments |
headers
Gary Chambers | 1 Nov 02:04

RE: Thoughts on a concurrent Squeak VM

A Slang to Squeak refactoring tool, perhaps...

> -----Original Message-----
> From: squeak-dev-bounces <at> lists.squeakfoundation.org
> [mailto:squeak-dev-bounces <at> lists.squeakfoundation.org]On Behalf Of
> Andreas Raab
> Sent: 01 November 2007 1:00 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Thoughts on a concurrent Squeak VM
>
>
> tim Rowledge wrote:
> > Yes, we could probably rewrite a lot of code currently in C
> source files
> > and put it into Slang methods. Yes, we could probably improve Slang (we
> > tried to get some of that done at Interval but ran out of time) to be
> > more friendly. Yes, we could do lots of things. Got time to do them? Or
> > money to pay me/Craig/Andreas/Ian/John/Mike/Bryce/whoever to do it
> > fulltime? That's the kind of thing that would be required to be able to
> > make any major changes
>
> Well, but let's not throw out the baby with the bath water. Improvements
> would be welcome, in particular if they are easy to review and to
> integrate. It is probably unwise to start this as the
> lets-rewrite-the-vm-and-its-tools-from-scratch approach but there are
> plenty of things that we could do better. For example, I would welcome a
> patch that enables the code generator to optionally build the entire VM
> as an object. That'd be a very nice stepping stone towared a
> multi-threaded VM and can probably be done in a fairly incremental way.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
John M McIntosh | 1 Nov 02:10

Re: Thoughts on a concurrent Squeak VM


On Oct 31, 2007, at 6:00 PM, Andreas Raab wrote:

> tim Rowledge wrote:
>> Yes, we could probably rewrite a lot of code currently in C source  
>> files and put it into Slang methods. Yes, we could probably  
>> improve Slang (we tried to get some of that done at Interval but  
>> ran out of time) to be more friendly. Yes, we could do lots of  
>> things. Got time to do them? Or money to pay me/Craig/Andreas/Ian/ 
>> John/Mike/Bryce/whoever to do it fulltime? That's the kind of  
>> thing that would be required to be able to make any major changes
>
> Well, but let's not throw out the baby with the bath water.  
> Improvements would be welcome, in particular if they are easy to  
> review and to integrate. It is probably unwise to start this as the  
> lets-rewrite-the-vm-and-its-tools-from-scratch approach but there  
> are plenty of things that we could do better. For example, I would  
> welcome a patch that enables the code generator to optionally build  
> the entire VM as an object. That'd be a very nice stepping stone  
> towared a multi-threaded VM and can probably be done in a fairly  
> incremental way.
>
> Cheers,
>  - Andreas

Well building the interpreter.c file to use a single structure for  
globals and then setup a pointer to that allocated structure  
somewhere is trivial as compared to the other ideas kicked about.
However to complete this concept is you need to move the support code  
and plugins to use memory hung off the interpreter structure for
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bert Freudenberg | 1 Nov 02:17
Picon
Gravatar

Re: Thoughts on a concurrent Squeak VM


On Nov 1, 2007, at 2:10 , John M McIntosh wrote:

>
> On Oct 31, 2007, at 6:00 PM, Andreas Raab wrote:
>
>> tim Rowledge wrote:
>>> Yes, we could probably rewrite a lot of code currently in C  
>>> source files and put it into Slang methods. Yes, we could  
>>> probably improve Slang (we tried to get some of that done at  
>>> Interval but ran out of time) to be more friendly. Yes, we could  
>>> do lots of things. Got time to do them? Or money to pay me/Craig/ 
>>> Andreas/Ian/John/Mike/Bryce/whoever to do it fulltime? That's the  
>>> kind of thing that would be required to be able to make any major  
>>> changes
>>
>> Well, but let's not throw out the baby with the bath water.  
>> Improvements would be welcome, in particular if they are easy to  
>> review and to integrate. It is probably unwise to start this as  
>> the lets-rewrite-the-vm-and-its-tools-from-scratch approach but  
>> there are plenty of things that we could do better. For example, I  
>> would welcome a patch that enables the code generator to  
>> optionally build the entire VM as an object. That'd be a very nice  
>> stepping stone towared a multi-threaded VM and can probably be  
>> done in a fairly incremental way.
>>
>> Cheers,
>>  - Andreas
>
> Well building the interpreter.c file to use a single structure for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Muller | 1 Nov 02:51
Picon
Gravatar

Re: SqueakMap crashes in 3.10 beta.7158

SqueakMap supports SAR files, which can do *anything*.  Therefore it,
too, supports dependencies.

To me, the process of building an image is something that always needs
to be done with care.  A tool that tries to pick "the most recent
versions" of prerequisite packages, to me, is "gunslinger" style of
building an image.

What exactly does "guaranteed to work together" mean?  This is a
notion I never really followed about Universes.  Does it simply mean
what SqueaMap already tells us?  That neither of the packages does any
modifications to the base image?  "Work" has different means for
different people depending on the needs.  If loading one package
causes a slow-down in the performance of the other that matters to me,
how can it be said "guaranteed to work?"

This is why I used the strong word "misguided".  It is not intended as
a criticism of the technology, maybe more of the marketing..

Stef wrote:

> the intention being universes is to have a kind of certified release
> which is really valuable.

By "certiifed" do you mean an assessment of the level of quality?  If
so, SqueakMap has this too ("Solid as a rock" ... "Full of bugs for
developers only).

> Since lot of squeakmap packages do not indicate really if they work
> on not in a given version.
(Continue reading)

Permalink | Reply | 23 comments |
headers
Chris Muller | 1 Nov 03:26
Picon

Re: SqueakMap crashes in 3.10 beta.7158

Hi,

> People want a smaller image (less packages in base) as we have now ?
> And this smaller image could load any Squeak code from past and future ?

Yes, this is a good vision.  But the base 3.9 Squeak has 4077 classes,
of which 40, 40!, are for SqueakMap.  This is less than 1%.

So, what do we pay for that 1% savings in number of classes in the
image?  SqueakMap.

This is not a bargain!  There are many old packages which are not
present on Universes which have a chance of resurrection if they are
visible.

> If the answer is not,  people should download ready to use images , like the
> excellent of Damien for 3.10.

Oh, does Damiens 3.10 have SqueakMap ready to go?  If so, he should be
able to help you get into the standard 3.10.

> Or 3.8.2 full if this suits his needs.

But that's not 3.10,which is what we're talking about.  There are
those of us who want the *possibility* of benefitting from all of your
hard work.

> If the answer is yes, people should encourage guys trying to reach this.
> Meaning some sacrifices are needed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcel Weiher | 1 Nov 04:33
Picon

Re: Thoughts on a concurrent Squeak VM


On Oct 31, 2007, at 6:00 PM, Andreas Raab wrote:

> tim Rowledge wrote:
>> Yes, we could probably rewrite a lot of code currently in C source  
>> files and put it into Slang methods. Yes, we could probably improve  
>> Slang (we tried to get some of that done at Interval but ran out of  
>> time) to be more friendly. Yes, we could do lots of things. Got  
>> time to do them? Or money to pay me/Craig/Andreas/Ian/John/Mike/ 
>> Bryce/whoever to do it fulltime? That's the kind of thing that  
>> would be required to be able to make any major changes
>
> Well, but let's not throw out the baby with the bath water.  
> Improvements would be welcome, in particular if they are easy to  
> review and to integrate. It is probably unwise to start this as the  
> lets-rewrite-the-vm-and-its-tools-from-scratch approach but there  
> are plenty of things that we could do better. For example, I would  
> welcome a patch that enables the code generator to optionally build  
> the entire VM as an object. That'd be a very nice stepping stone  
> towared a multi-threaded VM and can probably be done in a fairly  
> incremental way.

I had some code a while ago that generated the entire VM as an  
Objective-C object, with the actual class hierarchy (ObjectMemory ->  
Interpreter  ) still intact.  It interpreted a couple of thousand byte  
codes until it hit a function that had been generated from literal C  
code embedded in the Smalltalk code for the VM.  I gave up at that  
point because there turned out to be quite a bit of that literal code  
that would need to be rewritten, as it would probably need to be for  
any such effort unless these C snippets have since been replaced.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Brown | 1 Nov 07:02
Favicon
Gravatar

Re: SqueakMap crashes in 3.10 beta.7158


On Oct 31, 2007, at 7:51 PM, Chris Muller wrote:

> SqueakMap supports SAR files, which can do *anything*.  Therefore it,
> too, supports dependencies.
>
> To me, the process of building an image is something that always needs
> to be done with care.  A tool that tries to pick "the most recent
> versions" of prerequisite packages, to me, is "gunslinger" style of
> building an image.
>
> What exactly does "guaranteed to work together" mean?  This is a
> notion I never really followed about Universes.  Does it simply mean
> what SqueaMap already tells us?  That neither of the packages does any
> modifications to the base image?  "Work" has different means for
> different people depending on the needs.  If loading one package
> causes a slow-down in the performance of the other that matters to me,
> how can it be said "guaranteed to work?"
>

Hi Chris - I think you are missing one of the main points of the  
Universe model. Universes do not pick the "most recent version of  
anything. A particular universe has pointers to specific code  
packages, i.e. specific mcz files which represent one and only one  
version of that piece of code. There is nothing dynamic about it, so  
it is really like a freebsd port or debian package - you have to have  
specific version of the dependencies that port or package needs, not  
just the "latest".

"Guaranteed to work together" means that the author of the Universe
(Continue reading)

Permalink | Reply | 14 comments |

Gmane