Reinteract on Windows

November 18, 2007 – 1:33 pm

So I thought I’d try booting up one of my systems into Windows today and see how much work it would be to get Reinteract running. It turned out to be completely an exercise in clicking through installers (9 of them). If you are already a Windows Python user, the amount of things you need to install will be less.

  1. Follow the instructions in the PyGTK FAQ to install Python, GTK+, and PyGTK.
  2. Download and install NumPy and SciPy from www.scipy.org.
  3. Download and install the latest version of matplotlib.
  4. Download and install TortoiseCVS. (Will likely require a reboot since it’s a shell extension)
  5. Right click on your desktop, and select “CVS Checkout…”
  6. Enter “:pserver:anonymous@git.fishsoup.net:/srv/git/reinteract.git” into CVSROOT (without the quotes), and “master” into the Module (without the quotes). (Fetch List.. won’t work). Click OK
  7. Rename the resulting folder from “master” to “reinteract”
  8. Go into reinteract/bin and double click on”uninst”
  9. You can play around, or use File/Open to open the examples from reinteract/examples

Reinteract on Windows

It seems to work pretty well. Caveats I know about:

  • replay and the “play” example won’t work. (An easy project for somebody who knows how to get Python to play sounds on Windows)
  • There’s a bug in the cairo backend for matplotlib-0.90.1 which will cause non-square images to not work. (The images in the imshow example are square…) It’s pretty easy to fix up: just edit C:\Python25\Lib\site-packages\matplotlib\backends\backend_cairo.py and in draw_image(), change “rows, cols, row*4” to “cols, rows, cols*4”.
  • Saving over an existing file doesn’t work (should be an easy fix)
  • The GTK+ and PyGTK versions in the installers referenced above are a bit out of date. So they aren’t exactly what I’ve been testing with, though they seem to work fine. (There’s one bug triggered when deleting multiple lines and results, but that’s also in the latest released version of GTK+, 2.12.1, and only fixed in subversion.)
By Owen | Posted in Coding, Reinteract | Comments (3)

Reinteract infrastructure

November 13, 2007 – 12:36 pm

There’s been a lot of interest in Reinteract. So, I decided to go ahead and spend a bit of time setting up project infrastructure.

Everything is a bit raw and not fully configured, but should be better than having all the discussion in blog comments and my private mail. Next up on my plate is integrating the patches people have sent me.

By Owen | Posted in Coding, Reinteract | Comments (4)

Reinteract – Better interactive Python

November 10, 2007 – 9:41 pm

Recently, I’ve been doing quite a bit of reading about computer analysis of musical sound and some experimentation. But there wasn’t really anything I knew of that fit my desires for an experimental platform. Python + numpy provided a good combination of a pleasant language and signal processing ability. But beyond that I wanted an interactive environment that created a persistent record of what I was doing. And that means the ability to edit: to go back and fix up mistakes and add comments. Because a literal transcript of a shell session is worthless… it’s full of typos and dead ends. Also, I wanted inline plots and images. In essence, I wanted something like the Mathematica notebook user interface, but for Python.

The inline plot part can be found in Nicolas Rougier’s Pylab GTK Console, but other than that, it’s just the standard Python interactive mode in a GTK+ window. IPython has a lot of features but it’s still a shell in a terminal. So, I decided to create something myself. A couple of months of occasional evenings and 4000 lines of Python later, Reinteract is beginning to shape up. A screencast of it in operation can be found below:


Screencast (5 minutes)

I’m not ready to make a tarball release yet, but you can get the code out of git. (Instructions here.) The chances of it working out-of-the-box on a recent Linux system are pretty good. In theory, it should be completely portable to Windows and even to gtk-quartz on OS/X, but figuring out the details would take some work.

P.S. – Python shell envy within the Online Desktop / Mugshot team? It’s really a pretty different sort of thing from Colin’s project.

By Owen | Posted in Coding, Reinteract | Comments (38)

JHBuild and the Online Desktop

October 29, 2007 – 1:44 pm

One of the things I’ve been working on over the last few weeks is creating a recommended JHBuild configuration for the online-desktop project. The idea here is to get all of us on the same page as to how they we developing and testing, and to have a straightforward and reliable way that we can recommend to people who want to try the online-desktop out.

