Urania

SciSoft OSX Intel 2008.5.1 was released today. Nor’s blog post about the update states

The latest update to Scisoft OSX is now available. This includes an update to Pyraf (v. 1.6), GSL, pygsl, Gunplot, and a few backend libraries.

I went ahead and decided to install it today to investigate the improvements. As is usually my procedure, I first moved the directory containing my functional SciSoft OSX install temporarily out of the way via the command line:

sudo mv /scisoft /scisoft_old

Having done that I double-clicked on the installer package and let it do its thing, installing everything in the /scisoft directory. I poked around a bit an realized almost immediately that /scisoft/i386/Applications directory was empty! This one is kind of a show stopper as it means DS9 and FV are unavailable. I copied the files back from the previous installation without too much of a hitch. I did check, the installer package file with Pacifist and it does appear to contain those files in it, so I am not sure why they didn’t appear to install. I hope this is an isolated incident and not a recurring issue with the installer.

Other minor glitches I noticed:

• I discovered that /scisoft/i386/Packages, /scisoft/NEWS and /scisoft/i386/share are set to have owner 502:502 instead of root:admin. This glitch is easily fixed by issuing the following command from the Terminal
  

  <br />sudo chown -R root:admin /scisoft/
  

• I also noticed that in addition to the x11iraf-1.5DEV installation, the entire x11iraf-1.3.2 installation is still sitting in the /scisoft/i386/Packages directory. All the x11iraf binaries in /scisoft/i386/bin/ are linked to x11iraf-1.5DEV instead of the older 1.3.2 binaries. I suspect this is an oversight.

An investigation of the /scisoft/i386/Packages directory as well as the NEWS file reveals the following changes to this version of SciSoft OSX over the 2008.3.1 version.

• GSL updated from 1.9 to 1.11
• DS9 updated from 4.13 to 5.1 (The current version of SAOImage DS9 is actually version 5.2, you can read about how to update the SciSoft version of DS9 in this post)
• GNUPlot updated from 4.0.0 to 4.2.3
• Swarp updated from version 2.15.7 to 2.17.1
• WeightWatcher updated from version 1.7 to 1.8.7
• pyraf updated from version 1.3 to version 1.6
• The following Python libraries were updated:

• • pygtk updated from 2.8.6 to 2.12.1
  • matplotlib updated from 0.90 to 0.91.2

• atk library updated from 1.10.3 to 1.22.0
• cairo library updated from 1.1.6 to 1.6.4
• cfitsio library updaed from 3.040 to 3.080
• glib library updated from 2.8.6 to 2.16.3
• glib-1.2.10 library added as well (possibly for a particular package needing older version of library)
• gtk+ library updated from 2.8.19 to 2.12.9
• gtk+-1.2.10 library added as well (possibly for a particular package needing older version of library)
• pango library updated from version 1.10.4 to 1.20.2
• pixman 0.10.0 library added
• libtiff library upgraded from 3.7.4 to 3.8.2

Hats off to the SciSoft OSX folks for keeping this package up to date. I have placed a copy in my SciSoft OSX mirror in case there are any access issues.

Immediately after installing SAOImage DS9 5.2, I had a major failure of the application and initially I just thought it was some sort of build bug. This is what I posted at that time:

[HOLD OFF ON THIS UPDATE! I have discovered that at least on one of my systems, this version of ds9 is refusing to run properly. It launched once, but when I attempted to check the “About SAOImage DS9”, it triggered the following error:

 “An internal error has been detected local header mismatch couldn't open “zvfsmntpt/doc/sun.gif”: no such file.

(this occurred in both Aqua and X11 versions). Furthermore, all future attempts to launch ds9 (again, either Aqua or X11) fail with the following error:

Error in startup script: couldn't read file “./zvfsmntpt/src/ds9.tcl”: no such file or directory  

Even removing the preferences file at ~/.ds9.prf didn’t help.]

Apparently, my problems with SAOImage DS9 in Leopard are a known issue. If you configure the built-in Firewall to “Set access for specific services and applications” so that you can approve “holes” in your firewall on an Application by Application basis, your first launch of SAOImage DS9 will irreparably damage the application!  Unfortunately, Apple implements the application firewall in part by modifying the Application package of the Application you are running by digitally signing it if it was not digitally signed by the developer (adding a file called CodeResources to the Application package). According the Apple’s documentation on this:

If you run an unsigned application not in the Application Firewall list, you will be presented with a dialog with options to Allow or Deny connections for the application. If you choose Allow, Mac OS X 10.5 will sign the application and automatically add it to the Application Firewall list. If you choose Deny, Mac OS X 10.5 will sign the application, automatically add it to the Application Firewall list and deny the connection.

