The Smalltalk Development Tools team, Graeme Johnson, Dan Heidinga, and Gabriel Castro, brings a mix of both ENVY Smalltalk and Eclipse experience to provide a Smalltalk environment in Eclipse. Graeme, a manager on the J9 VM team, has been involved with Smalltalk since before he graduated from Carleton. He was part of the team that created OTI's ENVY Smalltalk and was the designer of the original ENVY debugger. Dan was introduced to Smalltalk during his University of Waterloo coop terms with IBM. He was quickly indoctrinated in the wonder that is Smalltalk and returned to work with the J9 VM team on STDT full time over a year ago. He is also an Eclipse contributor. Gabriel has been developing Eclipse-based tools for the J9 VM team for almost three years, including the recent STDT. He's an Eclipse contributor and has spoken at EclipseCon. In his spare time he enjoys running, biking, and photography.

J9 VM patch streams wrathified!

"Are you suggestin' coconuts migrate?!"

King Arthur: The swallow may fly south with the sun or the house martin or the plover may seek warmer climes in winter, yet these are not strangers to our land?
1st soldier with a keen interest in birds: Are you suggesting coconuts migrate?
      -Monty Python and the Quest for the Holy Grail

Unfortunately, source code, like coconuts, needs help to migrate from on repository to another. When we started, we only wanted to change where our Smalltalk source was stored. We had lived with multiple repositories and were tired of ensuring that dependent changes in each of the repositories got into the right build, or was correctly backed out when there were problems. Our original goal was only to replace the ENVY repository with CVS, or any other version control system, and continue to use all the existing browsers.

To get to that goal, we needed a way to export our Smalltalk code to flat files and a way to load from the files back into the image. The obvious answer is Smalltalk's existing file-format, the "chunk" format. Chunk format, while fine for computers, leaves something to be desired when it comes to human consumption. Various other file-formats for Smalltalk have been development but none of them felt quite right for us.

Our solution is something we call FileBasedSmalltalk (FBS), which has become on of the core components of STDT. FBS provides a meta-model to map classes and methods back to their files so that the source can be kept on disk, not in memory. The model maps FbApplications, FbSubApplications, FbClassDefinitions, FbExtensions and FbMethods onto their "normal" ENVY model objects. The FbLoader is responsible for reading the files in and creating these model objects. To provide name resolution, the FbResolver was created and it can be thought of as the Smalltalk dictionary for FBS.

I can hear you thinking, "You have a meta-model... you still haven't actually installed any classes in the image" and you're right. The EmImageBuilder is a fantastically complex piece of code that does a great job of atomically loading classes, applications, etc. We definitely didn't want to rewrite it, so we did the next best thing - we subclassed it. FbImageBuilder is the new image builder that can force the FBS model objects into the right shape, allowing them to be loaded and installed as classes. Getting this correct was a lot of fun as mistakes often meant starting with a new image.

Now, I've explained how the Smalltalk source gets loaded into the image, but what does this have to do with repository migration? At the same time we were getting the FBS figured out and working, we had started to mirror all of our code from ENVY into CVS each as part of every build. Source code without history - no change comments and no ability to see why things changed - makes it very difficult to determine if that nonsensical code snippet is there for some vastly important reason or can be safely removed. Today there is over a full year's worth of history in CVS for all of our Smalltalk source.

As part of each build, our Smalltalk tools were run twice, once from ENVY and once using FBS. The output from the two were compared to ensure they were identical. It was now safe to only run the tools using FBS, although ENVY was still the "master" for the source and the mirroring to CVS continued. And that was the migration, a gradual switch once confidence had been built up in the new tools.

Turned out that trying to keep the ENVY browsers and make them work on files was more work than was practical. Instead, the STDT tools were born.

Categories : [   envy  |  fbs  |  migration  ]

Oct 31 2008, 03:10:03 PM EDT Permalink

What? Smalltalk hasn't always been cool?

If you have investments in Smalltalk consider the risk of the language to be lower over the next 3 years than the last 3 years.  Smalltalk is cool again.  Is it the start of a long term trend or a fad?  Yet to been seen.

Where are the browsers?

I had promised an explanation of how we mapped ENVY concepts into Eclipse. Its probably a good idea to review how ENVY organized code. ENVY did this by provided first-class code organization structures:

• Classes were contained in Applications. Classes, in the normal OO style, owned the methods which were the basic level of version control.
• Applications, along with SubApplications, provided a tree-like structure, usually used to cover over platform dependencies. Applications also were able to express dependencies on other applications, providing scoping hints on which classes and methods should be available. Lifecycle events, such as image startup and application load, were sent to applications to allow them to set up and clean up state.
• Class extensions allowed adding methods to classes from other Applications
• Configuration Maps provided a grouping of Applications into logical sets. It was also possible for one config map to express dependencies on other config maps, providing a defined load order. This didn't prevent multiple config maps from including the same application, and this frequently occurred. Config Maps also provided configuration expressions which were evaluated prior to loading to ensure things like the to ensure that loading the config map was possible.

To get to our new world, we had to port these concepts into the Eclipse Resource model. Eclipse basically allows things to be organized into Projects containing directory trees of files. We opted to use a straight forward mapping: Configuration Maps become Projects, Applications become a Directory plus a file of the same name, SubApplications are identical to Applications except they must be stored in Application, and both classes and extensions became files.

There were a couple of things we had to give up to live in an Eclipse world:

• Applications can only belong to one Project (Config Map)
• Configuration expressions are now stored in separate files, called .smalltalk files.
• Version control happens on a per-file basis, not a per-method basis.
• Nothing is automatically stored in the repository any more.

Just because that's how we laid things out in the Eclipse Workspace, doesn't mean we wanted to live with just Eclipse's Project Explorer-style views. We wanted our browsers back! At this point, I need to say a big thanks to the guys at Instantiations for providing us with a couple of free copies of WindowBuilder to use on this project. Their tools have made our lives a lot easier, especially when we've been prototyping new UI designs. Meeting with John O'Keefe and Eric Clayberg at Smalltalk Solutions and not only seeing their enthusiasm for STDT, but also seeing the great things they are doing with VA Smalltalk, the successor to IBM's VisualAge Smalltalk, was an awesome experience.

So two Smalltalk perspectives were born:

the Smalltalk Applications perspective,

and the Smalltalk Classes Perspective.

Categories : [   eclipse  |  instantiations  |  smalltalk  |  ui  ]

Oct 14 2008, 01:24:25 PM EDT Permalink

How Wrathful are you?

So why have we done this? I guess it never hurts to provide some background.

All three of us work with IBM's J9 VM team, which was born out of OTI - the original creators of OTI Smalltalk and ENVY. Unfortunately, ENVY is showing its age in several ways (it was born in 1994 after all). We started experiencing problems working with distributed teams due to ENVY's chatty protocol, which requires a low-latency connection to the database. ENVY was also causing us problems because it doesn't have a lightweight tagging mechanism, making it difficult to get back to the exact code used in last weeks build. Finally, ENVY's strong notions of user/manager roles caused a lot of confusion when bringing new people on board. "Of course you can't do that. Only GAC can do that, obviously you have to be GAC to version, and you to release." Not exactly simple.

We looked at the current situation and picked out a few goals:

1. Keep the Smalltalk language - we have significant investment in VM construction tools for which Smalltalk is well-suited.
2. Put everything in Eclipse - our team already uses Eclipse... why would they want two IDEs open?
3. Remove confusing concepts - say good-bye to "become another user".

So we came up with a plan to migrate from ENVY to an Eclipse-based Smalltalk IDE, which we called STDT for Smalltalk Development Tools. There has already been some flak from coworkers for calling it STDT due to the fact that we have two many 'T's in there. That extra T comes from the '.st' file extension of our source files. Internally, the project has been called WRATH. Why WRATH? Well... figuring we should follow ENVY's example and pick one of the seven deadly sins, we looked at which of them had the letters ST in them. LUST jumped out as the most obvious choice. Sentences like "I've been working really hard on LUST lately" where enough to dissuade us of that name. WRATH seemed like the next coolest of the sins, so that's what we used.

We've also presented STDT at both EclipseCon 2008 and Smalltallk Solutions 2008:

EclipseCon 2008:

Summary

Smalltalk Solutions 2008:

Abstract

Video

Industry Misinterpretations podcast:

Podcast

'Are you Wrathful?' quiz. (Try to maximize your wrath score)

Quiz

In our next posts, we'll describe how we've mapped from ENVY into Eclipse and show some screenshots.


Sep 26 2008, 04:38:11 PM EDT Permalink