We’ve put up detailed instructions on live.gnome.org. Please try them out. Unless you are actively using JHBuild at the moment, I’d suggest moving any existing .jhbuildrc away and starting from scratch rather than trying to adapt. There are a lot of small details, and it’s easier to just follow the steps literally rather than trying to figure out the differences and merge them in.

A couple of observations: one is that it was surprisingly hard to create a JHBuild configuration that worked fully and integrated well with the user’s system. For example, the need to add line like:

os.environ['DBUS_SYSTEM_BUS_ADDRESS'] = 'unix:path=/var/run/dbus/system_bus_socket'

to get the D-BUS library installed by JHBuild to connect to the system bus is far from obvious. I think a lot of these difficulties are there because jhbuild is policy neutral over whether it’s supposed to be as isolated from the system as possible or as integrated. Most people want the integrated version: you don’t want to have to install a separate copy of, say, OpenOffice in your jhbuild directory, do you? But you have to engineer that yourself. I think we could do better here.

Another observation is that I had forgotten just how nice running out of a source build was. I ran into a metacity bug this weekend (#491090), and was able to easily come up with a fix, test it, and immediately start using the fixed version, something that would have far more of a pain with a system install.

Two quirks that I haven’t yet fixed in the online-desktop configuration: 1) trying to GPG sign a message using my system-built Evolution causes a deadlock 2) the JHBuild version of pygtk/pygobject doesn’t get found. (I know why, and could work around it by explicit PYTHONPATH munging, but am hoping to come up with something cleaner.)

Update: I tracked the evolution hang down to a Fedora 7 patch to Evolution that made it incompatible with upstream evolution-data-server. Shouldn’t affect other distributions or Fedora 8. If you’re on Fedora 7 and using Evolution, you’ll need to JHBuild it as well.

By Owen | Posted in Coding | Comments (3)

GNOME Summit, day 3

October 9, 2007 – 12:42 pm

Day 3 started 10:00 with summaries. Rodrigo gave a detailed summary of the control center discussion the previous day, and we had quick reports from the other sessions of the previous day.

The day was much like the other: people hacking and talking and a few sessions. I didn’t get to the *Kit sessions (PolicyKit, ConsoleKit, PackageKit), since we were running an online-desktop BOF at the same time, so I can’t tell you what went on there. In the online-desktop BOF, we discussed the code organization, and went over in detail how the GConf-sync feature of the online-desktop is implemented on the server side and client side. We also discussed other possibilities for GNOME enhancements via the online-desktop infrastructure. An interesting question is what data belongs in the core online.gnome.org server and what belongs elsewhere? My take is that the core server should generally be storing structural information: what are your accounts, who are your contacts, and so forth. It shouldn’t be responsible for storing actual documents or doing heavyweight computation.

We did the wrap-up session at about 3:00. The highlight was a demo of the results of Tomboy hackfest that Boyd Timothy, Jeff Tickle (and others?) were doing during the summit. Demos: embedding a drawing widget into a note, and special handling of Bugzilla links. Stefan Kost also showed off the bprof tool he created during the summit. The interesting thing to me was the visualization, which plots all the individual allocations with time on one axis and size on the other. I hope he’ll post screenshots.

People who didn’t have flights to catch hung around and talked until 6:00. I spent some time talking to Asheesh and Rob Taylor about microformats and RDFa. With the online desktop we do a lot of work integrating the services you use, but being able to react directly to the data on the pages you are on adds a whole new set of possibilities. (The conversation was inspired by a Firefox hack that Rob showed off during the online desktop session on Friday where he added extra right click actions for names on Facebook pages.)

My overall feeling from the summit was that the people who came got what they wanted out of it … the 50-60 attendees were largely experienced GNOME hackers who already knew who to talk to and what they wanted to do. But I think the lack of structure and small number scheduled sessions would be more of a problem if we done a better job of promoting the events and gotten more people who are not yet core community members. Next year, we should put some effort into planning discussions and hacking sessions ahead of time.

I created a Suggestions Page on the wiki for people to add their own thoughts about how to make it better next year.

By Owen | Posted in Coding | Comments (6)