iSync: so good, yet so bad

The multi-modal synchronization iSync makes possible is a terrific idea. I have lots of mobile devices: my Palm, my hiptop, my PowerBook and my iPod. When it works, iSync keeps them all talking and with a consistent world view, which has saved me from missing many appointments and given me the information I need when I need it.

When it doesn’t work, I am at the mercy of a horrendously buggy implementation. I get meaningless conflict messages, impenetrable and programmer-centric errors, repeated duplication of items, and more. iSync has done far worse things, including getting itself to the point it crashes when it tries to do anything, or deleting all my address book entries without warning. iSync is slow, a huge CPU and memory hog, especially when compared to the Palm Desktop conduits, which have quietly and efficiently done their jobs for years.

All in all, not what I expect from Apple. Fixing the problems, which occur at least once a week, requires me to think like a programmer, which is just wrong. I’d never ever give the current version to my parents because I’m sure they’d run screaming.

The most annoying problem I have every few days (losing all the departments in my address book) I can at least identify because of the dialog box that appears. I blame it on a third-party conduit, but these kinds of errors are entirely Apple’s fault:

Another broken conflict message in iSync
The connection between these events is…? Also, the event on the right is in a subscribed calendar, i.e. something I can’t edit in iCal. iSync shouldn’t be trying to sync those at all! Finally, what the hell is a “’cluster’ UID”? (See above, about impenetrable and programmer-centric errors.)

One broken conflict message in iSync
The difference between these is…?

If I had just one request for Mac OS X 10.4, it would be: fix iSync. Better yet, open it up so anyone can add devices or applications, as having a bunch of developers pound on its interfaces can help flush out the problems. I wish it would happen in 10.3.5 or a separate iSync update, but that’s pretty remote at this point.

National SR-W10NA 5 Cup Keep Warm Rice-O-Mat Rice Cooker
In completely unrelated news, Steve and I bought a rice cooker tonight (well, Steve bought it and paid for it while I watched). I really have no idea why we didn’t get one months ago; it’s just so useful.

MacUser UK online

MacUser UK is considering a worldwide version for electronic distribution. It’s the only mainstream Mac publication I read any more, assuming you don’t count MWJ, and I’d happily pay for it. I hope it kicks US Macworld et al. into being more relevant. (I let my Macworld subscription lapse several years ago, and haven’t seen anything on their Web site in the meantime that makes me think they’ve improved much.)

Shell redirection pain

I’m still learning more about zsh every week, trying to solve various problems and improve my productivity using its many features. Of course, it doesn’t hurt to show off from time to time either. :-)

Here’s a seemingly simple thing that’s stumped me tonight: how to display stdout from a process as it’s generated, and pipe it to another program at the same time. The MULTIOS feature makes this simple if it were two files, but it isn’t. The closest I could get, which admittedly isn’t very close, is foo >&2 | bar, but that waits until foo finishes before displaying anything, in a way it doesn’t if the | bar is missing.

In actuality, bar is the bbedit tool—I’m wanting to open the results in a BBEdit window if foo successfully finishes. The ideal tool for this would be BBEdit’s shell worksheet, but it also waits until foo has finished before displaying any output.

Update: Duh, I’ve seen and solved this problem before. foo is actually a Python script, and something in Python or the C library’s standard I/O routines thought I was redirecting to something that wasn’t a terminal, therefore it should be more efficient about flushing. Adding a strategically placed instance of sys.stdout.flush() caused the above incantation to work fine.

RSS feed fixed; Trac 0.7; Frontier open-sourcing; TWAIN SANE

Apologies to anyone who’s been getting parse errors from their newsreader trying to read my RSS feed; the PyDS upstream information Metakit database upstream.data is getting corrupted, and I can’t figure out why. Neither can PyDS author Georg Bauer or Metakit author Jean-Claude Wippler, and I’m kind of the unofficial maintainer for the Metakit Python bindings these days, so…

In other weblog administrivia, I did finally hook up the search box at right; it searches only the contents of my entries, so it should be pretty easy to use. One of these days I will figure out how to import my Radio weblog, comments and all, and redirect http://web.sabi.net/log to here. I did email the LiveJournal folks to update my feed URL, so all two of you who subscribe here, enjoy.

Trac 0.7 was released this week. As I’ve mentioned before, Trac is a great tool for small projects to use for documentation, bug management and source browsing. I’m now using it for svn.sabi.net and three projects at work (private site). The new version adds syntax coloring, a much improved source browser, and email notifications among other major features. I continue to be impressed with the quality of Trac, as well as the competence, friendliness and good humor of the folks at Edgewall. You’ll find a few of my patches in Trac 0.7, as well.

I can’t let the open-sourcing of Frontier go by without a comment, so here it is: Next to Smalltalk, Frontier has been the most productive coding environment I’ve ever used. I’d still be using Radio if it weren’t for the Frontier kernel’s instability and CPU usage on OS X. I don’t imagine I’ll have that much time to work on it, but I hope the people who do, understand what makes Frontier unique, and in time, I can start using it again. The last thing we need is yet another Python clone.

