Peek Debugging and Viewing Framework
Last updated at 6:10 pm UTC on 19 March 2007
by Matthew Fulmer
Idea
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:
- We could open a viewer on a window and it's submorphs and their messages. Messages are objects, and we could observe them as they are created, sent, executed, and returned.
- An object and all it's temporaries. As an object executes, it tends to create many short-lived objects to do it's bidding. A great way to speed up objects is to eliminate the creation of as many of those temporaries as possible. In this view, one could, at a glance, see how much time is spent creating and garbage-collecting temporary objects.
- A client socket, the requests flowing through it, and their creators. Doing protocol debugging means finding the packets that are not correct and then figuring out where it came from. This usually means logging all the packets searching through them until the invalid ones are found. At that point, information about who sent the packet has often been lost. If we watch the socket and its packets as they are flowing, it is much easier to trace their origin.
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.
Interface
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.
Implementation
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:
