Another creator pattern for clusters

September 15th, 2011

This is about Cocoa, and in particular about class clusters. The problem I wanted to solve was having a class cluster with easily extendable hierarchy without too much interdependency. In my case, I want to create a number of different UITableViewCell descendants, depending on the particular data element the cell should handle. If the data element has a field “string value”, then a UITableViewCell with a text field for such a string value should be created. If the data element has a field “check” representing a yes/no answer, then a UITableViewCell with a yes/no functionality widget should be created instead, and so on. In total, I have less than ten different kinds of UITableViewCell derived classes, but they could become more at any time.

Read the rest of this post »

Dr Dobbs circling the drain

March 17th, 2011

I’ve subscribed to Dr Dobbs journal off and on for decades, probably for ten to 15 years in total. Wherever I turn in this house, I encounter stacks of old issues of DDJ, even though I’ve thrown away quite a number. A couple of years ago I stopped subscribing, since the main focus of DDJ was drifting away from my main focus, or vice versa, or both. Since Microsoft started buying up all the people central to the C++ evolution, then riddling their version of it with proprietary “extensions” (or rather limitations), that language has become more and more of a dead end and both I, and DDJ moved away from it. But during the years, I’ve often read parts of DDJ on the web and I do get the “Dr Dobbs Update” through email every now and then. The most recent arrived two days ago and had the weirdest “Editor’s Note” ever, at least as far as one would expect from DDJ.

Read the rest of this post »

Death of medical articles?

February 2nd, 2011

Check out this article on “Improbable Research”. In short, it’s an application that can take raw data and write an article around it. Personally, I think it’s a good thing if the result is more objective and complete than most journalistic writing we see today. Can’t be less researched, at least.

But it also goes to show the opposite, which has a bearing on medical publications. In medicine, we have a huge problem with the sheer amount of articles published. If you want to find out the state of art in some particular disease or treatment, you have to collect a number of articles, skim through them, try to get at the original data that was used (very hard) and make up your mind. There’s not much guarantee of objectivity in selection or interpretation of the articles, and very little objective data on how reliable the articles are. If you can find a (reliable) meta study, it’s easier.

If a machine can produce medical articles based on study data, and those articles look like the real thing, this proves that the prose in the article is not a real value add. In other words, nothing in the text adds information beyond what the raw data already contains. And if it does, it’s probably misleading and wrong, anyway.

In conclusion, this only goes to show that what we need is more studies and less articles. What we need is immediate access to the raw data of all relevant studies and a desktop application that lets us view and manipulate the total of that data according to our needs, without going through the complications of reading articles and reverse-engineer the texts down to the objective facts hiding behind them.

Maybe this heralds the death of medical publishing as it looks today, and if so, good riddance.

Netbooting on OSX SL Server

January 13th, 2011

Once I got tftp working on IPv4, I still couldn’t get the Macbook client to download the boot or image files. Wireshark showed that the client didn’t get any file when it sent “acknowledge data block 0″. Nothing. So I installed tftp-hpa from Macports, hoping that would solve my problem, which it didn’t. But a few tips on that:

Install tftp-hpa using the “server” variant like so:

sudo port install tftp-hpa +server

Then go into the preference file (which isn’t in the same place as most plist files):

sudo pico /Library/LaunchDaemons/org.macports.tftpd.plist

…and remove the “-s” command line parameter, while changing the path to “/private/tftpboot/”. The “-s” parameter forced a chroot which won’t allow tftp to follow symlinks outside the given path, making netbooting impossible.

Then, and this is the crucial step, change the block size to max 512 by adding the “-B” option with the value “512″. What seemed to be happening in my installation is that the client requested a block size of 8192, the server approved it, and things just stopped working. Probably something to do with the switches I have, but crimping it to 512 fixed the problem. Of course, if you’re doing netbooting on a regular basis, or run diskless workstations, 512 may be intolerably slow, so then it could be worth experimenting with higher values.

