links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Matthew Fulmer Peek Application
Last updated at 6:30 am UTC on 3 April 2007


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:

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.


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.


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):

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: