Check out the latest version – 2.3.1 – at MacosForge.

This is also the first time I’ve used Packagemaker in xcode 3.0, so … I now am requiring authorization to install and I think I have it set up so that the iraf user will be given ownership, but I’m not 100% sure that’s going to work. Let me know if there are any problems.

Oh, and as an aside – did you see the iPhone version of IRAF?. Quite amusing.

Update The Intel installer is available here – Download IRAF 2.14 for Intel Macs .pkg installer (57MB). My prescribed update method is simple. Change to the IRAF user and do:

  % cd /
  % mv iraf iraf_old

Run the installer and then:

  % mv /iraf_old/extern /iraf/extern/

That should preserve all your external packages. You will most likely want to copy over the extern.pkg from your old install.

  % cd /iraf_old/iraf/unix/hlib
  % cp extern.pkg /iraf/iraf/unix/hlib/extern.pkg

That should work. Let me know if there are any problems – it worked ok for me. I’d keep /iraf_old around for a while just to be safe. And remember any installer errors are probably permission issues but be sure to check the log first before emailing me with any problems.

If it’s something about permissions, making / writeable by the admin will probably fix it (assuming IRAF is an admin user, as I suggest)

   sudo chmod g+w /

     set     editor          = emacs

Now, I personally never have IRAF invoke the editor defined in my login.cl file so this change has no effect for me other than making the delete key work. I’m not really sure when the editor is the login.cl file is used. But presumably this change would force you to use emacs when you want vi.

Ok, well let’s look at the requirements for stsci_python:

• IRAF (IRAF 2.13beta must be installed on MacOSX with Intel CPUs)
• TABLES/STSDAS – 3.6
• Tcl/Tk – v8.3 or higher

No problems here, installers are on this site for IRAF, TABLES, and STSDAS. Tcl/tk comes with OS X and it appears to be at version 8.3. What else does it need….

• Readline
• Python – v2.4 or higher (with readline and _tkinter modules enabled)
• Numeric – v24.2
• libf2c (Note: the package on our web site has a change that allows it to work on 64bit Linux platforms)
• Pmw 1.2
• Urwid -( optional)
• Ipython – (optional)

Ok, I needed some of these. Being a minimalist when it comes to installs, I ignored the Urwid and Ipython requirements. Python in Tiger is at 2.3, so that’s no good. I turned to fink for Readline, Python 2.4, Numeric, and Pmw. I installed Python 2.4 first, then the packages for it.

libf2c is included with iraf, and lives in /iraf/iraf/unix/bin.macosx or /iraf/iraf/unix/bin.macintel depending on your processor.

To make sure things are working, the stsci_python instructions say to try these commands:

%python
>>>import readline
>>>import Tkinter
>>>Tkinter._test()
>>>import Numeric
>>>import Pmw

and if there are no errors, you’re good. So, I tried them. Blamo – readline didn’t work. Oh, and python was curiously version 2.3. Hmm. It turns out fink installs python in /sw/bin which should have priority over the python at /usr/bin given the way that fink sets up its PATH variable. But, the python binary isn’t python it’s python2.4 so I had to create a symbolic link of python in /sw/bin and then typing python ran the fink python. Hooray. I learned later than a better approach is to change the symbolic link at /usr/bin/python to point at /sw/bin/python2.4.. This is because if you ever run an executable something_cool.py script, it may very well explicitly state the python path as /usr/bin.

All the above commands worked, but Tkinter._test() only will show a window if you run python from an xterm, xgterm, etc. or if you have manually set the DISPLAY variable in an OS X terminal. (Apple’s OS X Terminals do not set the DISPLAY variable which is why running X11 based programs from them usually fail. Simplest workaround – use an xterm or anything in which X11 appears as the active application – but not Terminal.)

Ok, so all now looked fine – I downloaded stsci_python, built numarray per their instructions, built stsci_python per their instructions (giving my f2c location as /iraf/iraf/unix/bin.macintel/) and pyraf was installed.

One extra thing I needed was scipy. That proved a pain because while I was able to compile numpy without any problems, scipy did not build giving some kind of g95 error. They had a binary for Tiger… but the download page explained that the binary installer would required Macpython or Activepython, neither of which I’d ever heard of before, and that the installer wouldn’t detect a fink build if python. Super. Indeed, it did not. So, not wanting to reinstall python, I used Pacifist to open the .pkg file and manually put the scipy folder in /sw/lib/python2.4/site-packages. This seems to be working, but I haven’t rigorously tested it yet.

Update The scipy trick very much did not work. I had to ultimately follow these instructions to compile scipy – the trick seemed to be that neither the fancy gcc 4.3 nor the Apple gcc 3.3 worked – it had to be gcc 4.02, and still I get 2 errors in the scipy.test(10). Confirming that I was using Apple’s gcc 4.02 required some trickery since I had installed gcc 4.3 from the MacOS X high performance computing site to get g95, and I don’t think scipy liked gcc 4.3

Anyway, it seems to be working now as well as I’m going to get it to…. the errors seem related to BLAS and check_dot. I don’t know what that means though.

Another update scipy woes continue. I either get the 2 errors in the test or I get malloc problems. And, the local package I’m trying to run which depends on scipy… that is producing odd “encountered invalid numeric results” problems. Which may or may not be scipy related but I think it is…

Yet another update – I’m told the failures in the scipy test don’t mean it’s not working … some failures are expected. The local pyraf based package however is very much not working, and in which package exactly the “invalid numeric result” is occurring is unknown at this time.