[GRASS5] Darwin Pre1 NVIZ

Glynn_Clements · June 6, 2001, 1:01am

Duff Maps wrote:

I have been using the following diff's on configure.in to compile with Mesa
on Debian. Because of the way Debian installs Mesa options. I have to
rebuild the *configure* by running *makeconf*. Then I ./configure and
compile as normally.

I recompile grass5 every few days and generally things go fine.

Tom Rake
The Duff Map Company.

Index: configure.in

RCS file: /home/grass/grassrepository/grass/configure.in,v
retrieving revision 1.64
diff -c -r1.64 configure.in
*** configure.in 2001/04/09 19:26:37 1.64
--- configure.in 2001/06/05 17:46:26
***************
*** 880,886 ****
--- 880,888 ----
      ac_save_ldflags="$LDFLAGS"
      LDFLAGS="$LDFLAGS $MATHLIB $OPENGLLIB $OPENGLULIB $X_LIBS -lXt -lXm"
      AC_CHECK_LIB(GLw,GLwDrawingAreaMakeCurrent,LGLWM=-lGLw)
+ AC_CHECK_LIB(MesaGLw,GLwDrawingAreaMakeCurrent,LGLWM="$LGLWM -lMesaGLwM")
      AC_CHECK_LIB(GLwM,GLwCreateMDrawingArea,LGLWM="$LGLWM -lGLwM")
+ AC_CHECK_LIB(MesaGLwM,GLwCreateMDrawingArea,LGLWM="$LGLWM -lMesaGLwM")
      LDFLAGS=${ac_save_ldflags}
  fi

Are you actually using r3.showdspf.openGL (from GMSL/g3d)? AFAIK, this
is the only program which actually requires libGLwM. As it currently
has outstanding bugs, it isn't in the 5.0.0 release branch in CVS.

Also, its documentation specifically refers to using Mesa's libGLw
(from the widgets-sgi directory) rather than libMesaGLwM (from
widgets-mesa).

I don't want to change configure to accept libMesaGLwM in place of
libGLwM unless it's known to work.

If GMSL/g3d isn't going to make it into the release, we may as well
just remove the GLw checks altogether; otherwise they just confuse
people.

--
Glynn Clements <glynn.clements@virgin.net>

Eric_G_Miller · June 6, 2001, 2:40am

On Wed, Jun 06, 2001 at 02:01:47AM +0100, Glynn Clements wrote:

Are you actually using r3.showdspf.openGL (from GMSL/g3d)? AFAIK, this
is the only program which actually requires libGLwM. As it currently
has outstanding bugs, it isn't in the 5.0.0 release branch in CVS.

Also, its documentation specifically refers to using Mesa's libGLw
(from the widgets-sgi directory) rather than libMesaGLwM (from
widgets-mesa).

I don't want to change configure to accept libMesaGLwM in place of
libGLwM unless it's known to work.

If GMSL/g3d isn't going to make it into the release, we may as well
just remove the GLw checks altogether; otherwise they just confuse
people.

I might add, the widgets should have appropriate symlinks. Like:

libGLwM.a --> libMesaGLwM.a

But I wouldn't recommend using the 3d grid stuff anyway (big bugs!).

--
Eric G. Miller <egm2@jps.net>

Glynn_Clements · June 6, 2001, 3:15am

Eric G. Miller wrote:

> Are you actually using r3.showdspf.openGL (from GMSL/g3d)? AFAIK, this
> is the only program which actually requires libGLwM. As it currently
> has outstanding bugs, it isn't in the 5.0.0 release branch in CVS.
>
> Also, its documentation specifically refers to using Mesa's libGLw
> (from the widgets-sgi directory) rather than libMesaGLwM (from
> widgets-mesa).
>
> I don't want to change configure to accept libMesaGLwM in place of
> libGLwM unless it's known to work.
>
> If GMSL/g3d isn't going to make it into the release, we may as well
> just remove the GLw checks altogether; otherwise they just confuse
> people.

I might add, the widgets should have appropriate symlinks. Like:

libGLwM.a --> libMesaGLwM.a

Note that Mesa includes both libGLw.a (widgets-sgi) and
libMesaGLw[M].a (widgets-mesa). The README for widgets-mesa says:

  * Provide a GLwDrawingArea widget which is 100%ly compatible with
  SGI's widget. Applications should port over with (almost) no
  changes to the source code.

