• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Champagne Beadworks -- handcrafted jewelry and beadwork
• Crafted By Carol -- handcrafted jewelry and beadwork
• Dharm Atma Yoga -- Kundalini yoga instruction
• EcoReality, an organization devoted to establishing a sustainable ecovillage
• Ecovillage Newsletter -- Diana Leafe Christian's news of her travels.
• Environmental Education Outreach -- providing environmental education worldwide.
• Gemini Gypsy -- Carole Good-Hanson's fused glass frames
• Green Chipper -- light forestry and environmental services.
• Salt Spring Island Society for Community Education -- community education on our island of 10,000.
• Veggie Van Gogh -- two artists' mobile warehouse and living quarters, petroleum-free!
• Veggiemog -- life and times of Kelly O'Toole's Unimog, running on biodiesel

Preface

27 November 1995, the authors

The latest (but pre-merger) word we had on this product is that no new development is planned for it. We can only speculate that the PPS-Digitalk merger has made it even less likely that this product is a viable option for Mac Smalltalkers.

About ten years ago, a Smalltalk product called Methods was introduced for IBM PCs and clones. This product grew into the Smalltalk/V product family that now largely dominates the IBM compatible Smalltalk market.

Along the way, a specific need for a Macintosh product arose, and the first Smalltalk/V Mac was shipped in November 1988, built largely from acquired technology.

As corporate MIS departments discovered Smalltalk, and IBM itself endorsed it, more and more effort went into enhancing and refining Digitalk's IBM compatible line, while the Mac version went through only two minor "bugfix" update cycles, culminating in June 1991 with version 1.2, which sold for $199.95.

In 1992, Digitalk acquired Instantiations, a Smalltalk consulting company largely derived from the remains of the disbanded Tektronix Smalltalk product group. This Portland, Oregon based group brought extensive knowledge of both 680x0 Smalltalk virtual machine implementation and Smaltalk 80 virtual image internals.

It is not surprising that this flow of history should result in August 1993 with the first major upgrade of Smalltalk/V Mac since its introduction. Version 2.0, while overdue, is impressive: about three times the number of classes and methods are in 2.0 as were in 1.2. Although the price has increased by a similar factor to $495, it is probably still the least expensive commercial Smalltalk available today, and even more so if it is still available at the upgrade price af $195 in effect at the time this was written.

Part 1 of this series (in the November 1993 issue of The Smalltalk Report ) described a new and original Smalltalk implementation, SmalltalkAgents, from Quasar Knowledge Systems. (A brief update on their progress appears in this article.) Also available for the Mac is Visualworks\Smalltalk 80 from ParcPlaceSystems.

(For convenience, the three dialects will be referred to as STA, ST 80, and ST/V, respectively. Unless otherwise noted, use of "ST/V" refers only to the Mac 2.0 version, not the other products in the Digitalk stable.)

Highlights and Changes

Unfortunately, we must begin the feature list with an omission. There are no release notes or concise description of the differences between version 1.2 and 2.0. Those already familiar with ST/V will quickly spot major additions, but many small improvements -- and incompatibilities with version 1.2 -- await to be discovered. This makes it difficult to plan a port; it would be nice to know concisely what had changed, so that one could scope the porting effort.

Among a long list of long awaited features claimed by Digitalk for version 2.0 are: DAL/DAM SQL, 32 bit color QuickDrav, QuickTime, Balloon Help, and AppleEvents. We'll look at just a few new things in detail.

Window Inspector

There is a new specialized Inspector for windows available on the Window menu. This is a useful tool that many people end up building themselves -- we'd like to see in all dialects of Smalltalk. It eliminates the need to open many levels of Inspector to figure out what is going on in the application window you are developing.

Figure 1: a Class Hierarchy Browser and Window Inspector.

Class Hierarchy Browser

The Class Hierarchy Browser has a different arrangement of panes and buttons, but otherwise it appears to be similar to that in 1.2. One pane lists the local and inherited instance and class variables of the class. Selecting in this pane filters the methods list to accessors and setters of the variable. Clicking again on a list selection does not deselect it, so it is not obvious how to unfilter the methods list.

Find Class in the Classes pane now works with wildcards, but it is fussy. When searching for window classes, all of these tries (*wind*, *windo*, *window*, *window, and *Window) were rejected with the same message: "Please enter a more specific pattern." This was frustrating, and not very useful!

