View this PageEdit this PageLock this PageReferences to this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide

Stable Squeak/Squeak World Tour

Intro

As there has been a lot of discussion about forking Squeak, making it more modular, document it better, make it more suitable as a base for developing applications, etc. etc. on the Squeak mailing list and also a few doubts raised about the ongoing Stable Squeak effort, I thought that an article on Stable Squeak might bring some more facts and insight
into the discussion.

Also check out the Squeak Stable World Tour page: http://swiki.squeakfoundation.org/stablesqueak
NOTE: This article is primarily written for Squeak developers, but it might be interesting to Smalltalkers in general or even other developers!


Background

I have been in contact with Paul McDonough, now at ReThink, regarding my SoonToBeReleasedAnyDayNowSqueakCVSProtocolImplementation - sqcvs part of CVST - and things led to this and that and finally I met up with Joseph Pelrine here in Stockholm for a demo of Stable Squeak, especially the new semantic code model which is his main contribution. We spiced the meeting with some discussion on Stable Squeak and Squeak in general, all finished off with raw fish and beer at the local sushi place.

My intentions with this article is to present Stable Squeak as-is, pose hopefully creative questions about it and encourage other people to speak up and join the debate IN A SQUEAKY CIVIL MANNER. :-)

So... wherever I have placed questions in bold in this article - please - fill in any suitable answer directly! But do include your name. The rest of the debate will probably be found on the Squeak mailinglist. ;-)


Stable Squeak/Squeak World Tour

I think Stable Squeak/Squeak World Tour was "born" 17th July 2000. See http://www.smalltalkconsulting.com/html/CampSmalltalk2d3.html - as witnessed by John McIntosh at CampSmalltalk. See interview with John Sarkela for more details later in this article.

John Sarkela has been the organizer but there has been contributions from quite a lot of people. Currently I think that John Sarkela, Andres Valloud, Joseph Pelrine and Paul McDonough are perhaps the most active developers in the project (see interview below for a few more names). The homepage for the project would be http://wiki.cs.uiuc.edu/CampSmalltalk/Squeak+World+Tour but it isn't very active right now. I have learned that this is not because of lack of progress - more on that later.


Setup

So, I downloaded a Stuffit archive with a decently recent version of Stable Squeak (a prerelease) onto my Windows98 machine (ok, my girlfriend needs to run a few programs and she doesn't really appreciate Debian the way I do...).

Unpacked a whole bunch of files that jumps out telling me No sir, this is not vapourware! :-)

A Readme.txt tells me to use a 2.8 VM but notes that a newer VM probably works too. The base image is 2.8 Mb. Oh, that sends warm fuzzy feelings down my spine. I first started the image using a 2.8 VM as instructed, then used a 3.0 VM. For basic exploring both seemed to work just fine. Let's check it out.


First impression

The image starts up in Morphic but with a new nice look. I don't really think that original Squeak looks so bad out of the box - I could even stretch to say that I like it, but it does have a sortof "childish" feel and I can easily understand how first timers could mistake Squeak for being "merely" a toy.

There are no other projects living in the base image, there is only one single instance of Project from the start. The only thing visible on the blue desktop is a "Script Manager", a sort of Workspace organizer with folders on the left and scripts on the right. Here we have it showing an overview on what Stable Squeak is all about:

Uploaded Image:overview.gif


A nice and simple idea reducing all those Workspace windows into one. An addition by Joseph Pelrine by the way. Thanks Joseph! I also like the minimalistic desktop, no other open windows, no flaps as default.

Nosing around in the Script Manager tells us that the new look for Morphic is courtesy of Torsten Bergmann and the new MVC look is from Stefan Matthias Aust - you can see all credits here:

Uploaded Image:credits.gif


Spawned a quick new MVC project, and checked out the look there. Looks like a minimalistic OpenLook/Motif-crossover with slightly transparent menus. Very soberly grey, yes, I think I like that too. Here is the good old browser in MVC:

Uploaded Image:mvcbrowser.gif


I also noticed that the mouse pointer now has new icons when resizing windows, looks almost identical to Win32 resizers in morphic, definitely better than the yellow ball. In MVC they are "corners" like those often used in X window managers I believe.

