Rur-ple 1.0rc

Rur-ple 1.0 is finally out ... sort of. Actually, it's a Release Candidate version. For the next little while, any free time I'll have is going to be spent on preparing my Pycon presentation (and working on Crunchy as needed to improve it before Pycon 2007). Since I had three more localizations available (German, Turkish and Welsh) than there was on sourceforge, I decided that it was better to release early. In the meantime, someone is working on an Italian localization (and possible lessons translation) which should be included in the final 1.0 version.

Pycon 2007: it's Crunch time

Yesterday I got some good news from the Pycon organizers: my proposed talk entitled Easy creation of interactive tutorials has been accepted. In this talk, I'll demonstrate how Crunchy can be used to create interactive Python tutorials. I've been thinking about how to organize my talk for about two months now but have not written a line yet. One thing I can say for sure at this time: this is not going to be your typical PowerPoint-type presentation. My current plan is to use Firefox for the presentation: one tab will display a fake html-based Python tutorial, the second tab will make use of codetch so that I can edit the same tutorial "live", and the third tab will display the resulting interactive tutorial as processed by Crunchy.

Rur-ple: double the number of languages

While I haven't had time to do programming in the past few months, some Rur-ple users have been busy and submitted new material. The upcoming 1.0 release of Rur-ple will include 3 new languages [Turkish (including a translation of most lessons), German and Welsh] as well as previously included languages [English (with all lessons), French and Spanish].

Inspired by the user contributions, I spent a few hours today re-writing the localization code. To add a new language now only requires the following:

1. Adding one line in a Python file (translation.py), that specify the language and language code, as well as the name of the .po file.
   
2. Creating a .po file containing the string translations.
3. Creating an html file (rur.htm) used as a Welcome Page in that language.

The new version will also save the last language selected and will use it upon re-starting Rur-ple.

Securing Crunchy

Following my last post, some alert readers pointed out that Crunchy could be a security risk for its users. Crunchy acts as a web server, fetching html-based Python tutorials and displaying them in your browser with controls allowing to execute the Python code. This is meant as a good thing... but it might not be if the code is allowed to run automatically when the page is loaded. In fact, this might have occurred with previous (<0.7) Johannes and I changed the way that Crunchy works so as to remove any security worries - at least, we hope so. Anyone interested can obviously look at the code; for others, here's what we do:

• Each time Crunchy starts, it generates a random session number (10 digit long).
• The javascript code used to communicate between Crunchy and the browser is fetched from a static file and modified to include the unique session number as part of each command; a new javascript file, with a filename that incorporates the session number is generated.
  
• When Crunchy fetches an html page, it processes it to remove unwanted code. This means removing all (java-)scripts and only allowing html tags that are on a "whitelist". This whitelist excludes any of the usual "onload", "oninit", etc., automatic execution.
  
• Next, Crunchy interactive elements (Python interpreter, code editor, button for Python code execution, etc.) are inserted with the javascript calls, each call given a unique identifier for that session.
• Finally, the processed page is displayed in the browser, with the server waiting for user-generated interactions.
• This procedure is repeated for any page that is loaded during that session.
  
• At the end of a session, when Crunchy is terminated, the javascript file that was generated and used in that session is deleted.

The latest version (0.7) includes this security features and many new additions [a complete list of the changes from version 0.6 is appended at the end of this message]. Currently, Johannes is working on adapting How to think like a computer scientist to use with Crunchy, as well adding new interactive features. For my part, I have been working on internationalisation issues (adding a French interface) and other configuration choices. Due to end-of-summer holidays, work on Crunchy will likely slow down for a few weeks at least but we should be able to reach version 1.0 early in the Fall.

After that, I will be ready to start implementing rur-ple inside the Crunchy environment; if there is enough interest, I might implement a turtle graphics module as well.

===== Changes from 0.6 to 0.7 ================
0. Name change
To prevent confusion with an existing program named CrunchyFrog, "Crunchy Frog" has been renamed as "Crunchy", short for "Crunchy, the Interactive Python Tutorial Maker".

1. *Security fix*
The previous versions of Crunchy allowed tutorials containing arbitrary (and hidden) javascript code to be loaded within a browser window. The new version removes any existing javascript code prior to processing for display within a browser.

Feel free to try and break this - and please report any findings back to us.

2. New functionality.

• It is possible to run external programs from within the browser; sample demos include GUI programs with 1. Tkinter, 2. pyGtk, 3. wxPython, 4. Pygame
• Automatic syntax colouring of (static) Python code, including (as an option) line numbering.
• New plotting canvas with simple to use api to draw mathematical functions
• Drawing & plotting canvas can be set to arbitrary size.
• Multiple canvas can now appear on same page.
• New addition and simplification to the sound api.
• Simplification of error message (tracebacks) more suitable for beginners.

• New plotting canvas with simple to use api to draw mathematical functions
• Drawing & plotting canvas can be set to arbitrary size.
• Multiple canvas can now appear on same page.
• New addition and simplification to the sound api.
• Simplification of error message (tracebacks) more suitable for beginners.

3. New visual design:

• Integrated menu which can be styled through custom css
• Three sample css styles now included (selectable via the browser menu)

4. New content:

• First draft sound tutorial exploring concepts of frequency, beats, harmonics (Fourier series), etc.
• New addition to the basic "Crunchy user" tutorial
• Additions to all reference documentation (sound & graphics api, vlam options, etc.)

Exciting Crunchy News

While I knew all along it could be done, I've had a lot of fun during the last two days playing with the newest, and possibly most exciting feature of "The application formerly known as Crunchy Frog", or simply "Crunchy". It is now possible, from within a Firefox windows, to click a button and launch an external Python script. (I should mention that the bulk of this latest feature was implemented by Johannes Woolard - I just had to make a few minor changes to get it working on Windows.)

I'll provide more details later, but here's the short story. You write an html document in which you insert the Python script you want to execute inside a <pre> element with some minor markup (<pre title="external copycode">); actually, you can have as many scripts you want on any given page. Crunchy processes the page, displays the Python scripts in colour (!) and makes a copy of each available for further editing inside a <textarea>. You can then just click on a button and the script is launched.

This means that Crunchy can really transform *any* Python tutorial into an interactive experience. Crunchy can load html pages from the web (not only local ones) and perform its magic ;-)

So far, I've launched Tkinter windows, wxPython apps, Pygame programs, a terminal with a Python interpreter and, the latest, a gnuplot window that ran the gnuplot demo. You can actually have a number of independent external apps going at the same time, allowing for some interesting experiments (edit the code in the <textarea> and launch the new version).

Stay tuned for more news soon, and the announcement of the next release.

Crunchy news

