• Eclipse 5.0.0 has been added to the distribution. Eclipse is an Integrated Development Environment (IDE) for programming. I don’t find it to be terribly useful, and in fact find it fairly awful in its implementation for IDL, but I am sure there are many people who disagree (enough to foster development of five major versions of it).
• Gnuplot has been updated to version 4.2.5 from 4.2.3
• Eye 1.4.1 has been added to the distribution. Eye is a program designed to allow you to use an artificial neural network to construct SExtractor filters for “adaptive filtering, feature detection and cosmetic corrections.”
• Swarp was updated to 2.17.6 from 2.17.1
• WeightWatcher was updated to 1.8.10 from 1.8.7
• The Python distribution was updated to version 2.5.4 from 2.5.2 and the following python packages were updated:
  • ipython updated to 0.9.1 from 0.8.4
  • Numpy updated to 1.3 from 1.1.1
  • pyfits updated to 2.1.1 from 1.1 (or this could be a typo in the old CONTENTS)
  • matplotlib updated to 0.98.5.2 from 0.98.3
  • pyraf updated to 1.7.1 from 1.6
  • stsci_python updated to 2.8 from 2.6
  • AstroAsciiData updated to 1.1 from 1.0
  • scipy updated to 0.7.0 from 0.6.0
• The STSDAS and TABLES IRAF packages were updated to version 3.10 from 3.08
• fftw library version 3.2.1 added. This will be useful to me since we have been using fftw in the computational physics class I have been teaching this semester.
• I noticed the Aquaterm.app application (used for graphics display by PGPLOT and Gnuplot) is now pre-installed in /Applications/scisoft/i386/Applications/.

Some minor glitches I have noticed in this distribution

1. Permission Problems Persist: 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.
2. Older SAOImage DS9 included: I noticed that the SAOImage DS9 distributed with this version of Scisoft OSX is version 5.3b, whereas the current version is 5.6.1, so I manually installed the current ds9 command line binary into /Applications/scisoft/i386/bin/ and the current Aqua application into /Applications/scisoft/i386/Applications/ and everything is working fine there.
3. HEASARC fv.app not installed: The fv.app application in the /Applications/scisoft/i386/Applications/ is actually a second copy of studenthera.app, misnamed. Not sure how that happened, but I manually installed the current version of HEASARC fv.app there without an issue.

All in all, a bunch of small updates, but it gets the package mostly up-to-date again. 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.

Interestingly, the XQuartz wiki notes that

[MacOS] 10.5.7 updates the X11 server to match what shipped with 2.3.2. Most of the userland, however, only saw security updates. The version reported by X11 in 10.5.7 is 2.1.6 to distinguish it from the 2.3.x series which contains a much newer userland.

I have the feeling that the update to MacOS 10.5.7 will be released very soon now.

[UPDATE: In fact, it took almost two weeks, but MacOS 10.5.7 was released on Tuesday, May 12, 2009.]

Well, I’m way late to the game on this, but our long national nightmare is over – Xquartz for Leopard support full screen!

The Xquartz folks latest edition of Xquartz (version 2.3.2.1) includes full-screen support. Now, personally, I like the way X11 integrates with Aqua, but for those who prefer to use only one windowing system at a time, you can now do it on MacOS X Leopard. You can download it here.

Yesterday Mekentosj released version 1.9 of Papers for the Mac as well as a new iPod Touch/iPhone based version of their software (Apple iTunes store link) I have purchased it and can confirm that the synchronization works as advertised, I am now carrying all the papers I have read in the last 10 years in my shirt pocket. Nice!

Here’s the (slightly edited to reflect stuff of interest to astronomers) press release from Mekentosj

Papers 1.9 for Mac – sync your library of science with your iPhone – Published on 02/19/09

IMMEDIATE RELEASE

Mekentosj BV has announced Papers 1.9, the Apple design award-winning application that helps scientists on the Mac manage their personal library of scientific articles. The free update brings over 60 improvements, including an improved workflow for working with collections, support for French and German library proxies. But most of all, it allows you to synchronize your PDF library with the newly introduced Papers for iPhone and iPod touch.

Aalsmeer, The Netherlands – Mekentosj BV has announced Papers 1.9, the Apple design award-winning application that helps scientists on the Mac manage their personal library of scientific articles. The free update brings over 60 improvements, including a better workflow for working with collections, and support for French and German library proxies. But most of all, it allows you to synchronize your PDF library with the newly introduced Papers for iPhone and iPod touch.

