Readline for python on OSX

Was trying to use python interactively on the command line in OSX 10.4, and realized it didn't have readline support (up arrow command history in interative python shell). Fortunately, google turned up the answer here. To summarize, running the following command in a terminal did the trick.

python `python -c "import pimp; print pimp.file"` -i readline

Debugging firefox (mozilla) extensions with venkman

In my quest to get OSX working the way I want, I discovered that a number of the firefox extensions that I use don't actually work on OSX. So I figured this would be a good opportunity to learn a little about mozilla extensions by debugging what was wrong with them.

In my quest to get OSX working the way I want, I discovered that a number of the firefox extensions that I use don't actually work on OSX. So I figured this would be a good opportunity to learn a little about mozilla extensions by debugging what was wrong with them.

First off, I recommend you create a separate dev profile so that you don't screw up your real profile while mucking around with debugging. There are also some other config variables documented at the mozillazine wiki, which are useful if you want to do stuff like editing extension files directly without having to restart firefox to have your changes take effect. To create a dev profile, I fired up the profile editor by running the command

/Applications/Firefox.app/Contents/MacOS/firefox-bin -P

Once the dev profile is created, run it and install venkman and the offending extension(s). I'm using venkman 0.9.85 on firefox 1.0.6.

/Applications/Firefox.app/Contents/MacOS/firefox-bin -p dev

You should probably install just the extension you care about so that it can be debugged in isolation, unless of course, one extension is interfering with another and you need to figure out why.

Now you are set to debug your extension, but first configure venkman to be able to debug extension files by unchecking "Debug->Exclude Browser Files". You may also want to tell venkman to automatically break in javascript that causes an Error or Exception by checking the menu items "Debug->Error/Throw Triggers->Stop for Errors/Exceptions". Not all errors/exceptions are bugs, so this may cause more noise than its worth - especially if you have a bunch of extra extensions installed in your dev profile.

There are already a number of tutorials that teach one how to use venkman, so I won't go into that here. You should now be able to set breakpoints in your code and step through it whilst exercising your extension. However, if you want to be able to debug the initial load/startup of your plugin, you need to do a couple more steps.

First, relaunch firefox telling it to run just venkman, without starting a browser:

/Applications/Firefox.app/Contents/MacOS/firefox-bin -p dev -venkman

At this point, since the browser window hasn't loaded, none of its extensions have been initialized either, so you can set a future breakpoint on the load of the extension's javascript file and be able to step through it while it is loading. In my case, I chose to debug the Single Window plugin because it seemed small and simple enough for me to get my feet wet. I also find it essential because new browser windows take a long time to start in my regular profile because of the extensions I have installed, with Google Toolbar being the biggest culprit.
/fbreak chrome://singlewindow/content/singlewindow.js 1

Now, its just a matter of telling venkman to start up a browser instance, which you can do with the open-dialog command, and then stepping through whatever code interests you.
/open-dialog chrome://browser/content/browser.xul

BTW, I submitted a fix for the Single Window extension to its author, and it should be in the next version > 1.4. If you can't wait, it was just a matter of saving the value of window.Startup at the point right before it was changed rather than saving it at initial extension load at which point it seems to be null on OSX:

Line 67: window.Startup = singwin.Startup;
becomes:
orig_Startup = window.Startup;
window.Startup = singwin.Startup;

Running eclipse with GTK on Mac OSX

So, the eclipse performance on OSX was bugging me enough that I decided to try getting the eclipse GTK port running on OSX. The idea being that eclipse GTK runs pretty good on linux these days, so it should run similary well on OSX.

So, the eclipse performance on OSX was bugging me enough that I decided to try getting the eclipse GTK port running on OSX. The idea being that eclipse GTK runs pretty good on linux these days, so it should run similary well on OSX.

Well, I was partially right. While it does run a lot faster than carbonized eclipse, there are a bunch of UI glitches that make it less usable for me. I'm hoping that if I document how I got it to work, maybe someone else can do the grunt work of trying out other alternatives that may fix the problems I am having. If you do, I'd appreciate the feedback.

First some pre-requisites. You'll need to have a X server installed and the gtk libraries. I'm using the Apple X server (from OSX 10.4 install CD), and used fink to install all the gtk libraries I needed - in fink-commander, install everything with gtk+ in the name.

