"Martin Kobetic" <martin at objectpeople.com> wrote...
>There was a series of articles in Smalltalk Report (long time ago,
>obviously) and there is a code in the archive on UIUC (Called
>LightweightClasses and ObjectDebugging, I believe), which implement
>breakpoints in some ancient version of VisualWorks. I've got the breakpoints
>to work in VW5i quite easily, but so far did not get around to make the
>necessary GUI enhancements. Anyway, I believe it should be fairly
>straightforward to make it work in Squeak as well. Breakpoints are much
>better than 'x halt'.

Folks -

I just fetched this code and looked at it.  It is quite lean -- a lot of bang for the buck.  I include the summary here below.  It's 33k, most of which is a specialized browser with a specialized kind of list.  The kernel breakpoint and lightwieght class code is very small.

Two questions:

Does anyone know of better code available of a prefereable way of doing this?

Would anyone be interested in porting this code to Squeak?

	- Dan
-------------------------
	NAME			ObjectDebugging
	AUTHOR			hinkle at primenet.com
	FUNCTION			Adding LightweightClasses and Breakpoints
	ST-VERSIONS		R4.1
	PREREQUISITES		None
	CONFLICTS		None known
	DISTRIBUTION		World
	VERSION			1.0
	DATE			25 October 1994
SUMMARY ObjectDebugging
	Adds two new concepts to the ST-80 programming environment:  lightweight 
classes and breakpoints.  Lightweight classes are a new kind of Behavior that
allow specific behavior on a per-instance basis.  This is useful in many ways,
and the main emphasis for this project is in using unique object behavior as an
aid in debugging and system exploration.  Breakpoints are an easy way of adding
'self halt'-like behavior at the beginning of methods without changing source
files.
	The code in this file is described in the article 'Debugging Objects,' written by
myself, Vicki Jones, and Ralph Johnson, which appeared in the July-August 1993 
issue (Volume 2, Number 9) of The Smalltalk Report.
									--  Bob Hinkle
"!

"Welcome to objectDebugging.st.  This file contains the complete source to
add lightweight classes and breakpoint methods to your system.  Together
these two changes provide new techniques to use while debugging.  Since
the code is largely uncommented, these prefatory paragraphs serve as
documentation for now.  The following paragraph is a brief introduction to the
purpose of this file, while the one after that explains the interface in more
detail."! 

"The notion of a lightweight class comes from the desire to be able to change
the behavior of a particular object without also changing all the other objects
of its class.  This can be done by creating a special class for the object, but
that's expensive in both time and space, so there's a need for a kind of class
that's cheap to create and store--and that's what a lightweight class is.  The
lightweight class is created between an object and its real class, and so any
methods defined in the lightweight class apply only to a singular object. 
Thus, you can modify the add: method of a particular OrderedCollection, say,
without changing all the many other OrderedCollections in the image.  One of
the changes you can make in a lightweight class (and in regular classes, too)
is to put a breakpoint on a method.  Breakpointing a method is like adding
'self halt' as its first line, but there are some important differences.  First, it's
easier to add (and remove) a breakpoint, since it's done by menu rather than
by typing.  Second, adding/removing breakpoints doesn't affect the various
change mechanisms, so the change set and change log don't include trivial
changes for putting (and presumably later removing) a halt in a method.
Finally, breakpoints are invisible in source code, so when you edit a
breakpointed method in a browser (or look at it in the debugger), you see
only the normally defined code--the breakpoint itself is transparent.
Combining lightweight classes and breakpoints allows you to set breakpoints 
on methods belonging to an individual object.  So it's possible to set a
breakpoint on the add: method of one OrderedCollection without bringing the
rest of the system to a grinding halt.  That kind of debugging is what our
object debugging package is for."!

"The interface for all this is (I hope) relatively simple.  You can send any
object the message 'browseLightweight' to create and edit its lightweight
class.  (Alternatively, there's also a browseLightweight menu option from any
Inspector.)  This kind of browsing creates a special Lightweight Class
Browser, which looks something like a ClassBrowser, but there are several
differences.  First, lightweight classes don't have protocols, so rather than
seeing methods organized into protocols, you just see a list of all methods for
the lightweight class.  The method display uses two formatting conventions to
convey information:  methods that are defined in the lightweight class have
their selectors printed in boldface, while those with breakpoints have their
selectors preceded by asterisks.  Second, in the upper right hand of the
browser is a text pane that lets you choose which methods to list--you can
either show only methods defined in the lightweight class, or all methods up
to some menu-chosen superclass.  This option is convenient since it lets you
look at methods as defined in a superclass and then alter and accept them in
the lightweight class.  Finally, the lightweight class browser has an inspector
for the object at the bottom, because we believe users will often want to get at
objects and their instance variables in the context of object debugging.
Adding breakpoints is even easier:  every method list now has a menu option
called 'breakpoint,' which occurs right above 'move to ...'  This option is a toggle 
switch--if the method is not breakpointed, a breakpoint will be added
(and the method's selector will be preceded by an asterisk to indicated this.)
If the method is already breakpointed, choosing 'breakpoint' will cause the
existing breakpoint to be removed.  We envision the browser will be used as
follows:  a programmer finds there's a problem in a particular method, with
some object behaving strangely.  So, he or she puts a breakpoint in that
method or some previous one where the object is created.  When that
breakpoint is triggered, the programmer opens a debugger and looks at the
problem object in the inspector.  Using the browseLightweight menu option,
the programmer changes or puts breakpoints on important methods of the
object, and then proceeds from the debugger.  Now he/she can monitor that
one object's behavior and (we hope) discover what the problem is."!

"This code was developed for Smalltalk-80 Release 4.1 for the Macintosh.  It
should work on earlier releases with work on the interface, and also on
compatible versions for other platforms.  We're interested in feedback on this
package, so please let us know if you have comments, questions, problems,
or ideas.  In particular, we're interested in whether you find these changes
useful for debugging, other features you'd like to see added to this package,
other debugging improvements you'd like to see in the Smalltalk
environment, and finally any other uses you have for lightweight classes.
Please direct any such comments or questions to Bob Hinkle at
hinkle at primenet.com."!