It's the "almost" which concerned me.

However, the original SGI version only has a libGLw.a. The Mesa
version used to be this way, but it was changed (by me) to put the
Motif version into a separate library (otherwise you had to link
against libXm even if you only used the non-Motif widget).

XFree86 4.0.* again includes both Motif and non-Motif versions in its
version of libGLw.a. However, even if you add a libGLwM.a symlink,
configure won't detect it because, in that version,
GLwCreateMDrawingArea() is a macro which expands to either
GLwCreateM1DrawingArea() or GLwCreateM2DrawingArea() depending upon
whether XmVERSION is 1 or 2.

Anyway, all of this is moot unless g3d finds its way back into the
source tree.

So, should I get rid of the GLw checks altogether? Or is g3d's absence
likely to be only temporary?

--
Glynn Clements <glynn.clements@virgin.net>

Eric_G_Miller · June 6, 2001, 4:11am

On Wed, Jun 06, 2001 at 04:15:50AM +0100, Glynn Clements wrote:

Note that Mesa includes both libGLw.a (widgets-sgi) and
libMesaGLw[M].a (widgets-mesa). The README for widgets-mesa says:

  * Provide a GLwDrawingArea widget which is 100%ly compatible with
  SGI's widget. Applications should port over with (almost) no
  changes to the source code.

It's the "almost" which concerned me.

However, the original SGI version only has a libGLw.a. The Mesa
version used to be this way, but it was changed (by me) to put the
Motif version into a separate library (otherwise you had to link
against libXm even if you only used the non-Motif widget).

XFree86 4.0.* again includes both Motif and non-Motif versions in its
version of libGLw.a. However, even if you add a libGLwM.a symlink,
configure won't detect it because, in that version,
GLwCreateMDrawingArea() is a macro which expands to either
GLwCreateM1DrawingArea() or GLwCreateM2DrawingArea() depending upon
whether XmVERSION is 1 or 2.

Hmm, well I didn't know that much about the widgets. I only hacked the
configure script to try to find the libraries and includes...

Anyway, all of this is moot unless g3d finds its way back into the
source tree.

So, should I get rid of the GLw checks altogether? Or is g3d's absence
likely to be only temporary?

I think we should at least comment out the "widgets" parts in
configure.in with a little note. On a related matter, there are a
couple places where the "g3dcell" shows up (like g.remove output). It
might be a good idea to find those and disable them for the time being,
so user's don't get confused ideas about missing some functionality.

It's a bummer that the 3d stuff isn't working better, but there seems to
be an uncorrected discrepency about what exactly x,y, and z mean versus
regular 2d rasters (I understand y and x are reversed, or some such).
Also, there's only a bare minimum of modules to use g3d files
(r3.showdspf was never intended for end users, for instance). Since, no
one wanted to dig into the g3d library code, the problem remains
unresolved. I've looked at it, but never fully grok'ed it's cache
handling code. It also has a totally different method for encoding data
compared to the two main methods (+backward compatibility) used in libgis
for 2d rasters.

As a kind of side note to this all, I think the use of a file descriptor
as the "handle" for rasters limits some forward capabilities. There
shouldn't be any module that actually tries to directly read/write a
raster file. But, using a file descriptor makes it impossible to do
things like "catalogs" or segmented raster files -- things that would be
very useful to have. Maybe, it'd be possible to substitute some kind of
integer id for the file descriptor, then the library could transparently
handle such things. Anyway...

--
Eric G. Miller <egm2@jps.net>

Helena_Mitasova · June 19, 2001, 4:37pm

Markus,

maybe you can replace the outdated command list reference on grass
manual page with Eric's list - it is really useful both for new and
old users.

http://www.geog.uni-hannover.de/grass/gdp/html_grass5/grass_commandlist.html

And here are the broken links