The access to the senders or implementors of a message in a selected method requires more menu actions in 2.0 than in 1.2. We found the extra steps annoying, and we disliked having to have an extra window open to get to the information we wanted. Developers with small screens will especially notice this difference, although ST/V is still more screen efficient than STA.

Text automatically word wraps in code panes. This feature is replaced by horizontal scroll bars for any window in which the user turns auto wrapping off. ST/V's non word wrapped heritage is irritatingly apparent -- method comments are formatted wider than the default window width, which makes for difficult reading.

Workspaces

Temporary variables are automatically generated for code written and executed in workspaces. (This is obviously part of the new Tektronix heritage -- wherever two or more former Tek Smalltalkers gather, they bemoan the lack of workspace variables!) Another improvement is that workspaces saved to a file and later reopened retain their text fonts and emphasis. Unfortunately, along with the improvements comes a large increase in the amount of time it takes to open a workspace from a file over that required in 1.2. This exceeds a 10:1 performance decrease in certain situations we encoundered.

Events -- A Roadmap

The classic Smalltalk "dependents changed/update" mechanism of user interaction is showing its age, and Smalltalk developers are clamoring for event driven operation. ST/V Mac 2.0 uses a strategy for change initiation and propagation that may be simpler to program than the classic dependency mechanism.

The advantage of true event handling is that polling of user interface components is hidden, ideally by direct use of operating system services. Rather than polling the state of input devices and locations in Smalltalk code, user actions and other system happenings spontaneously result in the evaluation of Smalltalk expressions.

Apparently, this is not quite the way ST/V operates -- it still has a single bottleneck Smalltalk Process that gathers and dispatches operating system events, so the differences tend to be syntactic rather than semantic.

Perhaps the worst way to try to attempt to understand the ST/V event dispatching is the way we initially tried. Merely browsing the code of Application and related classes does not quickly reveal how to use ST/V event dispatching effectively. This is the approach of those who are unused to having in depth documentation!

Those who are used to "changed/update" event dispatching may want to start with Tutorial Chapter 9, Windows, even if they normally do not "do" tutorials. Tutorial Chapter 10 also looks at building your application window and setting up events. Next, an examination of Application class in the Encyclopedia of Classes, combined with a reading of the Programming Reference chapters 6 (Building a User Interface) and 7 (Extending the User Interface Framework), will rapidly add to your understanding of setting up, triggering, and responding to events.

At this point, browsing the code of existing Application subclasses is fruitful. Eventually, the serious Smalltalker will want to memorize Appendix C, or at least make up a "cheat sheet" from it.

To maintain one paradigm between user initiated object change and other abject changes, ST/V "events" replace the generic update sent to all dependents of the object receiving changed . This somehow feels less object oriented -- previously, an object's dependents decided at run time if they were interested in that object's happenings, now the object must register for specific happenings, thus weakening the traditional model/UI division of responsibilities. ST/V makes this difference a bit less onerous for pre 2.0 applications by configuring an event and action when an application receives the addDependent: message, therefore providing some compatibility for many cases.

Are events, as implemented in ST/V, "A Good Thing?" They are undoubtedly valuable for capturing user actions, yet they can certainly be abused. We can't say that the result is easier to understand, debug, or maintain than the classic "changed/update" mechanism, and it may prove less flexible in complicated situations, but it is probably simpler to program in most situations.

Either way, the developer porting to 2.0 will not be able to ignore events, since they are firmly embedded in the application architecture. Perhaps some third party user interface builder will come to the rescue, providing more support for putting events in place.

Better documentation

There are three manuals: Tutorial, Programming Reference, and Encyclopedia of Classes, comprising about 2 1/2 times more material tan found in the 1.2 manual. We found the Encycopedia's methods index useful as a reference for standardizing selector names. The reference book is well written, and its Appendix C on Events is a valuable condensation of events information. Another nice section, especially for the beginner, is The Glossary, which defines most of the terms used throughout the documentation.

Finally (and perhaps most importantly), all of the methods we looked at had comments. A method on the class side called COMMENT is used to provide class comments. Although using a special method for class commentary is somewhat of a hack, the fact that there is commentary is an area in which ST/V beats both STA and more recent additions to ST 80.

Exception Handling