I ended up with a plist file for tftp-hpa looking like this:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
<plist version='1.0'>
<dict>
<key>Label</key><string>org.macports.tftpd</string>
<key>ProgramArguments</key>
<array>
        <string>/opt/local/bin/daemondo</string>
        <string>--label=tftpd</string>
        <string>--start-cmd</string>
        <string>/opt/local/sbin/tftpd</string>
        <string>-B</string>
        <string>512</string>
        <string>-L</string>
        <string>/private/tftpboot/</string>
        <string>;</string>
        <string>--pid=exec</string>
</array>
<key>Debug</key><false/>
<key>Disabled</key><true/>
<key>OnDemand</key><false/>
</dict>
</plist>

After modifying the file, stop and restart tftp-hpa by:

sudo launchctl unload /Library/LaunchDaemons/org.macports.tftpd.plist
sudo launchctl load -F /Library/LaunchDaemons/org.macports.tftpd.plist

It’s entirely possible I never needed to switch tftp servers from the default to tftp-hpa, but now I did, I don’t know if I’ve got the courage to switch back to try the original. Checking the man pages for the original tftpd server, I can find no setting for max block-size, so maybe tftp-hpa is necessary after all, just to be able to crimp the blocks enough.

OSX SL tftp doesn’t work?

January 12th, 2011

…then this may be the reason… took me hours to figure out. Had to get it going for a netboot project, and the netboot just kept circling around the boot image download without getting much anywhere. First, check out Bombich’s troubleshooting, which put me on the right track without actually giving me the solution, but maybe that’s because my particular problem is relatively new. It may have been introduced with Snow Leopard.

What happened in my case is that I was able to download an image using the form:

tftp myserver.local
get NetBoot/NetBootSP0/Netinstall.nbi/i386/booter

…but not using the form:

tftp 172.25.26.27
get NetBoot/NetBootSP0/Netinstall.nbi/i386/booter

even though the “myserver.local” name pointed to the IP 172.25.26.27. At least, that’s what I presumed until I whipped out Wireshark and found out that using the “myserver.local” name resolved to an IPv6 address, not the IPv4 address I expected.

Next, I ran this on the server:

sudo lsof -i :69

COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
launchd   1 root  144u  IPv6 0x0a9ab4a0      0t0  UDP *:tftp

Aha! The tftp server only runs IPv6 for some reason. That explains it.

To fix this, go into the tftp.plist file with pico:

sudo pico /System/Library/LaunchDeamons/tftp.plist

and add the optional key for IPv4 a bit down:

...
<key>Sockets</key>
<dict>
    <key>Listeners</key>
    <dict>
        <key>SockServiceName</key>
        <string>tftp</string>
        <key>SockType</key>
        <string>dgram</string>
        <key>SockFamily</key>
        <string>IPv4</string>
    </dict>
</dict>
...

After that, all you need to do is stop and restart tftp:

sudo launchctl unload /System/Library/LaunchDaemons/tftp.plist
sudo launchctl load -w /System/Library/LaunchDaemons/tftp.plist

Then check that the port is working on IPv4 as well:

COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
launchd   1 root  144u  IPv6 0x0a9ab4a0      0t0  UDP *:tftp
launchd   1 root  150u  IPv4 0x07e2ee14      0t0  UDP *:tftp

After that, retry the tftp get command using both IPv4 and “myserver.local” addressing. Should work now. I must admit I don’t understand why IPv6 keeps working, though. Oh well, not that it bothers me, but it bothers me a little bit.

Update: this post is correct, but it still didn’t solve my problem, so please see next blog post for more, at least if you’re doing netboot stuff on Snow Leopard

Don’t trust iTunes gift cards

December 23rd, 2010

This is what happened to me. I gave a friend $300 to buy gift cards for iTunes, and he got me six $50 cards in the Woodlands Best Buy store in Texas. This was in november 2009. Me and a relative redeemed three of these cards during the following months, but I only got around to redeeming the last three in september 2010. When I did, they didn’t work. The error I got was that these codes did not exist.

