This is a short summary of the talk given by Claus Gittinger, founder of Exept Software AG and creator of Smalltalk/X, on Friday September 19th, at University of Buenos Aires campus.
The introduction of the talk was a presentation of Smalltalk/X, it's history and technical things which are very different from other Smalltalks.
The motivation of making his own Smalltalk came when he read the famous Byte magazine in 1981. Since at that time it was very slow to have a byte-code interpreter, his first idea was to make something which compiles Smalltalk.
The process to achieve this was to:
The motivation of making his own Smalltalk came when he read the famous Byte magazine in 1981. Since at that time it was very slow to have a byte-code interpreter, his first idea was to make something which compiles Smalltalk.
The process to achieve this was to:
- Take a Smalltalk file (file out format) for a class
- Translate it to c (using stc), implementing all semantics of the original Smalltalk including contexts, blocks, etc.
- Compile it by the c compiler, obtaining .o or .obj files
- Make a dll with a collection of .obj files
machine code methods.
As a result, Smaltalk/X has an image but doesn't need one. Another interesting feature of Smalltalk/X is how window events are handled. Each topview and all of its subviews are grouped together in a WindowGroup, which runs on it's own process.
All events (keyboard, mouse etc.) are read by a separate process (called the event dispatcher), which reads the event from the operating system, puts it into a corresponding event-queue for the windowgroup, and notifies the view process about the arrival of the event (which is sitting on a semaphore, waiting for this arrival).
As a result, the hole system is not blocked by a long (or endless) operation occurring in one WindowGroup.
As a result, Smaltalk/X has an image but doesn't need one. Another interesting feature of Smalltalk/X is how window events are handled. Each topview and all of its subviews are grouped together in a WindowGroup, which runs on it's own process.
All events (keyboard, mouse etc.) are read by a separate process (called the event dispatcher), which reads the event from the operating system, puts it into a corresponding event-queue for the windowgroup, and notifies the view process about the arrival of the event (which is sitting on a semaphore, waiting for this arrival).
As a result, the hole system is not blocked by a long (or endless) operation occurring in one WindowGroup.
Then, the main topics were related to Method Lookup, Inline Caching and Garbage Collection methods.
Finally, Claus made a short demostration of expecco.
Thanks to Felix Madrid (fmadrid at the google email) for this resume and the photos :-)
0 comentarios:
Post a Comment