Fatal Python error: Interpreter not initialized (version mismatch?)

Abort trap

Fatal Python error: Interpreter not initialized (version mismatch?)

Abort trap

gcc myfile.c -lpython -shared -o mylib.so

gcc myfile.c -framework python -shared -o mylib.so

The ability to branch quickly and in a lightweight manner is one of the major selling points of systems like Mercurial and Git. Recently I’ve been thinking about trying out some refactorings and that can be difficult to do when you need to make sure that you can have a build-able version of your code at all times. Some things just take time, and the whole point of refactoring is to improve your code so rushing through it to meet an unrelated code deadline just doesn’t make a lot of sense.

Enter Mercurial.

There’s a project for Mercurial called hgsubversion that will allow you to pull from a subversion repository and make a mercurial repository locally. (Yes, git has something similar) Then you can hack away to your heart’s content using hg to branch and keep track of changes without pushing the changes out globally to the other SVN users.

This is exactly what all of the cool kids using hg, git, and bzr have been doing for years. Now those of us who talk to SVN can leverage this technique to bring a little more awesomeness to our day-to-day work, and no one is the wiser. At least that’s my theory.

Installing hgsubversion on a Mac or in Cygwin is like pulling teeth. I take that back, pulling teeth is not as painful. Plus you can leave your teeth under your pillow for some cash… but I digress. The best way to install it (for me at least) is to do the following:

• Have the following installed: mercurial, easy_install, the XCode tools (command line tools like gcc)
• Get a copy of the python swig bindings for Subversion. Collab has prebuilt binaries that seem to work best. I just copied the bindings from /opt/subversion/lib/svn-python/ to my python site-packages directory. I installed Python 2.6, so for me that path is: /Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages
• Get hgsubversion by typing at the command line: hg clone http://bitbucket.org/durin42/hgsubversion/ ~/hgsubversion
• cd into ~/hgsubversion/ and type in python setup.py install
• For me, the system had to download a few things and build them, so make sure you have XCode and the 10.4 SDK installed. (I’m running XCode 3.2.1 for this exercise)
• Hopefully everything completes normally. If it does, do a victory shot. If it fails, do 2 shots and then try to figure out what went wrong.
• Next make a file in your home directory called .hgrc
• Inside the file put the following:

[extensions]
rebase=
svn=/Users/<YOUR USERNAME>/hgsubversion/hgsubversion

• This should tell hg that you’ve got something extra for it. I went blind sometime during my attempts to get this working and had a typo in that line that kept me from getting it working for an embarrassingly long time.
• If you have done everything right, the moon is in the proper phase, and the wind is blowing from the NW at 7 mph, then this command should let you pull down a project from Google code:

hg clone svn+http://<A PROJECT OF YOUR CHOICE>.googlecode.com/svn <WHATEVER DIR>

• The end result should be a mercurial repository on your local machine. Refer to the link for hgsubversion for more details about commands and links to other installation instructions. (Some are older than others, and the commands have changed a little bit over time.)

So, that’s what I’m up to. Hopefully this will let me do some interesting experiments locally without sacrificing the safety blanket of using version control.

If you are seeing weird errors in the console when you run the application (specifically “Could not connect the action <your_action> to target of class <your_AppDelgate_class>”), here’s what it probably is: In the AppDelegate python file that XCode creates it uses spaces to do the indentation of the methods.

I hail from a land where tabs are used for such tasks, and the use of spaces is look down upon in much the same way that pick ones nose in public is.

At any rate, what’s happening is when the code is compiled/run the python interpreter is not recognizing the new methods that I put in (using tabs to indent) and instead of giving me a warning about inconsistent indention, it fails somewhat silently in that it groans it can’t hook the action up to the class and that’s it. It wasn’t until I turned on the invisible characters that this occurred to me that it might be the root cause of my problems.

Once setting all of the indentions to be the same, I chose tabs, everything worked like a champ.

By the way, if you are looking for some tutorials for PyObjC in XCode 3 (there are a ton of XCode 2 tutorials out there, but things have changed ever so slightly in 3), be sure to check out these links:

• PyObjC Hello world for XCode 3
• PyObjC Resources

For starters I created a new XCode project, ran it to make sure it could build, and then decided to check it in to svn so that I would have a “clean” starting point in case I ran into problems. This is how I normally work in other IDE’s, and I’ve never had a problem. Until today.

After setting up the repository in XCode I couldn’t find how to set the project so that XCode would “know” it was under version control (or SCM as XCode refers to it). If you look at the project’s properties, there is a drop down list the lists the available repositories (or it offers to let you set up a new one, which is a nice shortcut). However, the repository I just added is grayed out. After a half hour of trying various “obvious” things I gave up and googled around.

It turns out that XCode can’t create and then check in. The project has to be put into the repository, then checked out before XCode will recognize that it is under source control. Very unusual, but what ever, I decided to play along.  I used XCode’s svn browser (which isn’t half bad) to upload the code, then deleted the project and checked it out.

And right about then is when it became obvious that I was traveling the wrong way on a one way street. Here’s an executive summary of what I found so very, very, very wrong with XCode’s SCM integration:

