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

Archive for the ‘Programming’

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.

MacPorts getting more functional for this Astronomer 0

Posted on January 24, 2008 by Juan

About 6 weeks ago I posted about the various ports that failed to install in my first attempts at getting “my standard suite” of ports installed under MacPorts on Leopard. My standard suite until Tiger involved issuing the following command:

sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem

Since then MacPorts has released version 1.6 and the various porters have been hacking at the various problems. I can now report that of the ports I reported failed to install:

  • xterm, wine, and g95 all now install without any issues.
  • teTeX can be installed, there was a bad dependency in the portfile. You just needed to install openmotif first manually. I don’t know if the bad dependency is still there, it may have been resolved.
  • subversion can be installed, it also had a bad dependency. You just needed to install nawk first. Again, I don’t know if the bad dependency is still there, it may have been resolved.
  • gv can be installed if you apply a patch. If you check that bug ticket on gv (you need to get a free MacOSForge account), you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.

This leaves just two of my standard suite of packages that don’t compile right in Leopard, osxutils (See this post) and xephem (See this post). And xephem installs just fine manually if you download the source code.

Leopard uses Apache2… doesn’t migrate well 0

Posted on November 26, 2007 by Juan

I host a reasonably large astronomical database on my office Mac (http://www.cabanela.com/MAPS_Database/), so I pay attention to migration issues with the web server component of the Mac OS. I suspected there would be some because Apple was switching to Apache2. I have in recent years been a fan of the “MAMP” setup (MacOSX, Apache, MySQL, PHP) and have used Apple’s preinstalled Apache, the binary MySQL installs, and a custom compiled version of PHP. This typically required banging on the configuration files for the Apache server a bit.

As I discovered, my web pages wouldn’t even load on the laptop under Apache2. The first step was finding the Apache2 configuration file at /etc/apache2/httpd.conf and editing it to re-allow PHP execution (uncomment the

#LoadModule php5_module libexec/apache2/libphp5.so

line). I still continued to get a permission error, I finally discovered that the MacOS X upgrade process didn’t move user website directory configuration files to the new location on the drive. I moved the individual user files from /private/etc/httpd/users/ to/private/etc/apache2/users/ and bang, I could view most of my personal webpages on my laptop again. But anything using URL re-writing still failed (including WordPress blogs). I had to change the AllowOverride configuration entry in my users’ configuration files to include Options, then everything worked again. I’ll still need to custom compile a version of PHP that supports GD2 and a couple other libraries I use, but this has been less painful than I naively expected.

ChkTeX on Mac OS X 0

Posted on October 09, 2007 by Juan

I haven’t played with this personally yet, but since I will be working on a paper for publication shortly, it looks like this might come in very handy. A Dr. Figueroa-Centeno in the Department of Mathematics in Hawai`i has posted instructions for getting the LaTeX syntax checker, ChkTeX, running under MacOS X. It doesn’t look terribly difficult. He includes instructions and a script for BBEdit integration, which makes me a happier BBEdit user. To quote from the ChkTeX website:

[ChkTeX] has been written in frustration because some constructs in LaTeX are sometimes non-intuitive, and easy to forget. It is not a replacement for the built-in checker in LaTeX; however it catches some typographic errors LaTeX oversees. In other words, it is Lint for LaTeX.

Looks promising for me. I use Splint when C programming (I installed splint via MacPorts using the command line sudo port install splint), so the idea of a Lint for LaTeX is appealing. I’ll be visiting Dr. Figueroa-Centeno’s website on ChkTeX on Mac OS X for full details on installing it, once I get a break from teaching.

HINT: Resolving xgterm problems calling ecl scripts 0

Posted on August 09, 2007 by Juan

I am posting here an annotated version of one of my headaches for the last few days, which has been a persistent xgterm crash. I have been working on getting the Hectospec reduction scripts known as specroad running on my Macintosh (something I will fully document and provide binaries for when I am done). Having never done spectroscopy before, it seemed like a safer bet to learn by working my way through their scripts than trying to invent this as I go. Some magic done by the specroad scripts comes from the fact that they call IRAF routines in the form of ecl scripts, allowing two or more separate simultaneous IRAF processes. On a multi-processor system like mine, this parallelization can help cut down on the running time. More specifically, the specroad package contains a script called ‘callhectospec‘. This script calls ecl, the enhanced IRAF command line environment, and then sets up the environment by loading the hectospec package in IRAF. It then issues the IRAF command you requested. I was having a problem running the command:

xterm -e callhectospec hcal comp.ms
to calibrate the pixel to wavelength mapping because it would bring up a Tektronix window (via xterm’s Tektronix emulation), but I wasn’t able to type out the proper commands within that window. I suspected that I was triggering some sort of internal Tektronix commands, and so I tried switching the call spawn an xterm witha call to X11IRAF’s xgterm. xgterm is a xterm clone that offers more advanced plotting capabilities and interactions. The callhectospec script immediately crashed with the following error:
 Error in message to server, line 6: send: could not find object gterm
    while executing
"send gterm setGterm"
xgterm Xt error: Shell widget gterm-iraf has zero width and/or height
I spent a few hours searching for solutions in Google. All the previous instances of this error seemed related to running old versions of X11. This didn’t match my situation. I tried upgrading xgterm to the current version, which didn’t change things. It was a bit irritating because I knew IRAF worked with xgterm just fine. Clearly I was triggering this error message for a reason that didn’t match the previous cases. I finally relented and posted about my problem on IRAF.net‘s forums. Thankfully, the solution, pointed out by Fitz, was simple, the callhectospec script was setting up the IRAF environment for xterm, not xgterm. All I needed to do was edit callhectospec to replace
else if (envget("TERM") == "xterm") {
 stty xterm
else if (envget("TERM") == "xterm") {
  stty xgterm
My IRAF login.cl script does exactly this, which is why it worked when I entered ecl by hand. Once that was fixed, everything worked like a dream.

Read the rest of this entry →

HINT: Fast and loose f77 compilation on MacOS with g77 1

Posted on July 19, 2007 by Juan
One of the problems I had getting the hectospec IRAF scripts installed was that they used f77 to compile some code. My first thought was to just substitute g77 in the proper places in the hectospec scripts using the g77 binary I downloaded from the High Performance Computing on the Mac website. However, it turns out that g77 is stricter in its interpretation of logical statements than f77 … and so the old hectospec code failed to compile. A proper way to compile this old code is to use the –fugly-logint flag for g77, but that was a pain for so many IRAF scripts. Thus I created the following perl script to allow ancient f77 code to compile properly with g77 on the Mac. I just saved this script to /usr/local/bin and made it executable. Now my old IRAF scripts compile just fine on my new shiny Mac.
#!/usr/bin/env perl
# This script allows the compilation of legacy f77 code with g77 by tossing
# the g77 compiler a -fugly-logint flag to tell it to allow legacy logic
# statements instead of the proper EQV version.

# Initialize
$command = "g77 -fugly-logint ";
for ($i=0; $i<=$#ARGV; $i++)
 $arg = $ARGV[$i];
 $command .= " $arg";
  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin

↑ Top