Some people suggested dumping the ODB system and switching to filesystem hosted resources—please no! You think OS X’s switching away from resources to bundles is bad? Try that with several orders of magnitude more objects.

Wes writes, “The ODB is great, but it has its problems, like how putting code in the ODB kills integration with external version control systems.” Indeed, there was never any ODB-version control integration, but with the ODB’s strictly hierarchical design, it’d be even simpler than a version control system like ENVY or StORE for VisualWorks; perhaps even easier to use a DLL interface to Subversion instead of a relational database.

The TWAIN SANE Interface is terrific at resurrecting old scanners with no OS X drivers. After fixing some SCSI problems, I got ACM’s old scanner working with a Power Mac G4; it just works, with a minimal but very functional user interface, and zero setup required.

appswitch 1.0.1 and OS X speed improvements

appswitch 1.0.1 is out; the primary improvement involves a crashing bug I found and fixed about a month ago.

Part of appswitch’s README justifies its use by the speed advantage over alternate OS X command-line methods for bringing an application to the front. My timings were based on OS X 10.2.4, as of February 2003. I redid the same timings in OS X 10.3.3, adding my launch program, with the following results. Times are in seconds, as measured with time(1):

                  Mac OS X 10.2.4 10.3.3 appswitch -a Emacs             0.355  0.054 appswitch -i com.gnu.Emacs         0.381  0.063 launch -a Emacs               n/a   0.085 open -a Emacs                0.842  0.876 osascript -e 'tell app "Emacs" to activate' 2.361  0.949 

First, everything except open is a lot faster under Panther, especially appswitch and launch (for which I made essentially no code changes). AppleScript compilation and/or execution speed also improved dramatically, which is good to see.

Second, I’m surprised the huge performance gap between launch and open still exists. launch links to CoreFoundation, ApplicationServices, Carbon and Security frameworks; open to Cocoa. The tasks they perform are essentially equivalent, and I imagine call through to the same underlying APIs. This makes my original, somewhat arbitrary, choice to implement launch without using Cocoa a lot more defensible than it once was.

Some examples of how I use appswitch, from my ~/.zshrc.

Augmenting emacsclient to bring Emacs to the front:

  if [[ ! -z $TERM_PROGRAM ]] {   e() {    ( emacsclient -n $@ >&/dev/null && \     appswitch -a Emacs ) || \    ( launch -ba Emacs && \     until { emacsclient -n $@ >&/dev/null } do sleep 1; done;     appswitch -a Emacs )    export EDITOR=emacsclient   }   BROWSER='launch'  } elif [[ ! -z $DISPLAY ]] {   e() {    ( gnuclient -q $@ >&/dev/null ) || \    ( xemacs -f gnuserv-start $@ & )   }  } else {   alias emacs="/usr/bin/emacs -nw"   alias e=emacs  } 

Testing for a local X server before trying to enable SSH X forwarding:

 ssh() {  check_agent  # appswitch takes about 0.2 seconds to run, so don't check  # unless we're reasonably sure we have an X server running  if [[ -z $DISPLAY && -S /tmp/.X11-unix/X0 ]] && appswitch -Pi com.apple.x11 >& /dev/null; then   DISPLAY=':0.0' =ssh $@  else   =ssh $@  fi  chpwd } 

HTML problem solved; Cisco VPN client ranting

Discovered the solution to the HTML-escaping problem I reported in my last post: it turns out PyDS’s MetaWeblog API implementation attempts to be “smart” and render as reStructuredText unless the post starts with a <. Guess what I started this post with? :-)

In someone’s infinite wisdom, the Siebel Center provides one Ethernet port per desk for graduate students. We’re all supposed to use wireless for our laptops—which requires a VPN, because one of the available non-VPN wireless networks is for faculty and staff only, and the other doesn’t support AirPort cards. So I have to use the excellent *cough* Cisco VPN3000 client, which slowly breaks over repeated connections until the following dance is required to get it to connect.

 % vpnclient connect DCSnet-wireless *** malloc_zone_malloc[18118]: argument too large: 3269996800 malloc: Cannot allocate memory % sudo kextunload -b com.cisco.driver.vpn Password: kextunload: unload id com.cisco.driver.vpn succeeded (any personalities also unloaded) % sudo kextload /System/Library/Extensions/CiscoVPN.kext kextload: notice: extension /System/Library/Extensions/CiscoVPN.kext has debug properties set kextload: /System/Library/Extensions/CiscoVPN.kext loaded successfully % vpnclient connect DCSnet-wireless fread: Unknown error: 0 Cannot secure command line arguments. % sudo vpnclient connect DCSnet-wireless Cisco Systems VPN Client Version 4.0.2 (C) […] 

Eventually, not even unloading and reloading the KEXT and running vpnclient as root fixes the problem, and I have to reboot. That usually takes about a week. I guess that qualifies as an improvement over the VPN5000 client, which would cause repeated kernel panics. Of course, OpenVPN’s kernel component doesn’t crash at all, it works wonderfully, requires next to no setup, and I never have to touch it. The coming 2.0 version will make it possible for multiple users to connect, so it’ll be useful as more than a “personal” or permanent VPN connection.