The available menus "on the desktop" seem to be more or less identical to Disney Squeak. There are some new tool choices but that is probably all. I would guess that those having worked on Stable Squeak do not want to change things that does not really need to change - remember, Stable Squeak is meant to be merged back into Disney Squeak hopefully in the end producing a new better and unified Squeak.

Note though that there are a bunch of new browser tools being worked on, especially for the new semantic model from Joseph.


Fonts

Tada, there are new fonts. The default system font looks ok to me, looks Mac-ish but it doesn't really matter how it looks - it is covered by a better license! The font size summary tells us there are 10 different fonts in a total of 25 sizes. The default font seems to be 12pts Accushi. Of the others 2 are symbol fonts so we have 8 different text fonts. Very nice.

I did some screenshots of the fonts - take a look if you are interested.


Bam, memory low, my fault

During my first stumblings I noted that very large windows being moved around on the screen caused a low memory crash. Well, it did not crash first, there where debugger, notifiers and emergency evaluators etc. etc., but I couldn't get it to recover.

So I used a "-memory: 64" to start it up and then did some simple tests to see if it was the windows dragging that in fact was erroneously eating memory, but that was of course not the case.

Since this image starts in 32 bits of display depth I assume the default allocated memory for the VM was just too small, beware!


Menus and tools

Tried opening a few new tools like the module manager or the refactoring browser but got a nice little dialog telling me they are not loaded.

help->graphical imports gave me my first debugger. I was just trying out menus for no special reason.

Uploaded Image:graphicalimports.gif


A short investigation shows that #viewImageImports is no longer implemented by SystemDictionary. Then I tried help->standard graphics library and got another one.

Uploaded Image:standardgraphicslibrary.gif


Well, life on the edge! :-)

Having read earlier about the problems of "hooking up" different loadable tools in all the menus I remembered a proposal from Stephane Ducasse involving a singleton ToolsManager.

http://macos.tuwien.ac.at:9009/776242636.asHtml.full

The mechanism he describes of registering tools in the menus depending on what modules are loaded is not in place yet I presume. Or these things have not been hooked up to it.

QUESTION: What is the status on the ToolsManager idea/code etc. proposed by Stephane?


Unit tests all over the place

This is good. This is actually very good. There are a LOT of unit tests here. About a lot. I think most of you agree with me that this must be essential for a project like Stable Squeak - if not for any project. There should actually in time exist tests for whole Squeak IMHO. Obviously Stable Squeak adhers to the XP style of development.

Joseph was Kent Beck's assistant for a while - so it seemed natural to him to do the Stable Squeak stuff XP-style. He's really trying to convince others to prove that they do high-quality development by shipping their tests with their tools - sort of a macho, "I write good code, and here's the tests to prove it" type of mentality, in his own words. ;-)

Joseph told me he had yet to see any tools posted to the Squeak mailing list with the tests attached. Ehrm, shame on us all...

QUESTION: BTW - why aren't there more XP influences being seen in Squeakland? Or rather, why hasn't the use of SUnit caught on more?


Base image

Let's take a look in the current base image (without any loaded modules) using the standard browser. Kernel, Collections, Graphics, Tools, System, ST80, Morphic and Balloon. Notes that there is no Ballon3D nor Networking. This reminded me of someone the other day arguing about bloat in the form of Scamper and Celeste - and they are of course not here! And PWS is gone and no Sockets. So, no networking stuff at all! Interesting.

So a lot of stuff has been removed (of course turned into modules) and this is IMHO very good. It must be easier to do this kind of massive cleanup by starting from the bottom and then load these modules one by one.

Checking back in the ScriptManager we can see some more info on how Stable Squeak has evolved:

Uploaded Image:1stexperiment.gif


SessionManager and UIs

But what's new then? Well, we have a SessionManager in a new category. One thing I always do when looking at unfamiliar code is to check for the class comment and behold - there is one!

"The purpose of the SessionManager is to model execution environment of a running Squeak session. Currently it manages the loaded modules and ensures the execution of initializers in the order of module load. In the near future it is hoped that it will hold onto the current instance of the user interface builder (e.g. MVC, Morphic, text based...)."

