the helvetica scenario

Terry wrote his thoughts on pycon, so I figured I might as well too.

I should probably preface this with saying that I’m probably going to come off sounding like a total hater. That’s not entirely untrue, but don’t take it personally, I just hate a lot of stuff.

I started writing out a whole long thing talking about every talk I saw, but I grew tired of that by about saturday morning, so here are just some of the highlights.

Friday started with keynotes and whatnot. It’s nice to hear Guido talk and all, but whatever, nothing too interesting here. First talk was Max Ischenko’s Simple WSGI Composition. I thought the title here was a little misleading; the talk was very Pylons-focused. I’ve never used Pylons myself, and I still don’t particularly want to, but it’s good to see how the other half lives now and then.

Next was Daniel Greenfeld’s A Short Pinax Tutorial. I don’t think I “get” Pinax. I was hoping that this talk might show me how to do what I wanted with it, but now I’m feeling more like the usage I want is not part of their agenda. I understand that, I’m all for opinionated software, I just like it better when they’re compatible with my opinions. Brant’s question afterwards pretty much summed it up for me: “Why is Pinax a thing?” I also feel that all the stuff they provide above and beyond just a collection of reasonably isolated apps just gets in the way.

I wish I had gone to the VisTrails talk.

Grig’s Creating RESTful Web Services With Restish was quite a bit better than I expected. I’ve seen a couple REST talks, and they’re usually pretty awful, essentially boiling down to someone slowly repeating “nouns and verbs”. I thought Grig delved a little deeper into the right things, and gave some nice comparisons to xml-rpc. I don’t remember much more specific, I’ll probably watch the video again, though.

Saturday’s keynotes were a little better. I’m not entirely proud of it, but my brain pretty much shuts down whenever anyone starts talking about IronPython. I just can’t bring myself to care about it at all. PyPy, however, is some voodoo space shit from the future and it scares the hell out of me.

My first talk, Demystifying Non-Blocking and Asynchronous I/O was probably my favorite of the entire conference. Peter Portante had some solid slides, and did an excellent job of explaining something I knew nothing about in a way I could easily follow. I highly recommend this one.

David Beazley’s Understanding the Python GIL was probably the most hyped talk of the weekend, and it did not disappoint.

The middle of the day saturday was a little weak, I sat it out for a little while, and worked on a little project for later. I did go see Titus’ Continuous Integration and Ned Batchelder’s Testing talks, though. Both were very strong, and relevant to my interests. Titus is a great speaker, and gave probably this year’s most entertaining talk for me at least. Ned was also wearing one of my company’s nosetests shirts, which marks him as a person of quality.

Saturday night was the most important event of the weekend, the Testing In Python BoF meetup. What started last year as just a quiet little meetup for a quiet mailing list somehow grew into a monster. We were packed into the largest open space room, and people were even standing out in the hall. I feel a little bad asking this, but who are these people? The TiP BoF had probably the highest concentration of “big names” of any open space, I get the feeling that they attract a lot of “groupies” who figure that anything Michael Foord or Jesse Noller is going to is something they should be at too. I suppose they’re not necessarily wrong in thinking that, but it does make getting enough beer a problem.

Sunday morning, I went to the Eventlet talk. It sounded like some really cool stuff, and I hope I can think of an excuse to use it. After that was the two Mercurial talks. The first one by Dirkjan Ochtman wasn’t quite everything I was hoping for. It seemed a little too aimed at people that didn’t know how DVCS worked, where I was hoping for something that actually delved into the code, showing how Mercurial specifically made it work. Ironically the next talk, Hg vs. Git had a bit more of that, and was very good. I still don’t know how to actually do anything in Git, but at least I’m thinking it might be possible to learn.

So yeah, Pycon is awesome.

I’m using the system python 2.6 install on Snow Leopard, and occasionally get this when doing instally-type things:

/Library/Python/2.6/site-packages/setuptools/command/install_scripts.py:3: UserWarning: Module pkg_resources was already imported from /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/pkg_resources.pyc, but /Library/Python/2.6/site-packages is being added to sys.path
      from pkg_resources import Distribution, PathMetadata, ensure_directory
/Library/Python/2.6/site-packages/setuptools/command/install_scripts.py:3: UserWarning: Module site was already imported from /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site.pyc, but /Library/Python/2.6/site-packages is being added to sys.path
      from pkg_resources import Distribution, PathMetadata, ensure_directory
warning: no previously-included files matching '*.*' found under directory 'docs/_templates'

I try to be good about using virtualenv and pip and whatnot, but I probably slipped up somewhere. Either way, I finally got tired of seeing those warnings all the time and actually read them. Throwing caution to the wind, I deleted /System/​Library/​Frameworks/​Python.framework/​Versions/​2.6/​Extras/​lib/​python/​pkg_resources.pyc and everything seems to be working. hth

