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