[GRASS5] GRASS 5.7.0 beta1

GRASS GRASS developer
1

I have created beta1 source package for 5.7.0 :
http://mpa.itc.it/radim/grass-5.7.0beta1.tar.gz (6.5 MB)

It is full source code (make copymix; make srcdist)
with files copied from 5.3.0. This version is not tagged in CVS.
The purpose of this version is to check if configure, make,
make bindist and *-install.sh works on various platforms.

I would appreciate if volunteers could try to
./configure (without --with-grass50 but with --with-postgres if possible)
make
make bindist
install binary package
start grass57 installed from the binary package

I have tested on Red Hat 7.1 and I'll try Read Hat 9.0. Let us know
if you can test another OS/distribution.

I want to release 5.7.0 next week.

Thanks.
Radim

2

On Monday 31 May 2004 15:12, Radim Blazek wrote:

I have created beta1 source package for 5.7.0 :
http://mpa.itc.it/radim/grass-5.7.0beta1.tar.gz (6.5 MB)

It is full source code (make copymix; make srcdist)
with files copied from 5.3.0. This version is not tagged in CVS.
The purpose of this version is to check if configure, make,
make bindist and *-install.sh works on various platforms.

I would appreciate if volunteers could try to
./configure (without --with-grass50 but with --with-postgres if possible)

./configure --without-postgres --with-tcltk-includes=/usr/include/tcl8.4
--without-odbc --without-fftw

make
make bindist
install binary package
start grass57 installed from the binary package

it built and installed fine on debian (unstable)

regards, Martin

3

Radim Blazek wrote:

I have created beta1 source package for 5.7.0 :
http://mpa.itc.it/radim/grass-5.7.0beta1.tar.gz (6.5 MB)

It is full source code (make copymix; make srcdist)
with files copied from 5.3.0. This version is not tagged in CVS. The purpose of this version is to check if configure, make, make bindist and *-install.sh works on various platforms.

I would appreciate if volunteers could try to

Radim,

Thank you for all your work. It is exciting to see all the progress.

On Gentoo (2004.0, kernel 2.4, gcc 3.3.2)
   works fine

On Cygwin (what version, I do not know)
   builds and installs without error, but nziv and v.digit do not work for me (this has been discussed previously).

Regards,
--
Richard Greenwood
www.greenwoodmap.com

4

Hello Radim,

two erros, probably not primarily due to the installation procedure but
nevertheless an error .. did it happen before?

1. v.digit: error while loading shared libraries: libtk.so.0: cannot open
shared object file: No such file or directory

ln -s to where?

2. the button options->toggle form mode keeps on top of every window until I
select it.

Martin

On Monday 31 May 2004 20:24, Martin Wegmann wrote:

On Monday 31 May 2004 15:12, Radim Blazek wrote:
> I have created beta1 source package for 5.7.0 :
> http://mpa.itc.it/radim/grass-5.7.0beta1.tar.gz (6.5 MB)
>
> It is full source code (make copymix; make srcdist)
> with files copied from 5.3.0. This version is not tagged in CVS.
> The purpose of this version is to check if configure, make,
> make bindist and *-install.sh works on various platforms.
>
> I would appreciate if volunteers could try to
> ./configure (without --with-grass50 but with --with-postgres if possible)

./configure --without-postgres --with-tcltk-includes=/usr/include/tcl8.4
--without-odbc --without-fftw

> make
> make bindist
> install binary package
> start grass57 installed from the binary package

it built and installed fine on debian (unstable)

regards, Martin

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

Thanks to all who tested.

On Monday 31 May 2004 17:26, Lorenzo Moretti wrote:

Platform: MAC OS X

Error:
The only problem is in r.mapcalc. The official 5.3 version
(15-05-2004) is wrong. Last cvs version is correct. I have copied
this version in your 5.7beta1 and I have built all modules.

What was wrong? Last change in grass/src/raster/r.mapcalc3 was 3 weeks ago
(May 11) before release_15_05_2004_grass5_3_0.

