Urania

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!

Francesco Pierfederici and Nor Pirzkal have released a new version of Scisoft OSX for Intel which is available for download here. Here’s a quote from their blog about the changes:

This version is contains the latest STSDAS and TABLES Iraf packages as well as updates of a few packages.Startup scripts have also been modified to try to get around conflicts with Fink. Please let me know if you are still getting problems with Scisoft when Fink is installed.

I checked the list of packages included and changes that I was able to identify versus Scisoft OSX 2007.1.1 include:

• cfitsio 3.040 (previously 3.006)
• aXe 1.6 (previously 1.5.1)
• FV 4.4 (no previous version listed)
• Python 2.5.0 (previous 2.4.3)
  • ipython 0.8.1 (previously 0.7.2)
  • Numpy 1.0.3 (previous 1.0)
  • pyfits 1.1rc4 (no previous version)
  • matplotlib 0.90 (previously 0.87.7)
  • pygsl 0.9.1 (previously 0.3.2)
  • stsci_python 2.5 (previously 2.4)
  • MySQL-python 1.2.1_p2 (previously 1.2.1)
  • AstroAsciiData (no previous version)
  • scipy 0.5.2 (previous version 0.5.2.dev2320)
• IRAF Packages (WARNING: This version of Scisoft OSX doesn’t fix the missing symbolic links to mpkg and xc I noted earlier and you may want to manually fix those links.)
  • TABLES 3.7 (previous version 3.6)
  • STSDAS 3.7 (previous version 3.6)

The release notes warn if you use Aquaterm devices for PGPLOT, GNUPLOT, or any other packages that you “must manually run/scisoft/i386/Applications/Aquaterm.app once first to enable the aquaterm devices.

My standard way to install Scisoft OSX updates is to move my existing /scisoft directory to /scisoft_old and then I unpack the new version. That way, in case anything goes wrong, I can always switch back.

I am posting here an annotated version of one of my headaches for the last few days, which has been a persistent xgterm crash. I have been working on getting the Hectospec reduction scripts known as specroad running on my Macintosh (something I will fully document and provide binaries for when I am done). Having never done spectroscopy before, it seemed like a safer bet to learn by working my way through their scripts than trying to invent this as I go. Some magic done by the specroad scripts comes from the fact that they call IRAF routines in the form of ecl scripts, allowing two or more separate simultaneous IRAF processes. On a multi-processor system like mine, this parallelization can help cut down on the running time. More specifically, the specroad package contains a script called ‘callhectospec‘. This script calls ecl, the enhanced IRAF command line environment, and then sets up the environment by loading the hectospec package in IRAF. It then issues the IRAF command you requested. I was having a problem running the command:

xterm -e callhectospec hcal comp.ms

to calibrate the pixel to wavelength mapping because it would bring up a Tektronix window (via xterm’s Tektronix emulation), but I wasn’t able to type out the proper commands within that window. I suspected that I was triggering some sort of internal Tektronix commands, and so I tried switching the call spawn an xterm witha call to X11IRAF’s xgterm. xgterm is a xterm clone that offers more advanced plotting capabilities and interactions. The callhectospec script immediately crashed with the following error:

 Error in message to server, line 6: send: could not find object gterm
    while executing
"send gterm setGterm"
xgterm Xt error: Shell widget gterm-iraf has zero width and/or height

I spent a few hours searching for solutions in Google. All the previous instances of this error seemed related to running old versions of X11. This didn’t match my situation. I tried upgrading xgterm to the current version, which didn’t change things. It was a bit irritating because I knew IRAF worked with xgterm just fine. Clearly I was triggering this error message for a reason that didn’t match the previous cases. I finally relented and posted about my problem on IRAF.net’s forums. Thankfully, the solution, pointed out by Fitz, was simple, the callhectospec script was setting up the IRAF environment for xterm, not xgterm. All I needed to do was edit callhectospec to replace

else if (envget("TERM") == "xterm") {
 stty xterm
}

with

else if (envget("TERM") == "xterm") {
  stty xgterm
}

My IRAF login.cl script does exactly this, which is why it worked when I entered ecl by hand. Once that was fixed, everything worked like a dream.

