$5000 prize offered for port of Squeak to Strongtalk VM

[David.Gri...@gmail.com]

Everybody,

Dan Ingalls, founder of the Squeak project, has offered a $5000 prize
to the first person who can get a minimal port of Squeak going on the
Strongtalk VM by the end of 2006
-Dave

>Delivered-To: list-sq...@lists.squeakfoundation.org
>X-ORBL: [71.134.245.162]
>Date: Mon, 25 Sep 2006 14:43:48 -0700
>To: The general-purpose Squeak developers list
> <squea...@lists.squeakfoundation.org>
>From: Dan Ingalls <D...@squeakland.org>
>Subject: Re: Strongtalk VM for Squeak
>X-BeenThere: squea...@lists.squeakfoundation.org
>Reply-To: The general-purpose Squeak developers list
> <squea...@lists.squeakfoundation.org>
>List-Id: The general-purpose Squeak developers list
> <squeak-dev.lists.squeakfoundation.org>
>List-Unsubscribe: <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev>,
> <mailto:squeak-de...@lists.squeakfoundation.org?subject=unsubscribe>
>List-Archive: <http://lists.squeakfoundation.org/pipermail/squeak-dev>
>List-Post: <mailto:squea...@lists.squeakfoundation.org>
>List-Help: <mailto:squeak-de...@lists.squeakfoundation.org?subject=help>
>List-Subscribe: <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev>,
> <mailto:squeak-de...@lists.squeakfoundation.org?subject=subscribe>
>Sender: squeak-de...@lists.squeakfoundation.org
>
>Hi, Stef -
>
>>> Elimination of most global static state
>>> We keep talking about it but never doing it.
>
>Getting rid of Pools, and dropping metaclass instVars
>
>>> A mature Mixin system which is useful to compare with Traits.
>>
>>:)
>>Dan read the paper of TOPLAS on my web page. Traits are cooler :)
>>But we really got influenced by Strongtalk. We met Gilad before Strongtalk before it was public
>>and I was the nasty that launched this public gathering of signature to have strongtalk open-sourced ;)
>
>Thanks for your part, then. One or two other factors were critical as well ;-).
>
>>It would be great to see how we could run squeak on the strongtalk VM too.
>>Even if I do not know the impact of their mixin aware VM. May be traits could gain from that.
>>
>>Gilad told me that they were doing also clever copy down (only accessors would access state in strongtalk if
>>I understood correctly) so that copied down these methods on the mixin using classes ( since mixin has state and they could be
>>composed arbitrary and we could not garantee a linear order of ivs).
>
>I don't know if the VM is aware of the mixins. What I do know is that all access to inst vars is by messages, and this frees the system from worrying about how inst vars are ordered in a particular concrete class. In an ordinary VM this would add a substantial cost, but the inliner converts these to native access, so there is no extra overhead.
>
>>>And I'm thinking, what if there's some kind of opportunity for another run at the fence -- some sort of scheme that opened the door for Pearl, Python, Lisp, Ruby, JavaScript and Smalltalk all to vie for being, say, the core dynamic language around which most Internet software would be written...
>>>
>>>...Wouldn't it be cool if we could point not only to decades worth of cool media support, tutorials, games and development tools but also, a deployment engine that rivals the best in the industry.
>>
>>where should we sign for you to jump into it.
>
>I'm (over-) committed right now.
>
>>I think that it would be good to get some young blood there too. And we should really propose a Summertalk around that topic
>>next year (assuming that we will find a mentor willing to emails with a young smart guy).
>
>Next summer? !!
>
>Tell ya what...
>Here's $5000 that says "some smart guy" will do it before the end of 2006.
><lays money on table with a bottle of champagne on top>
> ;-)
>
>>>It appears that there is enough of a community around Strongtalk to at least get it running again regardless of what we do. But I felt (and thus the quote from before) that there was might be some low-hanging fruit worth reaching for, and that the result, independent of technical impact, would be to build the synergy of these two beautifully complementary communities, and thus strengthen the backbone of Smalltalk itself going forward.
>>
>>I agree!
>>
>>>The simplest project I had in mind (if I weren't already swamped (I know; we all are...)) was just to port Squeak's BitBlt to Strongtalk, fileIn all of Squeak (yes, this will take 206 tries ;-) make each native Strongtalk window into a Morphic project, and see how it all works. Ideally this could be done carefully and a "bridge" procedure developed so that when the next Strongtalk or the next Squeak is released, someone can fairly easily prepare a corresponding StrongSqueak release.
> >>
>>>Then there would be lots of fun stuff to do -- get speech and music going well, see how well Croquet runs with the fast float support.
>>>See how many primitives can be thrown away in the faster system, etc., etc.
>>>
>>>How hard would this be? I don't know. My guess is that this could all be done without even touching the VM, just by simulating a Morphic canvas in the Strongtalk world. A lot more fun than the Sunday puzzle page, at least.
>>
>>:)
>>
>>>
>>> - Dan

[Dave Newton]

Do we have a definition of what constitutes a "minimal port"?

Is this quote: "The simplest project I had in mind [..] was just to
port Squeak's BitBlt to Strongtalk, fileIn all of Squeak [...] make

each native Strongtalk window into a Morphic project, and see how it

all works." it?

Dave

[David Griswold]

You'd have to ask Dan (on squeak-dev, I assume). My guess would be that he
probably means enough to get the UI up and running, and add/change/run
methods (or at least doits).

