Code on Thoughts and Ramblings

Nix on Mac

Mon, 16 Dec 2024 12:45:28 +0000

A couple of months ago, I started using Nix on the Mac instead of homebrew. This included setting up home-manager and nix-darwin. There are a lot of setup guides on these and I’m not going to repeat that work. I will mention some pieces that I found particularly annoying and their solutions.

Multiple Repositories

Nix allows you to specify multiple repositories where it can fetch code. However, getting this to work with home-manager can be annoyingly difficult to figure out, especially if you use a flake with multiple files like myself. This is how I got it to work:

A Month with AppCode

Mon, 29 Apr 2013 14:45:43 +0000

Anyone who uses multiple IDEs along with Xcode recognizes just how far behind Xcode is compared to others. I would even go as far as to argue it is at least half a decade behind Eclipse. Features which I have long grown use to having are completely absent in Xcode. Then, about a month ago, I discovered AppCode and started using it for my Obj-C development at work. I could repeat the feature set mentioned on their website, but instead I’ll assume you’ve read that and outline the crucial parts.

Trac.fcgi Memory Usage

Sat, 16 Oct 2010 18:06:28 +0000

I’ve been slowly transitioning to using nginx as the web front-end in an effort to reduce Apache’s memory usage. In keeping with this task, I’m moving more and more off of Apache. One piece I recently moved was trac, transitioning to using it directly by nginx by running it in fast-cgi mode where as previously it was running as cgi though Apache.

While fast-cgi is faster, it has inherent issues, such as any memory leak can result in ever growing memory usage, which is exactly why Apache has a setting for each child to serve a limited number of requests before exiting. Trac.fcgi has no such directive, and has the equivalent of a large memory leak, a non-expiring cache. While it’s not as bad as a memory leak, which will indefinitely grow instead of reaching a limit, if the cache size is larger than the available memory for trac to use, it’s just as serious. The only solution, without fixing trac’s caching mechanisms, is to restart trac periodically, but during the time trac is restarting, all requests are lost, causing bad gateway errors to the user. Additionally, the restart needs to be done manually. Clearly not an ideal solution.

Google Link Redirection (cont.)

Sat, 09 Oct 2010 14:04:21 +0000

Earlier I wrote about google’s link redirection. I have finally finished my testing of a Safari extension which kills this behavior. I didn’t want to release this extension until the updating mechanism worked and that is what took me so long. Anyway, here is the the extension. Enjoy, and let me know what you think.

Googleâ€™s Link Redirection

Tue, 31 Aug 2010 02:42:50 +0000

Google, for quite some time, has been redirected clicks on links in their search results to www.google.com/url?…. While I don’t approve of such practices, I didn’t mind it so much since this is presumably an effort to improve their search results. That changed recently, when I noticed that my history in Safari was filled with entries containing that URL as the title. Considering the fact that I often use the history to re-find a page with pertinent information, this is bordering on making my browser usage useless. Note: I tend to cmd-click links so they show up in new tabs. If you just click the link, the title in the history is correct.

Text Compression Code Released

Sat, 17 Jul 2010 20:36:22 +0000

After it’s original post, I got a request for the code I used in my text compression technique. I’ve not gotten around to cleaning up the code and separating it from it’s test environment so it can be distributed separately. You can read more about it in its own page.

Sometime soon, I’ll get around to releasing my code for fetching old Escape Pod episodes that I hinted at earlier.

Text Compression Techniques

Wed, 29 Jul 2009 22:17:20 +0000

A friend of mine develops on an Bible application for the iPhone, BibleXpress. Since his application includes several translations with the app, he once mentioned to me the possibility of compressing them to save space. Any compression that is done must achieve a good ratio, but more importantly, decompression must be fast. I took it upon myself to find a compression algorithm that could fit the bill.

In my test case, I worked with the NASB translation of the Bible. The raw text of this translation, minus formatting and book/chapter/verse identifiers is 3.965MB. Since the iPhone already has zlib, using gzip compression is an obvious choice. When compressed with gzip, the file size becomes 1.189MB, a significant savings. Even though bzip2 is not readily available on the iPhone (at least not that I could find), I tested its compression which produced a file size of 0.8548MB. While these mechanisms provide a significantly smaller file, when one desires a certain portion of the file, one must first decompress the entire file up to that point. This is an expensive operation on a small device such as the iPhone.