I don’t think that there has ever been a point in time where installing lxml on OSX was not a horrible pain in the ass. I think that at one point, it was enough just to install updated versions of libxml2 and libxslt, and lxml would compile nicely. But I must have done something bad, cause at some point recently, lxml just stopped compiling for me.

This would not do at all. I use virtualenv (and virtualenvwrapper) pretty religiously, and am loathe to install much of anything in the system-wide site-packages. I needed to get things to a point where a straight-up easy_install lxml would work. I didn’t wanna be messing around with custom install flags or whatever every time I cut a new env.

This is not a neat step-by-step guide for getting lxml working in OSX. This is just a record of some stuff that I saw, and some things that I did. Some combination thereof was sufficient to get things working.

For the record, I’m using lxml 2.2.2, libxml2 2.7.5, and libxslt 1.1.26.

One day, I fired up python, typed from lxml import etree and got an error much like the following:

>>> from lxml import etree
Traceback (most recent call last):
  File "", line 1, in 
ImportError: dlopen(/Users/nwilliams/.virtualenvs/lxml1/lib/python2.6/site-packages/lxml-2.2.2-py2.6-macosx-10.5-universal.egg/lxml/etree.so, 2): Symbol not found: _xmlFree
  Referenced from: /Users/nwilliams/.virtualenvs/lxml1/lib/python2.6/site-packages/lxml-2.2.2-py2.6-macosx-10.5-universal.egg/lxml/etree.so
  Expected in: dynamic lookup

>>>

Needless to say, I was less than pleased.

Looking though the source, I gathered that _xmlFree was a symbol exported by libxml2. My first thought was that lxml was somehow compiling against the old system version of libxml2, or for some other reason couldn’t find the new version.

I noticed a few funny things about the output when installing lxml. First, there were two lines right before all the heavy compilation work:

Using build configuration of libxslt 1.1.26
Building against libxml2/libxslt in the following directory: /usr/local/lib

The second line suggested that lxml was, in fact, seeing the version of libxml2 that I wanted it to. The first was a problem though, because normally, it looks like this:

Using build configuration of libxml2 2.7.5 and libxslt 1.1.26

For some reason, lxml wasn’t finding xml2-config. Doing export XML2_CONFIG=/usr/local/bin/xml2-config seemed to fix things.

The other issue was probably the important one. While compiling lxml, I would see a bunch of warnings that looked like this:

ld: warning in /usr/local/lib/libxml2.dylib, file is not of required architecture
ld: warning in /usr/local/lib/libxslt.dylib, file is not of required architecture

Also for another file or two, and all repeated a few times.

Checking file /usr/local/lib/libxml2.dylib told me that the files in question were only compiled as i386 binaries. I eventually found this page, which showed me how to compile libxml2 and libxslt as universal binaries. I did modify things somewhat, though, most notably adding 64-bit architectures.
The configure command I used for libxml2 was:

env CFLAGS="-arch i386 -arch ppc -arch x86_64 -arch ppc64" ./configure --enable-static=no --without-python --disable-dependency-tracking

And for libxslt:

env CFLAGS="-arch i386 -arch ppc -arch x86_64 -arch ppc64" ./configure --disable-dependency-tracking

The CFLAGS bit is necessary, that’s what’s making things work. I don’t actually know exactly what the point of --enable-static=no is. I’m sure it’ll come back to bite me in the ass at some point. --without-python sounds scary, but since lxml is actually an alternative to the gross “real” bindings, we don’t care about them. I also have no idea what --disable-dependency-tracking does, but make will fail without it.

Once I had these universal libraries built and installed, easy_install lxml worked like a charm.

If you upgrade zsh and suddenly find that certain completion functions are breaking and throwing up all over your terminal, remember to delete ~/.zcompdump.

For instance, when I upgraded one of my systems from 4.3.4 to 4.3.9, I would get the following error whenever I tried to complete a command name:

alternative:69: command not found: _path_commands

This gets me every time.

Nothing too exciting here, just something I was chewing on for a while and wanted to write down. I’m testing a page that uses GreyBox to display modal windows. GreyBox puts the content in an iframe, so you have to do a little finagling to get at it. Most of the selenium rc methods that handle frames seem to require me to actually know something about the frame I’m looking at, like an id or a name or something. I dunno any of that crap, just use that damn iframe there.

Anyway, select_frame (I’m using the python bindings here) lets you use the “index” locator, so you can jump right in to the first frame. Then to get back out, there is the “relative” locator that lets you just move up one level. You end up with something like this:

# do stuff in the main window here
sel.click("the link you're clickin")
sel.select_frame('index=0')
# do stuff to the iframe here
sel.select_frame('relative=up')
# you're back in the main window

