Urania

A blog named for the muse of Astronomy containing musings by an astronomer

Archive for the ‘MacOS X’


PGPLOT on Mountain Lion 0

Posted on October 20, 2012 by Juan

One of the most popular posts I made on this site was back in 2009 when I wrote about how I got  the increasingly dated PGPLOT package put together by Tim Pearson running under Snow Leopard.  I decided to update that entry to how I approach things today, using homebrew as a package manager under Mountain Lion.  Honestly, these days I do most of my programming and plotting with Python and matplotlib, but I still have old code that needs to be run sometimes, so getting PGPLOT running under Mountain Lion allows me to keep that old software running.

  1. Install X11: You will need to install XQuartz in order to have XWindows support for PGPLOT.  Grab the package installer and install it.
  2. Install Homebrew:   Intall the homebrew package manager.
  3. Install GFORTRAN: The first thing you need to do after installing homebrew isinstall Gnu Fortran (aka gfortran).  This is fairly simple.  All you need to do is say:
    brew install gfortran
    There is a glitch here.  For some reason, the home-brew version of gfortran doesn’t bother to link the gfortran libraries from /usr/local/lib.  To workaround this,  symbolically linked them using:

    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortran.a /usr/local/lib/libgfortran.a
    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.a /usr/local/lib//libgfortranbegin.a
    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.la /usr/local/lib//libgfortranbegin.la

    The exact path to the original gfortran libraries may change if you install a newer version of gfortran! 
     
  4. Once they are installed, you simply have to make sure /usr/local/bin is in your $PATH.
     
  5. 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.txtfile included in the source code tarball).
    sudo tar -C /usr/local/src/ -xzvf pgplot pgplot5.2.tar.gz
  6. 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.  I ended up hacking the sys_macosx/ configuration directory to include a gfortran configuration. I have made a tarball of that configuration directory available in the pgplot5.2_macosx_addition.tgz that you can download and unpack into the PGPLOT source directory using:
    sudo tar -C -xzvf /usr/local/src/pgplot5.2_macosx_addition.tgz
  7. Compile the PGPLOT binaries: At this point, if you follow the instructions in the install-unix.txtfile 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.
     
  8. 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
  9. 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.
     
  10. Create the makefile: We now need to create the makefile using PGPLOT’s makemake script. Within the /usr/local/pgplotdirectory execute:
    sudo /usr/local/src/pgplot/makemake /usr/local/src/pgplot  macosx gfortran_gcc

    which should result in the following output
    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.
  11. Create all the binaries: Now you just have to create all the binaries, which is a simple makecommand:
    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. 
     
  12. Link 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 symbolically linked the versions in the /usr/local/pgplot directory to /usr/local/lib and /usr/local/include respectively using
    sudo ln -s /usr/local/pgplot/libcpgplot.a /usr/local/lib/libcpgplot.a
    sudo ln -s /usr/local/pgplot/libpgplot.a /usr/local/lib/libpgplot.a
    sudo ln -s /usr/local/pgplot/libpgplot.dylib /usr/local/lib/libpgplot.dylib
    sudo ln -s /usr/local/pgplot/cpgplot.h /usr/local/include/cpgplot.h
  13. Making sure I use these PGPLOT binaries: Since I am using SciSoft OSX, I modified my ~/.tcshrcfile 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 ~/.bashrcfile 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. 
     
  14. Installing PGPLOT support in Perl: 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.
    1. 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.17.tar.gz

      It can be easily compiled using the following standard perl module compilation steps:
      cd ExtUtils-F77-1.17
      perl Makefile.PL
      make
      sudo make install
    2. Install the PGPLOT perl module: You can download PGPLOT here. Untar the tarball.
      tar xzvf PGPLOT-2.21.tar.gz

      We start as we usually do for Perl modules, creating the makefile using the Makefile.PL script:
      cd PGPLOT-2.21

      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

      Once you have done that, you can finish installing the perl module using:
      make

      you will see some warnings related to missing type specifiers and non-void functions.  Ignore them and continue
      make test
      sudo make install

      I was able to get the make test to work once I had the proper environmental variable settings for PGPLOT_DIR (see step 13).

So that is it, I now have working PGPLOT installations with perl support on my Mountain Lion Macs.

SciSoft OSX 2012.7.1 Available 0

Posted on August 01, 2012 by Juan

I haven’t been doing much image processing in recent months (something that will be changing as I take charge of the MSUM observatory for the next year).  I just noticed that Nor Pirzkal placed a new version of the 64-bit SciSoft OSX online here.  If you are still transitioning from 32-bit Scisoft, this version of SciSoft OSX doesn’t install over the old 32-bit version, so a simple edit of your start up files can allow you to switch between the two versions.

This version makes a variety of updates to IRAF and pyraf and the underpinnings of those systems.  Specific changes I noticed versus the 2012.3.1 beta I was using

  • IRAF updated to version 2.16 64bit (from version 2.15 EXPORT) which was released on April 13, 2012.
  • STSDAS and TABLES updated to version 3.15 from version 3.13
  • pyraf updated to 1.11 (from 1.10)
  • Python package changes include
  • The ipython interactive interpreter updated to 0.13 (from 0.10)
  • The matplotlib plotting package has been updated to version 1.1.0 (from 1.0.0)
  • The scientific computing packages NumPy and SciPy have been updated.  Numpy from version 1.5.1 to 1.6.1 and SciPy from 0.8.0 to 0.10.0.
  • stsci_python updated to 2.12 (from 2.11)
  • The astronomical ephemeris calculator package pyephem was updated to 3.7.5.1 (from 3.7.3.4)
  • ScientificPython updated to 2.9.1 (from 2.8)
  • The python Monte Carlo stats package pymc was updated to version 2.1a (from 2.0).
  • The python database interface package egenix-mx updated to version 3.2.2 (from 3.1.3)
  • Cython updated to 0.15.1 (from 0.13)
  • New Python packages Quantities (version 0.7), uncertainties (version 1.8), and pymzq (version 2) added.
  • Nor also noted in his release notes that “This version fixed a missing link for SuperMongo and updated the STScI Synphot tables.”

