njr 3.0

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:

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.)

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.

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.

11:48 PM | PyCS
No Comments

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.)

8:40 PM | PyCS
No Comments

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.

12:52 AM | PyCS
No Comments

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.

12:32 AM | PyCS
No Comments

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
}

1:38 AM | PyCS
No Comments