What about a complete procedure for building from the latest C++
(pure) source?
Pretty detailed instructions are in the source code:
http://code.google.com/p/strongtalk/source/browse/trunk/README.txt
-- kjk
As far as I know, no. There isn't much activity at the moment on the
system. I myself am not working on it right now, primarily because I'm busy
with other things, and because the VM is not multi-threaded and it would be
very hard to make it so, which limits my interest in it. However, there has
been slow progress by others towards a working Linux VM.
Cheers,
Dave
> -----Original Message-----
> From: strongtal...@googlegroups.com
> [mailto:strongtal...@googlegroups.com]On Behalf Of leonsmith
> Sent: Wednesday, April 09, 2008 11:13 AM
> To: Strongtalk-general
> Subject: Re: Status of Strongtalk C++ code: VM stability and progress on
> a graphical debugger
>
>
>
> God, I'm glad I found this forum. I have been hand-porting the Windows
> source to Ubuntu using the Anjuta IDE to help create the make files
> and dependencies and I was pulling my hair out.I'll get the code from
> svn.
>
> A general question: Is anyone preparing to offer commercial support
> for this ? To ever get serious consideration companies will have to
> believe that there is an organization behind Strongtalk.
As far as I know, no. There isn't much activity at the moment on the
system. I myself am not working on it right now, primarily because I'm busy
with other things, and because the VM is not multi-threaded and it would be
practically impossible to make it so, which limits my interest in it.
I know Gilad has said that he can't justify devoting resources to VM
hacking, and I can understand that, but how stable do you need the VM
to be before you would consider using it as a base? What tools support
would you require? For example, would you need an interactive debugger
before you would consider using it? Equally are there any areas that
are particularly unimportant? Please consider what you can actively
contribute to the improvement of Strongtalk. Even if that doesn't
include fixing issues with the VM, identifying the areas that cause
problems that prevent you from using Strongtalk as a base would help.
-~----------~----~----~----~------~----~------~--~---
What's more, it scalesThis is one of my concerns.
> much better.
Agreed. What is Strongtalk's concurrency model, if any?
To continue working with Strongtalk, as if it were a serious tool and
not a cool toy, I need: stability, a graphical debugger, external
interfacing to DDLs, and then a sound concurrency model.
We need to understand why the progress has been slow. Strongtalk
When I arranged for Strongtalk's release at Sun I
> had hoped the open source community would make it robust enough for real
> use. So far, progress has been rather slow. I hope that will change.
looks like adavanced compiler technology to me. Why aren't people
working on it? Is the C++ code difficult to understand? Is it badly
organized?
And there's also the Actalk framework that was written in Smalltalk few decades ago.
http://www-poleia.lip6.fr/~briot/actalk/actalk.html
I also recommend reading some of Briot's research papers about Actalk, and OOCP (OO concurrent programming) in general.
Martin
Does the current Newspeak in Squeak have a method formatter and syntax
colorizer?
What is the next step in getting Strongtalk into a suitable state for
integration with (or de-Squeaking) Newspeak?
Is the current Strongtalk licensing a problem?
Where in the grand scheme of Newspeak is #become: needed.
I
don't immediately see why this is a challenge.
Does Strongtalk use a
direct-pointer model?
What's wrong with Strongtalk's #doesNotUnderstand:?
> A correct implementation of doesNotUnderstand: is necessary as well. I
> understand some people on the list are looking at these issues.
Concerning the use of Newspeak, I assume that I can download the
latest Squeak and play with Newspeak there.
I think I'm also reading
that there is a native version that Cadence are working on, but have
not released yet. Is this correct?
Is there a firm schedule for the
release of this native version?
Is this native version being built
from the ground up,
or have you decided to commit to the integration
of Strongtalk and this current native Newspeak, instead, to produce,
in less time, a faster native version.
I suppose that you will commit
to the latter path,
if the above problems in Strongtalk can be fixed.
But we do need it for serializing instances and source code?
The other place it is
> used is in the deserializer, which is pretty central to our take on
> deployment.
So, Strongtalk's polymorphism breaks on #doesNotUnderstand:, but not
> > > A correct implementation of doesNotUnderstand: is necessary as well. I
> > > understand some people on the list are looking at these issues.
>
> > What's wrong with Strongtalk's #doesNotUnderstand:?
>
> It doesn't seem to get called if you override it.
in general (seems to be working everywhere else in the image?).
There are two issues: first, Subversion is not suitable for archiving large
binary files (and there is only a 100MB limit on the archive). Secondly, we
cannot yet rebootstrap the image, so we always need to start with a working
image. But that won't be that hard to fix. Once we can re-bootstrap,
having the image is no longer necessary, it just acts as a convenient cache.
-Dave
>
> Shaping
>
Date: Wed, 14 May 2008 21:41:16 -0700
From: gbr...@gmail.com
To: strongtal...@googlegroups.com
Subject: Re: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
-----Original Message-----
From: strongtal...@googlegroups.com [mailto:strongtal...@googlegroups.com]On Behalf Of J J
Sent: Monday, June 02, 2008 6:12 AM
To: strongtal...@googlegroups.com
Subject: RE: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
Thanks very much for answering this. At the moment, this group is forwarded to an email I don't read much.
The actor model can, as you say, be added at any time as a library. One property that Erlang has that would require a VM change is that Erlang itself can and will run in multiple "OS threads". Each of these threads runs a scheduler and when ever the user creates a new "process" it will go to one of these schedulers automatically. This lets the programmer gain the speed up of multiple CPUs without the huge amount of pain involved in a fine-grain locked scheme.
I'm also not sure what it would be like adding exactly Erlang's scheme to Smalltalk, but I think it would be a positive. The biggest difference would be that currently Smalltalk "processes" can share state with other processes, while in Erlang a "process" is more like a Unix process, i.e. no possible way for another process to see the structures inside it.
There are also other options for concurency, e.g. the "futures" model used by the E language and by a system built in Squeak Smalltalk called Croquet.
-----Original Message-----
From: strongtal...@googlegroups.com [mailto:strongtal...@googlegroups.com]On Behalf Of J J
Sent: Monday, June 02, 2008 6:12 AM
To: strongtal...@googlegroups.com
Subject: RE: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
Thanks very much for answering this. At the moment, this group is forwarded to an email I don't read much.
The actor model can, as you say, be added at any time as a library. One property that Erlang has that would require a VM change is that Erlang itself can and will run in multiple "OS threads". Each of these threads runs a scheduler and when ever the user creates a new "process" it will go to one of these schedulers automatically. This lets the programmer gain the speed up of multiple CPUs without the huge amount of pain involved in a fine-grain locked scheme.
I'm also not sure what it would be like adding exactly Erlang's scheme to Smalltalk, but I think it would be a positive. The biggest difference would be that currently Smalltalk "processes" can share state with other processes, while in Erlang a "process" is more like a Unix process, i.e. no possible way for another process to see the structures inside it.
There are also other options for concurency, e.g. the "futures" model used by the E language and by a system built in Squeak Smalltalk called Croquet.
To: strongtal...@googlegroups.com
Subject: RE: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
Date: Mon, 2 Jun 2008 12:16:05 -0700
From: david.gri...@gmail.com
> There seems to be some confusion in the discussions caused by my comment about the difficulty of making the VM multi-threaded. Choosing a different model for Smalltalk > concurrency has almost nothing to do with the point I was making.
Erlang's model may or may not be a good one (personally I think it is a nice in a small way following the functional philosophy, but I'm not at all convinced that passing only lightweight values with no other shared state is good enough for what people do in the real world).
But regardless of the concurrency model of the target language, if you want multiple things happening at the same time then the VM needs to be internally multi-threaded with shared state, regardless of how the threads communicate in the target language.
The Strongtalk VM stores all the bytecodes, classes, etc on the same shared heap. Garbage collection, reflective modification, etc. all modify that heap, and those modifications must be syncronized across all running threads, processes, or whatever.
Of course, you could implement the Erlang model by making a completely separate copy of the entire VM/heap for each thread, but you can do that in any language without modifying the VM at all. That's called an 'OS process'. Or you could 'compile' a bunch of lighter-weight kind of Erlang-style threads into a single thread/process, but such threads won't run concurrently on a multi-core system.
None of these things have much to do with making the VM multithreaded.-Dave
Make every e-mail and IM count. Join the i’m Initiative from Microsoft.<BR