It's now been a month since my last blog post and a lot has happened in the meantime. We (Johannes and I) have just released a new version of Crunchy Frog. We were planning to do a release (version 0.5) a bit earlier but we kept "fixing this", "adding that little bit", "changing this", etc., until I felt it was well beyond what had been planned for the next release. So, after discussing briefly about it (at Johannes's request), we set up a roadmap for Crunchy Frog as a whole (as oppposed to just for Johannes' project) with a date set for the 1.0 release that would coincide with the end of this Summer of Code project for Johannes.

The new public release (0.6) looks very different from the previous public one (0.4). Crunchy now has its own site. Previously, Johannes had set up an svn repository which has come extremely handy. This summer of code project is supposed to be a learning experience from the student (Johannes) under the direction of a more experienced mentor (that would be me). However, I can say that it has been a huge learning experience for me. So far, I had only worked on my own project, and only very recently had learned to use an svn repository on my own computer. Working as part of a team (supposedly as the team leader [I have the final say, if need be]; in reality, it's pretty much a team of equals, each of us having different strengths) has been an experience in itself.

While we have settled on a roadmap, I can already see some additional features, not mentioned so far, that I would like to implement before the end of the summer. For those interesed in Crunchy Frog: stay tuned, there could be some very nice new stuff added soon.

The 0.6 release got some attention outside of "regular channels" and I just found out that there exists another Python project named CrunchyFrog (no space between the two words). This, I think, is most unfortunate and I am in a bit of a quandry as to what to do about the name. Note that the developper behind CrunchyFrog, who brought its existence to my attention, not only has not complained about me choosing this name, but has actually set up a link to Crunchy Frog on his own website. [This is something we'll definitely have to reciprocate; Johannes is responsible for the website and is taking a well deserved break after the last minute rush to get everything organised for the 0.6 release.] Nonetheless, the possibility of changing the name of the project has to be considered ... even though Johannes has designed a nice graphical interface based on a Frog theme.

With all this attention devoted to Crunchy Frog, Rur-ple's development has been suspended. However, just a few days ago, Michel Weinachter sent me

• a "patch" so that the user-chosen language can be remembered from one session to the next;
• an exe version, produced by py2exe, so that Windows users don't need to install Python nor wxPython to use Rur-ple;
• some simple code to make use of a clipboard within rur-ple; I have not had time to see how to make this work though;
• just today, a link to a Firefox extension useful to users of Crunchy Frog. This extension enables the "normal" use of a tab key within an html <textarea>, which comes in handy when typing Python code.

Merci Michel!

So, all in all, a busy month with lots of long nights of coding after work. I have a great job, which does not and never will require me to do any programming [sometimes, much to my chagrin.] However, as a hobby, programming in Python has really been a fantastic one. It is my hope that the programs I create will be found useful by others.

Almost there: version 0.9.9 of RUR-PLE has been released

The title of this post pretty much says it all. I just need to write a few more lessons, read over once more all the existing lessons, do once more all the suggested exercises ... and, barring any surprises, I will be ready to release version 1.0 of RUR-PLE. Thus will end an adventure that started a little less than 2 years ago, as I decided to start a new hobby and learned about Python.

Chasing an unseen bug

A few days ago I was contacted by M.H., a professor in the U.S. who teaches Introduction to Computer Programming every year and was thinking of using RUR-PLE. [Great, I thought, more user feedback to be expected.] Unfortunately, M.H. had tried the latest version and found that the code highlighting feature [described in this post] did not work.

How could I possibly find a bug that I can not reproduce? I thought... Thus began an exchange of emails that led me to find a way to reproduce the bug and, eventually, to solve it. The final solution was somewhat typical of my experience with Python: try the obvious!

These last three words are probably the best words of advice I could give to anyone who writes computer programs using Python. If you are reading this blog as a potential source of useful tips [you fool!], you should probably stop now as nothing else I will write is likely to come even close to being as useful to you.

However, if you want to get a good laugh at my expense, you are invited to continue reading.

I first started by asking M.H. what everyone always asks me when I claim to find a bug or when I don't understand the behaviour of some module and post some question on various lists.

What OS and what version of wxPython are you using?

I expected that M.H. was using Mac OS or Linux, in which case I was getting ready to diplomatically tell him that he was likely out of luck as I'm [shame on me], a Windows user. However, M.H. told me that he was using Win XP (same here), Python 2.4.3 (I'm using 2.4.2) and wxPython 2.6 (same here).

Ok. I was more stumped then ever. This was bugging me... These days, I'm working on Crunchy Frog which will, eventually, include and supersede RUR-PLE. As it is, I have a lot more ideas than time at my disposal to work on Crunchy Frog, and this "distraction" was not welcome. However, I could not ignore it.

Since I couldn't reproduce the bug, I asked M.H. if he could do me a favour and insert a print statement in the method where the line number was set for the purpose of highlighting. As I wrote the email, I had a "clever" thought. M.H. is in the U.S. He's probably using the ansi version of wxPython whereas I'm using the unicode version. I bet you something's wrong with that version... Sure enough, my first hunch was right: M.H. was using the ansi version. And the print statement was outputting the same result on his computer as it was on mine. So, if one hunch was right... I asked M.H. to install the wxPython unicode version, which he kindly agreed to.

Same result... Of course, you are no doubt thinking. However, you are not trying to quash a bug you can't even reproduce. [That's my excuse, anyway.]

At that time I was visiting my partner who, unfortunately, lives 300 km (200 mi) from where I live. Fortunately, she is extremely patient and puts up with me when I am distracted by a programming problem. I decided to install wxPython and the latest version of RUR-PLE on her computer to investigate some more.

Ooops... wxPython is now at version 2.6.3.2. I am sure the version installed on my computer is 2.6.1.0. I read over the "changes" document to see if I can find anything that I can use. There does not appear to be anything relevant. I install the new version ... sure enough, I can "see" the bug (or, should I say, I can't see anything as no highlighting is taking place).

I read the "changes" document a second (and third) time, just to be sure. No luck.

Time to dig in my code. [... Where is this object initialised?... This could have been written so much better... What was I thinking then (about a year ago)... ] After staring at the code for a while, being convinced that the highlighting information is properly set (it was working before, after all) I am convinced it is a wxPython bug that was introduced. I file a bug report and expect to leave it at that.

However, my conscience is nagging me. I decide to look at the code again, staring at the method where the highlighting updates should take place. Here it is, with a few added notes.

def update_refresh(self, robot, name):
  if 'robot' in self.robot_dict:  # (1)
      arg = self.parent.status_bar.beeper_field, self.robot_dict['robot']._beeper_bag
      event_manager.SendCustomEvent(self.parent, arg)
  time.sleep(robot.delay)  # (2)
  wx.Yield()   # (3)
  self.world.DoDrawing()  #(4)
  self.WorldDisplay.drawImage()  #(5)
  if name:
      self.WorldDisplay.scrollWorld(name)  # (6)
  self.WorldDisplay.Refresh()  # (7)
  wx.Yield()

1. The information in the status bar (number of beepers carried by robot, etc.) is updated.
   
2. The animation is paused at each step.
3. Making sure other controls of the application are responsive so that the program can be paused or stopped altogether by pressing the appropriate button, etc.
4. Update the (in-memory) image based on the latest robot action.
5. Update the screen image.
6. Prevent the robot from going off the screen.
7. Refresh the screen [Refresh() is a wxPython method.]
   

That's it. Not much there. I refresh the screen so as to ensure that the robot world, right next to the code "window", gets updated on the screen when a new line of code is executed, and should be highlighted in the code window.

Can you see the bug?

I didn't refresh the code window. It worked before though.

How do I do this... the robot world is a ScrolledWindow whereas the code window is a StyledTextControl... Where do I find the relevant documentation...

That's when I thought of the three important words I mentioned before: try the obvious. I typed in

  self.ProgramEditor.Refresh()

and launched RUR-PLE. Problem solved. I guess it was just dumb luck that this refresh statement was not required before. All I have to do now is fix the bug and update the version on sourceforge ... before I go back and rewrite the parts of the code that I didn't find easy to read just a few days ago.

Praise for Python

Sometimes, I come accross something which I really wish I could have written. Usually, I just smile, try to commit it to memory, and move on. This time, I have to quote what Jim Roskind wrote on Guido's blog:

I was initially a bit put off by the Python indentation approach (I was a grammar guy… and got used to parsing braces and parens, and didn’t like the idea of white space having so much meaning), but I soon came to love it. Eventually I came to apply one of my favorite computer science sayings to Python as an endorsement to their indentation blocking approach: “The fundamental evil in computer science is the replication of code or data.” In almost all languages I had previously worked, the indentation of code had always been a critical PART of program nesting structure (at least for the reader). As I read and wrote more Python, its use of indentation as the ONLY way to specify blocks began to look better and better. All the silly bugs related to indentation errors (misleading the human reader) were gone in Python. The redundant use in other languages of braces AS WELL AS indentation (the former to help the parser, and the latter to help the human reader) was an effective duplication of the author’s intent. That duplication in other languages, a fundamental original sin, was missing in Python. It was cool! ;-)

Yes, indeed. Python is cool. :-)

RUR-PLE video

The kind folks from ShowMeDo had contacted me and suggested I make a demonstration video for RUR-PLE. I'm happy to announce that this has been done, and that the video now appears on the ShowMeDo website. The link to this demonstration video can be found on the right hand side side-bar for this blog. The sound quality is not all that good, but the video should give a good idea of what RUR-PLE is all about. (I will definitely need to get a better microphone for future videos, and possibly for remaking this one.)

rur-ple bug fix for Mac and Linux users

Brad Miller uncovered a bug (hard coded windows specific path separators) in version 0.9.8.2 of rur-ple. Version 0.9.8.3 has been uploaded with required changes. Apologies to Linux and Mac users.

Summer of Code 2006

For a second year in a row, Google is paying hundreds of students to spend their summer contributing to open source projects. This is known as Summer of Code 2006. The Python Software Foundation is a mentoring organisation that is the beneficiary of 25 Summer of Code projects. Continuing on my streak of luck with Python, I am mentoring Johannes Woolard, a promising student whose project was accepted in this Summer of Code competition. Johannes has a blog, and has already started working on his project. Within the span of a day or two, he has already removed the CherryPy dependency of Crunchy Frog, which was one of my longer-term objective - but something I didn't know how to do. Kudos to Johannes!

Rur-ple 0.9.8.2 released

I implemented in rur-ple the "auto-indent" feature that was added to Lightning Compiler. This should be more user-friendly for beginners. I also fixed a bug that was introduced when I improved the highlighting method - it was no longer possible to run programs where robots were introduced by an instruction [e.g. Reeborg = UsedRobot()] in an otherwise empty world.

Lightning 2.1

Thanks to Milan Melena, who left a code sample on this blog, Lightning 2.1 has been released, with added auto-indent and quick fold/unfold. Next, I'll have to consider added auto-indent to rur-ple.

Rur-ple: getting closer to 1.0

Rur-ple is getting ever closer to version 1.0. I have to finish about 10 new lessons to get to version 0.9.9 after which I will do a final cleanup of the code for the 1.0 release candidate. The current version (released today) is 0.9.8.1.

Since the last release, I made two changes that should be helpful for students. The first one has been to use a scintilla feature to indicate white spaces with tiny dots as indicated in the picture below.



This should help locate problems related to blank lines with a number of spaces that does not match the indentation level; this had apparently been a problem for some students.

The second change is more significant. When I started working on rur-ple, I wanted to be able to step through the code and highlight the line of code being executed. I managed to do this only partially through a kludge.

The first step was to take the user code and add some line number information using the Python module tokenize and some complicated processing. For example, the code shown above might be re-written as follows:

def follow_right_wall():
....linenumber = 20
....if right_is_clear():
........linenumber = 21
........turn_right()
........linenumber = 22
........move()
........linenumber = 23
....elif front_is_clear():
........linenumber = 24
........move()
........linenumber = 25
....else:
........linenumber = 26
........turn_left()
........linenumber = 27

I would then call exec to execute the processed code, leaving the unprocessed one displayed in the editor window. Each time a basic instruction (like move, turn_left, pick_beeper, put_beeper) was executed, the graphical display would be updated and the corresponding line of code in the editor was highlighted. When I came up with this solution, I had only been programming with Python for a few months and thought it was rather clever.

Unfortunately it was not possible, using this method, to highlight every line being executed: only those with one of the four basic robot instructions.


The new version makes use of the Python method sys.trace to follow the execution. It is much simpler than the old version (5 lines of code instead of 33) and works much better, as can be seen on the picture on the left. It has not yet been field tested but Andy Judkis's students should do just that in the coming week.

New version of RUR-PLE (0.9.8)

After receiving some suggestions from Andy Judkis, a high school teacher who uses Rur-ple in his classes, I made the following changes to rur-ple.

• I added an "output pane" in the robot world window. Users can now put "print" statements in their programs, and the result will appear in the output pane. This should be useful in "tracing" the program flow.
• I added two new instructions that can be used in robot programs: input_int("optional text") and input_string("optional text: e.g. Enter your name.") This is an undocumented feature for now.
• I fixed an obscure "bug" discovered by Andy. When the "World file" is visible, the display was not updated when giving some beepers to the robot. This did not affect in any way the program execution; furthermore, most of the time, the world file viewer was probably hidden. Still, it should now be fixed.
• Finally, I had removed the requirement to save a program before running it. However, I had made it such that a dialog would pop up if a user was trying to quit without saving a program. Apparently, it would sometimes cause the program to hang. I could not reproduce the bug ...

Optional typechecking: fun with "with"

A while ago, prompted by various entries [1, 2, 3, 4] on Guido's blog about Adding Optional Static Typing to Python, I mused about different ways of doing this [5, 6, 7], keeping the syntax as Pythonic as possible, but at the cost of introducing a new keyword ("where"). Today's entry is written in the same spirit (i.e. just for fun), but with a different syntax, and makes use of the new "with" keyword. By itself, this blog entry is probably too brief to make much sense.

Let me start by introducing some static typing information that could be extracted from an IDE, or used by pychecker or pylint.

01 def gcd(a, b):
02     '''Returns the Greatest Common Divisor,
03        implementing Euclid's algorithm.
04        with __typecheck__:
05            assert isinstance(a, int), 'First argument must be an integer.'
06            assert isinstance(b, int), 'Second argument must be an integer.'
07        #Some doctests for good measure
08        >>> print gcd(6, 3)
09        3
07        '''
08     while a:
09         a, b = b%a, a
10     return b

The above is totally valid Python. Just like doctests can be extracted by the doctest module, the "typecheck" assertions could be extracted and used by other programs. However, as they stand, they are "totally optional".

Now, if we wanted to use the typechecking information in some module where gcd() is actually used, we would have to instruct the interpreter to do so ... here's a way we might want to write this:

1    with __typecheck__:
2        gcd()
3        some_other_useful_function()
4    # the rest of the code follows...

Granted, this is not currently valid in Python ... but its intent should be understandable!

Crunchy Frog 0.3

Version 0.3 of "Crunchy Frog" has been released. It can be found at
https://sourceforge.net/project/showfiles.php?group_id=125834

Crunchy Frog transforms a "traditional" Python tutorial into an interactive session within your favourite web browser. Four modes of interaction are currently possible:
1. One-liner, similar to the typical instruction at the Python interpreter.
2. Embedded Python shell, within an html page.
3. Multi-line Python code, as entered in a traditional editor, and executed by Python.
4. Solutions to doctests, as described by Jeff Elkner in a post on edu-sig.

Even though it is an early release, Crunchy Frog could probably already be useful in a classroom situation. To use it, you will also need to have installed Elementtree and CherryPy.

Suggestion: read the 6 page long "tutorial" included, using your favourite browser. Then, start Crunchy Frog, and go through the tutorial again. The whole thing should be doable in approximately 15 minutes ... if you don't spend too much time playing with the interpreter. :-)

My first CherryPy app.

Using CherryPy, I've just created version 0.1 of "Crunchy Frog". It can be found at
https://sourceforge.net/project/showfiles.php?group_id=125834

Crunchy Frog is just a temporary name for this app. (Read the tutorial for more details.) What it does is to transform a "traditional" Python tutorial into an interactive session within your favourite web browser. Three modes of interaction are currently possible:
1. one-liner, similar to the typical instruction at the Python interpreter.
2. multi-line Python code, as entered in a traditional editor, and executed by Python.
3. Solutions to doctests, as described by Jeff Elkner in a post on edu-sig.

Crunchy Frog is more of a proof-of-concept than a serious application at this point. The code is rather messy, showing my total lack of experience with this type of program (web app). I will very likely rewrite it from scratch for the next release. To use it you will also need to have installed Elementtree (included with Python 2.5?) and CherryPy.

To try it: read the 5 (short) pages long "tutorial" included, using your favourite browser. Then, start Crunchy Frog, and go through the tutorial again. The whole thing should be doable in less than 10 minutes.

Rur-ple 0.9.7a: bug fix

Once again, rur-ple was broken on Linux (and Mac OS); however, this time the bug was reported (only the second ever reported bug through sourceforge since Stas Z guided me to make it work on Linux for the first time!). It is now fixed :-)

There must be some other bugs, somewhere... After all, I did not use any kind of "unit tests" for most of the code. Anyone that tries to use rur-ple and find problems should feel free to report them!

As soon as I can get about a week's worth of time (and inspiration!) to write the last lessons, I will be able to finally release version 1.0. After that, watch for a new version that will use a web browser (instead of wxPython) as its graphical environment. Now, what I need is a new name for that future version...

CherryPy is great!

Inspired by Ian Bicking's HTConsole, I wanted to see if I could get a simple "Python compiler", similar to Lightning Compiler but using a browser window instead of basing it on wxPython. Having no experience with any web programming, and looking at Ian's code, I thought it would take me forever to get this going. Also, I didn't really want to have to learn about all the packages used by Ian to produce HTConsole.

After a few simple attempts with Python's webbrowser module, a fruitless query on comp.lang.python, and some wandering on the web, I came accross CherryPy. To be honest, I had heard of CherryPy before, but had never looked at it as I thought it was something I would never need.

Lo and behold, simply after reading the basic tutorials included with CherryPy, I was able to write a very small program which does pretty much the same thing that earlier versions of Lightning Compiler could do. The complete code is included below:

import cherrypy
import os
from tempfile import gettempdir
TMP_DIR = gettempdir()

class PythonRunner(object):
title = 'Play with Python'

def header(self):
    return '''
            <html>
            <head>
                <title>%s</title>
            </head>
            <body>
            <h2>%s</h2>
        ''' % (self.title, self.title)

def footer(self):
    return '''
            </body>
            </html>
        '''  

def index(self, code=None):
    cherrypy.session['code'] = code
    output = ''
    if code is None:
        cherrypy.session['output'] = ''
    else:
        tmp_filename = os.path.join(TMP_DIR, 'my_file.dat')
        f = open(tmp_filename, 'w')
        f.write(code)
        f.close()
        f_in, f_out = os.popen4("python %s"%tmp_filename)
        output = "The result of"
        output += "<pre><font color='blue'>%s</font></pre>is: "%code
        output += "<pre><font color='green'>"
        for line in f_out.readlines():
            output += line
        output += "</font></pre>"
        cherrypy.session['output'] = output        
    return self.header()+'''
            Type in your Python code.
            <form action="index" method="GET">
            <textarea name="code" rows=5 cols=80></textarea><br/>
            <input type="submit" value="Run Python"/>
            </form>
            <br/>
            %s
        ''' % output + self.footer()
index.exposed = True

cherrypy.root = PythonRunner()
cherrypy.config.update({'session_filter.on': True})

if __name__ == '__main__':
cherrypy.config.update(file = 'tutorial.conf')
cherrypy.server.start()

And here's what it looks like (html code simply pasted below; it doesn't work here!)

Play with Python

Type in your Python code.

The result of

def hello():
 print 'Hello from CherryPy!'
hello()
a = 3
print a*3

is:

Hello from CherryPy!
9

Thank you CherryPy developpers!

Lightning 2.0

I've upgraded Lightning Compiler significantly. It is now possible to have more than one editing tab. It is now also possible to run doctest suites, with an external file. As usual, it can be found on sourceforge.

Lightning Compiler (LC) is a wxPython based app. LC's purpose is to provide a friendlier environment to tests Python code snippets than the Python interpreter. It does include an interpreter (pyShell) but it is most likely to be used for its editor. You can execute the code that appears in the editing window and the output is redirected to an output window. raw_input() and input() are handled via dialogs. The basic layout (output window to the side or below the editor window) is customisable.

LC comes in a zip file with a sample app, showing how it can be embedded in other applications, as well as a sample script with doctests and a text file containing additional doctest based tests.

Since LC uses wxPython, it can not be run with a basic Python installation. If there is some interest, I might try and adapt it so that it could use Tkinter instead (as an option. However, I have no experience with Tkinter. Any help would, of course, be appreciated :-)

Lightning Compiler with doctest support

As readers of this blog will know, I wrote "Lightning Compiler" (LC) as a small application to test code snippets. Inspired by an idea from Jeffrey Elkner, I added two new options for LC. It is not possible to press a button an execute a code snippet as though it was imported as a module by doctest, either in "normal" mode, or in verbose mode. For example, suppose I have the following code:

def hello():
 """>>> hello()
Hello!
 """
 print "Hello!"

I can simply press LC's "docTest" button or "verbose" button to run Python with doctest.

What's happening behind the scene is that the following two lines

import doctest
doctest.testmod()

are appended to the code in the window, all of which is saved to a file which is then executed by Python, with or without the "-v" option. The result is saved to a second file which is then displayed in LC's output window.

Granted, if your script already includes some doctest-based testing within a "standard"

if __name__ == "__main__:"

block, this addition to LC may not seem that useful; however, if you already use the "if..." block for something other than tests with doctest and have some docstrings-based tests in your code, it might be worth your while trying LC's new feature.

Thoughts on the Shuttleworth Summit

Guido and Kirby Urner are two of the 20 or so participants currently taking part in the Shuttleworth Summit. To put it simply, the objective of that summit is to find a curriculum that will fit mathematics, where a child will have mathematical tools to solve problems, and to acquire their analytical skills, and while making efficient use of technological tools. During the discussion, it has been suggested that a possible way might be to start kids with Logo, then maybe move on to Squeak, then Python. I would argue that a programming environment like rur-ple might be more suitable and sufficient to replace both Logo and Squeak, while being used to introduce Python. Many of my thoughts on this have been influenced by a paper on mini-languages. (I encourage everyone to read this paper.) I should also acknowledge that the basic idea behind rur-ple is not my own, but rather Richard Pattis with his "Karel the Robot", which is mentioned in that paper.

I am going to present an admittedly one-sided view in order to invite some discussion. The reality is that Logo and Squeak have been used very successfully with learner of all ages - something I will conveniently ignore in my argumentation! Furthermore, because I want to use this post to try and provide some feedback to Kirby that he can perhaps use while he is at the summit, the depth of some of the arguments presented will definitely be less than satisfactory.

Let me jump straight into the discussion by first arguing Logo might be too complicated as a first step, for at least two reasons. In decreasing order of importance, they are: 1. Advanced geometry; 2. Too many (complicated) commands. Furthermore, I would argue that Logo is limited in its ability to introduce problems requiring analytical skills.

First, Logo (and similar turtle graphics environment) uses general two-dimensional motion. The mathematical concepts that are needed/introduced include length and angles (measured in degrees). While integer values are used, units of length are too small to be easily measurable on the screen. By contrast, rur-ple uses restricted two-dimensional motion, as combinations of either vertical or horizontal motions. The basic stepsize is easily measurable on the screen. While rur-ple is designed to introduced coordinates (which are, arguably, a fairly advanced mathematical concept), programs can be written without making any reference to this concept. Furthermore, even without writing an actual program, one can guide the robot, making it move and turn by using the keyboard; this can be useful in visually determining the order in which instructions must be written.

Note that, in a future version of rur-ple (after I complete version 1.0) will include a second environment which will be essentially a "turtle graphics" environment, like that of Logo.

Second, Logo generally include the following commands (written in non-abbreviated form): forward #, backward #, right #, left #, pen_up, pen_down, restart (cs), as well as a repeat instruction. Note that the symbol "#" refers to a numerical variable. By contrast, rur-ple's basic commands are: move(), turn_left(), pick_beeper(), put_beeper(), and turn_off(). Rur-ple also includes a repeat() instruction. One can easily make a correspondance between Logo and rur-ple's commands and see that Logo includes two extra commands (backward and right) that can be emulated by appropriate combinations of other commands. Granted, the previous argument is a bit weak... However, note that 4 of Logo's basic commands require the use of an additional numerical arguments. This may seem trivial ... but for an absolute beginner, such a combination, like "forward 5" is an advanced concept as compared with a simple instruction like move(). While it is currently not designed this way, rur-ple could (and probably should) be easily modified so that the basic instruction move() could take an optional argument, like move(5), which would more closely match Logo's syntax. This is most likely how the future "turtle" environment for rur-ple will be designed.

Another conceptual hurdle present with Logo is the concept of "pen_up" and "pen_down". Again, for the readers of this blog, it probably seems very simple. However, I understand that this is something that has to be explained to learners (especially the younger ones), as it does not have an immediate analogy in their experience. I would argue that a more natural set of commands would be something like "start_drawing()" and "stop_drawing()". This could then later be expanded to something like "start_drawing(color=red)" and "start_drawing(color=red, thickness=2)". Another future expansion of rur-ple would be in a third environment, this time a 3-dimensional one (perhaps using Vpython).

I have mentioned that Logo is perhaps too limited in its ability to introduce problems requiring analytical skills. This is because Logo's traditional environment is an empty one. By contrast, rur-ple introduce a world in which obstacles (walls) can be present. One can then ask the user to solve various programs, from a simple "climbing a step" to finding a way out of a maze. This is done by introducing, one keyword at a time, Python's syntax. In fact, because the full power of Python is available, one can even easily use rur-ple to program a visual solution to the Tower of Hanoi problem!

This brings me to my final, and perhaps most important point. If one is to design a curriculum making use of technological tools to introduce mathematical and analytical skills, the focus should be on coming up with a coherent and progressive set of problems to be given to the students. The main idea should be to use the technological tools to solve the problems and learn about them, rather than using the problems to learn about the technological tools. I have to admit that rur-ple's lessons so far have been written in the second way: problems are introduced as a motivation to learn about computer programming (i.e. a technological tool). Perhaps the result of the Shuttleworth Summit will influence future lessons that will be included with rur-ple!

Lightning Compiler and RUR-PLE update

Both Lightning Compiler and RUR-PLE have been updated. Lightning Compiler (L.C.) has been refactored to make it easier to be incorporated inside another program (like RUR-PLE). I have added a sample application that shows how to import L.C., using a different layout for the buttons.

RUR-PLE has changed internally quite a bit. I now use ".po" files for string translations instead of the idiosyncratic approach I was using. Previously I added a python file for each language, containing a series of variable assignements like:
USER_STOP = "You stopped me!"
or
USER_STOP = "Vous m'avez arrêté!"
and I would invoke the strings through something like translation.USER_STOP.

Now, I use the same method as the gettext approach, i.e. something like
_("You stopped me!")
with the translations stored in .po files. More than 100 strings had to be changed in some 14 different files. Other "minor" changes had to be made as well... all very tedious, but it seems to be working ok. I wrote my own ".po" interpreter instead of compiling the files to ".mo" format and using gettext, as this seems to give me a better control over the encoding. A similar project (Guido van Robot) is using gettext and baffling encoding problems seem to be surfacing from time to time.

Three other significant changes were made to RUR-PLE:
1. a program can be run without being saved first. This was inspired from reading a post by Ted Leung
2. The dialog that appears after a successful run now disappears on its own after two seconds, instead of requiring the user to click a button. This was suggested in a comment left on this blog.
3. The embedded Python editor has been replaced by Lightning Compiler. I had to draw a whole bunch of images to use for the buttons; artwork is not exactly my forte, but it will have to do for now. A consequence of this new embedding has been a more consistent choice of color used in the embedded Python interpreter as well; the same basic coloring is used in the Python editor, the "robot editor" and the interpreter.

Unfortunately, I had to write new strings... which are neither translated in Spanish (help!) nor in French (my own laziness).

I am seriously considering embedding a turtle graphics page within the app; this would be using the same format as the robot world page: an editor on the left, a canvas on the right, and the program is executed by clicking on a button. However, this is a major change and will probably have to wait after version 1.0 has been released (RUR-PLE is at 0.9.7 currently!). I will soon have to learn about using setup.py, pyexe and inno installer, as version 1.0 probably should be a one click install affair. I might have to learn how to install it in a multi-user environment, with some common directory for the basic app and separate directories for each user-written programs... Suggestions as to the best way to do that are more than welcome!

Python wish: a new meaning for "import ... as ..."

For Python modules that are meant to be imported, I usually try to put the testing code inside the module using the standard

if __name__ == "__main__":

block of code.

However, if the module is also meant to possibly be used by itself, then this approach doesn't work and the testing code has to be put in a separate module. I wish it would be possible to write something like

if __name__ == ''SomeNameChosenForTestingPurpose":

inside this_module.py and that importing the module using

import this_module as SomeNameChosenForTestingPurpose

would result in the variable __name__ inside this_module.py being assigned to SomeNameChosenForTestingPurpose. This would allow the inclusion of the testing code to be always kept inside a given Python module. To build a test suite, one would only need to have a module that does a series of "import ... as ..." statements.

As it is, __name__ is either equal to "__main__" or the original name of the Python file (this_module in the example above).

===In short, I would like to be able to design Python modules in this way:

some clever Python code

if __name__ == "__main__":
    some clever Python code to be 
    executed when this module
    is called as the main program.

if __name__ == "SomeNameChosenForTestingPurpose":
   Some clever Python code
   to be executed when
   this module is imported as
   SomeNameChosenForTestingPurpose

Was rur-ple broken for Linux?

A while ago, I made some changes with the help of a MacOS user so that rur-ple could work properly with that platform. Since then, many people downloaded it; I assumed that everything was working properly as there was no bug report - until tonight. Under Windows, if you start rur-ple by double-clicking RUR_start.py (which is what I always do), everything is ok. However, if you start it [version 0.9.5] with "python RUR_start.py", nothing happens! I assume that this is the way it is invoked by Linux users too... I just made a small change which should make it work. The new version on sourceforge is 0.9.5a. If there are any users out there who could report if it works properly (and under what operating system), I would be most grateful!

Lightning 1.7 released

As requested by a user, I've added the possibility to pass arguments to a running script. The arguments are passed as a string (named _Args). The new version is available from the usual place.

One thing I have noticed is that scripts that contain encoding information give a run-time error. It is thus necessary to remove the encoding information (a line like # -*- encoding: latin-1 -*-) prior to running the script. If anyone knows of a different workaround, I'd appreciate hearing about it.

Lightning 1.6 released

Following some suggestions left by readers on the previous post of this blog, Lightning 1.6 has been released. The main visible change is the possibility to change the layout and have the output window "switched" from the bottom of the editor window to the right of the editor window (and vice versa).

The code has also been refactored so that it should be possible to customize various display options (default window sizes and fonts primarily) without having to understand how the rest of the program is structured.

Planned for the next release is the ability to simulate running a program with an argument list.

Lightning compiler: drag and drop option

A new version (1.5) of Lightning Compiler has been released. It is now possible to "drag" a file (icon) and "drop" it in the editor window. The text of the file will be automatically imported to the editor window. This option has been added following a suggestion. Since I believe that it fitted well with the philosophy of L.C. as a quick-and-painless testing tool for Python scripts, I decided to implement it (which was surprisingly easy, thanks to wxPython!)

Feel free to suggest other useful options. :-)

A question of design (Lightning 1.4)

Since the release of my little app, Lightning Compiler :-), I have been confronted with design issues that, I imagine, many of those reading this blog face often in the course of their daily work. However, since I only program as a hobby, the issue of ui design is essentially all new to me. Going through the experience for a second time (the first was when I designed rur-ple) has given me a better appreciation of Joel Spolsky writings on the subject.

