Angus Thinks

Tag: development

  • SQLEditor 1.4b2

    Another day, another beta. (Kind of)

    SQLEditor 1.4b2 is now available, which is pretty much bug fixing against 1.4b1.

    There were several issues with 1.4b1 including an annoying bug that would sometimes delete foreign key connectors when you deleted an unrelated table.

    There are some fixes for other bugs which turned up and some improvements to undo/redo, to make it more stable when you undo or redo lots of things, one after the other.

    I’ve also moved SQLEditor to Sparkle. Sparkle replaces an update system that I wrote myself and it should offer better update support as well as a nice html based ‘what’s changed’ window.

    SQLEditor also now tells people that it is a beta and exactly when it will expire. It probably should always have done this, but it does it now, which is probably good.

    There are also some minor fixes to the live source view, so that it changes with the document sql dialect and appears correctly when reopening existing documents.

    [Download] (3.4MB DMG File, changelog)

  • What have I been doing recently?

    Well no updates for a bit. Humm?

    The main things I’ve been working on:

    1) SQLEditor. Lots of things are being worked on. The user interface is being rewritten to improve speed and increase flexibility, the data layer is being rewritten to switch it to cocoa (instead of java), the JDBC code is being rewritten to make it use JNI instead of cocoa/java and a new crash reporting system based on Google BreakPad is being worked on. There are also some other things too like live source view and assorted bug fixes.
    2) HTMLValidator. Also undergoing development. It recently moved across to use Sparkle (yey!) instead of the SQLEditor derived update system (which will also be replaced eventually). The final 1.0 release is due very soon now and several people have set in nice comments.
    3) A new idea (still secret) 🙂

    4) Web site improvements for malcolmhardie.com. Some have been deployed, others are still waiting to be deployed. Although the biggest one which is almost entirely invisible is the rewritten order processing system, which now supports multiple different products and better management features. But only I (and my somewhat-trusted minions) will ever see it. 😉

    Then when I’ve not been working I’ve been playing Pikmen on my new gamecube. (Many thanks to Leynos!). I’ve wanted to play this game properly for years and years and it definitely meets and exceeds my expectations.

    Although I also played some theme hospital this morning using Parallels 3.0 (new release). It runs really nicely, although since it is an ancient game (1997) this shouldn’t be too surprising. I hope to try out some of my other really old games to see how they perfom under parallels.

  • Writing Unit tests for Cocoa

    I realized something interesting today.

    I use unit testing to (hopefully) improve the quality of my code.

    With Java I use JUnit. With native Mac stuff I use OCUnit.

    One really clever thing about OCUnit that I realized today is that if you have several SenTestCase subclasses, each with multiple tests in it, you can put all of them into one XCode target and OCUnit will automatically run them as suites in one test run. This means that you get a summary of all of the tests at the end.

    Previously I had a separate XCode target for each test case, where each test case class reported its results separately, which isn’t nearly as good.

  • static link library to replace dylib in mac os x

    This post on the xcode-users list explains a neat trick on how to get xcode to link a static library instead of a dynamic library.

    Imagine the circumstance: you want to use a particular non-standard version of a native library which is already part of the system; perhaps you want to use an old version with better compatibility, or a newer version with more features. The obvious thing to do is to take a static build of the library and add it your xcode project.

    However this typically won’t work. The linker will choose the system version instead because by default it looks in all possible locations for a dynamic library first before looking through the same list of locations for a static library. If there is a dynamic library in any of the search locations it will always get chosen. There are some good reasons for this, but what if you really want to include your own statically linked version?

    The answer is to add the -Wl,-search_paths_first flag to the other link flags option (under linking in target settings).

    When this is set each possible location for a library is inspected first for a dynamic library and then for a static library. This means that the static library will get linked correctly.

    It’s not exactly something that will be needed frequently though.

    Edit: Apple have a technical Q&A article (1393) on this very subject which appeared a couple of days back and which I somehow missed.
    It offers this exact method. [Link]