Urania

I decided I should clean up my laptop’s left over digital crap, so I went through my /usr/local directories cleaning out ancient libraries installed two OSes ago (after making a backup first). I decided I would try reinstalling MacPorts under Leopard, if only to build it clean and remove the old source code siting around from various revisions to the packages over time.First, I installed MacPorts from the disk image for Leopard. Then I attempted to install my usual suspects: sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem Long story short, almost everything works but there were a few key packages that failed to build under MacOS X 10.5.1. This also reminded me that when a package fails to build, you should “port clean” the package (see examples below) before attempting to rebuild it:

• I discovered that teTeX failed to build. This appears to be due to an undeclared dependancy on openmotif. So after the failed install, I just did ansudo port clean --work teTeX; sudo port install openmotif teTeXand teTeX installed just fine.
• In attempting to build subversion I discovered that one of the packages subversion needs, sqlite3, fails to install on Leopard. This appears to be due to an undeclared dependancy on nawk (MacPorts Report Ticket #13500). So again, all I had to do was:sudo port clean --work sqlite3; sudo port install nawk subversionand it worked. I should note that a fairly recent version of subversion now comes with Leopard, version 1.4.4 (as opposed to 1.4.5 with MacPorts).
• gv fails to install unless you patch it. This was reported to MacPorts (Bug Report Ticket #13095). [If you check that bug ticket, you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.]
• osxutils fails almost immediately with a series of errors about conflicting types. Since osxutils did a lot of meta-data manipulation, I am not completely surprised it is broken under Leopard. I have submitted a bug report to MacPorts.
• xterm fails to build. This is irritating because I haven’t had time to confirm is the old xterm Tektronix emulation bug present in the Tiger version of xterm is still present. [This appears to have been cleared up with MacPorts 1.6 if you install Xquartz over the Apple installed X11 server. Doing this is a good idea anyway.]
• wine fails to build (already reported elsewhere). This has already been reported in MacPorts Bug Report Ticket #13488. I wonder if this is related to the possibility being mentioned of Leopard having unreported support for Windows binary execution. [Wine version 0.9.51 DOES compile under Leopard just fine.]
• I can’t build g95 because odcctools fails to compile. This has been reported in MacPorts Bug Report Ticket #13148. [This appears to have been fixed as of January 24, 2008.]
• xephem fails to build because lesstif builds but fails to install. Actually lesstif installed fine once I moved /usr/share/aclocal/ac_find_motif.m4 out of the way. I don’t know if that file was there from my previous install of lesstif. Once lesstif was out of the way, xephem failed to build. Interestingly, MacPorts has version 3.7, I downloaded the source for xephem 3.7.2 from the Clear Sky Institute website, compiled it following the installation instructions without a hitch. I submitted a bug report as MacPorts Bug Report Ticket #13524 (turned out my bug report was a duplicate of MacPorts Bug Report Ticket #13498). This has been fixed, see this post. [This appears to have been fixed as of March 3, 2008.]

I’m actually surprised the number of packages that failed to compile seems pretty small.

So this weekend I decided to take advantage of the long weekend and between bites of turkey with the family, I decided to upgrade my laptop to Leopard (MacOS 10.5). I had been reading about the various issues with Leopard before the upgrade, so among the things I did in anticipation of Leopard was

• I uninstalled Unsanity’s Application Enhancer.
• I removed X11.app from my automatic launch items in the Accounts Preferences Pane Login Items. X11 is extensively refreshed under MacOS 10.5, so you don’t want to autolaunch X11.app any more.
• I upgraded Cisco’s VPN software to the latest version distributed by my campus (you want Cisco VPN Client 4.9.01 (0090)).
• I did a quick search of the various applications I run and looked for “Leopard” upgrades via MacUpdate.
• Finally, I researched the incompatibility of Adobe Acrobat with MacOS X 10.5. I discovered that while the AdobePDF printer driver broken under the new OS, you can use Apple’s built in PDF capability (specifically “Save as PDF-X”) capability to create the PDF, which can then import and edit just fine in Acrobat.

Having done all that, I decided to bite the bullet and install the upgrade. First thing I did was back up the entire internal drive to an external drive (which I had formatted with Disk Utility to make sure it was capable of booting an Intel Mac) using Carbon Copy Cloner. Once the drive was cloned, I ignored the overhyped warnings from MacFixIt.com (who I won’t link to, because they were bought out, they definitely sold out as a source of accurate help) and instead followed the Apple recommended procedure of just doing an upgrade to my previous Tiger installation. I figured if worst came to worse, I would recover from the backup drive (in my mind, the backup is the critical step, not how you choose to upgrade). So approximately 80 minutes later my laptop finished its upgrade and rebooted. Some notes on my initial issues with the new OS.

• The new dock doesn’t bug me as much as some (John Siracusa does the best analysis of the problems with the new Dock in his extensive ArsTechnica review of Leopard), but maybe its because I thought the old dock was broken enough as a launcher that I use QuickSilver instead (which works fine under Leopard).
• Leopard finally handles virtual memory use nicely, removing old files in the /var/vm directory once the memory has been released.
• I don’t like the translucent menubar, but there exist various free applications to get rid of those and the changed dock.
• The new OS nuked all my installed printers. Not a huge deal, but I have to re-install all my printers again. I kind of understand why this might of happened, but it was a pain.
• I had to use Disk Utility to Repair Permissions before my Widgets behaved properly, but now, they actually seem to run better than before (less delay in accessing them).
• I patched IDL to version 6.4.1, seems to work now.
• I knew from Ben Bayer’s (Apple’s X11 guy) postings on the matter that
  

  Biggest architectural change in Leopard for X11: Switched from XFree86 codebase (based on, IIRC, X11R6.8) to X.org codebase (X11R7.2)

  Biggest user-visible change: launchd support for X11. The only situation where you should need to manually start X11.app is if you are only running remote X11 applications.

  The way that this is accomplished is by some slight-of-hand with the $DISPLAY variable — if you look, it should be something like “/tmp/ launch-vbXRyu/:0″. If an X client connects to this, it will actually connect to launchd, which will start Xquartz if needed and pass the client’s socket to the server.

  All of that should be invisible to you; the X client library (libX11.dylib) was modified to support this, and all X11 applications link against this library. “DISPLAY=:0″ would still work if X11.app is already running, but it will not trigger X11 to launch.

  So in other words, we are not supposed to set the shell environmental variable DISPLAY to “:0″. Well, I removed all the times I set it from .tcshrc, .bashrc, .login, etc and it still remained stubbornly set until I remembered trying to get Carbon Emacs working a few months back required my setting environmental variables to my entire session using the ~/.MacOSX/environment.plist file. I opened it, removed the DISPLAY variable from the list of those set for the entire session, and viola. Almost everything worked as advertised except:

• SAOImage DS9 refused to launch because of the non-standard DISPLAY variable. I initially hacked around this by launching an xgterm (from IRAF) and setting the DISPLAY variable in it to “:0″ then launching ds9 within that xgterm session. I did this all in one line via: 

  xgterm -geometry 80x45+40+30 -sb -e 'setenv DISPLAY :0; ds9 -fifo ~/iraf/dev/imt1 -geometry 800x800+600+30 &'

  where I was connecting to my IRAF pipes (thus the ‘fifo’ command line entry). However, I emailed the SAOImage DS9 folks on Thanksgiving and they replied same day to tell me about the new ds9 darwin 5.1beta. That fixed the launch issues with ds9. Apparently getting the Aqua version updated is a bit trickier, so its not done yet.
• I had to uninstall the MacPorts version of xephem, but installing it manually from the source worked just fine.
• I installed the unofficial updates to X11 from Xdarwin (see MacSingularity for some notes). The biggest issues this fixes are (1) the focusing problem of X11 windows behind Aqua windows not always being “focusable” and a (b) bug in X11 that caused several programs using the Gimp Toolkit (aka gtk) to crash. NOTE: These updates have been superceeded by those on the MacForce XQuartz updates site.

All in all, I like the new upgrade, the most useful feature for me being the QuickLook interface and the just generally better networking behavior. I also think there has been a lot of thought put into nips and tucks (such as where the Firewall controls are now, in the “security” prefpane instead of “sharing”). More reports from the field as my usage of IRAF and ds9 under Leopard continues.

There are a wide variety of LaTeX front-ends out there. I recently discovered Texmaker and I like it a lot. It’s not quite Mac native, so the interface takes a little getting used to, but has a nice syntax-coloring editor, some latex-specific menu items for inserting symbols and math, and it is free. You can download it here, but I would recommend installing aspell (for spell checking) via macports instead of using fink.  

I haven’t played with this personally yet, but since I will be working on a paper for publication shortly, it looks like this might come in very handy. A Dr. Figueroa-Centeno in the Department of Mathematics in Hawai`i has posted instructions for getting the LaTeX syntax checker, ChkTeX, running under MacOS X. It doesn’t look terribly difficult. He includes instructions and a script for BBEdit integration, which makes me a happier BBEdit user. To quote from the ChkTeX website:

[ChkTeX] has been written in frustration because some constructs in LaTeX are sometimes non-intuitive, and easy to forget. It is not a replacement for the built-in checker in LaTeX; however it catches some typographic errors LaTeX oversees. In other words, it is Lint for LaTeX.

Looks promising for me. I use Splint when C programming (I installed splint via MacPorts using the command line sudo port install splint), so the idea of a Lint for LaTeX is appealing. I’ll be visiting Dr. Figueroa-Centeno’s website on ChkTeX on Mac OS X for full details on installing it, once I get a break from teaching.

MacPorts is an easy way to install a lot of programs. However, it does occasionally have glitches. I installed xephem, a very powerful astronomical ephemeris package, today using

sudo port install xephem

Everything worked fine except when I launched xephem, it couldn’t seem to find any of its ancillary data files. A quick search revealed that they were located in /opt/local/share/xephem/. I suspect because I previously used a manually installed version of xephem, it was searching for the ancillary files in /usr/local/xephem and not finding the data there. After reviewing the documentation for xephem the solution turned out to be simple. I was storing my private settings in the directory ~/.xephem and telling xephem to look in that directory using the following line in my ~/.xephemrc file

XEphem.PrivateDir: ~/.xephem

So all I did was open the file ~/.xephem/XEphem (capitalization important) and edit the line pointing to the shared directory to read:

XEphem.ShareDir: /opt/local/share/xephem/

That told xephem to look in the new location in the MacPorts directories and not the default one in /usr/local/xephem.

I guess RTFM can actually be important!

Another piece of a fundamental *nix installation that is broken in MacOS X Tiger is xterm. Specifically, the Tektronix 4014 emulation in xterm on the Mac generates ‘empty boxes’ instead of actual characters for text as shown below:

I found that this problem had been reported on Apple’s X11-users mailing list here, but no solution had been determined. I spent a bit of time looking for “missing” fonts as suggested in the posting, then decided this had to be a problem with the xterm executable and tried my previous solution of installing the program from MacPorts via

sudo port install xterm

Since that doesn’t over-ride the default xterm, I then over-rode the default installed xterm using

sudo mv /usr/X11R6/bin/xterm /usr/X11R6/bin/xterm.disabled
sudo ln -s /opt/local/bin/xterm /usr/X11R6/bin/xterm

Now Tektronix emulation works and I get a screen like the one below:

After several days of trying to get the Hectospec folk’s data reduction packages working on my Mac, I realized one of the major problems was that ksh on the Macintosh had a major problem. Normally, in ksh (korn shell), you can set up a loop to read through a list of objects via a read command within a while..do loop. For example, to echo a list of files your ksh script could contain

#!/bin/ksh
ls -1 . | while read fname; do
  echo $fname
done

where the read filename bit reads a line from the piped input and assigns the first block of text (before a space) to the variable fname. Try this script on MacOS X and it produces no output. “read” fails. This has been documented elsewhere at least twice that I have been able to find with Google, here and here. So clearly, there is a serious bug in the installed version of ksh on MacOS X. I fixed it by updating my ksh using MacPorts, a simple

sudo port install ksh93

followed by changes in the Hectospec scripts to point to/opt/local/bin/ksh instead of /bin/ksh and I was done.

NOTE: I will assume you have installed teTeX (a modern LaTeX package) in one of a variety of ways. Personally I recommend either Fink or MacPorts. However you can get a lot more information about this by visiting the “Getting Started” page at the Mac TeX website.

AASTeX is used to help typeset publications for all the major astronomical journals (at least in the US). You have two fundamental options for installing AASTeX on the Mac:

1. Single User Install: The easiest way is to download AASTeX (the version for LaTeX 2e) from http://www.journals.uchicago.edu/AAS/AASTeX/ and then just copy the aastex.cls file to whatever directory contains your latex source code for your paper. It should work just fine if you do that.
2. Global Install: If you want to make the AASTeX class file available to all your Mac users, you need to install it globally where the laTeX installation keeps its latex libraries. The easiest way to do this is to first determine where teTeX keeps its laTeX libraries (referred to as TEXMFMAIN). One simple way to do this is to type the following from the command line
   

   texconfig conf | grep TEXMFMAIN

   
   Once you have found that directory, edit the Makefile that comes with AASTeX so that INSTALLDIR equals that directory and fire off a
   

   sudo make install

   
   Once you have installed AASTeX, run
   

   sudo texconfig rehash

   
   And you should be set.

P.S. – Most teTeX installs come set to European paper sizes. If you want US Letter size, just run the configuration program and set US Letter size pages as the default using:

sudo texconfig

Its text menu driven and pretty straight forward.