I think the goal is to 1) get it running to the point where some significant
code in Squeak
can be benchmarked, which should generate some enthusiasm for finishing the
port and 2) getting
a better grip on exactly what else would be needed for a full port.
-Dave

[David Griswold]

Hi Andras,

Sorry it's taken me so long to review the changes you submitted to get Strongtalk to build under VS6.   Here are my comments:

I don't understand why you have changed the inline function declarations into non-inline definitions.   We want those to be inline functions since they are performance critical, very small operations.  The system seems to compile and run with only the following changes, as far as I can see:

• compiler\expr.hpp 36: need (?:) to return bool, rather than implicit conversion.
• runtime\debug.cpp 41: bug: MATERIALIZE_BOOLEAN_FLAG should be MATERIALIZE_INTEGER_FLAG.  This is an error in the original code.
• topIncludes\types.hpp 36: change so that bool is not redefined for VC++.
• recompiler\recompiler.hpp 48:  needRecompilerCounter must return bool; no return type declared; didn't match def. This is an error in the original code.
• code\inliningdb.cpp 739: file_out_all is declared to return a bool, which is wrong and doesn't match the decl of int.  This is an error in the original code.

Is there something I am not understanding?

Cheers,

Dave

[Josh Scholar]

David Griswold wrote:
> Hi Andras,
>
> Sorry it's taken me so long to review the changes you submitted to get
> Strongtalk to build under VS6. Here are my comments:
>

It's a bad idea to standardize to VS6 _now_.

VS6 is a very badly nonstandard version of C++ (with a weak template
implementation), it's no longer sold and it's expensive. Code written
to VS6 won't compile on newer versions of Visual Studio without
modification, nor on GNU nor on Intel etc. - all of which are much
closer to standard C++.

Visual Studio 2005 Express edition is free, and with some tweaking and
add-ons that Microsoft supplies for free has everything except visual
wizards and MFC for non-dot-net programs. I think its a paired down
version of VS8, though I don't know that much about VS8. It is a full
version of the optimizing compiler anyway.

If you want microsoft's debugger then I recommend standardizing to a
newer version of VS than 6, and the free one sounds like the ticket.

The other options I know of are:
1. MingW - but I think it's missing unicode support.
2. Cygwin - fairly complete, but a bit of a big complicated install.

[Mark Haniford]

Yeah, might as well get it compiling under VS2005 at this point in time.

[Josh Scholar]

One more thought, though.

If compiled C++ code has to work with a garbage collector, then I'm not
sure what compilers are acceptable. I've noticed that no one has ever
gotten VS8 working with the Bohm conservative collector.

[Josh Scholar]

Josh Scholar wrote:

> 2. Cygwin - fairly complete, but a bit of a big complicated install.

Though to be fair any Microsoft install is huge too. Especially if you
include the Plaform SDK, which I would include if only because it
includes all of the Windows developement documentation that Express is
missing.

It used to include fixed libraries and includes compared with VS6, but
it would be dumb if Microsoft is still shipping crippled includes in VS.

[Josh Scholar]

Josh Scholar wrote:
> Plaform SDK, ... used to include fixed libraries and includes compared with VS6

Which also reminds me that VS6 is useless without the many compiler bug
fixes that Microsoft was forced to come out with.

[David Griswold]

> -----Original Message-----
> From: strongtal...@googlegroups.com
> [mailto:strongtal...@googlegroups.com]On Behalf Of Josh Scholar
> Sent: Sunday, October 01, 2006 6:33 PM
> To: Strongtalk-general

> Subject: Re: Code Review
>
>
>
>
> David Griswold wrote:
> > Hi Andras,
> >
> > Sorry it's taken me so long to review the changes you submitted to get
> > Strongtalk to build under VS6. Here are my comments:
> >
>
> It's a bad idea to standardize to VS6 _now_.

I'm not doing it because I want to, but according to Andras it is the most
stable
version right now, hence the one I want to build the release from. Then
we'll
immediately move on, but I don't want to wait until it becomes stable with
the
latest compilers to do a binary release with matching source code.

[David Griswold]

> -----Original Message-----
> From: strongtal...@googlegroups.com
> [mailto:strongtal...@googlegroups.com]On Behalf Of Josh Scholar
> Sent: Sunday, October 01, 2006 6:40 PM
> To: Strongtalk-general
> Subject: Re: Code Review
>
>
>

The VM does not *use* a garbage collector. Compilation data
is written to a resource area that is just cleared after each compile, the
fastest way of all. The rest is just good C++.
-Dave

[David Griswold]

> -----Original Message-----
> From: strongtal...@googlegroups.com
> [mailto:strongtal...@googlegroups.com]On Behalf Of Josh Scholar
> Sent: Sunday, October 01, 2006 7:03 PM
> To: Strongtalk-general
> Subject: Re: Code Review
>

Thank you, that may explain some things.

-Dave

[Josh Scholar]

David Griswold wrote:

> Thank you, that may explain some things.
>

Well it's pretty common for programs to not compile without the
platform SDK (and without the include and library directories set to
the platform SDK).

Or vise versa, programs written to use the VS versions of functions
that changed in the headers (such as the Interlocked functions) won't
compile if the include directories are set to the platform SDK.

But if memory serves, most of the bug fixes in the compiler were to the
optimizer so without the bug fixes, at least the debug version of code
should work. There may have been some compiler crash bugs fixed as
well, though it's still possible to crash the compiler, even in the
final update.

More trivia, some crashes can be fixed by increasing memory that the
compiler gives itself.