After taking a closer look I find that the "near future" is NOW! We do have a single instance living in the image being held as a Singleton on the class side of SessionManager and it holds no modules but has a uiBuilder.

This gets more and more interesting. Followers of Stable Squeak probably are aware of the inclusion of a new framework for building user interfaces. It works something like this:


Uploaded Image:inspectorxml.gif



Uploaded Image:xmlviewspecparser.gif



Uploaded Image:windowuispec.gif


The neatness of this shines through when you realize that the Spec classes are coded to be independent from the user interface framework. They do handle all the logic of glueing together the model and the user interface objects, but they do not handle the actual creation of user interface objects. That is delegated to the builder.

So it all boils down to methods being called in the builder that really instantiates something concrete. And as you may have guessed we currently have two UI builders - one for MVC and one for Morphic. If we inspect the singleton SessionManager and explore the uiBuilder we find a so called ComposedUIBuilder. A ComposedUiBuilder seems to be a "smart builder" using whichever of it's children to actually do the building depending on which UI framework is active:

Uploaded Image:uibuilders.gif


So the same XML description can produce user interfaces for both frameworks. Neato.

Note: I recognize this stuff from my VisualWorks days and talked with a collegue who knows a lot about it. On my verbal description he thought it sounded more or less exactly like in VW, apart from the use of XML.

QUESTION: Are there any significant differences compared to VW besides the use of XML?

I tried to tweak one of the XML specifications just to see if these things are "live" today - renamed the "instance" button to "instnce" - and sure, it changed in the next browser I opened up.

This seems to give us great flexibility and opens up new possibilities. It will be much easier to keep MVC alive and also develop other user interface frameworks within Squeak. I would also guess that one of the most obvious routes here is to use this with other external UI frameworks like Qt, Gtk+, wxWindows, Win32 and so on.

One remark though: The "Spec hierarchy" below looks a little strange to me.


ProtoObject #()

	Object #()

		NonVisualSpec #('client')

			FrameSpec #('leftFraction' 'topFraction' 'rightFraction' 'bottomFraction')

			PluginUiSpec #()

			VisualUiSpec #()

				ComponentUiSpec #('widgets')

					WindowUiSpec #('title' 'initialExtent')

				WidgetUiSpec #('frame' 'model')

					ButtonUiSpec #('label' 'state' 'action')

					ListUiSpec #('list' 'index' 'setIndex' 'menu' 'keyPress')

					PanelUiSpec #('widgets')

					TextUiSpec #('text' 'setText' 'selection' 'menu')

			WidgetListUiSpec #('widgets')

			XMLSpec #()


Perhaps we could apply some patterns here, the Composite pattern does not seem to have been applied (?) for example - I mean, wouldn't this version look better:


ProtoObject #()

	Object #()

		UiSpec #('client')

			FrameSpec #('leftFraction' 'topFraction' 'rightFraction' 'bottomFraction')

			PluginUiSpec #()

			VisualUiSpec #()

				ComponentUiSpec #()

					ContainerUiSpec #('components')

						WindowUiSpec #('title' 'initialExtent')

						PanelUiSpec #()

					WidgetUiSpec #('frame' 'model')

						ButtonUiSpec #('label' 'state' 'action')

						ListUiSpec #('list' 'index' 'setIndex' 'menu' 'keyPress')

						TextUiSpec #('text' 'setText' 'selection' 'menu')

I started by renaming NonVisualSpec to UiSpec. I like to be able to say that "subclass IS A superclass" and "a VisualUiSpec is a NonVisualSpec" did not sound right. :-)

Then I put ComponentUiSpec below VisualUiSpec, "something that can be part of a composition/contained in a container". The abstract "Composite" subclass is ContainerUiSpec with two concrete container-classes, window and panel. The widgets are (at least sofar) not capable of having children so they are merely components.

Note: In morphic all morphs can have children but that is another story...

I have not looked into the classes themselves so I might be rambling on about something I do not understand... But hey, it is so very easy to be "smart" when you don't really code it! The current stuff works too!


Various small things



Net presence

So what kind of "net presence" does Stable Squeak have? Well, searching with Google finds mostly mailing list stuff, Stephane's homepage, links into WellThot's Swiki which appears to be down.

