Bits Of History

as revived by Dan and Helge

Have fun.

Let me try with my Browser's built-in Java...

Let me try with my Browser's JavaPlugin...

Show me the license to hand me the Jar for offline use...

last update: 16. September 2004 (version a9, see below)

Usage Notes

Please let it boot fully. It loads and compiles the system methods from a source file in the jar. Let it do its thing, then breathe again.
On the Mac, the command shortcut key is COMMAND in the application, but CONTROL in the applet. (Safari seems to "capture" the COMMAND key.) WinXP will use CONTROL in both application and applet.
Browsers can currently only be opened from the desktop popup menu (control-click on Macs, right-click on Windows). Inspectors can currently only be opened on "Inspect it" requests. The UI is not accessible from the Smalltalk side.
There is no "save." There is no notion of a "system image", nor can the applet file out methods. The applet (un-signed as it is) doesn't even put stuff on the system clipboard. So feel free to muck around in the applet, but grab the jar to be able to load files from your favourite Unicode-capable (i.e. UTF8-generating) text editor. The application can file out methods of a class (from the browser tool's class pane, press command-S) to the current directory.
Code entered in a Browser tool will be autoconverted (on accept) from Ersatz-Alto ASCII to Unicode: ^ to up-arrow, ? to implication, ` (backquote) to unary-minus, _ to left-arrow, ! to index-bullet, # to pointing-hand and @ to dotted-box. Open-colon is entered and displayed as a percent sign %. Some special characters don't have an ASCII equivalent, so if you need greater-or-equal, less-or-equal, not-equal, identical, peekFor (the eyeball, see class Stream) and you're not using a Mac, you'll have to copy/paste these characters from some existing method. The classes Integer and Stream are good places to dig.
When the dreaded red Stepper appears, try the help command. The Stepper is a command-driven bytecode-level debugger. If the cause displayed is just a "MessageNotUnderstood", you can check the call chain with the where command, and then cancel the whole evaluation thread with the qq command. The receiver command may be of limited use, as it would display the receiver of the calling context -- the failing receiver can be determined by displaying the stack frame using frame, and looking at the top of the stack, marked with an asterisk *. Only the terminally curious would also try dis.
Loading code: Both application and applet can load from the jar, given Host load: 'jar:/source/file.utf.txt'. The Application can also load from the file system, just evaluate Host load: 'path/file.utf.txt'. Recommended code text encoding for files is UTF-8 (extension .utf.txt). Both application and applet can also load code from HTML pages via http, given Host load: 'http:/someserver/foo/bar.html'. Everything in <PRE> tags will be evaluated, anything else will be ignored. Note however that the applet won't be able to contact servers other than the one it "came from." (Sample page: signum.html)
The Application will, on startup, automagically load a file named autoload.utf.txt (if present) from current directory, while the Applet understands a single <PARAM name="load" value="jar:/path/somefile.utf.txt">.

Customization Notes

The "Welcome" window contents are loaded from the jar (/source/welcome.rtf).
Preferences allow customization of fonts and colors: The defaults are in the jar, in the file st76.ini. Please review that file for preference names and value formats. The applet understands a single <PARAM name="prefs" value="name=value;..."> to override the jar's defaults selectively. The application will instead look for files .st76.ini or st76.ini in that order, taking the first found. It will look for these files in the home directory, then in the current directory, and will load from both locations in that order.

Known Bugs

There is no source-level debugger.
It's rather unfinished. So is the Java source code. I'd rather publish it when it has reached a "presentable" state. Since this is a hobby project, I beg your patience. For the moment, please enjoy the little toy as it is.
The browser tool does not refresh the class pane when new classes have been loaded. Please close the outdated one, and open a new one from the desktop popup menu.
Some methods in the system may be of historical interest, but they certainly don't work as expected in the simulated system. For example, Methods originally weren't members of class Method but Strings, with the literal OOPs encoded after the header. Thus Context>>litof: is misleading. There are also no reference counts at all, so Object>>refct and Dictionary>>clean are misleading, too. And it can't enumerate #allInstances, even if the original could.
Some browser's Java runtime environments seemingly tend to wedge over time. (Could well be my fault, no accusation intended.) The browser then refuses to load the same applet that loaded perfectly (well, almost) two minutes ago, occasionally complaining about spurious missing methods during bootstrap. Sometimes it helps to reload the page, other times, the browser must be quit and fired up again. Once in a while, a browser may spontaneously decide to quit. Ouch.
Dazed and confused: Cross-browser, cross-platform applet popup menu handling seems to be a mess. Works okay in the Application. For the Applet, popups may be used as a command key reference. If at all. We need help: Is there a workaround? (Funny enough, FireFox on WinXP seems to provide the most consistent appearance there.)

Release Notes version a9, 16sep04

Less disturbing error notification: notifier windows tell error cause and simple backtrace (instead of entering the Stepper window)
Enhanced stability and less flicker in Transcript output; it also scrolls to its last output now
HasGUI and IsApplet boolean globals preset by the runtime engine, depending on how it was started; the st76.tools.Exec command-line script executor uses them to suppress boot messages (so the shell tool doesn't talk so much...)
If the first line of a script file starts with #!, that line is skipped (to allow for executable magic in Un*x, as in #!/usr/bin/env st76, with st76 defined along the lines of java -cp st76aN.jar st76.tools.Exec $*)
Turtle>>turnto: added to gfx.utf.txt
postboot.utf.txt fixes omissions and allows access to Method bytecodes, literals, Context top-of-stack etc. Used in Smalltalk-level error reporting, the text in a MessageNotUnderstood notifier is actually created in Object>>error.

Release Notes version a8, 08sep04

Added preferences as described in the Customization Notes above.
The Browser tool has finally settled upon "Serif" as its font. In fact, Workspace have changed along. That font should provide all necessary glyphs across platforms. Sorry for the previous mess.
A handy rejar.sh script has been added to the jar to allow easy repackaging after unpacking (which seems easy enough with jar xf st76a8.jar) and customizing.
Finally seems to work okay on WinXP with IE6. (non-SP2'ed machine, Sun JRE 1.4.2)

Previous Release Notes

added Color wheel support (with alpha) to Turtle
added Method class with accessors for introspection
fixed Undeclared handling and redeclaration of globals (Smalltalk define: #Foo as: 3+4).
fixed Turtle>>north to not point southwards. :-)
added over command to Stepper, to step over sends.

Contact

Please mention "Smalltalk-76" or "Smalltalk76" somewhere in the subject.