Read the rest of this post »

The first thing you should do on a new Mac

December 21st, 2010

The very first thing you should always do on your new Mac is to make sure you run as non-admin. This protects you against most malware out on the net, since it makes it very difficult to install anything without you knowing about it. It doesn’t exclude it entirely, but it makes a major difference.

Read the rest of this post »

Macport and mono

December 19th, 2010

Just a heads-up: Macport quit working on my machine. Link errors, missing architecture in sqllite3 dynamic libs or something. After much agonizing, I began to suspect mono, especially since the sqllite3 library port wanted to link against was in the mono path. There’s a shell script in mono called uninstallMono.sh that does a fine job of getting rid of it. Run that, and things work fine again.

I’m guessing the mono libraries are simply put in too early in paths, which may cause the problem, but since I’ve got actual work to do, I’ll just roll my eyes and get on with life.

Update: the above did solve most of my problems, but not all. After perusing more forums than I’d like to peruse, I hit on a remark from one of the Macport developers that you should always reinstall the entire Macport system after every major OSX upgrade. In other words, I installed my Macport under Leopard, then upgraded to Snow Leopard, so it got unhinged. The solution is to entirely remove the /opt/local directory contents, then reinstall Macport from source. Personally, I find it a little bit scary (like, is Macport really the only system using opt/local?) so I tarballed the directory first, just in case. But I don’t think that is necessary, but time will tell.

Anyway, after reinstalling Macport this way, the rest seems to have straightened itself out.

Lecture

December 11th, 2010

I was invited to give a lecture to the International Masters Programme in Health Informatics at Karolinska Institute, and we recorded a video of the entire lecture, in total around 3.5 hours. The last part is about iotaMed, our open source project for a “new and improved” electronic health care record, which is knowledge support, medical record, and national registries all rolled into one.

The rest of the lecture is about a lot of different things I have opinions about, and as there is no lack of things I feel strongly about, it went almost an hour longer than it should have.

The full lecture consists of 12 chapters (“parts”), each 1-4 video segments (YouTube limits videos to max 15 minutes, and that makes for a lot of dividing of videos). You can find the lecture notes here. Oh, by the way, the site for the iotaMed project is here. The playlist with all 20 videos is on YouTube here.

If all else fails, try Preview

November 25th, 2010

I’m totally amazed at all the things Preview does in OSX Snow Leopard. I already use it for knocking out backgrounds, using the “Instant Alpha” tool in the “Select” dropdown. But what happened today is more interesting.

To my everlasting regret I got me a Canon Lide 60 scanner a couple of years ago. Canon’s hardware is pretty nice, but their driver support stinks, especially for OSX. This scanner costs me on average much more work than it should to keep going. Same for my Pixma 5200 Canon printer, by the way. Awful.

Anyway, I needed to scan a page from a mag to show on a slide. Hooked up the scanner, tried Canon Toolbox, and sure enough “Failed to open driver”. Internet next, user groups, downloads, complicated shit about uninstalling, reinstalling, rebooting the Mac Pro ten times. No joy. After a few hours (!) of this, I got an inspiration: hey, since I saw “Twain” mentioned, maybe Acrobat Pro 9 (CS4) could import it, instead of using Canon Toolbox? Sure enough, Acrobat found the scanner, looked it over, and promptly crashed.

And then I got my second inspiration: check out OSX Preview. And yes, that one worked. Not only that, but it automatically calibrated the scanner, proceeded to analyze the page, divided it into sections, scanned it, and served it up already partitioned into useful chunks. See the screenshots below. All the time I was just sitting there watching, doing nothing. The only thing I had to do was select the image and hit cmd-R twice to turn it the right way up.

Jeez, that innocent looking little Preview app is becoming mighty useful for any number of things.

I probably should mention that the driver I installed came in a file called “lide60osx11131en.dmg” to be found, somehow, on Canon’s support site. It installs both the drivers and the toolbox, but the toolbox doesn’t work.