So basically,Apple doesn’t warn you in the dialog box that comes up that it has whatever decision you make, it will modify the application by digitally signing it and it doesn’t give you a way to avoid this. This is, in my opinion, is an incredibly boneheaded move on Apple’s programmer’s part. They readily admit that

  Some applications check their own integrity when they are run without using code signing.

They suggest the application firewall will try to automatically detect these and avoid modifying them, but they should give you, the user, the option instead of making the decision via some internal algorithm.  MacOS X shouldn’t assume its OK to change an application. In the case of SAOImage DS9, they are irreparably damaging the application without leaving you a way to avoid the damage once you trigger the application firewall. Shame on you Apple. The only way to fix it is to reinstall the application!

So when I figured this out (a tip of the hat to this post on IRAF.net). I reinstalled the SAOImage DS9 executables (both Aqua and X11 versions) and before launching them, I set the Firewall (via the Security Pane of the System Preferences) to “Allow all incoming connections” (this is the default mode, so it is as secure as MacOS Tiger was). Everything now appears to work just fine.

Personally, I believe an application that fails its checksum should present a message indicating that is the problem instead of just crapping out, but in this case, the fault lies mostly with Apple. Apple is damaging applications by making this critical decision in the background, without user intervention!

[See my more recent post warning about MacOS X Firewall settings and how they can destroy the SAOImage DS9 executable during its first launch! This problem is avoidable by tweaking the Firewall settings, but once you have launched SAOImage DS9 with the bad settings, the application is damaged can can't be relaunched again. A reinstallation is the only solution, so it is a good idea to avoid this problem.]

The folks in Cambridge have kept busy. They have released SAOImage DS9 version 5.2. The versions for MacOS X include the following:

• Aqua 10.4 Tiger (Universal)
• Aqua 10.5 Leopard (Universal)
• X11 10.4 Tiger (Universal)
• X11 10.5 Leopard (Universal)

The rather extensive changes are detailed in the release notes here, but the notable ones to me include:

• ANALYSIS: for MacOSX tiger, wrap cmds with shell and PATH.
• GUI: change default directory for standard dialog to $HOME.
• ANALYSIS: add /sw/bin to default path for MacOSX. While unstated in the release notes, this is clearly an attempt to support Fink, which places its installation in the /sw directory.
• GUI: ds9 will now start in the users home directory for MacOSX Aqua users when invoked from a double click and the default dialog box is Motif or Windows.
• MACOSX: fixed a problem with printing non standard colors.
• MACOSX: restore postscript printing.
• REGIONS: apply WCS to fits regions if present.
• GUI: add support for user configured button bar.
• CATALOGS: add support for simbad.
• IMEXAMINE: added support for key stroke events.
• Although unstated in their release notes, they are now apparently providing universal binaries instead of PPC and Intel binaries for MacOS X.

I have previously posted notes for integrating upgrades of DS9 into the Scisoft OS X installation and they still work just fine.

To quote iraf.net:

As of September 2007, NOAO has resumed development of IRAF on a limited scale, although primary responsibility for user support remains at the community IRAF.NET web site. IRAF V2.14 is a formalized version of the IRAF.NET V2.13 releases previously made available by iraf.net.

The major version number increase is meant to disambiguate NOAO releases from earlier versions and to provide a clean code base for future development. Unlike earlier ‘major’ IRAF releases that contained substantial new functionality, this release may seem a bit lacking. Support for Intel-based Mac and Cygwin platforms is the key highlight as well as many unseen but required maintenance/viability changes. A number of new tasks and features have been added, either inherited from the V2.13 releases or done as part of external package development.

It appears a full installation is required, even if you have previously installed IRAF 2.13. I won’t be upgrading until SciSoft OS X is upgraded (there is a beta I am playing with of SciSoft, but it has IRAF 2.13 in it). Marcos Huerta is already playing with it so those of you needing package installers of (just) IRAF 2.14 will probably get your wish soon enough.

No… the new Scisoft OSX isn’t out quite yet, but I got the following note from Nor Pirzkal responding to my post regarding the various broken symbolic links in SciSoft OSX 2007.11.1.

Just to let you know that I just implemented your changes in 2007.11.2b. Thanks again.

So it looks like these bugs will be fixed when Scisoft OSX 2007.11.2b is released soon. I have to hand it to them, Nor is pretty quick to respond to these bugs, given he has a full time job which doesn’t involve maintaining SciSoft OSX!

On October 15, the folks behind SAOImage released SAOImage DS9 version 5.0. The big change I noticed is they now have a completely MacOS X native (read “Aqua”) version of ds9 (but only if you use the application package version of ds9, the command line versions remain X11)! I downloaded the following three versions:

• MacOSX 10.4.x (Universal)
• Darwin PPC 10.4.x
• Darwin Intel

The new features lists page tells us that this release includes:

• MacOSX Aqua Support: DS9 has been ported to MacOSX Aqua and is an universal application which no longer requires X11.
• Compressed FITS Support: DS9 supports compressed FITS images using RICE compression.
• Mask Support: DS9 supports overlay masks. A mask is defined as a valid FITS image, in which a non zero value indicates that the selected mask color is to be displayed instead of the data value color.
• SkyView Support: DS9 provides support for HEASARC’s image cutout service, SkyView. This site provides image cutout service for a number of image surveys, including SDSS.
• Multi-Language Support: DS9 provides multi-language support. By default, the language used for menus and dialog boxes is based on the value of the operating system locale variable. The user may override the default value by selecting the desired language in the preferences or by the -language command line option.
• Preferences: Preferences are automatically saved when a user changes an option. Selecting the saving preferences menu item is no longer needed.

More detailed release notes are available here. I was able to get this version of ds9 integrated with SciSoft OSX by doing the following:

1. Decompress the command line version of ds9 via the terminal using tar xzvf ds9.darwinppc.5.0.tar.gz (PPC version) or tar xzvf ds9.darwinintel.5.0.tar.gz (Intel version). When the decompression is done, all you have is an executable called ds9.
2. Next, from the terminal, go to the /scisoft/bin directory (on PPC) or /scisoft/i386/bin/ directory (on Intel) and rename the old ds9 executable to something like ds9_old (using something like mv ds9 ds9_old).
3. Copy your newly decompressed ds9 executable into the SciSoft OSX binary directory. I should note the command line version of ds9 still requires X11.

The IRAF.net forums had a post from someone having issues getting the IRAF package rvsao to compile properly on MacOS X on Intel-based Macs. I’ve commented about this before and had discussions with Doug Mink, the fellow behind rvsao as I have battled to compile it. It’s not actually that tricky, you just have to be careful. The key issue is that the most commonly used g77 compiler on Intel-based Macs is probably g77 version 3.4 as downloaded from the High Performance Computing for Mac OS X site. This version of g77 is a bit more picky about logical statements. Specifically, when you try to compile rvsao within IRAF using mkpkg, you get the following error (as noted by Phil Massey in the IRAF.net Forums earlier today):

I’m trying to install the external package rvsao on my Intel mac. However, when I go to do the mkpkg there is a program “writetemp.f” that won’t compile:

In subroutine `tmpwrf':
writetemp.f:139:
if (.not.(debug .eq. .true.)) goto 130
1 2 3
Use .EQV./.NEQV. instead of .EQ./.NE. at (2) for LOGICAL operands at (1) and (3

I was having exactly these sorts of errors with not only rvsao, but several of the SAO IRAF packages this summer and after banging my head on this a bit, I found a solution that worked for me. It turns out g77 needed to be told to use less restrictive logicals via a “-fugly-logint” flag during the compile. So my solution was to write a perl script that was saves as /usr/local/bin/f77, such that when f77 was called (by these IRAF mkpkg calls) it would issue a g77 call with this flag set on the compile. So I posted about this on that IRAF.net forum thread started by Phil Massey.

I got a response from Mike Fitz where he points out that you can set up the XC compiler used by IRAF to always use these flags via environmental variables:

If you use ‘g77′ all the time and need this flag it can be set for all compilations either in the user environment (e.g. your .cshrc file) using:

Code:

setenv XC_F77 g77 setenv XC_FFLAGS “-fugly-logint”

or for problematic packages you can edit the ‘mkpkg.inc’ file for the package (normally in the pkg$lib directory but in the case of RVSAO it’s in the main rvsao$dir) to add “-/fugly-int” to the ‘XFLAGS’ definition. The ‘/’ tells the XC compiler to pass the flag thru to the underlying compiler unchanged, but note this sometimes causes problems or warning if say g77 knows the flag but gcc doesn’t (i.e. the XFLAGS are passed to all sources being compiled, you’ll need the XC_FFLAGS trick to pass only to fortran code).

Another new version of Scisoft OSX for Intel has been released and is available for download here. Here’s the entire description of the changes in this version of Scisoft OSX from the release notes:

This version contains an updated [ESO-]MIDAS package.         

I checked the list of packages included and sure enough, the only change was in the ESO-MIDAS package (whose current version is actually 07SEPpl1.0).

• MIDAS 07FEBpl1.1 (previously MIDAS 06FEBpl1.0)

I don’t use ESO-MIDAS, which is an image reduction package aimed as users of ESO’s La Silla facilities and the VLT at Paranal, so I can’t really comment as to the usefulness of this update. As with previous versions of Scisoft, 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.”

I have also confirmed that this release also fixes the IRAF problem with symbolic linking to mkpkg and xc in /scisoft/i386/bin/ I referred to earlier in my blog.   Thanks for the fix guys!

Finally, as I noted with the last release of Scisoft, my standard method for updating Scisoft OSX 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.

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 »

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.