One of the packages I use a lot in my research is the venerable PGPLOT package put together by Tim Pearson (currently at Caltech). You see evidence of this set of plotting routines in the figures in many astronomy papers from the 1980s onward. PGPLOT was written in FORTRAN and supports a wide variety of drivers to export its graphics, including color postscript, GIF, and Xwindows displays. In addition to using PGPLOT, I use PGPLOT.pm, a perl module for calling PGPLOT from perl scripts written by Karl Glazebrook. I have used it to make interactive perl scripts for ‘marking’ spectral lines in HI spectra among other things.
When I moved to Snow Leopard, I discovered that I could not get PGPLOT.pm compiled against the PGPLOT package that comes with Scisoft OSX and soon realized this was because Perl on my Mac Pro is 64-bit whereas the PGPLOT package included with Scisoft OSX was 32 bit. I decided to compile PGPLOT 64-bit native to try to remedy the problem and on the way discovered a few other issues. Here’s what I did to get both PGPLOT and PGPLOT.pm working under Snow Leopard (on both 32-bit and 64-bit computers).
Install GFORTRAN: The first thing I did was install Gnu Fortran (aka gfortran) as configured by Gaurav Hanna at the High Performance Computing for Mac OS X website. It turns out the version he compiled for Snow Leopard (here) is 64-bit Intel ONLY, so for my venerable first generation MacBook Pro, I grabbed the 32-bit Intel Leopard version (here), which worked fine in Snow Leopard. Installing them is a simple matter of issuing the proper tar command to unpack the tarball into /usr/local, where all the binaries are installed.
sudo tar -C / -xzvf gfortran-snwleo-intel.bin.gz
(for the 64-bit Snow Leopard version)
sudo tar -C / -xzvf gfortran-leopard-intel.bin.gz
(for the 32-bit Leopard version)
Once they are installed, you simply have to make sure /usr/local/bin is in your $PATH.
Install PGPLOT: I grabbed the PGPLOT source code from Tim Pearson’s website (here) and untarred the tarball into /usr/local/src/pgplot, the default location the code expects to be in (based on the instructions in the install-unix.txt file included in the source code tarball).
sudo tar -C /usr/local/src/ -xzvf pgplot pgplot5.2.tar.gz
Install sys_macosx configuration: The PGPLOT source code has various compiler configurations stored in “configuration directories” but it doesn’t come with one for Mac OS X. The MacPorts folks, when they ported PGPLOT, did create such a configuration. However, that configuration is hard coded to require AquaTerm, a nice MacOS X native display program that has not been made 64-bit compliant yet. Furthermore, their version of the configuration requires g77 to compile. The only g77 I could find was not 6-bit compliant, so I ended up hacking the sys_macosx/ configuration directory to include a new gfortran configuration that didn’t require AquaTerm. I am making a tarball of that configuration directory available in the pgplot5.2_macosx_addition.tgz which you can download and unpack into the PGPLOT source directory using:
sudo tar -C -xzvf /usr/local/src/pgplot5.2_macosx_addition.tgz
[The above line was edited to fix an error noticed by a commenter. - Juan (Oct. 24, 2009)]
Compile the PGPLOT binaries: At this point, if you follow the instructions in the install-unix.txt file in the PGPLOT directory you will be fine, baring in mind the configuration you want to use is the “maxosx gfortran_gcc” configuration. However, I will outline the steps I used below.
Create a PGPLOT library/binary directory:Create a directory to contain the PGPLOT libraries. I created /usr/local/pgplot using the command:
sudo mkdir /usr/local/pgplot
Choose the graphics drivers you want: Copy the drivers.list file from the source directory to this new pgplot directory and edit it to match your needs:
cd /usr/local/pgplot
sudo cp /usr/local/src/pgplot/drivers.list .
sudo vi drivers.list
(You can replace this last step with emacs or whatever text editor you prefer). You make a graphics driver part of the compilation by removing the leading exclamation point from the line. I choose to activate the X-Window drivers, the GIF drivers (to create GIF images), and the PostScript printer drivers (which you can use to create PostScript versions of plots for publication). Be aware PNG support requires libpng be installed.
Create the makefile: We now need to create the makefile using PGPLOT’s makemake script. Within the /usr/local/pgplot directory execute:
Reading configuration file: /usr/local/src/pgplot/sys_macosx/gfortran_gcc.conf
Selecting uncommented drivers from ./drivers.list
Found drivers GIDRIV NUDRIV PSDRIV XWDRIV
Creating make file: makefile
Determining object file dependencies.
Create all the binaries: Now you just have to create all the binaries, which is a simple make command:
sudo make
Assuming everything proceeds without error, you should then see at the end of the output
*** Finished compilation of PGPLOT ***
Note that if you plan to install PGPLOT in a different
directory than the current one, the following files will be
needed.
libpgplot.a
libpgplot.dylib
grfont.dat
rgb.txt
pgxwin_server
Also note that subsequent usage of PGPLOT programs requires that
the full path of the chosen installation directory be named in
an environment variable named PGPLOT_DIR.
At this point, you should (if you are going to use PGPLOT within perl or C compile the C library as well using
sudo make cpg
Finally, clean out all the temporary object files, you don’t need them. Do this using the makefile by typing
sudo make clean
If you want to test if things are working you can run one of the PGPLOT demo programs created in this directory. However, the pgdemo* executables seem hard coded to expect the pgplot libraries in the /usr/local/lib directory, to it might be a good idea to do the following step before trying the demos. [Edited in response to a comment about the demos not working. - Juan (Oct. 24, 2009)]
Copy library and header files: This step is optional, but since most programs (including the pgdemo* executables) don’t look in /usr/local/pgplot for library and header files, I copy them to /usr/local/lib and /usr/local/include respectively using
Making sure I use these PGPLOT binaries: Since I am using Scisoft OSX, I modified my ~/.tcshrc file to change the PGPLOT related environmental variables after loading Scisoft’s environment
setenv PGPLOT_DIR /usr/local/pgplot/
. If you are not using Scisoft, you can place these lines anywhere in your ~/.tcshrc file. If you stick to using bash, then the corresponding lines in the ~/.bashrc file that you need to create (after setting up Scisoft, if you are using that) are:
export PGPLOT_DIR=/usr/local/pgplot/
At this point you have a working PGPLOT set of libraries installed. You can stop here if you just want to use PGPLOT from C or FORTRAN source code. If you want to use PGPLOT from within Perl, you need to go further.
Install the ExtUtils:: F77 perl module: In order to install PGPLOT support, you need to install ExtUtils:F77 first. You can download ExtUtils::F77 here and once you untar the tarball,
tar xzvf ExtUtils-F77-1.16.tar.gz
it can be easily compiled using the following standard perl module compilation steps:
cd ExtUtils-F77-1.16
perl Makefile.PL
make
sudo make install
Install the PGPLOT perl module: You can download PGPLOT here. Untar the tarball.
tar xzvf PGPLOT-2.20.tar.gz
We start as we usually do for Perl modules, creating the makefile using the Makefile.PL script:
cd ExtUtils-F77-1.16
Unfortunately, the Makefile.PL script will create a makefile this creates doesn’t work because it doesn’t call gfortran so we have to change the Makefile.PL script to know about gfortran. So load Makefile.PL and edit the line that reads
use ExtUtils::F77;
to read
use ExtUtils::F77 qw{Darwin GFortran};
Once you have done that, create the makefile using
perl Makefile.PL
Now you still have a problem because this makefile is designed to create a universal binary. However, depending on which platform you downloaded gfortran for (in step 1), you only have 64-bit intel or 32-bit intel support. So you have to delete all mentions of
-arch ppc
from the makefile as well as removing
-arch i386
if you are compiling on a 64-bit system or
-arch x86_64
if you are compiling on a 32-bit system. Once you have done that, you can finish installing the perl module using:
make
make test
sudo make install
I did have some issues with make test because it couldn’t find my X-windows driver due to a bad environment, but the compile reported no errors and I was able to get the make test to work once I had the proper environmental variable settings for PGPLOT_DIR (see step 5).
So that is it, I now have working PGPLOT installations with perl support on both my 32-bit MacBook Pro and my 64-bit Mac Pro.
This is an upgraded tutorial to getting SSH2 support under PHP 5.3.0 that I wrote a while back. Getting SSH2 support in PHP is useful for maintaining WordPress blogs. It would be nice if such an extension were not necessary, but this is the only way WordPress supports SSH administration through their web interface.
The big difference is that I will now be using the built-in Apache2 and PHP 5.3.0 under MacOS 10.6.1. I have gotten tired of the fact that everytime MacPorts updates it PHP installation, it tends to clobber the php.ini file for the site, requiring me to re-setup everything. Furthermore, I am also a bit tired of having MacPorts install its own version of everything I already have under MacOS X (such as Apache2, PHP, and MySQL). I understand their philosophy (and the practicality of it), but I am trying to keep my computer as clean as possible. As such, I am only using MacPorts to provide libssh2 to the SSH2 extension for PHP.
I noticed that the WordPress code had ssh2 support built-in, so all I need to is activate SSH2 support in the MacPorts installed PHP and I should be able to use SFTP in WordPress to handle the upgrades. I poked around and found this posting outlining the process for adding ssh2 support to Ubuntu. It guided me in developing this list of hints:
If you haven’t already, start by installing libssh2 via MacPorts using the command:
sudo port install libssh2
Download the necessary SSH2 PHP extension using the build in PECL command
The sudo is necessary because a lock file needs to be created during the download in /usr/lib/php, which is a protected directory. However, the file is downloaded to the current directory. Once the download is complete, we will need to unpack the SSH2 extension and go into its directory:
tar xzvf ssh2-0.11.0.tgz
cd ssh2-0.11.0
If you try to do the normal phpize/configure/make sequence for compiling PHP extensions at this point, you will get a string of error messages ending with something like
/private/var/tmp/apache_mod_php/apache_mod_php-53~1/Build/tmp/pear/download/ssh2-0.11.0/ssh2.c:1105: warning: passing argument 4 of 'add_assoc_stringl_ex' discards qualifiers from pointer target type
Once you have done that, you can finish the SSH2 PHP extension compilation using
phpize
./configure --with-ssh2=/opt/local
make
sudo make install
The final command informed me the ssh2.so library was placed in /usr/lib/php/extensions/no-debug-non-zts-20090626/
Now you need to make sure PHP loads the new module, so we open the PHP configuration file /etc/php.ini and edit the extension_dir line to point the extension directory above:
and then add the following line to the end of the section on “Dynamic Extensions”:
extension=ssh2.so
If you edited everything properly, a simple php -v from the command line should NOT trigger any errors.
Finally, I restart the apache2 server so that the reconfigured PHP is loaded using
sudo apachectl restart
At this point, I checked (via the phpinfo(); command to see if the web server was supporting SSH. Near the bottom of the phpinfo(); listing is a listed of “Registered PHP Streams”. As noted here, it should incude “ssh2.shell”, “ssh2.exec”, “ssh2.tunnel”, “ssh2.scp”, and “ssh2.sftp”. If it does, you have enabled SSH support for Apache2 driven PHP pages under MacPorts.
If you are doing this to get WordPress 2.7 automatic installation working, you will notice now when the automatic installation dialog box pops up, in addition to ftp and ftps, you now have an ssh option.
Nor Pirzkal has released another minor update to Scisoft OSX. He states in his blog that:
A minor revision of Scisoft is available for downloading. Many people are experiencing many problems with the Apple Package Installer and I am distributing this release as a simple tar.gz file.
This version of Scisoft is distributed as a simple tar file that can be un-tarred in /. Scisoft expect to be located in /Applications/scisoft/
I can confirm the CONTENTS file distributed with the install is identical to the file for Scisoft 2009.9.1 so this release may just be a way to avoid some issues with the Apple Package Installer program.
This change to a tarball format is good, but it changes how to install the software. However, there is at least one major glitch in this distribution
WCSTools is missing from the installation! There are symbolic links to the package, but the /Application/scisoft/i386/Packages/wcstools-3.7.3/ directory is empty! If you are upgrading from a previous version of Scisoft OSX, there is an easy way to recover from this problem. I am outlining my suggested installation routine below.
As I noted for Scisoft 2009.9.1, “on Snow Leopard, Gordon Richards discovered that if you attempt ‘import pylab’ in python, you get a bus error. I can confirm the same error occurs on my Snow Leopard machine using either this SciSoft OSX release or the previous one. Furthermore, I can confirm the error DOES NOT occur in Leopard. I am not a heavy Python user, so I will leave it to Gordon, Nor, and others to investigate this issue. Gordon notes that this blog posting contains instructions for getting pylab installed under a vanilla Snow Leopard install, in case you need them.”
My suggested routine for upgrading to this version of Scisoft OSX from a previous version is the following:
Backup the previous version of Scisoft by renaming the /Application/scisoft/ directory to /Application/scisoft_old/.
Download the current gzipped tarball of Scisoft OSX. The current version of Scisoft OSX is available for download from the Scisoft OSX website, but I have made the package available on my Scisoft OSX mirror as well, in case it is faster for people.
Using the command line in an administrative account, you can untar the tarball using the command:
sudo tar -C / -xzvf Scisoft_OSX_macintel_2009.10.1.tar.gz
You will be asked for your account password to allow ’sudo’ to run the tar command as root.
The files are untarred with their ownership intact from when Nor created the tarball, so be sure to change the ownership to match your root account using
sudo chown -R root:admin /Applications/scisoft/
Finally, if you want to copy over the WCStools package from the previous Scisoft OSX installation, you can use the command:
I have alerted Nor to the missing wcstools directory as well as some other minor issues with this release. Hopefully, if Nor has some time, he will make
Nor Pirzkal has released a minor update to Scisoft OSX. He states in his blog that:
This version should fix a few outstanding bugs in version 2009.6.1. People running on case sensitive file system will hopefully stopped having problems. This version otherwise upgrades a few minor packages as described in the NEWS and CONTENTS files.
This version requires OSX Intel 10.5.x or higher. It also works fine with OSX 10.6.0 and OSX 10.6.1.
From reviewing the CONTENTS file distributed with the install, the major changes from the previous version as as he indicated, quite minor. They include:
mxDateTime 3.1.2 was added to the distribution. Adds certain useful date manipulation functions to the python installation.
pysao 2.1.8 was added to the distribution. This appears to add direct XPA communication capability between python scripts and SAOImage DS9.
The gsl library was update from version 1.11 to 1.13.
[From NEWS file] Changed ds9 [command line] unix version a [symbolic] link from an alias. I noticed the SAOImage DS9 website currently says “Note: the next release of DS9, version 5.7, will be available October 15th.”
[From NEWS file] Fixed references to “packages” to “Packages” in Setup scripts
The glitches I have noticed in this distribution
As with previous versions, the installer for Scisoft OSX (due to bugs, apparently in Apple’s installer.app) changes the ownership of /Applications after the install. I would run Disk Utility and Fix the Permissions on your root volume after installing Scisoft OSX.
[Added Sept. 23] Gordon Richards and I have have been investigating some serious annoyances with the python installation on Snow Leopard in this version of SciSoft OSX.
First of all, the installer apparently doesn’t install /Applications/scisoft/i386/Packages/Python-2.5.4/Python.framework/Versions/2.5/Resources/Python.app/ when running on Snow Leopard. This directory contains the python executable. Therefore, in the new SciSoft OSX on Snow Leopard, you can’t run python from the clean install. If you manually copy this directory from the previous SciSoft OSX installation to this one, then I find you can run python again (or in my case, pyraf). I can confirm this directory is apparently installed under Leopard.
On Snow Leopard, Gordon Richards discovered that if you attempt ‘import pylab’ in python, you get a bus error. I can confirm the same error occurs on my Snow Leopard machine using either this SciSoft OSX release or the previous one. Furthermore, I can confirm the error DOES NOT occur in Leopard. I am not a heavy Python user, so I will leave it to Gordon, Nor, and others to investigate this issue. Gordon notes that this blog posting contains instructions for getting pylab installed under a vanilla Snow Leopard install, in case you need them.
The current version of Scisoft OSX is available for download from the Scisoft OSX website, but I have made the package available on my Scisoft OSX mirror as well, in case it is faster for people.
I recently updated my laptop, an old Core Duo MacBook Pro, to Snow Leopard to test out the new OS. There have been a lot of little annoyances and a lot of little benefits to the move.
Some of the improvements I have noticed:
Snow Leopard is noticeably faster! I had thought it might just be fan-boy talk, but this operating system is in fact noticably faster at launching applications and the like. It is especially nice to no longer see the beachball every few minutes in the Finder. In fact, I don’t think I have seen that dreaded rainbow beachball int he Finder since upgrading!
Cisco VPN is built in! Like the iPod Touch, Cisco VPN networking is now built-in, so all I had to do was configure it as one of my network interfaces. Thank you Apple! If you previously had it installed, you can uninstall Cisco’s crappy little VPN client using the command:sudo /usr/local/bin/vpn_uninstall
QuickLook works in the Open/Save Dialog Boxes: Just as in the Finder, you can now hit the spacebar with a file selected in an Open/Save dialog box and you get a previous of the file’s contents. Sweet. QuickLook was probably the most useful feature I use everyday in Leopard, so I am glad to see it available in Open/Save dialog boxes as well.
I can see Hidden Files in the Open/Save Dialog Boxes: Credit this to MacOS X Hints, but in the Open-Save Dialog box, if I hit ‘Command-Shift-.’ (that’s a period), you can see the hidden files in a given directory. If you use your mac in a region where commas are normally used to as a decimal separate, you have to use the comma from the numerical keypad instead of the period. Very useful for people who edit .tcshrc or .bashrc files regularly.
Some of the annoyances I have been ironing out during the last week:
X11 now knows more about user environment: I use tsch as my shell environment. Apparently X11 on Snow Leopard loads the ~/.tcshrc file to set the system enviroment! I had a bug in the file that prevented X11 from launching. I was able to figure out it was local to my account by creating a test user account and launching X11 without a hitch. I was able to find the bad library path and fix it in the ~/.tcshrc and now my X11 works fine.
Battery Issues with Snow Leopard: I had issues with the battery under Snow Leopard. The battery life that was being reported was half what it had been before the upgrade. This seemed very odd to me, but the system profiler app insisted that after 183 charge cycles I had only 1949 mAh of power. So to ‘recalibrate’ I started up the computer after it went to sleep due to ‘low power’. It ran for another hour, reporting 0% battery the entire time. It then did a hard shutdown. I left it off and unplugged overnight, I then charged it full. It still reported only 1949 mAh total charge. I called Apple’s tech support which elevated the report to engineering. Then, after ’safe booting’ the machine (see notes below), and booting back into my normal setup, I discovered the battery level was being reported as 4300 mAh, as it should be. Now, as of this morning, the problem is back again and System Profiler insists the battery has only 2870 mAh of maximum charge and it requires service. Not sure what the problem was, but a lot of people have been having similar problems with this particular battery and snow leopard. [Followup (added Oct. 23, 2009): Apple replaced the battery and the problem went away. It is possible that the number of people reporting the problem is just indicative of a small percentage of users whose bad batteries were not obvious to them before Snow Leopard.]
Ethernet Issues with Snow Leopard: I had major issues with the ethernet connection dropping after a few minutes. Actually, it isn’t a full lost connection, I can still see computers on my subnet, and Skype seems to work, but a large percentage of websites fail to load and mail doesn’t work for off-campus mail servers. Quite a few other people were reporting similar problems on the Apple Discussion boards, but most of them resolved the problem by doing one of the following:
Sometimes corrupt settings persist from a previous setup. Removing all the files in /Library/Preferences/SystemConfiguration/ and rebooting will purge all the system settings related to networking. You will also lose settings related to other things, such as Energy Saver settings, but it can help when you can’t isolate the issue. I tried this, it didn’t work in my case
The other solution many people hit on was to create a new “Location” in the Network control panel. If you have a corrupt preference setting in your Location, creating a new one lets you start from scratch. Again, this didn’t work for me.
After going through all this, I talked to an Apple product specialist and they hit on the idea to try bringing up the computer in ‘Safe Mode‘ by rebooting ahdn holding the shift key during the boot. Safe mode turns off the launching of all non-system deamons and agents as well as turning off the launching of all the programs you might launch at login via your Accounts preference pane “Login Items”. Lo and behold, after doing this, my ethernet connection appears to have been stable! What I did was
I removed Adobe VersionCue CS3 from my launch items in the Accounts preference pane. Adobe noted it was incompatible with Snow Leopard anyway.
I disabled the following launch items by moving them to my Desktop and then rebooting
Having now brought the computer back up through a normal boot, the ethernet connection has remained stable. The fact that my battery issue seems to have been resolved almost simultaneously makes me think these apps were responsible. [Followup (added Oct. 23, 2009): I narrowed down the problem to an apparent incompatibility between Snow Leopard and the version of BIND my campus is using as a DNS server. And it may be specific to my machine. Not sure. Switching to using OpenDNS as my DNS resolver made the issue go away for me. My server, a Mac Pro, which I have upgraded to Snow Leopard, has exhibited no such weirdness.]
MacPorts Rebuild: I traditionally rebuild my MacPorts installation from scratch with a new OS installation. There were no major issues, but I took the opportunity to upgrade to the latest MacPorts and to try to rebuild with only the bare minimum of ports that I was using.
Many Mail Plugins Fail: Most mail plugins use ‘unapproved’ APIs and most of the Mail Plugins I used failed for Snow Leopard’s Mail.app. Furthermore, it looks like Apple has changed things so now every minor revision in the OS will require Mail plugin writers to explicitly approve the plugin for that version of Mail.app. This means in the future every minor revision in Snow Leopard will likely shut down Mail plugins until they get updated.
Force 32-bit compilation for IRAF in Snow Leopard: Doug Mink has discovered that compiling IRAF packages in Snow Leopard presented errors until he forced 32-bit compilation (I am assuming he was on a 64-bit machine). I am quoting his suggestions (sent to me via email) below:It turns out that Snow Leopard defaults to 64-bits and you need to add the -m32 flag to hlib$fc.csh and hlib$mkpkg.inc just like you have to for 64-bit Linux:
In fc.csh (Juan’s Note: in Scisoft OSX, this is /Applications/scisoft/all/Packages/iraf/iraf/unix/hlib/fc.csh) after this:
# Scan the argument list and concatenate all arguments.
set args = ""
while ("$1" != "")
set args = "$args $1"
shift
end
add this:
if ($MACH == "macintel") then
print ("MACINTEL: -m32 flag set")
set args = "$args -m32"
endif
and in mkpkg.inc (Juan’s Note: In Scisoft OSX, this is /Applications/scisoft/all/Packages/iraf/iraf/unix/hlib/mkpkg.inc for each IRAF package you want to recompile) :
I often have to tell people I live in “Fargo-Moorhead” before they have a clue where I live. But then they think I live in North Dakota. This is why I live on the Minnesota side of the Red River.
Nor Pirzkal has apparently been busy fixing the issues I noted in last month’s release of Scisoft OSX given his blog entry:
Scisoft OSX Intel 2009.6.1 Released
This version updates the STSDAS/TABLES packages and a few other packages.
It also fixes the issues pointed out by J. Cabanela
The new version of Scisoft OSX 2009.6.1 differs from Scisoft OSX 2009.5.2 in the following ways:
Stiff was updated from version 1.10 to version 1.12
HEASARC fv.app was updated from version 5.1 to version 5.2.1 and properly installed.
HEASARC hera.app was updated from version 5.1 to version 5.2.1 and properly installed.
HEASARC StudentHera.app was updated from version 5.1 to version 5.2.1 and properly installed.
SAOImage DS9 was updated to version 5.6.3 from version 5.3b.
Interestingly, the STSDAS and TABLESIRAF packages are still version 3.10, so I am not sure what updates Nor refers to above for STSDAS/TABLES.
The only glitch I noticed is that permissions problems persist. Specifically, when the installer installs Scisoft OSX, it appears that a bug in Apple’s Installer program triggers a change in ownership of the /Applications directory to that of the second user on the system. I strongly suggest checking the ownership of the /Applications directory afterward and if isn’t owned by an administrative user, set it as such using:
sudo chown username:admin /Applications
(where “username” is the primary administrator’s username, in most cases, your username) to perform the repair. I know Nor spent a bit of time trying to resolve this without success last summer, so its a glitch that will probably persist.
I also have a minor gripe. This is not a bug, so much a feature I prefer. I like having the X11 command-line version of ds9 available, so I manually installed the current ds9 command line binary into /Applications/scisoft/i386/bin/.
The current version of Scisoft OSX is available for download from the Scisoft OSX website (or will be shortly) and I have made the package available on my Scisoft OSX mirror as well.
When I first started this blog, I was using Apple’s built-in X11, but then with the transition to MacOS 10.5, there were some serious issues with Apple’s X11 implementation having to do with the transition from X11R6 to X.org. One of Apple’s programmers started putting out bleeding-edge updates to Apple’s X11 called XQuartz that fixed a lot of the programs and I have kept using it ever since.
Two years ago, I wrote a blog entry with hints for setting up X11 for the astronomer. The problem is that while the hints in that writeup are still valid, they don’t work if you are using Xquartz because the preferences are stored in a different location for XQuartz versus the built-in X11. As such, I am reproducing those X11 hints here, but with the edits necessary for use with XQuartz.
Once you have installed XQuartz, the X11.app should automatically launch when a program that needs X11 is executed (If you are an old hand at X11, you probably discovered since moving to Leopard that you should NOT set the DISPLAY variable to :0 to display an Xwindow on your primary display, just leave DISPLAY undefined.):
There are many hidden preferences in XQuartz 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 XQuartz preferences, type:defaults read org.X.x11NOTE: If you are still using Apple’s built-in X11 implementation (or if you are using MacOS 10.4), just replace ‘org.x.X11’ with ‘com.apple.x11’ in all the following hints.
In addition to “reading” the preferences, you can write to them. From the command line you can type:
defaults write org.X.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 org.X.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 org.X.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.
You can control which window manager is launched (if you prefer something other than the quartz-wm used by default). 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.
BIG LAPTOP USER HINT: Because XQuartz 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.
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”:
We have had a very cold winter this year. We had one cold snap in December where the nighttime lows dropped to -25 Fahrenheit (that’s -31 Celsius for the rest of the world). However, this new cold snap has been a bit more brutal with daytime highs of about -13 Fahrenheit (-25 Celsius) for the last 4 days. It was so cold yesterday morning (January 15, 2009) here in Moorhead that the temperature at the Moorhead airport dipped to -31 Fahrenheit (-35 Celsius) at 8:14am. At our house in town, the thermometer failed.
It listed the outdoor temperature as “OFL” which means “Off Low End” (I think)… so it was colder than -25 Fahrenheit (-32 Celsius). For fun, the kids and I went outside and decided to throw hot tap water into the air to create clouds. When you throw hot water into air that is this cold, it instantly vaporizes, forming a cloud. The video of it isn’t the clearest, but I think it is pretty cool.
On YouTube I found “Sharon in Minnesota” used extremely hot water from a tea kettle and a spray gun, which makes the droplets much smaller and thus gives you a much clearer cloud.
Finally, a much clearer video of the phenomenon with a simple glass of hot water comes from this poor soul in Alaska where they are dealing with weather about 20 degrees colder than us.
I believe what is happening is an extreme form of what happens to your breath becoming visible on a cold day. The water when thrown suddenly gets a relatively large surface area (allowing cooling) and is scattered into small droplets. These droplets have enough energy to transition to a more solid state, which gives us a visible cloud of tiny particles of ice. A few of the larger drops make it to the ground. I’d appreciate some clarification.
