Matthew Fulmer Peek Application
Last updated at 6:30 am UTC on 3 April 2007
Project
Peek is an experimental viewing and debugging framework that attempts to generalize and extend the usefulness of the Smalltalk inspector and debugger tools. At the core of Peek is the ability to simulate and examine selected aspects of selected objects. This simulator will be based on the current Smalltalk debugger, but should handle arbitrary threads of execution.
The key difference between the Squeak debugger and Peek will be that Peek is more reactive, transparent, and selective than the current tools:
- transparent to the user: The user will enter a query into peek, and the system will continue running, and peek will examine existing and new objects that satisfy the query. The user does not need to manually open inspectors on certain objects; peek should do that for them.
- reactive: When a message is sent anywhere in the system to an object that peek is watching, peek will intercept that message and begin simulating it and showing the user exactly what is being done internally. The user does not need to actively change the code by inserting self halt in a suspect method; instead, she can let peek reactively intercept messages to the object, then view what happens to them, either in slowed-down time, or in user time (aka single-stepping). When the user is no longer interested, he can disable the peek interception, and the system will run at normal speed.
- selective: The user may not be interested in all properties of an object, or all messages sent to an object. The user will be able to filter out objects and messages she is not interested in in order to cut down on visual noise. Also, the user may not be interested in messages sent from the focus objects to the outside world; these messages can be sent without peek watching them and the user seeing them. This is the difference between "into" (send) and "over" (step) in the current squeak debugger.
This could all be done using a textual interface similar to the existing Squeak tools, but peek will (eventually) use a more graphical interface, where each object (including messages) is represented by an on-screen icon, and pointers by a line between objects. This creates an active graph representing the interesting parts of the system.
Implementation
This is a rather large project, involving a near-realtime query system for the Squeak object memory, a selective debugger, and a new user interface. Therefore, I will focus on getting a useful product out fast, and save the killer UI for later. How can I do this?
1. A more fine-grained event producer
By drawing code the existing Debugger and MessageTally tools, I can create a framework that transforms very mundane Smalltalk events, such as a message sends, object creation, and garbage collection, into OBAnnouncements. This will require a bit of experimentation, as it will be all too easy to get into an infinite announcement loop with this. Also, it will have to be quite limited in focus, since the system would slow to a crawl if, for every message send, an announcement was created, broadcast, and processed.
However, such a framework, once working, would allow anything imaginable to be debugged, logged, or whatnot, in a much more uniform manner than is possible with the current thread-oriented debugger.
2. A tool to use it.
The most trivial use of such a framework would be a simple message logger. This will be the first tool created using the framework, as well as the method used to test the framework. The next step would be to recreate the Squeak debugger, inspector, object explorer, and MessageTally tools using this framework. Finally, I would tie it together into a message-logging debugger that will have a useful interface for creating event queries, as well as some useful pre-built queries.
Schedule
I will (hopefully) be working 40 hours per week during the summer at my internship. That will take up 4 days per week. I will work on this project approximately 15 hours per week on Wednesdays, weekends, and the bus. Creating the logging framework, unit tests, and a sample message logger will occupy the first 2 months of the project, and creating the new debugger will take up the last month (Assuming a 3-month summer):
- Event producer:
- Create unit tests to run a few sample programs under peek's watch, and check the announcement sequence for bugs
- System to add bytecodes to CompiledMethods to announce their running (1 week). This will probably make use of the ByteSurgeon framework created at the University of Bern. (see Marcus Denker's email)
- Edit Compiler, so that this works even when methods are newly-compiled (1 week). This may be handled by ByteSurgeon already
- Implement removal of these method annotations (1 week)
- Extend to support Announcements Framework at: object creation (1 day), garbage collection (3 days), instance variable assignment (5 days), temp variable assignment (2 days), and Pool assignment (1 day)
- Testing and Debugging (1 week)
- Tools
- Inspector
- annotate instance assignments at startup (1 day)
- listen to and use these Announcements Framework (2 days)
- de-annotate assignments at shutdown ( 1 day)
- Traditional Debugger
- make sure the new inspector works correctly within the debugger (2 days)
- New Debugger
- replace Thread pane with a hierarchical method history of interesting message sends. (1-2 weeks) This can probably draw on the Back-in-time debugger (see Marcus Denker's email)
- add a pane to type code to watch certain events
- Query system
- specify, test, and implement a Domain-Specific Language for specifying useful sets of events to watch for. (3-4 weeks)
About Me
My name is Matthew Fulmer, and I am a 21-year old college student at Arizona State University in Phoenix, USA. I am double-majoring in Computer Systems Engineering and Electrical Engineering, and will receive those two Bachelor's Degrees next December. I have been somewhat successfully organizing a documentation team to improve the state of Squeak documentation. We have focused almost exclusively on creating and categorizing Squeak tutorials. Recently, I have been busy porting ThingLab to recent Squeak images.
Although I have little experience in them, I am very interested in user interfaces and compilers. Due to my research at ASU, I have some experience in pattern recognition and signal processing. I created this project partly as an answer to the desire for a more introspective inspector, as expressed in the Viewpoints NSF grant.
Although Smalltalk is better than most systems, it is still harder than necessary to examine and log the history of an object. I want to be able to see more deeply into the worlds we create inside the computer, and that is why I proposed the Peek framework.
See Also:
