|
|
|
Aug 29th 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/ESSEN+ESUG+Day+2
ESUG Day 2.
Back to Day 1
It's breakfast and I'm deep into a discussion about VW processes and how thread safe the image is when you attempt time slicing by overriding the round robin approach with someone who happened to ask my opinion on this when I realize I need to be somewhere in about 5 minutes
So begins Wed AM.
Joseph Pelrine of Metaprog Gmbh (Modular Smalltalk)
{Scribe: hint to readers, this talk is important}
Squeak, well it has some rough edges. The compiler needs Morphic. The file-in and out doesn't really work just right. Squeak has that look from the California sixties. We are boring business people what to do. So late one night, John Sarkela and I sat down and over drinks he asked. "Well Joseph what would you do different"? So I say I have a long list. "Ok, why don't you do it! " Well I'm a humble guy and I know I stand on the shoulders of giants, so I looked at Orwell, talked to David Thomas, talked to Allen Wirfs-Brock and looked at how this all resolved over the years. There is a lot of history and we should pay attention to it. So I looked at the ANSI smalltalk spec. It's boring you can use it to put people to sleep, so the next part of my talk is boring.
Now how do we define stuff in Smalltalk. Well we send messages to objects. Now for example we send a message to Class to create a class, we send messages to Smalltalk to put things in the globals, again it's all messages.
This is done interactively using browsers and it's all usually hidden. We also have doit and lots of formats for moving data, SIF, file-in, XML etc. Well it's SEP (S)omeone (E)lses (P)roblem. But lets look deeper, these look like imperative actions.
Question "are they?"
Well no, chunk format is, but most of these aren't but they appear to be.
The imperative methodology forces a way of doing things on you, the machine must be in a certain state to do the work. It's difficult to figure out history and the future of this state from the workspace. Several issues arise from Smalltalk's imperative way of doing class building. As an example we can build a square from a set of independent statements to move a pen, the end result is square, but if something is wrong or out of order we won't get a square.
Issue software engineering
What is a program
What is change management
Intial state dependices.
etc
<> moved that slide a bit too fast.
If you think about it we have the application, the Tools, and the standard classes, these result in an orthogonal slice thru the image that is what we call the application. It's fuzzy. But a declarative syntax will allow us to describe this fuzzy stuff.
Today the normal way of packaging is to take the huge ball and carve off things, hopefully not too much and result in a sculpture that looks like your application. This of course is difficult, dangerous and mostly results in an application fatter that you actually have. This is what we've been doing for decades. This is wrong.
The standard says we should do a declarative definition that defines what the semantic element is. So for example you define a square as a detail specification detailing the size of the square, the color, the width of the border, etc. It is implementation independent, order independent, has no state dependencies, and easier to analyze.
Lots of languages have declarative definitions, C and Pascal for example.
So the ANSI standard defined how to do this for Smalltalk. Most vendors don't support this yet. Perhaps they should take this source code and use it. Originally I wrote this in Squeak but I moved everything to VisualAge in an hour. For VisualWorks it was more work because we had a collision with a class name, and a tool problem prevents doing a file-in into a namespace, so I can show Squeak and VisualAge today, but only a little bit in VW.
So if you look at the ANSI class definition, we see all the things we expect to see, but namespaces. It should not be difficult to add that. I believe at Camp Smalltalk in SD (CS1) a meeting was conducted by some VM developers and a gentleman's agreement was reached on how someday to reach a common format on namespaces. See <>
So the ANSI semantics for defining a class are:
Class name is defined as a global
The execution binding name is the class name
The binding of class name is fixed
Error if class name is duplicated.
Mmm these look like SUnit test criteria eh. So you can see we build an application from the definitions. The given error definitions allowed me to build an exception hander hierarchy that allow you to do neat things like throw an install exception on duplicate class name, then you just write a handler to deal with that situation.
Question about "dealing with duplicate classes"
Ok the deal here is I'm doing the exception framework, you just need to deal with them. Right now everything is validated, then it is installed, so a failure means no changes to your image. Some more work is required here to decide what is a recoverable failure and or other housekeeping issues.
So a Global definition follows the same pattern, a definition, a description of how it works, and a set of errors.
Question "Don't you have Initialization issues?"
Yes this is a problem. You can deal with the declarative part but the programmer holds you hostage, this is a doit and you can destroy the world if you wish.
Smalltalk program methods
Again definitions, etc etc.
So we have syntax, and various Camp Smalltalk projects to have a portable binary interchange format. But this is SEP (Someone elses problem), I don't care about how the data is moved or represented. I am only interested in what happens in the image.
So some things to think about
Global variables and pools are implemented as Dictionaries
Methods are objects
Methods are stored in dictionaries
Behavior in a class method
etc
Lots of these are represented differently in each dialect. This is unimportant to declarative syntax. If I install a method, I don't really care how the dialect stores and manages it.
The declarative model describes a program before execution. Reflection occurs dynamically during program execution. The declarative model neither requires nor precludes reflection.
{Scribe note} Lots of questions at this point I couldn't capture.
Meta level programming
Kent Beck "It makes you a better smalltalk programmer, but you must learn when to use it and when not to use it. "
Ok a slide with lots of small type. Ack lets go look at a Smalltalk image.
So under Object we have AnnotatedObject which provides variables for annotations of objects, like copyright, and comments.
{Scribe note} some discussion I didn't capture.
Ok, lets step back and look at another issue. Usually Smalltalk images works on the active image. This can break things, like adding halt to Collection>>add:. Better Smalltalk tools like the one I create for the declarative model have allows you to manipulate the declarative model of your application and NOT install it in your image. So then you can code without affecting the image. However at some point you must install it, in order to run it. {But of course you can install it in another remote or local image and destroy that image instead}
So when you work on definitions you can work on them and they are not installed. Code, validate, then install! So for example you could install a different parser like the Refactory browser for Squeak in a VW namespace, this enables you to write Squeak in VW and validate it, and then install it into a remote Squeak image.
If you remember the firewall prototype that Objectshare worked on in the mid 90s, it also exists in other dialects in some form, and it gave you the ability to separate development from deployment.
Question about "incremental modification via the debugger?"
Remote debugging is a big issue, just one step at a time. Right now we can develop methods and move them over, remote debugging is a different issue. You need a debugger that works on a semantic level.
You also have this issue of semantic leakage. If you use a tool that isn't semantic aware, the debugger, or doits then you can loose sync between the model, and the image. Your scribe pointed out you could use a tool to validate this. Yes but the tools need to enforce the synchronization, this will come in time as people rewrite the debugger and workspaces etc.
Question "does that cause problems with the VA browsers?"
Well yes and no. More on that later.
Some points.
You can work offline for example
Now normal people sit in the browsers and or debugger and write code.
Programs are completely defined
Reproducible from source code.
etc
The Digitalk V development image was the most advanced environment that ever existed. The ObjectShare/Parcplace? firewall prototype had the target decoupled from the development image which operated on a different thread, and gave you full incremental programming and debugging. An image containing "3 + 4" was 1Ok, utilities 30k -200k GUI about 2MB.
Wow, this is really small
Name Scope
Different than existing structures ie ENVY.
Not a containing relationship but a composite definition
Package contains definition
ScopedNode contains either scopedNodes or ScopedModules
One predefined hierarchy
A cluster is an orthogonal view of the objects an application needs across the image. All hierarchies can be tested for visibility and closure. Also mentioned packages, I need a link here to some docs.<>, say in two weeks or so..
I do have prerequisite definitions and testing but not enforcement, this gives Envy like rigour versus "Sunday Squeakers". However there is a switch to turn the rigour on or off.
Now when we were looking at the image there was a ginsu problem we needed to slice the image into parts. This was worked on with Dan Ingalls a while back as part of the early stable Squeak project when we were deciding how to chop the Squeak image up.
Coffee
During Coffee your scribe got to talk to the fellow who worked on the PPC version of VisualWorks for Mac-OS-X. Sounds great can hardly wait to see a proper demo.
Coffee ends
Joseph Pelrine of Metaprog Gmbh (Modular Smalltalk)
Ok, lets look at a stable Squeak image, and one of the tools we wrote is the Module manager, this looks, well a lot like Envy.
{note I believe based on a short conversation I had with Joseph later in the evening that Modules is the abstract superclass for the classes of Package and Cluster. Package is a leaf nodes and contain Classes etc. Clusters is a composite pattern and contains other Clusters or Packages. I certainly hope I got this right, otherwise I'll post any corrections Thursday evening/night}
In the Modules browser window you have Clusters, the prereqs, and the Dependents. So we looked at the Kernel cluster, which had these items CLDT, Core, Event Handling, Exceptions and Process. Also much like Envy we have extended classes which means classes are shown in bold or regular font depending if the class is extended. The tool allows multiple views so for example you can look at a class, and see what packages contain it. Think of the various Envy tools. You can also browse annotations, and remember each object can have an annotation.
There is a Clusters browser, which looks like the existing category browser. On a class level you can browse it on the basis of a particular Cluster. Or there is a browser to browse a set of classes in the Clusters, and finally a browser to browse the intersection of multiple Clusters and their classes. So in fact there is lots of browsers in the image to mange Packages and Clusters.
Now with Envy out of the box, you get the classes in nice Application maps for the repository, Adrian did that non-reproducible fashion at OTI. We had to make a browser ModuleBuilder that allows us to move classes into a Package or Cluster to enable us to build this set of definitions. This tool allows us to add Clusters or Packages to a Cluster, or a class to a package. Once you do all the work you can build the package or cluster and the tool sorts out the class visibility issues etc etc to make the scopeing correct and tells you if there are problems. For each dialect we need to use this tool to build the modules. However in VisualAge or VisualWorks we could just steal the Envy definitions by mapping the Envy definitions onto the declarative Model.
Ok, let write a method In the Squeak dialect within a VisualWorks or VisualAge image and pump it over to Squeak. {PS thanks to John McIntosh and Craig Latta for getting Flow working in this setup}
Ok, we start the Flow server in Squeak which setup a TCP/IP listen on port 4711. We will read from a flow stream validate, then install the incoming Cluster. Back to VisualAge and we send a Global initialize definition from both VA and VW to the listening Squeak image. Both actions are reflected in the Squeak transcript, We see the cluster definition come in get evaluated and the cluster gets installed. Ok now something more complex, we want to send a class over from VisualAge.
Ok, we do that, see the class Quank go from VisualAge to Squeak. This was confirmed by using a Squeak browser to see the newly created class in Squeak.
Ok, now a bit of Envy trivia, in Envy you can install a notifier for change activity such as a change to an envy controlled object. In this case we want to be notified if a class is changed and then we will send that change over to Squeak. This is done by converting the change, a method update, or class change to the correct declarative definition, then building a Cluster and shipping the bytes over to the Squeak server.
We try that by changing the class definition of class Quank by adding some instance variables. This gets reflected correctly in Squeak without having to do anything, since this now an automatic part of the Envy change process.
At this point what more is there to say.
Please feel free to download Squeak World Tour release with the mod squeak stuff from:
http://swiki.squeakfoundation.org/stablesqueak
{Hint store your Squeak Application code in VisualWorks Envy or Store, install and run when required via injecting a Cluster contain the Envy map into the basic Stable Squeak image. Your scribe will also add it's not important who was the server, or the client, or how the transportation was done, what was important was the tools enabled the activity and the declarative model made it possible}
Your scribe then got to talk about VMMaker, alas there was only one VM builder present in the room of Smalltalkers and I'll post a link to where and how for VMMaker in a few days.
At this point the ESUG committee had the various Camp Smalltalk projects report on the progress they had made earlier in the week.
Camp Smalltalk Report
FROST.
The FROST stuff came from the web, then to ENVY, slashes in class names ugly. Some Envy issues, so we migrated to STORE. Now we have a parcel and a STORE version, this will be made available on Sourge Forge and we'll reactivate the wiki about FROST. Further work is required like adding the JDBC interface, and a Java to Smalltalk converter! So lots of work, some of which might get postponed until the next camp just because of time allocations. People are welcome to take it and work with it.
Numerical Methods
Rodger
Took the code from VisualAge and ported to Squeak, VisualWorks 3. & 5.i4. In Squeak there is only 3 or 4 errors. There maybe a pending Envy and a Gemstone and Smalltalk/X port . However the rights for the code were signed over to the book publisher so we need to get official permission. So shortly we should have some really neat mathematical classes to use in most dialects.
Glorp
Alan
Getting it to file in and file out again was a problem We got it all to work on many dialects. Also we looked at table structure and mapping. This is a lot of work. Doing a 5 table definition is ok, but a big system has 1OO of tables. So we formed a subteam to read the database meta data from tables. So we map the meta data from the database using Glorp to build the application table definitions. We need some help from the Squeak programers Interested parties should contact Alan Knight <knight@acm.org> Note later in the evening Alan talked about forming a small team to put the right tools together to allow Smalltalk code interchange (ie file in/out) between all dialects without pain, also contact him if you can help.
Refractory Browser port
Porting the user interface to Squeak.
Took Bob Hartwig <bob@bobjectsinc.com> work. Had some work to get it to file in with the current image. Claus also filed in the test suite and started to work with it. We hope to have a working version in Squeak at the end of week, which we'll package and distribute. Morphic is difficult to work with, no builder, sigh
This was not an easy task. Need better set of widgets, etc.
SOAP, but this became the Web Services group
We create a service on a VA machine. Then imported the definition into VW, used the SOAP definition to talk to the VA server machine. We are now creating the SUnits and we'll setup a server. We need some Squeak people to help us setup a server. SOAP support in Squeak is in flux so we also need help for this. Interested parties should contact "Mark D Weitzel" <weitzelm@us.ibm.com>
Refactory Tool project
The rewrite tool is scary
Why not refactor it. A novice user should be able to
Put in some code, then get prompted for what to do. Now a novice needs a lot of information to do this. The rewrite tool sits on top of a large number of methods. This was exposed which makes the tool much easier to use. Will have something done by the end of the week. If others want to join please inquire, <email address here>
Dialect isolation
Hey we really need to have a common smalltalk to write to to avoiding having to port to all the dialects. So what is the LCD smalltalk, hint it's not ANSI. So we have started to work on what this is. So lots of more work to do here.
After this your scribe had to depart to do some housekeeping chores, so I missed the next presentation. After lunch we toured the Coking plant Zollverein in Essen-Katernberg. Quite an unbelievable facility and park also I'm sure I ruin a set of white pants forever with just a wee bit of Coal dust.
During the evening we all retired as a group to a local beer hall for traditional German hospitality. Do you know which VisualWorks programmer uses a German iBook (and OS-X I might add). If you came to the conference you would know. In any case I've a presentation to give on Thursday so it's lights now for another day.
Forward to Day 3
|