links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Peek Debugging and Viewing Framework
Last updated at 6:10 pm UTC on 19 March 2007
by Matthew Fulmer


Peek is a different kind of object inspector that incorperates features from an inspector and debugger to give the illusion of being able to take apart any object into it's components (instance variables and such) and watch it tick. It will have a graph-based interface, where objects are represented by nodes and pointers by edges.

The key idea behind peek is that an inspector and debugger are fundamentally the same kind of thing: a view on an object, or set of objects. They differ in two aspects: speed of execution, and field of view. An inspector views it's object as it is running in real-time, but it has a narrow field of view in that it only views a single object and it's immediate sub-components.

Similarly, a debugger is a view on a set of objects which share a common thread of execution. It views the objects in "user-time", where the speed is completely controlled by the user, ranging from stopped to full-speed.

Peek will generalize these two concepts into an object-viewer, where both the speed of execution and the field of view are completely user-definable. A user-definable field of view creates many possibilities:

This cannot easily be done using the existing tools of debugger and inspector without a bit of indirect intervention (such as putting self halt in the code). This creates an additional step in that the user has to intelligently guess about where the problem lies, and hope that they are "close enough" to find it when the debugger engages.


A dynamic field of view will require a dynamic interface; the interfaces of the debugger and inspector are too static. Peek will use a more direct view: every object of interest will be drawn on screen as a view. If an object contains another object, such as an instance variable, and both objects are within the fild of view, An arrow will be drawn from the container to the sub-object. Thus, peek will render dynamic graphs of the objects in its field of view, showing the relations between them. Nearly all the tools in a smalltalk system could, under peek, be reduced to the task of finding the appropriate field of view, and let peek actually show the objects. A hierarchy browser would set the field of view to a class and some of its ancestors and decedents; a method finder would set the field of view to a set of methods and their implementors.


The core of the system, as well as a useful tool to utilize it is now a proposed Google Summer of Code 2007 project. See Matthew Fulmer's application for a discussion of the core of Peek.

Next step would be to create the visualization for the objects. One could begin by drawing all objects as a simple rectangle, or we could use something like morphic wrappers to render all objects as Morphs.

An easy way to specify and update the field of view is critical to make this a useful system; indeed, it is the most difficult problem in this proposal. One possible implementation would be the SOUL language for VisualWorks, or something similar to Star Browser.

Another good improvement would be automatically drawing the object graph by means of a spring model or something similar. Then we can start improving the look and animations in the graph, such as making messages originate from the sender and execute inside the receiver.

See also: