Some time ago, Dr. Werner Hett created a list of 99 Prolog problems that could be used to skills in logic programming. More recently, a Ruby learner posted a Ruby version of the first 10 problems, and his solutions. This seemed to be a good idea, especially if one makes use of doctests ... and Crunchy :-). So, I've started my own version of these which you can get as a zip file (containing 6 problems and their solutions) from the Crunchy main page. If you have never done so before, to load a local html file within Crunchy, you simply click on the "Browsing" menu on the left hand side and scroll down until you reach the "Closer to home" section and follow the instructions.
Note that with the next version of Crunchy (the current one is 0.9.8.6) you will be able to start Crunchy with an arbitrary file using something like
python crunchy.py --url=full_local_path_or_url
It would be nice if there could be a complete Python version of the 99 Prolog problems. If anyone is interested in helping, please do not hesitate to contact me.
Showing posts with label crunchy. Show all posts
Showing posts with label crunchy. Show all posts
Friday, February 22, 2008
Tuesday, December 18, 2007
reStructuredText files and Crunchy
Crunchy can now handle reStructuredText (.rst) files in the same way it can process plain html ones! This requires the user to have docutils installed - which is normally the case for anyone that writes .rst files.
The test coverage for Crunchy is slowly improving. Currently, 10 modules are mostly covered by doctest-based unit tests, out of approximately 40. Since I make use of .rst files to keep the unit tests, these can now be browsed "pleasantly" using Crunchy itself.
Furthermore ... all the unit tests written so far work under Python 2.4, Python 2.5, and ... Python 3.0a1! This required some tedious rewriting of some parts of the code but the end result is well worth it - if only to really learn about differences between Python 2.5 and Python 3.0.
One thing that I found, which will be no surprise to TDD aficionados, is that code written without testing in mind can be quite tricky to write comprehensive tests for. Add to this the extra complication of making that code run under two incompatible Python versions, and you are on your way to major headaches. It's a good thing I am doing this only for fun!
The test coverage for Crunchy is slowly improving. Currently, 10 modules are mostly covered by doctest-based unit tests, out of approximately 40. Since I make use of .rst files to keep the unit tests, these can now be browsed "pleasantly" using Crunchy itself.
Furthermore ... all the unit tests written so far work under Python 2.4, Python 2.5, and ... Python 3.0a1! This required some tedious rewriting of some parts of the code but the end result is well worth it - if only to really learn about differences between Python 2.5 and Python 3.0.
One thing that I found, which will be no surprise to TDD aficionados, is that code written without testing in mind can be quite tricky to write comprehensive tests for. Add to this the extra complication of making that code run under two incompatible Python versions, and you are on your way to major headaches. It's a good thing I am doing this only for fun!
Saturday, December 08, 2007
Launching Python 3.0 program from Crunchy running under Python 2.5
As part of Google's Highly Open Participation contest, Michele Mazzoni completed the task of creating a new option for Crunchy: one can now launch (starting with the next release of Crunchy - 0.9.8.5) a program using a different version of Python than the one used by Crunchy itself. While I had suggested that the alternate Python version could be set via the configuration options for Crunchy (usually accessible from a Python interpreter), Michele had the brilliant idea to add a simple input box where one can specify the path (or 'alias') of the Python version used right on the page where the program is launched from. This makes it extremely easy to change the interpreter version used to launch a user written program.
Michele has prepared a screencast demonstrating this, which should appear on ShowMeDo hopefully soon.
Thank you Michele - and thank you Google!
Michele has prepared a screencast demonstrating this, which should appear on ShowMeDo hopefully soon.
Thank you Michele - and thank you Google!
Tuesday, December 04, 2007
More results from GHOP
Google's Highly Open Participation (GHOP) contest is attracting a lot of attention from the right people: pre-university students. The PSF is one of ten organizations mentoring students working on Python-related projects. Since I submitted tasks suggestions early on and volunteered to help following a call for volunteers from Titus Brown, Crunchy has benefited from many students contributions. Crunchy's messages have been translated in Estonian, Macedonian, Polish and Italian with, hopefully, more translations to come. Some new unit tests have been added with more to come. There may be a couple of nice surprises coming out soon too :-)
While other projects have also benefited from GHOP's students contributions, there could be more. If you have some good ideas for mini-projects (doable in 3-5 days, at a couple of hours per day with perhaps one full day), your suggestions would most likely be most welcome. Just check out the GHOP Python discussion group. And, if you would like to join the (too small) ranks of Python mentors, please do; we need all the help we can get.
While other projects have also benefited from GHOP's students contributions, there could be more. If you have some good ideas for mini-projects (doable in 3-5 days, at a couple of hours per day with perhaps one full day), your suggestions would most likely be most welcome. Just check out the GHOP Python discussion group. And, if you would like to join the (too small) ranks of Python mentors, please do; we need all the help we can get.
Sunday, June 24, 2007
From vlam to nam: Using Crunchy to interact with the official Python tutorial
Breaking news: you can now use Crunchy to browse and interact with the official Python tutorial. More below...
Since my last post that described briefly some features of the new Crunchy engine, I have not had much time to work on Crunchy. Johannes too has been fairly busy so that Crunchy development pretty much stopped, until the beginning of Google Summer of Code. Two students joined the Crunchy team: Edin Salković and Bryan Psimas. Unfortunately, due to other commitments, Edin was not able to continue with his SoC project - but he did manage to write the prototype of a new plugin for Crunchy that I will describe below.
The new Crunchy engine now works extremely well. As I wrote in my previous post, Crunchy is now more responsive; it supports simultaneous execution of multiple code sample, proper input (stdin) handling from the webpage browser and the api (for writing tutorials) has been significantly simplified as there is no longer be any need to have an embedded "canvas" call in a tutorial: the user is now able to load a graphics dynamically anywhere on a page. These graphics can even include simple animations using pure Python code (for the end user - javascript behind the scene for us, unfortunately).
There is more. For example:
Quite a few features from the "old Crunchy" need to be implemented (e.g. menus including a way to properly quit the application, translations, update:the ability to load an arbitrary tutorials given a URL, etc.) in the new version but, overall, it is working very well.
One of the "problems" with the old Crunchy is that it did require two things from a tutorial writer:
And ... Crunchy has now been written so that it automatically inserts a Python interpreter whenever it sees a bare <pre> (i.e. with nam = no additional markup). As a result, one can now browse the official Python tutorial with Crunchy and interact with it.
This automatic insertion of an interpreter sometimes yields too many interpreter inserted on a page than really needed; it is better to hand craft a tutorial. However, it should make Crunchy a lot more useful to many more people.
For those interested in trying out the "new Crunchy", an alpha release is available. If you have never used Crunchy before, you should try version 0.8.2 first and go through the tutorial from the menu.
Since my last post that described briefly some features of the new Crunchy engine, I have not had much time to work on Crunchy. Johannes too has been fairly busy so that Crunchy development pretty much stopped, until the beginning of Google Summer of Code. Two students joined the Crunchy team: Edin Salković and Bryan Psimas. Unfortunately, due to other commitments, Edin was not able to continue with his SoC project - but he did manage to write the prototype of a new plugin for Crunchy that I will describe below.
The new Crunchy engine now works extremely well. As I wrote in my previous post, Crunchy is now more responsive; it supports simultaneous execution of multiple code sample, proper input (stdin) handling from the webpage browser and the api (for writing tutorials) has been significantly simplified as there is no longer be any need to have an embedded "canvas" call in a tutorial: the user is now able to load a graphics dynamically anywhere on a page. These graphics can even include simple animations using pure Python code (for the end user - javascript behind the scene for us, unfortunately).
There is more. For example:
- it is now possible to style <code> elements;
- Python code sample (either inside <pre> or <code>) that contain pre-existing html markup can now be handled by Crunchy without generating an error (blank page!) as before;
- it is now possible to specify a starting number different from 1 when requesting that line numbers be added to a code sample;
- when it styles the code, Crunchy now automatically detects if a given code sample represents an interpreter session or a "normal" code sample;
- it is now possible to use input() and raw_input() with an interpreter, and the result appears inside the page displayed by the browser.
Quite a few features from the "old Crunchy" need to be implemented (e.g. menus including a way to properly quit the application, translations, update:
One of the "problems" with the old Crunchy is that it did require two things from a tutorial writer:
- That the html code written be W3C compliant (with no warning, no unclosed tags, etc.).
- That Crunchy specific markup (vlam = very little additional markup) be added to instruct Crunchy to add interactive elements.
And ... Crunchy has now been written so that it automatically inserts a Python interpreter whenever it sees a bare <pre> (i.e. with nam = no additional markup). As a result, one can now browse the official Python tutorial with Crunchy and interact with it.
This automatic insertion of an interpreter sometimes yields too many interpreter inserted on a page than really needed; it is better to hand craft a tutorial. However, it should make Crunchy a lot more useful to many more people.
For those interested in trying out the "new Crunchy", an alpha release is available. If you have never used Crunchy before, you should try version 0.8.2 first and go through the tutorial from the menu.
Wednesday, January 10, 2007
Pycon 2007: it's Crunch time - take 2
Well, it's done: I've registered for Pycon, booked a hotel room and bought plane tickets. Since November 1, when I first heard that my talk had been accepted, crunchy has changed quite a bit and my planned presentation will have to change. One demo I had planned to do, using codetch, and which I thought would take about 5 minutes will now be doable in less than 30 seconds without having to use anything else than the "new and improved" crunchy. Unfortunately, there has been so much changed since the last release that the documentation has to be re-organized significantly - this means that I can't really do a new release right now as it would likely be too confusing. So, I'm racing against the clock to put everything together to do a new release before Pycon. However, if some of you are interested in having a preview, drop me an email and I'll let you know where you can get the code from and give a quick description of how to use the new features.
Looking at the official statistics, I find the relatively small numbers of attendees compared with last year somewhat disappointing. Given that more talks are going to be presented this year, with a much larger rejection rate, I find this rather puzzling. I imagine the organizers are rather disappointed.
Looking at the official statistics, I find the relatively small numbers of attendees compared with last year somewhat disappointing. Given that more talks are going to be presented this year, with a much larger rejection rate, I find this rather puzzling. I imagine the organizers are rather disappointed.
Wednesday, January 03, 2007
Unicode headaches ... and a solution
Work on Crunchy has restarted by both Johannes and I over the holidays, after a few months long hiatus. Hopefully, we'll be in a position to do a new release soon (just a few more features...). Among the changes, Crunchy now has a proper embedded editor, EditArea. See this example to get an idea of what EditArea can do. Actually, the Python support has since been improved by Christophe Dolivet, the creator of EditArea, prompted by a few suggestions of my own, but the new version has not been made publicly available yet. It is however already used in the development version of Crunchy, and, with a few additions of my own, will definitively be showcased during my Pycon presentation.
Other Crunchy changes include a proper handling of English and French translations. Now, since EditArea's tooltips are available in many more language, I thought I should use a more complete encoding (like utf-8) rather than the one I normally use (latin-1). After all, if rur-ple has been found useful enough to be adapted to 6 languages (with Italian and Chinese in the pipeline), I figured that Crunchy is likely to eventually see the same kind of adaptation.
However, I soon encountered a most puzzling bug. All strings translated were properly rendered by Firefox except for those coming out of an interpretor session (some tracebacks have been customized and translated in French as well as being available in English). When French was selected as the default language, whenever an accented letter, like à, was supposed to appear as a result of a Python output, a ? instead was displayed.
After trying all kind of encoding/decoding tricks over the course of a few hours, I remembered that I had set the default sytem encoding on my computer to latin-1. I decided to change it to utf-8 and, sure enough, everything was working as expected. Success at last!
However, this was only the beginning of my problems. My favourite editor, SPE, stopped working. I also tried to run rur-ple which failed miserably. [Idle, on the other hand, which I use very rarely, was still working perfectly.] Clearly, changing the site default encoding was not an appropriate solution: I could certainly not depend on having a crunchy user set his or her site customization to utf-8. A different approach was needed.
After reverting back to latin-1 as my default python site encoding (so that paths that included my name, André, were properly read by SPE) and poring over the code, I finally figured out a more general solution.
Whenever Crunchy executes some Python code written by a user (or provided by a tutorial writer), it starts a Python interpreter in a separate thread. This Python interpreter uses the default system encoding for all its computation. When the result needs to be sent back by the Crunchy server to Firefox, it needs to have its encoding changed as
Of course, in retrospect, it all makes sense but it did stump me for quite a few hours; perhaps the information included here will save a few minutes or hours to someone else.
Other Crunchy changes include a proper handling of English and French translations. Now, since EditArea's tooltips are available in many more language, I thought I should use a more complete encoding (like utf-8) rather than the one I normally use (latin-1). After all, if rur-ple has been found useful enough to be adapted to 6 languages (with Italian and Chinese in the pipeline), I figured that Crunchy is likely to eventually see the same kind of adaptation.
However, I soon encountered a most puzzling bug. All strings translated were properly rendered by Firefox except for those coming out of an interpretor session (some tracebacks have been customized and translated in French as well as being available in English). When French was selected as the default language, whenever an accented letter, like à, was supposed to appear as a result of a Python output, a ? instead was displayed.
After trying all kind of encoding/decoding tricks over the course of a few hours, I remembered that I had set the default sytem encoding on my computer to latin-1. I decided to change it to utf-8 and, sure enough, everything was working as expected. Success at last!
However, this was only the beginning of my problems. My favourite editor, SPE, stopped working. I also tried to run rur-ple which failed miserably. [Idle, on the other hand, which I use very rarely, was still working perfectly.] Clearly, changing the site default encoding was not an appropriate solution: I could certainly not depend on having a crunchy user set his or her site customization to utf-8. A different approach was needed.
After reverting back to latin-1 as my default python site encoding (so that paths that included my name, André, were properly read by SPE) and poring over the code, I finally figured out a more general solution.
Whenever Crunchy executes some Python code written by a user (or provided by a tutorial writer), it starts a Python interpreter in a separate thread. This Python interpreter uses the default system encoding for all its computation. When the result needs to be sent back by the Crunchy server to Firefox, it needs to have its encoding changed as
result = result.decode(sys.getdefaultencoding()).encode('utf-8')
Of course, in retrospect, it all makes sense but it did stump me for quite a few hours; perhaps the information included here will save a few minutes or hours to someone else.
Thursday, November 30, 2006
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.
Subscribe to:
Posts (Atom)