The archive of Macsingularity
Well, I’m way late to the game on this, but our long national nightmare is over – Xquartz for Leopard support full screen!
Check out the latest version – 2.3.1 – at MacosForge.
Tags: full screen, x11 — .So, I dropped the ball – the January 14 2008 critical update to IRAF? I never bothered to incorporated the updated binaries to my .pkg installer. I have done so now, and the installer for IRAF 2.14 on the download page contains the updated binaries.
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.
Tags: installers, intel, IRAF, pkg — .IRAF 2.14 has been announced and is available for download. The Mac (PPC and Intel) versions appear to work properly on both Leopard and Tiger. I’ll try and have installers made for these today. Certainly, I can test the Intel one easily but it’s harder for me to test the PowerPC version so once it’s up if someone out there could test it, that’d be appreciated.
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.
Tags: 2.14, installers, IRAF, iraf.net, Leopard, Tiger, unix — .A common problem with the IRAF installers is that / is sometimes not writeable by the admin group, and thus the “iraf user” can’t write files to the root of the hard drive. To see what goes wrong with the installer, please check the installer log. You can see a screenshot here.
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 /
The way I make this work is to change the editor defined in the login.cl file from vi to emacs. The cl uses keybindings based on the editor and for whatever reason, changing the editor to emacs does the trick. You have to remove the comment # from the set editor line and then change it to emacs so it then looks like
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.
Well, the download page was rather confusing collection of links, and had the Intel installers rather hard to find sometimes, so I reorganized it a bit today. Hopefully, it’ll be less confusing now.
.So, this bug may cause a “bus error” when using display to show certain float images. There is a fix described in the thread, and I have incorporated the fixed binaries now into the IRAF installer, which you can find on the download page as always.
.This may be common knowledge among some IRAF users, but I came across this in the IRAF.net forums and its news to me. You can make shell scripts that call the CL, to use IRAF tasks from outside of IRAF. Check out the details here.
.Well, the link for GUIAPPS was broken, and then the installer in question didn’t work on Tiger. I had to compile these binaries myself on my iBook as the binaries at iraf.net seemed to have some issues. The updated installer is on the download page.
.So, I get a few search engine queries on pyraf that end up here – and occasionally searches of the site itself for pyraf. As you probably know, there is no pyraf installer here. The process of installing pyraf (or the larger stsci_python) is somewhat involved. But, I managed to do it today on my Mac Pro and I have lived to tell the tale. I’ll explain how I did it and where any problems popped up.
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.
.Bad Behavior has blocked 290 access attempts in the last 7 days.
