I remember fondly the interactions I had with Jr High students when I was teaching electronics in High School. Those younger kids came after school to a Amateur Radio Club up at the Sr High because they really wanted to get their license, build their own transmitter, and learn about electronics.
I rededicate myself to my belief that there are many kids in their young teens, who would really like to learn about computers, and how to program them. I would like to expand upon PyDebug, to develop a family of software tools, which will lead learners down the programmer path.
I worked pretty hard to make sure that PyDebug would run on all the early builds. Now that build 852 is available, with its full gnome desktop capability I believe that compatibility with earlier builds is no longer critical. Any enterprising teen should be able to get his XO unlocked, and upgrade to a full gnome platform. So as I try to imagine what the next pieces in the software development curriculum should be, not everything needs to be sugarized to be useful.
Next puzzle pieces
Seems to me that every young developer should have facility with a good text editor. I recently verified that yum repositories loaded Build 852 with “vim” and “gedit”. All that remains is to verify, and perhaps think about how localized versions can be orchestrated.
Very quickly, students need to be exposed to the html-client-server world we are developing. I’d like to identify the best open source html editor that runs on the XO (I’m currently interested in Bluefish). Do we need an activity that encapsulates a php enabled apache server? I’d like to look into packaging sqlite admin that runs under xulrunner, for teaching and learning about databases.
Maybe there’s a database application which catalogs music and/or images I could develop into an Activity, primarily as a software example and learning tool.
So what kind of help do I need?
One of my priorities now is to get started on internationalization. I just today generated the PyDebug.pot file in the PyDebug.activity/po folder, which will permit the menus to be translated.
When I look at the Deployment data it seems clear that my first priority should be to get a spanish help section going. The help system of PyDebug has a place holder “Spanish” root page (in english), and I have verified that when the language is changed via the control panel of the XO, the place holder Spanish page is displayed. I have found Spanish versions of some of the packages that are included in the English version of help but I need to download them and put them in place.
On the whole, the Help component of PyDebug seems incomplete, and of low quality. I guess my hope is that some volunteers will appear who are willing to improve and expand the Help section in directions that make sense. I heard of a group of college students in Manila who were starting on an Activity development project. They might be willing to take on the “first users” role.
In the longer term, my vision is that I need to write my program so that localized HTML help can be downloaded as a language pack, and become available automatically in PyDebug.
I need to get first impressions from people who program and from those who want to learn to program.
New in this Version
Breakpoint, trace() calls, and shell() calls are placed in the editor, and remembered across exits and restarts of PyDebug. Playpen checksum (actually an md5) is calculated at load time, and an notification is issued when the user is about to abandon playpen code that has been modified.
Breakpoints are essential when using a debugger. So far, I’ve encountered a blockage in getting IPython to stop at a breakpoint that is set on code that is executed due to a callback from a button press. So in the short term, I’ve developed a work-around. There is an easy way to insert a single line in the user’s program which executes the IPython debugger in the context of the insertion. (Inserted lines are stripped from the code when it is written from playpen to storage).
What’s missing in this Version?
The examples need a lot of development. I had hoped to have a simple gtk widget cookbook, sort of condensing the pygtk tutorial examples. I’d like to find some simple pygames to Sugarize. Do one as an example. Leave one to the learner.
The pleac branch on the help page need to go away. I’m not sure about “Dive into Python” as an intro.
It would be nice to configure pydoc so that the program in the playpen is featured at the top of the pydoc page. Work an example of how to use pydoc to learn essential information, solving real world programming version/interface incompatibility situation.
This gallery contains 1 photo.
Loading templates, saving, modifying, installing XO Activity Bundles Load the “Hello World” activity into the playpen/work area by clicking on the first item in the Examples window (which displays “HelloWorld…ivity”), and then click on the <right arrow>. Create a copy … Continue reading
Download Version 6 of PyDebug which was released October 5, 2010.
View the Help files included with the PyDebug activity.
Plow through earlier PyDebug development plans, progress reports, archive info at laptop.org
Email the author of PyDebug at georgejhunt <at> gmail.com
PyDebug was started late in 2009. But it’s development was put on the shelf in April of 2010, when it’s author was asked to try to find some way for users of the XO in the developing world to participate in the social networking that was so much an enthusiasm in the US and Europe.
Now in October of 2010, XoPhoto has been released, and it is time to resume development of the debugger.
What’s done? The basics are in place:
- Terminal, editor, project page, and browser/help page seem to function when executed in builds ranging from 650 on up to 852.
- Ipython is a terminal based command line debugger. The close cooperation between it and a cooperating editor is implemented ie. the editor positions itself to the line where an exception is discovered by the debug module.
- The graphical interface to the sugar defined “activity.info” setup file is functioning on the project page, as is the quick-and-dirty svg icon generation facility.
What is left to do?
- Debugging a GTK program with a command line debugger is a little tricky. During the startup phase, as the GTK memory structures are being set up, a programming error usually creates an exception, and useful diagnostic info is written to the terminal screen. During this start up process, the debugger can be set to break at line numbers, and variables can be examined, etc. But once the graphical interface is set up, control transfers to the gtk main loop, and the program that is being debugged is executed in response to mouse clicks and keystrokes. If the user sets a breakpoint in a routine that is a response to a mouse click, the breakpoint routine will stop execution of that subroutine, and pass the control back to the gtk-mainloop. IPython provides a means for including the terminal debug session in the GTK mainloop, but this functionality has not been developed, tested, and or documented.
- There needs to be a tutorial which leads the learner through the development of a simple activity.
- I’d like to develop simple template activities that demonstrate mesh networking, collaboration interface and gradually increase the coverage of templates and examples.
- There needs to be a mechanism for substituting help data for all the different languages into which PyDebug might be translated.