Archives / Search ›

Michael McCracken writes about some great Emacs minor modes, hide/show mode and the Emacs Code Browser. I wish there was some way to collapse everything at once in hide/show mode; I'm still looking for decent automatic folding support in Emacs that doesn't require I reformat my source code. The Emacs Code Browser is really nice: it takes over an entire Emacs frame, parses your code as you type, and adjusts its context to match the file you're working in though it does limit you two edit windows per frame (in Emacs parlance, a window is a pane, and a frame is a window—confused yet?) It essentially does correctly everything Speedbar does wrong, so if you've used Speedbar and been disappointed, give ECB a try.

I had some installation troubles because of the XEmacs 21.5 beta I was using. Make sure you update to beta 9 to get package installation (sort of) working, then install the latest eieio, semantic, speedbar and c-support packages. hs-minor-mode is included in the c-support package (see hideshow.el for some sample key bindings and mode hooks, taking care to fix the 'minro' typos); ECB is not yet packaged. Note that the site-lisp directory is dead. Packages you install (say, the ECB one), put in .../lib/xemacs/site-packages/lisp. Subdirectories of this directory are automatically added to the load-path, and site-packages/lisp/site-start.el works like you'd expect.

FaxJobMgr?

Quick question as I'm trying to troubleshoot this problem: Does anyone else's PowerBook or iBook running Mac OS X 10.2.x take more than a second or so to go to sleep? If so, do you have FaxJobMgr (part of FaxSTF X) running? If you kill FaxJobMgr, does your Mac go to sleep much more quickly? This is what I've observed on my PowerBook, but I'm not sure if it's unique to my configuration.

Every time I create a new, blank post in Archipelago, it publishes a blank entry to my Radio weblog. This undoubtedly causes RSS pollution. This will be my last entry posted from Archipelago until it's fixed, as much as I've enjoyed being able to write weblog entries in a real text editor!

Got Subversion working on OS X again this weekend. Once again, a good fraction of my open-source projects are imported into the repository, which you can now browse “live”. When the Subversion support in ViewCVS settles down, I'll install a copy so anyone can browse past revisions via the Web as well. If you have a Subversion client, you can of course access the repository on a read-only basis. I should be keeping up with the latest Subversion, as I'm now using it to manage code for my research work as well. (That repository is not public.)

There were two causes of the repository corruption I was seeing. One was a bug with concurrent access: Berkeley DB 4.0.14 incorrectly implements mutexes on Mac OS X. Keith Bostic posted a fix, which I've applied. It seems to work well. The eventual solution will be upgrading Subversion to support a current, 4.1.x release of Berkeley DB, which also incorporates the mutex fix. Justin Erenkrantz, an OS X user and Apache/Subversion developer, has some preliminary patches to add 4.1.x support without compromising 4.0.14 compatibility.

The second cause of corruption was ra_local (local filesystem) access to the database files scrambling permissions. The repository access layer in Subversion supports multiple access methods: the two most common and mature are ra_local and ra_dav, the latter making use of WebDAV/DeltaV through the Neon library. ra_pipe, somewhat akin to rsh/ssh access for CVS, is still under development.

Berkeley DB creates logfiles as needed, each of which grows to a set maximum size before another is created. In my oft-executed repository creation script, I was very careful to set the permissions so both myself (as a local client) and remote Web users were able to access the repository. But when the first logfile filled, as I locally modified the repository, a new logfile would be created, owned by myself with permissions limited by my umask. When Apache's mod_dav_svn, running as the www user, later attempted to access the repository and couldn't read the new log file. BDB interpreted this error as indicating database corruption. Subsequent access to the database in any form failed.

Several months ago, I took this corruption warning at face value, especially when combined with the inability of db_recover to help, and simply assumed that BDB and/or Subversion needed further testing on OS X. With repeated attempts, I formalized my Subversion test script and was able to isolate the problem. As usual, it seems obvious in retrospect.

Other activities, such as performing a db_recover to fix the problem, similarly scrambled the permissions, for example removing group access to the BDB database files. The workaround for these problems is to make sure your umask is set permissively before you run a svn or svnadmin command on a local repository. If something goes wrong, as it did many times tonight, the recovery procedure is: reset the permissions on the contents of the repository's db directory, run db_recover to make BDB happy again, check the permissions again, and continue on your way.

It's unclear where, and how, this problem should be fixed. Berkeley DB should better handle permissions problems instead of generating spurious and confusing error messages. Subversion should also provide some mechanism of specifying the umask for database files: relying on the user's umask is quite inappropriate.

Thanks to my always-useful referer listing, I found out about Brian Jepson's Radio Weblog and the book he recently cowrote for O'Reilly, Mac OS X for Unix Geeks. It appears to collect some of the technical, power user-focused documentation that has been largely the realm of folklore, mailing lists and Web sites such as macosxhints.com. I haven't seen the book mentioned elsewhere, but on the basis of the sample Directory Services chapter, I'll be picking up a copy.

If you're still opening Acrobat Reader or Preview.app to view PDFs in OS X, the new PDF Browser Plugin should be your next download. It's tiny (46K), because it just uses OS X's native PDF rendering. It exhibits a few visual anomalies, but appears to be stable and

‹ Newer Posts  •  Older Posts ›