With Papers 1.9 mek and tosj continue to improve the user experience and workflows of their popular PDF organizing tool for researchers. And with the ability to synchronize your library with the newly introduced Papers for iPhone and iPod touch it becomes easier than ever to manage your research literature, and now you have it with you wherever you go.

Papers for Mac and Papers for iPhone work together as a great team. Select which collections you want to keep in sync or make use of the smart auto-fill function to fill up your iPhone or iPod with articles based on the criteria that you choose. And if you make changes, or add ratings and notes, or if you download new articles on the road, the next time you sync with Papers on your Mac all those changes are immediately present in your library. It’s that simple. Visit our web site for a screencast to find out more.

Papers Features:
* organize and manage your entire library of scientific PDF files easily and elegantly
* built-in support for searching online article repositories
* built-in webbrowser for browsing publisher websites
* automatic downloading and archiving of PDF files
* tabbed and fullscreen reading of your PDF files
* razor fast spotlight searching of your entire library
* Syncing with the new Papers for iPhone and iPod touch.
* and much more.

Papers has built-in support for the following online repositories:
* ACM portal – Computer science
* NASA-ADS – Astronomy
* arXiv – Preprint repository
* Citeseer – Computer Science
* Google Books
* Google Scholar
* IEEE Xplore – Engineering
* MathSciNet – Mathematics
* Scopus – All sciences NEW
* Web of Science – All sciences

Minimum Requirements:
* Mac OS X Version 10.4 or higher
* Universal Binary for PowerPC and Intel
* 1.5 Ghz or faster G4, G5 or Intel Processor

Pricing and Availability:
Papers is priced at $42 (USD) for a single-user license. (Under)graduate students can apply for a 40% discount. A 30-day trial is available.

About Papers for iPhone:
Papers for iPhone and iPod touch puts your entire research literature database in your pocket, available at your fingertips wherever you go; whether you’re at a conference, in class, visiting your peers, or on the road. To celebrate the launch of Papers for iPhone and iPod touch you can now buy version 1.0 for the introductory price of $9.99 (USD) in the iTunes app store.

Papers is a program made by Mekentosj BV, a Dutch independent software company that writes innovative software for scientists. After a PhD in Cell Biology founder and CEO Alexander Griekspoor switched fields and initially joined the European Bioinformatics institute as a Marie Curie postdoctoral fellow. Alexander is perhaps most well-known as “Mek” from the duo “Mekentosj”. Together with his friend Tom “Tosj” Groothuis he developed a number of scientific Mac applications, two of which won Apple Design Awards for best Best Student and Best scientific Mac OS X application, respectively. What started in his spare time became his passion and has now also become his work: Mekentosj Inc. He aims to create new and innovative Mac OS X applications for scientists, of which his recently released new program Papers is a prime example, it won Mekentosj’ third Apple Design Award. Visit our website to learn more.

I just upgraded the software on this blog to WordPress 2.7. The major new feature I am interested in is automatic upgrading, which could prove quite a time saver. Unfortunately, this automatic upgrading uses only FTP (which is totally insecure) or FTPS (which requires me to set up an SSL certificate).

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. Start by installing libssh2 via MacPorts using the command:
   

   sudo port install libssh2
   

2. Once it is activated, link the libssh and PHP together using the PECL module SSH2. Unfortunately, directly installing the module with PECL under MacPorts is troublesome, so I just used PECL to download the module.
   

   pecl download ssh2
   

   triggered the following error (since ssh2 is apparently beta),
   

   Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.0, stability "beta", use "channel://pecl.php.net/ssh2-0.11.0" to install
   Cannot initialize 'ssh2', invalid or missing package file
   Package "ssh2" is not valid
   download failed
   

   so I used
   

   pecl download channel://pecl.php.net/ssh2-0.11.0
   

   as suggested and was able to download the PHP library for SSH2. Once the download was complete, I started on the standard compilation sequence for a PHP library
   

   tar xzvf ssh2-0.11.0.tgz
   cd ssh2-0.11.0
   phpize
   ./configure --with-ssh2=/opt/local
   make
   sudo make install
   

   The final command informed me the ssh2.so library was placed in /opt/local/lib/php/extensions/no-debug-non-zts-20060613/
3. Now you need to make sure PHP loads the new module, so we open the PHP configuration file /opt/local/etc/php.ini and edit the extension_dir line to point the extension directory above:
   

   extension_dir = "/opt/local/lib/php/extensions/no-debug-non-zts-20060613/"
   

   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 /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper 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.
   

6. Now that I got this working, I’ll just have to keep an eye out for any future MacPort updates to PHP and make sure they don’t overwrite the

   /opt/local/etc/php.ini

   file or the extensions directory where I installed ssh2.