Before installing this version, I backed up the old version of SciSoft OSX using the command line

sudo mv /usr/local/scisoft /usr/local/scisoft_old

(you may not need to ‘sudo’ if you have write permission for /usr/local).  Once the backup was done,  I installed this version of SciSoft OSX by double clicking the installer package.  

Minor Tweaks I Made to My SciSoft Installation After the Installation

  1. Fixing Owenership Issues: To fix ownership issues with some of the files, I performed a

    sudo chown -R root:admin /usr/local/scisoft
     

  2. Updating SAOImage DS9: I noticed that SAOImage DS9 installed by this Scisoft OSX is still at version 6.1 whereas version 7.0 is the current version, so I manually installed the updated version by downloading the MaxOSX 10.7 (Lion) version  DS9 from here.  Once unpacked, there were two files there, ds9 and ds9.zip.  I replaced the symbolic links to the SciSoft OSX ds9 binaries in /usr/local/scisoft/bin with these binaries using the commands when I had the terminal in the ds9 download directory:

    sudo rm /usr/local/scisoft/bin/ds9*
    sudo mv ds9 /usr/local/scisoft/bin/ds9
    sudo mv ds9.zip /usr/local/scisoft/bin/ds9.zip

  3. Living with Enthought Python Distribution: I have been using the Enthought Python Distribution for the last few month, quite happily I might add.  However, SciSoft OSX prefers to use the system’s python distribution and so I have taken to only loading the SciSoft OSX packages into my path when I need them by defining the following command in my ~/.tcshrc (and I use C shell, the native shell for IRAF out of habit):

    alias load_scisoft "test -r /usr/local/scisoft/bin/Setup.csh && source /usr/local/scisoft/bin/Setup.csh"
     

Rebuilding a server for little fun or profit… 0

Posted on May 31, 2012 by Juan

Well, that sucked.  I had my computer start locking up when severing web pages.  Not a hard lock up, but all the httpd processes would become ‘uninterruptible’ and hang.  Eventually this prevented the server for feeding out webpages and required me to hard reboot (aka, push the power button) on the server to reboot it.

As such, I decided to do some spring cleaning and built up the server from scratch, luckily I had backups of everything.  Steps thus far:

  1. Break up a mirrored and stripped RAID array of four 2TB drives.  Given the mirroring didn’t seem to be getting me much more than having a simple second striped RAID of two 2TB drives as backup, I switched to two 4TB partitions.  Had to copy the data back onto the new RAID setup from the backup drive. Total time: 7 hours for first copy, then 7 more hours to make backup that used to be mirrored.  Net gain: I now have 2GB of additional drive space available, even with the backups.
  2. Backup the old boot drive to a backup partition.  Total time: 5 hours.
  3. Wipe a drive and install OSX Lion Server on it. Total time: 1 hour
  4. Copy user files and Applications from old drive to new boot drive.  Total time: 4 hours (but ran simultaneous to the second copy of the RAID mentioned above).
  5. Set up new server to clone itself to backup every day and let those backups run.  Total time: 3 hours.
  6. Setup new web server, including figuring out how Apple sets up server security certificates.  Total time: 3 hours.

It may seem like a lot of time invested, but really, most of the time has been spent copying data from backups… so I multitask and work on other things on my laptop while that is going on.  The big lesson I take away from this.  Having automatic nightly backups is ABSOLUTELY ESSENTIAL to making this kind of changes relatively quickly.  My resistance to making this kind of change would have been much larger if I thought I might lose data and didn’t think I could just switch boot drives and go back to my old set up in case I had screwed things up.

So at this point, I have checked, all my old applications seem to be running and the website is back up.  The only problem I have is that PHP doesn’t seem to be properly loading the SSH2 extension.

Another Update to Clear Sky Clock (Now Supporting Accented Characters) 0

Posted on October 03, 2011 by Juan

A Quebec-er informed me that certain sites in Quebec were not showing up in my Clear Sky Clock widget.  An investigation revealed that JavaScript doesn’t understand Unicode characters in its regular expressions.  A bit of thinking revealed a much simply regular expression that would match the site names from Attilla Danko’s Clear Sky Chart website.  So I have fixed the widget to support all accented characters, and for that matter, any name that the Clear Sky Chart presents.  The accented characters may appear as ‘diamonds’ in the menu, but selecting the sites will work now.

You can download this MacOS X widget from here.

If you have the old version installed, you can simply quit the widget, then replace the installed widget with this one.  You may have to log out and log back in for the new version of the Clear Sky Clock to be loaded after installing the new version.

Update to Clear Sky Clock Widget for OSX Dashboard 0

Posted on August 12, 2011 by Juan

In mid 2008 I spent some time learning JavaScript well enough to update and fix the Clear Sky Clock widget for the OSX Dashboard. This widget, developed by Joshua Lynch, pulled Attilla Danko’s Clear Sky Chart images (example shown above) and displayed them on the Mac Dashboard. However, it was not parsing the locations properly. I fixed the location parsing and added a built-in legend and the ability to resize the widget and released it under a GPL license.