I don’t have all that solid a grasp on what’s going on around here, so I’m sure this only works in whatever bizarre edge case I have set up. Whatever, hopefully google will direct some poor soul here and I will end up making his day just that much brighter.

Here is an update to the CSS I posted the other day for tweaking Helvetireader.

#selectors-box, #add-box { display: none; }
.entry { -webkit-border-radius: 0 !important; -moz-border-radius: 0 ! important; }
.entry .collapsed { padding: 2px 0 2px 0 ! important; }
.entry .collapsed .entry-secondary { margin-top: 1px !important; }
.entry .collapsed .entry-original { margin-top: 2px !important; }
.entry .collapsed .entry-icons { top: -4px !important; }
.entry .collapsed .entry-date { margin: 0 30px 0 0 !important; padding: 1px 0 1px 0 !important; }
.entry-actions { height: 1.2em !important; padding-top: 0px !important; }
.entry-actions:hover { padding-left: 25px !important; }

I forgot to even mention in my last post, but the real reason for needing most of this is that I’m using Reader in list view, instead of expanded view as is intended. I think the only real difference you might see using this css in expanded view is that you won’t get the nice rounded corners around each entry. Unless there’s a CSS selector for matching the parent of a certain element, I don’t know a practical way to preserve the corners. I also never use expanded view, so I don’t care.

I use Google Reader a lot, and lately I’d been feeling somewhat frustrated with its use of space. It is the means through which I consume the majority of my online information, and I wanted it to be a little more efficient about presenting that info.

So, I was very happy to discover Helvetireader, a Greasemonkey script for applying a much more minimalist style to Reader. It removes many of the UI elements, forcing much wider use of keyboard shortcuts. I was already a big fan of Reader’s keyboard shortcuts, and Helvetireader prompted me to get familiar with a few others that I hadn’t even thought to look for.

At the moment, the script just adds two elements inside the page’s head tag — one link tag to change the favicon, and another linking to the stylesheet. I have been tweaking the script a little to get things a little more how I like them. What I did is just add a style element, define its InnerHTML, and append it as a child to the head tag. I put my tweaks inside a new userscript, but you could just as easily edit the Helvetireader script. Just make sure that your adjustments come after Helvetireader’s CSS.

So, the javascript I have for adding the style tag looks something like the following:

var newStyle = document.createElement('style');
newStyle.type = 'text/css';
newStyle.innerHTML = "CSS GOES HERE";
document.getElementsByTagName("head")[0].appendChild(newStyle);

The biggest thing that I wanted to change was removing the links above the feed tree. It takes up like half the height of the page and I never use any of them. Even with the browser window maximised, I could only see a tiny subset of my feeds. You might say that I was mad as hell and not going to take it anymore. Luckily, fixing this was a simple matter:

#selectors-box, #add-box { display: none; }

In list view, the little star icon was kind of off center, and the date overlapped with the icon on the right. The star icon being low also made the whole bar taller than it should have been and the top of some of the text underneath was being exposed. The following fixed that:

#entries.list .collapsed .entry-icons { top: -5px ! important; padding-bottom: 5px; }
.collapsed .entry-date { margin: .2em 30px 0 0 ! important; }

When an article is expanded, the options at the bottom only show up when you hover over them. They also overlapped with the little gear icon. I think they might have been pushed down a bit or something as well. As is typical with CSS that I write, I’m never quite sure what is actually necessary. I tend to just get stuff working, maybe pare down a few really obvious things, and then not mess with it. So don’t take any of this as authoritative, it’s just stuff that seems to work for me.

.entry-actions { height: 1.2em ! important; padding-top: -0px ! important; }
.entry-actions:hover { padding-left: 25px ! important; }

Unfortunately, Javascript doesn’t have nice multi-line strings or heredocs, and I didn’t really feel like putting all of my CSS on one line. So, I cheated a little like so:

newStyle.innerHTML = "\
#selectors-box, #add-box { display: none; }\n\
#entries.list .collapsed .entry-icons { top: -5px ! important; padding-bottom: 5px; }\n\
.collapsed .entry-date { margin: .2em 30px 0 0 ! important; }\n\
.entry-actions { height: 1.2em ! important; padding-top: -0px ! important; }\n\
.entry-actions:hover { padding-left: 25px ! important; }\n\
";

Not ideal perhaps, but not too terrible, I’d say. And that’s usually good enough.

I’ve only been using this for a day or so, but I’m really liking it so far. I suspect that I would probably feel the same even if I didn’t have a huge fetish for Helvetica.

EDIT: updated css

• ohnotheydidnt: Kermit Bale
  (tags: humor photos)

That twitter digest plugin was a nice idea and all, but it kind of loses its effectiveness when you never post for real. Also, it didn’t seem to understand how dates work.

• Ikea is a fun place, moreso than I remembered #