One reason some choose ST 80 is its flexible exception handling mechanism, since ST/V had none. Digitalk now has something similar to the PPS context unwind/marked method exception mechanism, but they made it somewhat easier to use, at the expense of being somewhat more difficult to create special cases. For example, both exception systems have a special purpose "do this thing, and then whatever happens, make sure to do this other thing" mechanism, since that is a useful way of releasing external resources, such as files. In ST 80, the mechanism involved "leaks through" into the method selector; you need to use the rather unwieldy method:

    [statement with possible error] valueNowOrOnUnwindDo:
        [statement that always executes]

ST/V uses the simpler, more intuitive:

    [statement with possible error] ensure:
        [statement that always executes]

Likewise, a block that is only executed when some other statement has a problem is invoked using valueOnUnwindDo: in ST 80, and ifCurtailed: in ST/V.

Like ST 80, ST/V also has a more general exception mechanism, using a block centered, class based approach, rather than the Signal centered, instance based approach pioneered in ST 80. For example, in ST 80:

    Number divideByZeroSignal
        handle: [:exception | exception return: 0]
        do: [x/y]

returns zero if y is zero, whereas in ST/V:

    [x/y]
        on: ZeroDivide
        do: [:exception | exception exit: 0]

does the same thing, using analagous components. ST/V is simpler to use in simple cases, but requires more work to set up new exceptions, since they must be coded as complete classes. In ST 80, new exceptions are very simply coded in the class protocol of objects that will be generating them, but are therefore not global, making the user of them work a bit more to protect a block of code.

A completely different approach is used in STA, which requires exceptions to be coded as compiler directives. This may be the easiest of all to use, but the STA exception mechanism was undocumented at the time of this review; this opinion is based on browsing examples in the STA image.

Support

Digitalk provides well regarded suport through their CompuServe forum. They announce all patches and bugfixes, and allow downloading to registered licensees. This again shows Digitalk's strong PC/clone bias -- a Mac user is more likely to be on America Online, AppleLink, or Usenet than CompuServe. We've seen grumblings in the Usenet Smalltalk newsgroup about CompuServe users getting more attention than Internet users.

For example, until we asked about the availability of patches, we had no way to know they existed. We were fortunate to have personal contacts among the team responsible for ST/V (special thanks to Pat Caudill, the ST/V Mac project leader), so we got good response when we inquired about bugfixes. However, we can't write from firsthand experience about general responsiveness of technical support for ordinary customers. We also do not know how the typical customer finds out about the availability of bugfixes, other than via CompuServe -- we have been licensed for ST/V Mac since 1990, and were only notified of major upgrades available for an additional fee.

Problems

After installation, we carefully write protected the image, so that we would not inadvertently change something that would affect a measurement. We then experienced repeated application crashes upon launching. This was extremely frustrating, until we discovered that you cannot run a write protected image.

In ST/V version 1.2, a notifier tells you this and lets you exit; in 2.0, it simply crashes into Macsbug. ST 80 happily runs a write protected image, allowing you to save to an alternative file name upon save; STA cryptically opens a standard file dialog, and when you choose the write protected image, it gracefully exits, without ever telling you why. We much prefer the ST 80 tactic, and wish other vendors would adopt it.

Other than the write protect incident, we experienced only one unexplained application crash. On attempting to resize a window on a 28k file, ST/V died with error #25 (dsMemFullErr, out of memory). On the other hand, we experienced numerous walk backs (with version 2.0) when trying things as reasonable as installing Digitalk supplied bugfix patches.

Patches, Patches

At the time this was written, there were two files of bugfixes and a new application and image, together known as version 2.0.2, available from Digitalk. Together they correct over 70 bugs, with about 25% of them classified as serious problems (walkbacks, methods silently misperformed, crashed application).

However, we could not get the patch installer to work by following the supplied README file. Bypassing the installer and manually filing in the patch files worked somewhat, but we also had to update the image's idea of which patches were installed, so that other files (such as the newly patched Compatibility.st) would file in. It took over an hour to install the patches, which seems unreasonable -- upgraders should get the new image and application, and not bother with the patches.

Later, we looked more closely at the installer problem. "Directory current," used by the installer, answered the top level directory, not the actual directory from which ST/V started. We moved our directory to the top level folder and the patch installer worked. Incidentally, one of the patches corrected this problem -- Digitalk's QA department must be using their prescient version of the patch installer!