Lightning Compiler was originally meant as a teaching tool embedded in rur-ple. As such, it was very simple by design. Since I "extracted" it from rur-ple to become a stand-alone tool, I have been faced with the temptation of adding various features (creeping featuritis?), following users' comments (3!), especially when they had themselves made some modifications that they found useful.

I don't want Lightning Compiler to become a bloated app. ;-) Actually, as anybody that has looked at it would know, there is very little danger of this happening anytime soon - at least, by the usual understanding of what a bloated app is. Still, I want to keep it simple and true to its orginal purpose. I would be very interested in hearing about other programmers' comments on my thoughts on the issue of design of an app like Lightning Compiler (L.C. for short), especially given my relative lack of experience on the subject. To provide a starting point to the discussion, here are a few thoughts on the subject.

• L.C. is meant as a "quick and dirty" little app, useful to test some programs, usually short ones but that would be too long to type (and re-type) at the interpreter prompt. The idea is: type a program, press a button to execute, look at the output; make some changes and repeat the process.
• L.C. is meant to add a "nice" user interface for input() and raw_input() commands when needed. This is its one "unique" feature as far as I know.
• L.C. can also be use to run (and modify, and run again...) longer programs obtained from elsewhere - like, for instance, the Python Cookbook. The idea is to be able to cut-and-paste a code sample and run it with as little fuss as possible.
• L.C. should be as simple as possible to be useful to do this - but no simpler.

With these objectives in mind, here are some of the design features with the motivation for each of them:

• L.C. is a gui app that is meant to be lauched either from a terminal window or (under Windows XP, which I use - sorry to Linux and Mac users;-) by double-clicking on it. Still, I keep a terminal window present so that error messages from running L.C. itself can be read and captured. (This was especially useful in the original writing of L.C.)
• L.C has two basic windows: an editor window and an output window; print and error statements are redirected to the output window when running a program (and redirected back to the default terminal window afterwards, so that error messages from running L.C. are captured separately).
• L.C. has no menus, only buttons. Each option/operation is thus meant to be always visible at all time. Since nothing is hidden, the number of options has to be small ;-)
  
• L.C.'s buttons are simple labeled buttons (no fancy image); the idea is to keep it in a single file, as small as possible.
• Button labels are only in English. Well, this is of course easily changed by an individual programmer; this is a programmer's tool after all.
• Each action that can be performed by pressing a button can also be performed by a key combination. This is to allow "power users" to use it without their hands leaving the keyboard. From what I have read, this is considered nearly essential by *nix power users ;-)
• Possibility to hide the output window, giving more space to the editing window (to see more code at once); when hiding the output window, the amount of screen-space it occupies (after possible adjustment by the user) is remembered.
  
• Focus in the editor window at the start; ready to type and run :-)
• Default size of output window just large enough that all "help text" can be displayed at once in it... but no longer.
• Access to the interpreter, through a tabbed interface. This should be especially useful for finding information about modules with dir() or help()
  
• (New) If some text is selected, only that text is executed - but a warning is added in the output window ... especially in case the selected text is not visible in the Editor window because of scrolling...
• (New) Go to line number feature; should be useful when an error message is seen in the output window.
• The text from the output window is NOT cleared each time a new program execution (run) occurs; I know that one user changed that default so that his output window is cleared each time. My reasoning is that a user should be able to run the program, change a parameter, run it again, and be able to compare the results of each run. It is easy enough to clear the output after all (ctrl-l or pressing a button).
• No "find" feature. I've debated about this one... I looked at the wxPython demo and realised that, to do this properly requires more than a few lines of code... Furthermore, if one runs a program and gets an error message, only the line number (with the new "go to" feature) is really needed. I'm still debating...
  
• NO find-and-replace feature. This is something that is useful in a full-fledge editor or IDE, but seems to be an overkill for an app of this kind.
• Open and save file; this should be self-explanatory. No "save as"; can be easily done within save - actually "save" is really a "save as". ;-)
• Help button; just as a reminder that it is available.
• L.C. has no provisions for running programs that expect some arguments. I believe that if this can not be simulated with an added "if __name__ == '__main__" block, then you should use a different tool to work with.
  

That's it. What are your thoughts? Is there anything that I should have done differently?

Lightning 1.3: yet, one more!

I was reading a post on comp.lang.python and thought:

Wouldn't it be nice to see to try to import this module and use dir() and help() to find out ...

Then I realised that it would be silly to use Lightning Compiler :-) to do so; this was clearly a task better left for the interpreter. Then it dawned on me...

Version 1.3 is out. I changed the layout to use a wxNotebook, with the first page being the same Python Editor as before, and the second page is an embedded Python Interpreter, for those rare occasions when you just need it. All this, under 20kb (of course, using wxPython to do the heavy work), and it still loads in less than a second on my computer.

Of course, for the really heavy work, I still use SPE...

P.S. Remember that the Editor handles input() and raw_input() much better than the Interpreter does! ;-)

Lightning 1.2: yet, another new version!

Inspired by a comment left on my last post, I made yet another change to Lightning Compiler :-) The output window is now at the bottom, so that longer lines can be easily seen both in the editor window and the output window. The reason I didn't do it like this in the first place was that I found that too little text showed up in the editor window by default. However... the new version has an option to hide the output window (using a button, or directly from the keyboard).


Feel free to make more suggestions! As long as it doesn't bloat the program, and that I see some use for them... I'll make the changes to this toy app.


Now, for something somewhat unrelated... I had posted a simplified version on the online Python Cookbook. Now, because of new additions, it no longer longer appears on the front page, and will probably never be commented on again. [After all, who would think of looking for such a little app in the Python Cookbook.] But, just for fun, if you find Lightning Compiler useful, why don't you go to the online Python Cookbook and give it a rating. It would be kind of fun if it turned out to be the most often rated recipe ;-)

lightning 1.1: new and improved

Non North-American readers: You may want to skip the "Infomercial" as it probably is something unique to our continent...
====Infomercial====
Are you tired of retyping some complicated indented code at the interpreter prompt?

Do you get annoyed with mixed tabs and spaces?

Do you find it troublesome having to start a full-fledge IDE just to test a few lines of code?

With Lightning Compiler, you don't have to!

Lightning Compiler allows you to open files and save them, or simply type in your Python code from scratch just like a more expensive editor. However, unlike these complicated programs, Lightning Compiler also allows you to test your code instantly, at the click of a button.

The new and improved Lightning Compiler even allows you to do all this without even having to use a mouse: you can control it entirely from your keyboard, just like the Unix gurus!

But wait, there's more!

If you download Lightning Compiler right now, we'll throw in a source colorizer in the editing window absolutely free. With the source colorizer, you will never make a typo in a Python keyword as you edit your code. In addition, we'll include a tab-to-4 space automatic conversion.

And that's not all... Lightning Compiler runs on all major platforms.

So, what are you waiting for? You can download Lightning Compiler right now!

Mirrors are standing by!

Lightning compiler is provided as is, with no guarantee. Possible side-effects include: carpal tunnel syndrome, cross eyes, sore neck, and general lack of social life. Python (and its batteries) and wxPython not included.
======End of Infomercial=====

I always wanted to do a fake infomercial... Now that it's done...

In the past week, I was looking at the stats on download for rur-ple, following the latest release of the lessons and of rur-ple itself, and noticed a fairly large increase. I felt good about that, given all the time I spent on it. Then, I noticed that I could look at individual stats for all the "packages". Much to my surprise, "Lightning Compiler" was responsible for a significant part of the increase in downloads. Not bad for just a little app that was extracted from rur-ple! I even got just about as much feedback (two comments in a week!) on it than I got for rur-ple in about a year. When I first released it, I gave it a version number 1.0, even though it was not very polished. I thought I was done with it as it was answering my needs as a small one-purpose tool. However, as a result of the comments I got, I made some changes to Lightning Compiler, and produced a version 1.1!