We have the official pages on the CampSmalltalk wiki, but they are not really vibrant. Obviously this is an area that Stable Squeak needs help with and this article is a first step.

Interesting hits in Google:


Interview with John Sarkela

When writing this article I soon realized that there are a lot of thoughts that can simply not be found in the image. :-) Therefore I mailed John Sarkela a bunch of questions and here are the answers (my questions are in bold):

How come you started the Squeak World Tour/Stable Squeak effort?
In the summer of 2000 during the short summer session at the University of Illinois, Ralph Johnson offered an OO design course based upon XP and Squeak. The short session runs for 4 weeks of 8 hour days. I volunteered to play the role of Customer. The end result of the effort was something the class called ObjectWeb. (If I recall, only two class members had any Smalltalk experience.) It was a pretty cool morph based wiki like thingy.

Surprisingly, one of the most difficult tasks was removing functionality. Also, the image showed the consequences of not have been through a phase that just focused on refactoring existing functionality to make the code easier to reuse and reconfigure. We talked at that point about a Camp Smalltalk like effort or offshoot to focus on refactoring the Squeak image.

A few weeks later I was talking with Ralph at the XP 2000 conference in the hotel lobby when in stormed Dave Thomas (The OTI guy, not the hamburger guy.) We put our heads together and the basics of the Squeak World Tour were thus formed.

Who are currently actively working on Stable Squeak?
The flip answer is everybody, but only a select few know it yet. Some key contributors (in no particular order) on the first release are Andres Valloud, Paul McDonough, Joseph Pelrine, Luciano Notarfrancesco, Stephane Ducasse, Roel Wuyts, Craig Latta, Tim Rowledge, Rob Withers, Duane Maxwell, Henrik Gedenryd. Many other people have contributed code and much code was lifted from the Squeak list. A more comprehensive list will be part of the release... my short term memory is definitely not to be trusted. ;-}>

This particular crew consists of people who were able to attend a Squeak World Tour event or are physically close. In an open source effort, it is a delicate proposition to decide precisely when to have a "first" release. It was necessary to reach a point that we could define a "base" release before opening to the public in general. Much of the person power of the first group is to set a mechanism in place to help us track and assimilate the various contributions of future developers.

How do you think the progress has been sofar? The first time estimates for Stable Squeak have been passed a long time ago - is Stable Squeak suffering a bit from "featuritis"?
I believe that things are progressing well. In this early phase, Squeak World Tour needed to forge a clear identity. Also, the fact that no one is getting paid to do this, makes it difficult to schedule when and how things get done. However, you make a good point. Our charter should be to reengineer existing functionality, not add new features. In practice, it was necessary to add new capabilities because they enable necessary refactorings further down the road.

Looking at the stated 6 goals in the overview (as seen in the ScriptManager), what are their status today?
  1. Define a minimal base development image.
We have a development image with MVC & Morphic and all the dev tools that comes in under 2.6 Megabytes. If you drop Morphic, the image size drops to 1.6M. With the tools we are building, subsequent releases should let us refine this base more carefully.

  1. Refine ANSI and Camp Smalltalk conformance.
The image now has ANSI conformant Streams and Collections. This is verified through the use of SUnit tests.

  1. Remove font licensing issues from the image.
Done. The only fonts found in the base image are the Accu fonts for which Doug Easterbrook has issued a special license for use in Squeak.

  1. Support emerging standards.
The base has better ANSI support. XML is being widely used when an external representation is required. For example, XML based view specifications, XML based language-independent object serialization. And of course, by embracing Camp Smalltalk code, we have a base of portable Smalltalk code against which to measure our success.

  1. Repackage base Squeak functionality in revisioned modules.
We have defined a repository interface. We have defined a module mechanism that is as simple and complete as we could make it. Our hope is to eventually support moving code to/from VW Store packages, Dolphin packages, Envy applications, OASIS modules, etc.

The availability of actually creating revisions from the base tools will probably have to wait for a subsequent release. At the present, it is possible to define a modular breakdown of the existing image.

  1. Create a true kernel image that loads required program functionality on startup.
