Python Debugger activity for the XO

Objectives And Strategy

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
2. An Editor - Initially lifted from Write, but possibly replaced by Gedit, if a dbus interface to Gedit can be created via a Gedit python plug-in.
3. The "Child Screen (the debugee)
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

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.

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.

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'm hoping to find a mentor, 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