Status of Strongtalk C++ code: VM stability and progress on a graphical debugger

43 views
Skip to first unread message

Shaping

unread,
Mar 3, 2008, 1:07:20 AM3/3/08
to Strongtalk-general
I want to build Strongtalk from C++ (without any dependencies on
assembler). I understand from the last thread ending on 2007-04-26
that the assembler portions have been removed and recoded as C++. If
this is correct, then where can I download the most current source and
an associated Visual Studio project file (if one exists)?

More generally, can someone point me to the reference page of
instructions on what C++ dev-environs are best used (I'll be using
VS .NET, unless I get other advice), compiling options, where to get
the actual CPP source files and how to best organize them in a VS
project. I too am trying to get a clean compile "from scratch" in the
sense of knowing that I can start with just some C++ files and get a
working, stable image, at least at startup.

Speaking of stability, where are we? How serious are the remaining
problems in the VM? Are we aware of most the problems that cause
crashes, or are we still trying to track them down? Does someone
maintain a page logging (with timestamps) investigations/descriptions
of serious bugs?

Concerning a graphical debugger, where are we? Has anyone done any
work in this direction? This seems to be the biggest impediment to
getting other things done in Strongtalk, like improving the GUI.
Specifically, I want a regular class-hierarchy browser, like Dolphin's
or VW's. I'm willing to build one, but can't get much done without a
good debugger. So a working graphical debugger (even if very simple)
seems to be the main project, apart from fixing stability-related
issues in the VM.

A more modest objective: Are there examples/instructions somewhere on
efficiently using Strongtalk's simple command-line debugger? I
suppose that a better one could be grown from this one, as a first
approach.

Any comments/details on these issues are welcome.


Regards,

Shaping

Gilad Bracha

unread,
Mar 3, 2008, 3:48:46 PM3/3/08
to strongtal...@googlegroups.com
Hi Shaping,

As far as an a debugger goes, there is a rudimentary debugger. It was intended to become a full debugger, but was never completed. You can easily bring it up by evaluating a send of an undefined message (e.g., Object new someUndefinedMethod).  Use the meta button to get an inspector on it, and you'll see that it is an instance of class StackTraceInspector. 