Fortunately, version 2.0.2 is much more stable, and all the problems we recorded in 2.0 (except for the write protect crashes) appear to be solved.

Copy protection

Unlike STA, ST/V is not copy protected, and it can be moved between machines as allowed under US copyright "fair use" doctrine. (Our review copy did not come with a license, so we cannot say that this would fall within a strict reading of the Digitalk license, but at least it is possible.)

However, like STA (and other ST/V dialects), certain classes (such as the compiler) are protected, and they cannot be viewed, modified, or debugged. This is lamentable -- changing the compiler isn't something one should do every day, but having the option to do so may make some problems simpler. Those who are attracted by Smalltalk's reputation as an open system have ST 80 as their only alternative at this time.

Porting from 1.2 to 2.0

Digitalk describes 2.0 as "a top to bottom re write of Smalltalk/V for Macintosh," and like all things in life, this is both good news and bad news. We've tried to give an impression of the depth and breadth of the good news.

The news is not entirely happy for users who have to port their applications from 1.2 to 2.0. The lack of release notes means that the user has no first line of approach to discovering puzzles like removed or changed classes. (In comparison, Object Technology International lists each changed method in their release notes, greatly easing the porting task.)

Several developers we surveyed said the port of their 1.2 code was not simple. "I thought I knew ST/V Mac really well," said a developer who had been with ST/V Mac for three years, "but now I'm having to re learn a lot." The many new features are strongly desired in the developer community, but many were bewildered by the magnitude of the changes. A "Porting Guide" section in Digitalk's othewise fine documentation would go a long way to redress the lack of release notes.

Also, 1.2 contained a popular "goodie" called Application Browser that aided users in creating file out packages to rebuild their application in another image. Not only is this goodie missing in 2.0, but the global name Application is taken for an entirely different purpose, so all files made with the 1.2 Application Browser require editing before installing them in 2.0. Digitalk is experiencing customer pressure, and will probably replace the Application Browser in some form.

Measurements

The following table, which originated in last month's STA article, compares available Macintosh Smalltalk implementations. Readers should refer to that article for additional information on how we got our numbers. Changes since that article are underlined [951127-JWS: in parentheses in HTML port].

Since last month's article, we've added two measurements. In an attempt to include some idea of high level performance, we added a simple timing of how long it takes to open a window on a 28k styled text file. (Only STA and ST/V 2.0 displayed the text appropriately styled.) While this is not a particularly rigorous test, it tends to parallel the slopstone and smopstone benchmarks against STA and ST/V 1.2, although it counters to some extent the results against ST 80, which has sluggish linear read file performance, due to multiple buffering.

We also added a line for the application (vs image only) disk file size.

As we mentioned last month, low level benchmarks do not necessarily predict the performance you'll get. To paraphrase Mark Twain, there are "lies, damn lies, and benchmarks!" In particular, ST/V (and STA) is much closer to the Mac than is ST 80, so windows open faster and menus drop quicker than they do in ST 80's Mac emulation.

Most of the measurements of 2.0.2 are within 6% of those of 2.0. There are 503 new methods, which add 118k to the image size. This seems like quite a bit for two minor rev cycles, and indicates the youthfulness of the product.

The number of classes can be misleading, and does not necessarily correlate with quantity of functionality. Recall that ST/V has a class per exception type, while ST 80 has a method per exception type. Also, 181 classes -- nearly a third of the total -- have names that begin with "Mac", indicating functionality may be distributed among more classes in ST/V than in other Smalltalk dialects.

The first column for each implementation (the percent numbers) lists that implementation's measurement relative to the greatest in the group. In general, lower is better, although items such as "number of classes" are better the higher the number.

                        (STA 1.1b15)     ST/V 1.2     (ST/V 2.0.2)   ENVY/VisualWorks