You know, it sometimes helps if people test their software to see if it breaks over, oh, I dunno, 20 or 30 uses.

Testing PyDS 0.7.2

Finally upgraded PyDS to 0.7.2; so far, nothing has broken. From the PyDS-Dev list I had been led to believe I’d have to redo all my templates. So far, so good; here goes a publish…

Looks like PyDS no longer likes me disabling the TopicExchange or Aggregator tools; when I try to publish, I get:

Background thread exception NameMapper.NotFound: aggregatorException instance __dict__: {’args’: (’aggregator’,)} /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/Tool.py[1300] in thunk /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/AggregatorTool.py[432] in _initthread /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/AggregatorTool.py[1751] in renderFeedList /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/Tool.py[760] in renderPage [49] in respond

and

Background thread exception NameMapper.NotFound: topicexchangeException instance __dict__: {’args’: (’topicexchange’,)} /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/Tool.py[1300] in thunk /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/WeblogTool.py[131] in _initthread /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/WeblogTool.py[1076] in renderTimeframeOnline /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyDS/Tool.py[760] in renderPage [104] in respond

It also seems that PyDS is escaping my embedded HTML tags, or I would have put <pre> around the above. Weird.

Since I now have a decent weblog editor, and the semester is over tomorrow, I’ll start posting a bit more.

Time passes…

Over two months since my last post. Wow. I’ve got a few minutes now, listening to back-to-back James McMurtry songs (incidentally, “Where’d You Hide the Body” was the first music I purchased on the iTunes Music Store) on radioio and relaxing before I head out again.

I spent last weekend in St. Louis, Saturday at a Kuk Sool Won tournament and Sunday with Robb Beal. You can see a picture of me with Robb’s two foxhounds on his weblog. If I look a bit harried, it’s because what you don’t see are the 8 pictures where we couldn’t get the dogs to stand still. :-)

My research continues to go really well, and I should be submitting my current work to next year’s CGO. Of course, I have to finish the work and write the paper first! The Siebel Center had its dedication this weekend, and seeing everything appear at the last minute was rather incredible. Now if they could only get rid of the smell of burning plastic from the elevators…

Still no time to work on F-Script Anywhere, ICeCoffEE or Pester. I’m planning on getting out of being a volunteer sysadmin for the local ACM student chapter over the summer, which should free up some time. I’ve started going ice skating on Friday evenings; it’s been over ten years since I had skated regularly, and it’s a wonderful way to spend two hours not worrying about life’s pressures. Also cheap, at $1 for skate rental (my skates are still in storage in New Hampshire) and otherwise free for U of I students.

Some software I’ve used recently and truly enjoyed:

Trac is great for organizing small projects; I’m using it on svn.sabi.net (publicly) as well as on a G4 Cube I set up at the med school (privately). One of these days I hope to set it up for research, too; currently we’re still on CVS and I’m hating it.

Colloquy is the first graphical IRC client since MacIRC I will use. I spent a few hours last weekend contributing a few fixes to Colloquy; it now pretty much does what I want, and works well with the irssi proxy. I’d like the scrollback to be refreshed through the proxy like cognetd does, but it can wait…

Both Trac’s and Colloquy’s authors care a lot about usability and limiting complexity, which is such a rarity in open-source development that I need to mention it.

Unison lets me synchronize my files across platforms between my PowerBook and research machines, easily exclude files, and generally does what I mean. I use the console UI, but it’s also got a reasonably decent GTK UI.

Dovecot, from the author of irssi, has allowed me to switch my uiuc.edu mail to IMAP without losing fast, local access with Mutt. It’s very much a “set it and forget it” server; it just works.

Glen Low’s Mac OS X port of graphviz is responsible for some of my productivity in research recently; between the amazing-quality Quartz PDF output, improving user interface, Glen’s responsiveness to feature suggestions, and the excellent use of OS X 10.3’s kqueue to automatically rerender modified documents, it is wonderful. When it misrotated some pages last night, I wrote a quick Python script last night to rotate its output PDFs, using the great (though underdocumented) Quartz Python bindings. Almost my entire new research group has PowerBooks, so it’s no problem giving this stuff to them to run.

My next project at the College of Medicine is an event scheduling system, for which I evaluated many Python Web frameworks. I will need to build a form construction toolkit for users, so they can design their own survey forms to give to attendees. The projects that made the most sense to me were Quixote and Nevow. In evaluating Quixote, I discovered the authors of Quixote don’t seem to care too much for presentational aspects of the Web. When I mentioned Nevow on #macpython, I discovered its author, Donovan Preston, was answering my questions. Can’t beat that for support; so, tentatively, I’ll be going with Nevow.

Saw that Wes just finished Altered Carbon; I borrowed Steve’s copy and read it while sick last year. It was enjoyable, and I see Steve has his next book Broken Angels sitting on his bookshelf; when I get sick next I might find myself with enough free time to read it! Steve has been even busier than me recently, what with three very hard classes and working half-time.