The nice thing about it is that (like Self's debugger), it uses the visual metaphor of a stack. Each stack frame is presented by an ActivationOutliner, which should communicate with a mirror representing the stack frame
in question, an instance of Activation. There is also an ActivationVMMirror, but it doesn't seem to do much at the moment. I don't recall the intent there (this stuff got done while I was on leave when my son was born), but in general mirrors are subdivided into low level mirrors that depend on VM specifics, and high level mirrors representing the language level abstraction. 

Expanding this to a full debugger may or may not require adding some primitives to the VM. It may be a matter of setting up the GUI to call existing facilities used by the console debugger.


--
Cheers, Gilad

Shaping

unread,
Mar 3, 2008, 10:30:35 PM3/3/08
to Strongtalk-general
Thanks Gilad.

What about a complete procedure for building from the latest C++
(pure) source?


Shaping

Gilad Bracha

unread,
Mar 3, 2008, 11:02:32 PM3/3/08
to strongtal...@googlegroups.com
Shaping,

What about a complete procedure for building from the latest C++
(pure) source?

That isn't something I can help you with, I'm afraid. Others have worked on these issues, and hopefully someone will respond to you soon.

I wish I could do more, but I haven't followed the mechanics of the project since helping with the initial public  release in 2006; I'm not a VM hacker, and I  am not actually working on Strongtalk at the moment. Instead, I'm focused on my new language, Newspeak.  I hope that at some point we can use the Strongtalk VM to run Newspeak - when Strongtalk is stable enough.

I think you are absolutely right to focus on questions about the overall stability of the system.  I haven't seen much happen on that front since the VM source was made available, which is too bad, because that is what is critical and hard.

--
Cheers, Gilad

Krzysztof Kowalczyk

unread,
Mar 3, 2008, 11:34:13 PM3/3/08
to strongtal...@googlegroups.com
On Mon, Mar 3, 2008 at 7:30 PM, Shaping <sha...@bigfoot.com> wrote:
> 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

Shaping

unread,
Mar 4, 2008, 2:04:28 AM3/4/08
to Strongtalk-general
This link seems to refer to a build involving Assembler. I thought
that all of this was recently removed and converted to C++.

Shaping



On Mar 3, 10:34 pm, "Krzysztof Kowalczyk" <kkowalc...@gmail.com>
wrote:

talksmall

unread,
Mar 4, 2008, 5:36:36 AM3/4/08
to Strongtalk-general
You will find the most recent instructions for building the code on
the Wiki - http://code.google.com/p/strongtalk/wiki/Building. I have
only used VC++ 2K5 Express to build under Windows. You can ignore the
part of the instructions that refer to the assembler sources and
the .obj files. These are no longer required. prunedtree has ported
the assembler code to the built-in macro assembler within the
Strongtalk binary. One of the first things the VM does on start up is
to generate the code for the interpreter and stub routines that used
to be written in assembler.

As for a project file, I don't do much work in Windows; my interest is
in the Linux port. When I do some work in Windows I have tended to
construct the project file from scratch.

I would suggest working with the gcc-linux branch. Although, as it's
name suggests, it is the home of the Linux port, I have made efforts
to ensure that the code continues to run under Windows as well. In
order to use this you will need a copy of a compatible image and
sources. These can be found on the download page of the Wiki -
http://code.google.com/p/strongtalk/downloads/list . This image can be
used by both the Windows and Linux versions of the VM.

As to VM stability, the interpreter appears to be reasonably stable.
The recompiler is another matter, at least under Linux. Since so
little of the code is OS dependent, I imagine the story is probably
quite similar under Windows, but I haven't really tested that
assumption. Most of the issues I have seen appear to be related to non-
local returns from blocks (I discovered this while writing a pure
Smalltalk implementation of ANSI exception handling that relies
heavily on NLRs).

Regards, talksmall

talksmall

unread,
Mar 4, 2008, 5:42:09 AM3/4/08
to Strongtalk-general
Gilad,
I know Eliot expressed an interest in porting the VM to Mac OSX late
on last year. It was just before Christmas, so it may just be
gathering dust. If not, I'd be interested to know how he got on.

Regards, talksmall

talksmall

unread,
Mar 4, 2008, 5:53:22 AM3/4/08
to Strongtalk-general
On Mar 3, 6:07 am, Shaping <shap...@bigfoot.com> wrote:
> Speaking of stability, where are we? How serious are the remaining
> problems in the VM? Are we aware of most the problems that cause
> crashes, or are we still trying to track them down? Does someone
> maintain a page logging (with timestamps) investigations/descriptions
> of serious bugs?

There is an issues list on the Wiki which you can find here -
http://code.google.com/p/strongtalk/issues/list . I would not say that
it is comprehensive, but it is a start.

Regards, talksmall

leonsmith

unread,
Apr 9, 2008, 2:12:57 PM4/9/08
to Strongtalk-general
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.

On Mar 4, 3:36 am, talksmall <StephenLR...@googlemail.com> wrote:
> You will find the most recent instructions for building the code on
> the Wiki -http://code.google.com/p/strongtalk/wiki/Building. I have
> only used VC++ 2K5 Express to build under Windows. You can ignore the
> part of the instructions that refer to the assembler sources and
> the .obj files. These are no longer required. prunedtree has ported
> the assembler code to the built-in macro assembler within the
> Strongtalk binary. One of the first things the VM does on start up is
> to generate the code for the interpreter and stub routines that used
> to be written in assembler.
>
> As for a project file, I don't do much work in Windows; my interest is
> in the Linux port. When I do some work in Windows I have tended to
> construct the project file from scratch.
>
> I would suggest working with the gcc-linux branch. Although, as it's
> name suggests, it is the home of the Linux port, I have made efforts
> to ensure that the code continues to run under Windows as well. In
> order to use this you will need a copy of a compatible image and
> sources. These can be found on the download page of the Wiki -http://code.google.com/p/strongtalk/downloads/list. This image can be

David Griswold

unread,
Apr 9, 2008, 5:06:37 PM4/9/08
to strongtal...@googlegroups.com
> -----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
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

David Griswold

unread,
Apr 11, 2008, 4:57:24 PM4/11/08
to strongtal...@googlegroups.com
Sorry for the delay in responding, I've changed my email settings and google
groups has been filtering out my replies for some reason.

> -----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.

J J

unread,
May 13, 2008, 3:12:58 AM5/13/08
to strongtal...@googlegroups.com
> From: david.gri...@gmail.com
> To: strongtal...@googlegroups.com
> Subject: RE: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
> Date: Wed, 9 Apr 2008 14:06:37 -0700

>
> 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.

If you mean "make it so" as in "make it have the multi-thread model Java has" then in my opinion it would be a waste of effort to ever do that.  Now what Erlang has would be great and I would expect to be much easier to add to the VM.

That is lots of information out there as to why the currently popular brand of "concurrency" is bad and needs to go away.  Systems that don't have it now shouldn't be making huge efforts to add it, but rather just go right into more advanced stuff.


With Windows Live for mobile, your contacts travel with you. Connect on the go.

Shaping

unread,
May 14, 2008, 11:39:05 PM5/14/08
to Strongtalk-general
To everyone who wants something useful to come of Strongtalk:

> From: david.gri...@gmail.com
> To: strongtal...@googlegroups.com
> Subject: RE: Status of Strongtalk C++ code: VM stability and progress on a
> graphical debugger
> Date: Wed, 9 Apr 2008 14:06:37 -0700
>
> 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.

>If you mean "make it so" as in "make it have the multi-thread model Java
>has" then in my opinion it would be a waste of effort to ever do that. Now
>what Erlang has would be great and I would expect to be much easier to add
>to the VM.

Can we discuss this at length and reach a resolve?

I want to get into the details, evaluate the choices for a
concurrency
model, make a small, concrete, realistic plan, and then execute it.

Or, I can keep fixing and extending VW, as I have for the last 14
years
(not so bad, but not good either).

Or, I can cave into Java's readiness for making real, multithreaded
apps
with good-looking GUIs. Java makes me think of lots of people, doc,
examples, help, descent standards--and a language with crappy sytax
(and
other problems) to clog your read-think path and keep you from your
expressive best.

>That is lots of information out there as to why the currently popular brand
>of "concurrency" is bad and needs to go away. Systems that don't have it
>now shouldn't be making huge efforts to add it, but rather just go right
>into more advanced stuff.

Let's get into it and do something.

What is currently wrong with Java's concurrency model?

What is Erlang's concurrency model and why is it better?


Shaping

Gilad Bracha

unread,
May 15, 2008, 12:41:16 AM5/15/08
to strongtal...@googlegroups.com
FWIW I occasionally had to deal with Java's concurrency issues in my previous life at Sun. Briefly:

Java's concurrency model is built around threads that access a shared heap. Shared state and concurrency is extremely difficult to manage; it is very error prone, and people are always battling race conditions and deadlocks.
Erlang uses an actor model.  Each actor (Process in Erlang) has its own thread of control, but they communicate only via asynchronous message passing. No state is shared among actors - only stateless values are passed among them. It's much easier and more natural to program with. What's more, it scales much better. Java threads are big, heavyweight entities, each with their own call stack. Erlang can support far many processes than Java can threads. There are variations of the actor model, and I'm not sure I want the exact version found in Erlang, but actors are a perfect fit with real object orientation, and any version of them is better than the mess found in Java. In the interest of optimization, Java defines a shared memory model where counter intuitive things can happen; maybe half a dozen people in the world actually understand that model; in practice, it doesn't help the performance of concurrent apps at all, as it encourages over locking. I know someone who calls Java a "lock-oriented" language, since every object is a lock.

So I strongly agree that attempting to emulate that style of concurrency support is a complete waste. I think the number one priority for Strongtalk is to make it stable. Do that, and it runs rings around Java for client applications (not very hard, Java has never been a good client platform), regardless of concurrency. To the extent concurrency is a concern, it's because the optimizations done by the VM/JIT aren't really friendly to concurrency - at least not the pre-emptive threading kind Java does. Overall, I don't think concurrency is even very high on the list of things Strongtalk needs. 

If Strongtalk were robust, we could use it for Newspeak, and bind our portable native GUI, updated browsers, debugger etc. to it. In time, we expect to do an actor library as well- regardlesss of what runtime we use. Unfortunately, I cannot justify the kind of serious VM work necessary to get it ready for prime time. 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. If not, maybe at some point I'll get the resources to work on Strongtalk as part of the Newspeak project, but who knows when/if that will happen.
--
Cheers, Gilad

talksmall

unread,
May 16, 2008, 9:54:41 PM5/16/08
to Strongtalk-general
FWIW although I toy with the idea of multi-threading the VM
occasionally I tend to agree that this should not be a particularly
high priority. I agree with Gilad that stability ought to be our first
goal.

Personally, I am doing my best to focus on stability issues, and have
fixed a couple of issues related to scavenging and garbage collection,
with particular reference to optimized builds and initially focusing
on running with the original compiler. I haven't tried to look at the
new backend yet, since as far as I understand the new backend is not
yet complete and I figure it will be more productive to stabilise the
original compiler first. Progress is slow, because my time is limited,
it sometimes seems like no-one else is involved, there is limited
documentation and no tests (for the VM at least). Now I'm not a VM
expert, so I'm sure that holds me back as well, but I got involved
because I was interested and am making progress, albeit slowly.

So, consider this a call to arms. If you are interested in Strongtalk,
and you want to make it better, please start using it, and let the
group know of your experiences. If things don't work, please raise
issues on the issue database. Please write tests in Smalltalk or C++,
depending on the nature of the issue, to illustrate the problem.
Please provide fixes for them if you can. If something you need is
missing, please consider adding it. If others are out there working on
Strongtalk, either on the VM or on the image, please let us know what
you are doing. If you get stuck post something on the group. It would
be great to know that others out there are actually trying to use
Strongtalk.

If Strongtalk is to move forward we need more people to get actively
involved rather than just tentatively kicking the tyres and then
backing off. That's not meant as a criticism; it can certainly seem
daunting to start with. Very little documentation and a whole lot of C+
+ code to read. Especially if like most of us you are probably a
Smalltalker rather than a VM whiz (and there aren't many of those
about after all).

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.

To reiterate, if you want a better, more robust Strongtalk, get
involved. It won't happen unless more people start to contribute.

Regards, Steve

Shaping

unread,
May 17, 2008, 3:59:57 AM5/17/08
to Strongtalk-general
> Java's concurrency model is built around threads that access a shared heap.
> Shared state and concurrency is extremely difficult to manage; it is very
> error prone, and people are always battling race conditions and
> deadlocks.

Agreed.

> Erlang uses an actor model. Each actor (Process in Erlang) has its own thread of
> control, but they communicate only via asynchronous message passing. No
> state is shared among actors - only stateless values are passed among them.
> It's much easier and more natural to program with.

Agreed. This is cleanest way to program. Being able to see scopes
(actors) and their behaviors clearly, even if I have to work harder to
improve the run-time efficiency of the programming tool is better than
a machine-efficient design that leads to human mental inefficiencies.
People almost always waste more time than machines.

What's more, it scales
> much better.

This is one of my concerns. Do we have actual measurements, from
anyone, on latencies for process switching versus thread switching? I
know that the threads are heavier contexts with possible contention/
locking issues for shared resources, and are generally slower. They
are slower and more complicated. I don't see good reasons for their
existence.

> Java threads are big, heavyweight entities, each with their own
> call stack. Erlang can support far many processes than Java can threads.

What is a practical upper bound on the number of processes? Is there
a maximum count of actors and hence an actor-granularity we need to
respect?

> There are variations of the actor model, and I'm not sure I want the exact
> version found in Erlang, but actors are a perfect fit with real object
> orientation, and any version of them is better than the mess found in Java.

Agreed. What is Strongtalk's concurrency model, if any? What C++
classes or primitives must be reworked to create an Erlang-like
concurrency model?

> In the interest of optimization, Java defines a shared memory model where
> counter intuitive things can happen; maybe half a dozen people in the world
> actually understand that model; in practice, it doesn't help the performance
> of concurrent apps at all, as it encourages over locking. I know someone who
> calls Java a "lock-oriented" language, since every object is a lock.

I don't think anyone wants such a design for Strongtalk.

> So I strongly agree that attempting to emulate that style of concurrency
> support is a complete waste. I think the number one priority for Strongtalk
> is to make it stable.

Do we have a specific list of issues and relevant C++ classes we need
to debug/fix to make it stable?

> Do that, and it runs rings around Java for client
> applications (not very hard, Java has never been a good client platform),

I was impressed by the unboxed-float Mandelbrot-benchmark performance
relative to C. The two were close enough for me not to feel like I
was missing much by developing exclusively in Strongtalk. Still, I
don't mind writing C for primitives, where needed.

> regardless of concurrency. To the extent concurrency is a concern, it's
> because the optimizations done by the VM/JIT aren't really friendly to
> concurrency - at least not the pre-emptive threading kind Java does.
> Overall, I don't think concurrency is even very high on the list of things
> Strongtalk needs.

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.

>
> If Strongtalk were robust, we could use it for Newspeak, and bind our
> portable native GUI, updated browsers, debugger etc. to it.

That seems reasonable. It sounds like an efficient way to get a lot
of the things we need quickly. What exactly then do we need to fix in
Strongtalk to make it stable/robust?

> In time, we
> expect to do an actor library as well- regardlesss of what runtime we use.
> Unfortunately, I cannot justify the kind of serious VM work necessary to get
> it ready for prime time.

I can put some time into it, starting in about three weeks. I need to
setup a C++ environment again, on the new machine (octacore).

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.

We need to understand why the progress has been slow. Strongtalk
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?

> If not,
> maybe at some point I'll get the resources to work on Strongtalk as part of
> the Newspeak project, but who knows when/if that will happen.

I am looking now at Newspeak in greater depth...


Shaping

Gilad Bracha

unread,
May 17, 2008, 12:27:47 PM5/17/08
to strongtal...@googlegroups.com
Hi,

To answer your question - how stable would Strongtalk have to be before we'd use it - very stable. We intend to ship commercial products on the Newspeak platform, and if the Strongtalk VM is to be used as a basis, it has to be production quality. I believe that once the ball gets rolling , this isn't that far away. I also realize it's a chicken and egg problem.

As far as tools - I am not concerned with the state of the debugger. We would layer the Newspeak GUI and IDE (including the debugger) on top of the VM, and do whatever adaptations needed to make that work. I don't think there's an awful lot that would be needed: our FFI is very similar to Strongtalk's, so binding our GUI to Strongtalk should be very doable. There are the basics of debugger support in Strongtalk already, including activation mirrors, so again, I'm optimistic on that front.

On Fri, May 16, 2008 at 6:54 PM, talksmall <Stephe...@googlemail.com> wrote:

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.


-~----------~----~----~----~------~----~------~--~---




--
Cheers, Gilad

Gilad Bracha

unread,
May 17, 2008, 12:52:57 PM5/17/08
to strongtal...@googlegroups.com
Hi,


I'll try and respond to those issues I have an answer for.

On Sat, May 17, 2008 at 12:59 AM, Shaping <sha...@bigfoot.com> wrote:

 What's more, it scales
> much better.

This is one of my concerns.  

If you want to chase down performance data for Java threads vs. actors, you might look at the actor library in Scala. See


some of their papers explore this in some detail. The Erlang literature will also give data.


Agreed.  What is Strongtalk's concurrency model, if any?  

Non-preemptive threading. You can implement some versions actors on top of that as it stands, I think. 
 

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.

Stability is the hard part, where one needs a detailed understanding of the VM code.  As I've said, getting a full debugger isn't that hard:

a. There already is a partial implementation of a debugger
b. If we were to get the system stable enough to be a basis for Newspeak, we'd bind the Newspeak IDE to it, including a debugger.

One caveat for us would be the licensing. Any new code would have to be licensed under similar terms to the Strongtalk base. GPL is the kiss of death for us.

I'm not sure  what you mean by "DDL"? Data Definition Language? Or is it a typo? In any case, you can call out to C and have C call back via the FFI and do whatever.

I expect actors on top of the current system would satisfy your concurrency needs.

 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.

We need to understand why the progress has been slow.  Strongtalk
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?

It is very well organized, but it is still difficult to understand, because high performance VMs are difficult to understand.  


--
Cheers, Gilad

Martin Kobetic

unread,
May 17, 2008, 3:48:54 PM5/17/08
to strongtal...@googlegroups.com
Gilad Bracha wrote:
> If you want to chase down performance data for Java threads vs. actors,
> you might look at the actor library in Scala. See
>
> http://lamp.epfl.ch/~phaller/actors.html
>
> some of their papers explore this in some detail. The Erlang literature
> will also give data.
>

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

Shaping

unread,
May 17, 2008, 4:22:29 PM5/17/08
to Strongtalk-general
Hi.

> > 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.
>
> Stability is the hard part, where one needs a detailed understanding of the
> VM code. As I've said, getting a full debugger isn't that hard:
>
> I'm not sure what you mean by "DDL"? Data Definition Language? Or is it a
> typo?

Yes, typo: Should be "DLLs"

In any case, you can call out to C and have C call back via the FFI
> and do whatever.

Great.


> I expect actors on top of the current system would satisfy your concurrency
> needs.

I think so.

> > 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.
>
> > We need to understand why the progress has been slow. Strongtalk
> > looks like advanced compiler technology to me. Why aren't people
> > working on it? Is the C++ code difficult to understand? Is it badly
> > organized?
>
> It is very well organized, but it is still difficult to understand, because
> high performance VMs are difficult to understand.

I don't see why the understanding would be difficult to achieve with
modular, well factored code, but I haven't actually looked at any of
it yet.


Shaping

Shaping

unread,
May 18, 2008, 5:52:56 AM5/18/08
to Strongtalk-general
> > If you want to chase down performance data for Java threads vs. actors,
> > you might look at the actor library in Scala. See
>
> >http://lamp.epfl.ch/~phaller/actors.html
>
> > some of their papers explore this in some detail. The Erlang literature
> > will also give data.
>
> And there's also the Actalk framework that was written in Smalltalk few decades ago.
>
> http://www-poleia.lip6.fr/~briot/actalk/actalk.html


Gilad/Martin, thanks for the links. I've been reading about Newspeak
and Scala all day, mostly Newspeak, which has a refreshingly simple
grammar. The nesting of classes, overriding of slots, methods, and
classes, and the late binding for all sends is a powerful
combination. I think I can achieve the patterns of expression I want
with it. Brazil and Hopscotch are also inspiring.

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?


Shaping

Gilad Bracha

unread,
May 18, 2008, 11:27:08 AM5/18/08
to strongtal...@googlegroups.com
Hi Shaping,


I'm glad you like what you've seen of Newspeak so far.

On Sun, May 18, 2008 at 2:52 AM, Shaping <sha...@bigfoot.com> wrote:


Does the current Newspeak in Squeak have a method formatter and syntax
colorizer?

We have a syntax colorizer; You can see the syntax coloring in some of the screenshots, and in the video of my talk at HPI in Potsdam.  The native  version doesn't colorize yet, as native text support is still being refined. But it will in the foreseeable future.

There is no method formatter right now. It is pretty easy to add one, especially since the grammar is a shared executable spec that can be subclassed (see my blog posts on parser combinators and executable grammars). 


What is the next step in getting Strongtalk into a suitable state for
integration with (or de-Squeaking) Newspeak?

I assume you mean functionality as opposed to robustness. Support for become:, including a group become: a la Squeak, and a one-way (type safe) become:. The latter two are easy if you get the first working.
A correct implementation of  doesNotUnderstand: is necessary as well.  I understand some people on the list are looking at these issues.


Is the current Strongtalk licensing a problem?

No, as long as it is BSD it should not pose difficulties. 

--
Cheers, Gilad

Robert Shiplett

unread,
May 18, 2008, 11:58:57 AM5/18/08
to strongtal...@googlegroups.com
There would now be an opportunity to run on the Curl NITRO Runtime from curl.com

They are in the process of relaxing the license

Most users are in Korea, Japan and India.  I am hoping to add China and various former Soviet republics to that list ..

I have tried to interest Rebol3 in running on NITRO

We need something Smalltalk-like and we are already typed (Curl)

Robert

Shaping

unread,
May 18, 2008, 6:29:56 PM5/18/08
to Strongtalk-general
On May 18, 10:27 am, "Gilad Bracha" <gbra...@gmail.com> wrote:

> > Does the current Newspeak in Squeak have a method formatter and syntax
> > colorizer?
>
> We have a syntax colorizer; You can see the syntax coloring in some of the
> screenshots, and in the video of my talk at HPI in Potsdam. The native
> version doesn't colorize yet, as native text support is still being
> refined. But it will in the foreseeable future.
>
> There is no method formatter right now. It is pretty easy to add one,
> especially since the grammar is a shared executable spec that can be
> subclassed (see my blog posts on parser combinators and executable
> grammars).

I'm reading http://bracha.org/executableGrammars.pdf now.

I like the brevity of this strategy.

> > What is the next step in getting Strongtalk into a suitable state for
> > integration with (or de-Squeaking) Newspeak?
>
> I assume you mean functionality as opposed to robustness.

Both really.

> Support for
> become:, including a group become: a la Squeak, and a one-way (type safe)
> become:. The latter two are easy if you get the first working.

Yes. 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?

> 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:?

I poked around in Strongtalk-commit. Most of the recent submissions
seem to relate to the gcc build process or to linux. Is anyone
developing with the latest version of Visual Studio. I just asking.
I don't really want to use it because the VS IDE seems to be broken is
basic ways, anyway. What is the most common, least problematic C++
tool set being used to edit and build Strongtalk C++ code?

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.
Is this correct?


Shaping

talksmall

unread,
May 18, 2008, 7:53:45 PM5/18/08
to Strongtalk-general
On May 18, 11:29 pm, Shaping <shap...@bigfoot.com> wrote:
> On May 18, 10:27 am, "Gilad Bracha" <gbra...@gmail.com> wrote:
> Does Strongtalk use a
> direct-pointer model?
>

Yes, additionally both compiled and interpreted methods cache
references to classes.

> > 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 is broken ;)

Basically, method lookups get cached in inline caches. When the class
of the receiver doesn't match the class of the cached method a method
lookup is performed. If a matching method is not found
doesNotUnderstand: gets called, however overriding the implementation
in Object doesn't work quite as expected. Any result returned by the
method is discarded and the lookup just repeats until the stack
overflows.

To fix this, message sends in compiled and interpreted methods need to
allow for a failed lookup followed by an invocation of
doesNotUnderstand: that pops the arguments from the stack and pushes
the result returned by the method.

>
> I poked around in Strongtalk-commit. Most of the recent submissions
> seem to relate to the gcc build process or to linux. Is anyone
> developing with the latest version of Visual Studio. I just asking.
> I don't really want to use it because the VS IDE seems to be broken is
> basic ways, anyway. What is the most common, least problematic C++
> tool set being used to edit and build Strongtalk C++ code?

Actually, although the commits have been on the Linux branch, the code
on that branch builds under both Linux and Windows. The shared image
used by both has no Linux UI support as yet, but scripted Smalltalk
code can be executed.

Most of the recent work I have been doing has been in Windows using VC+
+ 2008 Express. What problems have you had? I haven't seen any
problems with the environment, only with my code ;)

I'm just about to start looking into some of the issues Gilad is
interested in. In particular, doesNotUnderstand:, automatic garbage
collection and become: Wanna help?

Regards, Steve

Gilad Bracha

unread,
May 18, 2008, 8:05:32 PM5/18/08
to strongtal...@googlegroups.com
Shaping,

On Sun, May 18, 2008 at 3:29 PM, Shaping <sha...@bigfoot.com> wrote:
  Where in the grand scheme of Newspeak is #become: needed.

Needed is a strong word. It makes things much easier. 
Traditionally, become: is useful for implementing schema changes. In Strongtalk this is not the case, because there is a primitive that does all that for you for any number of mixins, their applications (classes), subclasses thereof and their instances atomically. The other place it is used is in the deserializer, which is pretty central to our take on deployment.

 I
don't immediately see why this is a challenge.  

It shouldn't be a huge problem, but it isn't implemented right now. It needs to be.
 
Does Strongtalk use a
direct-pointer model?

Yes. 


> 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. 
 

Concerning the use of Newspeak, I assume that I can download the
latest Squeak and play with Newspeak there.  

Alas no. First, it hasn't been released yet, and the public release is a quite a ways off. I know we'll only get one chance to have people look at a new system like this; first impressions are critical. So we will not release it prematurely. We want the native GUI bindings solid, the language close to frozen, all Newspeak libraries (as opposed to Squeak libraries) in place etc. There is a lot of work still.