start up time [1]       (33%) (16)       15%   7.3    (81%) (39)     100%   48
image save time [1]     (94%) (16)      (19%)  3.3   (100%)  17      (94%)  16
slopstone (no FPU) [2]  100%  (0.14)    (38%)  0.054  (32%) (0.045)  (26%)  0.037[4]
slopstone (FPU) [3]     (87%) (0.20)     30%   0.070  (26%) (0.059)  100%   0.23
smopstone (no FPU) [2]  100%  (0.19)    (24%)  0.046  (18%) (0.036)  (21%)  0.039[4]
smopstone (FPU) [3]    (100%) (0.27)    (22%)  0.060  (20%) (0.053)  (81%)  0.22
28k file window [1]     (35%) (1.8)     (35%) (1.8)   (84%) (4.3)   (100%) (5.1)[5]
required memory (k)      85%   3500      35%   1465    65%   2654    100%   4096
preferred memory (k)    (50%) (5000)     20%   1953    36%   3584    100%   10003
image size (k)          (56%) (2316)[6]  16%   669    (53%) (2191)   100%   4121
application size (k)    (96%) (492)[6]  (17%) (88)    (43%) (222)   (100%) (512)
number of classes [9]   (42%) (340)[8]   20%   165    (75%) (606)    100%   811[7]
number of methods [10]  (39%) (6685)     20%   3490   (62%) (10693)  100%   17268[7]

Table notes:

1. time in seconds, measured with a hand held stop watch, using a fast 11 mS disk.
2. Mac PowerBook Duo 210: 25 MHz 68030, 12 MB RAM, 80 MB disk, 1 bit LCD, System 7.1, no system extensions or power saving.
3. Mac IIci: 25 MHz 68030, 20 MB RAM, 32 kB cache, 80 MB and 1.2 GB disks, 1 bit internal video, System 7.1, no system extensions.
4. poor result possibly due to memory starvation -- could not obtain "preferred" memory, and had to settle for a mere 9560k. This result was disturbing, so we repeated it -- and gave up after two hours!
5. strongly correlated with file size -- ST 80 was actually as fast as ST/V 1.2 for very small files.
6. STA uses one file, image size is data fork size, application size is resource fork size.
7. includes ENVY, which adds 126 classes and 3213 methods.
8. fewer classes than previous version -- a number of demo classes appear to be "unbundled" in files, rather than be delivered in the image, although the method count is actually higher in this version.
9. obtained via "MetaClass allInstances size", which may include classes with hidden source code.
10. obtained via "CompiledMethod allInstances size", which may include methods with hidden source code.

Figure 2: "should I use it?" decision tree.

SmalltalkAgents Update

At article deadline time, we had just received STA version 1.1b15. Although nomenclated as a beta version, QKS assured us that short of crucial bugfixes, what we received is identical to what is shipping by late November as version 1.1. We've updated the measurements table with data from the new version.

The new measurements show that QKS has not been on vacation these two months. Essentially every measurement has improved in that time. The smopstones doubled in performance, while the preferred memory size was reduced 17% and the image plus application size went down 5%. Keep in mind that the removal of internal debugging code probably accounts for much of the size reduction, and possibly some of the speed improvement as well.

More important than the measurements is that STA 1.1b15 feels much more stable than the version 1.0.1 previously reviewed. We experienced no application crashes or debuggers while evaluating version 1.1b15.

Only speed and quality appear to have changed since we last described STA. The biggest omissions of version 1.0.1 still exist: no manual, no GUI builder, no crash recovery strategy, partially implemented inspector and debugger, non standard command key map, etc. STA remains a product with exciting potential, suitable for early adopters and pilot projects, but don't bet your business on it just yet.

Summary

Digitalk's Smalltalk/V Mac version 2.0 is an ambitious upgrade to version 1.2, and is a bargain, even at the full list price. Those with ongoing ST/V Mac projects should not hesitate to port to it, although such a port may not be trivial. Three times the quantity of code and eased access to the toolbox alone make it worth switching for ongoing development, and the addition of exception handling alone may be enough to justify a port of ongoing work.

However, three times the code potentially means three times the resource consumption. Those with completed ST/V applications may not want to port to 2.0 if RAM usage, disk size, and performance are utmost issues. Those who are supporting an existing application that must work nicely on an old Plus or Classic might consider staying with 1.2.

Those considering new development need to ask a number of questions before settling on ST/V. Are you willing to watch CompuServe for the inevitable patches and bugfixes that come with a young product? Do you need the utmost performance? Are you already comfortable with another vendor's product? Will you be working with a team? Do you need to work on multiple platforms? None of these questions alone may rule out ST/V, but if many of them are issues, a different vendor's Smalltalk may be appropriate for you.

Related product reviews: go to the previous column in the series, which describes Quasar Knowledge Systems SmalltalkAgents, or go to a previous product review we did on ENVY/Developer.