>But, if you had the time, I'd sure be happy to learn more about any unusual
>aspects of the general architecture if you can describe it simply. As a
>simple answer to that, is it still organized as Michael outlined: "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."

Yes, still so organized -- I haven't touched it since 2006.

>And how many pages or lines of Java code (roughly) did that turn out to be?

Evaluating:
  | dir s | dir _ FileDirectory on: 
'/Users/danielingalls/Desktop/SqueakOnJava/src'.
dir fileNames do: [:n | s _ (dir fileNamed: n) contents.
	Transcript cr; nextPutAll: n; space; print: (s asBag 
occurrencesOf: Character lf); endEntry]
prints...
BitBlt.java 897
Main.java 31
Screen.java 380
Squeak.java 125
SqueakImage.java 360
SqueakObject.java 300
SqueakPrimitiveHandler.java 1680
SqueakVM.java 1704
Starter.java 55
... so it's about 5000 lines of code counting comments (and there are some ;-).

>And also, did you write a Smalltalk->Java translator to make the VM or did
>you code it by hand?

I wrote it by hand because (a) I was trying to learn Java, and (b) I 
wanted to use
Java storage management.

>I'd be curious about anything you could say about the license of the Java
>part (or Smalltalk->Java translator). X/MIT? Squeak? Other (Sun's Java or
>GPL+Exception)? (Even LGPL is fine with me, by the way, as I expect to be
>using that if I draw from GNU/Smalltalk for the core.) Though I know until
>its formally released maybe you can't make promises as to license, so feel
>free to not answer that. Still, I would expect that those classes would all
>be very useful in whatever implementation anyone worked on for the JVM.

It's an MIT license.

>These questions would all take longer to answer, or might have proprietary
>or personal answers, so feel free to skip them. In general, it would be nice
>to learn what parts were hardest to do or where you had to write a lot more
>Java code than expected (or even, what parts were surprisingly easy).

A lot of the code just looks like the C that comes out of our C translation.
I would have just made a Java translator, except for the adaptation to
Java objects.

>Although perhaps that would be too specific to you to know if it applies to
>any such effort? It would be nice to get a general impression of how many
>Squeak classes it has (if different form a standard image), how it performs
>relative to Squeak in C on the same hardware, or what parts of the Squeak VM
>the JVM struggles with (if you profiled it), or if it exposed any (publicly
>known) JVM problems or weaknesses any such effort might encounter.

I had as a goal to run the Mini2.1 image, period. You can fire it up
and get all the stats.  It's about 600k (320k gzipped), it has 202 classes,
and 4592 methods that decompile to 856k of source (more than the image
size itself -- I always used to kid that it was like source code compression
with an integrated development environment thrown in for free ;-).

>I'd like
>to learn if it involved refactoring or changing any of the Squeak core
>classes (or if you just used essentially a release image or something
>similar). It would be nice to know what version(s) of Squeak you drew from.

Mini2.1 period.

By the way, if the stars are lined up right, you can just click on...

	<http://Weather-Dimensions.com/Dan/ForwardToThePast.jnlp>http://Weather-Dimensions.com/Dan/ForwardToThePast.jnlp

[It will run your cpu full throttle because I never bothered to figure out
how to yield to the OS  That would be a big help]

>It would be nice to know if newer JVMs (like six or seven) make it perform a
>lot better.

I can't tell you.  I just run what's on my Mac.  I get
	16088486 bytecodes/sec; 928210 sends/sec
where the Squeak VM gets
	539515279 bytecodes/sec; 12461126 sends/sec
or  between 10 and 30 times slower than C.

But you can't take this as an indication of Java versus C because the
whole object memory is simulated.  If you look at bitBlt performance
which is pretty comparable code, they're just about equal (believe it or not).

>Also, compared to the C, it would be nice to know if you though
>the Java code seemed as beautiful or elegant?

Well, look at the size.  It was very nice not to have to write a 
garbage collector,
and enumeration and become together are only a page of code.

>Did you find the tools as
>reasonable as ones for C?

Huh?  I've never used C.  Ha ha.  Got ya there.
The only C tool I've ever used is the C translator

>I'd be curious what setup you used to develop and
>test it too, just out of curiosity (Eclipse, Sun's tools? Other?).

I used Sun's NetBeans.  It seemed PC, and a useful reality check.

>Does the
>system feel stable to you (that is, relatively to Squeak on a VM in C)? Or
>anything else related to an overview to get everyone even more tempted. :-)

Yes, it's stable, but very untested.  I'd say it needs a month or two 
to complete it
and maybe another month to work up a decent synergy with Java.

>Essentially, anything non-proprietary you might want to later put in a
>lengthy "readme" file or an informative pre-announcement is what I would
>love to know right now. Or a pointer to such if it already exists on the
>public web. :-)

You wanted to know about the object format.  Here it is...

public class SqueakObject {//Later make variants for common formats
     short hash;        //12-bit Squeak hash
     short format;      // 4-bit Squeak format
     Object sqClass;  //squeak class
     Object[] pointers; //pointer fields; fixed as well as indexable
     Object bits;       //indexable binary data (bytes or ints)

The only other tricks are that I use a weak object table to
support enumeration and become, and I use boxed integers
throughout, keeping the common ones in a table for quick creation
and to avoid needing to reclaim them (they are shared).

>This is unrelated, but as long as I'm asking, :-) feel free to say no
>comment, I'd be curious if you were involved or in touch at all with Sun's
>effort to make the JVM have better support for dynamic languages (like JRuby
>or Jython, or, hopefully, a Squeak/JVM. :-) No Smalltalkers listed here,
>sadly, but it was years ago:
>   "Sun warms to Dynamic Languages: Summit Held" (Dec. 2004)
>   http://www.theserverside.com/news/thread.tss?thread_id=30462
>That's just to get a sense of how much the JVM might (in theory) continue to
>improve in a Smalltalk-ish direction if there was an actively used Smalltalk
>on the JVM and someone there who cared about it.

I've left this up to their own technical and marketing decisions.
If they wanted to take this project farther I would certainly help them
to get started.

	- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080209/d62bff40/attachment.htm