Oct 24 2001.	Camp Smalltalk Essen ESUG 2001

Note on Oct 24th 2001 this paged was moved to a Wiki so you can edit it there. Please read it over there, this copy is here for historical reasons. http://wiki.cs.uiuc.edu/CampSmalltalk/Camp+Smalltalk+%40+Essen+ESUG

Camp opens on a hot day here in Germany. About 30 smalltalkers are sweating (literally) over hot keyboards spread across two rooms in the Essen library building, or the red building as it is known. Logistics was being handled by Joachim, and the company Tomcat had sponsored the much welcomed drinks. The usual kilometers of Ethernet cable had been laid and we were Internet aware. Thanks to those that made this possible. Stephen told me things had started at 8:00 to setup the server, and I had arrived in the late afternoon after a relaxing drive up the Rhine river, but now was prepared to set holidays aside and dig into where Smalltalk was going.

So begins another story about Camp Smalltalk, if you've missed the others, then perhaps I can suggest you start reading at the first Camp Smalltalk, and SqueakEnd'00. Because of the hectic and hot atmosphere today I may have gotten some details wrong, campers should email me with corrections, or chat with me at camp when time permits

By this time of the afternoon numerous projects were underway, those being SOAP, NUMERIC, FROST, GLORP, the isolated dialect project, and the Refactoring Browser port. I'm sure other were awaiting individuals to arrive, as they did thru out the afternoon as airplanes arriving from the USA allowed jet lagged Americans to straggle in.

Roger Whitney was working with four others on Didier Besset book " Object-Oriented Implementation of Numerical Methods: An Introduction with Java & Smalltalk " ISBN: 1558606793. They had already found that some of the code wasn't correct because as they were doing SUnits they found that some of the methods no longer existed. As code was being created discussion arose about how much optimization they needed to do at this point. Comments about inject:into: hurled about, and decisions were made to delay such exotic changes until it was decided what really need to be done from an optimization viewpoint.

In the next room I entered into a discussion with Andrzej about Class category extensions. This was old work done by him many years ago, but being revived due to the discussions about modular Squeak on the Squeak list in the last month. As an example, you could add a new category to String, say 'test string changes', in that category similar to what Envy does for class extensions and then add any new methods. Later if you view the String hierarchy you would find both the core system methods, and another selector for the 'test string changes' category. Most importantly you could remove the class category and it would remove all the methods in that class category without really altering the String class. At the moment he was fighting with the newly introduced environment logic in Squeak which had affected ways in which his code had worked.

Alan Knight was working on GLORP of course, he was busy filing out code for others to work on for the Dolphin and VisualAge ports. This activity was pointing out some problems with class initialization, some Singletons did not have re-initialization methods which was causing problems when the code was being re-filed into the VisualAge, Visualworks was much more lenient with filein issues as compared to VA.

Although work was being done on ports and the ability to read the data model schema from a database, what was really needed is some consultants that are actually using the product to solve real world problems, aka 'real users' of the product. They of course would have priority in the long list of things to be worked on in GLORP. Such people are welcome to email Alan with their issues. (Help too of course).

Markus, Daniel and others were looking at writing the UI for the Squeak Refectory Browser. They had taken source from Bob Hartwig site and were examine differences between a Visualworks image, and a Squeak image running on a powerbook.

Hans-Martin Mosner and another keen smalltalker were working on the standardized socket layer, remember at Smalltalk Solutions 2001 it was discussed that we should build a layer based on the BSD socket layer, and use this interface to build http and ftp protocol layers upon, with the actual functionality of the BSD simulation being done lower down in C, or via the existing dialect socket implementations. This would enable one to port network aware Smalltalk applications between dialects without running into porting problems. At this point they had worked on method names and the exception handling architecture. I discussed with them the importance of doing SUnits before writing most of the behavior, however as yet they were far away from writing concrete methods. They had lots of abstraction to do first.

Claus of Smalltalk/X fame was surround by 5 smalltalkers examining what I think was Smalltalk/X doing Java, well at least I think that is what he was doing because I was talking to Chris Folkers about the dialect isolation project. For example most Smalltalks have different ways of find lists of classes. The isolations layer will allow you to make a call that will then be delegated to a object instance that understand how the dialect of Smalltalk actually performs that function. Peter van Rooijen told me they had originally separated such features into ANSI Smalltalk and dialect specific implementations. But this doesn't really work, rather they need to find the common Smalltalk layer between dialects, then the rest is specialized and requires port specific knowledge. So for example to port an application that uses the LCD (lowest common denominator) Smalltalk, or the isolation layer then porting is simple, in fact no work should be required. The end goal is to port the ANSI Smalltalk test suite to the isolation layer then have the ability to run it on any Smalltalk.

In the next room Joseph Pelrine and Stephen were talking about modular Squeak and details about how to do this. The vision which is a major discussion point on the squeak list at the moment is to have a base Squeak, then load functionality for your needs, so if you need Etoys, so be it, otherwise you need not load it. This enables you to build a Squeak image, perhaps from scratch each time, much like SmallScript, when you start the VM. Remember in the past some Smalltalk never used monolithic images, rather they loaded modules and the such from scratch from a source code control database thus ensuring what you thought you had, you actually had.

Joseph vision is to write a Squeak class in VisualWorks, then file it out VisualWorks then back into Squeak. The Browsers doesn't work on the code, rather they work on a semantic model, so the definition is semantically common, then it solidified into dialect code for compilation and viewing to occur. Since this work on Smalltalk semantics model results in dialect independent code I suggested Joseph should work with Peter on the dialect isolation layer.

As this discussion was ending I entered into a discussion with Claus about remember table logic in Squeak and how it was done in Smalltalk/X. He spoke of the same scalability problems although to a different degree that we have in Squeak. Running 700MB images is a problem, however he discussed with me his building of a treadmill GC in Squeak that he was using as a testbed for considering changes to Smalltalk/X. We discussed at length the issue of the remember table and how to remember roots without running into scalability or performance issues, a difficult problem to solve. Solutions are welcome, feel free to email me with links to papers, etc. I should point out his treadmill collector with doubly linked objects using various list types is very interesting and allows for some interesting features such as the ability to make the sweep phase (aka mark/sweep) disappear.

Back in the NUMERIC group they had moved to chapter 4, and were merging code. How many test units they create will drive how far they get in the book by Monday. During this process Roger was pointing out that he had ported all the neat browser features and shortcuts to VisualWorks, what are the name spaces, what are the last 25 changes, what are the open windows. Simple things that make an experienced Smalltalk coder happy. Mmm and the file outs are where?

By this time it was nearly 19:00 hours, time to leave, the facilities were closing and about 20 of us decided to descend on a local restaurant down the street from the hotel for a bite to eat and perhaps much good German beer.

During the consumption of some fine German cooking, with a greek flair, the interesting things I heard around the table was that Mercedes had actually used Smalltalk not only for desktop applications, much too large at 16MB, but had written many of the control systems used in their most impressive manufacturing plants. I was much surprised, since I've not seen any links to that fact before (links are welcome). In fact the system, that I got to see in Mercedes car manufacturing plant the month before, managing the insertion of the car dashboard was written in Smalltalk I was told. Because car manufacturing with robots is a simulation, then with Smalltalk little other work is required once you've gotten the simulation to work. Just add robots.

Many things from the taste of European coffee, to Larry I. Martin were raised, and it was a chance for Smalltalkers from different countries, abilities, and experiences to come together, talk, and discuss where the community was going.

Is it 2:00AM yet? Well not quite, but I'm going to skip http linking this and post it, since tomorrow comes early.
Day 2 continues