http://www.geog.uni-hannover.de/grass/grass5/related/README.mesa3d
(this link is called from
http://www.geog.uni-hannover.de/grass/grass5/binary/linux/REQUIREMENTS.html

several links:
http://www.geog.uni-hannover.de/grass/gdp/html_grass5/programming/time/index.html

http://www.geog.uni-hannover.de/grass/gdp/html_grass5/programming/sites-api/index.html

http://www.geog.uni-hannover.de/grass/gdp/html_grass5/programming/raster/fpnv.html

http://www.geog.uni-hannover.de/grass/gdp/html_grass5/programming/g3d/index.html

called from
http://www.geog.uni-hannover.de/grass/grass5/index.html

Also please update:
http://www.geog.uni-hannover.de/grass/grid3d/index.html
it has a link to s.vol.rst binaries and says that sources won't be
distributed.

As for s.vol.rst - it may actually be useful to include it into GRASS5 - it
can be run
without the grid3 if it is run with the option of bivariate interpolation
with additional variable (for example precipitation with influence of
terrain).
We just got a paper accepted about it to TGIS and we say that it is available
in GRASS5, so it would be nice to have it there. It works very well and there
aren't
many programs around that can do that. However, there is a problem with
compilation
without the g3d library so I would have to take out all the volume stuff and
we
may end up again with 2 versions of similar program. So I don't know, let me
know
what do you think.
Figure 4b and a related animation in the document

http://www2.gis.uiuc.edu:2280/modviz/viz/sinter.html
and
http://www2.gis.uiuc.edu:2280/modviz/viz/tropy.html

illustrates what the program does The input is 2D raster of elevation and site
precipitation
and output is precipitation raster map. It can be used also for other
phenomena.

Helena

Markus Neteler wrote:

On Wed, Jun 06, 2001 at 04:15:50AM +0100, Glynn Clements wrote:
[...]
> Anyway, all of this is moot unless g3d finds its way back into the
> source tree.
>
> So, should I get rid of the GLw checks altogether? Or is g3d's absence
> likely to be only temporary?

Glynn,

this g3d absence *is* only temporary unless the bugs are fixed. Jaro
Hofierka offered to look into them, probably he will find the time.
Or, Helena, could you provide some help?

Basic bug is the 3D coordinates system confusion: The 3D coordinates system
should be similar to GRASS 2D, just with a 3rd dimension. At time some
modules read bottom-up, other top-down etc. Maybe much of the problems
can be cleaned out without too much work, only someone has to fully
understand the g3d concept.

Markus
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

From neteler Tue Jun 19 23:29:06 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id XAA00419; Tue, 19 Jun 2001 23:29:06 +0100
Date: Tue, 19 Jun 2001 23:29:06 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: Grass Developers <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Error to compile i.fft
Message-ID: <20010619232905.A29291@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Grass Developers <grass5@geog.uni-hannover.de>
References: <3B2F1895.3F60653F@hpcc.nectec.or.th> <20010619132536.M19538@hgeo02.geog.uni-hannover.de> <20010619140224.A25873@hgeo02.geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010619140224.A25873@hgeo02.geog.uni-hannover.de>; from neteler@geog.uni-hannover.de on Tue, Jun 19, 2001 at 02:02:25PM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 1770
Lines: 54

On Tue, Jun 19, 2001 at 02:02:25PM +0100, Markus Neteler wrote:

Hi,

again on the "gmath"/numerical functions issue...
I need a recommendation.

Currently we face following situation:

- src/libes/gmath/ has been written by David to support LAPACK/BLAS
   (it contains wrapper functions)
- we have spreading around numerous files containing various numerical
   functions like fft, ifft, matrix operations etc.

My intention is to assemble all functionality in one library. So
I started to migrate all such functions into src/libes/gmath/
(as I did for i.fft and accidentially already uploaded).

A problem arises on those machines, which don't have LAPACK/BLAS and "g2c"
(requirement, which is the former f2c.h) installed.
For example you will get, when compiling "gmath":
  src/include/la.h:28: g2c.h: No such file or directory
  make: *** [OBJ.sparc-sun-solaris2.6/la.o] Error 1

Two solutions may the at our choice:

  (1) split the library into two libraries
         a) LAPACK/BLAS routines
         b) others
  (2) add some clever mechanism to selectively compile with/without
      LAPACK/BLAS support. So far "configure" checks already the presence
      of LAPACK/BLAS.

I would vote for (2), but don't know how to implement it. Must be some
ifdef's around "la.h"?

So far I have updated configure now to search for g2c.h and f2c.h.
The src/libes/gmath/la.c is compiled only, if g2c.h is present (shall we
allow f2c.h as well?). That should do the trick for (2) above.

To test, please update

cvs up configure configure.in
cvs up src/include
cvs up src/libes/gmath

