I’ve been playing around with Bayesian filtering and Python.

One of the results is this little Python library which provides a very simple wrapper for the CRM114 Discriminator.

I’ve also written a few additional notes on how to build CRM114 for MacOS X.

Richard Buckle and I moderate a mailing list for Mac, iPhone and iPad developers based in the UK and Europe.

The target audience is a technical one - Cocoa and Carbon programmers writing in Objective-C, C++, Python, Ruby, Java and so on. It isn’t intended as a help group for Mac or iPhone users - there are other resources for that.

Why Another List?

The list isn’t a replacement for Apple’s own lists - and as such it’s generally very low volume. If you have a specific question about Cocoa you’re probably best off posting to Apple’s Cocoa list. Sometimes, though, it’s nice to be able to ask a question of people who you actually know - and of course there are times when the question is specifically relevant to the UK or Europe. We encourage posts about recruitment and the sharing of work - as long as they are relevant and focussed.

How To Subscribe

For more information, to subscribe to the list via the web, or to read the messages without subscribing, go to http://yahoogroups.com/groups/uk-mac-dev/.

Membership to the list is moderated (in other words, we have to approve your membership). This is a mere formality to try to prevent spammers from joining - so please include a sensible comment when you apply for membership.

If you have any problems, please mail uk-mac-dev-owner@yahoogroups.com.

First Posts

The first post that any member makes to the list is subject to approval by the moderators.

Again, this is just to stop spammers from joining the list just to post spam. The down-side of this is that your first message may take a while to turn up, because we have to notice that it is awaiting approval! Once you’ve posted something that is clearly not spam, we’ll switch your address over to unmoderated and hopefully subsequent posts will be faster.

Job Postings

Job postings are fine as long as they are directly relevant and not repeated unreasonably often (in case of doubt, ask uk-mac-dev-owner@yahoogroups.com). If you don’t want to go to the hassle of joining the list just to post a job message, you are welcome to send it to uk-mac-dev-owner@yahoogroups.com and we will post it for you.

Monthly Meeting

We also have a regular monthly meeting in London, at a pub. This is an informal opportunity to gossip, talk shop about Macs and programming, and to drink beer - all without having our non-technical friends and partners sighing, tutting or leaving us in disgust! These days this meeting is officially a NSCoder night, and is organised via the @nscodernightlon twitter account. It’s also advertised on our mailing list and the Cocoa Heads mailing list, so effectively it’s also the London meeting for a number of groups.

History

We set up the list after meeting at an Apple Script kitchen given by Chris Espinosa in Stockley Park about ten years ago. We realised that we’re a relatively rare breed, we enjoyed meeting other like minded folks, and we really ought to try to keep in touch with each other.

Isn’t The UK In Europe By The Way?

Yes it is :)

I stupidly named the list “UK” at the beginning, despite half the people at the Apple Script kitchen being from mainland Europe. I realised my mistake quickly, but the mailing list name has stuck.

Richard Buckle has released a new version of decodecrashlog.

decodecrashlog is an open-source, BSD licensed Python program that can apply a CodeWarrior CFM link map to a Mac OS X crash log from a "release build", recovering the function names and offsets.

John Siracusa’s Tiger review includes a digression about boolean searches, which struck a chord with me.

He says “I think Apple has an insultingly low opinion of users’ ability to understand nested boolean logic. They may not know what it’s called, but the concept is intuitively understood”, and cites a number of Apple’s programs such as Mail and Spotlight which duck this issue by only allowing a single group of tests to be OR-ed or AND-ed, rather than allowing a query that can contain both ANDs and ORs, such as:

(genre is "Anime" or genre is "Game") and my rating is greater than 2 stars

This is something that’s always annoyed me too. Most applications don’t do it, and, I’ve usually found the interface to be pretty poor in the ones that do.

I’ve always thought that the best solution to this problem is to allow the “simple” expressions to be named and saved, and then to allow one simple expression to refer to the results of others. Siracusa actually mentions my approach as a “cumbersome” workaround, but I disagree, I think it’s actually a good pragmatic compromise. In my opinion, the alternative approach of allowing nested expressions and trying to implement an interface which allows them to be edited “in-line” in one big chunk generally ends in tears!

I can see that having to create named sub-clauses is not the fastest interface to use if you want to create a query on the fly, but then I find that any query requiring nested ANDs and ORs is likely to take more than one attempt to get right, and is also likely to be reused, so having an interface that forces you to name the sub-clauses and save them for later is no bad thing.

To illustrate what I mean, imagine a search filter interface which lets the user specify that a rule is true only if either “no test is true”, “any test is true”, or “all tests are true” (in other words, NOT, OR or AND). This is the interface that is provided with programs like Mail, iTunes and Spotlight.

Now imagine that one of the tests that you can specify is that another rule is true. This is the crucial step that is missing from most of Apple’s search interfaces (and lots of others), for no sensible reason that I can see.

The above example would be composed into two sub-clauses:

"Is Anime or Game" if any of the following is true: genre is "Anime" genre is "Game" "Is Good Anime Or Game" if all of the following is true: my rating is greater than 2 stars rule "Is Anime or Game" is true

The advantages of this approach are:

• you have all you need to make arbitrarily complex rules, but at each stage of editing, you only have to deal with one kind of comparison - not, or or and - which can be specified by a pop up menu in a clean way
• there's no nesting, so all the tests can be listed in a vertical list with no indenting or bracketing required
• this approach forces decomposition of a complex problem into simpler steps, which as programmers we know to be a good approach
• by naming and subdividing even relatively simple search clauses, and allowing them to be saved for later, we promote re-use, which turns out to be handy too

For me, just the simple addition of the ability to refer to the result of one rule or filter when defining another would vastly improve the utility of many programs. I’m even quite surprised that Apple hasn’t come up with a reusable interface for this sort of thing. It’s clearly something that would benefit from standardisation (like choosing files does, for example), and it ought to be relatively simple to come up with an API which dealt with displaying, editing, and storing rules whilst allowing application-specific code to be plugged in to implement that actual evaluation of results.

I’ve just noticed an embarrassing error on this site - the software link on the menu bar was doing a search of all blog posts under the software category, instead of linking to the Elegant Chaos Software page as it should have done.

Doh! I’ve fixed it now - apologies for the confusion.