I try to keep my image compression code fairly simple; it doesn’t do the best lossy compression, it doesn’t to the best lossless compression, but it does both fairly well, fairly fast, and without introducing much code bloat.

As a measure of this, I simply look at the size of the resulting executable for my simple test-application, wako. This can of course be very misleading, but it certainly is some measure of complexity, and I try to maintain its size below 40,000 bytes. But generally speaking, I want to do this by simplifying the code and making it more reusable, not by applying some complicated tricks that make the code harder to read but result in smaller a smaller binary.

So after fixing a problem in the implementation (using a fixed factor to convert from a floating point error-estimate of the mean-square error to a fixed point representation, which could then overflow), the code had grown above the “magic 40,000” mark. This was due to the fact that many channels can be interleaved into a single file, but to do that properly they each have to have comparable error estimates.

One obvious place to reduce the size, is the very basic command-line argument parser (which is not part of the library itself, but the sample application), which when commented out, reduces the size of the binary by 8kb! Rewriting this explicit parser to be data-/table-driven did not reduce the size as much as hoped, but it was enough.

39,849

As an aside, did you know the order of declarations within a structure has a non-negligible effect on code-size? 😉

I am currently writing a graphical user interface (GUI) for my Wavelet Image Compression Library that will allow for selecting and inspecting compression settings. As my “main computer” for the past year has pretty much been an Apple Mac mini (with an x86 laptop for Linux (work) and Windows (games)), I decided to write it in Cocoa, learning the Objective-C language and the Cocoa class library / ApplicationKit at the same time.

I quite like the language (ignoring the message send syntax in square [] brackets) as you’re always aware when you’re doing OO stuff like sending messages, or writing simple C-code. It is very dynamic as essentially all binding happens at runtime and dynamically (which you of course pay a speed penalty for, but that shouldn’t matter much for high-level GUI code).
The Objective-C class library (“Foundation”) is very clean, always making a distinction between mutable and immutable versions of objects, and seems very complete with all the conveniences of modern OO.
Using the Interface Builder to create not only the actual interface, but instantiate classes and bind actions / outlets is a very nice touch. You can usually get a semi-functional mock-up of your application without writing any code at all, especially when using things like Cocoa Bindings, which allows for introspection via Key-Value-Coding (KVC) conformant objects. In essence, the AppKit “knows” how to access your member variables and set them according to the rules you defined in Interface Builder.

There are also some things which aren’t so nice. Documentation in some areas is lacking (e.g. using NSTreeController without CoreData or a dataSource), some things that look simple on the surface definitely aren’t under the hood (Key-Value-Observation replacing some of my objects by proxies, but at least they remembered to properly override isEqual: ;)). Memory management is also something which my head took some time to wrap itself around properly: every object is reference counted, but the crux is NSAutoreleasePool which is a bit like poor-man’s garbage collection. My problem with that wasn’t what it does, but when it does it. Oh, and namespace support would be nice…
Today’s challenge was to extend the NSOpenPanel of an NSDocument-based application with an accessoryView. I got it working in the end, but it wasn’t trivial (subclass NSDocumentController, changing stuff around in the Interface Builder to make sure the subclass is instantiated first, creating a separate .nib file for the accessoryPanel and praying that the View gets released properly).

Most of the time it’s a joy to work with, and a welcome change of pace from the dreadful writing of Windows GUIs in MFC. I only wish a decent Objective-C compiler with Foundation class library were available there as well (GNUStep doesn’t count, unfortunately). Might be an interesting idea to try to get Objective-C working on Microsoft’s .NET platform…

I’ve been looking for something (other than regular backups) to keep a history of my personal development projects.
Once upon a time, I used Perforce (the free 2 client license), but I’ve never really gotten on with it that well; probably using about 2% of its features. It also uses a rather different terminology to what I am used to.
Looking for alternatives, I ended up trying out darcs, and it is easy to use and does what I want from it. An additional bonus is, that you can work disconnectedly (as each workspace is also a repository) and that it does not try to reinvent the wheel by not having its own server / network protocol. Simply get access to the files any way you can (e.g. http, ftp, ssh, …).
This serves me quite well when developing the same project on more than one machine, although darcs most decidedly does not like keyboard-interactive ssh authentication. It simply fails to get the patches (using sftp), although manual sftp / scp and ssh work fine (using Ubuntu Linux to get a repository from Mac OS 10.4). Using non-interactive key-based authentication works fine, however.
It is written in Haskell, which has some unwieldly dependencies unless linked statically; I have to admit I’d feel slightly better were darcs written in something else (e.g. Python or Ruby). But, as long as it works… 😉
I also took a look at Codeville but that doesn’t even support binary files, so it’s a no-go.
Nevertheless, I’d quite like a comparison between recent, maintained distributed revision control systems (e.g. darcs, arch (?), codeville, monotone, git (?), …).