This morning I was alerted by Bruce Krobusek to the fact that the widget was no longer allowing users to select a location, at least with the current Snow Leopard and Lion releases. I had not seen this problem because once you had the widget configured (as I did under Leopard), the settings were saved. However, new users could not change the location from the default of Minneapolis, Minnesota without a bit of hacking on the preferences files. After a bit of digging around, I found the glitch in the location parsing. I am not certain, but I believe this failure was occurring due to a change in JavaScript. There were no changes to Attilla’s website where the widget gets its list of locations. In any case, I have fixed the bug and everything seems to be working again.

The new widget, version 1.4, is available at my Clear Sky Clock widget website. If you have the old version installed, you can simply quit the widget, then replace the installed widget with this one. You may have to log out and log back in for the new version of the Clear Sky Clock to be loaded after installing the new version.

Scisoft OSX 2011.4.1beta available and IRAF as a package install from STScI! 0

Posted on May 24, 2011 by Juan

New version of Scisoft OSX 64-bit beta available

I just noticed today that, over a month ago, Nor Pirzkal placed a new beta of the 64-bit SciSoft OSX online here.  I have not had as much joy with the 64-bit version of IRAF as with the older ones.  That said, this version of SciSoft OSX doesn’t install over the old 32-bit version, so a simple edit of your start up files can allow you to switch between the two versions.

I backed up the old version of scisoft using the command line

sudo mv /usr/local/scisoft /usr/local/scisoft_old

and then I installed this version

sudo tar -C / -xzvf scisoft.current.tar.gz

(you may not need to ‘sudo’ if you have write permission for /usr/local).  I’ll report back if anything interesting changes.  The CONTENTS file only noted that ncftp 3.2.5 had been added.  Not sure why an FTP client was added unless it was needed by some other package.

One note is that I have been experimenting with Enthought’s Python Distribution and have it over-riding the python packages installed by the Scisoft OSX installation, so I may have to play around a bit to get PyRAF working again.  Or I may drop SciSoft OSX altogether (since its Python interferes with Enthought).

STScI makes MacOS X Package Installer version of IRAF available

In the process of looking at PyRAF, I was pleasantly surprised to find that STScI now has a package installer available for installing IRAF+STSDAS/TABLES and all the corresponding files needed for STSCI Python in a single click.  It is only for 64-bit Macs.  I will have to look this over in the future, but it apparently installs everything in /usr/scisoft so it will not collide with anything. However, it also requires a new installation of gfortran which I already know can break my PGPLOT installation.

Securing your Snow Leopard Web Server 0

Posted on April 05, 2011 by Juan

I run several blogs as well as some WebDAV servers on my MacOS X web server, all of which use passwords to authorize access.  I recently decided it would a good idea to support HTTPS (secured, encrypted HTTP) on my web server so that my passwords for accessing my blogs and webDAV server were not sent plaintext and unsecured over the internet.

Initially I had balked at this because the typical SSL Certificate, needed to encrypt and decrypt the traffic from the web server, cost on the order of $100 per year if signed by a Certificate Authority (one of the companies that all the web browsers come set up to ‘trust’ as signers of SSL certificates).  Such a digital signature is necessary if you want your https connections to be recognized as trusted by all web browsers.

However, I recently learned that it is possible to simply ‘self-sign’ your SSL certificates and so long as you only need the encryption for yourself (for example, when using a password to log in as an admin on a blog), this is a free solution that works.  The certificate will not be marked as ‘trusted’ by any authority, but if you can trust it, it will allow you to encrypt the traffic to and from your web server.

The solution I outline below is partly based on a hint provided at MacOSXHints for getting a full Certificate Authority signed certificate installed (here) and a hint from the CentOS wiki (here) for self-signing your certificates.

