PalmOS

Next up, getting a PalmOS development environment up and running so I can get another old project up and running again.

The most convenient approach looks to be the version here, which packages up PRC-Tools 2.3, PilRC 2.9p10 and the PalmOS SDK V.5. This seems to put the SDK into /opt/palmdev/sdk-5, and the command line tools (m68k-palmos-gcc, m68k-palmos-ld etc) into /usr/local/bin.

The pdbc tools are also useful, so I pulled a copy of v0.9.5 from the PalmGear site. Out of the box, this gave syntax errors on every file I fed it; to get it to work I had to:

• convert the lex and yacc source files to Unix file format
• regenerate from the lex/yacc generated code (which needed chmod +w *)
• rebuild (make)

To test things out, I also needed the Palm OS Emulator and the skins to go with it, from PalmSource (registration needed)

MathML

Hmm. I had a previous project to do some things with MathML, but getting anything visible on Mac OS X seems to be tricky. It doesn't look like Mozilla/Firefox currently has decent support, and Safari shows no signs of support. Even turning to Internet Explorer in desperation, it turns out that the MathPlayer plug-in is Windows-only.

Sigh.

Servlets and Applets

Another project that's lurking on my hard disk involves some Java servlets, so I thought I'd try to get that up and running again. The first stop for information was the page on the subject at developer.apple.com, and the first thing to download is a copy of Tomcat 5.5.9. After installing under /usr/local/jakarta-tomcat-5.5.9 and reading the RUNNING.txt file, the first piece of vital extra information is that JAVA_HOME needs to be /Library/Java/Home.

The more serious problem elucidated in the RUNNING.txt file is that tomcat-5.5.9 needs JRE 5.0 or later to run out of the box.

Pause. Actually, the even more serious problem is that the OS 10.3.9 upgrade has killed Java.

~:java -version
Segmentation fault

<click>.

~:java -version
java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-141.4)
Java HotSpot(TM) Client VM (build 1.4.2-38, mixed mode)

Digression over.

So, returning to the fray the jakarta-tomcat-5.5.9-compat.tar.gz gets untarred into /usr/local, and lo a page appears at port 8080.

Some hints from this page also led me to edit conf/tomcat-users.xml to add the roles admin,manager to allow administrative access, which is helpful for seeing how things are getting on.

Now I just need to get my own code compiled and installed. Adding /usr/local/jakarta-tomcat-5.5.9/common/lib/servlet-api.jar to the CLASSPATH takes care of the first, and the second involves following the instructions at the developer.apple.com page.

10.3.9

Ooh look, an OS upgrade. <click>

Stat none, perl one

Got back from a friend's wedding today, so I've got a bunch of new pictures from the digital camera, which gives me the opportunity to get my scripts for JPG files up and working again. First stop is to use FinkCommander to pull in libjpeg-bin and libjpeg-shlibs (version 6b-16) so that I've got wrjpgcom installed.

The perl part of the scripts Just Works, but there doesn't seem to be a command-line stat command available. Easy enough to convert to a one-line Perl script to hit stat and scalar localtime, though.

Breadcrumb Trail

