Hi guys -

[Just caught up with Squeak mail and this thread]

Michael Haupt <mhaupt at gmail.com>  wrote...

>Hi Paul,
>
>On Feb 4, 2008 11:44 PM, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
>> As impressive as it was for Dan Ingalls to make that version of Squeak, and
>> then Pavel to decompile the result into source, so what? What is the license
>> of it all (either origins or decompiled version)?
>
>unclear. It's not officially released, there is no licensing statement.

I'm actually nearly done with this process.  I'm in a ridiculous discussion about the name.  I had proposed JSqueak and got "push-back", as they say, from the trademark folks.  It appears that, if I'm willing to call it 'Idaho' or 'Potato' or something, then we're good to go.  It's clear Sun is happy to let it go and I am too.

>(Isn't it a true nuisance that, instead of caring about software and
>complaining about and fixing bugs, we end up having to care about
>legal stuff and complaining about and fixing licensing issues these
>days?)
>
>> How well factored is it?
>
>It's very nice code, and nicely modularised into just 8 classes and 1
>interface: the Squeak interface defines constants. The Main and
>Starter classes are wrappers to get everything running. Then there are
>SqueakVM and SqueakPrimitiveHandler for execution, Screen and BitBlt
>for displaying, and SqueakImage and SqueakObject for representing
>living things.
>
>> Does it have nay hope to be supported by a community?
>
>See above. Since it's not officially released, it's a problem. I'd be
>in that community, for sure.

I will fix that problem.

> > Does it take advantage of the Java/JVM platform, including threading and multi-processor support?
>
>No; apart from garbage collection, it does not take advantage of the
>JVM platform.
>
>> Or interoperate easily back and forth with Java libraries like Jython can?
>
>That is not supported, but should be possible through primitives.
>Object conversion may be challenging, though.
>
>> Also, that version is (to my understanding) defining its own objects, not
>> using Java/JVM's objects, so there is a performances hit as well as other
>> layers of complexity and interoperability issues
>
>You are right there. Then again, the difference for objects is larger
>for Java and Squeak than for Java and Groovy - the latter's objects
>are deliberately Java objects, and the entire object model of Groovy
>has been designed with the Java object model in mind. SqueakOnJava is
>"just" a Squeak implementation on top of the JVM, with an approach as
>simple as possible.
>
>> To me, that example just shows again everything wrong with the Squeak
>> development process and why it is so frustrating to deal with it
>
>I really would not put it that way. I don't believe SqueakOnJava was
>intended to be the next big thing in Squeak progress; I rather believe
>it was a case study, or a feasibility study. In other words,
>SqueakOnJava, as I see it, is simply not part of the "Squeak
>development process" (whatever that may be).

Actually, it was neither:  I felt I needed to learn Java and the Java tools, so I picked the most fun thing I could think of to do.  I tried to make it really small and yet reasonably performant.  The simplicity should make it relatively easy to morph into something that integrates more closely with Java objects but that was not my focus.  It was more important to me to retain enumeration and mutation than to hook up to Java.

	- Dan