For those that don't know about Lightning Compiler, it is a simple windowed app: one window is a Python editor, the other an output window. Your can run your code, and watch the result in the output window, with input() and raw_input() handled through dialogs (wxPython based).

It is not meant to be a "serious" app, but I find I use it more and more, and almost never use the Python interpreter anymore!

Fixing Reeborg: introducing classes

For those familiar with rur-ple lessons, I thought I would share the first draft of my introduction to classes. Some points to remember from preceding lessons:

• I used the analogy of synonyms to talk about variables
• Students have already seen how to define new object [like Reeborg = UsedRobot()]

I definitely welcome comments!

Fixing up Reeborg

As we have seen, we can create new robots by using the notation

Reeborg = UsedRobot()
Erdna = UsedRobot(2, 2)

However, these robots are just like the original nameless one: they
can only turn left. To teach them how to turn right, we could define
a function similar to what we did before:

def Reeborg_turn_right():
 for i in range(3):
     Reeborg.turn_left()

However, there are at least two problems with this approach:

• We need to define a similar function for every single robot we create (Reeborg, Erdna, ...).
  

• Reeborg and turn are separated by an underscore character "_" for the function we defined [to turn right] and by a dot "." for the built-in method [to turn left]. This would not look right...
  

A better approach is to define a new class that would inherit from the class UsedRobot. This is
what we do in the next section.

Designing a new class

I will show you first how we can fix our robot so that it knows how to turn right, and explain what I did afterwords.

class RepairedRobot(UsedRobot):
 def turn_right(synonym_used_to_refer_to_this_object):
     for i in range(3):
         synonym_used_to_refer_to_this_object.turn_left()

Here's how we can then use this new class of objects:

newReeborg = RepairedRobot()
newErdna = RepairedRobot(2, 2)

newReeborg.turn_left()    # as before
newReeborg.turn_right()   # new method!

newErdna.turn_right()     # this one works too!

And now, it is time to explain. The Python keyword class indicates that we are going to define a new type of "function", one that creates objects. What follows class is: RepairedRobot(UsedRobot).

RepairedRobot is the name of our new class; by writing UsedRobot between the parentheses, we ensure that the new class RepairedRobot inherits all the methods and attributes that UsedRobot had. Thus, when we write:

newReeborg = RepairedRobot()

we create a new robot "named" newReeborg which can do (at least all) the same things that the old Reeborg = UsedRobot() could do.

Next, inside the new class, as indicated by the indented block, we define a new method, turn_right(). By defining it inside the class, we take the first step to insure that all the robots that are created by calling RepairedRobot() will be able to turn right!

The second step that is required is to tell Python that the method will "belong" to the particular object that has been created. To do so, we use the variable synonym_used_to_refer_to_this_object which will refer to newReeborg, newErdna, etc., depending on what object is created. When we write

newReeborg = RepairedRobot()

Python creates a new instance of the class RepairedRobot and defines all the methods, replacing the first argument of the method (synonym_used_to_refer_to_this_object) by the name of the
instance (newReeborg).

Now, synonym_used_to_refer_to_this_object is rather a long name to type. By convention, another variable name is used: self. Thus, to follow the normal convention, I should have
written:

class RepairedRobot(UsedRobot):
 def turn_right(self):
     for i in range(3):
         self.turn_left()

Showcasing Python: rur-ple on the web?

There has been much discussion on Python related blogs expressing fear about how "Ruby on Rail" might be a "killer app", promoting strong adoption of Ruby over Python, etc. Much also has been said about how the lack of a "single web framework" was hurting Python, etc.

I was intrigued with the idea of a "Try Python" web site that I read about recently. Inspired by an idea originally mentioned by Steve Howell to create Webster van Robot, a web version of Guido van Robot (which itself was the inspiration for rur-ple) I have been wondering about the possibility of creating a version of rur-ple (only Reeborg's world part) that would run in a standard browser, just like one can use "Try Python".

There are two versions of "Try Python": Mike Meyer's, and Devan Lai's. While Devan (a very promising 14 year old programmer, imho) in a post on comp.lang.python wrote that Meyer's is the "cooler" implementation of the two, I personnally think that Devan's is the cooler of the two, and the one with the best potential for showcasing rur-ple as his version can already accept function definitions (and probably more; I just had a very quick look at both).

Now, I know very little about web stuff. One thing I know is that, for "games" type object, it is much better required to have all the code on the client side (through a java applet, a flash file, or some very fancy javascript) rather than on the server side. I also know that there is (for now, anyway) no Python support in standard browsers. How's that for very little? :-)

Now, I think that, if having a version of rur-ple on the web were to be done, it could generate a lot more attention on Python, and on the web framework that would have been used to develop it if using one of those fancy web frameworks is required.

Nonetheless, if one was to really showcase Python using rur-ple on the web, I think the following requirements would have to be satisfied:

• It should not require the user to install a plugin in his/her browser, just like it is done with the "Try Python" sites;
• it should not require a special browser, like Grail, either;
• it should not require some fancy javascript, but only html and css - remember, it is Python we want to showcase; along the same lines, it should not be implemented via a Python applet. Using Jython would be almost like cheating, imho.
  

Ok, the no-javascript part is perhaps too strong; after all, javascript is probably a "web standard" on the same footing as html and css. Still, it should be kept to a minimum...

Can this be done using one of these famous web frameworks that are generating so many discussions, including the one spurred by Python's bdfl? I personnally have no idea... One thing I know for sure: if it is, I will have to do some major refactoring of my code as the gui stuff is too much intertwined with the logic part; I had no concept of the model-view-controller approach when I started creating rur-ple, and I had no clear reason to try to conform to it (if it ain't broke...) later on. But, given a strong enough incentive, I could always do it!

Rur-ple 0.95 is out

RUR-PLE 0.95 has been released. The "end" is somewhat in sight. A copy of the announcement that I have posted on a few lists is appended at the end of this post.

