Urania

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

Archive for the ‘X11’


X11 without an xterm on Leopard 0

Posted on December 15, 2007 by Juan

The latest XQuartz release (2.1.1) finally fixes one of the major annoyances I was having with X11 under Leopard. Because the X11.app program under Leopard is really an xterm launcher, starting X11 always started an xterm window. This has now been fixed. All you need to do is install the new XQuartz package (WARNING: Because this changes the launch daemon settings, you will need to restart the computer afterwards) and then once you have rebooted, type the following command into the terminal:

defaults write org.x.X11 app_to_run /usr/bin/true

And you have xterm-free X11 again. Furthermore, this updates xterm as well, so even though I don’t want xterm to launch automatically with X11, I am happy to have it updated.

MacPorts failures under Leopard 1

Posted on December 05, 2007 by Juan
I decided I should clean up my laptop’s left over digital crap, so I went through my /usr/local directories cleaning out ancient libraries installed two OSes ago (after making a backup first). I decided I would try reinstalling MacPorts under Leopard, if only to build it clean and remove the old source code siting around from various revisions to the packages over time.First, I installed MacPorts from the disk image for Leopard. Then I attempted to install my usual suspects: 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 Long story short, almost everything works but there were a few key packages that failed to build under MacOS X 10.5.1. This also reminded me that when a package fails to build, you should “port clean” the package (see examples below) before attempting to rebuild it:
  • I discovered that teTeX failed to build. This appears to be due to an undeclared dependancy on openmotif. So after the failed install, I just did ansudo port clean --work teTeX; sudo port install openmotif teTeXand teTeX installed just fine.
  • In attempting to build subversion I discovered that one of the packages subversion needs, sqlite3, fails to install on Leopard. This appears to be due to an undeclared dependancy on nawk (MacPorts Report Ticket #13500). So again, all I had to do was:sudo port clean --work sqlite3; sudo port install nawk subversionand it worked. I should note that a fairly recent version of subversion now comes with Leopard, version 1.4.4 (as opposed to 1.4.5 with MacPorts).
  • gv fails to install unless you patch it. This was reported to MacPorts (Bug Report Ticket #13095). [If you check that bug ticket, 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.]
  • osxutils fails almost immediately with a series of errors about conflicting types. Since osxutils did a lot of meta-data manipulation, I am not completely surprised it is broken under Leopard. I have submitted a bug report to MacPorts.
  • xterm fails to build. This is irritating because I haven’t had time to confirm is the old xterm Tektronix emulation bug present in the Tiger version of xterm is still present. [This appears to have been cleared up with MacPorts 1.6 if you install Xquartz over the Apple installed X11 server. Doing this is a good idea anyway.]
  • wine fails to build (already reported elsewhere [link since deleted]). This has already been reported in MacPorts Bug Report Ticket #13488. I wonder if this is related to the possibility being mentioned of Leopard having unreported support for Windows binary execution. [Wine version 0.9.51 DOES compile under Leopard just fine.]
  • I can’t build g95 because odcctools fails to compile. This has been reported in MacPorts Bug Report Ticket #13148. [This appears to have been fixed as of January 24, 2008.]
  • xephem fails to build because lesstif builds but fails to install. Actually lesstif installed fine once I moved /usr/share/aclocal/ac_find_motif.m4 out of the way. I don’t know if that file was there from my previous install of lesstif. Once lesstif was out of the way, xephem failed to build. Interestingly, MacPorts has version 3.7, I downloaded the source for xephem 3.7.2 from the Clear Sky Institute website, compiled it following the installation instructions without a hitch. I submitted a bug report as MacPorts Bug Report Ticket #13524 (turned out my bug report was a duplicate of MacPorts Bug Report Ticket #13498). This has been fixed, see this post. [This appears to have been fixed as of March 3, 2008.]
I’m actually surprised the number of packages that failed to compile seems pretty small.

Leopard and X11: A blog and an X11 update 0

Posted on December 02, 2007 by Juan

Found this nice blog documenting Leopard and X11 issues. On there I found a note that the updated XQuartz package [link now points to page for newer packages] with various fixes for Leopard has been released. I’ll be trying it out shortly.

X11 Issues under Leopard… some additional information 0

Posted on December 01, 2007 by Juan

Well, I think I have ironed out most of my issues with X11 and I am actually very happy with it. But if you are not as happy, check out the X11-Users FAQ. It contains information about how to tackle the following:

  • If you really hate the new way X11 uses a custom DISPLAY environmental variable to trigger launchd to launch X11.app, the FAQ contains information on how to disable the launchd trigger and then revert to the Tigerish behavior of manually launching X11.app (HINT: Don’t use /Applications/Utilities/X11.app, use /usr/X11/X11.app instead.
  • Information on installing Tiger’s X11 on Leopard. Apparently, it can be done without clobbering Leopard’s X11 install.

Really, very useful, even if you don’t mind the new X11, since it illuminates a bit about how this X11 has bee changed. Oh, and it looks like future X11 updates will be made available at a new MacForge website. I hope a nicer set of packages for X11 is available soon, the only big irritation has been my X11 windows slipping under the menubar!

Leopard Issues for the Astronomer (a.k.a. I’m not sure X11 is better) 2

Posted on November 25, 2007 by Juan

So this weekend I decided to take advantage of the long weekend and between bites of turkey with the family, I decided to upgrade my laptop to Leopard (MacOS 10.5). I had been reading about the various issues with Leopard before the upgrade, so among the things I did in anticipation of Leopard was

  • I uninstalled Unsanity’s Application Enhancer.
  • I removed X11.app from my automatic launch items in the Accounts Preferences Pane Login Items. X11 is extensively refreshed under MacOS 10.5, so you don’t want to autolaunch X11.app any more.
  • I upgraded Cisco’s VPN software to the latest version distributed by my campus (you want Cisco VPN Client 4.9.01 (0090)).
  • I did a quick search of the various applications I run and looked for “Leopard” upgrades via MacUpdate.
  • Finally, I researched the incompatibility of Adobe Acrobat with MacOS X 10.5. I discovered that while the AdobePDF printer driver broken under the new OS, you can use Apple’s built in PDF capability (specifically “Save as PDF-X”) capability to create the PDF, which can then import and edit just fine in Acrobat.

Having done all that, I decided to bite the bullet and install the upgrade. First thing I did was back up the entire internal drive to an external drive (which I had formatted with Disk Utility to make sure it was capable of booting an Intel Mac) using Carbon Copy Cloner. Once the drive was cloned, I ignored the overhyped warnings from MacFixIt.com (who I won’t link to, because they were bought out, they definitely sold out as a source of accurate help) and instead followed the Apple recommended procedure of just doing an upgrade to my previous Tiger installation. I figured if worst came to worse, I would recover from the backup drive (in my mind, the backup is the critical step, not how you choose to upgrade). So approximately 80 minutes later my laptop finished its upgrade and rebooted. Some notes on my initial issues with the new OS.

  • The new dock doesn’t bug me as much as some (John Siracusa does the best analysis of the problems with the new Dock in his extensive ArsTechnica review of Leopard), but maybe its because I thought the old dock was broken enough as a launcher that I use QuickSilver instead (which works fine under Leopard).
  • Leopard finally handles virtual memory use nicely, removing old files in the /var/vm directory once the memory has been released.
  • I don’t like the translucent menubar, but there exist various free applications to get rid of those and the changed dock.
  • The new OS nuked all my installed printers. Not a huge deal, but I have to re-install all my printers again. I kind of understand why this might of happened, but it was a pain.
  • I had to use Disk Utility to Repair Permissions before my Widgets behaved properly, but now, they actually seem to run better than before (less delay in accessing them).
  • I patched IDL to version 6.4.1, seems to work now.
  • I knew from Ben Bayer’s (Apple’s X11 guy) postings on the matter that

    Biggest architectural change in Leopard for X11: Switched from XFree86 codebase (based on, IIRC, X11R6.8) to X.org codebase (X11R7.2)

    Biggest user-visible change: launchd support for X11. The only situation where you should need to manually start X11.app is if you are only running remote X11 applications.

    The way that this is accomplished is by some slight-of-hand with the $DISPLAY variable — if you look, it should be something like “/tmp/ launch-vbXRyu/:0″. If an X client connects to this, it will actually connect to launchd, which will start Xquartz if needed and pass the client’s socket to the server.

    All of that should be invisible to you; the X client library (libX11.dylib) was modified to support this, and all X11 applications link against this library. “DISPLAY=:0″ would still work if X11.app is already running, but it will not trigger X11 to launch.

    So in other words, we are not supposed to set the shell environmental variable DISPLAY to “:0”. Well, I removed all the times I set it from .tcshrc, .bashrc, .login, etc and it still remained stubbornly set until I remembered trying to get Carbon Emacs working a few months back required my setting environmental variables to my entire session using the ~/.MacOSX/environment.plist file. I opened it, removed the DISPLAY variable from the list of those set for the entire session, and viola. Almost everything worked as advertised except:

  • SAOImage DS9 refused to launch because of the non-standard DISPLAY variable. I initially hacked around this by launching an xgterm (from IRAF) and setting the DISPLAY variable in it to “:0” then launching ds9 within that xgterm session. I did this all in one line via: 
    xgterm -geometry 80x45+40+30 -sb -e 'setenv DISPLAY :0; ds9 -fifo ~/iraf/dev/imt1 -geometry 800x800+600+30 &'
    where I was connecting to my IRAF pipes (thus the ‘fifo’ command line entry). However, I emailed the SAOImage DS9 folks on Thanksgiving and they replied same day to tell me about the new ds9 darwin 5.1beta. That fixed the launch issues with ds9. Apparently getting the Aqua version updated is a bit trickier, so its not done yet.
  • I had to uninstall the MacPorts version of xephem, but installing it manually from the source worked just fine.
  • I installed the unofficial updates to X11 from Xdarwin (see MacSingularity for some notes). The biggest issues this fixes are (1) the focusing problem of X11 windows behind Aqua windows not always being “focusable” and a (b) bug in X11 that caused several programs using the Gimp Toolkit (aka gtk) to crash. NOTE: These updates have been superceeded by those on the MacForce XQuartz updates site.

All in all, I like the new upgrade, the most useful feature for me being the QuickLook interface and the just generally better networking behavior. I also think there has been a lot of thought put into nips and tucks (such as where the Firewall controls are now, in the “security” prefpane instead of “sharing”). More reports from the field as my usage of IRAF and ds9 under Leopard continues.

Scisoft OSX 2007.11.1 Released 2

Posted on November 01, 2007 by Juan
Wow, Nor Pirzkal and Francesco Pierfederici have kept quite busy making small updates to Scisoft OSX for Intel. They released another new version today (available for download here). Here’s the entire description of the changes in this version of Scisoft OSX from the release notes:
This version updated Python to version 2.5.1 and correct some minor issue with the bash version of the irafuser.bash script when running under OSX 10.5 Leopard. Missing GCC runtime fortran libraries are also now included. This version was test under OSX 10.5 and seems to run fine. Note that 10.5 does deal with X11 applications slightly differently. Once the Setup.bash script has been source[d], you should add the following line to your .bash_profile: export DISPLAY=127.0.0.1:0.0 This will enable all Scisoft X11 applications to start from Terminal.app
I am not running Leopard (and probably will not switch until the winter break, when I have time to deal with all the X11 issues it creates), so I can’t confirm the ability to run under Leopard, but its great to know they are keeping SciSoft OS X up to date.

Issues with this Release of Scisoft OSX
  • I did notice this new version of Scisoft OSX doesn’t appear to link its IRAF install with the rvsao IRAF package (used for radial velocity computations). Doesn’t matter to me to much since I compiled the newer version and linked to it, but it is funny they include the rvsao package at /scisoft/all/packages/iraf/extern/rvsao but don’t link to it in the $hlib/extern.pkg file, which I do believe they did in the older versions.
  • I may not have noticed this earlier, but in the libraries directory /scisoft/i386/lib, some of the symbolic links are broken. Specifically:
    • All the items in this directory linking to the OpenMotif library items are not linked, it appears /scisoft/i386/Packages/OpenMotif-2.3.0/lib doesn’t exist. However, /scisoft/i386/Packages/OpenMotif-2.3.0/lib.org does. So I symbolically linked lib to lib.org via:
      cd /scisoft/i386/Packages/OpenMotif-2.3.0/
      ln -s lib.org/ lib
      And now all the links to the OpenMotif libraries within /scisoft/i386/lib work.
    • The CFITSIO library is mis-linked to an older version which no longer is installed. So I needed to:
      cd /scisoft/i386/lib/
      rm libcfitsio.a
      ln -s ../Packages/cfitsio-3.040/lib/libcfitsio.a libcfitsio.a
      and the CFITSIO library was properly linked again.
    • libpng.so was apparently not compiled within /scisoft/i386/Packages/libpng-1.2.10/lib, so there is no quick fix for that broken link.
    • I removed a link to python2.4 in /scisoft/i386/lib and replaced it with a link to python 2.5:
      cd /scisoft/i386/lib/
      rm python2.4
      ln -s ../Packages/pygtk-2.8.6/lib/python2.5/ python2.5
  • All the CFITSIO headers in /scisoft/i386/include/ are linking to an older version (3.006) instead of the current installed version (3.040). Fixed via:
    cd /scisoft/i386/include/
    rm -f drvrsmem.h fitsio.h fitsio2.h longnam.h
    ln -s ../Packages/cfitsio-3.040/include/*.h .
  • There are symbolic links in the /scisoft/i386/bin directory to a variety of executables from the sm plotting package which doesn’t appear to have been installed as part of the Scisoft OSX distribution.
  • Not really a bug, but the version of SAOImage DS9 is version 4.1.3 and not the current version 5.0.0. Of course, given the long history of dangerous version X.0.0 software, this maybe safer that way.

SAOImage ds9 version 5.0 released 1

Posted on October 16, 2007 by Juan
On October 15, the folks behind SAOImage released SAOImage DS9 version 5.0. The big change I noticed is they now have a completely MacOS X native (read “Aqua”) version of ds9 (but only if you use the application package version of ds9, the command line versions remain X11)! I downloaded the following three versions: The new features lists page tells us that this release includes:
  • MacOSX Aqua Support: DS9 has been ported to MacOSX Aqua and is an universal application which no longer requires X11.
  • Compressed FITS Support: DS9 supports compressed FITS images using RICE compression.
  • Mask Support: DS9 supports overlay masks. A mask is defined as a valid FITS image, in which a non zero value indicates that the selected mask color is to be displayed instead of the data value color.
  • SkyView Support: DS9 provides support for HEASARC’s image cutout service, SkyView. This site provides image cutout service for a number of image surveys, including SDSS.
  • Multi-Language Support: DS9 provides multi-language support. By default, the language used for menus and dialog boxes is based on the value of the operating system locale variable. The user may override the default value by selecting the desired language in the preferences or by the -language command line option.
  • Preferences: Preferences are automatically saved when a user changes an option. Selecting the saving preferences menu item is no longer needed.
More detailed release notes are available here. I was able to get this version of ds9 integrated with SciSoft OSX by doing the following:
  1. Decompress the command line version of ds9 via the terminal using tar xzvf ds9.darwinppc.5.0.tar.gz (PPC version) or tar xzvf ds9.darwinintel.5.0.tar.gz (Intel version). When the decompression is done, all you have is an executable called ds9.
  2. Next, from the terminal, go to the /scisoft/bin directory (on PPC) or /scisoft/i386/bin/ directory (on Intel) and rename the old ds9 executable to something like ds9_old (using something like mv ds9 ds9_old).
  3. Copy your newly decompressed ds9 executable into the SciSoft OSX binary directory. I should note the command line version of ds9 still requires X11.

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
}
with
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 →

Annoyance: Xterm Tektronix emulation broken on MacOS 0

Posted on July 19, 2007 by Juan

Another piece of a fundamental *nix installation that is broken in MacOS X Tiger is xterm. Specifically, the Tektronix 4014 emulation in xterm on the Mac generates ’empty boxes’ instead of actual characters for text as shown below:

Xterm Broken Display

I found that this problem had been reported on Apple’s X11-users mailing list here, but no solution had been determined. I spent a bit of time looking for “missing” fonts as suggested in the posting, then decided this had to be a problem with the xterm executable and tried my previous solution of installing the program from MacPorts via

sudo port install xterm

Since that doesn’t over-ride the default xterm, I then over-rode the default installed xterm using
sudo mv /usr/X11R6/bin/xterm /usr/X11R6/bin/xterm.disabled
sudo ln -s /opt/local/bin/xterm /usr/X11R6/bin/xterm

Now Tektronix emulation works and I get a screen like the one below:

Fixed Tektronix display on xterm

  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin



↑ Top