Python Debugger activity for the XO

PyDebug Links and Resources

Download version 7 December 19, 2010
Help files for PyDebug included in the Activity (useful offline)
Public forum useful into the future to collect FAQ, best practices, and user feedback.
Git repository for PyDebug.
Bug Trac listing of current bugs.
Link to Enter a new bug into PyDebug tracking system.

Objectives And Strategy

For a Snapshot of current status as of 10/25/09
For a Snapshot of current status as of 1/8/10
For a Snapshot of current status as of 4/29/10

It would be wonderful to have a python sourcecode debugger for the XO, fully integrated with sugar. But at this point, even command line tools like Ipython and PDB, are difficult to use within the SUGAR environment. It appears that most Activity development is done using emulation and cross machine development. The purpose of this Activity is to develop, as quickly as possible, the minimal functionality which will permit stand alone development of Sugar Activities on the XO.

• One way it will try to minimize development time is by combining Activities that are already available on the XO -- such as Write, Browse, and Terminal (with ipython).
• Another is to tightly control the addition of "nice to have" features.

It would be nice if this activity can become a springboard for older students as they explore the world of Python, Gtk, and Sugar Activity development. In the service of this objective, PyDebug should provide simple working examples which can be explored and modified. It should provide a set of offline documentation, available in html, as learning facilitation.

Features

There will be 5 notebook pages in PyDebug:

1. A Terminal page - lifted from the Terminal Activity -- with 2 terminal tabs. The first is the interactive debugging front-end, the second is the debugger engine. The two processes are connected via a socket connection (will allow remote debugging in the future).
2. An Editor - The "Develop" activity (based upon sourceview2) has been incorporated, almost without modifications. As of 11/20/09 search/replace needs work/testing.
3. The "Child Screen (the debugee) as of 11/20/09 I might have to rely on alt-tab to get from debugger to program under test.
4. Project data - which maps to the "activity.info" file required by the Sugar interface, This could also provide access to example Activities.
5. Help -based upon the Browse Activity and Hulahop

Technical explorations and Tradeoffs

Exploration of What's available

CONSIDERATIONS 

• An activity needs to bring everything it needs along within it's own package. A number of available solutions are based on TKinter, WxWidgets, or QT. We should focus on GTK based solutions. See this list http://wiki.python.org/moin/PythonDebuggers Our Activity needs to be GPL.
• One impression is that there has already been a lot of development of debuggers. Some of the downloads are 5 or more mB downloads compressed.

OPTIONS

• IDLE comes with python and is installed on the XO. But it requires TKinter. The tkinter yum download is 4+ mBytes. That would be a lot of baggage to carry along in our PyDebug Activity.
• The combination of DDD and pydbgr needs to be explored further.
• I just discovered a python remote procedure library which looks promising: see http://rpyc.wikidot.com/theory. It looks promising as the glue which will solve more than one of my architecture issues. It will allow the debugger and the program which is being debugged to run in separate processes, thereby preventing a buggy program from crashing the whole application. The rpc function will also solve the question of how to integrate Gedit into the activity.
• As an additional benefit, by isolating the two processes, it opens the door to sharing a debugging session among a number of XO's.

Currently at a crossroads

The work done so far, refactoring Terminal, Write, Browse has helped me learn about Sugar, and Activity development in general. At this point I could probably shift to another presentation system, or another backend debugger, without any lost effort. I currently use Komodo remotely for editing, and inspect the log crash traces on the XO. It seems that many debuggers are essentially remote debuggers, like Komodo, and the communicate between the front end and the lower level via a socket.

Datastore interface

The native format of an XO Activity will be the format used by the debugger when it stores the program away in the journal. Once the debugged program is bug free, it can be resumed from the journal, and thereby installed permanently on the local machine, and it can be shared more widely to other XO's. During the development process, the zipped XO file is expanded from the journal into the SUGAR_ACTIVITY_ROOT/tmp directory, modified and executed from there, and then re-zipped and stored back in the journal at the end of the debugging session. During the debugging process, the editor operates, and saves to the disk as a normal editor would.

NOTE:I found documentation which suggests that .../tmp may be disk-space limited. So I moved the development arena to a subdirectory under (sugar-activity-root) data.

Current Status

10/10/2009 Terminal, Write, Hulahop modules load into a single screen, Ipython, and PDB running in Terminal can launch an Activity within the same process (no spawn or second thread) as the debugger. Currently debugging the interface to the journal.

10/11/2009 Thought better of having the activity and the debugged program in the same process. Discovered the rpyc library.

10/25/2009 Replaced Write Activity with Sourceview. Used glade to specify the project page. Wrote treeview file system module. Current focus is to get the activity save/load interface with the Journal in place again (I had it working when Write was part of my application). Also to document where I'm at so I can more effectively ask for help at my stuck points.

11/20/2009 The interactions between the loaded program (I'm calling it the item in the playpen), the journal, the writable disk storage, and the saved application state have been challenging to perfect. I installed a md5sum hashing as a way to determine whether the application needs to be changed, and have most of the user alerts in place to protect the changes a user may have made.

A lot of discouragement was encountered as I tried to get the hulahop/help portion of the application running on build 802. It seems that the software stack has changed significantly, even though both build 802 and FC11 are based upon the same xulrunner version. Tentatively, I've concluded that I will need to package help as a separate application for 802 users. Maybe sometime in the future, I can recompile the essentials and backport to 802.

3/1/2010 Overcame the Browser incompatibility with sugar 0.82 this morning. I'm deciding to put the git/journal integration into the second release. Seems like I should focus on mainline functionality and get this project out the door. I'm going to try to get PyDebug onto sugarlabs git by the end of this week.

Next Steps

There are some significant unknowns.

• Can I subclass Activity so that when an Child tries to add his canvas to the screen under the Activities toolbar, he actually puts himself on the correct page of the debugger notebook?
• Can I accomplish this with Gedit, essentially hijacking the Gtk.Mainwindow and repositioning it on the Child screen?
• When the breakpoint is hit, while gtk.mainloop is in control, can Ipython regain control, and switch back to the terminal screen?

Once this basic functionality is in place, I need to put PyDebug on Git and get Trac bug going.

I would love to find a development partner, or someone to talk the issues over with. I'm hoping to find a mentor on the development list or the support-gang; someone who knows more about this than I do.

It would be nice to connect with college level teachers of programming to see if we could insert the contributor's program into their curriculum. There are a number of follow on projects which would greatly enhance the ease of developing Activities on the XO:

• GEdit Activity
• Glade Activity for easy GTK layout
• Firefox with SQLite add-in and Screem as a client/server database development tool