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

Shaping,

On Sun, May 18, 2008 at 3:29 PM, Shaping <[email protected]> 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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---