Another small error: tcltkgrass is old in 5.7beta1. Download last
version from Michael Barton site
(http://www.public.asu.edu/~cmbarton/grass.htm)

Only grass51/gui/tcltkgrass/Makefile has changed? I have updated in cvs.

PROJ support is missing from this final table but it's present in my
configure.

PROJ is requirement, so it is not printed.

On Tuesday 01 June 2004 10:21, Martin Wegmann wrote:

two erros, probably not primarily due to the installation procedure but
nevertheless an error .. did it happen before?

1. v.digit: error while loading shared libraries: libtk.so.0: cannot open
shared object file: No such file or directory

ln -s to where?

I have
/usr/lib/libtk8.3.so -> libtk.so.0
/usr/lib/libtk.so -> libtk.so.0
/usr/lib/libtk.so.0

2. the button options->toggle form mode keeps on top of every window until
I select it.

Which module, which button?

On Tuesday 01 June 2004 05:23, Richard Greenwood wrote:

On Cygwin (what version, I do not know)
   builds and installs without error, but nziv and v.digit do not work
for me (this has been discussed previously).

This I don't know how to fix.

I have also fixed the 'magic' bug in attributes form (update mode did non work).
It was most probably caused by GRASS_FORM_MODE variable which I replaced by
'-e' flag in d.what.vect. d.m global option moved to vector's options.
d.what.vect will from now by default use VIEW mode.

Radim

6

On Mon, 31 May 2004, Radim Blazek wrote:

I would appreciate if volunteers could try to
./configure (without --with-grass50 but with --with-postgres if possible)
make
make bindist
install binary package
start grass57 installed from the binary package

Worked OK compiling on an IRIX 6.2 system and installing on IRIX 6.4.
Configure line was
  CFLAGS="-O" LDFLAGS="-s" ./configure --with-libs=/usr/local/lib --with-includes=/usr/local/include --with-dbm=no --with-odbc=no
--with-postgres=no --with-fftw=yes --with-motif=yes --with-blas=yes
--with-cxx=no --with-opendwg
--with-opendwg-includes=/indigo-disk2/grass/opendwg/toolkit --with-opendwg-libs=/indigo-disk2/grass/opendwg/toolkit
and the only modification required before running make was the usual one of commenting out the HAVE_KEYPAD line in include/config.h so it will work with the (buggy) IRIX Winterm.

After installing the message reported

Installation finished. Start GRASS 5.7.0-mips-sgi-irix6.2-01_06_2004 with
     /usr/local/bin/grass-5.7.0-mips-sgi-irix6.2-01_06_2004

which is kind of off-putting! Especially as all that needed to be typed was grass57.

One another annoyance is that all the monitors closed down when exiting. Is this a new feature? I usually just leave monitors running permanently and if just exiting and restarting quickly to change location this could become annoying.

But overall looking good. Very small package and quick to install as well.

Paul

7

Thanks.

On Tuesday 01 June 2004 17:56, Paul Kelly wrote:

Worked OK compiling on an IRIX 6.2 system and installing on IRIX 6.4.
Configure line was
  CFLAGS="-O" LDFLAGS="-s" ./configure --with-libs=/usr/local/lib
--with-includes=/usr/local/include --with-dbm=no --with-odbc=no
--with-postgres=no --with-fftw=yes --with-motif=yes --with-blas=yes
--with-cxx=no --with-opendwg
--with-opendwg-includes=/indigo-disk2/grass/opendwg/toolkit
--with-opendwg-libs=/indigo-disk2/grass/opendwg/toolkit
and the only modification required before running make was the usual one
of commenting out the HAVE_KEYPAD line in include/config.h so it will work
with the (buggy) IRIX Winterm.

After installing the message reported

Installation finished. Start GRASS 5.7.0-mips-sgi-irix6.2-01_06_2004 with
     /usr/local/bin/grass-5.7.0-mips-sgi-irix6.2-01_06_2004

which is kind of off-putting! Especially as all that needed to be typed
was grass57.

I have changed that now to $BINDIR/$GRASSPRG (= $BINDIR/grass57).

One another annoyance is that all the monitors closed down when exiting.
Is this a new feature? I usually just leave monitors running permanently
and if just exiting and restarting quickly to change location this could
become annoying.

Yes, new feature:
http://grass.itc.it/pipermail/grass5/2004-May/014486.html
http://grass.itc.it/pipermail/grass5/2004-May/014528.html

I know that it is more work now, I was used to do the same. Maybe
it is just question of a habit because now it is possible to start more
sessions at the same time. Anyway, I think that the possibility
to run (without tricks) more sessions (e.g. scripts in one mapset
and interactive work in another) is more important than
this inconvenience.
We can maybe find a way how to reopen monitors when grass is started in X?

Radim

8

I have created beta2:
http://mpa.itc.it/radim/grass-5.7.0beta2.tar.gz

All bugs found (except nviz/v.digit on Cygwin) hopefully fixed.
This is mixed with 5.3 HEAD from CVS (even if I don't know
why 5.3.0 should not work).

Radim

PS: I have seen new features submitted to 5.3 HEAD after 5.3.0, why that?

9

PS: I have seen new features submitted to 5.3 HEAD after 5.3.0, why
that?

I was not aware there was now a feature freeze in place. Is there???
Is this temporary until 5.7.0 is done? or should all new raster changes,
e.g., go only into 5.7? What about minor-bugfixes? Should we hold off on
them until 5.7.0-final?

One of the things I just added[*] was specifically for easing the
transition to 5.7..

[*] 'v.in.ascii -s' to automatically run 'v.support -r' after importing

Hamish

10

One of the things I just added[*] was specifically for easing the
transition to 5.7..

[*] 'v.in.ascii -s' to automatically run 'v.support -r' after importing

.. but obviously this isn't seen by copymix ..

There were other raster+lib changes though.

H

11

I have created beta2:
http://mpa.itc.it/radim/grass-5.7.0beta2.tar.gz

$ diff SRCPKG MIX
$
?

AUTHORS:
"RASTER
see 5.0 authors"

We should probably mix in a copy of AUTHORS_5.0 or something.

the TODO file:
- some are done but still in there

REQUIREMENTS.html:
- GDAL is now not optional?
- copyright at end of file 2003

compiled on Debian/testing (Sarge) on i686:

CFLAGS="-ggdb -march=pentium4 -Wall" ./configure \
     --with-tcltk-includes=/usr/include/tcl8.3 \
     --with-postgres-includes=/usr/include/postgresql \
     --with-motif --with-motif-includes=/usr/X11R6/include \
     --with-readline --with-gdal --with-cxx --with-glw

GRASS is now configured for: i686-pc-linux-gnu

Source directory: /usr/local/src/grass/grass-5.7.0
Build directory: /usr/src/grass/grass-5.7.0
Installation directory: /usr/local/grass57
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -ggdb -march=pentium4 -Wall
C++ compiler: c++ -g -O2
FORTRAN compiler: g77
Building shared libraries: yes

  NVIZ: yes

  X11 support: yes
  JPEG support: yes
  TIFF support: yes
  PNG support: yes
  Tcl/Tk support: yes
  PostgreSQL support: yes
  MySQL support: no
  OpenGL(R) support: yes
  ODBC support: yes
  FFTW support: yes
  BLAS support: no
  LAPACK support: no
  Motif support: yes
  FreeType support: no
  GLw support: yes
  NLS support: no
  Readline support: yes
  C++ support: yes
  openDWG support: no
  GDAL support: yes
  OGR support: yes

builds ok
I ran 'make bindist' but didn't install with it.

'nviz elev=topo' works.
v.digit works.

Tcltkgrass: (looks really nice; some things need to be greyed out?)

[Import|Export] -> Vector -> Import/Export old GRASS vector format
v.convert is import only, are there plans to change that, or is
'v.out.ascii -o' the official way?

Export -> Raster -> GRASS ASCII:
as this does Surfer & Modflow formats as well, maybe just
"Export->ASCII"?

Display -> Display Manager
maybe that should read "[Start|Launch] Display Manager"

Display -> NVIZ visualization tool
maybe that should real "[Start|Launch] NVIZ visualization"
(tool is redundant, or at least not the right word..)

Generic Menu items: is it possible to give the module name (eg d.mon) in
a hint box upon mouseover?

Help -> Authors?
Maybe a flag from g.version?

congrats to all on a really nice job ..

Hamish

12

> One another annoyance is that all the monitors closed down when
> exiting. Is this a new feature? I usually just leave monitors
> running permanently and if just exiting and restarting quickly to
> change location this could become annoying.

Yes, new feature:
http://grass.itc.it/pipermail/grass5/2004-May/014486.html
http://grass.itc.it/pipermail/grass5/2004-May/014528.html

I know that it is more work now, I was used to do the same. Maybe
it is just question of a habit because now it is possible to start
more sessions at the same time. Anyway, I think that the possibility
to run (without tricks) more sessions (e.g. scripts in one mapset
and interactive work in another) is more important than
this inconvenience.
We can maybe find a way how to reopen monitors when grass is started
in X?

How safe is this for changing mapsets via g.gisenv? I'm doing that all
day long. That works with 5.7.0 (+d.redraw), but I don't want to badly
screw anything up by mistake..

I know it's up to me not to have the same mapset loaded twice, but what
happens if on a bad day I do?

Do I have to add $LOCATION/$MAPSET/.gislock management to my mapset
changing script? I'm already running $GISBASE/etc/clean_temp upon exit..

Or is this tied to the process id that started it? Upon exiting GRASS
5.7.0 I get: ERROR: LOCATION_NAME not set

but it seems to be ok in ~/.grassrc57
?

thanks,
Hamish

13

Hamish wrote:

> PS: I have seen new features submitted to 5.3 HEAD after 5.3.0, why
> that?

I was not aware there was now a feature freeze in place. Is there???

yes, there is. No new features for 5.3

Is this temporary until 5.7.0 is done? or should all new raster changes,
e.g., go only into 5.7?

everything new should go into 5.7

What about minor-bugfixes?

that is all that can go into 5.3 so that 5.4 stable can be released.

Helena

Should we hold off on

them until 5.7.0-final?

One of the things I just added[*] was specifically for easing the
transition to 5.7..

[*] 'v.in.ascii -s' to automatically run 'v.support -r' after importing

Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

14

Now the display manager pops-up and a "task bar" -- looks great, much
more modules included, looks pretty sophisticated!

Nice, isn't it.

BTW when I do v.digit -> polygon and click right mouse button the
polygon should be closed, shouldn't it? In the display it is still
open.

Hm. That's not working correctly for me either.

Snapping only seems to work with previously established nodes; you can
change the thresholds in the settings menu, the default is 10 screen
pixels. So currently you need to use the "add vertex" tool to close the
area? Or move well away with the "move vertex" tool and then move it
back to get the area to close properly. shrug.

Hamish

15

On Wednesday 02 June 2004 12:43, Hamish wrote:

> I have created beta2:
> http://mpa.itc.it/radim/grass-5.7.0beta2.tar.gz

$ diff SRCPKG MIX
$
?

MIX stores the info about 5.0 version (must be created by make mix),
SRCPKG sais that it is full 5.7 package (must be created by make bindist).
Both are temporary untill 5.0 is merged, not important I think.

AUTHORS:
"RASTER
see 5.0 authors"

We should probably mix in a copy of AUTHORS_5.0 or something.

Yes.

the TODO file:
- some are done but still in there

Like doc/v.modules.html, my suggestion is to remove files we know
we are not able to keep up-to-date.

REQUIREMENTS.html:
- GDAL is now not optional?

I don't think so.

Tcltkgrass: (looks really nice; some things need to be greyed out?)

[Import|Export] -> Vector -> Import/Export old GRASS vector format
v.convert is import only, are there plans to change that,

No.

or is 'v.out.ascii -o' the official way?

Yes.

Radim

16

On Wednesday 02 June 2004 13:17, Hamish wrote:

> > One another annoyance is that all the monitors closed down when
> > exiting. Is this a new feature? I usually just leave monitors
> > running permanently and if just exiting and restarting quickly to
> > change location this could become annoying.
>
> Yes, new feature:
> http://grass.itc.it/pipermail/grass5/2004-May/014486.html
> http://grass.itc.it/pipermail/grass5/2004-May/014528.html
>
> I know that it is more work now, I was used to do the same. Maybe
> it is just question of a habit because now it is possible to start
> more sessions at the same time. Anyway, I think that the possibility
> to run (without tricks) more sessions (e.g. scripts in one mapset
> and interactive work in another) is more important than
> this inconvenience.
> We can maybe find a way how to reopen monitors when grass is started
> in X?

How safe is this for changing mapsets via g.gisenv? I'm doing that all
day long. That works with 5.7.0 (+d.redraw), but I don't want to badly
screw anything up by mistake..

This is not affected.

I know it's up to me not to have the same mapset loaded twice, but what
happens if on a bad day I do?

You get wrong outputs. I forgot about this possibility.

Do I have to add $LOCATION/$MAPSET/.gislock management to my mapset
changing script? I'm already running $GISBASE/etc/clean_temp upon exit..

Yes.

Or is this tied to the process id that started it? Upon exiting GRASS
5.7.0 I get: ERROR: LOCATION_NAME not set

but it seems to be ok in ~/.grassrc57

Not clear to me when did you get this.

What about official
g.mapset/g.chmapset/g.set/g.reset/? gisdbase= location= mapset=
which would check if the mapset is in use, reset variables and run d.erase?
This should be in 5.7.0, I think. Otherwise it is too dangerous.

Radim

17

On Thursday 03 June 2004 04:01, Hamish wrote:

> Now the display manager pops-up and a "task bar" -- looks great, much
> more modules included, looks pretty sophisticated!

Nice, isn't it.

> BTW when I do v.digit -> polygon and click right mouse button the
> polygon should be closed, shouldn't it? In the display it is still
> open.

Hm. That's not working correctly for me either.

Snapping only seems to work with previously established nodes; you can
change the thresholds in the settings menu, the default is 10 screen
pixels. So currently you need to use the "add vertex" tool to close the
area? Or move well away with the "move vertex" tool and then move it
back to get the area to close properly. shrug.

Yes.

Radim

18

On Thursday 03 June 2004 11:35, Radim Blazek wrote:

What about official
g.mapset/g.chmapset/g.set/g.reset/? gisdbase= location= mapset=
which would check if the mapset is in use, reset variables and run d.erase?
This should be in 5.7.0, I think. Otherwise it is too dangerous.

I have written g.mapset which does that (check mapset permission,
clean temporary files, erase monitors, reset variables).
But I don't know how to change shell settings (rc and history files),
so I hesitate to add it into CVS.

Radim

19

Radim Blazek wrote:

I have written g.mapset which does that (check mapset permission,
clean temporary files, erase monitors, reset variables).
But I don't know how to change shell settings (rc and history files),
so I hesitate to add it into CVS.

You cannot write a command to change the shell's environment. This is
the main reason why we have $GISRC and G_getenv() etc instead of just
using environment variables.

Although, GISRC shouldn't need to be changed; it should remain
constant for the duration of a session.

And, environment issues aside, you can't make the shell close the
history file and start writing a new one. You just have to accept the
fact that the history will be stored in the starting mapset.

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

20

On Friday 04 June 2004 00:29, Glynn Clements wrote:

And, environment issues aside, you can't make the shell close the
history file and start writing a new one. You just have to accept the
fact that the history will be stored in the starting mapset.

In bash it is possible to do

export HISTFILE=myhist1
history -w
history -r myhist2

similarly in tcsh it should be possible

history -S myhist1
history -L myhist2

but it must be in a script without #!/bin/, is it a problem?

Radim