I just installed the OpenOSX Grass (non-pro) version.
When I start the application, it complains that there is no X11 installed:
Missing Apple X11
This application requires Apple's X11. Please install X11 and try again.
Would you like to open the Apple X11 page in your web browser?
But X11 *is* installed! I can start xterm and so on. Is this just yet
another reason for me to use the "framework" version of the OS X Grass
release for Mac? I very carefully made sure X11 was installed when I
installed Leopard. It shows up in the Applications/Utility folder and
responds just fine when I double click on it. I've also got the Developer
installation, which has X11 libraries. I mean I'm like totally X11!
So I guess the questions are:
- Is OpenOSX Grass broken?
- Is every thing just fine, other than a spurious error message?
- Is there a secret trick for telling apps that X11 *is* installed?
- Would it be better to use one of the other OSX Grass installations?
I just installed the OpenOSX Grass (non-pro) version.
When I start the application, it complains that there is no X11 installed:
Missing Apple X11
This application requires Apple's X11. Please install X11 and try again.
Would you like to open the Apple X11 page in your web browser?
But X11 *is* installed! I can start xterm and so on. Is this just yet
another reason for me to use the "framework" version of the OS X Grass
release for Mac? I very carefully made sure X11 was installed when I
installed Leopard. It shows up in the Applications/Utility folder and
responds just fine when I double click on it. I've also got the Developer
installation, which has X11 libraries. I mean I'm like totally X11!
So I guess the questions are:
- Is OpenOSX Grass broken?
- Is every thing just fine, other than a spurious error message?
- Is there a secret trick for telling apps that X11 *is* installed?
- Would it be better to use one of the other OSX Grass installations?
I suggest that you first try the version from the GRASS website:
If you have problems with the OpenOSX versions, you would be better
off asking OpenOSX. AFAIK, none of the GRASS developers are
particularly familiar with the OpenOSX version.
I suspect that the problem is that the OpenOSX version is out of date.
Apple's X11 support is something of a moving target. IIRC, prior to
Leopard, it was necessary to explicitly start X11, but that isn't
necessary (and doesn't work) in Leopard.
I suspect that the problem is that the OpenOSX version is out of date.
Apple's X11 support is something of a moving target.
IIRC, prior to Leopard, it was necessary to explicitly start X11,\
but that isn't necessary (and doesn't work) in Leopard.
Looking at the OpenOSX website, the latest available version for download
is 6.2.1 (Dec 2006), several versions out of date.
It seems that the main decision is whether or not to go with Mac Frameworks
rather than an all-in-one approach.
If I understand "frameworks", they are much like the more traditional shared
libraries. Both have versioning and should support a mix of version
requirements by applications. I.e. if you have a collection of the last 4
or 5 versions of the library sets, applications should be able to happily
work together without getting confused or failing.
When working at Sun with Solaris, I did indeed experience delightful
backward compatibility with the ability to also install newer systems. But
I'm a bit skeptical that Apple has pulled that off.
Would you agree that's the "bet" here? If Frameworks do indeed work, then I
should prefer using them but if they don't work as well as they should, I
should use the all-in-one? It would be nice to have the presumed ability to
use all the GRASS components (GDAL etc) by them selves as well as within
GRASS.
Any experience of the two installs would be much appreciated!
Would you agree that's the "bet" here? If Frameworks do indeed work, then I
should prefer using them but if they don't work as well as they should, I
should use the all-in-one?
Versioning in OSX libraries and frameworks works. They're really very similar.
Basically, it's a choice of installing one package or a bunch of extra dependencies. And how well they are kept up to date. And...
It would be nice to have the presumed ability to
use all the GRASS components (GDAL etc) by them selves as well as within
GRASS.
... being able to use the dependencies on their own. Which really depends on how they are packaged. Usually an all-in-one will bundle just the bare necessities for the main application. Even external dependencies (framework or otherwise) don't have to include all the extra bits (and a framework is mainly a library, so extra utilities are often left out). That said, I do include all the extra utilities within my framework builds.
William, you've converted me to Frameworks, they are clearly the cleanest way to avoid the many conflicts inherent using lots of libraries and versions. Your work is a prize, and I thank you very much. GRASS is now running fine.
Just as an aside, our local science/tech community were just talking about the difficulties of version control, and one of us came out with such a wonderful rant I thought I'd share it! It goes like this:
On Jun 12, 2008, at 11:45 AM, Roger Critchlow wrote:
The maze of package management, revision management, version control, and
configuration control tools, and whether they exist or not, is the real pain
of moving between programming environments. I can almost keep the language
syntax and libraries straight, but when it comes to figuring out how to run
CPAN for perl again, or how the 'easy_install' package works for python, or
what the alternative for Tcl is that ActiveState.com has implemented, or the
ruby gems repository, or why "yum update" and "apt-get update" do completely
different things, I give up.
It's a Turing complete mess.
Owen Densmore <owen@backspaces.net> wrote:
Yup, indeed my interest related to the netlogo gis extension: it
currently does not handle DEM raster data, only ASC, which apparently
is a fairly standard format .. also called ESRI Grid I think.
I guess its time for me to start using basic GIS libraries with either
Python or Java. My main problem with Python is their library system
and lack of backward compatibility. The libraries are always in cat-
fights with each other and they all fail to run on the same version of
Python itself, thus requiring a rather awkward balancing.