This new version has required a lot of work, and relatively little to show for, for the casual observer. Other than writing more lessons, there are still a few things that I must implement before release 1.0. There has been a comment made on this blog about eliminating the "Success" dialog. The person who made the comment had a very good point. However, I have read a fair bit about "positive visual reinforcement" as an encouragement to programmers; even experience programmers seem to get motivated by it (think "green lights/red lights" for Java unit testers ... if you're familiar with it). So, I have been thinking about some alternative that don't require the user to actually press a button to resume.

This newest release has what I consider to be a really nifty feature; I call it the Lightning Compiler. This is a cross between a Python editor and a Python interpreter. It is a GUI based app with two main windows. Just enter a script, either by typing it in or importing from a file, in the Editor window, press "run", and you get the result in the output window. It handles input() and raw_input() through dialogs. I like it so much, that I submitted a simplified version to the online Python cookbook. It is available as a separate download (lightning.py) on sourceforge. I now use it as my lightweight basic Python testing environment. I still use SPE for serious coding though. If you haven't tried it yet, I strongly encourage you to do so.

[The lightning compiler is embedded in rur-ple in the fourth tab, and the interface is a bit different from the stand-alone version. It should be more user-friendly looking for a younger audience.]
=============================
RUR-PLE 0.95 has been released.

A link to the download page can be found at http://rur-ple.sourceforge.net

(The site is slightly out of date, and there is no plan to update it in the future as it provides an excellent idea of what RUR-PLE is about.)

This new version contains a few bug fixes and it should now work properly on MacOS. wxPython 2.6+ is strongly recommmended. There has been a few minor changes in the robot instructions, and the lessons has undergone some major changes.

RUR-PLE stands for Roberge's Used Robot: a Python Learning Environment.

This learning environment contains four main elements:

1. A simple html browser to look at the documentation and, potentially, the lessons. However, the new lessons use cascading style sheets which cannot be interpreted correctly by the browser. Usage of an external browser (Firefox :-) is strongly recommended.
2. A "robot world" with a robot that can accomplish tasks through Python programs.
3. A built-in interpreter which can be used to play with Python
4. A built-in file editor which can be used for futher Python explorations.

The interface is available in English, French and Spanish. Translations are welcome!

Version 0.95 contains 36 complete lessons (English version only). The lessons are also available as a separate download.

Version 1.0, which will aim to be a "complete" Python tutorial for people that have never programmed before, should have approximately 50 lessons.

A few "bonus" lessons have been included. In particular, it is suggested that you have a look at "A Robotic Fairy Tale".

=====
In 1981, Richard Pattis introduced "Karel the Robot" as a tool to teach computer programming.
Reeborg is a robot built on the 1981 Pattis' model... and it is starting to show its age.
It has an oil leak, which allows us to follow its trail. Its compass is broken; it only knows if it is
facing north or not, unlike Karel who could determine its orientation with respect to all four cardinal points.
Pattis' Karel the Robot was named after the author Karel Capek, who popularized the word robot in his play Rossum's Universal Robots (RUR). While RUR-PLE shares the basic RUR acronym,
in this case it stands for Roberge's Used Robot. However, through the magic of Guido van Rossum's Python, you can learn how to fix it and design a better one, worthy of the name Rossum's Universal Robot.

First separate release of rur-ple lessons

Finally! After much writing, rewriting, fixing typos, changing format to use style files, fixing more typos, I have a separate package of lessons for rur-ple completed. They can be found here. All in all, there is about 50% more material included than in the last rur-ple release. Now that they are separate from the application, it should be easier to have more frequent releases. It should also be easier for people to have an idea of what rur-ple is about without having to download and install the whole thing (including wxPython).

Next, I will have to do an application release, with various bug fixes...

Foxit pdf reader: fast!

This post is not about Python, contrary to this blog's purpose - but I just had to write about Foxit pdf reader . It is fast. Incredibly fast compared with Adobe's Reader. When it is set as the system's default browser, it can be used with Firefox (just do Tools -> Options -> Downloads -> Plugins -> disable viewing PDF files with plugin). The only drawback I can see is that it is a Windows only product. You can even type in your own text on a page prior to printing.

Rur-ple: time to drop the browser?

After spending some time writing my python tutorial included with rur-ple in html+css, I have started getting even more annoyed with the simple html browser included with wxPython. I am thinking of dropping it altogether (or perhaps only use it to display some introductory message) and require the use of a standard browser to read the lessons in a separate window. While I have written a simple program that does the html+css -> simple html conversion, it is rather tedious to have to do this, lesson by lesson, every time I update a lesson. Of course, I could change it to process files in batch I suppose, but I'm not sure it's worth the effort.

This would have the added benefits that 1) I could do separate releases for the lessons and the main app, and 2) I could start adding "fancy css tricks" to make the lessons even more visually interesting.

In addition to dropping the browser, I have had to modify the "python editor" window so that programs are not run from it using "exec", as I found out that one cannot make use of "raw_input()" in code that's run by exec or other family members. I have had to embed a second python shell and programs are now run via an import/reload done at the push of a button. I looked briefly at how Idle runs programs, but it was rather convoluted and didn't seem worth the effort to implement. Perhaps someone reading this will have a better idea... [I have not looked yet at the possibility of using popen(), which I have never used, but is apparently used by Makebot; Makebot seems to be doing exactly what I would like to do.].

I'm almost ready for a new release (0.9.5?) of rur-ple, which should now work under MacOS (as well as Windows and Linux). The new release should include about 40 lessons; 10 more lessons or so and it will be finally release 1.0; next will be an introduction to designing games with Pygames!

Reading about browsers, I found out that 20% of users still use screen sizes of 800x600 only. Rur-ple's interface has grown so that it currently needs at least 900x700 for sub-windows to be displayed in a large enough size to be fully useful. One solution might be to reduce the button sizes; however I am afraid that they would become too small at much larger screen sizes. Of course, a way out would be to have multiple image sizes for the buttons, depending on the screen size ... but that somehow seems excessive. I wonder what Joel would think of this.

Rant!

Google "Karel Robot", and have a look at the results: web pages about how a Java or C++ version of "Karel the Robot" can be used to teach (parts of) a first year university level in computer science. You'll find explanations on how important programming concepts can be taught using modern paradigms, object-oriented and polymorphism. All serious stuff.

Now, Rur-ple is always described as a fun way to teach programming to children. Nothing serious about that.

Granted, the lessons included so far (save for a few incomplete examples) do not touch "important modern programming concepts, like objects, and polymorphism." And granted that I wrote the lessons so that even children could learn programming by using Rur-ple; I even made some comments about this fact. It is (only) possible to do so because Python is used (instead of C++ or Java).

I guess I will have to wait until I finish writing the first 50 lessons or so before I can have people notice that Rur-ple could perhaps be taken more seriously by older children.

That's my rant for 2006!

Rur-ple update

As the few readers of this blog know, my programming work had stalled for a few months. However, I have resumed work on rur-ple over the last few weeks and some good news should come out soon.

I have revised all existing lessons and changed from using hard-coded html information (like font-colors and such) to using cascading style sheets. This will give me more freedom in trying various visual designs for the lessons. However, since rur-ple makes use of wxPython and that its browser uses wxHtml which does not recognize style sheets ... I had to write a converter that would take an xHtml file with the associated .css and convert into plain Html. This work has taken a few (long) nights to complete but it is now essentially done; I can finally resume writing new lessons.

While revising the existing lessons, I wrote my own solutions to all suggested exercises. This lead to some reorganisation of the material, some new minor additions and, more importantly, some deletions of less pedagogical examples.

I have also received some feedback (bugs report!) from a MacOS user. I had to make a few changes to the basic code and it should now be more robust on all platforms. Unfortunately, this also lead me to change the default size on opening to 900x660; I just hope that this relatively large size (greater than 800x600) will not create problems for prospective users.

The lessons are now divided in 5 parts:

1. Welcome to Reeborg's world. This includes 9 lessons and introduce various robot commands.
2. Reeborg knows Python. 15 lessons, which include an introduction to the following Python keywords: def, if, else, elif, while, not, pass. Notions of "True" and "False" are also introduced.
3. Python the interpreter. This will be more akin to a "standard" introduction to Python, although with some side-excursion back into Reeborg's world. I have written a few lessons but they will need some polishing. There should be about 10-15 lessons in total covering numbers, strings, tuples, lists, dicts as well as the following keywords: print, for, in, from, import, return, and the pseudo-keyword "as". Variable assignment is also going to be covered in this part.
4. Learning about objects. This will include lessons going back and forth between "typical" Python examples and examples in Reeborg's world. I have written four lessons and plan for about a dozen. These lessons have been the most fun to write - hopefully, they will be fun to read as well.
   
5. Making games with Pygame. I got sidetracked with learning about Pygame a few months ago. I have some first drafts of 7 lessons which were originally written independently of rur-ple and that I will have to integrate in it. I am planning to have about 20 simple lessons that will eventually lead to some separate lessons on "major projects".
   

I don't know if I will delay the release of version 1.0 of rur-ple until after these 5 parts (excluding the major Pygame projects) are completed. The next release will probably occur once I have completed the first three parts. Hopefully this will be done within a month. At that time, I should probably release a first version (0.1?) of my "xHtml/css to Html" converter.

Finally, as some users have suggested, I might investigate the possibility of turning the lessons into a book. However, I should probably get some more feedback from users before attempting to do so.

Note to self: about site customization

This post is probably of no interest to anyone but myself. I just installed Python on a new Windows XP (English), with André as my usual user name and SPE wouldn't work, due to some encoding error. The solution (which I only found in Python in a Nutshell - and only because I vaguely remembered what to look for [other Python books did not cover that topic :-( ] ) was to create a file name sitecustomize in Lib with the following:

import sys
sys.setdefaultencoding('iso-8859-1')

I have to remember this...