Send mail to the CREATE web master
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" protocol (some people
would call this a "distributed GC"). Periodically a space (process)
will enumerate all its stubs, group them by the spaces in which the
corresponding scions exist, and send a "live message" to each known
remote space -- this live message contains a list of referenced scions
in the receiving space. A space which receives a live message
enumerates its scions, collects all those which are referenced from
the space which sent the live message, and the difference between the
collected scion set and the set of scions named in the live message
represents those scions which are no longer referenced from stubs, and
which can therefore be deleted. The reason it's done like this is to
keep the protocol safe: it is both idempotent (the live message can
arrive more than once and no harm is done) and tolerant to losses
(dropping a live message simply delays the cleanup until the next live
message arrives). This is very attractive behaviour when using
unreliable protocols, such as UDP.
My implementations keep two tables. One contains all the scions, and
is implemented as a regular Set-like thing. The other contains all
the Stubs, and must be implemented as a *weak* Set. These tables
allow the enumeration of the objects, and the "weakness" of the stub
table prevents the table itself from hanging on to an otherwise
unreferenced stub.
This is the only way to do it in C++, but not in Smalltalk. However,
I kept this implementation in the Smalltalk version for two reasons:
simplicity and efficiency. I could live without the first if
necessary, and (since Squeak gives me an efficient implementation of
#allInstances) I can ignore the second -- the only negative point is
that the code will necessarily be rather different from the OWST
implementation. However, it might not be quite so easy since the
cleanup protocol is not the only place where the stubs are
enumerated...
When a reference is exported, the system tries hard to reuse an
existing scion (if a scion can be found for which both the target
object and referring spaces are the same, it is reused). It is
therefore possible that the receiver gets a message containing a
reference to a scion which already has a stub -- in this case it is
essential that the existing stub be found and reused as the "proxy".
Do you think that #allInstances is fast enough in Squeak to permit it
to be called for *every* incoming or outgoing reference in *every*
message exchanged in a distributed computation?
There are "hybrid" solutions. I could, for example, keep the stub
table -- as a kind of "conservative cache" on the real situation in
the object memory. I would periodically delete the stub table, do a
full GC, and then rebuild it using #allInstances.
[...END of distributed object implementation stuff]
> In short, you can exploit the existing memory-scanning functionality
> rather than adding a new mechanism to the virtual machine.
As I pointed out above: this potentially involves scanning the object
memory for every reference in every message exchanged between two
processes!
> (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.)
But you then have the additional cost of a full GC (to be sure the
dead objects referenced from the "flushed" cache are deleted) to add
to the overhead.
> 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?
I can see that finalisation might be possible in terms of weak
references, but not the other way round. (How would you know to
finalise an object, and thus remove its weak reference, when the weak
reference to it isn't really weak at all? Unless you're willing to
use disguised pointers: #asOop to make a weak pointer and #asObject to
"dereference" it...?)
I suspect that the simplest thing that can be done is something like
the system that Dave Ungar designed for ParcPlace. (It's also very
similar to a feature provided in Boehm's C/C++ collector). There you
have "disappearing references" to objects. Some reference R to an
object O is designated to disappear when O is collected. R is not
considered as a root for O, and when O is collected R is set to zero.
Using this mechanism you can do sort-of-finalisation by keeping your
real objects in an array, containing "dissapearing references" (i.e. a
WeakArray ;-), and keeping a parallel array of *clones* of these
objects, containing "strong" references. When you want to finalise
your objects, you scan the "real" object array and look for zeros.
When you see a zero you set it to nil, and finalise the corresponding
object in the "cloned" array (which can perform any finalisation
actions needed by its orignal [already deceased] prototype), after
having removed it from the clone array of course.
A few months ago there was a *long* debate on the gc list about how
finalisation should be implemented and presented to end users. The
only certain conclusion from this was that there are many ways to do
it, and not one of them is obviously "right". I like Dave's solution
the best out of any: it's very simple to understand, and the
implementation of finalisation that you build using the clones very
neatly avoids the nasty issue of "how do you prevent an object which
is being finalised from storing a pointer to itself somewhere, thereby
`raising it from the dead'?" (and various other unpleasant scenarios).
Got to go...
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 15 4:13:30 pm
From: Ian Piumarta <piumarta@prof.inria.fr>
To: Patrick_D_Logan@ccm2.hf.intel.com
Cc: squeak@create.ucsb.edu
Subject: Re: Re[3]: Weak references + finalisation
Patrick,
> Try MIT tech report #402 (MIT-LCS//MIT/LCS/TR-402, Sep. 1987)
> "MULTI-SCHEME: A PARALLEL PROCESSING SYSTEM BASED ON MIT SCHEME
Is this available online?
Thanks,
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 15 5:37:14 pm
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
To: piumarta@prof.inria.fr
Cc: squeak@create.ucsb.edu
Subject: Re[5]: Weak references + finalisation
>> Try MIT tech report #402 (MIT-LCS//MIT/LCS/TR-402, Sep. 1987)
>> "MULTI-SCHEME: A PARALLEL PROCESSING SYSTEM BASED ON MIT SCHEME
>Is this available online?
Unfortunately, it looks as if it is not on-line yet. The MIT labratory
for computer science (LCS) page lists what they have on-line, and
abstracts + ordering information for everything else. They are
converting their most recent TRs first, and they have TR-405, so
perhaps they'll have TR-402 soon!
Meanwhile, it costs $24.00 to order hard copy.
ftp://ftp-pubs.lcs.mit.edu/pub/lcs-pubs/pubs.html
I know where my copy is, but unfortunately it is in storage. When I
get back in that room (!) to dig out Christmas boxes in a few weeks
I'll dig out the TR too!
-Patrick Logan
Date: 96 Nov 15 6:53:16 pm
From: johnson@cs.uiuc.edu (Ralph E. Johnson)
To: squeak@create.ucsb.edu
Subject: Re[3]: Weak references + finalisation
I have never implemented weak references, but I remember a discussion
with Peter Deutsch where he explained an idea of his for doing it. I
think this eventually became the scheme in VisualWorks, though maybe not.
This idea works with any copying garbage collector. We will mark all
the objects with a weak reference to them. After copying, if they have
been left behind then we will finalize them. When we copy an object
from old space to new space, we always store a forwarding pointer in
the version in old space. So, one way to find all objects that have
not been copied is to scan old space and see if there is a forwarding
pointer. But the whole point of a copying collector is to avoid scanning
old space. So, we keep a list of all the objects with a weak reference
to them, and just scan them. In fact, we can use the weak arrays as the
list, so we don't need to keep track of all objects with weak references,
just objects that are weak arrays. After a copy, scan all your weak
arrays and finalize any object that has not been copied. In VisualWorks,
finalization is done by just nilling out the reference in the weak array.
To summarize, all the VM has to do is to keep track of all weak arrays.
Don't use their contents for copying, but at the end of copying, scan
each weak array and nil out the entries that still point into old space.
If you don't have many weak arrays, this is fast. It should also be
easy to implement. You just need to keep from tracing the contents of
a weak array (an extra if statement) and then scan weak arrays after
the g.c. is over.
-Ralph
Date: 96 Nov 18 3:18:45 pm
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Squeak 1.16-to-1.17 patches
Here's the first batch of new updates from Dan Ingalls.
They're in the directory
ftp://ftp.create.ucsb.edu/pub/Smalltalk/Squeak/patches/1.17.fileIns
and are also there as a StuffIt file.
There's also a new (1.17) Mac VM on the ftp site.
stp
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
(FileStream readOnlyFileNamed: 'CompositionFix.st') fileIn.
"Corrects a bug related to the line height
computation when a FormSetFont is used."
(FileStream readOnlyFileNamed: 'DefaultColorMapFix.st') fileIn.
"Corrects a bug in the generation of a default color map from one depth
to another. Only affects the pasting of a 16- or 32-bit glyph into text
in the 1.16 release, but this method will likely see greater use in the
future."
(FileStream readOnlyFileNamed: 'SpecialObjects-di.cs') fileIn.
"Defines a method that will recreate the list of special objects known to
the virtual machine. In addition to documenting what has been so for
a long time, this method also adds a number of prototypical instances
that can be block-copied to speed the initialization of, eg, Contexts and
Floats."
(FileStream readOnlyFileNamed: 'BBCorrection-di.cs') fileIn.
"Corrects three methods that accidentally got out of phase with the (proper)
code that was used to make the version 1.16 VM. Affects only the generation
of new VMs, and only a 1-pixel error in on-screen scrolling."
(FileStream readOnlyFileNamed: 'ExtendedLiterals-di.cs') fileIn.
"Changes the compiler (and decompiler and disassembler) to support access
to up to 255 literals per method and up to 254 instance variables per class.
It does this by making use of Squeak's existing double-extended-do-anything
bytecode (132). Also enables compilation of Squeak's second-extended-send
bytecode (134) that was part of the same change to the VM back in July."
(FileStream readOnlyFileNamed: 'UseMoreLiterals-di.cs') fileIn.
"Reunifies a couple of methods that had been split to avoid the old limit
of 63 literals. Also recompiles all methods with more than 31 literals
to take advantage of the Squeak's second-extended send bytecode."
(FileStream readOnlyFileNamed: 'ExtendedInstVars-di.cs') fileIn.
"Makes a backward-compatible change in the VM to support classes with
up to 254 instance variables. Namely, a new 2-bit field is defined at the
top of the current 'format' word in every behavior (which = 0 in existing
classes). NOTE: these changes must be read in, and then a new VM produced,
which shall be known hereafter as 1.17. With THAT vm and these changes,
it will be possible to work with classes of up to 254 instance variables."
(FileStream readOnlyFileNamed: 'ExtendedScans-di.cs') fileIn.
"Makes scans for instVar refs/defs work in classes with > 63 instance
variables."
(FileStream readOnlyFileNamed: 'CleanQuitBanner-di.st') fileIn.
"Eliminates tacky priorSource link from snapshot and quit banners
displayed in the Transcript."
_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 18 5:36:38 pm
From: Tim Rowledge <rowledge@interval.com>
To: Squeak mailinglist <squeak@create.ucsb.edu>
Subject: littleendian BitBLT ?
Anybody playing with a little-endian friendly BitBLT? Having to pixel reverse the display bitmap before drawing it to the screen is a real pain.
I've started looking into it, but it seems a good idea to see if anyone else is hacking at it before I spend too much of my copious spare time on it!
tim
--
Tim Rowledge: rowledge@interval.com (w) +1 415 842-6251(w)
rowledge@hooked.net (h) <http://www.hooked.net/~rowledge>
Date: 96 Nov 18 7:24:29 pm
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: squeak@create.ucsb.edu
Subject: FYI Fall '97 Squeak Classes at Georgia Tech
FYI I just received permission from our Associate Dean to go ahead and
start to move our Sophomore object-oriented analysis/design/programming
class to Squeak in Fall '97. The big selling points were:
- The simpler UI model compared with VisualWorks (which we're currently
using); and
- The potential to explore non-GUI interface methods in Squeak.
I probably won't start work on this until Spring/Summer '97, but I was
excited by the news and wanted to pass it on.
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 19 12:45:48 pm
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Goodies directory reorganized; new items added
Below is the new README file for the squeak goodies. They're now organized
into separate subdirectories for graphics, gui extensions, music, other
packages, system extensions, and tool enhancements and new tools.
Squeak Goodies README File -- LastEditDate: 1996.11.19
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Graphics
"Graphics-3D.st 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 and the two
additional Zpoint methods in this directory.
stp@create.ucsb.edu--1996.11.14"
"Graphics-DisplayLists.st
This is the Squeak MODE DisplayList Framework. It
is written to support the MODE's music editing tools, and is not the world's
most comprehensive and elegant structured graphics hierarchy. It is, however,
one of the simplest and most easily extensible.
One could easily add support for regular polygons, better arcs, more kinds of paths, etc.
Note also that the display item hierarchy is separate from the display list editing
framework.
The class DisplayList has loads of example methods; try,
DisplayList testAll
for a good sampler
stp@create.ucsb.edu--1996.11.15"
"ZPoint-perspective.st
These are a few additional ZPoint methods that are
needed by the 3D graphics or fractal surface code.
stp@create.ucsb.edu--1996.11.14"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
GUI
"P.Ed.ctrlKeys.st
For UNIX keyboards--treat <CTRL> like <COMMAND> for accel keys.
stp@create.ucsb.edu--1996.11.18"
"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.
stp@create.ucsb.edu--1996.11.13"
"WindowColors.st
Set your favorite colors for the standard applications
here. The pre-defined colors are:
black blue cyan darkGray gray green lightBlue lightBrown lightCyan lightGray
lightGreen lightMagenta lightOrange lightRed lightYellow magenta red
veryDarkGray veryLightGray white yellow
stp@create.ucsb.edu--1996.11.18"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Music
Coming soon...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Packages
Coming soon...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
System
"STP V11 FileIns -- LastEditDate: 1996.11.18"
"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: 'CaseStatement.st') fileIn.
"Several useful collection extensions--second, third, etc.,
with:with:with:with:with:, etc."
(FileStream readOnlyFileNamed: 'CollectionAdds.st') fileIn.
"A few modified printing methods: Time without seconds, Dates with leading
0's (e.g., 1995.04.08)."
(FileStream readOnlyFileNamed: 'Printing.st') fileIn.
"A few new messages for generating random numbers in limited ranges, or
selecting from collections at random."
(FileStream readOnlyFileNamed: 'RandomAdds.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: '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: 'StreamIO.st') fileIn.
"Adds many useful string crunching methods--stripTrailingSpaces, padTo:,
clipTo:, breakIntoLinesOf:, stripCRs. cr."
(FileStream readOnlyFileNamed: 'StringAdds.st') fileIn.
"3-D points, i.e., one can say 3@4@7."
(FileStream readOnlyFileNamed: 'ZPoint.st') fileIn.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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).
stp@create.ucsb.edu--1996.11.07'
"Notifier-ProcessRedButton.st
Make the red button act like the yellow one within a notifier.
stp@create.ucsb.edu--1996.11.07"
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.
stp@create.ucsb.edu--1996.11.04"
"RedComments.st
Simple changes to the Browser to make the selector of a
method appear in bold blue and make comments red (or italics) so that they
stick out more; edit to taste.
stp@create.ucsb.edu--1996.11.18"
"Increase the size of the transcript's log
stp@create.ucsb.edu--1996.11.10"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Comments are invited...
_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 19 3:11:53 pm
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Re: Squeak 1.16-to-1.17 patches
At Ian's suggestion, I've reorganized the ftp site a bit so that deltas
(relative changes between versions) are kept separately from patches (bug fixes).
The newest changes from Dan Ingalls are now in,
ftp://ftp.create.ucsb.edu/pub/Smalltalk/Squeak/deltas/1.17.fileIn
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 19 3:36:34 pm
From: John Maloney <johnm@wdi.disney.com>
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: johnm@wdi.disney.com, squeak@create.ucsb.edu, tedk@wdi.disney.com,
John Maloney <johnm@wdi.disney.com>
Subject: Re: Weak references + finalisation
Ian,
Thanks for the thorough description of your remote object system.
Sounds quite reasonable and more robust than some distributed
GC schemes I've seen. Is it your own design?
Re:
Do you think that #allInstances is fast enough in Squeak to permit it
to be called for *every* incoming or outgoing reference in *every*
message exchanged in a distributed computation?
Memory scans are pretty fast (assuming you don't have to
page). For example, on a PPC Mac 8100, with the release image, it
takes 30-40 milliseconds to enumerate all instances of Set (134
instances). This time increases with both the total number of
objects and the number of instances found, but I imagine it
would remain well under a second even for moderately large
number of objects. (The scan is not affected by object size;
scanning 100 8-byte objects is just as fast as scanning 100
100-kbyte objects since the scan only looks at object headers.
Thus, an image with lots of large pixmaps, text, or sound
data may still scan quickly.)
However, rather than doing a scan on every message exchange
I prefer your hybid scheme:
There are "hybrid" solutions. I could, for example, keep the stub
table -- as a kind of "conservative cache" on the real situation in
the object memory. I would periodically delete the stub table, do a
full GC, and then rebuild it using #allInstances.
You could have a background process that did this, say, once a
minute, or it could be done every so many message sends.
Re:
I can see that finalisation might be possible in terms of weak
references, but not the other way round. (How would you know to
finalise an object, and thus remove its weak reference, when the
weak reference to it isn't really weak at all?
You'd use your hybrid scheme to make the object GC-able. After a
GC, the client would get a list of objects to be finalized.
Thanks for describing Ungar's scheme for implementing finalization
via weak pointers. That's exactly what I was looking for! (And I
wasn't aware of it, since Dave did it before he came to Sun.)
It appears that:
1. You can implement finalization in Smalltalk if you have
weak reference arrays.
2. You can use object enumeration to solve problems
that are often addressed with weak reference arrays.
Strange as it may seem, this implies that one could actually live
without either finalization OR weak arrays; the current Squeak
VM would suffice.
However, the weak reference array abstraction seems to have
a number of uses and can also be used to implement finalization.
It would also be fairly easy to add it to the VM. The only argument
against doint it is that it makes the system less accessible to novices.
(Like metaclasses, weak references sound more mysterious than
they really are.)
I'd be interested in hearing about applications that, like Ian's
distributed object system, are greatly simplified by weak reference
collections or by finalization. (Just a sentence or two would suffice.)
Here's a start:
Weak References
caches of reusable or sharable objects
caches of proxies for remote objects (special case of previous)
Finalization
releasing external resources such as files or network streams
debugging tools that trace object creation/deletion
Thanks,
-- John (and the Squeak Team)
Date: 96 Nov 19 3:43:42 pm
From: John Maloney <johnm@wdi.disney.com>
To: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
Cc: squeak@create.ucsb.edu
Subject: Re: Re[3]: Weak references + finalisation
Re:
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.
Thanks for the reference!
Of the two, which is more immediately useful to you? Using Ungar's
idea (that Ian described), it looks like weak references is the right
little nugget to put into the VM. What do you think?
-- John
Date: 96 Nov 19 4:18:35 pm
From: stp (Stephen Travis Pope)
To: guzdial@cc.gatech.edu (Mark Guzdial), squeak@create.ucsb.edu
In-Reply-To: guzdial@cc.gatech.edu (Mark Guzdial)'s letter of: 96 Nov 18
Subject: Re: FYI Fall '97 Squeak Classes at Georgia Tech
What great news!
I'd like to propose that a group of us work together and edit one of the
existing on-line Smalltalk tutorials to cover Squeak (so that we can all use
it in classes).
There is a good VisualWorks tutorial at
http://www.cs.clemson.edu/~lab428/VW/VWCover.html
and a (better) VisualAge tutorial at
http://www2.ncsu.edu/eos/info/ece480_info/project/spring96/proj63/www/index.html
I've up-loaded both of these and placed them on the CREATE ftp site on the
"docs" directory.
Who wants to collaborate in working on educational materials for Squeak?
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 19 4:19:56 pm
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
In-Reply-To: <v03007800aeb5ab0278bf@[206.16.10.79]>
Subject: Important fix needed for 1.17
--============_-1363673187==_============
Content-Type: text/plain; charset="us-ascii"
Folks -
Just discovered a compiler bug in 1.17. It is fixed by the attached file.
In case attachments fon't work for you, here it is in-line:
!VariableNode methodsFor: 'code generation'!
sizeForStore: encoder
self reserve: encoder.
code < 256 ifTrue: [^ 2].
(code \\ 256) <= 63 ifTrue: [^ 2].
^ 3! !
--============_-1363673187==_============
Content-Type: text/plain; name="VitalFixFor1.17.st"; charset="us-ascii"
Content-Disposition: attachment; filename="VitalFixFor1.17.st"
"VitalFixFor1.17.st
Fixes an inconsistency between compiler sizing and code generation.
AUTHOR Dan Ingalls (DanI@WDI.Disney.com)
VERSION 1.17
PREREQUISITES none
DISTRIBUTION world
VERSION ID 1
VERSION DATE November 19, 1996"!
'From Squeak 1.13 of October 17, 1996 on 19 November 1996 at 3:37:43 pm'!
!VariableNode methodsFor: 'code generation'!
sizeForStore: encoder
self reserve: encoder.
code < 256 ifTrue: [^ 2].
(code \\ 256) <= 63 ifTrue: [^ 2].
^ 3! !
--============_-1363673187==_============--
Date: 96 Nov 19 5:26:37 pm
From: Patrick D Logan <Patrick_D_Logan@ccm2.hf.intel.com>
To: johnm@wdi.disney.com
Cc: squeak@create.ucsb.edu
Subject: Re[5]: Weak references + finalisation
Here is another reference I remembered over the weekend... it explains the
darkside of finalization and presents a solution. The problems addressed are
(1) when does finalization run;
(2) where are the objects being finalized and in what order are they visited;
and
(3) what can a finalization method do (e.g. can it "resurrect" the finalized
object?)
It also addresses implementation and performance of weak references and
finalization with a generation-based collector. And it provides more examples of
how they've been used in various Lisp systems.
See http://www.cs.indiana.edu/proglang/papers/guardians.ps
BTW Perhaps for Smalltalk, the appropriate object would be a WeakAssociation as
compared with a WeakPair in Lisp. The key would be weak and the value would be
strong.
-Patrick Logan
______________________________ Reply Separator _________________________________
Subject: Re: Re[3]: Weak references + finalisation
Author: johnm@wdi.disney.com at SMTPGATE
Date: 11/19/96 3:38 PM
Re:
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.
Thanks for the reference!
Of the two, which is more immediately useful to you? Using Ungar's
idea (that Ian described), it looks like weak references is the right
little nugget to put into the VM. What do you think?
-- John
Date: 96 Nov 20 12:31:35 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: guzdial@cc.gatech.edu, squeak@create.ucsb.edu, stp@create.ucsb.edu
Subject: Re: FYI Fall '97 Squeak Classes at Georgia Tech
> Who wants to collaborate in working on educational materials for Squeak?
I have a comprehensive (140 slides + 1 page of full text for each
slide) 3-hour tutorial which I gave at last year's ESUG Summer School
all about "Interfacing Smalltalk with the real world" -- user
primitives, sockets, client-server communications, etc. etc. It's
currently in LaTeX, but with sufficient motivation I would be prepared
to (a) convert it to HTML, (b) modify it for Squeak (once that
Socket class appears...;-), and (c) donate it to whatever Big Book of
Squeak might be under preparation.
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 20 4:19:49 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: johnm@wdi.disney.com
Cc: squeak@create.ucsb.edu, tedk@wdi.disney.com
In-Reply-To: <199611192339.AA26962@bobo.rd.wdi.disney.com> (message from John
Maloney on Tue, 19 Nov 1996 15:38:10 -0800)
Subject: Re: Weak references + finalisation
John, Squeakers,
> Thanks for the thorough description of your remote object system.
> Is it your own design?
It was designed by David Plainfossé and Marc Shapiro. There are some papers
and a Ph.D. thesis: anyone who's interested can find them somewhere under
http://www-sor.inria.fr/
(David left a few years ago; Marc is still here. I was drafted a year and a
half ago to re-engineer it from scratch into an "industrial-strength" system,
and to continue the research w.r.t. collecting distributed cycles,
fault-tolerance and failure recovery, application to mobility, and
scalability to VLANs via reference-aware gateways...)
I'm still not certain I understand what you're proposing w.r.t. implementing
finalisation on top of the "hybrid" fake-WeakArrays.
> Re:
> I can see that finalisation might be possible in terms of weak
> references, but not the other way round. (How would you know to
> finalise an object, and thus remove its weak reference, when the
> weak reference to it isn't really weak at all?
>
> You'd use your hybrid scheme to make the object GC-able.
There are a couple of issues which I don't see the solution to. The first is
in the hybrid scheme itself. It can work for me because the WeakArray that I
want to construct contains *all* the instances of a particular class. So I
can happily throw it away, garbage collect, and then reconstruct it with
#allInstances. But how could one do this if the WeakArray were to conatian
an arbitrary collection of objects? After throwing it away and doing a GC,
you'd have no way to know how to reconstruct it, with or without
#allInstaces.
This is related to the second point: let's assume that you can, by some
magical means, recreate your "WeakArray" after the GC. In order to make the
list of "finalisable objects" you need to subtract this from the original
list of objects. How can you keep the original list of objects, which will
represent a set of *strong references* to those objects, and still expect any
of them to be garbage collected?
> After a GC, the client would get a list of objects to be finalized.
I think there's a problem with this too. Assuming you can do a hybrid scheme
for "WeakArrays" (ignoring the possibly problems I mentioned above -- maybe
we *can* assume that the WeakArray contains all the instances of a particular
class...), I can't see how you could finalise the objects that have been
collected: how can you interact with an object *after* the GC has swept it
away?
I apologise if I'm just being stupid... (Or if I misunderstood the generality
of WeakArray to which your comments were being applied!)
If you have a few minutes to spare, I would appreciate greatly some sort of
"algorithm outline" for the scheme that you have in mind for WeakArrays (of
arbitrary objects) using the "hybrid" scheme, and their finalisation.
> It appears that:
> 1. You can implement finalization in Smalltalk if you have
> weak reference arrays.
We should be careful here: you don't get to finalise the object itself, only
a "clone" (normally this would be a shallowCopy) of the object.
> 2. You can use object enumeration to solve problems
> that are often addressed with weak reference arrays.
>
> Strange as it may seem, this implies that one could actually live
> without either finalization OR weak arrays; the current Squeak
> VM would suffice.
I'm not (yet ;-) convinced that (2) can be used to implement either general
WeakArrays, or finalisation. But for the limited case of "weak array of all
instances of a particular class/classes", the hybrid scheme is certainly one
solution.
> However, the weak reference array abstraction seems to have
> a number of uses and can also be used to implement finalization.
> It would also be fairly easy to add it to the VM. The only argument
> against doing it is that it makes the system less accessible to novices.
> (Like metaclasses, weak references sound more mysterious than
> they really are.)
Unlike metaclasses, if you never use weak references then you need never even
know that they're there! 8^)
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 20 5:28:07 am
From: gollmann@edvz.tuwien.ac.at (Georg Gollmann)
To: squeak@create.ucsb.edu
Subject: Some UI stuff & ramblings
Hello,
I have put my (few) changes onto the web at
<http://ftp.tuwien.ac.at/~go/Squeak/>:
SqueakIcons.Hqx: A resource file to give Squeak Finder icons. Based on the
Squeak logo by Tim Rowledge.
noListDelimiters.st: Do away with the top and bottom delimiters in lists.
swapButtons.st: Swap the mapping of the option and command keys to the
blue/yellow mouse buttons. I found this more convenient for my working
style.
---
While browsing the image I found that the instVars ScrollController-menuBar
and ListView-lineSpacing are not used. Is it safe to remove them ?
Is there a special design rationale behind the top and bottom delimiters in
lists ?
I have disabled them (which is easy to do), but am thinking about ripping
them out altogether.
I would like to make the scrollers more "conventional" and simpler, i.e.
non-flopping with just a dragable marker and paging regions above and below
the marker. Comments ? Has anyone done this ?
Kind Regards
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 20 6:50:19 am
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: stp@create.ucsb.edu
Cc: squeak@create.ucsb.edu, chai@uiuc.edu (Ian Chai)
Subject: Re: FYI Fall '97 Squeak Classes at Georgia Tech
>Who wants to collaborate in working on educational materials for Squeak?
I'm interested, but not in the short term (3-6 months). Getting our CS
2390 class ready for Squeak is an exciting new item on my list, but I have
to work down the list to it.
One of the background processing things I've been engaged in is working my
way through the original Addison-Wesley Smalltalk-80 books as well as a
book that uses Tektronix Smalltalk (whose reference I don't have at hand)
to determine how much is similar and how much is different. My current
plan for texts for our class is to use Goldberg & Robson and also one of
the newer texts that cover OOA/OOD methodologies and introduce C++ (like
Budd's new book). The focus of our course is generally "Modeling and
Design" from an O-O perspective, so we typically deal with Smalltalk
in-depth and touch on at least one other O-O language for perspective.
In your list of Web tutorials, one of Ralph Johnson's students, Ian Chai,
sent me a URL to a nice Web site he's building that uses a pattern-approach
to VisualWorks. I'll cc this note to him, as a request for permission to
share that site.
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 20 6:52:50 am
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: squeak@create.ucsb.edu
Subject: Re: FYI Fall '97 Squeak Classes at Georgia Tech
EXCELLENT! I'd definitely be interested! There's a growing movement in
our College to aim toward ubiquitous computing, and I could see a tutorial
like this being a great resource for our students to use in applying
Smalltalk in the effort to have lots of machines talking to lots of
different devices.
Mark
>> Who wants to collaborate in working on educational materials for Squeak?
>
>I have a comprehensive (140 slides + 1 page of full text for each
>slide) 3-hour tutorial which I gave at last year's ESUG Summer School
>all about "Interfacing Smalltalk with the real world" -- user
>primitives, sockets, client-server communications, etc. etc. It's
>currently in LaTeX, but with sufficient motivation I would be prepared
>to (a) convert it to HTML, (b) modify it for Squeak (once that
>Socket class appears...;-), and (c) donate it to whatever Big Book of
>Squeak might be under preparation.
>
>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 -----------------------
--------------------------
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 20 9:43:21 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: guzdial@cc.gatech.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <v02130503aeb88010e1c4@[130.207.3.225]> (guzdial@cc.gatech.edu)
Subject: Re: FYI Fall '97 Squeak Classes at Georgia Tech
> [...] I could see a tutorial like this being a great resource for our
> students to use in applying Smalltalk in the effort to have lots of
> machines talking to lots of different devices.
In its current form it is specific to ParcPlace Smalltalk. The PostScript is
in
ftp://alix.inria.fr/pub/course-notes/if:proc.ps.gz
with online source code for all the examples in
ftp://alix.inria.fr/pub/course-notes/if:example-sources.tar.gz
Please respect the copyright notices -- if you want to use it for teaching
purposes it would be nice if you talked with me more about it first.
I also have a tutorial on metalinguistic abstraction in Smalltalk, but I
guess that's far less relevant... ;-)
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 20 5:05:50 pm
From: Stephen Travis Pope <stp@create.ucsb.edu>
To: squeak@create.ucsb.edu
Subject: e: FYI Fall '97 Squeak Classes at Georgia Tech
I have up-loaded Ian's slides and the GNU Smalltalk tutorials to the
CREATE ftp server and placed them in the "docs" directory.
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 20 6:38:05 pm
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: squeak@create.ucsb.edu
Subject: Frameworks pages for VisualWorks
This is the Web site that I mentioned earlier:
>Date: Tue, 12 Nov 1996 17:55:13 -0600
>To: guzdial@cc.gatech.edu
>Subject: Stable
>Cc: chai@chip.cs.uiuc.edu
>From: chai@uiuc.edu (Ian Chai)
>
>Dear Mark,
>
>Dr. Ralph Johnson just pointed out your pages on Stable to me. This is
>of great interest to me as I am working on how to document frameworks,
>and have also written some web pages on how to use Visualworks, though
>as a class project and they're less extensive than yours. They are at
>http://st-www.cs.uiuc.edu/users/chai/writing/visualessons/
>
...
>Ian Chai <chai@uiuc.edu> http://www.uiuc.edu/ph/www/chai
>
--------------------------
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 21 8:06:38 am
From: gollmann@edvz.tuwien.ac.at (Georg Gollmann)
To: squeak@create.ucsb.edu
Subject: simpler and smaller scrollbars
Hello,
I have added my first cut at simpler and smaller scrollbars to my website
at <http://ftp.tuwien.ac.at/~go/Squeak/simplerScrollbars.st>. They have
just a dragable marker and paging regions above and below. The marker is
pinned to be at least as high as wide, so one has something to drag.
UI preferences have been lifted from STPīs SmallColoredScrollBars.
There's also a bug: Typing into a FillInTheBlank draws a marker at the top
left of the display. I havenīt tried to track this down yet.
I have tested the fileIn by loading it into a vanilla 1.16 image. The
removal of two unused instVars at the end takes a little time ...
Comments are welcome.
Have Fun
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 21 4:26:05 pm
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Updated Structured Graphics Framework and Editor
Hello all,
I've just up-loaded an updated version of my simple display list framework
as well as a *very early* version of my display list editor (SqueakDraw). The
file comments are included below. Right now the editor can draw complex
graphics, and lets you scroll, select, drag, and rubber-band (all slowly).
There is no grouping or cut/copy/paste at present (these are on their way).
I'd very much like to collaborate with someone on this. I really don't need
a full-featured drawing package (the package as it is is sufficient to
support the music notation editors I'm porting), but I think it would be very
good for the community for there to be one. Does anyone have any interest in
taking this over and extending it?
Also, there are several bugs that I can't figure out--why do circles and
splines only display in black-and-white?
Also, I'm missing code for arbitrary arcs and ellipses--does anybody have
the time to write this?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Graphics-DisplayLists.st
This is the Squeak MODE DisplayList Framework. It is written to support the
MODE's music editing tools, and is not the world's most comprehensive and
elegant structured graphics hierarchy. It is, however, one of the simplest
and most easily extensible.
One could easily add support for regular polygons, better arcs, more kinds of paths, etc.
Note also that the display item hierarchy is separate from the display list editing framework.
The class DisplayList has loads of example methods; try,
DisplayList testAll
for a good sampler
Graphics-DisplayListViews.st
This is a very simple display list editor (i.e., structured graphics drawing
program) that lets one scroll, select, drag and re-size items in a display
list. It is not intended for general use, but rather to serve as the basis
for more sophisticated tools that are implemented as subclasses.
The red mouse button selects, drage, and rubber-bands items in the display list.
The yellow button brings up a simple menu of basic functions (only redraw has been tested so far).
The blue button is used for 'drag-scrolling' of the view--try it...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_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 21 4:28:07 pm
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Simple Dynamic Value Framework
I just finished the most bare-bones value hierarchy I could think of.
Here's the file comment:
Kernel-Values.st
This is a minimal value framework.
It has useful items such as indirect values (AKA PluggableAdaptors),
lazy-block values, range values, and index values.
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 22 2:26:37 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: simplerScrollbars fix/workaround
Here's a fix/workaround to the FillInTheBlank marker bug I mentioned in my
post about 'simplerScrollbars.st' yesterday.
----
'Call the superclasses controlInitialize method to avoid stray scrollbar
marker drawing.'!
!CRFillInTheBlankController methodsFor: 'basic control sequence'!
controlInitialize
super controlInitialize. "go-22.11.1996"
startBlock _ paragraph characterBlockForIndex: startBlock stringIndex.
stopBlock _ paragraph characterBlockForIndex: stopBlock stringIndex.
self initializeSelection.
beginTypeInBlock _ nil! !
----
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 22 6:22:28 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: color issues
It's me again :-)
I have done some color cleanup
<http://ftp.tuwien.ac.at/~go/Squeak/colorCleanup.st>: Correction of color
examples. Also changed them to be class methods. Some obsolete private
instance methods are removed.
I have come across an inconsistency in StandardSystemView: The comment in
the method labelColor states that the label color could be different from
the background color. However the window bits are cached in a TwoToneForm,
so the label background becomes black in the cache when one uses a
different color.
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 22 10:32:02 am
From: Dan Ingalls <DanI@wdi.disney.com>
To: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
Cc: squeak@create.ucsb.edu
In-Reply-To: <v03007801aebb5dca8a6c@[128.130.36.64]>
Subject: Re: color issues
>I have come across an inconsistency in StandardSystemView: The comment in
>the method labelColor states that the label color could be different from
>the background color. However the window bits are cached in a TwoToneForm,
>so the label background becomes black in the cache when one uses a
>different color.
You're right about this. Once we got 32-bit color working, it was
frightening how much memory it consumed. We work with a lot of windows,
and a lot of images were weighing in at 10-15 megabytes for no reason other
than window backing bitmaps. So I put in the TwoTone hack, and I admit
freely that it is a hack. Bingo, it was suddenly almost free to work in 32
bits, and I think everyone is the better off for it. Note that it is
pretty simple to defeat this feature: just redefine
cacheBitsAsTwoTone
"Buy semiconductor futures..."
^ false
in StandardSystemView. Also, on a per class basis, you can elect to use
ColorSystemView (q..v.) instead of StandardSystemView (note that Projects
and the Form Editor do save full color). Finally, on a per-window basis,
one could add a field to SSView if one thought it worthwhile.
Instead of doing that, you can adapt the following hack as a more general
mechanism. It mutates a SSView into a ColorSystemView on the fly. This
particular hack is designed to make the welcome window in Squeak 1.16-7
preserve color so that you can see my cute litte apple-striped pregnant S
in color all the time, not just after clicking in the title bar to refresh
it...
| ctl | "Fasten seat belts..."
ctl _ ScheduledControllers scheduledControllers detect:
[:ctl | (ctl isMemberOf: StandardSystemController)
and: [ctl view label = 'Welcome to...']].
ctl view become: (ctl view as: ColorSystemView)
Enjoy
- Dan
Date: 96 Nov 22 2:27:07 pm
From: guzdial@cc.gatech.edu (Mark Guzdial)
To: squeak@create.ucsb.edu
Subject: Squeak to Playstation?
Is anybody planning to port Squeak to the Sony Playstation (or Nintendo 64
or Sega Saturn)? I hear that Metroworks is supposed to be coming out with
C Compiler for Playstation RSN. Smalltalk on a $200 box is a pretty
exciting idea!
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 25 2:44:51 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: simplerScrollbars tweak
This tweak (which has been incorporated into
<http://ftp.tuwien.ac.at/~go/Squeak/simplerScrollbars.st>) avoids the jump
in scroll position when grabbing the marker.
----
!ScrollController methodsFor: 'private'!
scrollAbsolute
| markerOutline oldY markerForm offset |
self changeCursor: Cursor rightArrow.
sensor anyButtonPressed ifTrue: [
markerOutline _ marker deepCopy.
markerForm _ Form fromDisplay: marker.
Display fill: marker fillColor: scrollBar insideColor.
Display border: markerOutline width: 1 fillColor: Color gray.
oldY _ sensor cursorPoint y.
offset _ oldY - marker center y.
markerForm
follow:
[oldY ~= sensor cursorPoint y
ifTrue:
[oldY _ sensor cursorPoint y.
marker _ marker translateBy:
0 @ ((oldY - offset - marker
center y
min: scrollBar inside
bottom - marker bottom)
max: scrollBar inside top -
marker top).
self scrollView].
marker origin]
while: [sensor anyButtonPressed].
Display fill: markerOutline fillColor: scrollBar insideColor.
self moveMarker
]! !
----
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 26 2:02:34 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: coloring the desktop
Here's a quick hack to make the desktop more colorful. More work is needed
to bring it to full 'goodie' status.
---
!ControlManager methodsFor: 'displaying'!
updateGray
(screenController view model isMemberOf: InfiniteForm)
ifTrue: [screenController view model: (InfiniteForm with:
Preferences desktopColor)]! !
!ControlManager methodsFor: 'initialize-release'!
initialize
"Initialize the receiver to refer to only the background controller."
| screenView |
screenController _ ScreenController new.
screenView _ FormView new.
screenView
model: (InfiniteForm with: Preferences desktopColor)
controller: screenController.
screenView window: Display boundingBox.
scheduledControllers _ OrderedCollection with: screenController! !
!Preferences class methodsFor: 'ui prefs'!
desktopColor
"Answer the preferred color for the desktop.
Do the message below after changing the color."
"ScheduledControllers updateGray; restore"
" ^Color lightMagenta "
^Color indexedColors at: 98
" ^Color red: 0.1 green: 0.1 blue: 0.4 "
---
Enjoy,
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 26 2:32:44 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: display updating (was: color issues)
<rambling on>
Regarding display updating and those infamous caches:
As far as I have figured out the updating mechanism it works by
representing the region that needs redrawing as an Array of Rectangles. For
each rectangle the topmost view is asked to repaint that rectangle,
recursively passing any unpainted subrectangles to lower views.
Now if we change the order from depth first to breadth first, so that each
view is visited at most once, we could make a view render itself into a
temporary form (at the display bit depth) and then blit that form to the
various dirty rectangles. This might be fast enough to do without caching.
Of course we could (and probably should) combine this with some sort of
caching. Options might be:
- cache on class (as it is now)
- cache on instance
- cache views taking more than a specified time to render
- use <n> kB for caches in a least recently used scheme
- ???
All variations above could also be done on the subview level.
A further goal would be to enable Sqeuak to cleanly write to (partly)
obscured windows (i.e. without temporarily popping them to top).
Soooo, has anyone done this (and has found it infeasable), is anyone doing
it, comments ...
<rambling off>
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 26 3:59:59 am
From: Hans-Martin Mosner <hmm@heeg.de>
To: squeak@create.ucsb.edu
Subject: Re: display updating (was: color issues)
Georg Gollmann wrote:
>
> <rambling on>
[...]
> A further goal would be to enable Sqeuak to cleanly write to (partly)
> obscured windows (i.e. without temporarily popping them to top).
>
> Soooo, has anyone done this (and has found it infeasable), is anyone doing
> it, comments ...
> <rambling off>
I did something to enable ParcPlace Smalltalk 2.3 to display on
partially obscured windows (for a simulation project with animation).
It was not easy, and there is a performance penalty to be paid.
Also, this was with the original monobit approach to BitBlt, I do not
know how well it would work with view caches of various depths etc.
I would rather have Squeak use multiple host windows. The graphics
system of the host already does handle overlapping windows, so why
should we invent the wheel again?
One possible approach to do it without a major UI overhaul would be to
have multiple DisplayScreen instances, each representing one host
window. Display would be the DisplayScreen of the currently active
StandardSystemController. StandardSystemViews should then remember on
which DisplayScreen they are shown, and use that for redisplaying
themselves.
One shortcoming of this approach is that we would essentially have full
depth bit caching for all DisplayScreens. This would cost quite some
memory. I haven't looked at the ways that make BitBlt to Display
propagate its output to the host window, but probably it would be
possible to avoid the bits instance variable altogether for
DisplayScreen instances, and BitBlt directly to the window.
Then you would need to handle update events from within Squeak.
Probably this is all too complicated, and we should stick with the old
and ugly way of dealing with graphics...
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 26 9:02:40 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Piece missing from Graphics-DisplayLists.st
An attentive user noticed that there was a piece missing from the file
Graphics-DisplayLists.st. I've up-loaded a new version of this, and of
Graphics-DisplayListsViews.st, to the Squeak goodies archive.
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 26 9:16:08 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Pluggable Text View
I've added the file packages/Interface-PluggableMVC.st to the archive.
It's a
simple pluggable text view/controller.
The outline browser application (see my next note) is a good example of its use.
I put it in a separate class category in the hope that the 'powers that be'
would move the pluggable list there in the next release as well.
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 26 9:16:10 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Personal Build Scripts
I've placed a build script for my VI on the ftp site in the file build/stp.fileIn.
It is partly intended as a demonstration of how to make these, and partly as
an invitation for others to post their own favorite build scripts.
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 26 9:16:09 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Outline Browser App
The file packages/Tools-Outlines.st is my simple outline view application.
An
outline is just a keyed collection of texts (with local variable dictionaries).
The outline browser lets one move between these 'chapters' and read/write
outlines from/to files (saving local variables in the process).
In this version, outlines are only 1 level deep--are there any volunteers to
make it hierarchical?
Two outline files are included as demonstrations: a simple test, and one that
includes the contents of the 3 default Squeak text views (welcome, Squeak UI,
change management). You can only load the latter of these with a 1.17 VI/VM.
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 27 9:58:16 am
From: Tim Rowledge <rowledge@interval.com>
To: Squeak mailinglist <squeak@create.ucsb.edu>
Subject: Problems with StandardFileStream implementation
I've had a note to send this mail for ages, but been too busy to do anything. I'm very suprised nobody else has been moved to mention the problem.
FileStream defines rwMode to be used as a bitflag instvar, with 3
bits used; read, write, shorten. Unfortunately, StandardFileStream
overloads rwMode and uses it as a Boolean; thus we can't handle
shorten mode on our writes and whenever you overwrite a file with
less bytes (such as recreating the interpreter.c file) junk is left
at the end of the file!
Obviously this confuses a poor dumb C compiler mightily.
Changing this would seem to mean rewriting the file prims somewhat to
allow them accepting an int flag-word instead of the simple boolean
read/write argument, and then making the other changes so they act
correctly.
Also, the flush primitive ought to be implemented since not all OSs
do a flush simply because the file position is altered.
Is there any work being done on this area, or is it not considered
important for the moment. Anybody got the time to make improvements?
tim
--
Tim Rowledge: rowledge@interval.com (w) +n (oph) one-yet! (w)
tim@sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>
Date: 96 Nov 27 12:18:00 pm
From: CarlGWatts@AppliedThought.com (Carl G. Watts)
To: DanI@WDI.Disney.com, Squeak@create.ucsb.edu
Subject: Bug in Interpreter primitiveBeep (pops stack when shouldn't)
Dan & Squeakers,
There once was this Squeak programmer that was trying to debug a difficult=
piece of code. The code was difficult in that it was running in a Process=
at lowIOPriority so it wasn't amenable to stepping in the debugger.
So this resourceful programmer placed "Smalltalk beep" statements at=
appropriate places in the code so he could tell by listening how far the=
code was getting at certain points.
The bugs turned out to be very pernicious. Part of the reason why is that=
the primitive that implements "Smalltalk beep" pops too many things off the=
stack, leaving the stack invalid! If you have any doubt this makes=
debugging a real nightmare (if you are unaware of this bug), let me assure=
you, it does.
This bug can be demonstrated easily by evaluating the following expression=
and examining the value of "temp" at the time of the halt. With the=
Smalltalk beep commented out, you get the right answer, 4. But with the=
Smalltalk beep evaluated, you get nil in temp!
| temp |
temp _ true.
[temp =3D=3D true] whileTrue: [
"Smalltalk beep."
temp _ 4].
self halt
*************
The fix is simple, remove the pop from the Interpreter>primitiveBeep method.=
This will leave the receiver on the stack which is the proper return value=
for this primitive. Of course you will have to recompile a new VM now that=
you've modified class Interpreter.
Carl Watts
http://AppliedThought.com/carl
Date: 96 Nov 27 4:19:32 pm
From: "David N. Smith" <dnsmith@watson.ibm.com>
To: squeak@create.ucsb.edu
Subject: [LONG] Random Numbers & Floating Numbers
All:
I've ported a couple of my standard things to Squeek:
PrintHex
--------
Methods Float>>printHex, a method that prints IEEE floating point values in
hex in this format:
Float pi printHex '1.921FB54442D18e1'
-------------
All digits are in hex. The exponent is the number of bits to shift the
mantissa. The leading 1 digit is omitted in the raw hex format, but present
here.
For comparison, the hex method produces:
Float pi hex '400921FB54442D18'
-------------
The underlined digits in the two formats match. The remained of the stuff
(400) is a biased exponent and the sign of the number. Here are two other
examples; note how easy the first 3 hex digits are to interpret using the
hex method.
1.23 hex '3FF3AE147AE147AE'
1.23 printHex '1.3AE147AE147AEe0'
-1.23 hex 'BFF3AE147AE147AE'
-1.23 printHex '-1.3AE147AE147AEe0'
I find printHex useful from time to time when trying to convice someone
that floating-point arithmetic is not broken, or in trying to understand
some odd result.
Note that this method was developed and tested for Squeak on a Mac PowerPC.
It may depend on byte ordering and may not work on other platforms without
tweaking. (That's certainly true with IBM Smalltalk versions which index
floats by bytes; Squeak indexes floats a words.)
Park-Miller Random Number Generator
-----------------------------------
The Random class provided with Squeak has a range of 65536. This example
shows that it has only 65535 unique values:
| randy n first |
randy := Random new.
first := randy next.
n := 1.
[ randy next ~= first ] whileTrue: [ n := n + 1 ].
n 65535
This is not a good algorithm. The code below is a version of my Smalltalk
implementation of the Park-Miller algorithm converted to Squeak. (It looks
big but most of the code consists of two testing class methods.
The generator is based on the one from:
Random Number Generators: Good Ones are Hard to Find
Stephen K. Park and Keith W. Miller
Communications of the ACM, October 1988, V31 N10, pp 1192-1201.
For information on testing RNGs, see:
Chapter 3: Random Numbers
which is the first chapter in:
The Art of Computer Programming, Volume II, 2nd Edition
Seminumerical Algorithms
Addison-Wesley. ISBN 0-201-03822-6
Pages 1-177.
The code below is extracted from my random number generator test-bed, part
of an effort to explore random number generators which I started some time
ago and not yet 'quite' finished.
The ParkMillerRNG is used like this:
| randy |
randy := ParkMillerRNG new.
10 timesRepeat: [
Transcript cr; show: randy next printString ].
Summary of methods ---
Creation:
randy := ParkMillerRNG new
Generation:
randy next -- Floating point value: [0.0,1.0)
randy nextInteger -- Integer value: [0, max 32 Bit Int]
Please not that I do NOT recommend this generator for ANY particular
purpose. See the Park-Miller paper for their opinion on its usability. But
you should never use one that is worse, and the one in Squeek is definitely
worse.
---------------------------------------------------------------------------
'From Squeak 1.13 of October 17, 1996 on 27 November 1996 at 5:20:43 pm'!
Object subclass: #ParkMillerRNG
instanceVariableNames: 'seed a m q r mu1 '
classVariableNames: ''
poolDictionaries: ''
category: 'Collections-Streams'!
!ParkMillerRNG methodsFor: 'all'!
initialize
" Set a reasonable Park-Miller starting seed "
seed := 2345678901.
a := 16r000041A7. " magic constant = 16807 "
m := 16r7FFFFFFF. " magic constant = 2147483647 "
q := 16r0001F31D. " quotient (m quo: a) It's 44488 in decimal "
r := 16r00000B14. " remainder (m \\ a). It's 2836 in decimal "
mu1 := 0.46566128752457969e-9. " Reciprocal of m (ie, mu1 == 'm
under 1') "
!
next
" This method generates random instances of Float in the interval 0
to 1. "
seed := self peekInteger.
^ seed * mu1!
nextInteger
" This method generates random instances of Integer
in the interval 0 to 16r7FFFFFFF. "
seed := self peekInteger.
^ seed!
peek
" This method answers the next random number that will be generated as
a Float in the range [0..1). It answers the same value for all
successive
message sends. "
^ self peekInteger * mu1!
peekInteger
" This method generates random instances of Integer
in the interval 0 to 16r7FFFFFFF.
This method does NOT update the seed; repeated sends answer the
same value.
The algorithm is described in detail in 'Random Number Generators:
Good Ones Are Hard to Find' by Stephen K. Park and Keith W. Miller
(Comm. Asso. Comp. Mach., 31(10):1192--1201, 1988). "
| lo hi aLoRHi answer |
hi := seed quo: q.
lo := seed rem: q.
aLoRHi := (a * lo) - (r * hi).
answer := (aLoRHi > 0)
ifTrue: [ aLoRHi ]
ifFalse: [ aLoRHi + m ].
^ answer!
seed: anInteger
seed := anInteger! !
"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
ParkMillerRNG class
instanceVariableNames: ''!
!ParkMillerRNG class methodsFor: 'testing'!
bucketTest
" A quick-and-dirty bucket test. Prints nbuckets values on the
Transcript.
Each should be 'near' the value of ntries. Any run with any value
'far' from ntries
indicates something is very wrong. Each run generates different
values.
For a slightly better test, try values of nbuckets of 200-1000 or
more; go get coffee.
This is a poor test; see Knuth. Some 'OK' runs:
1000 1023 998 969 997 1018 1030 1019 1054 985 1003 1011 987
982 980 982 974 968 1044 976
1029 1011 1025 1016 997 1019 991 954 968 999 991 978 1035
995 988 1038 1009 988 993 976
Execute this: ParkMillerRNG bucketTest "
| nbuckets buckets ntrys randy slot |
nbuckets := 20.
buckets := Array new: nbuckets.
buckets atAllPut: 0.
ntrys := 1000.
randy := ParkMillerRNG new.
randy seed: Time millisecondClockValue.
ntrys*nbuckets timesRepeat: [
slot := (randy next * nbuckets) floor + 1.
buckets at: slot put: (buckets at: slot) + 1 ].
Transcript cr.
1 to: nbuckets do: [ :nb |
Transcript show: (buckets at: nb) printString, ' ' ]!
theItsCompletelyBrokenTest
" Put the first 10 rng's on the Transcript. Execute:
ParkMillerRNG theItsCompletelyBrokenTest
The values should be:
0.1492432697
0.3316330217
0.7561964480
0.3937015400
0.9417831814
0.5499291939
0.6599625962
0.9913545591
0.6960744326
0.9229878997
If they are not these values (accounting for precision of
printing) then
something is horribly wrong: DO NOT USE THIS CODE FOR ANYTHING. "
| rng |
rng := ParkMillerRNG new.
10 timesRepeat: [
Transcript cr; show: rng next printString ]! !
!ParkMillerRNG class methodsFor: 'instance creation'!
new
^ super new
initialize! !
---------------------------------------------------------------------------
Dave
_______________________________
David N. Smith
dnsmith@watson.ibm.com
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author
and not of his employer.
Date: 96 Nov 27 4:31:49 pm
From: stp (Stephen Travis Pope)
To: "David N. Smith" <dnsmith@watson.ibm.com>, squeak@create.ucsb.edu
In-Reply-To: "David N. Smith" <dnsmith@watson.ibm.com>'s letter of: 96 Nov 27
Subject: Re: [LONG] Random Numbers & Floating Numbers
I have placed David's new random generator in the goodies archive (under the
name NewRandom.st).
I re-named the class PMRandom for increased obviousness.
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 27 7:13:51 pm
From: james@clyde.as.utexas.edu (James McCartney)
To: squeak@create.ucsb.edu
Subject: Squeak method cache
I'm trying to decipher the method caching scheme used in the
interpreter. A couple of statements escape me in the findNewMethodInClass:
method in the interpreter. The method cache is probed three times
with a hash index (t2) that is right shifted by one each time through the
loop. I assume this is a double hashing scheme as opposed to simple linear
probing. t4 is the loop counter and is also used as the right shift to the
hash index in the statement:
t3 _ (t2 >> t4 bitAnd: MethodCacheMask) + 1.
What confuses me is where entries are put into the cache. The hash index
for insertions is calculated from:
mcProbe _ mcProbe + 1 \\ CacheProbeMax.
t3 _ (t2 >> (mcProbe * 3) bitAnd: MethodCacheMask) + 1.
mcProbe is a variable that steps around the values 0,1,2 each time it is
is used. I can think of why this might be a good thing to do. For instance
if there were a method cache collision in a loop then performance would
go to hell if secondary probing were not done. I would like to know the
real motivation for this. Why wasn't linear probing used? Gnu ST doesn't
do any secondary probing, it either finds it the first time or looks it up.
But the biggest question I have is what is the * 3 for in (mcProbe * 3)?
I'm not understanding how this works. The lookup hash index is only
shifted by one bit 2 times and the insertion index is shifted by 0, 3,or
6 bits. It seems that it would never find the indexes created by shifts
of 3 or 6 bits. I must be completely confused.
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Nov 28 12:01:50 am
From: Hans-Martin Mosner <hmm@heeg.de>
To: Squeak Mailing List <squeak@create.ucsb.edu>
Subject: Re: Problems with StandardFileStream implementation
I too have a problem with the StandardFileStream:
When compiling the VM with MPW 3.4 prerelease (MrC), the resulting VM
will not be able to create a proper interpreter source.
The method TStmtListNode>>endsWithCloseBracket: will introduce garbage
at the end of lines.
Interestingly, that same method has a comment talking about File
positioning. And when I change the line
aStream position: pos.
to
aStream position: aStream position
as suggested in this comment, everything works fine.
It seems to me that relying on C FILE operations is somewhat
dangerous... Might be safer to implement files on top of more primitive
operations (on the level of UNIX read()/write()).
Hans-Martin
Date: 96 Nov 28 12:07:36 am
From: Hans-Martin Mosner <hmm@heeg.de>
To: Squeak Mailing List <squeak@create.ucsb.edu>
Subject: Re: Squeak method cache
James McCartney wrote:
>
> I'm trying to decipher the method caching scheme used in the
> interpreter.
[...]
> But the biggest question I have is what is the * 3 for in (mcProbe * 3)?
> I'm not understanding how this works. The lookup hash index is only
> shifted by one bit 2 times and the insertion index is shifted by 0, 3,or
> 6 bits. It seems that it would never find the indexes created by shifts
> of 3 or 6 bits. I must be completely confused.
I also stumbled across this one. I am certain that the code for
inserting an entry into the cache is broken. It does not hurt much since
this only affects the hash conflicts, so it probably incurs a small
performance hit. The fix is easy, and I did it but then couldn't
regenerate the VM due to the File positioning problem reported in my
previous mail...
Hans-Martin
Date: 96 Nov 28 9:12:47 am
From: james@clyde.as.utexas.edu (James McCartney)
To: Hans-Martin Mosner <hmm@heeg.de>,
Squeak Mailing List <squeak@create.ucsb.edu>
Subject: Re: Squeak method cache
At 9:08 AM 11/28/96, Hans-Martin Mosner wrote:
>>The lookup hash index is only
>> shifted by one bit 2 times and the insertion index is shifted by 0, 3,or
>> 6 bits. It seems that it would never find the indexes created by shifts
>> of 3 or 6 bits. I must be completely confused.
>
>I also stumbled across this one. I am certain that the code for
>inserting an entry into the cache is broken. It does not hurt much since
>this only affects the hash conflicts, so it probably incurs a small
>performance hit. The fix is easy, and I did it but then couldn't
>regenerate the VM due to the File positioning problem reported in my
>previous mail...
Actually it probably produces a large performance hit since 2/3 of the
method cache entries appear to be unreachable. This hashing function
doesn't work by conflicts the way normal hashing does. Entries are
inserted to probed locations in a round robin fashion, not just if there
is a collision. I'm not totally clear on why, but have a few guesses.
For example if one method is used a lot then it could get hashed in to
up to three slots in the table. Then other methods that collide may
only overwrite one of those, leaving one or two of the original.
However for that to work the cache would have to be inserted every time
not just when there's a miss. That's not the way it is written now,
so I'm not sure what the reasoning is for the round robin secondary
hashing. I'm probably missing something major.
---
I assume the fix is to change the line :
t3 _ (t2 >> t4 bitAnd: MethodCacheMask) + 1.
to:
t3 _ (t2 >> (t4 * 3) bitAnd: MethodCacheMask) + 1.
since this shifts in 3 bits at a time producing a better secondary hash
than a single bit shift each time.
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Nov 28 12:17:07 pm
From: Dan Ingalls <DanI@wdi.disney.com>
To: james@clyde.as.utexas.edu (James McCartney)
Cc: squeak@create.ucsb.edu
In-Reply-To: <v01530500aec2bd386182@[128.83.128.27]>
Subject: Re: Squeak method cache
Regarding...
> I'm trying to decipher the method caching scheme used in the
>interpreter. A couple of statements escape me in the findNewMethodInClass:
>method in the interpreter. The method cache is probed three times
>with a hash index (t2) that is right shifted by one each time through the
>loop. I assume this is a double hashing scheme as opposed to simple linear
>probing. t4 is the loop counter and is also used as the right shift to the
>hash index in the statement:
>
>t3 _ (t2 >> t4 bitAnd: MethodCacheMask) + 1.
>
>What confuses me is where entries are put into the cache. The hash index
>for insertions is calculated from:
>
>mcProbe _ mcProbe + 1 \\ CacheProbeMax.
>t3 _ (t2 >> (mcProbe * 3) bitAnd: MethodCacheMask) + 1.
>
>mcProbe is a variable that steps around the values 0,1,2 each time it is
>is used. I can think of why this might be a good thing to do. For instance
>if there were a method cache collision in a loop then performance would
>go to hell if secondary probing were not done. I would like to know the
>real motivation for this. Why wasn't linear probing used? Gnu ST doesn't
>do any secondary probing, it either finds it the first time or looks it up.
James -
You are right to be confused; this is a long-standing non-fatal bug. We
had a fix to go out in 1.16, but we wound up holding most of the VM changes
for a later release, and this didn't get addressed. Also, this way we find
out who's just running it, and who's really working on it ;-)
Obviously, you can fix it either by multiplying by 3 in both places, or in
neither place. It doesn't make much difference, so I would leave it out
for simplicity.
Here is why I did it the way I did: If you just do linear reprobing then,
if you happen to be unlucky, you can get two or three methods that collide
directly and along their reprobe chains, unless you have fancy reprobe
logic. This scheme makes the reprobes pretty independent, and makes that
situation very unlikely.
About performance: when you fix the bug you should see an immediate drop
in cache misses by a factor of three. Unfortunately (or fortunately,
depending on how you look at it), Squeak already hits about 93% of the
time, so the boost to 98% doesn't make a big difference.
The original logic behind the *3 variant was to introduce more
(independent) bits of the hash at each reprobe. But then I saw that it
didn't make any difference, and with 9 bits of original hash, there were
only 6 independent ones left anyway, so I decided to go for the simple
1-bit reprobe shift. I just forgot to fix both places. Mea culpa.
Nice to know you're paying attention.
- Dan
Date: 96 Nov 29 7:48:56 am
From: John Maloney <johnm@wdi.disney.com>
To: james@clyde.as.utexas.edu (James McCartney), squeak@create.ucsb.edu
Cc: John Maloney <johnm@wdi.disney.com>
Subject: Re: Squeak method cache
James:
It sounds as though you are not seeing the comments and variable names in
the system
sources. The problem could arise from (a) not having the system sources
file in either
the same directory as the virtual machine or (b) not having the .changes
file in the
same directory as the .image file. (The source for a method can be in
either the
.changes file or the system sources file, depending on whether it was changed
after the sources file was built.) If the system can't find the source for
a method,
it decompiles it from bytecodes, but it has to make up names like t1 and t2 for
the local variables and, of course, it has no comments. I enclose the commented
source from the latest version of the image I have with me, which is version
1.13.
>From your message, it sounds as though your version of this method is an older
one. I can't check recent versions of the system right to determine which
version of the method is in our more recent releases. Do you know which version
of the image you have (1.1, 1.13, 1.16, etc.)? As Dan said, we've fixed
the bug
you found, but we could have accidentally reverted to the old version somewhere
along the line.
Interestingly, the bug isn't as terrible as it may appear, since it only
affects
reprobes. I recall measuring 80-85% hit rates with the bug and 96-99% hit rates
after the bug was fixed. The overall performance difference was scarcely
noticable (which says something about where the bottlenecks are in our
current VM).
Hope this helps.
-- John
findNewMethodInClass: class
| hash probe p |
"NOTE: Does NOT use hash field, but direct oops instead.
Therefore must relocate or flush when compacting storage.
[Have to do this for class oop anyway]."
hash _ (messageSelector bitXor: class) >> 2.
"This shift drops two low-order zeros from addresses"
"First try a few probes in the cache"
0 to: CacheProbeMax-1 do: [:p |
probe _ ((hash >> p) bitAnd: MethodCacheMask) + 1. "see
reprobes, below"
((methodCache at: probe) = messageSelector
and: [(methodCache at: probe +
MethodCacheEntries) = class]) ifTrue:
[newMethod _ methodCache at: probe
+ MethodCacheEntries + MethodCacheEntries.
primitiveIndex _ self
primitiveIndexOf: newMethod.
^ nil]].
"Not found in the cache."
self lookupMethodInClass: class. "Look it up the hard way"
mcProbe _ (mcProbe+1) \\ CacheProbeMax. "Pick a randomish reprobe
for it"
probe _ ((hash >> (mcProbe*3)) "see below"
bitAnd: MethodCacheMask) + 1.
methodCache at: probe put: messageSelector. "and install it there"
methodCache at: probe + MethodCacheEntries put: class.
methodCache at: probe + MethodCacheEntries + MethodCacheEntries
put: newMethod
"About the reprobe scheme...
The hash is the low bits of the xor of two large addresses.
By shifting 3 bits right, we should introduce 3 new randomish bits,
leading to an 8-way scatter at each level of reprobe."
Date: 96 Nov 29 7:43:25 pm
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: desktop color update
There is a minor update to desktopColor.st at
<http://ftp.tuwien.ac.at/~go/Squeak> which slightly improves display
updating when view caching is off (StandardSystemView dontCacheBits).
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 30 5:20:03 am
From: John Maloney <johnm@wdi.disney.com>
To: Tim Rowledge <rowledge@interval.com>
Cc: Squeak mailinglist <squeak@create.ucsb.edu>,
John Maloney <johnm@wdi.disney.com>
Subject: Re: Problems with StandardFileStream implementation
Tim,
Thanks for your comments. There's definitely a problem there.
However, it turns out to be difficult to implement "shorten" on
the Mac. Essentially, you have to create a new file, copy the old
file into the new file up to the truncation point, delete the old file,
and rename the new file to replace the old one. This is best done
at the Smalltalk level, rather than in a primitive, and I have been
intending to make the necessary fixes for some time. I may not
get around to it for several more weeks, however.
-- John
Date: 96 Nov 30 5:20:16 am
From: John Maloney <johnm@wdi.disney.com>
To: CarlGWatts@AppliedThought.com (Carl G. Watts)
Cc: Squeak@create.ucsb.edu
Subject: Re: primitiveBeep pops stack when shouldn't
Gak! Stack errors in prims are a terrible pain. I'm rather amazed
that we haven't seen this one before, but I'm glad you found it.
It's my bug; sorry!
-- John
Date: 96 Nov 30 12:02:51 pm
From: "David N. Smith" <dnsmith@watson.ibm.com>
To: squeak@create.ucsb.edu
Subject: Bugs: Debugger and File save
A couple of bugs:
==========================================================================
When stepping, the debugger doesn't always update local variables. I've run
into worse cases than the simple examples below, but I think this
illustrates the problem.
|a b|
self halt.
a := 0.
b := 0.
self halt.
10 timesRepeat: [
a := a + 1.
b := a factorial ].
self halt.
b
Select and DoIt. Enter the debugger at the first halt. From the top stack
position do steps until the second halt is about to be sent.
The variables a and b are still nil.
Proceed and enter the debugger again. The variables a and b are now
correct. Keep sending, except when necessary to step.
Note that while sending down thru factorial the debugger highlights the ^1
and the self printString even though it isn't executing them.
factorial
"Answer the factorial of the receiver. Create an error notification if the
receiver is less than 0."
self = 0 ifTrue: [^1].
self < 0
ifTrue: [self error: 'factorial invalid for: ' , self printString]
ifFalse: [^self * (self - 1) factorial]
On return from factorial, this code is highlighted as if it is finished
executing the block:
timesRepeat:
[t1 _ t1 + 1.
t2 _ t1 factorial]
but t2 still shows the old value.
-------------------
Now, try this variation.
|a b|
self halt.
a := 0.
b := 0.
10 timesRepeat: [
a := a + 1.
b := a factorial ].
self halt.
b
Select the top of the stack and do a step. Note that the next stop is in
the timesRepeat: block and that a and b are still nil.
Then, DoIt again but this time select the DoIt stack entry and do a step.
The next stop is also in the timesRepeat: block but now a and b are both
zero.
Also note that while on succeeding passes through the timesRepeat: loop,
the block is debugged as a result of sending value inside timesRepeat:,
this first time it is shown within the body of the DoIt method.
==========================================================================
Open a file in the file browser. Spawn it into its own window. Make a
change. Select put. When asked if it is OK to overwrite, choose not to. A
halt walkback occurs.
newFileNamed: aFileName
"create a file in the default directory (or in the directory contained
in the input arg), set for write access. 2/12/96 sw. Fixed 6/13/96 sw so
that if deletion of old conflicting file fails, the error raised is more
helpful."
| result |
(self isAFileNamed: aFileName)
ifTrue:
[(self confirm: (self localNameFor: aFileName) , ' already exists.
Do you want to overwrite it?')
ifTrue: [result _ FileDirectory default deleteFileNamed: aFileName.
result == nil ifTrue: "deletion failed"
[self halt: 'Sorry - deletion failed']]
ifFalse: [self halt]].
^ self new open: aFileName forWrite: true
==========================================================================
Dave
_______________________________
David N. Smith
dnsmith@watson.ibm.com
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author
and not of his employer.
Date: 96 Nov 30 12:03:48 pm
From: "David N. Smith" <dnsmith@watson.ibm.com>
To: squeak@create.ucsb.edu
Subject: Bugs
Uh oh, I forgot to mention I'm on 1.16 on a Mac PPC9500.
Dave
_______________________________
David N. Smith
dnsmith@watson.ibm.com
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author
and not of his employer.
stp@create.ucsb.edu]
Created: 1996.11.08; LastEditDate: 1996.11.11