Second, when it is released, it will include a modified VM with it. We have modified the Squeak VM in a number of ways and will continue to do so. We have added some new byte codes and FFI support, for example. Some of this work would not be necessary if we used Strongtalk - but some might. Bottom line -  you won't run Newspeak on vanilla Squeak.
 
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?  

Not exactly. Let me clarify. There is one version - it runs on a modified Squeak VM.  The "native version" refers to the bottom layer of the GUI. The GUI consists of 3 layers: Hopcotch, an application framework; Brazil, a widget framework; and a binding to some system that actually draws stuff. Sometimes the binding layer of the GUI calls the native GUI. The higher layers are what the programmer sees, and their code runs the same.

Through the binding layer, the Newspeak GUI can be dynamically bound to different underlying GUIs. The first such binding was to Morphic. We now also have a Windows binding, though not quite finished. We intend to build Unix bindings as well. Because the GUI binds dynamically, an image moved from a Windows XP machine to a Linux machine will open up with Linux windows in the same places where the XP windows were when the image was saved on XP. These native bindings will be part of the release. We expect to abandon the Morphic GUI binding entirely. 


Is there a firm schedule for the
release of this native version?  

No.  We are not making public commitments on the schedule.  I'd guess 6-9 months. But that is just a guesstimate. 

Is this native version being built
from the ground up,

Hopefully my comments above answer this. 
 
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.  

We don't rule anything in or out :-). Most of our code should run unchanged regardless of the underlying engine, and it is likely that both the Squeak version and others would co-exist. Only the compiler (probably just its code generator), the low-level Mirrors (for reflection), the Aliens (for FFI) and the binding layer of the GUI vary.
 
I suppose that you will commit
to the latter path,
 
 As I said, these are not mutually exclusive options, and so there is no need to commit. And I won't. Nor do you need me to - Newspeak will be open sourced, and if we don't run it on Strongtalk, there's little to stop others from doing that. If Strongtalk runs well, the odds are very good that we would do the port. If not, someone will, and have a blast doing it :-). I just can't make commitments of this kind.
 
if the above problems in Strongtalk can be fixed.

I'm not sure what "above problems" means, so I'll try and be unambiguous.   What needs to be fixed in Strongtalk above all else is its overall stability. The specific issues listed above (become:, doesNotUnderstand:) are issues of functionality and actually less critical. However, I believe they are useful starting points for people in this group to work on. They are concrete and relatively self contained, and they need to be fixed in any case - whether you want to run Squeak on Strongtalk, as had been suggested, or run Newspeak on it (as I want), and many other usages.  

In other words, I'm not asking anyone here to do something special to support Newspeak. Everything I'm suggesting should be done independently of whether Newspeak ever existed. What I am suggesting is that if these issues are fixed, a lot of the higher level issues around debugging, portable GUI etc. will have a solution waiting.

Fixing functionality alone will not change the basic situation - robustness will. Nevertheless, it will be real progress, and maybe get more momentum going. I'm more optimistic about using Strongtalk than I've been in a while.



--
Cheers, Gilad

Shaping

unread,
May 18, 2008, 9:33:35 PM5/18/08
to Strongtalk-general
On May 18, 6:53 pm, talksmall <StephenLR...@googlemail.com> wrote:
> On May 18, 11:29 pm, Shaping <shap...@bigfoot.com> wrote:
>
> > On May 18, 10:27 am, "Gilad Bracha" <gbra...@gmail.com> wrote:
> > Does Strongtalk use a
> > direct-pointer model?
>
> Yes, additionally both compiled and interpreted methods cache
> references to classes.

What are the differences in the implementations compiled and
interpreted methods? Are the Interpreted methods fully reified?
If you are swapping pointers during a #become:, you have to be able to
find all references. Is doing this reliably the problem?

> > > 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 is broken ;)
>
> Basically, method lookups get cached in inline caches. When the class
> of the receiver doesn't match the class of the cached method a method
> lookup is performed. If a matching method is not found
> doesNotUnderstand: gets called, however overriding the implementation
> in Object doesn't work quite as expected. Any result returned by the
> method is discarded and the lookup just repeats until the stack
> overflows.

Do we actually know where this code for the looping on the method-
lookup lives?

>
> To fix this, message sends in compiled and interpreted methods need to
> allow for a failed lookup followed by an invocation of
> doesNotUnderstand: that pops the arguments from the stack and pushes
> the result returned by the method.

Are you saying that you want the exception handling following the
raising of the MNU expection to work correctly? Apparently the
exception itself is not being raised at all. Is this the problem?
Normally, without a handler in place, you would get the usual
walkback. Do you just want this to work in the usual way, where you
get the walkback, or do you have a specific kind of handler in mind
for this situation in which the cached class doesn't match that of the
reciever?
>
>
>
> > I poked around in Strongtalk-commit. Most of the recent submissions
> > seem to relate to the gcc build process or to linux. Is anyone
> > developing with the latest version of Visual Studio?. I'm just asking.
> > I don't really want to use it because the VS IDE seems to be broken is
> > basic ways, anyway. What is the most common, least problematic C++
> > tool set being used to edit and build Strongtalk C++ code?
>
> Actually, although the commits have been on the Linux branch, the code
> on that branch builds under both Linux and Windows. The shared image
> used by both has no Linux UI support as yet, but scripted Smalltalk
> code can be executed.
>
> Most of the recent work I have been doing has been in Windows using VC+
> + 2008 Express. What problems have you had?

One of the newer versions (I think 2008) of VS, a fresh install,
reportedly (and I verified it) cannot successfully search for and find
referenced member functions, when they are clearly present. This must
be a setup/config problem, but it's very bad one to experience on a
fresh install. I'm considering using Eclipse.

I haven't seen any
> problems with the environment, only with my code ;)
>
> I'm just about to start looking into some of the issues Gilad is
> interested in. In particular, doesNotUnderstand:, automatic garbage
> collection and become: Wanna help?

Yes.

I don't have much choice. Smalltalk is not enough anymore and I need
a better language and VM. Specifically, if there is a bottleneck, I
need to be able to write a primitive myself, compile it in statically
as part of the VM or place it in a DLL and link to it. I also need
callbacks, and I understand from Gilad that this is doable.

I am working with an old machine--somewhat slow, but tolerable if I
don't do to much at once. I'm getting into a new machine soon, but
will be two to three weeks doing that. I can look at C++ source in
the meantime, ask some questions, and get oriented.


Shaping

Shaping

unread,
May 18, 2008, 10:16:41 PM5/18/08
to Strongtalk-general
On May 18, 7:05 pm, "Gilad Bracha" <gbra...@gmail.com> wrote:

> > Where in the grand scheme of Newspeak is #become: needed.
>
> Needed is a strong word. It makes things much easier.
> Traditionally, become: is useful for implementing schema changes. In
> Strongtalk this is not the case, because there is a primitive that does all
> that for you for any number of mixins, their applications (classes),
> subclasses thereof and their instances atomically.

OK, so we don't need #become: for any of the above.

The other place it is
> used is in the deserializer, which is pretty central to our take on
> deployment.

But we do need it for serializing instances and source code?

> > > 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.

So, Strongtalk's polymorphism breaks on #doesNotUnderstand:, but not
in general (seems to be working everywhere else in the image?).

> > Concerning the use of Newspeak, I assume that I can download the
> > latest Squeak and play with Newspeak there.
>
> Alas no. First, it hasn't been released yet, and the public release is a
> quite a ways off. I know we'll only get one chance to have people look at a
> new system like this; first impressions are critical.

Agreed.

So we will not release
> it prematurely. We want the native GUI bindings solid, the language close to
> frozen, all Newspeak libraries (as opposed to Squeak libraries) in place
> etc. There is a lot of work still.
>
> Second, when it is released, it will include a modified VM with it. We have
> modified the Squeak VM in a number of ways and will continue to do so. We
> have added some new byte codes and FFI support, for example. Some of this
> work would not be necessary if we used Strongtalk - but some might. Bottom
> line - you won't run Newspeak on vanilla Squeak.
>
> > 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?
>
> Not exactly. Let me clarify. There is one version - it runs on a modified
> Squeak VM. The "native version" refers to the bottom layer of the GUI.

I see.

The
> GUI consists of 3 layers: Hopcotch, an application framework; Brazil, a
> widget framework; and a binding to some system that actually draws stuff.
> Sometimes the binding layer of the GUI calls the native GUI. The higher
> layers are what the programmer sees, and their code runs the same.
>
> Through the binding layer, the Newspeak GUI can be dynamically bound to
> different underlying GUIs. The first such binding was to Morphic. We now
> also have a Windows binding, though not quite finished. We intend to build
> Unix bindings as well. Because the GUI binds dynamically, an image moved
> from a Windows XP machine to a Linux machine will open up with Linux windows
> in the same places where the XP windows were when the image was saved on XP.

Nice.

> These native bindings will be part of the release. We expect to abandon the
> Morphic GUI binding entirely.

Good. :)

>
> Is there a firm schedule for the
>
> > release of this native version?
>
> No. We are not making public commitments on the schedule. I'd guess 6-9
> months. But that is just a guesstimate.

Fair enough.

>
> Is this native version being built
>
> > from the ground up,
>
> Hopefully my comments above answer this.

Yes.

>
> > 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.
>
> We don't rule anything in or out :-). Most of our code should run unchanged
> regardless of the underlying engine, and it is likely that both the Squeak
> version and others would co-exist. Only the compiler (probably just its code
> generator), the low-level Mirrors (for reflection), the Aliens (for FFI) and
> the binding layer of the GUI vary.
>
> > I suppose that you will commit
> > to the latter path,
>
> As I said, these are not mutually exclusive options, and so there is no
> need to commit. And I won't. Nor do you need me to - Newspeak will be open
> sourced, and if we don't run it on Strongtalk, there's little to stop others
> from doing that. If Strongtalk runs well, the odds are very good that we
> would do the port. If not, someone will, and have a blast doing it :-). I
> just can't make commitments of this kind.

I think I see. You just want it to work well, however it can. I
thought that choosing one path over the other, ultimately, might spare
programming resources.

>
> > if the above problems in Strongtalk can be fixed.
>
> I'm not sure what "above problems" means,

The mentioned issues with Strongtalk.

so I'll try and be unambiguous.
> What needs to be fixed in Strongtalk above all else is its overall
> stability. The specific issues listed above (become:, doesNotUnderstand:)
> are issues of functionality and actually less critical. However, I believe
> they are useful starting points for people in this group to work on. They
> are concrete and relatively self contained, and they need to be fixed in any
> case - whether you want to run Squeak on Strongtalk, as had been suggested,
> or run Newspeak on it (as I want), and many other usages.
>
> In other words, I'm not asking anyone here to do something special to
> support Newspeak. Everything I'm suggesting should be done independently of
> whether Newspeak ever existed. What I am suggesting is that if these issues
> are fixed, a lot of the higher level issues around debugging, portable GUI
> etc. will have a solution waiting.

I want the highest-performance solution, which currently looks like
Newspeak on Strongtalk. I'm trying to gather a list of prioritized
needed Strongtalk fixes to work on, so that Newspeak on Strongtalk
happens as quickly as possible.
>
> Fixing functionality alone will not change the basic situation - robustness
> will. Nevertheless, it will be real progress, and maybe get more momentum
> going.

That's what I'm thinking.

>I'm more optimistic about using Strongtalk than I've been in a while.

I'm glad.


Shaping

Gilad Bracha

unread,
May 18, 2008, 10:28:31 PM5/18/08
to strongtal...@googlegroups.com
On Sun, May 18, 2008 at 7:16 PM, Shaping <sha...@bigfoot.com> wrote:


 The other place it is
> used is in the deserializer, which is pretty central to our take on
> deployment.

But we do need it for serializing instances and source code?

We use become: or deserializing objects in NOF (Newspeak Object Format). Again, it could be done otherwise, but its a lot easier this way. 


> > > 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.

So, Strongtalk's polymorphism breaks on #doesNotUnderstand:, but not
in general (seems to be working everywhere else in the image?).

talksmall explained the mechanics in detail.  Bottom line. It does not work as expected.





--
Cheers, Gilad

talksmall

unread,
May 18, 2008, 11:18:10 PM5/18/08
to Strongtalk-general
Hi Shaping,

On May 19, 2:33 am, Shaping <shap...@bigfoot.com> wrote:
> On May 18, 6:53 pm, talksmall <StephenLR...@googlemail.com> wrote:
>
> > On May 18, 11:29 pm, Shaping <shap...@bigfoot.com> wrote:
>
> > > On May 18, 10:27 am, "Gilad Bracha" <gbra...@gmail.com> wrote:
> > > Does Strongtalk use a
> > > direct-pointer model?
>
> > Yes, additionally both compiled and interpreted methods cache
> > references to classes.
>
> What are the differences in the implementations compiled and
> interpreted methods? Are the Interpreted methods fully reified?

When I referred to compiled methods I meant "interpreted methods that
have been recompiled into native code by the recompiler". I'm not sure
what you mean when you refer to interpreted methods being "fully
reified". Do you mean the methods, or context objects for the stack
frames? Each interpreted method has it's own stack frame, however,
compiled methods are a different matter. Compiled methods are subject
to inlining, so a single physical frame on the stack may represent
multiple logical frames, however the source code structure of the
inlined frames is preserved to allow deoptimization of the frames for
debugging. The StackTraceInspector is an almost-complete UI debugger,
that works with the deoptimized frames. In this tool the frames are
represented by Activation instances somewhat similar to the
homeContexts from Squeak. Is this what you meant?

> If you are swapping pointers during a #become:, you have to be able to
> find all references. Is doing this reliably the problem?
>

Finding all of the references for become: is not really a problem.
After all, this is exactly what the garbage collector has to do when
moving objects around. The code is specific to the garbage collector
though, so it will need to be extracted to allow its reuse for
become:. As Gilad mentioned, it's not that it's hard, it's just work
that has to be done, and no-one's done it yet.

> > > > 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 is broken ;)
>
> > Basically, method lookups get cached in inline caches. When the class
> > of the receiver doesn't match the class of the cached method a method
> > lookup is performed. If a matching method is not found
> > doesNotUnderstand: gets called, however overriding the implementation
> > in Object doesn't work quite as expected. Any result returned by the
> > method is discarded and the lookup just repeats until the stack
> > overflows.
>
> Do we actually know where this code for the looping on the method-
> lookup lives?
>
>

The generated bytecode primitives and the recompiled native methods.
It is not helped by the fact that this is assembler, however, the
assembly is done dynamically on image startup using the same built-in
macro assembler used by the re-compiler and since the assembler code
for the send bytecodes of the interpreter is generated by a single
parameterised method, fixing the interpreted case shouldn't be too
hard. I haven't looked at the equivalent code in the re-compiler,
though I imagine that it will be similar.

The way that the interpreted code works at the moment is to identify
that the IC is stale (ie. the receiver class doesn't match) and fall
through to the lookup code which is supposed to patch the method and
class in the IC. The code then jumps back to the start IC test again
and falls through again. Actually why this causes the stack overflow I
saw when I tried earlier, I'm not sure. I was actually expecting it to
go into a spin loop around the send.

>
> > To fix this, message sends in compiled and interpreted methods need to
> > allow for a failed lookup followed by an invocation of
> > doesNotUnderstand: that pops the arguments from the stack and pushes
> > the result returned by the method.
>
> Are you saying that you want the exception handling following the
> raising of the MNU expection to work correctly? Apparently the
> exception itself is not being raised at all. Is this the problem?

Actually the current doesNotUnderstand: doesn't signal a MNU.
Strongtalk doesn't have ANSI standard exceptions. Instead it calls

Processor stopWithError: (ProcessDoesNotUnderstandError new message:
m)

which is a bit like an exception, without quite being one.
Specifically, there is no mechanism to catch this error other than the
ProcessorScheduler's stopHandler.

Actually I have ANSI exception handling almost completed. A few things
need finishing off, then we should be able to plug it into (for
example) doesNotUnderstand: and be able to catch MNU.

> Normally, without a handler in place, you would get the usual
> walkback. Do you just want this to work in the usual way, where you
> get the walkback, or do you have a specific kind of handler in mind
> for this situation in which the cached class doesn't match that of the
> reciever?
>

In Strongtalk, the equivalent of a walkback would be the
StackTraceInspector mentioned above. This allows individual objects
from the stack to be inspected and modified like a normal debugger. It
has limited restart capabilities though.

>
> > > I poked around in Strongtalk-commit. Most of the recent submissions
> > > seem to relate to the gcc build process or to linux. Is anyone
> > > developing with the latest version of Visual Studio?. I'm just asking.
> > > I don't really want to use it because the VS IDE seems to be broken is
> > > basic ways, anyway. What is the most common, least problematic C++
> > > tool set being used to edit and build Strongtalk C++ code?
>
> > Actually, although the commits have been on the Linux branch, the code
> > on that branch builds under both Linux and Windows. The shared image
> > used by both has no Linux UI support as yet, but scripted Smalltalk
> > code can be executed.
>
> > Most of the recent work I have been doing has been in Windows using VC+
> > + 2008 Express. What problems have you had?
>
> One of the newer versions (I think 2008) of VS, a fresh install,
> reportedly (and I verified it) cannot successfully search for and find
> referenced member functions, when they are clearly present. This must
> be a setup/config problem, but it's very bad one to experience on a
> fresh install. I'm considering using Eclipse.
>

OK I lied, I have seen that one. I get by with text-based searches
instead. Works nearly as well, but it is slightly more clunky. I use
Eclipse when developing on Linux, but I think it only works with GCC.
Which platform are planning on focussing on Linux or Windows. I don't
think anyone has done much work with GCC in Windows since last year
when prunedtree did some of the initial work to the VM to build under
GCC. Also, I'm not wild about it's disassembly support. Typically it
only shows you context going forward from the correct execution point,
which is not great when you are trying to debug a piece of generated
code. Another alternative you might like to look at is Codeblocks,
though I only took a brief look at it last year, so I can't give much
of an impression.

> I haven't seen any
>
> > problems with the environment, only with my code ;)
>
> > I'm just about to start looking into some of the issues Gilad is
> > interested in. In particular, doesNotUnderstand:, automatic garbage
> > collection and become: Wanna help?
>
> Yes.
>
> I don't have much choice. Smalltalk is not enough anymore and I need
> a better language and VM. Specifically, if there is a bottleneck, I
> need to be able to write a primitive myself, compile it in statically
> as part of the VM or place it in a DLL and link to it. I also need
> callbacks, and I understand from Gilad that this is doable.
>

Yes, both callouts and callbacks work for stdcall and cdecl calling
conventions. FFI calls are the one area where an element of
concurrency is available in Strongtalk today. It is possible to call
out to DLL functions asynchronously and continue running Smalltalk
code while the function is executing. Of course, if the call out in
turn results in a call back, then it will pause until the Processor
schedule's it's Process again. The DLL functions do not typically gain
access to Smalltalk objects though. Instead, any data passed to these
functions is copied to the heap via ExternalProxy objects. It is
important not to pass object references outside Smalltalk space, since
these references will not be updated by the garbage collector.