Read the rest of this entry →

Like many Macintosh users, the first few months of using MacOS X I wasn’t even aware of what the Keychain really was. After a while, you realize just what a cool little piece of security it is. It ensures many MacOS X programs can securely store passwords and other information without the programmer having to be a great cryptographic genius.

One of my favorite programs which exploits this is 1Passwd. 1Passwd stores all your web form passwords (and any other data you care to secure, like credit card numbers or software serial numbers) in a Keychain, so the cryptography is managed by Apple’s Keychain. Recently, on my iMac at home, 1Passwd started locking up whenever it tried to access it’s keychain. Specifically, I have updated 1Passwd so it presented me with a dialog to allow the updated version access to the Keychain. When I clicked continue, the dreaded rainbox beachball of doom showed up and would not go away. From that point on, logins to the machine failed and most Apps using the keychain were unable to use the keychain.

I checked the system usage from the command line

top -u -s 5

and discovered a program called securityd was eating up CPU cycles and RAM. I called up the manual page on securityd via the command line:

man securityd

and discovered:

securityd maintains security contexts and arbitrates cryptographic operations and Security Authorizations. Access to keychain items is routed through securityd to enforce access controls and to keep private keys out of user process address space. Authorization calls also communicate with securityd to enforce rules contained in the /etc/authorization database. All user interaction with securityd is mediated through the Security Agent.

So by locking up securityd, I was messing up all the cryptographic operations that ran through it. Great. I figured there had to be a corrupted file on my computer that was mucking up the works, but where. My first thought was a corrupted keychain file, so I checked out my keychains using the “Keychain First Aid” item in the Keychain Access (in /Applications/Utilities) [shown in the figure below].

The files all checked out as intact, so that wasn’t it. Something was corrupted on my computer, but what.

Just a Google search on “securityd” later, I found the solution on the Unsanity programmers blog in an article titled “Fix for securityd hogging RAM when reauthorizing apps’ Keychain access“. In a nutshell, the corrupted file is a cryptographic database at /var/db/CodeEquivalenceDatabase. In order to fix this problem they suggest:

just open the Terminal (/Applications/Utilities/Terminal) and type:

sudo mv /var/db/CodeEquivalenceDatabase /var/db/CodeEquivalenceDatabase.old

Upon rebooting, God should be in His Heaven and all should be well with the keychain.

And I verified this worked to fix my iMac and all the Keychain apps are happy again. Excellent!

Update: I have updated this blog entry to reflect some updated information from Nor Pirzkal regarding the best way to fix this glitch.  This problem has been fixed in Scisoft OSX MacIntel version (2007.9.1).

During my adventures compiling the hectospec-related IRAF packages, I was using Scisoft OSX and discovered there were a couple of issues with the symbolic links for the mkpkg command necessary for compiling new IRAF packages.

• In the Scisoft OSX PPC Beta (2006.11.1b) mkpkg appears to be mis-linked, so it can’t be executed. So I did the following in the terminal:

  cd /scisoft/binsudo rm mkpkgsudo ln -s ../iraf/iraf/unix/bin.macosx/mkpkg.e mkpkg

• In the Scisoft OSX MacIntel version (2007.1.1) and Scisoft OSX MacIntel version (2007.7.1), there are some missing symbolic links to mkpkg and xc in the directory for MacIntel binaries.  As a result, both mkpkg and xc were instead pointing to PowerPC binaries. I fixed this as follows (again, from the command line):

  cd /scisoft/i386/bin/sudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/mkpkg.e mkpkgsudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/xc.e xc

  This mis-linking certainly didn’t help getting things to compile under MacIntel, since IRAF was attempting to compile MacIntel code using PowerPC versions of mkpkg and xc.

Thanks for Nor Pirzkal for giving me some feedback on fixing this problem.  He tells me he has made the appropriate changes so that the next version of Scisoft OSX will not have this  issue.By the way, my complaint here should in no way be construed as a critique of the efforts of Francesco Pierfedericki and Nor Pirzkal in putting together Scisoft OSX. They have done a great deal of work to put together an awesome package. For two people to track over 2 GB of software and not expect some glitches is unrealistic. And I for one am extremely grateful that his efforts have saved me a lot of time.