This goal is further down the road. We need to stabilize a base dev image first, so that folks who are more interested in packaging functionality that was removed from the base may get on with their tasks. With modules in place, we can leave the factoring of a micro-kernel for those folks who care about such things.

Do you have any idea about the timeschedule for Stable Squeak the rest of this year?
The next scheduled location is ESUG 2001 in Essen, Germany at the end of August. Once we have loadable modules in a repository, we can have a more continuous release process. This first release had a long gestation as it sought its form. The second should be a maintenance release that gives us more power to track our changes. After this, we should be able to much more open and responsive.

Is there a definitive decision on folding back Stable Squeak into regular Squeak or is a fork possible? What have the reactions from Disney been on this issue?
The reality of Smalltalk development, is that every time an image is saved, the code base has forked. Period. Our goal is to foster evolution of Squeak by paying attention to mundane capabilities that enable us to characterize the software elements of any image. After all, variation is the means of evolution. To be able to cross fertilize our development efforts, we need a means to separate our individual developments from the base image... so that our developments may be more easily shared between images.

SUnit tests form the first test of image component compatibility. Modules form the second test of compatibility. It is inevitable that this will lead to two co-evolving images. The more feature poor Squeak World Tour image and the more feature rich Squeak Central image.

I have been talking with Squeak Central about these issues since at least Squeakend 2000... so I guess that I have been keeping Alan and Dan et. al. in the loop for about a year.

Squeak central is up to its ears in work that it needs to get done to meet its objectives. They just don't have time to address many of the issues that the Squeak World Tour is addressing. Contrariwise, Squeak World Tour doesn't have the time to keep up with the wildly dynamic update stream for Squeak.

The co-evolution model seems to make sense to all the folks that I have been talking to at Squeak Central. I have received encouragement and support from SqC.

(if it will be folded back:) When do you think Stable Squeak will be mature enough to be folded back into "regular Squeak"?
The process has already begun. The base image tests are quite mature. They could be incorporated immediately. Afterall, it is more important that flavors of Squeak behave the same way than that they are implemented the same way. The exception fixes have been rolled into the base. Scripts exist that will help in the process of expunging problematic fonts from the Squeak base image. These seem to be some of the more pressing things to fold back into the mainstream right away.

The natural process of selection should take care of defining of defining subsequent cross fertilization activity.

Are all the license issues regarding Stable Squeak ironed out? Is there a decided base policy and have all the contributors decided on their respective take on this issue?
It would seem to be the case that things have been worked out. The code will be released under the Squeak license with the observation that problematic fonts have been expunged.

Would you like to run Stable Squeak more like a "regular" OSS project in the future with a mailinglist, people joining up, regular releases etc.? Or are there reasons for delaying such a development?
It was deemed necessary to get to a first release status. Until we have ways of recognizing and managing variation, more inputs is not helpful. Part of a recognizable core is the small development environment. With this first release we have reached the milestone after which more of the standard OSS practices are meaningful and helpful.

(if Stable Squeak shold become more "open":) What do you propose as the first steps in opening up Stable Squeak more? What can we help you "core guys" with?
I would like to have a set of development stories that address packaging functionality that was removed from the base image. I would like to have stories that address image refactoring and composition. I would like to have stories that talk about the tools necessary to foster sharing code between mainstream Squeak (or Smalltalk in general) and Squeak World Tour. From here XP practices give us a nice way to let folks sign up for tasks with clear scoping and deliverables. Packaged modules give a chance of actually integrating all of these different development efforts.

I recall that the Exception framework finally adopted in Disney Squeak clashed with another variant developed by Craig Latta together with Flow, how have you resolved those issues in Stable Squeak?
We just reused work that John McIntosh had already posted to the Squeak list. In this regard, it looks as though Craig prefers to go with a LGPL license on the network portion of Flow. We are repackaging this as a separate module so that we can statically assess which modules are covered by which licenses.

