Archive for the ‘python’ Category

Play – a python squeak clone

Thursday, February 21st, 2008

Play is the current name for a non existent and probably never to exists clone of squeak that currently resides in my mind. I’ve been wanting to have something squeak like but with python syntax, preferably a python engine under it, to play with. I’ve just read the whole thread that included many comments by the patapata guy (too bad he stopped), and resulted apparently from a shuttleworth fund / idea, that is further discussed here. So I’m thinking – how would I name such a program? play is my current idea (acronym however you like, maybe python learning yard), and how would you write it? My current idea is to do nothing at the interpreter level – I’ll start with CPython and exec away. I’ll have to have a gui with event handling, and at a minimum create the halo effect and the Transcript and Component browser (ok, it isn’t named that but I haven’t played enough with squeak to remember unfortunately). I guess I’d create a module and give access to it as a play binding in the namespace I exec user code in. So I’ll have the basic user objects (serializing the image will be done by using the pickle+code I know some guy in python-il did, forgot his name). The gui would be gtk, since I think it’s better then wx which was my previous favorite (gtk seems more stable, especially when combined with twisted). I’ll use twisted’s event loop. Of course I don’t want user code to have to see any of this. I guess all the nice stuff, like EToys, would be implemented by having a bunch of methods in the play module that allow you to tie in to the event system, and of course callbacks are very easy in python. The whole Gui/Event layer will be strictly python, so it will be visible to the user if he wants it too, maybe I’ll find some way to save it too into the image, should be pretty easy (some bootstraping problem here, but shouldn’t be a problem). The actual objects/stuff I’ll have to implement:
event loop – basically just use twisted+gtk for this
windowing system – If I want to implement the halo’s and user objects, to get maximum control I could have a single canvas and implement the whole windowing layer including any painting my self, probably using cairo to do the painting. That would give me maximum flexibility, especially if I decide one of the goals is similarity to squeak look and feel. otoh, if I don’t want to write code to do z-buffering of windows and directing events, I could just use gtk for that and get all the widgets it has (of course I then have more limited portability).
The real question is whether someone already started doing this. I’ll have to read the rest of the thread I guess. How much time could I invest in this? what would I gain by doing so, except scratching an itch which would probably disappear if I left it alone?

Interactive Python, pypy status blog now online

Wednesday, November 14th, 2007

Some stuff I recently found:

  • reinteract – It is like a Mathematica worksheet for python. You can do plots, images, and whenever you change one of the previous lines everything affected is recomputed (think excel if you’re not familiar with mathematica). Wonder if the sage people are aware of this? they could have a desktop frontend that isn’t webbased.
  • what about a console that can be used by a few people at the same time? good for trying out stuff, teaching. Should be behind https, but that’s just a detail. Probably pretty easy to do with any available web framework. With pypy you can also do it securely.
  • pypy has a status blog – Seems they are currently or just finished a road show, hope they manage to get to the faster then c goal (just noticed that seems like faster the light speed.. guess I’m pretty slow 🙂

pypy don't do generators

Wednesday, October 31st, 2007

It does do some other stuff. Ok, to clarify I’m actually talking about RPython, the subset of python (rpython code runs under python) that is used by the pypy team to write the interpreter for python. The point is that pypy has a whole translation thing that can take rpython into about anything, including c code, making it much faster. But to get that benefit you need to be using rpython, not python. That means, for instance, no generators. The rest I can somehow get over. For instance you can’t use .so modules (afaik). So you rewrite some things in python. But most of the important “batteries included” modules are already in the rpython support lib, so you don’t really need to rewrite much (except numpy, which seems to have the beginning of support). Back to generators – it seems no one would be opposed to an addition of generator support in rpython, but it is said to be very hard, in the order of supporting stackless. Except for an intro to rpython (just a presentation) and going through some of the code through pdb/vim, I haven’t grokked it in the least. Someone reading this: Give me generator support for hanuka! Thanks!!

update: After using pypy for a week, trying to make a signal implementation that actually works in rpython (sorry for lack of capitalization), I came to several realizations:

  • lists in rpython are not lists in python (just reading the documentation wasn’t enough for me, but hitting a wall was)
  • creating code on the fly (before starting the rpython translation) is cool
  • **kw is also not rpython (hence the code creation trick I used, to make a function that already takes the correct arguments, with correct defaults)
  • rpython lists can contain instances, they can contain  classes, they can’t contain instances not derived from the same base, and you can’t call methods.
  • A lower form of signals where the user who does the connect must know the class of the target is possible, but not very useful.

And last but not least, this is not a top priority for me. So I’m just keeping this info for the next time I start up on pypy, which I really believe is a great project, and also a great learning opportunity for me, sometime in the future.


Monday, October 15th, 2007

This showes my python based geometry server and algorithms. It is basically a implementation of computing a 2d celldecomposition (arrangement), and the display is done using pygtk and opengl, and twisted for the networking, a better combination then wx+twisted (I no longer have any timeouts, nor do I have to move the mouse to force processing of network events, and ctrl-c actually works). Other then that, like always, the code is not very good, but it works. The right showes the current bug being investigated – the shape on the left is symmetric, and the resulting graph on the right should be too, but it isn’t. Probably more numerical inaccuracies (lines that should be parallel but are not, etc.).

NShape Visibility Bug

Citations Ahead

Thursday, September 20th, 2007

Let’s get this out of the system. I’ve spent the last day doing this:

  1. learning to script dia with python
  2. finding a script for searching with googlescholar from python
  3. adapting it to get the citations for the first found document, assuming a search for the full title will always lead to the document with that title being first (seems reasonable).
  4. fixing the bugs and getting the picture below.

To get it running I did the following (there is probably a much simpler way):

  1. got the from dia sources (apt-get source dia-libs)
  2. copied it to ~/src/dia_python
  3. put there the files attached (,,,
  4. export DIA_PYTHON_PATH=~/src/dia_python
  5. dia

The result is that dia has an extra menu entry in the Objects menu. It expects you to have selected a “Flowchart – doc” type (see the attached dia file), and then goes and expands it through google scholar, putting new nodes. Due to a bug/lack of understanding on my part, you have to refresh the display somehow, by dragging around, to actually see the new nodes.

Missing: identifying same objects instead of creating them again, citations by, clickable links so you can easily go to the web, export to bib file / aigaion, go wild.

Since I can’t actually upload any of the non image files (dia, py) I’ll put them here

citation generation

raindrops keep falling on my head

Monday, June 25th, 2007

The blog. I haven’t really considered the implications of this, but since this is a prewritten first entry, I probably never will.

Why am I writing this? I’ve been using a wiki for more then a year, and despite it being a very good place to store junk, it is not so good at linearizing thought. So using a real blog, will it have any better results? I’m not sure. But it has so much fewer points of entry, that may be a boon.

If I want anyone to actually read it it better contain some useful information.

I’m calling this “raindrops keep falling on my head” since I couldn’t find anything containing “webdrops” or “googledrops” or whatever, but you get the gist.

Of todays drops:
* rasterman – the man behind e17. He’s 28, like me!
* sage – first it is a web accessible python interpreter, so that’s something off the todo list, but other then that it is a very nice CAS. I’m trying to get it to do voronoi diagrams (but first I need a working python based implementation, or wrapping an existing c one, like fortune’s or Tess).
* TexMacs – this too has a python plugin which makes it very nice as well.

Plotting with TexMacs looks like this:
from math import pi
from pyx import *

basically just like plotting with pyx, but you use ps_out.

with sage:
g=sum(sum([[line([m[i],m[j]]) for i in xrange(j+1,len(m))] for j in xrange(0,len(m)-1)],[]))