Index
Date: 96 Nov 07 9:16:19 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: File In Scripts for 1.13 -> 1.15 Updates
Hello all,
Below are updated versions of the file-in scripts for the recent updates.
These have been altered to allow the use of a relative path names for the
file-ins (so that they need not be in the same directory as the image). One
can set the variable "dir" in the README files to point to the source directory.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"This is an executable file. If it is in the same folder as your image,
along with all the other files called out below, you may simply fileIn this
file, and it will in turn fileIn all the others. If these files are in some
other folder that you are browsing with the file list, you can instead use
the fileList fileIn capability to file in the various files, in the order
specified below."
"Relative path to the directory where the file-ins are"
| dir |
dir := '../../1.13->1.14 FileIns'.
"Define a new 'staggered' window placement policy. The goal is to
distribute windows around the edges of the screen, but staggered in such a
way that the outside corner of every window is always visible. Try it,
you'll like it. Use the screen menu window...stagger choice."
(FileStream readOnlyFileNamed: dir, 'WindowPlacement-di.cs') fileIn.
"Define ctrl-Return as CR followed by the same number of tabs as the line
above, (adjusted by number of brackets). Also define Shift-backspace as
forward delete-char [not currently undoable]."
(FileStream readOnlyFileNamed: dir, 'KbdShortcuts-di.cs') fileIn.
"A fix to arcTan that makes it more accurate and also a lot faster for
certain angles"
(FileStream readOnlyFileNamed: dir, 'ArcTanFix-db.cs') fileIn.
"A fairly major change that cures preexisting problems where long titles
forced windows to be too big. In the process the discrepancy between the
height of title bars on collapsed and expanded windows is removed."
(FileStream readOnlyFileNamed: dir, 'WindowTitleFix-di.cs') fileIn.
"Fixes a couple of problems with the StrikeFont edit: hack. Read the method
comment before using it, though"
(FileStream readOnlyFileNamed: dir, 'FontEditFix-di.cs') fileIn.
"Tweaks the 1.13 font so that a few characters are better centered in their
frames. Looks better and easier to select, too."
(FileStream readOnlyFileNamed: dir, 'FontTweak-di.doit') fileIn.
"Makes it easier to access the window drag-corner feature."
(FileStream readOnlyFileNamed: dir, 'BorderEditTweak-di.cs') fileIn.
"Two post-release tweaks to earlier fileIns above."
(FileStream readOnlyFileNamed: dir, 'WindowPlacementTweak-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'TitleTweak-di.cs') fileIn.
"Adds the ability to browse classes and methods in their inheritance
hierarchy. Also a 'browse all' feature that gives you all classes
alphabetically (and shows you what category they are in, too)."
(FileStream readOnlyFileNamed: dir, 'BrowseHierarchy-di.cs') fileIn.
"These two fileIns change the representation of Text emphasis. As a result,
in-line color changes are supported, as well as text ranges that execute
abitrary code when you click on them (now why would you want to do that?).
Command keys 0-9 have different meanings."
(FileStream readOnlyFileNamed: dir, 'NewTextPhase1-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'NewTextPhase2-di.cs') fileIn.
"A silly demonstration of the new Text features. If you select the browser
code 'format' command with the shift key down, it shows message names in red
and temps in green. Illustrates the use of a TextStream to build emphasized
text sequentially. Note that if you click on a message name, it immediately
shows you all implementations of that message. Note that color is not
normally preserved when you leave a window (See StandardSystemView
cacheBitsAsTwoTone), so click in the title bar to redisplay."
(FileStream readOnlyFileNamed: dir, 'ColorFormatDemo-di.cs') fileIn.
"Five files roughly described by their names"
(FileStream readOnlyFileNamed:
dir, 'DependentsImprovements.st') fileIn.
(FileStream readOnlyFileNamed: dir, 'FillInBlankFix.st') fileIn.
(FileStream readOnlyFileNamed: dir, 'ObjectReferencesFixes.st') fileIn.
(FileStream readOnlyFileNamed: dir, 'JohnCleanups3.st') fileIn.
(FileStream readOnlyFileNamed: dir, 'JohnCleanups4.st') fileIn.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"This is an executable file. If it is in the same folder as your image,
along with all the other files called out below, you may simply fileIn this
file, and it will in turn fileIn all the others. If these files are in some
other folder that you are browsing with the file list, you can instead use
the fileList fileIn capability to file in the various files, in the order
specified below. Note: it is likely that some of these fileIns will crash if
you have a Transcript open during the operation (since text display code is
being modified)."
"Relative path to the directory where the file-ins are"
| dir |
dir := '../../1.14->1.15 FileIns'.
"Fixes an age-old bug that affected fileIns containing messages categorized
as 'as yet unclassified', and also defines a simpler 'find class' option for
the browser (you just type, eg, 'form', and it finds all the classes that
have those letters in their names."
(FileStream readOnlyFileNamed: dir, 'TwoFixes-di.cs') fileIn.
"Four minor improvements..."
(FileStream readOnlyFileNamed: dir, 'ColonFix-di.st') fileIn.
(FileStream readOnlyFileNamed: dir, 'BetterCornerCtl-di.st') fileIn.
(FileStream readOnlyFileNamed: dir, 'DebuggerFlushKbd-di.st') fileIn.
(FileStream readOnlyFileNamed: dir, 'FasterBorders-di.cs') fileIn.
"Reworks text display so that it does not clear ahead. No more flashes
during type-in."
(FileStream readOnlyFileNamed: dir, 'NoFlashText-di.cs') fileIn.
"Defines NullColor, and reworks text display to support transparency. There
is an example in DisplayText class."
(FileStream readOnlyFileNamed: dir, 'TransparentText-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'TransparentFix-di.cs') fileIn.
"A complete overhaul of Text, so as to support arbitrary decorations as
objects in the run codes. In particular, enables color and active text"
(FileStream readOnlyFileNamed: dir, 'TextStyleMods-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'Text class-initialize.st') fileIn.
"A new overview to recent items in the changes log"
(FileStream readOnlyFileNamed: dir, 'ChangesChanges-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'ChangesChanges2-di.cs') fileIn.
"A bunch of improvements to StikeFont to better support file I/O, especially
from BitFont. Also defines a couple of methods that allow storing a whole
font family as a subclass that can be filed in just like any other class.
The second file is just such a class."
(FileStream readOnlyFileNamed: dir, 'FontWork-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'NewYork.st') fileIn.
"An overhaul of Paragraph and TextScanners that introduces automatic line
spacing, thus enabling greater facility to handle, eg, headings in text
without the need to put them in separate paragraphs. Existing paragraphs in
your system may not feel this change (or at least not in a positive manner).
Choosing window...collapse-all, followed by expand-all should help. You may
want to read the command key summary in the screen-menu help choices."
(FileStream readOnlyFileNamed: dir, 'AutoLineHeight1-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'AutoLineHeight2-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'AutoLineHeight3-di.cs') fileIn.
(FileStream readOnlyFileNamed: dir, 'LineHeightTweaks-di.cs') fileIn.
StrikeFont hackDefaultStyle. "Installs fonts 1-4"
"Two minor interpreter changes. One fixes a long-standing off-by-1 bug that
affected the exact bounds of the screen update after a bitblt of the screen
onto itself, as when scrolling, in positive x or y direction. Also
simplifies the alignment of sub-sampling coordinates when WarpBlt is doing
smoothing. Note: these changes affect only the virtual machine
specification, and will not take effect in your Squeak unless you rebuild or
otherwise obtain an updated interpreter."
(FileStream readOnlyFileNamed: dir, 'BBandWarpFixes-di.cs') fileIn.
"Moves most functionality of SelectionMenu up into PopUpMenu"
(FileStream readOnlyFileNamed: dir, 'MenuExtensions.cs') fileIn.
"Defines a pluggable ListView as a start in cleaning up the old MVC in this
system"
(FileStream readOnlyFileNamed: dir, 'PluggableListView.st') fileIn.
"A number of small cleanups and additions"
(FileStream readOnlyFileNamed: dir, 'TextStuff.cs') fileIn.
"Some more fixes relating mostly to Paragraph compositionRectangle"
(FileStream readOnlyFileNamed: dir, 'AutoLHTweaks-di.cs') fileIn.
"Reinstate template for metaclass instvars (but dont use it ;-) "
(FileStream readOnlyFileNamed: dir, 'Metaclass-definition.st') fileIn.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Nov 07 9:41:01 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Organizing the Squeak source code archives
In setting up the Squeak source code archives, I'd like to invite
suggestions as to how to organize the contributions. One option would be to
follow the practices used on the UIUC Smalltalk archive--using catalog card
files and having the packages organized by author--and another would be to
have each source file accompanied by a .doc file (as in my goodies
collection), and to have these organized by "package" (e.g., collections,
GUI, I/O, sound, etc.).
Does anyone see any real advantages to the first approach?
stp
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Nov 07 10:12:44 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: stp@create.ucsb.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <9611071740.AA04522@tango.create.ucsb.edu> (stp@create.ucsb.edu)
Subject: Re: Organizing the Squeak source code archives
> One option would be to follow the practices used on the UIUC Smalltalk
> archive--using catalog card files and having the packages organized by
> author--and another would be to have each source file accompanied by a .doc
> file (as in my goodies collection), and to have these organized by
> "package" (e.g., collections, GUI, I/O, sound, etc.).
> Does anyone see any real advantages to the first approach?
I don't see any difference between a catalogue card and a .doc file, as long
as your .doc file includes the equivalents of the essentials from the
catalogue card (the author's details and email, any copyright statement, and
the VERSION and PRE-REQUISITES [other goodies] that are needed to file-in the
goodie -- a goodie is practically useless if it has any dependencies and is
not accompanied by these last two pieces of information).
Sorting by "package" is more sensible.
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 07 11:53:32 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: stp@create.ucsb.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <9611071740.AA04522@tango.create.ucsb.edu> (stp@create.ucsb.edu)
Subject: Re: Organizing the Squeak source code archives
Hang on, I just remembered something...
> One option would be to follow the practices used on the UIUC Smalltalk
> archive--using catalog card files
I don't know what the UIUC are doing now, but in the old Mushroom archive
days the "catalogue cards" were *not* separate files -- they were comments,
with a well-defined and *indexable* layout, at the top of the goodies
themselves, and were completely transparent to filing in. If this is what
you mean by "catalog cards" then it's far better than having a separate .doc
file. For example:
- the goodie will *never* become detached from its accompanying
documentation;
- an indexing program (for a www front-end, or a regular "new
goodies" mail shot, or whatever) would not depend on a
human remembering to use (or specify) the correct name of
the source file for (or in) the .doc file.
I would strongly suggest the use of an "itegrated catalogue card" scheme, if
only for indexing and for short descriptions (including the prerequisites,
etc, that I mentioned earlier). If more extensive documentation is required
(how to use a framework, or whatever) then this can certainly be put in a
separate file.
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 07 9:41:03 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Prioritizing What Squeak Needs
Hello!
I've been working on porting my old Smalltalk "goodies" over to Squeak, and
have developed an informal "to-do list" of the things I'd like to see in the
system. My idea in distributing it would be that interested developers chip
in and avoid further duplication of effort (Like JM and me both working on
mail readers, then on pluggable list views). My hope is that we could all
work together and make the system more "competitive" by year's end or so.
Each item in the list below is prioritized (subjectively, or course) on a
scale of 1-3 where 1 means "real important" and 3 means "desirable." The
second item in each line is the "package" impacted by the change.
(1) [Lang] Exception handling (ANSI or PPS model?)
(1) [Lang] Block temporaries (e.g., [ | temp | ... ]
(1) [I/O] Sockets, TCP/IP, etc.
(1) [VM] Squeak access to function & cursor keys
(1) [Env] Package Browser (AKA 6-Paned Browser)*
(1) [Env] Protocol Browser*
(2) [GUI] Pluggable MVC classes (partially done in the recent updates)
(2) [Env] Workspace Variables (AKA Environments)
(2) [Sys] Real-time Scheduler*
(2) [GUI] Display List graphics classes*
(3) [I/O] Unix coprocesses
(3) [Env] Better change/source code manager (using packages)
(3) [GUI] Newer look-and-feel (debatable)
(3) [I/O] Transparent CR/LF handling*
* means I'm working on it and expect to be able to release it in a week or so.
If other users contribute, I'll maintain a "master" list on the CREATE ftp site.
...comments/additions are invited...
stp
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Nov 07 12:34:03 pm
From: Ian Piumarta <piumarta@prof.inria.fr>
To: stp@create.ucsb.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <9611071740.AA04515@tango.create.ucsb.edu> (stp@create.ucsb.edu)
Subject: Re: Prioritizing What Squeak Needs
Just some random musings...
> (1) [Lang] Block temporaries (e.g., [ | temp | ... ]
The dialiect of Smalltalk in Squeak is very old. There is a lot more than
just adding temporaries that is needed to bring it up to date. But Block
problems are certainly top of the list. They should be made into proper
closures: local temporaries, no more unpleasant "aliasing" effects due to
blocks and methods sharing arguments, and removing any need for that
unforgivable #fixTemps kludge.
The changes would affect both the VI and the VM, but are not unrealistically
hard to do. The BlockClosure class would not be large, and the handful of
extra bytecodes required are trivial to implement. What would be harder are
the changes to the compiler. The encoder would have to be extended to manage
lexical scopes, and to do the job properly would require some non-trivial
analysis of variable usage to detect which free variables in a block need not
be shared with their defining scope. This isn't really difficult, it's just
that there are a lot of cases to consider, and being sure that the code is
correct is difficult.
I have written several Smalltalk compilers that treat blocks properly. One
day I might have a go at adding a Blue-Book-ish back end to one of them and
incorporating it into Squeak.
> (3) [GUI] Newer look-and-feel (debatable)
At the time that Squeak appeared, I was 2.5 months into my "free Smalltalk"
project. (I had corrected and/or rewritten large parts of the GNU class
library, extended it with a lot of missing classes, added a compiler written
in Smalltalk and an image-side interpreter (as part of Context) for
debugging, and was in the process of finishing the first version of a highly
portable, high-performance VM.) What's relevant from this effort is the
GUI...
I have a Smalltalk UI framework which is connected to Tk. To Smalltalk
programs it can look very similar to the old MVC style except that Views and
Controllers are merged into one "interactor"-like thing. (I am told that
this is similar to what Dolphin intend to do in their next release, with
their MVP paradigm.) What is surprising is that it is very easy to write
wrappers around the basic widgets to change radically the way the UI is put
together: I currently have both a very Tk-oriented style where all the
interaction with the "model" is through callbacks (which are just blocks that
you plug into the interactors, and which are evaluated when interaction
happens), and a more MVC-like style where the user interaction is connected
to the model through dependencies. These two coexist quite happily. One of
my personal medium-term goals is to put this framework into Squeak, and make
the old Forms thing largely redundant. (One thing which cannot be denied is
that, with the right resource settings [which are *not* the defaults], Tk
looks *very* nice on the screen -- nicer than any commercially available
Smalltalk that I know.)
Oh yes, you get canvases with your "Small/Tk" too! ;-)
> ...comments/additions are invited...
How about a high-performance, highly portable VM? With the right engineering
you can push 50% the speed of the best dynamic translation to native code,
*without* making the portability sacrifices that dynamic translation implies.
Have to dash...
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 07 3:24:33 pm
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Re: Prioritizing What Squeak Needs
I forgot one important item:
(2) [I/O] MIDI I/O
_Stephen Travis Pope, Center for Research in Electronic Art Technology
_(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
_Editor, Computer Music Journal (CMJ), MIT Press
_stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 08 7:59:53 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: File In Scripts for 1.13 -> 1.15 Updates
For those of you who haven't discovered it yet, there is a slight error
(missing filename delimiter) in the file-in scripts I sent out yesterday. The
assignment should read,
"Relative path to the directory where the file-ins are"
| dir |
dir :=
'../../1.13->1.14 FileIns/'. "Or wherever you have them"
stp
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Nov 08 9:37:43 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Another "missing feature"
Another important "feature" for the VMs on multi-process OSs
(1) [VM] Make the VM a "good citizen" on Unix (i.e., go to sleep after 15 sec with no events)
stp
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Nov 08 9:40:26 am
From: stp (Stephen Travis Pope)
To: users
Cc: squeak@create.ucsb.edu, waveframe-users@create.ucsb.edu,
mxv-users@create.ucsb.edu
Subject: Mailing List Archives at CREATE
Hello!
The 3 new mailing lists at CREATE now have archives. This means there are
files you can get via email that are monthly collections of all the traffic
on the mailing list. We intend to turn these into web pages in the near future.
To see what files are available for a given list (e.g., squeak), send a
message to majordomo@create.ucsb.edu with the message body
index squeak
for more help, send the message
help
end
to majordomo@create.ucsb.edu. The 3 current mailing lists are squeak,
waveframe-users, and mxv-users.
stp
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Nov 08 9:43:54 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: stp@create.ucsb.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <9611081737.AA10552@tango.create.ucsb.edu> (stp@create.ucsb.edu)
Subject: Re: Another "missing feature"
> Another important "feature" for the VMs on multi-process OSs
>
> (1) [VM] Make the VM a "good citizen" on Unix (i.e., go to sleep after 15 sec with no events)
Wouldn't it be better to turn the whole thing around, so that Squeak is
properly event driven. That way when there are no events pending Squeak goes
to sleep immediately. There are several issues here, including:
- the interrupt key would need special treatment. One possibility
would be to have a high priority process in Squeak waiting on an
interrupt sempahore;
- timing (delays, sound support, etc.) would have to be redesigned to
use "timing events" instead of polling the millisecond clock.
Again, a high-priority process could service these;
- etc.
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 08 10:09:14 am
From: stp (Stephen Travis Pope)
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: squeak@create.ucsb.edu
In-Reply-To: Ian Piumarta <piumarta@prof.inria.fr>'s letter of: 96 Nov 08
Subject: Re: Another "missing feature"
>> Another important "feature" for the VMs on multi-process OSs
>>
>> (1) [VM] Make the VM a "good citizen" on Unix (i.e., go to sleep after 15 sec with no events)
>Wouldn't it be better to turn the whole thing around, so that Squeak is
>properly event driven
It's actualy even more complicated, because one wants to be able to have
"background" processes (like real-time schedulers) going on...
stp
_Stephen Travis Pope, Center for Research in Electronic Art Technology
_(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
_Editor, Computer Music Journal (CMJ), MIT Press
_stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 09 3:52:43 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: STP V.11 System FileIns
Hello all,
I just up-loaded my basic system file-in "goodies" to the CREATE ftp site.
They're in the directory ftp.create.ucsb.edu/pub/Smalltalk/Squeak/sources/system.
There are two files: one uuencoded, compressed, tar file for UNIX users, and
a BinHexed self-extracting archive for Macintosh users. There's a README
file/file-in script after the style of the recent Squeak upgrades. I include
it below.
Comments are invited...
stp
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"STP V11 FileIns -- LastEditDate: 1996.11.08"
"Relative path to the directory wiere the file-ins are"
| dir |
dir := '../Source/System/'.
"A couple of useful behavior messages: allSubInstances and sortedSubclasses"
(FileStream readOnlyFileNamed: dir, 'Behavior.st') fileIn.
"Adds a format for immediate dictionaries and a case statement; a neat
example, but don't use it too often. Usage example:
( (#a -> [Transcript cr; show: 'a'; cr]),
(#b -> [Transcript cr; show: 'b'; cr]),
(#c -> [Transcript cr; show: 'c'; cr])
) case: #b"
(FileStream readOnlyFileNamed: dir, 'CaseStatement.st') fileIn.
"Several useful collection extensions--second, third, etc., with:with:with:with:with:, etc."
(FileStream readOnlyFileNamed: dir, 'CollectionAdds.st') fileIn.
"A few modified printing methods: Time without seconds, Dates with leading
0's (e.g., 1995.04.08), and short-hand to print LimitedPrecisionReals with a
given precision."
(FileStream readOnlyFileNamed: dir, 'Printing.st') fileIn.
"A few new messages for generating random numbers in limited ranges, or
selecting from collections at random."
(FileStream readOnlyFileNamed: dir, 'RandomAdds.st') fileIn.
"Adds the method safeHalt to Object that's a LeftShiftHack of self
halt--very useful. The idea is from Jim Robertson. Also adds several useful
annotation methods (i.e., they're np-ops) such as todo, todo: aString, and
canBeOptimized. These ideas come from Bill Shauck and Jeff Eastman."
(FileStream readOnlyFileNamed: dir, 'SafeHalt.st') fileIn.
"Adds a few utility methods to class DisplayScreen for determining the
current screen size and getting default rectangles for view opening. This is
very useful for applications that are supposed to be portable between desk-
and lap-top machines."
(FileStream readOnlyFileNamed: dir, 'ScreenAdds.st') fileIn.
"Code to support external I/O in floats, longs, 96-bit doubles, etc. Some of
this is from the Kyma system thanks to Kurt Hebel."
(FileStream readOnlyFileNamed: dir, 'StreamIO.st') fileIn.
"Adds many useful string crunching methods--stripTrailingSpaces, padTo:,
clipTo:, breakIntoLinesOf:, stripCRs. cr."
(FileStream readOnlyFileNamed: dir, 'StringAdds.st') fileIn.
"3-D points, i.e., one can say 3@4@7."
(FileStream readOnlyFileNamed: dir, 'ZPoint.st') fileIn.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Nov 09 1:39:48 pm
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: squeak@create.ucsb.edu
Subject: No cursor in Win95? Sound?
I've just downloaded the Win95 Squeak, and I'm trying it on an unusual
system (DOS card in a PowerMac 6100/66). So, I don't know to what to
attribute some unusual behavior I'm seeing: Something I'm doing wrong, my
weird set-up, or the system.
- Are other people getting a text cursor in the Win95 Squeak? I've got a
mouse cursor, but no little up arrow showing me the text entry point.
- When I tried the sound demo in Win95 Squeak, it asked me if I wanted to
start the sound processor, then hung. Frozen mouse.
Thanks!
Mark
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Date: 96 Nov 10 11:36:39 am
From: Patrick Logan <plogan@teleport.com>
To: guzdial@cc.gatech.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <v02130500aeaaa70e6073@[130.207.3.225]> (guzdial@cc.gatech.edu)
Subject: Re: No cursor in Win95? Sound?
- Are other people getting a text cursor in the Win95 Squeak? I've
got a mouse cursor, but no little up arrow showing me the text
entry point.
I am not getting a cursor in, e.g. a workspace, on Win NT 3.51.
It does show up in some places, e.g. a dialog box.
- When I tried the sound demo in Win95 Squeak, it asked me if I
wanted to start the sound processor, then hung. Frozen mouse.
I have not tried it on my Win95+sound system yet. My NT system has no
sound card, so no info yet.
-Patrick Logan, plogan@teleport.com
Date: 96 Nov 10 10:01:39 pm
From: DanI@wdi.disney.com (Dan Ingalls)
To: squeak@create.ucsb.edu
Subject: Working Together
I wanted to establish (but also solicit) some context regarding how we all
can best work together. It's a bit of a ramble, but probably more useful
than silence.
I think as a start I will try to outline what we (the squeak team) are
interested in and likely to do in the coming weeks and months, then a bit
about what we would love to see others contribute, and finally a bit about
the process of working together.
Things we are already working on that will likely show up in the next month
or two:
1. Extending # of inst vars per class to 255
2. Extending # literals per method to 255
3. Making Views pluggable and cleaning up our existing
applications by converting over.
4. Folding in the suggestions and code that we have received
toward making Squeak more easily portable.
5. Putting secondary dispatch into arithmetic to clean up
and speed up the coercion process.
Things we are interested in but would like help with:
1. Getting MIDI I/O to work
2. Access to Mail Servers so we can start to do E-mail
direct from Smalltalk. (sounds like we have at least
3 mail systems in various states of completion).
3. Same for WWW access so we can start to surf from Smalltalk.
4. More work on music - a reverb "player", and some support for
decent "patches" that include envelopes.
5. Basic 3-D facility.
6. More work on WarpBlt that might allow pan and zoom around
360-degree surrounding images.
7. A high-performance (but still portable) execution engine.
Our current orientation is to keep the Squeak UIF "native" -- that is to
say that it does all its own graphics so it ports easily (including to
chips with no OS) and looks and works the same everywhere. At the same
time, we could have the best of both worlds if we evolved to a
platform-independent layer that then had a number of different front ends:
All-Squeak, Windows toolbox, Max toolbox, X, etc.(is this how Ian's TK work
should fit in? (I'd like to hear more about it). If someone has a proposal
for such an architecture, I'd like to hear it.
I am personally interested in doing a type system, partly in service of our
C translation, but mainly for navigation, assisting novices, and throwing
out unneeded code in stand-alone applications. My idea of a type system is
one that you never HAVE TO tell anything to, but that can understand and
perhaps correct anything that you do tell it. [You can guess that it would
start out looking a lot like the one that Alan Borning and I wrote, back in
'81].
The Squeak team has an interest in doing the world's simplest application
construction framework, but I suspect that we will get sucked up with
enough other things that this won't happen in the next two months (but who
knows...).
Mechanics: Here's how the Squeak group works together: we all submit
goodies, and try each others' out. Then periodically someone (usually me)
puts together everything that is deemed to be smaller, faster or better
(and preferably all 3), and we make a release.
We could try for a while to do just the same in the Squeak community at
large. Namely submit a goodie, and send a message out saying what's good
about it. What doesn't scale is for me to try everything out as well as do
the integration. I propose that we slow down the Squeak team releases to
once every 2 or three months. It is then my hope that the community at
large will be trying out the goodies, selecting what is good, rejecting
what isn't ready, and discovering what is needed to integrate them
reasonbly. Then, when we're ready to do another release, we can fairly
quickly choose what to include, and know that most of it has been
reasonably tested.
I could even imagine that one of Y'ALL out there might make a hobby of
keeping track of outstanding goodies so that at any time there was a list
of what can be filed in, in what order, and be known to work together and
do wonderful new things.
There was mention in recent messages of how to do the indexing, and I must
say that (although we haven't been doing this) I like the convention of
beginning every goodie with a comment section describing what it does, what
it depends on, what it changes, etc. This is nice because, if you work in
a LAN-like environment with others, then you can just use the FileList to
browse files on the server, getting both the code and its description in
one click. Later, if someone wants to assemble a catalog, it's simple to
do, and could even be done by a program if we observe some convention about
a single header comment.
About priorities...
Let's face it, we will all have different priorities.
I think I can speak for most of the Squeak team in saying that our top
priorities (not ordered; all top) are
1. Getting networked (e-mail and web access first, then actual
interactive, and object-passing traffic).
2. Performance as always.
3. Cleaning up the UIF classes (at least end up with a "clean MVC",
but maybe something cleaner and better still, for instance
event-driven, with separate change and update processes,
with damage rectangles and double-buffered display update).
We have other "content" goals, like end-user programming, educational and
entertaining apps, but these will probably not go out publicly, except on
occasion (as we did with the early version of HyperSqueak).
By the way, about HyperSqueak: we may well stop distributing it with every
release (we would have with 1.16, except it was easier to leave it in). It
uses space, and confuses the folks who are just wanting a decent Smalltalk.
Also we probably won't be updating it each time, except possibly to
release another major step some time in the future.
A lot of things can go on pretty independently, but some things require
what we in the Squeak team refer to as seizing the baton. In other words,
some changes are major enough that you have to seize the whole system,
perform major surgery on it that is not fileIn-able, and finally produce a
new (improved) system that may well have a different image format and
require a new VM to run it. Let's try to make a distinction between
compatible goodies, and this kind of change. Ian's suggested changes to
Blocks fall into this major category.
I would like to start a thread here on how to get some real performance out
of Squeak. It seems like we have 4 performance points right now:
0.1 Where squeak is
0.5 Where Squeak ought to be
1.0 Where commercial Smalltalks are
3.0 The Animorphic VM
The numbers are approximate, but I don't want to quibble. I think that
Squeak can be made to run about four times faster without compromising its
portability, and without adding a lot of complexity.
I don't think it makes sense to try to go much farther unless it can be
done equally simply. My experience is that critical applications (serious
music, video, etc) will require on application-specific primitives anyway,
and for mainstream develoment, I find squeak already to be mighty
productive (I run on a 100 mhz mac, which is ho-hum these days).
Does anyone think they have a breakthorough approach to apply? Is anyone
ready to tackle doing a high performance VM? This is an area the Squeak
team would love to hand off to someone else if we thought they could do it,
because our plates are already full. If there is willingness, but no
design, I will suggest a design, but mine is pretty conventional, and I
can't see it getting more than a factor of 3 or 4 over the current
performance.
Date: 96 Nov 11 1:14:19 am
From: gollmann@edvz.tuwien.ac.at (Georg Gollmann)
To: squeak@create.ucsb.edu
Subject: Re: Working Together
At 22:04 Uhr 10.11.1996, Dan Ingalls wrote:
> 2. Access to Mail Servers so we can start to do E-mail
> direct from Smalltalk. (sounds like we have at least
> 3 mail systems in various states of completion).
> 3. Same for WWW access so we can start to surf from Smalltalk.
On a related topic: I would like to port my adaptive newsreader (aka
NewsAgent) to Squeak once TCP/IP is implemented.
Georg
----
Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum
phon:(++43-1) 58801 - 5848
mail:gollmann@edvz.tuwien.ac.at
http://ftp.tuwien.ac.at/~go/Gollmann.html
Date: 96 Nov 11 11:20:37 am
From: stp@tango (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Squeak mailing list as a Web Page
Hello all,
I wrote a small script (in Smalltalk , of course) that takes our mailing list
archive and converts it into an indexed web page.
The page is currently at http://www.create.ucsb.edu/squeak/9611.html.
I'll update it every few days, or as the traffic warrants.
Suggestions are invited.
stp
__Stephen Travis Pope
__Center for Research in Electronic Art Technology (CREATE)
__Dept. of Music, U. C. Santa Barbara
__Editor--Computer Music Journal, MIT Press
__stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 11 1:10:12 pm
From: John Maloney <johnm@wdi.disney.com>
To: Patrick Logan <plogan@teleport.com>, guzdial@cc.gatech.edu
Cc: squeak@create.ucsb.edu
Subject: Re: No cursor in Win95? Sound?
Mark and Patrick:
Thanks for problem reports.
> I am not getting a cursor in, e.g. a workspace, on Win NT 3.51.
> It does show up in some places, e.g. a dialog box.
This could be a color problem (i.e. the cursor is the same
color as the background). Try setting your display to monochrome
by executing "Display newDepth: 1" and let me know if the
cursor appears.
> When I tried the sound demo in Win95 Squeak, it asked me if I
> wanted to start the sound processor, then hung. Frozen mouse.
>From looking at the source code, it appears that the sampling
rate should be 11025, 22050, or 44100 and the buffer size should
be 16384 for mono or 8192 for stereo. You can edit the parameters
in SoundPlayer startUp before trying the sound examples. Let
us know if you find a set of parameters that works for you.
(I'd start with mono at 11025 and work up from there.)
-- John
Date: 96 Nov 11 1:10:30 pm
From: John Maloney <johnm@wdi.disney.com>
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: squeak@create.ucsb.edu
Subject: Squeak VM Performance
Re:
How about a high-performance, highly portable VM? With the right
engineering you can push 50% the speed of the best dynamic translation
to native code, *without* making the portability sacrifices that dynamic
translation implies.
Are you thinking of Eliot Miranda's techniques, perhaps? We've been considering
using those! I've also been pondering two others approachs to the problem that
may yield most of the performance with even less complexity. (Both ideas
involve redesigned bytecode interpreters.)
Here is my mental picture of the implementation technique versus speed graph
for Smalltalk. It is normalized to the speed of C on a set of C-like benchmarks,
such as matrix multiply and tight loops.
Bytecode Interpreter (e.g. Squeak) 60-75 times slower than C
Redesigned Bytecode Set (e.g. ST/V Mac) 20-25 times slower than C
Portable Threaded Code (e.g. BrouHaHa) 10-12 times slower than C (my guess)
Native Dynamic Translator (e.g. ObjectWorks) 6-10 times slower than C
Dynamic Optimization (e.g. Animorphic) 2-5 times slower than C (my guess)
The Animorphic Smalltalk stunned the Smalltalk implementation community
at the last OOPSLA by demonstrating performance 2-4 times that of the faster
existing Smalltalk. They use the dynamic optimization techniques pioneered
by the Self group.
We want to find the right balance between portability, simplicity (which
aids understanding and contributes toward reliability), performance, and
small memory footprint.
-- John
Date: 96 Nov 11 1:10:32 pm
From: John Maloney <johnm@wdi.disney.com>
To: stp@create.ucsb.edu (Stephen Travis Pope)
Cc: Ian Piumarta <piumarta@prof.inria.fr>
squeak@create.ucsb.edu
John Maloney <johnm@wdi.disney.com>
Subject: Re: Another "missing feature"
> > Wouldn't it be better to turn the whole thing around, so that Squeak is
> > properly event driven
>
> It's actualy even more complicated, because one wants to be able to have
> "background" processes (like real-time schedulers) going on...
Our plan is the make user inputs be event driven, but to allow background
processes. Presumably if your background processes are important, you don't
mind using cycles on them. If they aren't, you would add delays to them to
slow them down. (For example, a background process that checks the mail
might run only every 10 minutes. One that updates a clock might run only
once per second.)
We haven't yet figured out the best platform independent way to implement
this, however. Suggestions are welcome...
-- John
Date: 96 Nov 11 2:43:10 pm
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
Cc: squeak@create.ucsb.edu
Subject: Re[2]: No cursor in Win95? Sound?
>> I am not getting a cursor in, e.g. a workspace, on Win NT
>> 3.51.
>> It does show up in some places, e.g. a dialog box.
>
>This could be a color problem (i.e. the cursor is the same
>color as the background). Try setting your display to monochrome
>by executing "Display newDepth: 1" and let me know if the
>cursor appears.
The cursor shows up in B&W, so it does appear to be the problem.
-Patrick Logan
Date: 96 Nov 11 6:58:42 pm
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: John Maloney <johnm@wdi.disney.com>
Cc: squeak@create.ucsb.edu
Subject: Re: No cursor in Win95? Sound?
>> I am not getting a cursor in, e.g. a workspace, on Win NT 3.51.
>> It does show up in some places, e.g. a dialog box.
>
>This could be a color problem (i.e. the cursor is the same
>color as the background). Try setting your display to monochrome
>by executing "Display newDepth: 1" and let me know if the
>cursor appears.
This worked for me! I can now see the cursor. Thanks!
Mark
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Date: 96 Nov 11 7:21:05 pm
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: DanI@wdi.disney.com (Dan Ingalls), squeak@create.ucsb.edu
Subject: Re: Working Together
WOW! This is a pretty exciting list!
For myself, I don't expect to be helping at this level of development in
the near term, but I am actively looking for ways to use Squeak in my
research and teaching.
- I lead a seminar at Georgia Tech in educational technology. Two weeks
ago, I gave a talk where I demonstrated Squeak and used "Line example" to
draw a line between two inactive windows. For grad students who have grown
up on the Mac, Windows, and X-Windows, this was a little disconcerting --
there was a line right across the boundaries of the window!! We then had a
very interesting discussion about something that got lost when GUIs moved
from Parc to Apple: The notion that the user controlled the windows, could
make them into something else, and even write over them. We're continuing
to talk about the power of Squeak for exploring non- or alternative-GUI
interfaces; and learning environments where the student has greater control
over the environment and interface. (We read "The Anti-Mac Interface" by
Gentner and Nielson from CACM -- it's interesting how much of the
"Anti-Mac" interface was in ST-80, the predecessor of the Mac.)
- I teach a Sophmore level class on OOA, OOD, and OOP. I've proposed
dropping VisualWorks next year in favor of Squeak. The biggest factor for
me, as a teacher, is that the HCI framework is so much simpler and cleaner.
I don't go into much depth on building interfaces in VisualWorks -- we're
on the quarter system, and in only ten weeks, I can't introduce MVC *and*
deal with the pluggability extensions, while also exploring OOA and OOD
methodology and helping students learn Smalltalk. I think that the basic
MVC model of Squeak will be easier to grasp, though arguments are being
made preferring VisualWorks for its tools and greater functionality.
Of your list, the tie to WWW is the most exciting for me. I have a set of
learning tools already (e.g., case library of Smalltalk projects; a
Web-based collaboration tool). I'd love to be able to deeply integrate
them into Squeak, so that the cases are available within the development
environment.
Thanks to all the members of the Squeak team -- this is a very exciting tool!
Mark
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Date: 96 Nov 12 5:13:24 am
From: Stephen Travis Pope <stp@create.ucsb.edu>
To: squeak@create.ucsb.edu
Subject: Working Together
I, too, am excited by Dan's ideas, and would like to offer the following comments.
> Making Squeak more easily portable
I believe that it's quite important to maintain complete binary virtual image
portability (rather than source code portability). I move frequently between a
number of platforms, and *love* being able to ftp images between architectures.
The only way I can think of to achieve this is to have some form of "return-from-
snapshot installation" and "abstract begets concrete" in the form that ParcPlace
uses in their VI. This would entail making classes that are likely to have platform
dependencies (file streams, cusrors, fonts, etc.) be abstract, and having their
concrete subclasses instantiated at run-time to be the right (platform compilant)
ones. (For example, [FileStream named: 'output'] might give you a MacFileStream or
a UNIXFileStream).
We also need some primitive to identify the run-time environment, such as a call
that returns an array of strings with the processor, OS, version, and window system,
e.g.,
#('PowerPC' ' MacOS' '7.5.5' 'Mac')
or
#('SPARC' 'Solaris' '2.5.1' 'X11R6')
> WWW access
How about porting the existing freeware HTML renderer in Smalltalk to Squeak?
> Basic 3-D facility
I have Hans-Martin Mosner's old 3-D wire-frame code almost working.
> A high-performance (but still portable) execution engine
Ah the Holy Grail!
> I am personally interested in doing a type system
The Animorphic system--StrongTalk--is written all in Smalltalk, and the details were
published at OOPSLA several years before they went commercial.
> Mechanics: Here's how the Squeak group works together
> ...
> I could even imagine that one of Y'ALL out there might make a hobby of
> keeping track of outstanding goodies
I'll volunteer (in my copious free time next to my 3 "day" jobs) to maintain file-in
directories between releases, so that users can get the "current" set of proposed
file-ins for comment. If users submit goodies with .doc files (or emailed descriptions),
I'll set up and update file-in scripts on the CREATE ftp server.
> Squeak can be made to run about four times faster without compromising its
> portability, and without adding a lot of complexity.
NOW you have my attention!
> Does anyone think they have a breakthrough approach to apply?
(1) A bytecode interpreter will always be much simpler and more portable than a dynamic
compiler (now called just-in-time compilers by the Java marketing types).
(2) Most of the speed of the Animorphic system comes from clever usage of polymorphic
inline caches (the Self-93 idea, Urs Hoelzle's thesis). Urs is at UCSB now, and I'm
leaning strongly on him to get more involved.
(3) I think making a portable dynamic compiler is a great master's thesis project;
if anyone wants to try, apply to UCSB today!
Lastly, I'd like to thank the Squeak team for doing this. It has really revived my
excitement for Smalltalk.
Does anyone have a logo for Squeak that we can use on the mailing list web page?
stp
__Stephen Travis Pope
__Center for Research in Electronic Art Technology (CREATE)
__Dept. of Music, U. C. Santa Barbara
__Editor--Computer Music Journal, MIT Press
__stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 12 6:14:03 am
From: johnson@cs.uiuc.edu (Ralph E. Johnson)
To: squeak@create.ucsb.edu
Subject: Re: Another "missing feature"
At 1:14 PM 11/11/96, John Maloney wrote:
>Our plan is the make user inputs be event driven, but to allow background
>processes.
>
>We haven't yet figured out the best platform independent way to implement
>this, however. Suggestions are welcome...
"Allow"? Aren't background processes already platform independent?
I assume you are referring to a platform independent event-driven GUI,
not processes. If you have an event-driven GUI, background processes
are no problem.
-Ralph
Date: 96 Nov 12 7:16:25 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: johnm@wdi.disney.com
Cc: squeak@create.ucsb.edu
In-Reply-To: <199611112114.AA25898@bobo.rd.wdi.disney.com> (message from John
Maloney on Mon, 11 Nov 1996 13:14:07 -0800)
Subject: Re: Squeak VM Performance
> Re:
> How about a high-performance, highly portable VM? With the right
> engineering you can push 50% the speed of the best dynamic translation
> to native code, *without* making the portability sacrifices that dynamic
> translation implies.
>
> Are you thinking of Eliot Miranda's techniques, perhaps? We've been considering
> using those! I've also been pondering two others approachs to the problem that
> may yield most of the performance with even less complexity. (Both ideas
> involve redesigned bytecode interpreters.)
This is exactly what I was talking about, with various
extensions/midifications to the techniques.
The VM that I was developing for my "free smalltalk" project has a redesigned
v-code instruction set, and a redesigned approach to CompiledMethods.
Instead of bytescodes+literal frame, the compiler generates an Array of
objects. This array contains instructions, encoded as SmallIntegers, with
the operands inline as real objects. This array corresponds 1-to-1 with the
"translated methods" that the runtime generates on the fly. Instruction
opcodes are converted into threaded code addresses, and the operand objects
are copied verbatim. Amongst other benefits, this approach removes the need
for n-PC to v-PC mapping when converting from the exectuable representation
of contexts (on a stack) into heap-based Smalltalk objects.
I use a two-level caching scheme: point-of-send inline caches in the
translated methods, which are refilled from a comprehensive method cache when
they miss. This "comprehensive cache" is a highly optimised two-level
mapping, class -> selector -> method.
I was intending to use a combination of Eliot's context cache and the
ParcPlace dynamic change of representation, where there would be volatile,
hybrid, and stable contexts. With some hairy compiler analysis, it is
possible to avoid stablising the vast majority of contexts.
I was also considering applying to Smalltalk some of my previous approaches
to Lisp translation -- in particular I think that it might be time to rethink
*entirely* the way that Smalltalk contexts work. They are really two kinds
of object combined into one: an "activation" (which records the current
method, IP, stack pointer, etc., and probably also subsumes the stack for
argument handling and intermediate values) and a "local environment" (which
contains the temporaries of the active method/block). In Smalltalk these two
separate concepts are confused into a single Context object. An important
observation is that it is ONLY the "local environment" part of a context that
ever needs to be stabilised; the "activation" parts are always LIFO, unless
you need to support full continuations of course...
My experiments with Lisp indicate that a very simple interpreter, which does
no analysis on temporary usage to eliminate stabilisation (and which
consequently stabilises *every* "local environment", but *never* the
activation part or stack frames), can acheive considerably better performance
than...
> Portable Threaded Code (e.g. BrouHaHa) 10-12 times slower
> than C (my guess)
...which is a fairly accurate guess. With a threaded-code VM you should be
looking for about 50% the performance of ParcPlace's dynamic translation. My
VM manages 120,000 nfibs calls/second on my IPX, compared to OWST4.1's
220,000. But the macro performance will be different (I don't know which way
yet) because the nfibs benchmark invokves no block handling, and also I
haven't put in any tail call optimisions (which I hope will be possible, but
I've not thought the consequences through yet).
> We want to find the right balance between portability, simplicity (which
> aids understanding and contributes toward reliability), performance, and
> small memory footprint.
My VM experiments have led me to a much simpler approach than Eliot's. Where
he uses two interpreters, I suggest only one. He also goes to painful
lengths to create "global register variables" for the main "registers" of the
translated code. I elide this problem by compiling all the opcode
implementations inside one method, and let the compiler figure out how best
to allocate registers to variables. (After all, it is one of the things that
we "pay" the compiler to do. ;-)
All these techniques are specific to gcc. In particular, my approach depends
on the ability to define and manipulate first-class program labels. (Each
opcode translates into the address of its label within this single method.)
If anyone is interested, I could post a much more comprehensive description
of my VM ideas to this list.
One other possibility would be to translate to native code. The route to
portability here would be to compile Smalltalk into RTL (or some intermediate
representation, and convert this to RTL at runtime) and then use the gcc back
ends to do the native code generation. (There are possible problems with
this approach too, since C calling conventions are not obviously the best for
dynamic languages -- in particular, tail-call elimination is very diffuclt
[if not impossible] using the gcc back end due to its "caller pops the
arguments" assumption.)
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 12 7:26:38 am
From: Hans-Martin Mosner <hmm@heeg.de>
To: Squeak Mailing List <squeak@create.ucsb.edu>
Subject: Re: Working Together
Stephen Pope wrote:
> (1) A bytecode interpreter will always be much simpler and more
> portable than a dynamic compiler (now called just-in-time compilers by
> the Java marketing types).
Yes, and I would rather prefer the compactness of a properly written
bytecode interpreter. The current situation with microprocessors is such
that with maybe ten processor architectures you have probably 95 or 98
percent of the machines currently in use:
- x86
- 68k
- SPARC
- MIPS R3000/4000
- PPC
- HP-RISC
- DEC Alpha
- (3 slots left open for the CPU families escaping my memory...)
I have a very fast interpreter in mind, whose per-bytecode overhead is
on the order of 5 PPC instructions, with no pipeline stalling.
Having the central interpreter completely in L1 cache is feasible.
> (2) Most of the speed of the Animorphic system comes from clever usage
> of polymorphic inline caches (the Self-93 idea, Urs Hoelzle's thesis).
> Urs is at UCSB now, and I'm leaning strongly on him to get more
> involved.
> (3) I think making a portable dynamic compiler is a great master's
> thesis project; if anyone wants to try, apply to UCSB today!
Please, don't make Squeak into something that can only be loaded on a
64M high-end workstation (I remember trying to run Self on a 16M Sun...
impossible.) I'm quite pleased with Squeak's performance on my lowly
Performa 6200, and making it maybe 2-3 times faster by just writing an
optimized bytecode interpreter and less costly call stack architecture
would be enough for me...
Hans-Martin
--
+--- Hans-Martin Mosner ---- Senior Smalltalk Guru :-) ---+
| These opinions are entirely ficticious. Any similarity |
| to real opinions is purely coincidental and unintended. |
+--- <hmm@heeg.de> ------ URL:http://www.heeg.de/~hmm/ ---+
Date: 96 Nov 12 7:59:21 am
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
To: squeak@create.ucsb.edu
Subject: Re: Working Together
> We also need some primitive to identify the run-time environment,
> such as a call that returns an array of strings with the processor,
> OS, version, and window system, e.g., #('PowerPC' ' MacOS' '7.5.5'
> 'Mac') or #('SPARC' 'Solaris' '2.5.1' 'X11R6')
How about an object with messages, rather than an array with fixed
positions? I mean, the first thing I'd do with the array is wrap it in
a class to help me remember which index was what...
SystemInformation>>cpu
^someArray at: 1
...and so on.
-Patrick Logan
Date: 96 Nov 12 8:53:21 am
From: stp@tango (Stephen Travis Pope)
To: Patrick_D_Logan@ccm2.hf.intel.com
Cc: squeak@create.ucsb.edu
Subject: Re: Working Together
> How about an object with messages, rather than an array with fixed
> positions?
Sounds like a better idea to me! That way, we could
also merge in the user's UNIX shell environment.
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 12 1:06:33 pm
From: Tim Rowledge <rowledge@interval.com>
To: Squeak mailinglist <squeak@create.ucsb.edu>
In-Reply-To: <199611121516.QAA09394@prof.inria.fr>
Subject: Re: Squeak VM Performance
When considering implementation ideas, do remember the enormous cost in
complexity that tends to accompany dynamic translation:-
- you have to understand all the cpus involved
- you have to write a portable system to generate code for them
- you have to manipulate the instruction and data caches directly to
maintain coherency in a manner that is usually not intended by the cpu
makers and that changes every ^&%$ issue of the chip.
- you have to maintain a cache of translated code and manage it
- it takes a lot of space (usually)
- it is a big job to create and a bigger one to maintain
I speak from a modicum of experience in working with several
implementations, writing a VW dynamic translator for the ARM cpu and
having been manager of Smalltalk dev. at PPS for a while. So maybe my
perspective is a little skewed by all the hassles it caused...
My preference, for what it's worth, would be to make the interpreter
as good a possible first, by improving the context handling and
reducing overheads as much as possible. Next would come a look at
direct-to-native compilation (see Ian's thesis for a damn good start)
which I think would provide many benefits akin to dynamic translation
(speed etc) and yet avoid the run-time costs and complexities.
Recompiling a method as a developer takes many milliseconds anyway,
and so the cost of flushing the cpu caches the simple way (usually a
total flush is easy to arrange) is lost. Doing a partial flush many
times per second can sometimes occupy most of that second!
--
Tim Rowledge: rowledge@interval.com (w) +1 415 842-6251(w)
rowledge@hooked.net (h) <http://www.hooked.net/~rowledge>
Date: 96 Nov 12 1:16:32 pm
From: Hans-Martin Mosner <hmm@cww.de>
To: Squeak Mailing List <squeak@create.ucsb.edu>
Subject: A fix for variable line height code
Here's a small fileIn that fixes a bug related to the line height
computation when a FormSetFont is used.
Hans-Martin
---
"Fixes a bug concerning lost descenders when an image is pasted into
text."!
!CompositionScanner methodsFor: 'scanning'!
setActualFont: aFont
"Keep track of max height and ascent for auto lineheight"
| descent |
super setActualFont: aFont.
descent _ lineHeight - baseline max: font descent.
baseline _ baseline max: font ascent.
lineHeight _ lineHeight max: baseline + descent!
setFont: fontNumber
"Keep track of max height and ascent for auto lineheight"
| descent |
super setFont: fontNumber.
descent _ lineHeight - baseline max: font descent.
baseline _ baseline max: font ascent.
lineHeight _ lineHeight max: baseline + descent! !
Date: 96 Nov 12 1:28:21 pm
From: johnson@cs.uiuc.edu (Ralph E. Johnson)
To: squeak@create.ucsb.edu
Subject: Re: Squeak VM Performance
At 4:16 PM 11/12/96, Ian Piumarta wrote:
>I was also considering applying to Smalltalk some of my previous approaches
>to Lisp translation -- in particular I think that it might be time to rethink
>*entirely* the way that Smalltalk contexts work. They are really two kinds
>of object combined into one: an "activation" (which records the current
>method, IP, stack pointer, etc., and probably also subsumes the stack for
>argument handling and intermediate values) and a "local environment" (which
>contains the temporaries of the active method/block). In Smalltalk these two
>separate concepts are confused into a single Context object. An important
>observation is that it is ONLY the "local environment" part of a context that
>ever needs to be stabilised; the "activation" parts are always LIFO, unless
>you need to support full continuations of course...
Blocks with returns in them need to know the activation. This is a
kind of continuation, though not a full continuation. It is traditional
to only allow one return from a context.
If there are no blocks with returns in them, or if all of them are
optimized away (as usually happens with ifTrue:ifFalse:) then you can
treat your activation part LIFO. But I don't see how you can do that
for a context that creates a block with a return in it.
-Ralph
Date: 96 Nov 12 11:35:45 pm
From: John Maloney <johnm@wdi.disney.com>
To: stp@tango.create.ucsb.edu (Stephen Travis Pope)
Cc: squeak@create.ucsb.edu
John Maloney <johnm@wdi.disney.com>
Subject: Re: Squeak mailing list as a Web Page
Re:
I wrote a small script (in Smalltalk , of course) that takes our mailing list
archive and converts it into an indexed web page.
Cool! I love that you wrote it in Smalltalk!
I wonder if there is any way to get comp.lang.object postings about
Squeak into some sort of archive? I'm currently saving some of the
postings in a mail archive but, to be honest, I'm not sure how much
longer I'll be scanning that newsgroup now that we have our own
mailing list.
-- John
Date: 96 Nov 12 11:35:50 pm
From: John Maloney <johnm@wdi.disney.com>
To: johnson@cs.uiuc.edu (Ralph E. Johnson)
Cc: squeak@create.ucsb.edu
John Maloney <johnm@wdi.disney.com>
Subject: Re: Another "missing feature"
Hi, Ralph!
Re: "Allow"? Aren't background processes already platform independent?
Of course they are. What I meant is this. One could (a) make the
entire Sqeak UI be event-drive (as has been done in other Smalltalks) and
(b) arrange for the Smalltalk VM to go to sleep completely between user
events. That is, the VM would just be called from the application
event loop (Mac, Windows) or when an interrupt occured (Unix),
and would have no autonomy. Thus, any Smalltalk processes would
be suspended between user events, whether they wanted to be or not.
However, this is NOT how we want Squeak to work. We want Smalltalk
processes to keep running in between user events, as they do now. We
just don't want the VM to be using up a lot of cycles when there is
nothing to do. It is this "good citizenship" business that seems to be
achieved in different ways on different platforms.
-- John
Date: 96 Nov 12 11:35:59 pm
From: John Maloney <johnm@wdi.disney.com>
To: Hans-Martin Mosner <hmm@heeg.de>
Cc: Squeak Mailing List <squeak@create.ucsb.edu>
John Maloney <johnm@wdi.disney.com>
Subject: Re: Working Together
from Hans-Martin Mosner <hmm@heeg.de>:
> I have a very fast interpreter in mind, whose per-bytecode overhead is
> on the order of 5 PPC instructions, with no pipeline stalling.
> Having the central interpreter completely in L1 cache is feasible.
We're just about there now on a PPC 601/604. I believe our per-bytecode
overhead is 7 PPC instructions after applying the interpreter patch. I
tried keeping the base of the jump table in a register to eliminate another
instruction, but that actually made no difference due to the memory wait
for the bytecode fetch. By measuring the time for a "noop" bytecode, I
found that the dispatch runs at about 10 million dispatches/sec on
a 100 MHz 8100, which is 10 cycles per bytecode. If there are any
PowerPC experts out there, I'd be happy to send you an assembly
dump of the dispatch (i.e. just the key 7 instructions)...
> Please, don't make Squeak into something that can only be loaded on a
> 64M high-end workstation (I remember trying to run Self on a 16M Sun...
> impossible.) I'm quite pleased with Squeak's performance on my lowly
> Performa 6200, and making it maybe 2-3 times faster by just writing an
> optimized bytecode interpreter and less costly call stack architecture
> would be enough for me...
I'm well aware of the space/speed tradeoffs in Self, since I was in
the Self group for nearly four years :->. However, the Animorphic
system shows that good engineering can reduce the space costs
to a very reasonable level. I believe the Animorphic Smalltalk is about
the same memory footprint as the current commercial Smalltalks.
(It's VM is probably a bit larger, but its image is smaller.)
Still, we want the VM to be simple as well as small, so your point
is well taken.
-- John
Date: 96 Nov 13 3:35:15 am
From: johnson@cs.uiuc.edu (Ralph E. Johnson)
To: John Maloney <johnm@wdi.disney.com>
Cc: squeak@create.ucsb.edu
Subject: Re: Another "missing feature"
At 11:39 PM 11/12/96, John Maloney wrote:
>Of course they are. What I meant is this. One could (a) make the
>entire Sqeak UI be event-drive (as has been done in other Smalltalks) and
>(b) arrange for the Smalltalk VM to go to sleep completely between user
>events.
That is a silly way to do it! The right way to do it is to make one
process be the event-loop. It makes a VM call to get the next event,
and blocks until there is one. The VM will run as long as there is a
non-blocked process, and then go to sleep until the next user event.
Given the right operating system features, this isn't hard to do.
The VM handles all I/O, and must only call non-blocking I/O routines.
In other words, whenever it does I/O, it needs to be told whether the
routine has completed or is pending, and if it is pending then it needs
to register to be told when it is finished. It will then block the
Smalltalk process that initiated the I/O. When it is notified that
the I/O is finished, it will unblock the process.
This is all pretty standard operating system stuff, and I would be
happy to discuss it off-line with anybody. The only iffy part is
whether the OS provides non-blocking I/O so that the VM can keep
from blocking until it wants to. I assume that all modern OSes
provide this, but I really only know about Unix.
-Ralph
Date: 96 Nov 13 5:15:40 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: johnson@cs.uiuc.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <v0153052daeaea953d12f@[128.174.23.50]> (johnson@cs.uiuc.edu)
Subject: Re: Squeak VM Performance
> Date: Tue, 12 Nov 1996 16:32:50 -0600
> From: johnson@cs.uiuc.edu (Ralph E. Johnson)
>
> Blocks with returns in them need to know the activation. This is a
> kind of continuation, though not a full continuation. It is traditional
> to only allow one return from a context.
You're right: for blocks you need to keep a pointer to the home context for
truncating the stack during a nonlocal return. There are other details to
consider too, such as how to implement the situation where the block's home
context returns before a nonlocal return in the block. The obvious solution
would be to keep a stabilised "environment part" for both the block and its
home context, even if these had no state (just the home pointer, and the
"I've returned" flag in the home "context"). But with some thought it might
be possible to do better...
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 13 6:55:46 am
From: Hans-Martin Mosner <hmm@heeg.de>
To: Squeak Mailing List <squeak@create.ucsb.edu>
Subject: Re: Squeak VM Performance
Ian Piumarta wrote:
>
> > Date: Tue, 12 Nov 1996 16:32:50 -0600
> > From: johnson@cs.uiuc.edu (Ralph E. Johnson)
> >
> > Blocks with returns in them need to know the activation. This is a
> > kind of continuation, though not a full continuation. It is traditional
> > to only allow one return from a context.
>
> You're right: for blocks you need to keep a pointer to the home context for
> truncating the stack during a nonlocal return. There are other details to
> consider too, such as how to implement the situation where the block's home
> context returns before a nonlocal return in the block. The obvious solution
> would be to keep a stabilised "environment part" for both the block and its
> home context, even if these had no state (just the home pointer, and the
> "I've returned" flag in the home "context"). But with some thought it might
> be possible to do better...
>
> Ian
I'm currently working on a proposal for a solution. In short, this
scheme separates the operand stack from the call frame stack just like
FORTH or PostScript do (but both stacks are maintained in a single
object of class StackSegment), and allocates Context objects only where
needed for variables whose lifetime exceeds that of their context, or
block returns. I'm assuming that this change would be implemented
together with BlockClosures; they need to be implemented anyway. Note
that call frames are not objects, but simply structures of 4 words
managed within the StackSegment object.
A call frame consists of:
- fp: a pointer to the receiver and arguments on the operand stack
- pc: a pointer to the next instruction
- method: the oop of the method involved
- context: the oop of the context for this frame, or nil
On the operand stack, oops are stored in the order in which they are
pushed, so that the pushed receiver and arguments for a message send can
be used directly without being copied into a new Context.
A context object has inst vars for the StackSegment in which its frame
resides, plus a frameIndex into the StackSegment where that frame
begins. To check whether a context has a live frame, you simply look
into its StackSegment at the frameIndex and see whether it's oop is
still there. This does not require additional work when a method
returns. BlockClosures would have a reference to the Context of the
enclosing method. For nested BlockClosures that access variables from
outer contexts, a reference to the outer context must be held. And if a
block references method arguments or the receiver, they must be stored
in the Context as well.
Blocks that do not access outer variables and do not return from their
method can be implemented as clean blocks just as in VW: the
BlockClosure can be created at compile time and stored in the literal
frame of the method.
A distinction between copying and dirty blocks as in VW is not
necessary, because this kind of Context is so lightweight that I don't
think that copying blocks would give a measurable advantage.
The StackSegment scheme somewhat complicates the garbage collector,
because StackSegments would hold an operand stack and a call frame stack
growing into a common free space that is not cleaned up when the stacks
shrink, and the call frame stack would consist of mixed oop and non-oop
data.
There need to be functions to activate/deactivate a StackSegment, which
would map from SmallIntegers for the fp and pc slots to pointers, and
vice versa.
StackSegment would need different at: and at:put: primitives so that
accessing the call frame area and the gap between operand stack and call
stack is handled correctly. There also must be a list of recently used
and freed StackSegments, because StackSegments cannot be simply
garbage-collected when their frame stack becomes empty (Contexts might
still point at them)
Overflow has to be handled (allocate a new StackSegment and copy the
receiver and arguments from the previous one into the new one), as well
as underflow (using a root return frame), but that's not really
difficult.
This is all a lot of work, especially when BlockClosures are mixed in,
but I think it would be worth the extra performance.
Hans-Martin
Date: 96 Nov 13 7:27:07 am
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: Stephen Travis Pope <stp@create.ucsb.edu>, squeak@create.ucsb.edu
Subject: Logo
>Does anyone have a logo for Squeak that we can use on the mailing list web
>page?
Well, my two-year-old claims that "squeak" is what a Mouse says, and the
Squeak team is now at Disney...
Nah, we'd get sued. :-)
Mark
(Robin Williams: "To a two year old, Mickey Mouse is a Six Foot Rat!" :-)
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Date: 96 Nov 13 7:47:46 am
From: stp@tango (Stephen Travis Pope)
To: guzdial@cc.gatech.edu
Cc: squeak@create.ucsb.edu
Subject: Re: Logo
So if I hear the last few suggestions correctly, we
need a picture of Mickey Mouse falling out of a
hot air balloon?
> Nah, we'd get sued. :-)
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 13 9:30:49 am
From: Nickolay Saukh <nms@nns.ru>
To: squeak@create.ucsb.edu
Subject: Time to go international
Is it possible to make Unicode the base charset?
So I would be able to have russian class names, .... ;-)
Thanks
Date: 96 Nov 13 10:00:14 am
From: johnson@cs.uiuc.edu (Ralph E. Johnson)
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: squeak@create.ucsb.edu
Subject: Re: Squeak VM Performance
At 2:16 PM 11/13/96, Ian Piumarta wrote:
>You're right: for blocks you need to keep a pointer to the home context for
>truncating the stack during a nonlocal return. There are other details to
>consider too, such as how to implement the situation where the block's home
>context returns before a nonlocal return in the block. The obvious solution
>would be to keep a stabilised "environment part" for both the block and its
>home context, even if these had no state (just the home pointer, and the
>"I've returned" flag in the home "context").
I think the traditional way to do this is to clear the home pointer when
the block or the home context returns. Thus, a nil home pointer means
"I've returned".
-Ralph
Date: 96 Nov 13 10:03:23 am
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
Cc: squeak@create.ucsb.edu
Subject: Re[2]: Another "missing feature"
Ralph Johnson writes:
>
> This is all pretty standard operating system stuff, and I would be
> happy to discuss it off-line with anybody. The only iffy part is
> whether the OS provides non-blocking I/O so that the VM can keep
> from blocking until it wants to. I assume that all modern OSes
> provide this, but I really only know about Unix.
Windows NT provides non-blocking I/O.
Another option is to do blocking I/O in a separate thread, if the OS
doesn't block all threads when one is blocked. I am not sure whether
Windows 95 offers the non-blocking I/O calls that NT has, so using a
separate OS thread for the GUI and for any I/O *may* be the way to
implement once for '95 and NT.
-Patrick Logan
Date: 96 Nov 13 10:08:51 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: johnson@cs.uiuc.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <v0153053eaeaf910a99e7@[128.174.23.50]> (johnson@cs.uiuc.edu)
Subject: Re: Squeak VM Performance
Ralph,
> I think the traditional way to do this is to clear the home pointer when
> the block or the home context returns. Thus, a nil home pointer means
> "I've returned".
That fixes the problem of the block returning more than once, but doesn't fix
the problem of the block trying to return to a home context which no longer
exists. The two are almost certainly separate problems: you wouldn't want
the home context to have to keep track of all the blocks which it creates,
just so that it can nil their home context pointers when it returns. (That's
why I think a simple solution requires the home context to be stabilised
too -- even if only to let it's subordinate contexts know that they can't
return to it any more.)
I'm beginning to wonder if it would be such a good idea to try to separate
the activation and environment parts of a Smalltalk context anyway: doing so
would make the debugger much more complex. The current situation, where
contexts evaluate themselves, is appealingly clean.
Regards,
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 13 10:31:15 am
From: Tim Rowledge <rowledge@interval.com>
To: Squeak mailinglist <squeak@create.ucsb.edu>
In-Reply-To: <199611131545.HAA15355@volta.ucsb.edu>
Subject: Re: Logo
On Wed 13 Nov, Stephen Travis Pope wrote:
>
> So if I hear the last few suggestions correctly, we
> need a picture of Mickey Mouse falling out of a
> hot air balloon?
I have a draw file (Acorn form of macdraw kinda thing) of a Smalltalk
balloon which could easily be extended to add mouse passengers, or
maybe a simple mickey-face above the 'Smalltalk' lettering. The
advantage of this is that the artwork is mine (about 3 weeks worth of
it, from when I had nothing better to do a few years back!) and I
would imagine that a Disney group would be able to arrange making use
of a legal mouse.
I can easily provide a gif/jpeg file version, or indeed a SQ Form
version...
Some of you have probably seen this file printed on teeshirts worn
around occasionally by ex-PPS people. Some of them even look good in
them :-)
--
Tim Rowledge: rowledge@interval.com (w) +1 415 842-6251(w)
rowledge@hooked.net (h) <http://www.hooked.net/~rowledge>
Date: 96 Nov 13 10:35:44 am
From: stp@tango (Stephen Travis Pope)
To: rowledge@interval.com
Cc: squeak@create.ucsb.edu
Subject: Re: Logo
How about merging the images, and having a hot air
balloon with large ears?
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 13 12:12:07 pm
From: Dan Ingalls <DanI@wdi.disney.com>
To: Tim Rowledge <rowledge@interval.com>
Cc: Squeak mailinglist <squeak@create.ucsb.edu>
In-Reply-To: <Marcel-1.08-1113174920-63dKL&V@goldskin.interval.com>
Subject: Re: Logo
Easy, folks!
Of course anyone may do what they want, but I would prefer if we didn't get
to heavy with the logo. Especially, I don't want to encumber it either
with Mickey Mouse, or with the Smalltalk balloon (which was my conception
(someday I'll relate the whole story), realized by R. Tinney). I have in
mind something very simple:
Just a stylized set of whiskers and a smile, maybe a wink at most.
Any artists out there?
- Dan
--------------------------------
>On Wed 13 Nov, Stephen Travis Pope wrote:
>>
>> So if I hear the last few suggestions correctly, we
>> need a picture of Mickey Mouse falling out of a
>> hot air balloon?
>I have a draw file (Acorn form of macdraw kinda thing) of a Smalltalk
>balloon which could easily be extended to add mouse passengers, or
>maybe a simple mickey-face above the 'Smalltalk' lettering. The
>advantage of this is that the artwork is mine (about 3 weeks worth of
>it, from when I had nothing better to do a few years back!) and I
>would imagine that a Disney group would be able to arrange making use
>of a legal mouse.
>I can easily provide a gif/jpeg file version, or indeed a SQ Form
>version...
>Some of you have probably seen this file printed on teeshirts worn
>around occasionally by ex-PPS people. Some of them even look good in
>them :-)
>--
>Tim Rowledge: rowledge@interval.com (w) +1 415 842-6251(w)
> rowledge@hooked.net (h) <http://www.hooked.net/~rowledge>
Date: 96 Nov 13 2:52:55 pm
From: Tim Rowledge <rowledge@interval.com>
To: Dan Ingalls <DanI@wdi.disney.com>
Cc: Squeak mailinglist <squeak@create.ucsb.edu>
In-Reply-To: <v030078010002a2388fed@[206.16.10.121]>
Subject: Re: Logo
On Wed 13 Nov, Dan Ingalls wrote:
> Easy, folks!
>
> Just a stylized set of whiskers and a smile, maybe a wink at
most.
>
> Any artists out there?
Well, I played one for a while at the Royal College of Art, so I have
knocked up a simple little black and white logo for you. I don't
think I should email everyone with it, so if someone can suggest a
good place to which I can ftp it... though it's only 1574 bytes.
Can't put it on my public home page at the moment sinceI can't get to
Hooked.
tim
--
Tim Rowledge: rowledge@interval.com (w) +1 415 842-6251(w)
rowledge@hooked.net (h) <http://www.hooked.net/~rowledge>
Date: 96 Nov 13 4:00:13 pm
From: stp@tango (Stephen Travis Pope)
To: rowledge@interval.com
Cc: squeak@create.ucsb.edu
Subject: Re: Logo
Take a look at the Squeak mailing list archive page to see
Tim's new Squeak logo suggestion!
http://www.create.ucsb.edu/squeak/9611.html
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 13 5:24:38 pm
From: stp@tango (Stephen Travis Pope)
To: squeak@tango
Subject: Re: Another "missing feature"
At 11:39 PM 11/12/96 -0800, you wrote:
>Hi, Ralph!
>
>However, this is NOT how we want Squeak to work. We want Smalltalk
>processes to keep running in between user events, as they do now. We
>just don't want the VM to be using up a lot of cycles when there is
>nothing to do. It is this "good citizenship" business that seems to be
>achieved in different ways on different platforms.
>
> -- John
I beleive the normal practice is to set up an idle process at the lowest
priority which goes to sleep until a user event, on interrupt causes a
resheduling.
Regards,
Peter Goodall -- peterg@acm.org
Date: 96 Nov 13 8:45:18 pm
From: stp@tango (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: STP's Tool Enhancements, Round 1
Hello All,
I've just placed a few minor tool enhancements on the ftp
site. As per Dan's suggestion, each file has a comment at
the start telling what it's about. Here they are:
ftp://ftp.create.ucsb.edu/pub/Smalltalk/Squeak/sources/tools/Browser.Recent.st
This adds a cache of recently visited classes to the Browser, and puts a
menu in the class list to select from among them and go there (extremely useful).
ftp://ftp.create.ucsb.edu/pub/Smalltalk/Squeak/sources/tools/ProtocolBrowser.st
The protocol browser shows the methods implemented by a class and all its
superclasses (but not Object by default) as a "flattened" list. It is useful
for learning new libraries.
ftp://ftp.create.ucsb.edu/pub/Smalltalk/Squeak/sources/gui/SmallColoredScrollBars.st.
This file makes the standard flop-out scroll bars a bit narrower and more
colorful. Change the colors in the Preferences class is you prefer others.
...more to come...
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 14 8:23:22 am
From: stp@tango (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Apple Squeak Page Updated to 1.16, Extended
Hello all,
TedK has updated and extended Apple Research's Squeak Web page.
Take a look at
http://www.research.apple.com/research/proj/Learning_Concepts/squeak/intro.html
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 14 8:55:48 am
From: stp@tango (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Re: Logo
YES! Looks great!
>Take a look at the Squeak mailing list archive page to see
>Tim's new Squeak logo suggestion!
> http://www.create.ucsb.edu/squeak/9611.html
>
>stp
>
>___Stephen Travis Pope, Center for Research in Electronic Art Technology
>___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
>___Editor, Computer Music Journal (CMJ), MIT Press
>___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Date: 96 Nov 14 9:34:44 am
From: TECHIN.A.KANG@sprint.sprint.com
To: squeak@create.ucsb.edu
Subject: running @ winNT
Hi,
I installed the Squeak Win32 version to 2 NT machines, and here are the
result:
1. NT 3.51 16mb ISA machine -- I can scroll the document. While I tried to
resize the widow (5 - 10 times), the program stopped. No error message!
2. NT 4.0 32mb EISA machine -- No more than 3 times after I resizing the
window, the program stopped. NT prompted this message:
The instruction at "0x0043153b" referenced memory at "0x00f1a000".
The memory count not be "read".
I recompile VM, the program stopped at
function reverse_image_bytes of sqWin32Window.c
I recompiled VM with _M_IX86 disabled. It still failed.
****** QUESTION ******
1. I am new to SmallTalk. Can anyone give me a direction to create the first
image?
2. Anyone working on distributed Smalltalk -- I want to know how you can
design a Smalltalk allow you to send a message to other Smalltalks that may
run at other machines. For example, a clint Win32 smalltalk send a mesasge to
a server smalltalk running at Sun machine.
Thanks,
Alex
Date: 96 Nov 14 9:44:54 am
From: stp@tango (Stephen Travis Pope)
To: TECHIN.A.KANG@sprint.sprint.com
Cc: squeak@create.ucsb.edu
Subject: Re: running @ winNT
I can't help you with the NT VM bugs, but I am looking into
porting a Smalltalk ORB to Squeak. (Details later...)
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 14 9:52:11 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: TECHIN.A.KANG@sprint.sprint.com
Cc: squeak@create.ucsb.edu
In-Reply-To:
<PHJG-1587-7452/27*/I=A/G=TECHIN/S=KANG/O=US.SPRINT/ADMD=TELEMAIL/C=US/@MHS>
(TECHIN.A.KANG@sprint.sprint.com)
Subject: Re: running @ winNT
> 2. Anyone working on distributed Smalltalk -- I want to know how you can
> design a Smalltalk allow you to send a message to other Smalltalks that may
> run at other machines. For example, a clint Win32 smalltalk send a mesasge to
> a server smalltalk running at Sun machine.
My "day job" ;^) is all about remote references, objects, etc. etc. etc. I
have a prototype of my reference system for OWST4.0 -- I would port this to
Squeak the moment that socket support goes in. Significant benefits over a
traditional "ORB-based" approach include (but are not limited to):
o complete transparency
o distributed garbage collection
Just waiting for that Socket class to arrive... ;-)
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Nov 14 10:36:41 am
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
To: squeak@create.ucsb.edu
Subject: Re: running @ winNT
> 2. Anyone working on distributed Smalltalk -- I want to know how you can
> design a Smalltalk allow you to send a message to other Smalltalks that may
> run at other machines. For example, a clint Win32 smalltalk send a mesasge
> to a server smalltalk running at Sun machine.
Well, if you had a socket...
Ignoring things like distributed garbage collection, it is trivial to send a
simple message to an object in another image. You need:
* to parse the identify of the object that is the receiver (network globals)
* to parse the selector
* to parse the arguments
(constants are easy, references become a slippery slope)
* to Object>>perform: the message
* do something with the result (another slippery slope)
You could also send a "do it" over a socket.
Hey, what about transactions, and, and... er, wait for STP's port of an ORB?
-Patrick Logan
Date: 96 Nov 14 12:48:12 pm
From: John Maloney <johnm@wdi.disney.com>
To: Nickolay Saukh <nms@nns.ru>
Cc: squeak@create.ucsb.edu
Subject: Re: Time to go international
Re:
Is it possible to make Unicode the base charset?
So I would be able to have russian class names, .... ;-)
We may need to do this at some point, but it will
probably be later rather than sooner.
Is the Russian character set encoded into the 8-bit ISO
character set or does it require 16 bits? If it's the former,
you may be able to make up a StrikeFont that does the
trick. You'd also need to figure out how to type the
characters (perhaps you'd add a mode to ParagraphEditor).
-- The Squeak Team
Date: 96 Nov 14 1:20:30 pm
From: John Maloney <johnm@wdi.disney.com>
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: squeak@create.ucsb.edu
Subject: Re: running @ winNT
Re: Just waiting for that Socket class to arrive... ;-)
I'm working on it right now. But, realistically, it probably won't
get out there until early-mid December.
-- John
Date: 96 Nov 14 5:24:14 pm
From: Steve Beisner <sbeisner@cisco.com>
To: squeak@create.ucsb.edu
Subject: Getting started with Squeak
I've got it installed and running and have figured out "projects"
and tried a few simple examples. Does anyone have any particular
recommendations of the best path to familiarity with Squeak? My Smalltalk
experience to date has been with various Digitalk dialects. I have
a first edition "bluebook" -- which the Apple web pages suggest is
somewhat applicable. Are there other resources, or is just playing
around really the best approach?
Date: 96 Nov 14 5:44:34 pm
From: Latta@interval.com (Craig Latta)
To: Steve Beisner <sbeisner@cisco.com>
Cc: squeak@create.ucsb.edu
Subject: Re: Getting started with Squeak
> Does anyone have any particular recommendations of the best path
> to familiarity with Squeak? ...is just playing around really the best
> approach?
I'd say so. Adding some of the missing things (e.g., sockets,
exception-handling) is a good way to get acquainted. ;)
-C
Date: 96 Nov 14 6:55:21 pm
From: stp@tango (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Cc: hmm@heeg.de
Subject: 3-D Graphics Example Available in Squeak
I've ported Hans-Martin's old 3-D wire frame model over to Squeak
as an example (and a benchmark) (and a screen saver).
The code's in
ftp://ftp.create.ucsb.edu/pub/Smalltalk/Squeak/sources/gui/Graphics-3D.st
and it requires the ZPoint file-in from the STP11 goodies collection.
The description from the source file is:
'This is Hans-Martin Mosner''s 3-D graphics example. It creates wire-frame models and can display and rotate them. It also serves as a cool screen saver. It requires the 3-D point class ZPoint. stp--1996.11.14'!
There's a bug I can't seem to find right now with color BitBlt. Look
aththe WireModel displayOn: methods and their comments. I'd love some
help on this from another pair of eyes...
This port is a step towards getting the MODE DisplayList framework
ported over. Does anyone want to serve as beta-testers?
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 14 7:04:26 pm
From: Stephen Travis Pope <stp@create.ucsb.edu>
To: squeak@create.ucsb.edu
Subject: Getting started with Squeak
Perhaps an old Orange Book (Smalltalk-80: The Interactive Programming
Environment) would be the best. It steps you through using all the
built-in tools.
stp
__Stephen Travis Pope
__Center for Research in Electronic Art Technology (CREATE)
__Dept. of Music, U. C. Santa Barbara
__Editor--Computer Music Journal, MIT Press
__stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 15 12:49:04 am
From: gollmann@edvz.tuwien.ac.at (Georg Gollmann)
To: squeak@create.ucsb.edu
Subject: Re: Logo
>Take a look at the Squeak mailing list archive page to see
>Tim's new Squeak logo suggestion!
> http://www.create.ucsb.edu/squeak/9611.html
>
>stp
I have converted the logo to application and document icons for the Mac
desktop. Is anyone interested ?
Georg
----
Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum
phon:(++43-1) 58801 - 5848
mail:gollmann@edvz.tuwien.ac.at
http://ftp.tuwien.ac.at/~go/Gollmann.html
Date: 96 Nov 15 3:49:40 am
From: Nickolay Saukh <nms@nns.ru>
To: John Maloney <johnm@wdi.disney.com>
Cc: squeak@create.ucsb.edu
In-Reply-To: Your message of "Thu, 14 Nov 1996 12:34:46 PST."
<199611142050.AA08285@bobo.rd.wdi.disney.com>
Subject: Re: Time to go international (Unicode as base charset)
> Re:
> Is it possible to make Unicode the base charset?
> So I would be able to have russian class names, .... ;-)
>
> We may need to do this at some point, but it will
> probably be later rather than sooner.
>
> Is the Russian character set encoded into the 8-bit ISO
> character set or does it require 16 bits?
I don't think about any particular language. Going 16 bits
(Unicode) can (should I say 'must'?) solve problem for many
languages.
--
Nickolay Saukh
Chief Technical Officer
National News Service
Moscow, Russia
Date: 96 Nov 15 4:35:51 am
From: stp@tango (Stephen Travis Pope)
To: sbeisner@cisco.com
Cc: squeak@create.ucsb.edu
Subject: Re: Getting started with Squeak
> Does anyone have any particular recommendations of the best
> path to familiarity with Squeak?
There are several excellent web-based references for Smalltalk,
including a complete on-line tutorial (or two). For a sood
starting place, look at Jeff McAffer's page of Smalltalk-related
links at http://www.oti.com/jeffspg/smaltalk.htm or Dave Smith's
FAQ document at http://st-www.cs.uiuc.edu/users/dnsmith/SmallFaq.html.
The books referenced on the Apple Squeak page are also quite worth
recommending.
stp
___Stephen Travis Pope, Center for Research in Electronic Art Technology
___(CREATE), Dept. of Music, U. of California, Santa Barbara (UCSB)
___Editor, Computer Music Journal (CMJ), MIT Press
___stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/
Date: 96 Nov 15 6:40:13 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: johnm@wdi.disney.com
Cc: squeak@create.ucsb.edu
In-Reply-To: <199611142123.AA08378@bobo.rd.wdi.disney.com> (message from John
Maloney on Thu, 14 Nov 1996 13:23:39 -0800)
Subject: Weak references + finalisation
> Re: Just waiting for that Socket class to arrive... ;-)
>
> I'm working on it right now. But, realistically, it probably won't
> get out there until early-mid December.
I forgot to mention: the other two things that are vital for remote
references (for supporting distributed garbage collection in particular) are
weak references and finalisation. Any plans to incorporate these in the near
future?
Ian
Date: 96 Nov 15 10:42:17 am
From: Dan Ingalls <DanI@wdi.disney.com>
To: squeak@create.ucsb.edu
Cc: scottw@wdi.disney.com, tedk@wdi.disney.com, johnm@wdi.disney.com,
alank@wdi.disney.com
Subject: Bug Fix for 1.16
The last line in Color class defaultColorMapFrom: sourceDepth to: destDepth
should be changed from
colorMap
to
^ colorMap
The only thing this could affect at present is pasting a 16- or 32-bit form
into text.
Date: 96 Nov 15 1:04:28 pm
From: John Maloney <johnm@wdi.disney.com>
To: squeak@create.ucsb.edu
Cc: stp@tango.create.ucsb.edu (Stephen Travis Pope),
John Maloney <johnm@wdi.disney.com>, alank@wdi.disney.com
Subject: Bug fix: PluggableList Example
Folks:
The following change fixes a bug in the PluggableList example. (The
protocol for ListParagraph creation changed). Thanks to Stephen Pope
for pointing this out.
Enjoy!
-- John
---------------------------------------
!PluggableListView methodsFor: 'initialization'!
list: arrayOfStrings
"Set the receivers items to be the given list of strings."
"Note: the instance variable 'itemsList' holds the original list.
The instance variable 'items' is a paragraph constructed from
this list."
| s |
items _ arrayOfStrings.
isEmpty _ arrayOfStrings isEmpty.
s _ WriteStream on: Array new.
"add top and bottom delimiters"
s nextPut: topDelimiter.
arrayOfStrings do: [:item |
item == nil ifFalse: [s nextPut: item].
].
s nextPut: bottomDelimiter.
list _ ListParagraph withArray: s contents.
selection _ self getCurrentSelectionIndex.
self positionList.! !
---------------------------------------
Date: 96 Nov 15 1:04:55 pm
From: John Maloney <johnm@wdi.disney.com>
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: johnm@wdi.disney.com, squeak@create.ucsb.edu, dani@wdi.disney.com,
scottw@wdi.disney.com, tedk@wdi.disney.com, alank@wdi.disney.com,
John Maloney <johnm@wdi.disney.com>
Subject: Re: Weak references + finalisation
Ian (and other Squeakers),
I've thought a lot about these two things. It seems to me that
finalization allows one to do things that are not possible otherwise,
but that the problems one typically addresses with weak references
could be implemented with primitives we already have (perhaps at
some cost in performance).
For example, in a distributed object system you might use proxy
objects to represent remote objects. You need the ability to
enumerate these objects, but you also want them to be reclaimed
when they are not referenced by any local object. So, you store
the proxies in an array so they can be enumerated, but make
it a weak-references array so that the array itself doesn't keep a
proxy from being reclaimed when it has no other references. (I
have no experience with weak pointers or remote objects, so I'm
describing how I imagine this working. Please enlighten me if
I'm wrong.)
However, in Squeak it is fairly cheap to find all instances
of a class, assuming that the entire object heap is in memory.
So you could use that mechanism to enumerate the live proxies
when necessary. In short, you can exploit the existing
memory-scanning functionality rather than adding a new
mechanism to the virtual machine. While I realize that the
"memory resident object heap" assumption does not scale to
really large applications, Squeak is not intended to replace
commercial Smalltalks. And I think occaisional memory scans
are feasible for up to 15-25 megabyte object heaps. (Remember,
the application can cache a list of proxies for ready access
most of the time. Only needs to do the scan when one wants
to be sure unreferenced proxies are released.)
In the interest of simplicity, it would be nice if we could
support the kinds of applications that require weak references
and finalization with as little extra machinery as possible.
Does that seem possible, or do you really need both? Can one
be implemented in terms of the other?
-- John
Date: 96 Nov 15 2:12:28 pm
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
Cc: squeak@create.ucsb.edu
Subject: Re[2]: Weak references + finalisation
> In the interest of simplicity, it would be nice if we could support
> the kinds of applications that require weak references and
> finalization with as little extra machinery as possible. Does that
> seem possible, or do you really need both? Can one be implemented in
> terms of the other?
See Robert Halstead's PhD thesis from MIT, ca. 1985-1990 on MultiLisp.
It exlains an implementation of weak references and finalization. It
can be done with simple machinery. And it seems to me that an
implementation of finalization without a general implementation of
weak references will require *similar* machinery, but that machinery
would be embedded in the VM/collector and be unavailable to the
application developer.
-Patrick Logan
Date: 96 Nov 15 2:46:42 pm
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
Cc: squeak@create.ucsb.edu
Subject: Re[3]: Weak references + finalisation
Let me correct my previous citation. It should be James Miller's PhD thesis on
MultiScheme, rather than Halstead's on MultiLisp!
Try MIT tech report #402 (MIT-LCS//MIT/LCS/TR-402, Sep. 1987)
"MULTI-SCHEME: A PARALLEL PROCESSING SYSTEM BASED ON MIT SCHEME
-pdl
______________________________ Reply Separator _________________________________
Subject: Re[2]: Weak references + finalisation
Author: owner-squeak@create.ucsb.edu at SMTPGATE
Date: 11/15/96 2:10 PM
> In the interest of simplicity, it would be nice if we could support > the
kinds of applications that require weak references and
> finalization with as little extra machinery as possible. Does that
> seem possible, or do you really need both? Can one be implemented in > terms
of the other?
See Robert Halstead's PhD thesis from MIT, ca. 1985-1990 on MultiLisp.
It exlains an implementation of weak references and finalization. It can be done
with simple machinery. And it seems to me that an implementation of finalization
without a general implementation of weak references will require *similar*
machinery, but that machinery would be embedded in the VM/collector and be
unavailable to the application developer.
-Patrick Logan
Date: 96 Nov 15 4:09:50 pm
From: Ian Piumarta <piumarta@prof.inria.fr>
To: johnm@wdi.disney.com
Cc: alank@wdi.disney.com, dani@wdi.disney.com, scottw@wdi.disney.com,
squeak@create.ucsb.edu, tedk@wdi.disney.com
Subject: Re: Weak references + finalisation
John,
(Anyone not interested in how remote references work can skip the
first part of what follows...)
> For example, in a distributed object system you might use proxy
> objects to represent remote objects. You need the ability to
> enumerate these objects, but you also want them to be reclaimed
> when they are not referenced by any local object. So, you store
> the proxies in an array so they can be enumerated, but make
> it a weak-references array so that the array itself doesn't keep a
> proxy from being reclaimed when it has no other references. (I
> have no experience with weak pointers or remote objects, so I'm
> describing how I imagine this working. Please enlighten me if
> I'm wrong.)
[START of distributed object implementation stuff...]
This is precisely what you want to do. In the SSP Chains system (the
one I'm working on) it works like this: whenever a reference to an
object is sent in a message to another process (or "space", in
distributed systems terminology), a "scion" is created to handle
future incoming messages to the referenced object. At the receiving
process (space), a "stub" is created which forwards messages to this
scion for delivery to the target object. The number of scions
pointing to an object approximates (conservatively) a reference count
to the target object.
Scions are deleted by an asynchonous "cleanup" prot