When working with Smalltalk source code, what are your personal experience regarding team support? Disney Squeak is more or less totally relying on a stream of changesets. Many Smalltalkers consider ENVY/TeamV as more or less as THE way of doing things (fine granularity, ownership, no automerging as in CVS etc). Could the Squeak/Smalltalk community benefit by taking a good look at the rest of the world, for example the OpenSource world?
It is always a good idea to adopt fresh points of view. The module concepts are pretty generic and map directly into VisualWorks, Dolphin and ENVY. Again, the intention here is to foster variation and cross fertilization between images and dialects. Not to make the "best" or "only" one.

Folks who prefer to develop with change sets, should continue to do so. We need better tools to analyze change sets with respect to modularity considerations.

As the World Tour Guide, my direction has been to do the simplest thing that maps in and out of the other points of view as simply and directly as possible. Some tasks I want to queue up for the next round of development would include things like supporting VW XML Source code format. I wonder if Squeak's Environments can be used in place of VW5i's namespaces???

What are you "core guys" working on right now in Stable Squeak?
Getting this beast out the door. I've been busy incorporating contributions and building a release directory. Joseph and Paul have been busy burning the midnight oil in order to get us a mechanism to manage our code. Short of that, we are in a feature freeze until this first release is widely available to the public in general.

Thank you for your time!
Thank you for your time! It wasn't till I took the time to read your reflections on the limited pre-release that I realized how much work was accomplished in spare time by a small, geographically dispersed team.

Thanks,
John Sarkela :-}>


Conclusions (too long but hey...)

First - I have not really had the time to look into Joseph's semantic model and Paul's accompanying Repository code yet so this article has not touched upon those areas, but there is a followup article coming!

What Joseph showed me felt like "the future" for Squeak - it was solidly built with tests for everything, seemed extremely powerful and yet simple at the same time. The semantic model, code partitioning and version/configuration management (Joseph's stuff) are quite elegant. I think the phrase "ENVY done right" sums it up. If you've read Joseph's book (Mastering ENVY/Developer, co-written with Alan Knight and Adrian Cho, published by Cambridge University Press), you know that he knows his stuff. That combined with a powerful framework for connecting to different sourcecode repositories (Paul's stuff) sounds like the booster Squeak needs right now to really bloom. Hopefully this description has whet your appetite. :-)

The forking issue of Stable Squeak is still somewhat open! Before I wrote this article I was against forking and was under the impression that the Stable Squeak "branch" was temporary and that it would merge into regular Squeak at a planned moment down the road and then cease to exist.

But this is probably not exactly how it will go down if I am interpreting John's current thoughts correctly.

Stable Squeak has forked and there probably will exist (at least!) two different "flavours" of Squeak for some time. Perhaps the more realistic scenario is actually that Stable Squeak might eventually pick up a similar role that Debian stable has in Debian.

Short backgrounder on Debian: The Linux distribution Debian (from which there are IMO many things to learn) has currently three different "stages" where Debian packages of software lives - unstable, testing and stable. A new package first enters unstable which is the bleeding edge development stage. After it has been living there for a while without any critical bugs left it moves into testing. Finally, after a while in testing, a package is deemed production quality and is accepted into stable which is the official release of Debian.

I know that the comparison is... perhaps far fetched. But obviously Stable Squeak was born out of similar needs and this may be a suitable model to mimic.

There has also been concerns about why Stable Squeak hasn't been more open, and I agree that the project has not really been trying too hard to publish their work openly yet...

But the project isn't really secret either - I have had no problems getting in contact and getting access to the current development image and my impression right now is that these guys are hacking away like mad dogs :-) in order to reach their goal and the first public release. My inbox is suddenly flowing with emails from Paul, Joseph and John!

There are two main reasons for the guys cruising under the radar. Firstly, they're busy developing the infrastructure needed to manage other folk's future contributions. Secondly, John, Paul, and Joseph know each other from way back (from the pre-dark age days of Digitalk), and have what XP calls a "common system metaphor" for their development.

If I am not mistaken, Paul and Joseph are getting their semantic model/repository stuff together and when that falls into place it would probably - as John is suggesting in the interview above - be a good time to open up the project more.

Note though that personally I do not see any real problem in opening up right now either - even if a good "commit policy" is in order as earth is still shaking in Stable Squeak!

And this brings me to the content of my upcoming followup article where I will try to:


But until then - and I do not know when "then" will be - I hope this first article was interesting to someone, regards Göran

Links