So this page looks like an excellent place to start (and one which would have been very useful back during my perennial quest for the --work-properly option, and this page also has some useful hints—which seem to point me towards the -dynamic -r options.

Finding the --work-properly option

I once worked on a sequence of projects that involved porting a fair chunk of code between a variety of different Unix variants—Solaris (both x86 and SPARC), IRIX, HP-UX, AIX and Linux. To begin with, we would tend to use the GNU toolchain because it was easily accessible and cheap, but in the end we had to use the native compilers on each system (not least because we were selling the product to the equipment manufacturers themselves, and they seem oddly biased towards their own toolchains).

Now, in general I remain impressed at how easily half a million lines of code did port between these systems. The codebase included some fairly low level code, some hacking in the internals of the X server, and some vexing C++ (this was pre-ANSI C++ by some margin)—and the record for getting it running on a new system was around two weeks.

However, every platform had some kind of gotcha in the toolchain. It would always be a different issue—on one platform it would be template instantiation, on another it would be position-dependent code, on a third it would be allowing dereferencing of a null pointer. In each case, though, it would boil down to a peculiar default behaviour of some tool in the build process—the compiler, the linker, the dynamic loader. In each case, it would also always turn out that there was an option buried in the depths of the man page that would make the tool behave sensibly (where "sensibly" here means to behave like the equivalent tool on the other four platforms).

Thus the legend of the --work-properly option was born.

The legend that whenever cc or ar or ld or ld.so or libdl.so isn't doing what it's supposed to, somewhere there's an option to make it so.

And now, as I try to get another project up and running again, the hunt is on for the --work-properly option for shared library generation.

[Edit: Nic helpfully points out that this page has some good stuff on OS X dylibs]

Escape Meta Alt Control Shift (Command Option)

I'm now playing with copy and paste in the Carbon version of Emacs. Sean Luke's page has some useful functions to get normal Mac copy and paste working—and which are making me lean towards having Alt map to Emacs Meta.

(Of course, this stops alt-3 working as the hash key, but a quick

  (defun mac-insert-hash () 
    "Insert a hash / octothorp character"
    (interactive)
    (insert-char ?# 1))
  (define-key global-map "\M-3" 'mac-insert-hash)

sorts that out.)

Of course, this doesn't work with the arcane (insane?) complexities of X11 selections/clipboards/cut buffers/whatever. Once upon a time I even had to understand all the nonsense in the ICCCM and get it to work with the rest of the known universe, but thankfully all of that has since faded from my brain.

I also figured out the problem with emacsclient—my default path was picking up the version that matched the pre-installed terminal-only Emacs, not the full Mac OS X build. Changing my edit script to use

  /Applications/Emacs.app/Contents/MacOS/bin/emacsclient --no-wait $*

sorts that out. I got a bit confused in the process of sorting this out, because it looks like the emacsserver stuff doesn't run as a separate process (at least, nothing other than the main Emacs program shows up in ps).

More lost keys

First up today, some minor tweaks to my .emacs file. Moving to the beginning and end of the buffer isn't working with my normal Ctrl-Home and Ctrl-End (or rather Ctrl-Fn-Left and Ctrl-Fn-Right) bindings, and a quick Ctrl-H, K (also known as describe-key) reveals that keys are coming in as <kp-home> and <kp-end>

  (define-key global-map [C-kp-home] 'beginning-of-buffer)
  (define-key global-map [C-kp-end]  'end-of-buffer)

Next is to set up some sort of delete-right key, because I'm used to having both a backspace and a delete key on my other keyboards. Again, Ctrl-H, K reveals that the raw backspace key is giving <backspace>, and Fn-backspace is giving <kp-delete>, so in goes:

  (define-key global-map [kp-delete] 'delete-char)

At the moment, I'm still not sure whether I'm going to want the Apple/command key or the Alt key as the Emacs meta key, so I'm still bouncing between (setq mac-command-key-is-meta 't) and (setq mac-command-key-is-meta nil).

Finally for today's keyboard tweaking, I need a way of switching between insert and overwrite mode—you know, the thing which that handy key labelled "Insert" does. For the moment, I'm going to hijack the key just to the right of the right-hand command key, which Emacs tells me is <kp-enter>:

  (define-key global-map [kp-enter] 'overwrite-mode)

Now I need a way of putting all of this stuff inside a conditional, so that I can use the same .emacs across all my different machines. Looks like system-configuration is the right thing to look at—on the Powerbook it's coming out as "powerpc-apple-darwin7.4.0" (whereas my Linux box gives "i386-redhat-linux-gnu"). So

  (setq on-mac (string-match "powerpc-apple" system-configuration))

seems to do the trick.

Should Just Work™

Worked on getting a few more of my old projects up and running. The xytools 2.4.5 plotting utilities from James Theiler (that I've been using for 10 years now) just compiled and worked, as did the Saxon XSLT processor (since it's in the form of a Java jar file and the Powerbook comes with Java support) that I've used for the odd XML experiment.

These aren't the permissions you're looking for

A little more tweaking of the setup; I'm used to using the F-keys to do various things in Emacs, so I changed the default configuration (where they adjust volume, brightness etc) to need the Fn key to be pressed too (System Preferences, Keyboard, check "Use the F1-F12 keys for custom actions"). I also tweaked the Exposé settings to just do things with F11 and F12 (not F9-F11), and to add the top-right and bottom-right mouse corners as triggers too. (System Preferences, Exposé )

I've also been going through the files I transferred across from my Linux box and correcting the permissions. Because I did the transfer via a USB drive, basically everything ended up with mode -rwxrwxrwx, so I needed to get rid of the execute bit on regular files that weren't scripts, and to get rid of write permission on any RCS/*,v files and their corresponding workfiles.

This isn't that exciting, except that it revealed a feature of the filesystem that I hadn't realized—there's an extra layer of permissioning on top of the normal Unix modes. Even as root (which I enabled via Applications, Utilities, NetInfo Manager, Security, Enable Root User) I'd get:

  % chmod -x file
  chmod: file: operation not permitted

This is because the file has been locked, which is visible (and alterable) in the Finder file Info window. The chflags uchg file and chflags nouchg file commands lock and unlock files from the command line respectively. I've still no idea why some (and there seemed no pattern as to which) of the transferred files ended up locked but most didn't.

Standards are great; there's so many of them to choose from

Ah, the joys of media formats. The QuickTime client included with MacOSX doesn't cover all of the panoply of different video formats I seem to have lying around on my disk (some of which are admittedly of, er, dubious provenance) so I've had a frenzy of installing different video clients:

• Windows Media Player v9.0.0
• VLC 0.8.1
• MPlayerOSX version 2.0b9r4
• 3ivx D4 v4.5.1 codecs
• DivX 5.2.1 codec