I’ll outline the procedure I used below, but as a warning, you need to have a familiarity with the command line and the use of sudo.  I am also assuming you are using Snow Leopard (MacOS 10.6.x).

  1. Create Directory to store certificate: Start by creating a directory you want to place the certificates in and then “cd” into that directory on the command line.  I used /etc/apache2/local_certs/ as my directory.
  2. Generate the Private Key file: Next, from the command line, generate a private key:
    openssl genrsa -out ca.key 1024
    during the command the output should look like this:
    Generating RSA private key, 1024 bit long modulus
    ........++++++
    .......................++++++
    e is 65537 (0x10001)
  3. Generate a Certificate Signing Request file: Next you need to generate a certificate signing request. You won’t ask anyone else to sign this, but you need it in order to create the public key file. So from the command line type:
    openssl req -new -key ca.key -out ca.csr
    and you will be asked a series of questions. Your answers should be as follows:
    1. For Country Name (2 letter code) answer with the two letter code for your country, for the United States it was “US”.
    2. For State or Province Name (full name) I answered “Minnesota”.
    3. For Locality Name I entered my city.
    4. For Organization Name I entered my name (Juan Cabanela) since this is a server run by my school, but not managed by my school.
    5. For Organizational Unit Name I just hit “enter” and left it blank, your answers may vary.
    6. For Common Name I entered by server’s URL iparrizar.mnstate.edu.
    7. For Email Address I used my email address. It appears in the certificate so I suppose it could lead to spam, but I figured it was better to give people stumbling across the certificate an email address they could contact for questions.
    8. For A challenge password and An optional company name, I hit enter. I don’t expect to need to get the certificate signed.
  4. Generate a Public Key file: The last step in certificate creation is you need to generate the self-signed public key which will actually be what users get when they access your server. The user uses this public key which decrypts the traffic the web server will encrypt with the private key (only accessible to the web server).  To generate the public key file, use the command line to run:
    openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
    This will only make your public key valid for 365 days, you might want to change this if you don’t want to have to generate a new public key every year.
  5. Set up the web server: Now you have to edit your MacOS web server configuration to support encrypted HTTPS traffic.  This comes down to editing two files. ou will need ‘admin permission’ to edit both of these files, so you will either need to use sudo with a command line text editor (like vi or emacs) or you will need to use a text editor that supports editing files with ‘admin’ permission. The changes you need to make are the following:
    1. Open the main web server configuration file, /private/etc/apache2/httpd.conf, in a text editor and uncomment (remove the leading ‘#’ from) the following line (it’s line 473 in my installation):
      Include /private/etc/apache2/extra/httpd-ssl.conf
    2. Edit /private/etc/apache2/extra/httpd-ssl.conf and make sure the following lines are set as follows:
      • SSLCertificateFile points to /private/etc/apache2/iparrizar_ssl_new/ca.crt or where ever you have your ca.crt file you created in step 4. SSLCertificateKeyFile points to /private/etc/apache2/iparrizar_ssl_new/ca.key or where ever you have your key file you created in step 2.
      • Make sure the lines containing SSLCACertificateFile and SSLCARevocationPath (these are two seperate lines) are commented out (add a leading ‘#’ to each line). Since these certificates will not be signed by a certificate authority, you have no need to point people to CA certificate files or revocation paths.
  6. Restarting the web server: Now all you should have to do is restart you apache web server and see if everything works. From the command line type:
    sudo apachectl restart
    This should restart the web server.  Assuming no error messages appear, you can next test the connection.
  7. Testing the web server: See if you can go to your web server using https://your.domain.name.here/ as the URL in your web browser. You will be presented with the ‘untrusted’ certificate and asked if you want to accept it.  In Safari on the Mac, accepting the certificate adds it to the Keychain.  I am not sure about where Firefox or Chrome store the certificate, but they should hold on to it for future use, ensuring your future connections to the web server are secure (if done via “https”).
  8. Bonus Step for iOS device users: If you want to add these self-signed certificates to your iOS device, you can do this by simply ‘exporting’ the certificate as a ‘crt’ file from the Keychain (or finding the original “crt” public key file you created earlier).  Email that public key .crt file to yourself and open that email on the iOS device.  If you click on the attached certificate in that email you will be presented with the option of adding that certificate to your iOS profile.  Doing so will allow Safari and other programs on the iOS device to connect securely to your web server.

Papers2: Not ready for prime time 0

Posted on March 08, 2011 by Juan

papers2 really still a betaOne of the programs I use almost daily now that I am on sabbatical is Papers by Mekentosj B.V. Papers really helps you organize your reading, allowing you basically an iTunes-like interface for organizing PDFs.  While it originally seemed to be aimed at medical researchers, it has supported ADS abstract searches for quite some time.  Its ability to store metadeta outside the PDFs in a searchable database made it a powerful tool for me.

For the last few weeks, Mekentosj B.V. has been promoting the release of Papers2 and it has some really interesting new features.  The ones that stood out for me were:

  • Ability to attach other sorts of files (such as ASCII data tables) to a paper in the database.
  • The ability to search multiple online search engines (ADS abstracts and Google Scholar, for example) simultaneously.
  • “Magic Manuscripts” which basically seemed like a citation manager to integrate Papers into almost any writing environment.

This morning, I downloaded and purchased the update to Papers2.  It is clear the developers had some idea of how important Papers is to people in that they made the update create a whole new database instead of wiping out your old one.  You don’t even have to shell out any money, as Papers2 has a fully functional 30-day trial mode.  This means if you are a Papers user, trying out Papers2 is a safe thing to do.  And while I paid for the update (since I trust the developer to improve the product over time), I would suggest you NOT do so until you have throughly tested it, especially if you are a Papers user already.

Papers2 is a complete re-write, so problems were bound to exist.  This is after all a .0 release.  However, in a few hours of experimentation with Papers, I have found it to be much buggier than Papers.  Papers2 is also missing some features I had come to rely on.  The developers are clearly aware of this as one of the web pages they link to within Help menu of the app is a link to their “Future Roadmap,” a lot of which seems geared toward bringing features back that were in Papers.

Among the problems I have experienced this morning:

  1. Activation problems: The license I purchased is supposed to allow registration and activation of Papers2 on two computers.  The activation failed on the second computer and I have not heard back from their (probably overwhelmed) tech support about this yet.  I am sure this will be resolved as they have very good tech support, but it is annoying. [Tech support didn’t respond to my email but a re-attempt a bit later did activate my second copy of Papers2.  I suspect an overloaded activation server. – March 10 3:45 pm CST]
  2. No synching available, yet: I use Papers on my iPad to carry my collection of papers with me on the road.  Apparently, syncing, even though advertised in the app as a feature.  When I reported it, the response was that synching is not available until the next update of the iOS app (which has already been submitted to the Apple for review).  I understand that Mekentosj B.V. can’t control Apple’s App Store acceptance timetable, but then make it clear the feature is not yet available or is pending the release of the new version of the iOS app.  It does say this in small print, but it is not clear enough in my mind.
  3. Missing AAS citation template: Its a small thing, but of the 1400 citation styles built-in in the Manuscripts Preferences, only one is astronomical and it is not one I use.  The American Astronomical Society format (used for the Astronomical Journal, Astrophysical Journal, and Publications of the Astronomical Society of the Pacific as well as many conference proceedings) is documented, I’d like to see it added.  I suspect I can add my own, but it would have been nice for it to have been built in.
  4. Refreshing Smart Collections: I have a smart collection set up to identify all papers not already in a collection.  When I file a paper in a collection, this smart collection doesn’t reflect that until I either restart Papers2 or control click on the smart collection and say “Edit Collection” to re-setup the collection.
  5. GUI bugs: There are various GUI errors I have run across.
    1. Occasional Lockups in “Match to Repository”: Attempts to “Match to Repository” an article usually brings up a one line interface for attempting to match an article’s metadata, but occasionally the program doesn’t seem to respond properly.
    2. Metadata column disappearance bug: I have a reproducible bug [as shown in the video below] where if I use the “View Mode” button more than 3x on a given paper, it locks up with the “View Mode” button grayed out and disabled, no longer allowing you to view the meta data.  Furthermore, it is clear that this bug is stored in a preference file, because relauching the app leaves you with the same disabled View Mode button.  I have reported the bug to the support forums and have at least one other person seeing the bug there.  [WORK AROUND DISCOVERED: I have confirmed that if you move your mouse to the right edge of the window after the right metadata column has disappeared, you have the ability to drag the panel back open as suggested by “Good and Bad”in their comments in the support forum. – March 10 4:00 pm CST]
    3. Failure to reimport article: An attempt to connect a arXiv preprint to the final peer-reviewed paper produced an interesting bug.  The new paper was found, and when I try to add the PDF, it reports it can add it as supplemental material, but all choices I make produce a “error” beep and the program doesn’t offer a way out of this.  Makes importing articles dangerous.
  6. Searching for metadata is crippled: Searching for articles on the ADS abstract server appears to only allow searches by paper author and maybe title (this problem was also noted by Bryan Gaensler).  It is no where near as robust as searching in Papers, which allowed your to indicate the title, author, year, and other pieces of metadata for your search.  That said, this crippled search is on their list of “Missing Features” in their “Future Roadmap” so it is clear they are working on fixing this.  

    [I will note that my critique below, while valid for how poor the search capability is compared to Papers, may also be a bit unfair, since Papers2 has a very different approach to metadata matching.  In the days since the release of Papers2, the folks at Mekentosj have been releasing videos to better explain the new search approach.  There are two videos of note regarding this: (1) a tutorial video here that explains Papers2’s approach to metadata and  (2) a video illustrating how to use specific tags in searches.  I don’t know yet if BIBCODEs can be used with ADS searches, but it is clear that it doesn’t default to this and so it is still not as easy as Papers was in its searching, at least for astronomers. – Added March 13 12:15 pm CDT]

    But this problem also affects the ability to match papers to their metadata.  When the “Match to Repository” dialog is used, its ability to search is so crippled [as shown in the video below] that I have not managed to get and article matched to its metadata yet (since I can’t pull up the correct article to match it with.  This reduced search capability is also giving some people pause on the support forums.  “Jonathan” on that forum page stated something I agree with:

    It appears as though the developers tried to simplify and automate the matching process, but in doing so, oversimplified and compromised a critical function. Although I have been looking forward to the new version, I have had no choice but to revert to Papers1 until this is addressed (hopefully a.s.a.p.).

    “Matias” from Mekentosj B.V. does respond that

    We’re looking into this — degrading the matching user experience certainly isn’t the plan and we will either re-introduce the matching view from Papers1 or improve the automated matching behaviour in an upcoming update (most likely both). Please also keep Papers1 still around and only migrate once you’re happy with the experience that Papers2 gives you.

Because of the GUI interface glitches and the compromised matching ability compared to Papers (version 1.9.7), for now I will be sticking with Papers for my work.  Am I concerned about the future of Papers2?  Not at all! Mekentosj B.V. has had a very good record, at least as I have seen with Papers, of addressing bugs and adding features as time goes on.  I am sure, in a few month, Papers2 will be part of my arsenal for organizing my research reading and writing… but it is not there yet.

Experimenting with a little Homebrew 0

Posted on March 01, 2011 by Juan

Well, today it finally happened.  I got sick and tired of MacPorts behavior of replacing every binary already included in the Mac OS with its own version.  I don’t need two versions of perl or python installed on my Macs and I am getting tired that every time I try to install a port, it insists on installing a complete perl/python installation or its own set of libraries the MacOS already has built in,  in order to install a small utility.  I know that MacPorts has some justification for this, but it seems messy to me.

As such, I started looking for alternatives and came back to homebrew, which I had discovered a few months ago.  It is a package management system in which everything relies on already installed Mac binaries/libraries as much as possible.  By default, homebrew packages are installed into their own isolated directory (/usr/local/Library/Cellar/) and then symlinked into /usr/local/bin, /usr/local/sbin, or /usr/local/lib directories as needed. But it is flexible enough that you can install it where ever you want and it will still run.  Another nice feature, it doesn’t require you install it as root, it can run completely as the user permission level!

The negatives of homebrew:

  1. There are no where near as many packages (they call them “Formula”) are available for Homebrew as for MacPorts or Fink.
  2. For an astronomer, another big problem, there is no TeX under Homebrew.

It turned out the first negative was a bit of annoyance, but I was willing to live with it because the installation was so much cleaner and most of the important packages I needed MacPorts for were already there.  The second negative turned into a postive because I discovered here is a very easy to install MacTeX package available now that installs a complete TeXlive installation, including AASTeX, by default!  It even has some nice GUI controls included for keeping it up to date.

What follows is a description of what I did to transition from MacPorts to HomeBrew+MacTeX.

  1. Backing up MacPorts: No need to not have a way to change my mind if this blows up in my face.  I backed up my entire MacPorts installation by using the command

    tar czvf /opt_backup.tgz /opt

    and then when that was done, I had a 1.6 Gig tarball at the root level of my drive called opt_backup.tgz.

  2. Disable MacPorts: At this point, I deleted the /opt directory and commented out the commands in my ~/.tcshrc that added those directories to the PATH environmental variable.   If you use the default bash shell, you will need to edit ~/.bashrc to disable MacPorts.
  3. Install Homebrew: Following the directions on the Homebrew site. I originally wanted to place homebrew in its own custom install directory (/usr/local/homebrew).But after reviewing the Homebrew installation documentation, I came to realize that using the default /usr/local location for the install makes the most sense.

    I did this in the recommended manner, using the install script, which does some nice permission checking to make sure things will run nicely before installing. Since my default shell isn’t bash, I had to switch to it, then just run the install script from the command line:

    bash
    ruby -e "$(curl -fsSLk https://gist.github.com/raw/323731/install_homebrew.rb)"

    The first time I ran it, it failed because my permissions for /usr/local had been tweaked. So I had to run the command

    sudo chown -R root:staff /usr/local

    to get the permissions so the script could run.

  4. Activate Homebrew: Since I am not using a custom directory for the installation, there is not configuration needed in terms of setting up the environment. /usr/local/bin/ is in the default PATH, so as soon as I start up a new terminal window, homebrew is available! Otherwise, I would have to edit my default ~/.tcshrc or ~/.bashrc to add the homebrew binaries directories (bin and sbin) to the PATH environmental variable.
  5. Install my favorite packages using homebrew: Installing packages in homebrew is just a matter of making sure the Formula for the package exists (all the publicaly available Formula are here) and then typing

    brew install (formula name)

    So for example, installing CFITSIO was just a matter of typing:

    brew install cfitsio

    Actually, this was for the most part simple for my attempts to install git.  It kept crashing with an error that said:

    The current directory must be set to the ITT directory.

    Well, ITT is the vendor of IDL (a package commonly used by astronomers for data reduction) and I discovered that I had accidentally set the IDL binary directory to be in the PATH ahead of the default system directories.  This meant the IDL version of a binary called install was replacing the system default version of this.  Just the kind of problem I was trying to get away from in MacPorts.  I  changed to my ~/.tcshrc to make sure the IDL binaries directory was later in the PATH than the system directories fixed things.  The only package this affected the install of was git, all the other packages installed without a hitch thus far.  The other brew formulae I installed were installed with the following commands:

    brew install subversion  imagemagick ghostscript macvim lynx coreutils findutils plotutils

    I can get a list of all the packages I have installed using the command:

    brew list

  6. Installing MacTeX: This was extremely easy, I downloaded the MacTeX 2010 package (The version I got was dated 10 Sept 2010 and was 1.6 Gig) and then uncompressed it and double clicked it. It installs using the Mac Installer. I did make sure to customize the install to remove some of the stuff I didn’t feel I needed, but I kept the GUI tools. Turns out there is a nice TeX Live Utility installed in /Applications/TeX that lets you customize which TeX packages are installed and can automatically update things. Review of this tool also showed a very astronomer friendly decision to include AASTeX by default! The TeX installation is in the /usr/local/texlive/ directory and it installs a symlink at /usr/texbin/ to all the LaTeX binaries. I added the following lines to my ~/.tcshrc file to get the tex binaries in my PATH:

    # Set up MacTeX 2010 by including path to that installation of LaTeX
    setenv PATH ${PATH}:/usr/texbin

So there you have it, how I went from using MacPorts and the literally hundreds of packages to support the few I wanted to trimming things down to a few packages in homebrew and one double-clickable TeX installer.

[Edited on Mar. 2, 2011 11:04 am to update the instructions to the default homebrew instructions, which are cleaned and easier to implement.]

Mac Apps for the Professional Astronomer 2

Posted on June 01, 2010 by Juan

I was asked by one of my colleagues who was late to switching to a Mac (from linux) what the necessary software is for an astronomer to have on their Macintosh. Some lists of this sort have been assembled online, however most are no longer available. Some resources I was aware of that were still online as of this writing (Summer 2010) were

  • Jane Rigby’s (Carnegie Observatories) OS X for Astronomers: This site is a fairly complete listing of Mac software the Professional Astronomer would be listed in. However, she uses “Fink” whereas I prefer “MacPorts”. To each their own.
  • MacOS X for Astrophysicists: This site is a bit dated (last update 2007) but there is a lot good information about how to configure X11, LaTeX, etc. on the Mac.
  • MacResearch: Focused more generally on using a Mac for research (notably programming), this site is a good read even if not astronomy focused.

My approach here will be to list everything I use on a regularly basis in my research. I will warn you up front that I am an optical astronomer who as dabbled in some radio astronomy, but I don’t know anything about High-Energy packages. So that is one bias. Secondly, being a college professor at a smaller state institution, I tend to focus on free (as in beer) or inexpensive software although I will list a few programs that I think are definitely worth the money for professional astronomer.

Programming/Unix Environment

There is some stuff any astronomer using a Mac should install, because it is free and/or critical to using your computer as a competent astronomer (depending on your specialty)…

  • XCode: You will need the gcc compilers in many cases and they come with the OS, so you might as well install them. If you want to get the most current Xcode, you can download it from the Apple Developer Connection website (you will need a free account).
  • g77/gfortran compilers: If you need a g77 (for MacOS before 10.6) or gfortran compiler, the best place to get pre-built binaries is at the High Performance Computing of MacOS X website.
  • X11: X11 is an optional install under Tiger and is installed by default under Leopard. However, when in Leopard, Apple switched from Xfree86 to X.org, and this transition introduced some advantages (no DISPLAY environment setup necessary…. yeah!) and some bugs (Boo!). As such, I had been using XQuartz in Leopard, which remain a few steps ahead of Leopard’s X11 and easily installed over it. However, I have found Snow Leopard’s X11 installation stable and robust enough to not replace it with XQuartz any more.
  • MacPorts: The bane of many unix-style OSes these days is the package manager one uses to install the unix-style programs with all their dependencies. I have settled on MacPorts. I used it’s “competitor” Fink for a while, but I have found MacPorts to generally be a much more up-to-date package manager. I use it to install TeTeX and a multitude of CLI programs (PGPLOT, gs,gv,gsl,xephem).
    • Porticus: is a decent (free) GUI front end for MacPorts if you fear the command line.

For the Optical Astronomer

This is the data reduction software I use almost every time I work on my research…

  • Scisoft OSX (My Mirror): IMHO the simplest way to install IRAF and many other packages I use regularly (PGPLOT, WCSTools, Sextractor, CFITSIO, etc.) in one double-click of a mouse (and some editing of my .tcshrc file).
  • SAOImage DS9: I sometimes update the version of DS9 included in SciSoft OSX with the most current versions from the CfA.
  • HEASARC’s fv: They call it the “Interactive FITS File Editor” and frankly it sometimes is the easiest way to quickly see the contents of a complex FITS files.
  • JSkyCalc: This venerable observing planning software that used to be solely for the command line (when it was skycalc) has now been updated to a graphical user interface written in java, so it runs on almost any platform, including Mac OSX. For the Mac, just save the jskycalc.jar file someplace and double click on it to launch it.
  • IDL: Definitely not cheaper (but cheaper than it used to be). Some astronomers I know swear by it (I have been known to swear at it). Personally, I do need the power of IDL sometimes, especially when someone else provides me her/his IDL code. If you use it, you will probably want to grab the IDL Astronomy Users Library which provides a large number of pre-built IDL routines for the astronomer. If you are feeling cheap, you might be able to get away with GDL (from High Performance Computing)

For the Radio Astronomer

This is the data reduction software I played around with when reducing radio data. I can’t claim I am current on the state of the art, so let me know if you feel I am missing something here.

  • AIPS: When I was doing more radio astronomy, I was working with AIPS a lot. I helped in the process of getting it working under MacOS (as a guinea pig). It ran quite nicely under MacOS the last time I used it (about 2004).
  • CASA: CASA (formerly AIPS++) is a sort of successor to AIPS. Personally, I was never that impressed with it, but I know several people who like using it (such as folks involved with ALMA). It is available for Mac OS 10.5 and 10.6 (Intel Macs only).

Writing Tools for Astronomers

Writing either documentation or papers for peer-review publications can be a challenge. For informal work, I have quite happy using Apple’s Pages for written work or Apple’s Keynote when assembling a poster or set of slides. However, for peer-reviewed journals or NSF applications, I typically use latex, having installed tetex with MacPorts.

  • Texmaker: is a nice interface for writing LaTeX on the Mac. Certainly not perfect or as good as some commercial products I have seen, but it is free and it works well. I especially like it when used with the Skim PDF reader which allows in-window updating of the PDF.
  • Papers: This is an awesome package for organizing your personal library of publications. It provides (somewhat glitchy) ADS Abstracts and arXiv interfaces that allow you to match PDF files to their metadata. Once you have done this, you can search for you local library by the words in the title, abstract, author’s name, year of publication, etc. And you can keep your PDFs organized. It has been a wonderful way for me to keep track of everything I have been reading when I have to prepare a paper.
  • iWork: is a very useful package from Apple that acts as a lower cost replacement to Microsoft Office (if all I cared about were cost, I would use OpenOffice.org). However, I use it because it includes:
    • Keynote: Keynote is a much more polished presentation manager than PowerPoint.
    • Pages: I prefer pages for my word processing and MacResearch had a compelling article on why you might use Pages for grant applications.
  • MathType 6: I would recommend also getting MathType 6, which let’s you insert equations into Pages or Keynote with ease (and it accepts LaTeX as a way of building equations). Make sure to update to the current version, it avoids a lot of crashing bugs.
  • LaTeXit: If you don’t want to pay for a commercial program, LaTeXit is a great option for typeseting formulas with LaTeX. It allows you typeset and then drag the results into Keynote or Pages documents where they are inserted as PDF images.
  • Evernote: I don’t use Evernote solely for writing papers, it is just a place to toss little notes I used to keep on post-it notes. But if I want to save some webpage or some text for later use, it is a perfect tool for that. It can sync between Mac and iPhone/iPod touch and it is free for up to 40 MB of notes a month.

Astronomically Useful Widgets

Widgets have been in MacOS since version 10.4 (Tiger), and while I don’t find them terribly useful, there are some free Widgets can be useful to have on observing runs:

  • Clear Sky Clock Widget: I may be biased since I helped re-work this widget and am responsible for the current version, but is useful as a way of displaying the current Clear Sky Chart (formerly called “Clear Sky Clock”) on your desktop. Clear Sky Chart is only useful for astronomers in North America.
  • AstroTimes Widget: I am not sure if this widget is still available, but it was a quick way to see the Local Sidereal Time when observing.

Astronomically Useful Spotlight Plugins

Spotlight is a feature that has been built-in to MacOS X since version 10.4 (Tiger). It indexes the contents of files to allow for almost instantaneous searches of the contents of a hard drive. The built-in plugins search many file types, but the following additional plugins are useful for file formats astronomers commonly run into.

  • FITSImporter: This plugin allows Spotlight to index FITS file headers.

Astronomically Useful QuickLook Plugins

QuickLook is a feature that has been built-in to MacOS X since version 10.5 (Leopard). When in the Finder, selecting a file and tapping on the spacebar displays a preview of the file. As with Spotlight plugins, many common file formats are supported with the built-in plugins, but for file formats astronomers commonly run into some plugins can be useful.

  • QLFits: This QuickLook plugin allows easy previewing of FITS file headers and images/spectra from the Finder.
  • QLColorCode: This QuickLook plugin displays source code files with syntax highlighting making QuickLook a much more powerful way of previewing code.
  • EPSQuickLookPlugIn: Allows viewing of encapsulated PostScript files via QuickLook. Since most figures I embed in my papers start as EPS files, this is very useful to me.

The Less Obvious Stuff

Some software doesn’t fit well into a particular broad class of work astronomers do, but can come in useful all the same for specific tasks.

  • User Interface Enhancements:
    • ShellHere.app: Drag this to your Finder winder and from now on, if you want to open the Terminal at a location corresponding to a given Finder winder, all you you need to do is click on the ShellHere icon. Works great, sort of the counterpart to “open .” in the terminal opening up a Finder window.
    • QuickSilver: Why waste your time digging through the Finder? I use QuickSilver to launch programs, access frequently used documents, and basically streamline my use of my Mac. Its the swiss army chainsaw of launchers.
    • GeekTool: This is an awesome little tool that allows you to display almost anything on your desktop. I use it to display my weblogs and system logs to my desktop, along with the local weather conditions and Doppler radar image. Anything you can display in the shell can display on the desktop.
  • A backup solution beyond Time Machine! Time Machine (part of Mac OS since version 10.5) is wonderful for incremental backups, but if your boot drive fries, you can’t boot from your Time Machine backup. This is why I also clone my boot drive regularly.
    • Carbon Copy Cloner: This is a free way to clone your boot drive on the Mac.
    • DejaVu: If you want an more automated solution, I prefer DejaVu, which runs scheduled rsync sessions in the background. That way, my backup drive is constantly updated and when my boot drive fails, I can just switch over to the backup without losing a beat.
  • Versions: Actually, I can’t say I ‘recommend’ Versions per se. I would strongly recommend subversion or some other version tracking system for anyone who writes code regularly. It makes tracking edits to source code (and latex documents) a breeze. I happen to use Versions as a very nice GUI that allows quick examination of differences between different versions of the source code you have tracked. That said, it is not cheap and I think SynX is a perfectly adequate free GUI front-end for code version tracking with similar functionality, if not as polished.
  • Parallels/VMWare Fusion/VirtualBox: If you occasionally have to run software that only runs on that other platform (you know, Linux), virtualization software is quite useful. I have found both Parallels 5 and VMWare Fusion 3 to be quite good (I found Parallels to be faster, but I heard VMWare was catching up). VirtualBox is free (as in beer) and may be an option to try before shelling out money for commercial virtualization software.
  • Chicken of the VNC: At several observatories, I am required to use VNC to interface with the computers. Chicken of the VNC works as a client. There are commercial VNC clients that are a bit faster, but if you have decent bandwidth, this works fine.
  • Wx: As an frequently optical astronomer, I sometimes obsess about the weather. Of all the weather programs out there, I have found this one to be the most stable and flexible. Its relatively inexpensive ($16.95 US), but as a warning, it is limited to the United States.
  • OmniFocus: This program is probably the single most useful program I have for managing my time. It implements David Allen’s Getting Things Done approach to time management. Its not cheap, nor is it completely intuitive… but it is absolutely necessary for me. A iPhone version also exists, which allows syncing of your OmniFocus sessions between your Mac and iPhone/iPod Touch.
  • DropBox: If you look at DropBox for the first time, it just looks like a way to sync files between computers. That is, until you realize you can allow specific users to share specific directories. I use it to share files to big to email with collaborators all the time. The only warning, it currently doesn’t map out extended attributes of files (like the executable settings) between computers, so it is not good for shell scripts. This failing is supposed to be fixed in the current version 0.8 beta.
  • fseventer is useful for diagnosing programs that create files. It tracks all file system events as long as it is on. So if you want to know where an installer is tossing files around your system, this will help you see what is happening. Its rare that I need it, but when I do, it is a Godsend.

[I made some minor edits adding some links I had forgotten about. – June 1, 2010 11:45 am CDT]

PGPLOT on Snow Leopard 28

Posted on October 23, 2009 by admin

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).

  1. Determine 32/64-bit nature of hardware: Since a lot of people don’t know a priori whether their processor is 32 or 64-bit, here’s a simple command line test.  Type the following into the command line:
    sysctl hw | grep 64bit

    If the response is
    hw.cpu64bit_capable: 1

    you have a 64-bit system. If the response is
    hw.cpu64bit_capable: 0

    you have a 32-bit system. If it is something else, well, you are on your own!
  2. 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.

  3. 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
  4. 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 64-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)]
  5. 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.
    1. 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
    2. 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.
    3. Create the makefile: We now need to create the makefile using PGPLOT’s makemake script. Within the /usr/local/pgplot directory execute:
      sudo /usr/local/src/pgplot/makemake /usr/local/src/pgplot  macosx gfortran_gcc

      which should result in the following output
      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.
    4. 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)]
    5. 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
      sudo cp *.a /usr/local/lib
      sudo cp *.dylib /usr/local/lib
      sudo cp *.h /usr/local/include
  6. 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.
  7. 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
  8. 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.

 

[Edited on December 28, 2009 to add the first step to determine whether your system is 32/64-bit.]

SSH2 extension activation in PHP 5.3.0 4

Posted on October 13, 2009 by admin

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:

  1. If you haven’t already, start by installing libssh2 via MacPorts using the command:
    sudo port install libssh2
  2. Download the necessary SSH2 PHP extension using the build in PECL command
    sudo pecl download channel://pecl.php.net/ssh2-0.11.0
    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

    This is occuring because there is an incompatibility between this ssh2 extension code and PHP 5.3.0. It can be patched by downloading the ssh2-php53.patch file from http://remi.fedorapeople.org/ssh2-php53.patch and applying the patch from the command line in the ssh2-0.11.0 directory
    curl -o ssh2-php53.patch http://remi.fedorapeople.org/ssh2-php53.patch
    patch < ssh2-patch53.patch
    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/

  3. 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:
    extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20090626/"

    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.

  4. 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.

  5. 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.
  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin



↑ Top