Python Debugger activity for the XO

From OLPC
Revision as of 05:31, 11 October 2009 by Ghunt (talk | contribs) (→‎Exploration of What's available)
Jump to: navigation, search

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

Technical explorations and Tradeoffs

Exploration of What's available

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. 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. 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.

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 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
Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Python_Debugger_activity_for_the_XO&oldid=220354"