One of the big advantages of Strongtalk is that this may very well not
be necessary, depending on the type of code that you are working with.
The Recompiler can progressively recompile hotspot methods to speed up
bottlenecks. The more frequently the bottleneck is run, the more it is
likely to speed up.

Additionally, DLL calls are subject to the impedance mismatch problem.
Having to copy the data to the heap adds significantly more overhead
than a message send, so if you are frequently crossing the boundary
between Smalltalk and C (or whatever) then this will probably dominate
your performance measurements and you won't see much saving. If you
write additional primitives statically linked into the VM, you will
need to be careful that any object references you store are available
to the garbage collector, or problems will occur when objects get
moved.

> I am working with an old machine--somewhat slow, but tolerable if I
> don't do to much at once. I'm getting into a new machine soon, but
> will be two to three weeks doing that. I can look at C++ source in
> the meantime, ask some questions, and get oriented.
>
> Shaping

My Linux porting stuff was done on a five year old Acer laptop, which
isn't exactly state of the art. Strongtalk performs very well with
limited resources, since most of the technology dates from more than
10 years ago, when machine weren't so generously decked out as they
are today. Building the VM under those environments is another matter
though. The faster the better when you're talking about C++ compiles
and links.

Ask away. I will do my best to provide answers where I can, but I'm
still learning the ins and outs myself. Hopefully Gilad will be able
help out with some other details, and Dave G. occasionally lurks on
the group.

I know some parts better than others (interpreter, memory management,
stack unwinding after ifCurtailed, linux porting details), but I
haven't done much investigation into the Recompiler which is what does
the work of dynamic recompilation of interpreted methods into native
code. Unfortunately, this is also where a lot of the stability issues
seem to occur.

Welcome!

Regards, Steve

Shaping

unread,
May 19, 2008, 11:47:14 PM5/19/08
to Strongtalk-general
On May 18, 10:18 pm, talksmall <StephenLR...@googlemail.com> wrote:

> > What are the differences in the implementations of compiled and
> > interpreted methods? Are the Interpreted methods fully reified?
>
> When I referred to compiled methods I meant "interpreted methods that
> have been recompiled into native code by the recompiler".

Right.

I'm not sure
> what you mean when you refer to interpreted methods being "fully
> reified".

Both are modeled as first-class objects in Smalltalk? Seems that way.

Do you mean the methods, or context objects for the stack
> frames?

Both. I'm asking how we model compiled and interpreted forms of a
method, specifically, so that I can determine how to track-down all
references that may need to participate in a #become:

Each interpreted method has it's own stack frame, however,
> compiled methods are a different matter. Compiled methods are subject
> to inlining, so a single physical frame on the stack may represent
> multiple logical frames, however the source code structure of the
> inlined frames is preserved to allow deoptimization of the frames for
> debugging.

So the CompiledMethod instance that models a compiled method is still
retained for use in debugging, even if the compiled method's machine
code has been inlined in another method being called from an actual
frame on the stack.

The StackTraceInspector is an almost-complete UI debugger,
> that works with the deoptimized frames. In this tool the frames are
> represented by Activation instances somewhat similar to the
> homeContexts from Squeak. Is this what you meant?

Yes, I was referring to this and the models used for the two kinds of
methods.

>
> > If you are swapping pointers during a #become:, you have to be able to
> > find all references. Is doing this reliably the problem?
>
> Finding all of the references for become: is not really a problem.
> After all, this is exactly what the garbage collector has to do when
> moving objects around. The code is specific to the garbage collector
> though, so it will need to be extracted to allow its reuse for
> become:. As Gilad mentioned, it's not that it's hard, it's just work
> that has to be done, and no-one's done it yet.

That is what I supposed and was wondering why the traversal from the
roots of the world hadn't been factored-out for use in #become:

>
>
>
> > > > > 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 is broken ;)
>
> > > Basically, method lookups get cached in inline caches. When the class
> > > of the receiver doesn't match the class of the cached method a method
> > > lookup is performed. If a matching method is not found
> > > doesNotUnderstand: gets called, however overriding the implementation
> > > in Object doesn't work quite as expected. Any result returned by the
> > > method is discarded and the lookup just repeats until the stack
> > > overflows.
>
> > Do we actually know where this code for the looping on the method-
> > lookup lives?
>
> The generated bytecode primitives and the recompiled native methods.

"Recompiling" is the iterative compiling of bottlenecked regions of
code?

> It is not helped by the fact that this is assembler, however, the
> assembly is done dynamically on image startup using the same built-in
> macro assembler used by the re-compiler and since the assembler code
> for the send bytecodes of the interpreter is generated by a single
> parameterised method, fixing the interpreted case shouldn't be too
> hard. I haven't looked at the equivalent code in the re-compiler,
> though I imagine that it will be similar.

All of that seems reasonable.

>
> The way that the interpreted code works at the moment is to identify
> that the IC is stale (ie. the receiver class doesn't match) and fall
> through to the lookup code which is supposed to patch the method and
> class in the IC. The code then jumps back to the start IC test again
> and falls through again. Actually why this causes the stack overflow I
> saw when I tried earlier, I'm not sure. I was actually expecting it to
> go into a spin loop around the send.

Seems that that once the patch in the IC is done correctly, the test
for stale will not longer fall through to the lookup code. Perhaps
the patch itself is the problem.


> > > To fix this, message sends in compiled and interpreted methods need to
> > > allow for a failed lookup followed by an invocation of
> > > doesNotUnderstand: that pops the arguments from the stack and pushes
> > > the result returned by the method.
>
> > Are you saying that you want the exception handling following the
> > raising of the MNU expection to work correctly? Apparently the
> > exception itself is not being raised at all. Is this the problem?
>
> Actually the current doesNotUnderstand: doesn't signal a MNU.
> Strongtalk doesn't have ANSI standard exceptions. Instead it calls
>
> Processor stopWithError: (ProcessDoesNotUnderstandError new message:
> m)
>
> which is a bit like an exception, without quite being one.
> Specifically, there is no mechanism to catch this error other than the
> ProcessorScheduler's stopHandler.

So what magic do we do inside this special handler?

>
> Actually I have ANSI exception handling almost completed. A few things
> need finishing off, then we should be able to plug it into (for
> example) doesNotUnderstand: and be able to catch MNU.

So then we do intend to use exceptions in the usual way, once you get
the new ANSI exception handling code finished?

> > Normally, without a handler in place, you would get the usual
> > walkback. Do you just want this to work in the usual way, where you
> > get the walkback, or do you have a specific kind of handler in mind
> > for this situation in which the cached class doesn't match that of the
> > receiver?
>
> In Strongtalk, the equivalent of a walkback would be the
> StackTraceInspector mentioned above. This allows individual objects
> from the stack to be inspected and modified like a normal debugger. It
> has limited restart capabilities though.

OK.

> > One of the newer versions (I think 2008) of VS, a fresh install,
> > reportedly (and I verified it) cannot successfully search for and find
> > referenced member functions, when they are clearly present. This must
> > be a setup/config problem, but it's very bad one to experience on a
> > fresh install. I'm considering using Eclipse.
>
> OK I lied, I have seen that one.

:)

I get by with text-based searches
> instead. Works nearly as well, but it is slightly more clunky.

I prefer not to have to get by. I want VS to work correctly in the
simplest use-case, and it doesn't. Does anyone have a fix for this?
I guess not. I don't understand why a basic bug like this persists in
a dev environ. I expect MS to be incompetent when they make an OS.
But VS is their development environment, and basic referential
integrity is not present, seemingly, unless I've missed something.

> I use
> Eclipse when developing on Linux, but I think it only works with GCC.

I could use Eclipse for editing code, and then jump out to a command
prompt to run a nmake, but I don't relish the idea.

> Which platform are planning on focussing on Linux or Windows.

I'm focusing on WinXP Pro (no Vista, not ever). I will do Linux
later.

>I don't
> think anyone has done much work with GCC in Windows since last year
> when prunedtree did some of the initial work to the VM to build under
> GCC.

I recall that.

Also, I'm not wild about it's disassembly support. Typically it
> only shows you context going forward from the correct execution point,
> which is not great when you are trying to debug a piece of generated
> code.

That's sounds very frustrating.


> Another alternative you might like to look at is Codeblocks,
> though I only took a brief look at it last year, so I can't give much
> of an impression.

...I did some reading on this. It looks interesting. I will try it
with MinGW.


> > > I'm just about to start looking into some of the issues Gilad is
> > > interested in. In particular, doesNotUnderstand:, automatic garbage
> > > collection and become: Wanna help?
>
> > Yes.
>
> > I don't have much choice. Smalltalk is not enough anymore and I need
> > a better language and VM. Specifically, if there is a bottleneck, I
> > need to be able to write a primitive myself, compile it in statically
> > as part of the VM or place it in a DLL and link to it. I also need
> > callbacks, and I understand from Gilad that this is doable.
>
> Yes, both callouts and callbacks work for stdcall and cdecl calling
> conventions. FFI calls are the one area where an element of
> concurrency is available in Strongtalk today. It is possible to call
> out to DLL functions asynchronously and continue running Smalltalk
> code while the function is executing. Of course, if the call out in
> turn results in a call back, then it will pause until the Processor
> schedule's it's Process again. The DLL functions do not typically gain
> access to Smalltalk objects though. Instead, any data passed to these
> functions is copied to the heap via ExternalProxy objects. It is
> important not to pass object references outside Smalltalk space, since
> these references will not be updated by the garbage collector.

This is similar to what we do in VW with CDatum objects on the foreign
heap. These C structures can be managed manually if allocated with
malloc, or automatically by the GC if allocated with gcMalloc.