On the Mac, X11 is part of the optional install. To quote Apple’s X11 Developer Note on Installing and Configuring X11 Applications on MacOS X on the Mac:

X11 is available as an optional install on the […] Mac OS X v10.4 Tiger install disks. Run the Installer, select the X11 option, and follow the instructions.

Once you have installed X11, you can launch X11 by going to the /Applications/Utilities/ directory and double clicking X11.app (this may display in the Finder as “X11” depending on your settings for showing File Extensions). And now some hints for better X11 usage (these are not in any particular order):

1. If you are an astronomer, you probably use a lot of programs like IRAF, AIPS, or XEphemthat need X11. So it probably makes a lot of sense to set it up so that X11 automatically launches when you login. To do this:
   • Open your “Accounts” preference pane in the System Preferences.
   • Choose the “Login Items” tab within the Accounts pane and then you will see a list of login items (possibly empty).
   • You can add X11 to this list by pressing “+” at the bottom of the list of login items. This will bring up a dialog to select the file, work your way to the /Applications/Utilities/ directory and select X11 and you are done. NOTE: On MacOS X Tiger, there is no ability to control the order in which items are launched, so its position on the list is somewhat meaningless.
2. There are many hidden preferences in X11 just like in many Mac Applications. You can see a list of the hidden (and not hidden) preferences using the command line tool defaults. To see the available X11 preferences, type:
   

   defaults read com.apple.x11
   

   In addition to “reading” the preferences, you can write to them. From the command line you can type:
   • defaults write com.apple.x11 no_quit_alert true

     This allows X11 to quit without an alert box. Useful if you find it irritating like I do that X11 will prevent me from logging out or the computer from restarting due to that dialog box. However, this does mean you can accidentally quit X11.app pretty easily if you hit cmd-Q at the wrong time.

   • defaults write com.apple.x11 wm_ffm true

     Allows which X11 window is selected to follow the mouse, which is the way X11 behaves under most *nix systems by default.

   • defaults write com.apple.x11 wm_click_through -bool true

     This activates click_thorough events in the Quartz window manager, which allows clicks to pinned windows, another behavior common to *nix X11 installations.

3. On the Mac X11 launches the quartz-wm Window Manager and while you can run any other window manager of your choosing, I like it. However, if you modify your ~/.xinitrc file, you can control which window manager is launched. If you don’t have a ~/.xinitrc file, copy the default one:
   

   cp /private/etc/X11/xinit/xinitrc ~/.xinitc
   

   and then manipulate it with any text editor.

4. You can launch an X11 application from the Terminal directly if you have set the DISPLAY environmental variable properly or by using the open-x11 command, for example:
   

   xclock &
   

   will launch the xclock in the background if I have already set the >DISPLAY variable.

   open-x11 /usr/X11R6/bin/xclock &
   

   will do the same without DISPLAY being set.

5. BIG LAPTOP USER HINT: Because X11 on the Macintosh uses authentication to prevent connections from unauthorized sources to the X11 client, something interesting happens when you change IP address, you will discover you can’t use X11.app from the MacOS X Terminal until you quite and relaunch X11.app. This happens to me all the time on my laptop when I travel and the IP address changes. I recommend either using the Xterm as your terminal or just get used to restarting X11 if you have problems connecting to the terminal.
6. You can run X11 remotely on your Mac, if you can ssh into your Mac, then just use

   ssh -Y youraccount@yourcomputer.com

   the -Y flag should allow you to run X11 remotely as long as X11.app is running on your machine before the connection is made. If your ssh on the remote machine doesn’t support X11 connections and you have admin access, you can edit the file /etc/sshd_config on the remote machine and make sure X11 Forwarding is turned on by looking for the following lines and making sure they are uncommented and that all “no”’s are set to “yes”:
   

   X11Forwarding yes<br />X11DisplayOffset 10<br />X11UseLocalhost yes
   

7. The X11 Dock icon on the Mac can let you select specific X11 windows when X11 apps are running.
8. Tektronix emulation in xterm is broken under MacOS X (at least in Tiger). To get it functional again, see my previous posting about this.

And that is it for the hints for now.