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

Shaping <[email protected]> Sun, 18 May 2008 19:16:41 -0700 (PDT)
Newsgroups gmane.comp.lang.smalltalk.strongtalk
Message-ID <[email protected]>
On May 18, 7:05 pm, "Gilad Bracha" <[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.

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