> One of the big advantages of Strongtalk is that this may very well not
> be necessary, depending on the type of code that you are working with.
> The Recompiler can progressively recompile hotspot methods to speed up
> bottlenecks. The more frequently the bottleneck is run, the more it is
> likely to speed up.

Yes, I recall reading about this, and am excited about the potential
efficiencies achievable.


> Additionally, DLL calls are subject to the impedance mismatch problem.
> Having to copy the data to the heap adds significantly more overhead
> than a message send, so if you are frequently crossing the boundary
> between Smalltalk and C (or whatever) then this will probably dominate
> your performance measurements and you won't see much saving. If you
> write additional primitives statically linked into the VM, you will
> need to be careful that any object references you store are available
> to the garbage collector, or problems will occur when objects get
> moved.
>
> My Linux porting stuff was done on a five year old Acer laptop, which
> isn't exactly state of the art. Strongtalk performs very well with
> limited resources, since most of the technology dates from more than
> 10 years ago, when machine weren't so generously decked out as they
> are today. Building the VM under those environments is another matter
> though. The faster the better when you're talking about C++ compiles
> and links.

This is my main concern.

Also, I am still collecting opinions on the best C++ environs on
Windows.

> Ask away. I will do my best to provide answers where I can, but I'm
> still learning the ins and outs myself. Hopefully Gilad will be able
> help out with some other details, and Dave G. occasionally lurks on
> the group.
>
> I know some parts better than others (interpreter, memory management,
> stack unwinding after ifCurtailed, linux porting details), but I
> haven't done much investigation into the Recompiler which is what does
> the work of dynamic recompilation of interpreted methods into native
> code. Unfortunately, this is also where a lot of the stability issues
> seem to occur.
>
> Welcome!

Thanks.


Shaping

talksmall

unread,
May 20, 2008, 6:51:04 AM5/20/08
to Strongtalk-general
Hi Shaping,

On May 20, 4:47 am, Shaping <shap...@bigfoot.com> wrote:
> On May 18, 10:18 pm, talksmall <StephenLR...@googlemail.com> wrote:
> I'm not sure
>
> > what you mean when you refer to interpreted methods being "fully
> > reified".
>
> Both are modeled as first-class objects in Smalltalk? Seems that way.

No. Only the interpreted version is visible to Smalltalk. The compiled
version appears as an nmethod in the VM, but I don't believe there is
a Smalltalk level equivalent. When Activation objects are created for
the StackTraceInspector the stack has already been deoptimised to
leave on interpreted frames (and therefore interpreted methods).

>
> Do you mean the methods, or context objects for the stack
>
> > frames?
>
> Both. I'm asking how we model compiled and interpreted forms of a
> method, specifically, so that I can determine how to track-down all
> references that may need to participate in a #become:

In the VM a (re)compiled method is represented as an nmethod. An
interpreted method is represented as a methodOopDesc usually referred
to be a methodOop pointer. The core of the code necessary for a
become: is in phase 1 of the mark and sweep garbage collection in
markSweep.cpp. This illustrates iteration over all places where the VM
may store references to Smalltalk objects.

At the moment this code uses a function pointer passed to a series of
iterator functions (such as Universe::oops_do()). Continuing with this
means that we would need to put the state in global variables, an idea
I'm really not keen on, but may be better than the alternatives.

> So the CompiledMethod instance that models a compiled method is still
> retained for use in debugging, even if the compiled method's machine
> code has been inlined in another method being called from an actual
> frame on the stack.

Well the inlined method may not have been inlined at all call sites,
and the inlining may need to be updated if the site is a polymorphic
send that subsequently needs updating. Also, whenever the stack gets
deoptimised, such as for Smalltalk level debugging, the interpreted
methods (they are actually just referred to as Method(s) in Strongtalk
Smalltalk code) are still required. Also, any reflective performs may
need interpreted or at least non-inlined versions of the method code.

> > > If you are swapping pointers during a #become:, you have to be able to
> > > find all references. Is doing this reliably the problem?
>
> > Finding all of the references for become: is not really a problem.
> > After all, this is exactly what the garbage collector has to do when
> > moving objects around. The code is specific to the garbage collector
> > though, so it will need to be extracted to allow its reuse for
> > become:. As Gilad mentioned, it's not that it's hard, it's just work
> > that has to be done, and no-one's done it yet.
>
> That is what I supposed and was wondering why the traversal from the
> roots of the world hadn't been factored-out for use in #become:
>

I suspect this is solely because no-one got around to implementing
become: yet.

> > The generated bytecode primitives and the recompiled native methods.
>
> "Recompiling" is the iterative compiling of bottlenecked regions of
> code?

It's not iterative exactly, but it may happen repeatedly if a method
is heavily used. Note that tight loops inside a single method
activation that never ends (the typical case being event loops) are
not optimized by the recompiler. Recompilation is typically triggered
on send sites, but the new version of the method is only used for a
new activation of the method, not for existing activations.

