Recently, I came across a neat script from Dr.Drang for making quick
graphs from the command-line. I thought this would be a nice thing to have
around, since it would save me having to look up all the options to make
gnuplot look decent or remembering how exactly
matplotlib works. I
downloaded the script, tried to run it, and the comedy of errors began:
ImportError: dlopen(.../matplotlib/_png.so, 2): Library not loaded: /usr/local/lib/libpng15.15.dylib
Referenced from: .../matplotlib/_png.so
Reason: image not found
How vexing, apparently matplotlib wants a different version of libpng than I
have installed. Luckily, I use [
homebrew][brew] to install this sort of
thing, so with only a little bit of searching, I was able to find this
Stack Overflow answer that showed exactly how to get the desired version
of the library I wanted.
Being the hubristic fool that I am though, I assumed that since I wasn’t seeing the error that the questioner there was with regards to freetype, I would be fine to only do the first part of the fix and only get the old version of libpng and not bother with getting the specific version of freetype.
Of course, after performing the lengthy rebuild of matplotlib, now I was getting the freetype error, so I had to do the second step anyway. I avoided having to go through the lengthy re-build again though…because now pip was caching the compilation. While this did make it go very quickly, it also meant that it wasn’t bothering to try to link things again, so it was still trying to use the wrong version of the library and dying.
After cursing, repeatedly re-building, and trying in vain to discover if pip had
some way to tell it to clean out its cache, I eventually was able to discover
that the temporary build files were being stored in the intuitive location of
only the mildest of invectives, I deleted the directory, rebuilt matplotlib, and
no longer saw the freetype error! Hooray! Instead, I got an error that my
version of python wasn’t built as a framework.
This, of course, was because I’ve been using pythonbrew (which is now
deprecated) to provide python, so that I don’t need to worry about my particular
version of python being overwritten by OS upgrades. There is a flag one can
give pythonbrew to make it build as a framework to avoid exactly this issue, but
I had neglected to provide it when I first set it up, many moons ago. Since, as
best I can determine, there’s no way to make pythonbrew just build the
framework, I had to uninstall my current version of python and re-install it,
this time with the
--framework flag. This took a while, but it succeeded, and
I was finally able to run the script! Except now vim, my text editor, was broken.
At this point I was becoming a little more annoyed. Making graphs once in a
while would be nice, but I use vim not only for all of my work, but for
composing emails1 and basically anything that entails composing more than a single
line of text. Now though, any time I tried to start vim, I was rewarded with
nothing but the terse error
ImportError: No module named site.
My first thought was that since I had re-installed python, all the packages had
been nuked, so I just needed to re-install said packages. However, there exists
no package named
site. As best I can determine
site is some sort of magical
meta-package that should just always exist.
After some fruitless
Googling DuckDuckGo-ing, I guessed that it was because
vim was linked against some particular version of python and that having
the pythonbrewed version installed as a framework was causing it some distress.
Suppressing the terrifying flashbacks to the last time I tried to do anything
related to vim linking with python2, I decided to try just
re-installing vim from homebrew, hoping it would pick up the new environment.
Girding my loins, I unlinked my current version of vim, ran
brew install vim
to get the new version…and the build exploded. Suppressing panic, trying not
to imagine a future where I wrote code using a quill and my own blood, I tried
again. And, for reasons I completely fail to understand, it worked. Which
frankly, makes me even more uncomfortable. When something unexpectedly fails,
you can debug and figure out what’s going on. When something unexpectedly
succeeds, all you can do is hope that you never lose the favour of the good
faeries in the computer.
So, in summary: Computers are ridiculous, making the smallest change to anything will break everything, and success is more troubling than failure. But at least I can make these sweet graphs!
In fact, while in the throes of dealing with this, I got a time-sensitive email from my step-mother that I couldn’t respond to, since vim would crash every time mutt tried to compose a response, forcing me to resort to sending a text message, like an animal. ↩
A long and sordid tale, entailing building vim from source; many, many segfaults; weeping; and no real resolution ↩
I’ve been fairly quiet online for the last year or so, as I’ve been fairly heads-down working on quite a few different things. Penyo Pal went through a few iterations and my new startup has been doing a number of different things.
Most of what I’ve been doing is closed-source for now, but we’ve been wanting to start open-sourcing our stuff. To help start that process, I decided to try to compile a list of the stuff I’ve built over the last little while that we’ve released.
Without further ado,
From Penyo Pal, we forked and modified two different game frameworks: Moai for the original version of the game & currently for Private Eye and Dance Party, then Ejecta for the current version of the main app.
- Ejecta (fork): Now lagging behind the main repo by quite a bit, but we’ve added a number of helpers that we needed for our purposes.
- moai has two different branches we used on the previous versions of Penyo Pal, both of which are very far behind
From Lean Pixel, where most of our work has been Clojure-based.
- inliner: A clojure library for inlining CSS in HTML emails.
- lein-lesscss (fork): A fork of the leiningen lesscss plugin to update the version of the LESS compiler & to let it run continuously in “auto” mode
- www_fdw (fork): A fork of the Postgres www foreign data wrapper to fix some bugs we found using it
- metaslurp: A clojure library to get information about a given URL, primarily using Open Graph, but falling back to heuristics if unavailable
Hopefully we’ll be able to open-source some of the big, cool things we’ve been working on soon…
He’s fabulous. It helps that he’s nice to look at.
Livin’ the dream
So I decided to make a lil’ promo video for the weightlifting team I want to start in the fall. Enjoy :)