To test:
configure
gmake5 src/libes/gmath

No error should occur.

In case of problems, please let me know.

Markus

Eric_G_Miller · June 21, 2001, 1:51am

On Wed, Jun 20, 2001 at 09:20:10PM +0100, Markus Neteler wrote:

Helena,

On Tue, Jun 19, 2001 at 12:37:29PM -0400, Helena Mitasova wrote:
>
> Markus,
>
> maybe you can replace the outdated command list reference on grass
> manual page with Eric's list - it is really useful both for new and
> old users.
>
> http://www.geog.uni-hannover.de/grass/gdp/html_grass5/grass_commandlist.html

o.k, done. I have been using Eric's version as I don't get g.xml2html
compiled at time. Perhaps Eric can update again the
html/grass_commandlist.html

as I have added the missing descriptions? The web site will get updated
by cron_job.

I'll try to get them updated tonight. I can't guarantee I'll keep those
pages up forever. I want to look at using xsl stylesheets for
generating the output as it should be easier to tweak the looks and a
small perl script can probably do the job. At present I know 1.0e-19
about xslt, though ;0

--
Eric G. Miller <egm2@jps.net>

Eric_G_Miller · June 21, 2001, 7:45am

On Thu, Jun 21, 2001 at 08:34:21AM +0100, Markus Neteler wrote:

Hi Eric,

it would be perfect to update them in CVS (only?):
html/grass_commandlist.html

Then it appears on the web automagically.

Ahh, I see you have the index linking into the man page directory. Did
a little search and replace on the href's? I'll try to update it
tomorrow then (must sleep).

Been playing with XSL transformations, and they could really work out
nicely (once I figure out all the syntax). Should be easier to write the
transformation stylesheet to produce xhtml than to code up a complicated
program that'd break anytime the structure of the XML was changed
slightly (well, so would the XSL, but it should be much easier to
update). Figure if I can get the syntax worked out, we'd only need a
little shell script to call "xsltproc" (part of libxslt). Well, more on
this later...

--
Eric G. Miller <egm2@jps.net>

From neteler Thu Jun 21 11:08:45 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id LAA17103; Thu, 21 Jun 2001 11:08:45 +0100
Date: Thu, 21 Jun 2001 11:08:44 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Cc: "Eric G. Miller" <egm2@jps.net>
Subject: Re: [GRASS5] broken links in documentation and s.vol.rst
Message-ID: <20010621110844.J10015@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de,
  "Eric G. Miller" <egm2@jps.net>
References: <F97OONwIidWZe2BS7QT0000e753@hotmail.com> <15133.33019.929881.777086@cerise.nosuchdomain.co.uk> <20010605194015.D23813@calico.local> <15133.41062.452043.244362@cerise.nosuchdomain.co.uk> <20010611144400.B23503@hgeo02.geog.uni-hannover.de> <3B2F7FC9.A51A2D23@unity.ncsu.edu> <20010620212010.C9402@hgeo02.geog.uni-hannover.de> <20010620185133.B5949@calico.local> <20010621083421.I10015@hgeo02.geog.uni-hannover.de> <20010621004559.B14701@calico.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010621004559.B14701@calico.local>; from egm2@jps.net on Thu, Jun 21, 2001 at 12:45:59AM -0700
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 1135
Lines: 33

On Thu, Jun 21, 2001 at 12:45:59AM -0700, Eric G. Miller wrote:

On Thu, Jun 21, 2001 at 08:34:21AM +0100, Markus Neteler wrote:
> Hi Eric,
>
> it would be perfect to update them in CVS (only?):
> html/grass_commandlist.html
>
> Then it appears on the web automagically.

Ahh, I see you have the index linking into the man page directory. Did
a little search and replace on the href's? I'll try to update it
tomorrow then (must sleep).

Yes, please adjust the direct urls to the modules by
html/<module>

Then upload and everyone will get happy

Been playing with XSL transformations, and they could really work out
nicely (once I figure out all the syntax). Should be easier to write the
transformation stylesheet to produce xhtml than to code up a complicated
program that'd break anytime the structure of the XML was changed
slightly (well, so would the XSL, but it should be much easier to
update). Figure if I can get the syntax worked out, we'd only need a
little shell script to call "xsltproc" (part of libxslt). Well, more on
this later...

Sounds good...

Sleep well!

Markus