>
> > The way that the interpreted code works at the moment is to identify
> > that the IC is stale (ie. the receiver class doesn't match) and fall
> > through to the lookup code which is supposed to patch the method and
> > class in the IC. The code then jumps back to the start IC test again
> > and falls through again. Actually why this causes the stack overflow I
> > saw when I tried earlier, I'm not sure. I was actually expecting it to
> > go into a spin loop around the send.
>
> Seems that that once the patch in the IC is done correctly, the test
> for stale will not longer fall through to the lookup code. Perhaps
> the patch itself is the problem.
>

No. You can only patch the IC with a method that matches the signature
of the message send. doesNotUnderstand: doesn't meet this criteria. In
particular, it expects an instance of Message as an argument, rather
than a list of arguments for the original message send. To work in the
way you suggest the lookup routine would need to pop the arguments off
the stack, construct a Message with those arguments and push it back
in their place, then patch the IC, keeping in mind that this is all
occurring in a different frame of the stack - that of the method
containing the IC, rather than that of the lookup function.

In addition, and somewhat more problematically, the next time you hit
that IC it will contain a reference to doesNotUnderstand:. That's not
so bad if the receiver class has changed, because the lookup gets
called to updated the IC, but if it is the same class, you have a
problem, because there is now no hook to pop the arguments from the
stack and create a Message with them.

All round, I think it is easier to change the send code to invoke
doesNotUnderstand: rather than trying to do it in the lookup function.

> > > > To fix this, message sends in compiled and interpreted methods need to
> > > > allow for a failed lookup followed by an invocation of
> > > > doesNotUnderstand: that pops the arguments from the stack and pushes
> > > > the result returned by the method.
>
> > > Are you saying that you want the exception handling following the
> > > raising of the MNU expection to work correctly? Apparently the
> > > exception itself is not being raised at all. Is this the problem?
>
> > Actually the current doesNotUnderstand: doesn't signal a MNU.
> > Strongtalk doesn't have ANSI standard exceptions. Instead it calls
>
> > Processor stopWithError: (ProcessDoesNotUnderstandError new message:
> > m)
>
> > which is a bit like an exception, without quite being one.
> > Specifically, there is no mechanism to catch this error other than the
> > ProcessorScheduler's stopHandler.
>
> So what magic do we do inside this special handler?
>

Typically the stopHandler starts a StackTraceInspector on the stopped
process. Take a look at Launcher. This is the main Transcript window.
When the programming environment starts it sets the stopHandler on the
Processor (a ProcessorScheduler instance). The code is in
Launcher>>startProgEnv. Of course, the stop handler could be set to
something else using stopHandler: on the Processor, but there's
effectively only one chance to catch the error, not a nested set of
exception handlers. This is what my exception handling implementation
provides using the ANSI Smalltalk description.

> I could use Eclipse for editing code, and then jump out to a command
> prompt to run a nmake, but I don't relish the idea.

Well Eclipse lets you launch external commands automatically, so you
don't need to jump out to a command prompt (or at least not manually).

Regards, Steve

Shaping

unread,
May 21, 2008, 1:20:11 AM5/21/08
to Strongtalk-general
> > Both are modeled as first-class objects in Smalltalk? Seems that way.
>
> No. Only the interpreted version is visible to Smalltalk. The compiled
> version appears as an nmethod in the VM, but I don't believe there is
> a Smalltalk level equivalent. When Activation objects are created for
> the StackTraceInspector the stack has already been deoptimised to
> leave on interpreted frames (and therefore interpreted methods).
>
>
>
> > Do you mean the methods, or context objects for the stack
>
> > > frames?
>
> > Both. I'm asking how we model compiled and interpreted forms of a
> > method, specifically, so that I can determine how to track-down all
> > references that may need to participate in a #become:
>
> In the VM a (re)compiled method is represented as an nmethod. An
> interpreted method is represented as a methodOopDesc usually referred
> to be a methodOop pointer. The core of the code necessary for a
> become: is in phase 1 of the mark and sweep garbage collection in
> markSweep.cpp. This illustrates iteration over all places where the VM
> may store references to Smalltalk objects.
>
> At the moment this code uses a function pointer passed to a series of
> iterator functions (such as Universe::oops_do()). Continuing with this
> means that we would need to put the state in global variables, an idea
> I'm really not keen on, but may be better than the alternatives.

Why not maintain needed global state in a single instance of class
Universe (the most global scope in Strongtalk, presumably), where the
iterators also live?

> > "Recompiling" is the iterative compiling of bottlenecked regions of
> > code?
>
> It's not iterative exactly, but it may happen repeatedly if a method
> is heavily used. Note that tight loops inside a single method
> activation that never ends (the typical case being event loops) are
> not optimized by the recompiler. Recompilation is typically triggered
> on send sites, but the new version of the method is only used for a
> new activation of the method, not for existing activations.

I see.
Agreed.

>
> All round, I think it is easier to change the send code to invoke
> doesNotUnderstand: rather than trying to do it in the lookup function.

Agreed. I need to know more about the structure of the IC and how it
is used in the course of a send. I'm following the gist of this but
some of the details are unclear. I should be looking at code soon
with CodeBlocks.

> > > > > To fix this, message sends in compiled and interpreted methods need to
> > > > > allow for a failed lookup followed by an invocation of
> > > > > doesNotUnderstand: that pops the arguments from the stack and pushes
> > > > > the result returned by the method.
>
> > > > Are you saying that you want the exception handling following the
> > > > raising of the MNU expection to work correctly? Apparently the
> > > > exception itself is not being raised at all. Is this the problem?
>
> > > Actually the current doesNotUnderstand: doesn't signal a MNU.
> > > Strongtalk doesn't have ANSI standard exceptions. Instead it calls
>
> > > Processor stopWithError: (ProcessDoesNotUnderstandError new message:
> > > m)
>
> > > which is a bit like an exception, without quite being one.
> > > Specifically, there is no mechanism to catch this error other than the
> > > ProcessorScheduler's stopHandler.
>
> > So what magic do we do inside this special handler?
>
> Typically the stopHandler starts a StackTraceInspector on the stopped
> process. Take a look at Launcher. This is the main Transcript window.
> When the programming environment starts it sets the stopHandler on the
> Processor (a ProcessorScheduler instance). The code is in
> Launcher>>startProgEnv. Of course, the stop handler could be set to
> something else using stopHandler: on the Processor, but there's
> effectively only one chance to catch the error, not a nested set of
> exception handlers. This is what my exception handling implementation
> provides using the ANSI Smalltalk description.

Do we have a standard set of test-scripts in Smalltalk (SUnit tests or
even an agreed upon DoIt or set of them) that drill the VM for various
basic functions, as well as new ones being tested for the first time,
like your ANSI exception handling? In each test cycle I want to know
that I'm fixing my own stuff and not breaking someone else's.


Shaping

talksmall

unread,
May 21, 2008, 5:03:10 AM5/21/08
to Strongtalk-general
Effectively, that is what happens now, except that Universe is
AllStatic (which means what it sounds like). wrt become: I think this
is nasty, because the stored values aren't really part of the state of
Universe, that is just a convenient temporary place to store the two
values (or to sets of values, in the
elementsForwardIdentityTo:copyHash: case) to allow a stateless
function pointer to be used in the iterator method.
There are some Smalltalk-side tests, but very little at the level of
the VM itself. If you look at Bootstrap>>deterministicallyTestSystem,
this is the closest to a SUnit test suite. Actually, now that my
exception handling stuff is nearly complete, I managed to port across
SUnit from the Squeak version, so we could port these across to a
separate set of test classes, as well as adding our own, as they are a
bit skimpy. I have never liked the idea of having the test code for a
class within the class itself.

There is a handy little test script that can be used to run this
automatically from the command line within starting the UI. You will
find it in tools/test.dlt. To run this use something like
strongtalk_debug.exe -f tools\strongtalkrc-forInterpretedTests -script
tools\test.dlt from the strongtalk directory.

BTW once you manage to build strongtalk, and assuming that you are
using the gcc-linux branch, you will need a compatible image and
sources. You can find a zip containing these on the downloads page of
the wiki. You should unzip them in the strongtalk directory.

Regards, Steve

Shaping

unread,
May 22, 2008, 11:15:06 PM5/22/08
to Strongtalk-general
On May 21, 4:03 am, talksmall <StephenLR...@googlemail.com> wrote:

> > Do we have a standard set of test-scripts in Smalltalk (SUnit tests or
> > even an agreed upon DoIt or set of them) that drill the VM for various
> > basic functions, as well as new ones being tested for the first time,
> > like your ANSI exception handling? In each test cycle I want to know
> > that I'm fixing my own stuff and not breaking someone else's.
>
> There are some Smalltalk-side tests, but very little at the level of
> the VM itself. If you look at Bootstrap>>deterministicallyTestSystem,
> this is the closest to a SUnit test suite. Actually, now that my
> exception handling stuff is nearly complete, I managed to port across
> SUnit from the Squeak version, so we could port these across to a
> separate set of test classes, as well as adding our own, as they are a
> bit skimpy. I have never liked the idea of having the test code for a
> class within the class itself.
>
> There is a handy little test script that can be used to run this
> automatically from the command line within starting the UI. You will
> find it in tools/test.dlt. To run this use something like
> strongtalk_debug.exe -f tools\strongtalkrc-forInterpretedTests -script
> tools\test.dlt from the strongtalk directory.
>
> BTW once you manage to build strongtalk, and assuming that you are
> using the gcc-linux branch, you will need a compatible image and
> sources. You can find a zip containing these on the downloads page of
> the wiki. You should unzip them in the strongtalk directory.
>
Why do we not place the compatible image and sources with the source
code? How is the image created or changed when necessary?


Shaping

David Griswold

unread,
May 22, 2008, 11:58:18 PM5/22/08
to strongtal...@googlegroups.com

> -----Original Message-----
> From: strongtal...@googlegroups.com
> [mailto:strongtal...@googlegroups.com]On Behalf Of Shaping
> Sent: Thursday, May 22, 2008 8:15 PM
> To: Strongtalk-general
> Subject: Re: Status of Strongtalk C++ code: VM stability and progress on
> a graphical debugger
>
>
>

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
>

J J

unread,
Jun 2, 2008, 9:12:16 AM6/2/08
to strongtal...@googlegroups.com
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.


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


Make every e-mail and IM count. Join the i’m Initiative from Microsoft.

David Griswold

unread,
Jun 2, 2008, 3:16:05 PM6/2/08
to strongtal...@googlegroups.com
-----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.
 
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

David Griswold

unread,
Jun 2, 2008, 3:36:35 PM6/2/08
to strongtal...@googlegroups.com
-----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.
 
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

Dave Griswold

unread,
Jun 2, 2008, 3:49:34 PM6/2/08
to Strongtalk-general
Sorry for the multiple replies, but for some reason the HTML
formatting of quoting indentation of my reply doesn't appear to be
showing up right in the posting as far as I can see on the web, so I'm
trying to get it right (if anyone knows why google groups does this,
or how to get google groups to send your own posts back to you so you
can see how they look, please let me know, since Google apparently
provides absolutely zero tech support for posting problems).

On Jun 2, 6:12 am, J J <azreal1...@hotmail.com> wrote:
> 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.

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


> Date: Wed, 14 May 2008 21:41:16 -0700
> From: gbra...@gmail.com
> To: strongtal...@googlegroups.com
> Subject: Re: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
>
> [...]

J J

unread,
Jun 2, 2008, 3:54:48 PM6/2/08
to strongtal...@googlegroups.com
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.

I understood that, I was simply pointing out that there is more to Erlang's model then just the "green threads".

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).

Well, given that Erlang was used to achieve an unfathomable 9 9's of reliability for phone switches, it would appear to work quite well for what people do in the real world. :)  It doesn't necessarily pass only "lightweight" values either, it can pass very complicated values.  The VM knows that if the data is passing from one OS thread to another, or even between 2 green threads in the same OS thread that no actual copying is needed, and other such sophistication.


 
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.

Yes, I point this out all the time, but most people tend to be stuck on the horrendous module that is so dominant today.



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.

Actually all Erlang "processes" are in the same heap and I believe that may even be the case across OS threads in the same VM instance.  Of course they can do this easier since variables can't be modified (i.e. no write contention on a variable).  But not allowing processes to share state also helps here.


None of these things have much to do with making the VM multithreaded.
 
-Dave
Well, it depends.  If people are bound and determined to feel like they are running on two CPUs at the same time then VM changes will be required, and it would be better to make the kind of changes that support a high level form of concurrency then chasing Java's (et al) tail.

Make every e-mail and IM count. Join the i’m Initiative from Microsoft.<BR



Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft.

beck...@googlemail.com

unread,
Jun 16, 2008, 4:11:34 PM6/16/08
to Strongtalk-general
Hi Gilad

>Erlang
> uses an actor model. Each actor (Process in Erlang) has its own thread of
> control, but they communicate only via asynchronous message passing. No
> state is shared among actors - only stateless values are passed among them.
> It's much easier and more natural to program with.

When I first came across objects (1990) this is exactly how I thought
objects worked.
Sending asynchronous messages to concurrent processes. This made sense
to me coming from a embedded
background where I was use to asynchronous queues and concurrent
processes. The when I looked into OO code (C++) I realised
that there weren't any messages, and everything was synchronous.
Reading Grady Booch
(Object Orientated Analysis and Design with Applications) convinced me
that I was wrong
and Bjarne Stroustrup was right. Objects have nothing to do with
messages, all you need is a vtable :)

It took the discovery of Smalltalk to realise that I was right about
messages, and the discovery of Erlang to realise
that I was right about concurrency too :)

Now I can't be the only one out there that has had this experience of
having to unlearn their own intuition.
Objects are intuitive, yet the popular form of OO and the concurrency
model in which it is used are both anti-intuitive.

If anyone can realise these simple intuitive ideas in a production
quality environment then I am sure it would
have wide spread appeal.
Paul.

(A long suffering Java programmer :))

Shaping

unread,
Jun 17, 2008, 2:01:13 AM6/17/08
to Strongtalk-general
I've been meaning to respond to this since first seeing it. (I've been
very busy learning about the VM and building a new box.)

I did some reading. Curl is very interesting. I very much want a
graphically rich web-client experience. Has anyone actually used Curl
and been able to observe something about its strengths and weaknesses?


Shaping
Reply all
Reply to author
Forward
0 new messages