Next, get the eclipse linux-gtk 3.1 release and extract it to the directory of your choice (I used /Applications/eclipse-swt. This makes for an easy starting point since I didn't feel like creating a new eclipse port and building from scratch.

There are really only 3 native components we need to worry about replacing, two of which are optional. The launcher we can bypass by using java to launch eclipse, and the org.eclipse.core.resources.linux only improves filesystem performance, defaulting to java.io.File if the native library is not present. The only one we really need to do anything for is the swt plugin. Fortunately, one of the eclipse developers recently ported/compiled the swt-gtk libraries for OSX, and you can fetch them from here.

Now you need to extract the swt plugin into a directory of the same name:

cd <eclipseInstall>/plugins; unzip -d org.eclipse.swt.gtk.linux.x86_3.1.0 org.eclipse.swt.gtk.linux.x86_3.1.0.jar

Remove the jar when you are done. Next you need to copy the osx-swt-gtk *.jnilib files from the above download into the directory you just created. I also deleted the existing binaries from that directory to be safe.

Finally, to run eclipse, you have to use the command line to run the java launcher directly. Make sure your X server is running, and the shell you are running from has the DISPLAY=:0 environment set. Then the command to run eclipse is

java -cp <eclipseInstall>/startup.jar org.eclipse.core.launcher.Main -clean -os linux -ws gtk -arch x86 -vmargs -Xmx512M

Note that I specified linux/gtk/x86, which seems counter intuitive, but thats the download we started from. Also, you probably don't want to use an existing workspace, so pick an empty directory for your workspace location.

Now, assuming I didn't miss anything (let me know if I did), your eclipse should fire right up using swt-gtk.

Issues I have

• 
  Dialogs are all weird sizes/layouts, no idea how to fix them. Especially broken is the Find dialog (ctrl-f in an editor)
  


• 
  Related to dialogs, but more annoying to my work habits, the ctrl-f6 used for switching between editors is unreadable because its too small.
  

Things to do

• Billy Biggs (eclipse guy who made the binaries) mentioned on eclipse.platform.swt newsgroup that fonts may be to blame, could be worth investigating.


• Try a different X-server, maybe a more recent build of Xfree/Xorg from fink or darwinports would fix some of the dialog issues


• Try some different window managers - I only tried the built in apple one and gnome-metacity, both exhibited same funky dialogs


• If other issues are resolved acceptably, might be worthwhile to do the full macosx/gtk/ppc port using the eclipse source distribution. At the very least, the core.resources binary from linux/gtk/x86 should be recompiled in the same way swt libs were so that we don't suffer when doing a workspace refresh.

Eclipse performance under OSX

Dog slow!

A couple of things I've learned

• Stop spotlight from indexing eclipse workspace.


• Bug in Tiger/Java that causes eclipse to slow to a crawl after launching a (java?) app. This was really killing me because I have a builder than runs an ant script, so my performance was always in the shitter. Better now that I've removed the builder, but the UI still seems very slow - especially when using Apple-F6 to switch between editors. I hear that disabling a bunch of things like CVS decorators make it better, but haven't tried it yet cuz I like those things. See this eclipse bug for details on the Java performance problem under OSX (boy I sure wish I could find a torrent for 10.4.3 build 8F8)


• I've been experimenting with getting eclipse to run with GTK bindings under OSX. I;ve bgotten it working, but it has too many issues to make it suitable for me. I'll publish the details in another entry if anyone comments that they are interested. Maybe someone else can take up the torch and get it working well.

Made the switch

Well, hell has finally frozen over as I've made the switch (at least for work) to Apple. Specifically, 17" Powerbook G4 running OSX 10.4 (Tiger).

I like what I see so far, now its just a matter of learning everything all over again.

My biggest gripe to date is not so much with Apple, but with the fact that eclipse is so much slower under OSX than Windows or Linux. Its kinda ironic that I make the switch from linux to OSX for development work right when eclipse is finally performing acceptably on GTK - exactly the same scenario when I made the switch from Windows to Linux. Lets hope that the performance improvements for OSX don't take as long as they did for GTK!