Exclude Directories From TextMate Side Bar for Faster Find in Project
I’m not much of a user of TextMate project files, generally preferring to just mate . in a directory. This works great until the directory or one under it contains large, irrelevant files like log files or database dumps. Its at this point you start encounter massive slow downs in the otherwise very useful ‘Find in Project…’ function. The slow downs turn into crashes if the files are big enough as this results in TextMate atttempting to grab vast amounts of memory. Eventually the OS tells it to, “bugger off, 1Gb is all I can give you”, or something along those lines.
A common solution, particularly when working on Rails projects is to create a shell alias that just invokes mate with the directories of interest. This works ok but given I’m working on a mix of project types (Pylons, Rails, Radiant) I wanted a solution that did the reverse: Choose everything except what I want to exclude. Informed by an answer to a question on Stack Overflow I came up with this:
As the comments in the script note I have this in a file called ‘ate’ in ~/Local/bin, which is in my PATH. I can now happily go to any directory, type ate and have it ignore that list of directories.
My First New Site is Live
Since starting my new job at Tricycle Developments in January I’ve been working on a project to repurpose the Reddit source code into a kind of community blogging platform with voting and karma.
The result of that work went live on Thursday and after an initial hiccup with a questionably named user posting off topic content its going well so far. One of the first posts on the site is one asking for feedback on Issues, Bugs, and Requested Features. The thread has been inundated with all three of these so it looks like I still have plenty of work ahead refining the user experience.
As well as being the first site I’ve worked on from start to finish (aside from personal ones) Less Wrong is also my first Python project and significant open source project. Its been great learning another programming language and putting that knowledge into practice. You can check it out the code on GitHub (pun not intended). Also if you end up looking at or using the code or Less Wrong itself and encounter any issues there is an issue tracker on Google Code where they can be logged.
Stop Vim Completion Searching Included Files
I use vim coupled with the SuperTab plugin for my text editing and auto-completion needs. In some vim setups (E.g. Mac OS X) it is configured by default to search included files when completing words. This sounds like a useful feature but it turns out not to be. It has a habit of searching the include files of system libraries and modules, the keywords of which you rarely want. Its also quite a slow operation as it trawls through all the files. The solution is to add the following in your .vimrc file.
set complete=.,w,b,u,t
This is the same set of flags as the default except with the ‘i’ option removed. See the help for the ‘complete’ option for an explanation of what each flag means.
MP3 Decoder Libraries Compared
For my current software project I have the need to decode MP3 files for the purpose of producing an audio waveform. It doesn’t need to be overly accurate as the decoded samples will be displayed, not played. However it does need to be fast, as a typical use case for the application will be MP3 files of around 100Mb (full length CDs). The application is for Mac OS X, although the results of my testing below could be useful for other platforms.
Assisted by a code sample from Apple I wrote an initial version of the decoder that would read the source MP3 file and write the raw linear PCM data out to a file. I did this using the Core Audio framework built into Mac OS X. Once the program was working I tested it against some sample files and came to the conclusion that 4 seconds to decode a 3 min track was great but over 100 seconds for a full length CD, not so great.
I did some searching and came up with two other libraries that seemed well suited to the task of MP3 decoding, they were mpg123 (libmpg123) and MAD (libmad). mpg123 had claims of being very fast, mad claimed it was very accurate.
Methodology
I built the two additional libraries with the default configuration options, except for libmad, which I added the --enable-speed option. With the help of example code I made programs out of each that were comparable to the first version for Core Audio. I.e. MP3 file in, 16-bit Linear PCM audio samples out.
To provide a benchmark I wrote a script that would run each of the three programs against a source MP3 file. Each program reported the elapsed time (via time(3)) and the processor time (via clock(3)) when it finished decoding. The programs were run one after another on the source file 10 times. Their PCM output was written to a new file for each invocation.