[GRASS5] testing GRASS5.0.0pre1

[Markus Neteler]

Hi  Andreas,

On Thu, Apr 19, 2001 at 11:51:21AM +0200, Andreas Lange wrote:
> Hi 2 all,
> 
> I checked out the 5.0.0pre1 tagged version from CVS (fresh checkout) and
> recompiled on Linux, FreeBSD/Alpha, IRIX and Windows 2000/cygwin. 
> 
> 
> Linux (Red Hat 7.0, Kernel 2.2.17, gcc 2.96):
> compiles without any problems, but could not test many
> programs. Basics work (tcltkgrass, display etc.), but have to test
> r.in.gdal and NVIZ 2.2.
> Does someone have a set of testing data for r.in.gdal?

maybe your try these sample data:
http://csd-esic.unl.edu/drg100.htm
(Nebraska)

r.in.gdal -e input=AINSWORTH.tif  out=ainsworth location=testlocation

Start this command in any other location (as r.in.gdal only works within
GRASS), it will generate a new *location* from the dataset.


> FreeBSD 4.2 (Alpha 64bit, gcc)
> recompiles without problems, can not compile NVIZ2.2, because i 
> have not installed mesa/openGL. 
> Optimizing is not possible (removed -O2 flag!), due to bug in 
> gcc on FreeBSD-Alpha.

Sidenote:
For all not knowing this (like me until last week):
If you would like to set compiler optimisations, for a smaller binary, type,

        CFLAGS=-O2 ./configure
or,
        setenv CFLAGS -O
        ./configure

So no need to edit the head file manually. I have added this to the
INSTALL file.

> Works if i replace the wish script with a softlink to wish8.3
> (How can i change the GRASS_WISH variable for my installation?).
grass5 -help
Environment variables:
    GRASS_TCLSH                    set tclsh shell name to override 'tclsh'
    GRASS_WISH                     set wish shell name to override 'wish'

> I can confirm that it is possible to import ASCII/DXF vector files
> and to manipulate them. The demo vector files are not readable due
> to the 64bit environment. 
> Left out r.in.gdal and NVIZ 2.2.
> 
> 
> IRIX 6.5 (32bit, latest gcc from freeware.sgi.com) One has to remove the
> -I/usr/freeware/include line to gcc in order to get any library to
> compile. Don't know why, but with the line the libraries fail to compile
> and nearly no modules are built.
> I still use all options to ./configure, but i did not try if this is
> still  needed. NVIZ 2.2 compiles and works! Great!
> The only module i left out is r.in.gdal. Did not test postgresql.
Doesn't r.in.gdal compile? Or why do you leave it?

> Windows 2000/cygwin 1.1.8/gcc
> Everything compiles out of the box (when using my compiling
> instructions!). 
> I had a problem compiling r.mapcalc in
> the first run, but could not reproduce this. With the StarNet demo
> everything seems to work.
> I left out r.in.gdal and NIVZ 2.2. r.in.gdal compiles, but last time i
> tested it did only core-dump. NVZI does not compile, John reports that
> it did compile, but his fix does not work with my installation.
> There are problems with localization libraries if installing the Windows
> 2000 binary (xtcltk binary) on NT 4.0. But the other way round it seems
> to work. So one should compile always on NT 4.0. 
> The odbc drivers compile, but i did not test anything. PostgreSQL does
> not compile on my machine, but i think that postgreSQL is not ready for
> wider use (you need a "cutting edge" cygwin1.dll and the ipc daemon
> installed and running in order to start the server part!).
> 
> 
> The only real BUG that needs IMHO fixed for the 5.0.0stable version is the
> CELL driver problem.  The colors are sometimes wrong, but it is not always
> black/white that are changed. I have no clue.

> On Windows in noticed that the CELL driver could only be started and
> stopped once, the socket is not removed, so that on restarting the driver
> i get the message "can not bind to socket...". Very annoying.
> Is this a problem on Linux too? I have to check. 

This is the timing bug which is currently addressed by Glynn and Eric.

> Minor bugs/problems (all with FreeBSD/ALPHA):
> 
> v.out.e00:
> does not read vector files from other mapsets,
> e. g. coastlines at PERMANENT, when in mapset andreas
> Produces coredump on coastlines mapset from global5
> dataset (on linux)!

Hi Michel :-)

> v.out.arc:
> not a bug, but the manual page does not mention
> that the generated arc-files are stored under
> $LOCATION/arc !

Yesterday this was changed. It saves the data into the current
directory now. Just now I have added such a note in the man page.
 
> d.zoom (lat/lon on Alpha/FreeBSD):
> does not keep color of vector file!
> does not recognize that background color
> was white/different from black?
> 
> d.zoom has problems with rubber-band box in lat/lon 
> locations?
This runs well here. Maybe it is a platform specific bug?
 
> sorry that some messages may not be clear, but i wrote this before the
> easter break and my memory is fading...

Thanks for your tests!

 Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'