1. I had to create the project, check it in, then check it out for XCode to realize that it was under version control.
2. Although XCode has an svn repository browser that allows me check in and out the code, it doesn’t seem to know anything about XCode projects as it checked in the build directory without asking. For me (and a lot of developers I know) the last thing I want in version control are files that are going to change constantly (i.e. object files). Checking in a finished version, fine. Checking in a ba-jillion intermediate files: fail.
3. After checking out the project, XCode began complaining about there not being a lock on a file in the build directory. The error message actually said “This might be a bug, please report it.” Sorry Apple, I’m a nice guy, but I’ve got limits. This seems like something that shouldn’t happen on a fresh project (i.e. all boilerplate code, I haven’t done a thing to the project yet).
4. Deciding that I might be slightly smarter than the computer, I decided to delete the build directory in the repository. I tried to refresh the project to let it know there was a change it might need to be aware of. Instead I was made aware of the fact that there doesn’t seem to be one central view of what’s changed for the project. The near-useless SCM menu item in the project reported that one file had change, and I could not seem to get it to even look at the project as a whole. Maybe I’m spoiled by the way Eclipse handles this situation (which provides a bunch of clues in different areas, but all of which lead to a pretty straightforward GUI for dealing with changes). Even TextMate handles this decently (just not as good looking as Eclipse).

By this time I just gave up. I removed the repository connection from the project settings, and decided to just go Command-line for doing my updates/commits. Life’s too short to be chasing my tail on stuff like this.

Last week at an Apple ADC Tech Talk I saw an example of Quartz Composer.  I had only vaguely heard of Quartz Composer before and hadn’t really looked into it. It turns out that it is a very useful tool for building a neat GUI quickly, and is available as part of the Xcode tools. After getting home from the talk I played around with it and was able to build lots of cool demo-type apps very quickly.

And then… I discovered that it can be integrated into Cocoa apps very easily. I mean, I found this great tutorial on the Apple Dev site, and within 5 minutes I had a Quartz Composer (QC) window running in my test app along side my OpenGL test window. And not a line of code was written. The absolute bets news is that you can expose the internals of the QC window to the Cocoa framework and then manipulate the QC object from your program!

That just rocks so hard. Now I can focus on the mechanics of my program instead of worrying about the mechanics of OpenGL. Of course, the QC isn’t 100% efficient as hand tuned code, but for most of what I want to do with it, its perfect! Thank you Apple!

As a side note, if you are interested in doing Mac development and you aren’t a member of the ADC (Apple Developer Connection), you really owe it to yourself to go sign up for one of their free accounts and check it out. Its a great resource for all things Mac and OS X.

But this is nothing new. Emacs vs. vi, Whopper vs. The big Mac, Windows vs. Mac vs. Linux, Kirk vs. Picard. There have been many holy wars before, and there will be many more. And like most of them, this is one is over something seemingly small and insignificant.

For some people these apps are the best thing since sliced bread. Myself, I don’t really get the appeal of the application. If I want “full screen” editing, I usually just maximize the window, but I’m simple like that. To each his own I suppose, no one is forcing you to use the app.

But one thing I do get is the cool free publicity that these apps are getting! WriteRoom is the leading full screen editor for the Mac, and with Mark’s blog post making the front page of Reddit, I imagine that it is getting a lot new traffic which translates into new sales. At $24.95 a pop, even a dozen extra sales will mean a few extra hundred dollars for the developer.

That’s not too shabby. Hopefully this little flare up will result in the developer (Hog Bay Software) winning a few new customers. Mac Developers can use all the free attention they can get…

When I added the file(s), I did so by clicking on “New” and selecting a C++ file under “BSD” because it was the first option that I saw. It turns out when you do this, the Cocoa project settings will attempt to compile the files as Objective-C files (which they are not). This results in cryptic messages about a “parse error before” in you .h file.

The solution is to right click on the .cpp file, select info, then change the file type to “sourcecode.cpp.objcpp”. This tells XCode to use the Objective-C++ compiler to build the files, and from then on everything *seemed* to work ok. I’ve never worked with Objective-C (or Obj-C++), so I’m figuring this out as I go. If something bad seems to happen, I’ll post a follow up to let everyone know.

Last year I had an “incident” that basically required me to re-run the 10.4 installation. I think when I did that it must have wiped out the symbolic link I had made to get Petit to run. If you are finding yourself in this situation, here’s what I did to get it up and running (Mac Mini running OS X10.4.5):

WARNING: Only attempt this if you are confident of your computer skills *and* you have backups of your important data. This is a fairly safe thing I’m describing, but you are doing it at your own risk. I’m merely pointing out what I did and how it worked for me. Your mileage may vary. Proceed at your own risk.

1. Open up a terminal window.
2. Type in cd /usr/local/lib and press return.
3. Type in ls and press return. Odds are there is nothing there.
4. If you don’t see anything that says SDL, type this in: sudo su and press return
5. Enter your system password. (Basically you are going to run as root for this next command)
6. Your prompt should now say “root”. Type in (or cut-n-paste) this line: ln -s /sw/lib/libSDL-1.2.0.dylib libSDL-1.2.0.dylib and press return.
7. Type in ls and press return. You should now see libSDL-1.2.0.dylib. At this point try running any Petit dos program. If it works, yaa! If not, you might be missing the SDL installation. I’m not sure if it comes with the Mac by default or ifI had installed it manually.

If you have success or failure with these instructions, please leave a message in the comments. I’ll try to help out if I can (but no guarantees).

Go get it now!

If nothing else, Camino scored another point with me when Firefox crashed on me the other day. Plus using Firefox on the Mac isn’t as satisfying as I thought it would be. The Adblock plugin doesn’t work quite the same as it does in Windows, and that was a major disappointment. I’m sick of the flash based ads that are running everywhere that spike my CPU to 100% and make the whole system grind to a crawl. I was really hoping that Adblock would help with that, but I found it difficult to get it to mark a site as “needing to be blocked”. Another point for me was that Camino uses the native OS X buttons, where as Firefox uses the plain HTML web buttons.

On the bright side, Firefox does seem to handle flash better than Camino. The CPU only goes up to about 75% on the bad ads. *sigh*

What’s the lesson in this? For me its to make sure the next desktop computer I get has a minimum of 1GB of memory. Trying to skim by on 512MB in my Mac Mini was a bad idea.