PyOmniFocus

A while back, I mentioned here and here that OmniFocus maintains some kind of cache of your data in a SQLite database.

I just hacked together a quick little prototype Python module for reading OmniFocus data:

https://github.com/msabramo/PyOmniFocus

Please feel free to fork it and send pull requests! Or file bugs. Or send ideas for improvements.

This could be used as part of a larger solution to pull all the data out of OmniFocus and publish it as some consumable format for the web (e.g.: XML, JSON, HTML, etc.). Or to have an OmniFocus CLI, which is what I’m most interested in.

Fix for oh-my-zsh git-svn prompt slowness

I was dying a slow death from the slowness of my zsh prompt when using oh-my-zsh‘s git plugin and a repository managed by git-svn. I finally decided to do something about it today.

I tracked the slowness down to the parse_git_dirty function in oh-my-zsh/lib/git.zsh. This function calls git status which seems to be quite slow in my environment. My fix was to replace the oh-my-zsh version of the git_prompt_info function with a version that doesn’t call parse_git_dirty. This means that I can’t get the little checkmark (“✔”) or “X” (well actually “✗”) that shows whether my working copy is dirty or not, but it’s worth it to me to not have my prompt lag like crazy.

To fix this, I pasted the following into my ~/.zshrc:

https://gist.github.com/2355834

TarColor: color the output of tar tvf similarly to the way GNU ls would

One day I was looking through a tar file and looking for an executable. When I use ls, I can do this at a glance by just looking for green filenames, as I always have my ls configured to show executable files in green. It occurred to me that it would be nice to see the same kind of coloring when looking at the contents of tar files with tar tvf. Thus, TarColor was born. It was a quick Perl script to scratch my own itch. I thought others might find it useful, so I put it on GitHub and CPAN.

Usage

You can use tarcolor manually like this:

$ tar tvf some_tarball.tgz | tarcolor
... colored output ...

There is also a bundled shell script (for bash and zsh) that makes tar automatically pipe its output through tarcolor:

$ source /usr/local/etc/tarcolor/tarcolorauto.sh
$ tarcolorauto on
$ tar tvf some_tarball.tgz
... colored output ...
$ tarcolorauto off
$ tar tvf some_tarball.tgz
... normal uncolored output ...

Customization

Colors can be customized using the LS_COLORS or TAR_COLORS environment variables:

$ export LS_COLORS='di=01;34:ln=01;36:ex=01;32:so=01;40:pi=01;40:bd=40;33
:cd=40;33:su=0;41:sg=0;46'

The format for LS_COLORS and TAR_COLORS is the same format used by LS_COLORS (used by GNU ls). So if you use GNU ls and have your LS_COLORS set, then tarcolor will use similar colors as ls. If you want to tweak your colors and don’t want to edit LS_COLORS manually, you might try this online LS_COLORS generator.

Links

Installing GNOME in FreeBSD 9

I pretty much followed these instructions, but one extra step was required.

The problem that I was having was that the system kept running out of file descriptors and becoming unusable. After a little digging around with fstat and such, it was apparent that gam_server from Gamin was the culprit, using some 3700 file descriptors. From a bit of web browsing, I saw that this is somewhat common on BSD, because BSDs don’t have inotify like Linux, so Gamin uses kqueue but this requires opening files and using file descriptors. This is described in the Gamin Wikipedia page.

My solution was to increase the number of file descriptors by adding to /boot/loader.conf:

kern.maxfiles="25000"

This was enough file descriptors to placate gam_server:

[marca@freebsd9-0 ~/src]$ fstat | grep gam_server | wc -l
    6435