The solution suggested on the PHP boards is to compile PHP against expat. This would be kind of a pain for me since I am using the MacPorts install of PHP. So I looked into rolling back to an earlier version of libxml2 using MacPorts. The solution was originally outlined in this blog post by Stephen Chu on how to install earlier versions of ruby under DarwinPorts, I have updated it for MacPorts. The key is to create a local MacPorts repository with the version of the port you want copied over to it.

1. First I identified the version of the libxml2 portfile I wanted by going to http://trac.macports.org/browser/trunk/dports/textproc/libxml2/Portfile and entering revisions into the “View revision” box until I found the appropriate version of the Portfile linking to libxml2 2.6.32 instead of 2.7.1. This turned out to be revision 40211 (actually 39551).
2. I created a directory to contain my MacPorts repository at /Users/Shared/dports/ and after creating that directory, I edited the MacPorts configuration file /opt/local/etc/macports/sources.conf to include the line:

   file:///Users/Shared/dports

   and you should make this line appear before the “rsync” or svn” port listing in the config file, otherwise it defaults to using that version of the port during the install.

3. I then installed the old libxml2 port into my local MacPorts respository using subversion:

   svn co --revision 40211 http://trac.macports.org/browser/trunk/dports/textproc/libxml2/ textproc/libxml2/
   

   and then I updated the MacPorts index:

   portindex /Users/Shared/dports

   With this done, I can see the two versions of libxml2 in my ports list, when I issue a

   port list libxml2

   the result is:

   libxml2 @2.7.2 textproc/libxml2 libxml2 @2.6.32 textproc/libxml2

   showing the current libxml2 version in MacPorts and the older one in my repository.

4. Now I can install the older version of libxml2 by first forcing removal of the current version and then installing the old version:

   sudo port -f uninstall libxml2 @2.7.2_1+darwin_9 sudo port install libxml2 @2.6.32

   [Warning: Unless you place the file:///Users/Shared/dports line before any rsync/svn lines of the config file noted in step 2, this port install command installs the current version instead of the old version]

5. I had to forcible uninstall and then reinstall libxslt but then my reinstall of php within MacPorts went fine. And I can now use WordPress again without any issues when using a remote blog editor.

I just figured in case anyone else wanted to use an older MacPort port they could use this to figure out how.

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

error when fonts are used in PHP routines (fuller notes on this problem here although with my “hacked” fix, which is no longer needed). This problem as originally reported under Trouble Ticket #15909 on MacPorts.

Careful with that Apache2 upgrade, Eugene: I also discovered I have to be careful when updating apache2 under MacPorts in that it actually wiped out some of the configuration files stored in /opt/local/apache2/conf/, specifically it overwrote my modified versions of the /opt/local/apache2/conf/extra/httpd-dav.conf file and /opt/local/apache2/conf/extra/http-userdir.conf files. So now I am keeping copies of everything in /opt/local/apache2/conf backed up so I can roll back my changes after an upgrade of apache2 in MacPorts.

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

The release notes for SAOImage DS9 don’t necessarily suggest dramatic changes in this version relative to version 5.3.

1. CATALOGS: removed support for Chandra Source Catalog at request of Ian Evans of CXC (only added on October 3, 2008).
2. MASKS: add support for mask transparency.
3. MASKS: add new mask properties.
4. GRID: add grid title support.

My previously posted notes on integrating upgrades of DS9 into the Scisoft OS X installation still work. Just note that newer releases of Scisoft OS X place the binaries in /Applications/scisoft/i386/bin/ instead of /scisoft/i386/bin/ and if you are installing the X11 binary that is compatible with the firewall, you have to install both the ds9 and ds9.zip file in the bin/ directory of Scisoft OSX.

1. Fixed a parsing bug that prevented the loading of any Clear Sky Chart for sites containing parentheses or periods in their names. It was this bug that was interfering with the loading of our observatory’s Clear Sky Clock.
2. Since the Clear Sky Chart is quite large and many people will use the widget on laptops with small screens, I added a “Half-size mode“. All you do is click on the “Toggle Size” link on the widget. This shrinks the charge and saves screen real estate.
3. With Attilla Danko’s permission, I added a Built-in Legend (copied from his site) for interpreting the Clear Sky Chart to the widget. Just click on the charge and the legend appears. Click again and it goes away.
4. I also added a link to the Clear Sky Charge site page, so if I wanted more detailed information, I can get it there.

I hope a few Mac-owning astronomers in the U.S. and Canada find this widget useful.

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

To quote the release notes on the SAOImage DS9 website, the changes in the newly released version 5.3 are

Regions: Regions now support a centroid function. The centroid function can be manually invoked or regions can automatically snap to a centroid when moved or edited. Regions now have a DASH line property.

Colorbar: Now supports a vertical colorbar layout option, via the View Menu. Users can configure the font type and size of the colorbar, via the View Menu.

GUI: Now supports a vertical button bar, when in vertical layout mode.

Aqua MacOSX 10.5 firewall: The MacOSX Aqua 10.5 Leopard port of DS9 can be used with the MacOSX 10.5 firewall enabled.

X11 MacOSX 10.5: There are now two versions available for X11 MacOSX 10.5 Leopard. The non-firewall version is recommended for all unless you wish to enable the 10.5 firewall. [Juan's Note: While not stating this, they mean specifically the application-specific version of the MacOS firewall. See my notes on this problem here.] In that case, please use the firewall enabled version. Please note: this version consist of 2 files, ds9 and ds9.zip. It is very important that ds9.zip be placed in the same directory as the ds9 binary at all times.

Contours: Contours now have a DASH line option.

I have previously posted notes for integrating upgrades of DS9 into the Scisoft OS X installation and they still work just fine except that newer releases of Scisoft OS X place the binaries in /Applications/scisoft/i386/bin/ instead of /scisoft/i386/bin/ and if you are installing the X11 binary that is compatible with the firewall, you have to install both the ds9 and ds9.zip file in the bin/ directory of Scisoft OSX.

should resolve a few outstanding problems created when changing the location of scisoft from /scisoft to /Applications/scisoft/. Packages such as MIDAS and Gnuplot should now work properly.

This version removes some remaining dependencies on the HPC OSX compilers, which I had on my machine but which most users do not have (and do not want to have).

I compared the /Application/scisoft/i386/Packages directory from this release of Scisoft OSX to the last one and there are no new packages installed. The few issues I noted with the Scisoft OSX 2008.8.1 release all appear to still be valid. Notably:

1. Permission Problems Persist: When the installer installs /Applications/scisoft, 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 administrative users username, in most cases, your username) to perform the repair.
2. ds9 command line executable missing: This release has the same glitch I noticed in version 2008.8.1 in that /Applications/scisoft/i386/bin doesn’t appear to have a ds9 binary installed. You can fix this by installing the X11 version of ds9 there or by linking to the Aqua version of ds9 that was installed using the command line
   

   ln -s "/Applications/scisoft/i386/Applications/SAOImage DS9.app/Contents/MacOS/ds9" /Applications/scisoft/i386/bin/ds9

I have placed a copy of this release in my Scisoft OSX Mirror in case the main Scisoft OSX repository gets bogged down.

As I reported on my blog here, here, and here, I have been having problems with my PHP programs on my web server that use fonts crashing with errors of the form:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

The problem turns out to not lie in PHP, but in Apple’s pre-installed FreeType which is compiled with “old font” support. This old font support is apparently old Carbon code instead of Cocoa (if I understand correctly, which I may not) and thus requires a forking of the process… which triggers this fault.

If you use MacPorts version of Apache and PHP (as I am now doing), you can fix this problem by editing the Portfile for freetype to disable old font support, recompiling it, and restarting your apache server. So following the hints in the MacPorts Bug Report #15909 I did the following:

Edit the Portfile located at /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/freetype/Portfile changing line 50 to

#    --with-old-mac-fonts 
--with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no --with-quickdraw-carbon=no 

Now recompile freetype in MacPorts. To do this you have to force the uninstallation of freetype (which will cause much gnashing of teeth by MacPorts since freetype is required for several other ports.

sudo port -f uninstall freetype

Then recompile and reinstall freetype:

sudo port install freetype

And finally, give the apache server used by MacPorts a fresh restart to get it going with the new freetype libraries loaded.

sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart

Doing this fixed all my freetype issues and I was able to use my FinderChart program again. The only disadvantage is that if freetype is updated from version 2.3.7 in MacPorts (and no no-old-font variant appears), I will have to re-apply this hack.

1. Reboot your Mac and hold down Cmd-S during the boot until the text booting dialog appears.
2. Run applejack. I enter applejack auto restart to automatically do all the system maintenance then restart into normal multi-user (graphics interface) mode.

AppleJack has saved my bacon more than once. I use it on those rare occasions where I have to do a forced shutdown of my Mac, but it has also fixed problems due to bad preferences or messed up font caches for me. I just tried out this version under Leopard on my MacBook Pro and it worked like a charm, about 5 minutes start to finish and it found a variety of permissions problems and fixed them. Best part is its free, so you have no excuse for not using it.

While the main site hasn’t been updated to reflect the presence of the new files, you can download AppleJack for Tiger or Leopard (version 1.5) here. There are also versions for Jaguar and Panther. Basically, its a must have tool for almost any MacOS version!

There are a few changes in this version and all packages have been updated to the latest available versions. Starting with this version, Scisoft is installed in /Applications/scisoft (it previously was installed in /scisoft). Make sure that you remove any old /scisoft installation and properly update your startup files to source the Setup.csh or Setup.bash from their new locations.

In the README file you are told

Once the collection is successfully installed csh and tcsh users should invoke the command:

source /Applications/scisoft/all/bin/Setup.csh

to gain access to all the software and configure their environment correctly.

Users of the “bash” shell should instead use:

. /Applications/scisoft/all/bin/Setup.bash

Personally, to avoid problems in tcsh with a script breaking or with modifying my PATH multiple times by repeated execution of the Setup.csh script, I use the following line in my .tcshrc to first check for the existence of the Setup.csh script and SCISOFT environmental variables before executing it.

if (! $?SCISOFT) then
test -r /Applications/scisoft/all/bin/Setup.csh && source /Applications/scisoft/all/bin/Setup.csh
endif

Permission Problems Persist
This version addresses all the issues I noticed with Scisoft OSX 2008.5.1 except for one annoying one, the reassignment of ownership of the enclosing directory on installation. If you installed the old version of Scisoft OSX, it would reassign ownership of the root (/) directory to the second user on the system (in my case, since their is none, it showed the user as “502″). I beta-tested various versions of Scisoft OSX but Nor was not able to stamp out this particular problem. I believe Nor has come to the conclusion after extensive testing that this is a problem with Apple’s software for constructing installer packages. By moving the Scisoft OSX installation to /Applications/scisoft, it is the /Applications directory that gets its ownership changed instead of the root directory, which is less damaging. However, I would 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 administrative users username, in most cases, your username) to perform the repair.

A Quick-Fix for any Legacy Scisoft-related scripts
If you had a few scripts that relied on Scisoft OSX being located in /scisoft and you don’t want to edit them all is you can make /scisoft point to /Applications/scisoft. This can be accomplished by first moving the old version of Scisoft OSX before installing 2008.8.1 via the command line:

sudo mv /scisoft /scisoft_old

and then once you have installed the new Scisoft OSX in 2008.8.1, create a symbolic link from the old location to the new by typing (again from the command line)

sudo ln -s /Applications/scisoft /scisoft

This will allow any scripts that refer to items in /scisoft to continue to work for the most part.

What’s New?
An investigation of the /Application/scisoft/i386/Packages directory as well as the NEWS file reveals the following changes to this version of SciSoft OSX over the 2008.5.1 version.

• DS9 updated from 5.1 to 5.3beta
  
• FV updated from 5.1 to 5.2.1
• ATLAS updated to version 3.8.2
• MIDAS updated to 08FEBpl1.1
• cdsclient was updated to version 2.87
• OpenMotif updated to 2.1.32_compat
• cfitsio library updaed from 3.090 to 3.090 (the current version is 3.100)
• pango library updated from version 1.20.2 to 1.21.3
• pixman library updated from 0.10.0 to 0.11.2
  
• expat library updated from 2.0.0 to 2.0.1
  
• fontconfig library updated from 2.3.2 to 2.6.0
• freetype library updated from 2.2.1 to 2.3.6
• gettext library updated from 0.14.5 to 0.17
• gtk+ updated from 2.12.9 to 2.12.10
• libpng library updated from 1.2.10 to 1.2.29
• netCDF library version 3.6.2 added
• pkg-config updated from 0.20 to 0.23
• TclTk package updated from 8.4.13 to 8.4.19
• wcstools library updated from 3.6.4 to 3.7.3 (current version is 3.7.5)
• IRAF package rvsao updated t version 2.5.7 to 2.6.4
• Python was updated to 2.5.2 and the following Python libraries were updated:
  
• • ScientificPython updated to 2.6.1

Minor Glitches
The only other minor glitch I noticed was that /Applications/scisoft/i386/bin doesn’t appear to have a ds9 binary installed. You can fix this by installing the X11 version of ds9 there or by linking to the Aqua version of ds9 that was installed using the command line

ln -s "/Applications/scisoft/i386/Applications/SAOImage DS9.app/Contents/MacOS/ds9" /Applications/scisoft/i386/bin/ds9

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

Finally, there’s a big problem with FreeType. As I discovered, anytime FreeType fonts are used by GD, they apparently make a Carbon API call of some sort. Problem is, Apache2 uses fork() without a corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon call in FreeType causes Apache2 to crash. It shows up in the error_log as

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
Mon Nov 26 12:38:11 2007 notice child pid 304 exit signal Trace/BPT trap (5)

and in the system.log as

Nov 26 13:12:00 shr-g5 ReportCrash664: Formulating crash report for process httpd659
Nov 26 13:12:02 shr-g5 ReportCrash664: Saved crashreport to /Library/Logs/CrashReporter/httpd_2007-11-26-131145_shr-g5.crash using uid: 0 gid: 0, euid: 0 egid: 0

I didn’t discover the cause–I can’t take credit for this one.

[I]nstall FreeType 2 without the Mac-specific extensions. These extensions make it possible for FT2 to access fonts stored in a font suitcase, something which is unnecessary if you use plain “.ttf” fonts from other sources. Here’s how I did that: Get FT2 and expand the tarball: (in Sources–my version of /SourceCache):

curl -O http://download.savannah.gnu.org/releases/freetype/freetype-2.3.5.tar.gz
cd ..
tar xvfp Sources/freetype-2.3.5.tar.gz

Configure FT2 and make it:

MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" CXXFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" LDFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load" ./configure --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no --with-quickdraw-carbon=no
make
sudo make install

Libraries end up in /usr/local/lib.

I had tried to alleviate the solution previously by compiling a version of PHP myself that would be compatible with Apple’s built-in Apache 2 web server. This turned out to be difficult because Apple’s Apache 2 web server is a “universal” binary, meaning it contains four seperate binaries (for 32-bit PowerPC, 64-bit PowerPC, 32-bit Intel, and 64-bit Intel processors). As such I needed to compile a “universal” PHP binary and since I wanted MySQL support, I needed a “universal” MySQL binary. This turned out to be too much for this astronomer, so I gave up on making a new PHP that was compatible with Apple’s built-in web server.

So I bit the bullet and after reviewing the options, I decided to install Apache 2 and PHP under MacPorts. If you have read the other posts on this site, you know I really like MacPorts as the quick and dirty way to get many things running on the Mac. However, despite this, I don’t like installing MacPorts for items Apple provides, instead generally preferring to use Apple’s “pre-installed” versions. Furthermore, there have been a lot of complaints on the MacPorts mailing lists about various issues compiling PHP5. So I wasn’t as quick to jump onto the MacPorts bandwagon for PHP as I am for other problems. However, since I am familiar with MacPorts, I decided this was the best approach for getting my online Finder Charts to work again.

The process proved reasonably painless, especially since I was able to review this blog post, where he lays out pretty much what to do. However, since I wanted to achieve maximum compatibility with Apple’s built-in web server and PHP setup, in case I wanted to switch back, I ended up doing things a little bit differently, so I am outlining my steps here.

1. I started by installing the MacPorts version of Apache 2 using the command sudo port install apache2
2. Next, I had to create the Apache 2 configuration files and edit them. I started by copying the sample configuration file

   sudo cp /opt/local/apache2/conf/httpd.conf.sample /opt/local/apache2/conf/httpd.conf

   and then editing /opt/local/apache2/conf/httpd.conf with my favorite text editor to change the configuration to match the that of the built-in Apache 2 server a closely as possible. My matching the configuration of Apple’s built-in server, I can switch back to it with relative ease if I choose to do so later. So I made the following changes to /opt/local/apache2/conf/httpd.conf:
3. 1. I changed DocumentRoot to "/Library/WebServer/Documents" as is the case with Apple’s built-in server.
   2. To allow index.php files to be used as directory indexes, I changed

      DirectoryIndex index.html

      to

      DirectoryIndex index.html index.php

      (I don’t know why this isn’t necessary with Apple’s built-in server, but it was necessary here).
   3. I changed to and in that directory block of code, I added “MultiViews” to the Options line.
   4. I changed to in order to prevent the listing of .DS_Store files in directory listings by the web server.
   5. Before the ErrorLog block of code in this file, I added the following lines copied from Apple’s default Apache 2 configuration:

      #
      # Apple specific filesystem protection.
      #
      
      Order allow,deny
      Deny from all
      Satisfy All
      
      Order allow,deny
      Deny from all
      Satisfy All

   6. I changed ErrorLog to "/private/var/log/apache2/error_log"
   7. I changed CustomLog to "/private/var/log/apache2/access_log common"
   8. To match Apple’s Apache 2 server configuration, I changed ScriptAliasMatch to

      ^/cgi-bin/((?!(?i:webobjects)).*$) "/Library/WebServer/CGI-Executables/$1"

   9. I changed back to
   10. I added the following Handles to the “To use CGI Scripts” block of code:

       AddHandler imap-file .map
       AddHandler cgi-script .cgi
       AddHandler cgi-script .pl

   11. I uncommended the following lines near the end of the file:

   12. [OPTIONAL] Because I use the WebDAV server on my server, I also uncommented
   13. Finally, I added the following lines to the end of the file in order to allow loading of the PHP5 configuration

4. Next, I editted /opt/local/apache2/conf/extra/httpd-userdir.conf and added the following to the end of the file

   #
   # Users might not be in /Users/*/Sites, so use user-specific config files.
   #
   Include /private/etc/apache2/users/*.conf

5. [OPTIONAL] Since I use the built-in WebDAV server, I made a backup of the WebDAV configuration, then copied the Default MacOS X one, because I have spent a lot of time tweaking it previously and I didn’t want to have to reinvent the wheel. 

   sudo cp /opt/local/apache2/conf/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf.orig
   sudo cp /etc/apache2/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf

6. I had to install PHP5 with MacPorts. Since I wanted to add support for Apache 2 and MySQL, I entered the command: sudo port install php5 +apache2 +mysql5 +pear which has the side effect of installing MacPorts version of MySQL as well. Assuming everything goes well, after a few minutes (this takes longer than the apache2 install earlier), the installation will end. At this point we can configure the Apache 2 mod_php module by typing: 

   cd /opt/local/apache2/modules/opt/local/apache2/bin/apxs -a -e -n "php5" libphp5.so

7. [OPTIONAL] Next, I had to create the PHP5 configuration file and edit it. I started by copying the sample configuration file sudo cp /opt/local/etc/php.ini-dist /opt/local/etc/php.ini and then editing /opt/local/etc/php.ini to make it match /etc/php.ini (which Apple’s built-in PHP uses). All the changes I made were optional and related to the specifics of my setup. The only interesting one was that I wanted to continue to use the MySQL.com binary distribution of MySQL server, so I set the following variables in /opt/local/etc/php.ini: 
   1. mysql.default_port from “” to 3306
   2. mysql.default_socket from “” to /private/tmp/mysql.sock
   3. mysqli.default_socket from “” to /private/tmp/mysql.sock
8. I deactivated Apple’s built-in web server by turning off Web Sharing in the Sharing.prefPane.
9. Finally, I launched the new webserver (and set it up for launching on boot-up in the future) by typing

   sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

   If this breaks anything, I can reverse the process by typing

   sudo launchctl unload -w /Library/LaunchDaemons/org.macports.apache2.plist

10. [OPTIONAL] I like the ability to turn on and off the Apache webserver from the command line using apachectl. I can “emulate” this in /bin/tcsh (my prefered shell) by adding the following command to the ~/.tcshrc file:

    alias apache2ctl 'sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper'

    After which I can bring down the server by typing apache2ctl stop and restart it by typing apache2ctl start.

While I’m sure Apple did this for security reasons, since upgrading the Leopard, I have had a problem with scripts that use the JpGraph plotting PHP library crashing. After looking in /var/logl/apache2/error_log, I see the following eror message:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

PHP on Mac OS X. Apple’s PHP version which is bundled with Mac OS X does not work with PDFlib DSOs. To use PHP with PDFlib on Mac OS X you need third-party PHP packages such as MAMP, XAMP[P] for Mac, or Marc Liyanage’s version from www.entropy.ch. Mac OS X 10.5 (Leopard) adds new complications. As described in developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html it is no longer possible to use CoreFoundation functions after a call to fork( ) without exec( ). However, CoreFoundation functions are required for PDFlib’s host font feature, and the critical sequence above is used in the combination of Apache and PHP. This may trigger the following error message in the Apache log (and can even crash the Apache process):

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on _THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

In order to avoid this problem you can run PHP as a CGI on Apache, or disable the host font feature in PDFlib[.]

Sure enough, JpGraph is using host fonts. Damn.

Unfortunately, the Marc Liyanage’s version of PHP5 for Leopard from www.entropy.ch is still in beta and the last update of MAMP was quite a long time ago. And while XAMPP for MacOS X looks promising (at least it has been updated recently), I would really like to keep on using the MySQL server I already have running. So for now, I try installing Apache 2 and PHP using MacPorts.

[See my subsequent posts about getting the MacPorts version of Apache 2 and PHP going and the subsequent continuation of the problem after a reboot.  There is more information about this issue there.]

Unfortunately, there are very few “external” users of the Hectospec, so the software pipeline available for reducing Hectospec observations, called SPECROAD, was only geared to run on SAO computers. I spent a considerable amount of time last summer and this summer getting that software into a much more portable form, documenting how to use it, and removing bugs from the code.

All this work resulted in the creation of a new version of the Hectospec data pipeline I dubbed “External SPECROAD” or “E-SPECROAD” for short. There were several major problems with the original SPECROAD code that I addressed in E-SPECROAD:

1. Nonportability: The SPECROAD scripts were only designed to run on a Solaris computer at the SAO, with files in specific hard-coded locations using a specific IRAF environment with all the IRAF parameters set before the scripts were run. This has been addressed by trying to assume almost nothing about a user’s IRAF environment from the start except that they have the proper packages installed.
2. Lack of Documentation: The documentation for SPECROAD is frankly inadequate. It was an in-house tool for the SAO, so the publically-available documentation consists mostly of one webpage describing what the scripts do. I have now written up both an installation guide (because there are a lot of pre-requisite pieces of code to install) and a E-SPECROAD user’s guide.
3. No Installation Instructions: There were several IRAF packages to install (available here). The shell scripts required not only the installation of several IRAF packages and the compilation of several C programs, they used korn shell (ksh) which I was unfamiliar with. And, as I would also soon discover, the ksh installed on the Mac had serious bugs in its list handling. There is now a fairly compete installation guide laying out all the pre-requisites and addressing installations on both Macs and Linux boxes.
4. Undocumented Bugs: The available SPECROAD scripts had major bugs whose workarounds were undocumented and only available when I would email someone at the SAO to inquire about them. In one case, you had to know to actually break out of the script with Control-C, then run some of the reduction in IRAF, and then restart the script! E-SPECROAD has been fairly extensively debugged. It’s not bug free, but the exterminator has made some serious passes at the code.
5. Assumed Availability of Spectral Templates: The SPECROAD scripts typically relied on pre-set spectral line databases for different grating/central wavelength configurations instead of having the user exploit the IRAF identify command to build a database. E-SPECROAD is geared toward the user who is going to wavelength calibrate their observations by building the spectral line database for themselves.
6. Assumed Use of Low Resolution Spectra: The SPECROAD scripts were mostly pre-configured for working with 270gpm gratings and required some tweaking for 600gpm. E-SPECROAD can work with either configuration without editing the code.
7. Inconvienent Backups As Data Reduction Progresses: If one of the scripts executed by SPECROAD crashed, you had to dig around subdirectories to “backtrack” the changes before restarting the script. With disk space not an issue, I prefer monolithic backups of the entire data directory at certain key points in the data reduction pipeline. Since you may not like this form of backup (as they consume a lot of disk space), they are optional.

Today, I am posting E-SPECROAD online as a beta release along with installation instructions and a user’s guide. All the other external users of Hectospec I am aware of, all two of you, can enjoy or complain to me about this code. The ones I am unaware of are free to use the code as well.

Unfortunately, it looks to to be as twitchy as running your own Darwin Calendar Server. I’ve been using CalDAV on my own personal server for a few months and I have to admit it has been a bit twitchy, but getting better as time rolls on. I tried to synchronize this afternoon to Google Calendar and got the following error:

The server responded with
"HTTP/1.1 500 Internal Server Error"
to operation CalDAVWriteEntityQueueableOperation.

Followup (July 30): I noticed all of the errors occurring during the import were for old classes last semester. So I forced my way through them by clicking “Revert to Server” for every one of the errors. There were probably 20 of them. Once done, I compared my calendar on my computer and Google’s Calendar, they were identical. So for now, it looks like GCal’s CalDAV server may serve my needs after all. I could have avoided all this by directly importing my ics file into Google through their web interface.

Followup (August 27): So I got an iPod Touch and discovered that CalDAV calendars are loaded on the iPod Touch as “Read-only”. If Apple really wants to back CalDAV as a standard, you would think they would support it more fully on their own products. For now, I found that BusySync works quite nicely for syncing my iCal calendars with gCal in such a way that the calendars are hosted on my Mac and the iPod Touch then can treat the calendars are read-write. This, along with the lack of native ToDo list synchronization on the iPods are about the stupidest bits of inconsistency I have seen in using the iPod Touch. Luckily the ToDo list being missing from the iPod Touch doesn’t affect me as much as I am using OmniFocus, which works very well on the Mac and iPod Touch and allows synching between both.

As such, for now, since I prefer the X-windows version of SAOImage DS9, I am leaving the the Firewall off for now, I’m not too concerned.