[GRASS5] 5.4 release branch

GRASS GIS GRASS GIS developer
1

I think the way forward now is to create a new branch in CVS and prepare 5.4.0 from it. I'm starting to think now maybe 5.3.1 would be a waste of effort. I will create a new branch in a few days if there aren't many objections.

Here is my first rough draft of what to put in the NEWS file for 5.4.0, additions and corrections welcome:

Raster I/O re-write incorporating support for files > 2GB (Glynn)
Support for zlib compression in integer/CELL maps (Glynn)
g.pnmcomp: Added (Glynn)

PNGdriver: can now also write PPMs and optionally supports incremental writing of PNG after each display operation (Glynn)

Doxygen comments for improved Programmers' Manual (Markus)

r.colors new format for rules files (Hamish, Glynn)

nviz: some bugfixes (Glynn, Hamish)

Cygwin and Mac OSX shared library compilation working (Paul)

ps.map floating point legend fixes (Hamish)

rgb.hsv.sh bugfix (Glynn)
r.buffer nautical miles support (Hamish)
Raster map titles standardised to 1024 characters in all relevant modules and libraries (Hamish)

r.univar2 now operational (Hamish)
v.in.garmin.sh now operational (Hamish)

Various compiler warnings fixed (Glynn)

d.zoom fixes (Hamish)

Longer names for database, location and mapset allowed in start-up screen (Markus, Glynn)

2

Here is my first rough draft of what to put in the NEWS file for 5.4.0,
additions and corrections welcome:

r.univar2 now operational (Hamish)

This isn't built by default, so I don't think it is worth mentioning.
[goes for d.nviz, r.series, etc too]

v.in.garmin.sh now operational (Hamish)

(it did work before, just not as well..)

d.zoom fixes (Hamish)

Might make that "d.zoom fixes for lat/lon" ?

The floating-point Lat/Lon dateline crossing bugfix should be mentioned.

Hamish

3

Hello Hamish

On Tue, 12 Oct 2004, Hamish wrote:

Here is my first rough draft of what to put in the NEWS file for 5.4.0,
additions and corrections welcome:

r.univar2 now operational (Hamish)

This isn't built by default, so I don't think it is worth mentioning.
[goes for d.nviz, r.series, etc too]

OTOH I think it's now or never for enabling useful modules that aren't compiled, as the 5.4 verison will be frozen. I was planning on checking and enabling a few before the release. I suppose that could result in more build problems that would take a while to sort out though (some of the recent src.contrib stuff). It's just that quite a lot of the stuff mentioned
in the 5.3.0 release announcement wasn't compiled by default.

Making a mental note to change the other things you noted when I update the NEWS after creating the branch,

Paul

4

On Mon, Oct 11, 2004 at 09:14:29PM +0100, Paul Kelly wrote:

I think the way forward now is to create a new branch in CVS and prepare
5.4.0 from it. I'm starting to think now maybe 5.3.1 would be a waste of
effort. I will create a new branch in a few days if there aren't many
objections.

Great!

Here is my first rough draft of what to put in the NEWS file for 5.4.0,
additions and corrections welcome:

Raster I/O re-write incorporating support for files > 2GB (Glynn)

Probably it should become a flag for 'configure' (maybe that is already?)?

Support for zlib compression in integer/CELL maps (Glynn)

How to activate it? Is that documented?

g.pnmcomp: Added (Glynn)

Is it documented?

PNGdriver: can now also write PPMs and optionally supports incremental
writing of PNG after each display operation (Glynn)

Doxygen comments for improved Programmers' Manual (Markus)

I need to clean the libgis file (.dox), hopefully tomorrow.

r.colors new format for rules files (Hamish, Glynn)

Is there a possibility to make the parser (a function) list the
available color files? Such as the 5.7 db.* tools list the available DB
drivers?

nviz: some bugfixes (Glynn, Hamish)

Cygwin and Mac OSX shared library compilation working (Paul)

ps.map floating point legend fixes (Hamish)

rgb.hsv.sh bugfix (Glynn)
r.buffer nautical miles support (Hamish)
Raster map titles standardised to 1024 characters in all relevant modules
and libraries (Hamish)

r.univar2 now operational (Hamish)
v.in.garmin.sh now operational (Hamish)

Various compiler warnings fixed (Glynn)

d.zoom fixes (Hamish)

Longer names for database, location and mapset allowed in start-up screen
(Markus, Glynn)

Markus

5

Markus Neteler wrote:

> Here is my first rough draft of what to put in the NEWS file for 5.4.0,
> additions and corrections welcome:
>
>
> Raster I/O re-write incorporating support for files > 2GB (Glynn)

Probably it should become a flag for 'configure' (maybe that is already?)?

I'm not sure about the right way to implement this. Ideally, it should
only be the core raster I/O files which I changed which should be
using the large-file support, as the rest of GRASS won't handle large
files correctly.

One possibility is to make configure define a macro, e.g.
RASTER_LARGEFILE, in config.h, and have the files in question do:

  #include "config.h"
  #ifdef RASTER_LARGEFILE
  #define FILE_OFFSET_BITS 64
  #endif

before including any other headers. But that seems a bit messy.

> Support for zlib compression in integer/CELL maps (Glynn)

How to activate it?

If the environment variable GRASS_INT_ZLIB exists, new compressed
rasters will be compressed using zlib instead of RLE compression. Such
rasters will have a "compressed" value of 2 in the cellhd file.
Obviously, decompression is controlled by the raster's "compressed"
value, not the environment variable.

Is that documented?

Not yet.

> g.pnmcomp: Added (Glynn)

Is it documented?

No.

It's intended for internal use only, if at all. It composes a set of
PPM/PGM files (where a PGM file contains the alpha channel for a
specific PPM file) into a single PPM file.

The idea is to consider using it in d.m, in conjunction with the PNG
driver. d.m would render each layer as a PPM/PGM pair (the PNG driver
will generate these if $GRASS_PNGFILE ends in ".ppm" and
$GRASS_TRANSPARENT is "TRUE").

If the layer stack is changed (enabling or disabling layers, changing
the ordering), d.m would only need to re-compose the
(already-rendered) PPM/PGM files, which is much faster than
re-rendering everything using the d.* programs.

This assumes that d.m would be displaying the composed image itself
(in a Tk widget) rather than via XDRIVER.

> r.colors new format for rules files (Hamish, Glynn)

Is there a possibility to make the parser (a function) list the
available color files? Such as the 5.7 db.* tools list the available DB
drivers?

Can you elaborate?

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

6

> r.colors new format for rules files (Hamish, Glynn)

Is there a possibility to make the parser (a function) list the
available color files? Such as the 5.7 db.* tools list the available DB
drivers?

I think a -l flag for r.colors is the way to go. (ala 'g.mapsets -l')

Hamish

7

Hello Hamish

On Wed, 13 Oct 2004, Hamish wrote:

[...]

also r.[in|out].mat, r.grow2, more..?
mind r.univar2 doesn't collide with the script version. Had to rename
the script in 5.7.

r.grow2 is already enabled. Will look at the others or someone else can.

Can a cvs2cl.pl 5.3->HEAD changelog be posted somewhere? (I don't know how)

'make ChangeLog' using the alternate build mechanism. I'll make it the default soon (of course announce it at the same time).
Copy as of this morning available in /pub/users/paulk/grass on ftp.qub.ac.uk

will we have a 5.4rc- for at least a week?

No problem.

Paul

8

On Wed, Oct 13, 2004 at 10:29:40AM +1300, Hamish wrote:

> > r.colors new format for rules files (Hamish, Glynn)
>
> Is there a possibility to make the parser (a function) list the
> available color files? Such as the 5.7 db.* tools list the available DB
> drivers?

I think a -l flag for r.colors is the way to go. (ala 'g.mapsets -l')

Yes, something like this, which then reports the following list:

ls $GISBASE/etc/colors
aspect bcyr byg byr elevation evi grey gyr rainbow ramp ryg slope srtm terrain wave

Not sure how to implement that (I tried but didn't manage).

Markus

9

Markus Neteler wrote:

> > > r.colors new format for rules files (Hamish, Glynn)
> >
> > Is there a possibility to make the parser (a function) list the
> > available color files? Such as the 5.7 db.* tools list the available DB
> > drivers?
>
>
> I think a -l flag for r.colors is the way to go. (ala 'g.mapsets -l')

Yes, something like this, which then reports the following list:

ls $GISBASE/etc/colors
aspect bcyr byg byr elevation evi grey gyr rainbow ramp ryg slope srtm terrain wave

Not sure how to implement that (I tried but didn't manage).

I've added this.

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

10

Paul Kelly wrote:

> also r.[in|out].mat, r.grow2, more..?
> mind r.univar2 doesn't collide with the script version. Had to rename
> the script in 5.7.

r.grow2 is already enabled. Will look at the others or someone else can.

I've enabled r.series.

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

11

On Wed, Oct 13, 2004 at 07:52:27PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > > > r.colors new format for rules files (Hamish, Glynn)
> > >
> > > Is there a possibility to make the parser (a function) list the
> > > available color files? Such as the 5.7 db.* tools list the available DB
> > > drivers?
> >
> >
> > I think a -l flag for r.colors is the way to go. (ala 'g.mapsets -l')
>
> Yes, something like this, which then reports the following list:
>
> ls $GISBASE/etc/colors
> aspect bcyr byg byr elevation evi grey gyr rainbow ramp ryg slope srtm terrain wave
>
> Not sure how to implement that (I tried but didn't manage).

I've added this.

Great - thank you very much.

Markus

12

Just a more generic restating of my request of a few minutes ago.

If in sorting out what does and does not get automatically compiled in 5.4,
there are new modules that need to be added to tcltkgrass (or old ones to be
deleted), please let me know so that I can make the changes. I'll follow the
discussion here, of course, but some kind of compiled list would make this
easier and more accurate.

Thanks.

Michael Barton

On 10/13/04 1:41 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Hello Hamish

On Wed, 13 Oct 2004, Hamish wrote:

[...]

also r.[in|out].mat, r.grow2, more..?
mind r.univar2 doesn't collide with the script version. Had to rename
the script in 5.7.

r.grow2 is already enabled. Will look at the others or someone else can.

Can a cvs2cl.pl 5.3->HEAD changelog be posted somewhere? (I don't know how)

'make ChangeLog' using the alternate build mechanism. I'll make it the
default soon (of course announce it at the same time).
Copy as of this morning available in /pub/users/paulk/grass on
ftp.qub.ac.uk

will we have a 5.4rc- for at least a week?

No problem.

Paul

______________________________
Michael Barton, Professor of Anthropology
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

13

Hello Michael

On Thu, 14 Oct 2004, Michael Barton wrote:

Just a more generic restating of my request of a few minutes ago.

If in sorting out what does and does not get automatically compiled in 5.4,
there are new modules that need to be added to tcltkgrass (or old ones to be
deleted), please let me know so that I can make the changes. I'll follow the
discussion here, of course, but some kind of compiled list would make this
easier and more accurate.

Off the top of my head, r.grow2, r.in.mat, r.out.mat have been or will be enabled for 5.4.0. Check the release notes for 5.3.0 for ideas for more that might need tcltkgrass modules.

Paul

14

OK. Thanks much Paul.

Michael

On 10/14/04 1:50 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Hello Michael

On Thu, 14 Oct 2004, Michael Barton wrote:

Just a more generic restating of my request of a few minutes ago.

If in sorting out what does and does not get automatically compiled in 5.4,
there are new modules that need to be added to tcltkgrass (or old ones to be
deleted), please let me know so that I can make the changes. I'll follow the
discussion here, of course, but some kind of compiled list would make this
easier and more accurate.

Off the top of my head, r.grow2, r.in.mat, r.out.mat have been or will be
enabled for 5.4.0. Check the release notes for 5.3.0 for ideas for more
that might need tcltkgrass modules.

Paul

______________________________
Michael Barton, Professor of Anthropology
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

15

Michael Barton wrote:

Just a more generic restating of my request of a few minutes ago.

If in sorting out what does and does not get automatically compiled in 5.4,
there are new modules that need to be added to tcltkgrass (or old ones to be
deleted), please let me know so that I can make the changes. I'll follow the
discussion here, of course, but some kind of compiled list would make this
easier and more accurate.

r.series and r.grow2 are now enabled.

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

16

Today I added:
d.info
r.in.mat
r.out.mat
r.univar2 (and renamed r.univar to r.univar.sh)
s.kernel
d.nviz
to src/CMD/lists/GRASS

I had a quick look through the 5.3.0 release notes and unless I've missed something these were the only modules that actually compile without errors (on IRIX and Solaris) that weren't already compiled by default. The others can wait until bugfixes make them ready for a later 5.4.x release.

As they are just new modules, I'm not sure they should all be added to tcltkgrass yet. I'd like to release 5.4.0 (well the release candidate anyway)
quite soon; one thing that remains to do is perhaps add a configure option to enable large file support? Any thoughts, anybody?

Paul

17

On Tue, 12 Oct 2004, Glynn Clements wrote:

[...]

Raster I/O re-write incorporating support for files > 2GB (Glynn)

Probably it should become a flag for 'configure' (maybe that is already?)?

I'm not sure about the right way to implement this. Ideally, it should
only be the core raster I/O files which I changed which should be
using the large-file support, as the rest of GRASS won't handle large
files correctly.

I think maybe we should put support for it into the 5.7 configure script, encourage people to use 5.7 if they want large raster file support, and leave it as an undocumented unsupported feature of 5.4 for now.

Paul

18

On Tue, 12 Oct 2004, Markus Neteler wrote:

On Mon, Oct 11, 2004 at 09:14:29PM +0100, Paul Kelly wrote:

I think the way forward now is to create a new branch in CVS and prepare
5.4.0 from it. I'm starting to think now maybe 5.3.1 would be a waste of
effort. I will create a new branch in a few days if there aren't many
objections.

Great!

OK, here is the plan:
On Monday or Tuesday I plan to create a new CVS branch with the latest revisions of all files in the HEAD as the branch point. The branch will be called 'releasebranch_5_4'.
There is a script tools/cvsbranch.sh but I decided not to use this, as I feel it is more convenient and transparent if the whole source tree is included in the release branch and source distributions. I also feel it is inappropriate to include a date in the branch tag as the date it was created
is not significant, and it will be used for all 5.4.x releases.

After the branch has been created, any new features added to the CVS HEAD will not be in the 5.4 releases and will probably never be released, as development and releases will now all be done in the grass51 CVS module. Only bugfixes should be committed to the release branch and if in doubt about if something should be added, it should be discussed on the mailing list.

After creating the release branch I will update the configure script there so it uses the alternate build mechanism by default. Then we can prepare the 5.4.0 release candidate for testing by the middle of this week.

Does this sound like a reasonable plan?

Paul

19

I think this is great but need to know what to do with a few updates to
tcltkgrass. I guess I'd call them bug fixes. I added in all the new default
compile command modules that have just been added to 5.4 yesterday, but was
waiting for an answer to my question about r.grow2 so I could add it also. I
can commit what I have tomorrow. But since I'm in Arizona, I fear that you
will have already made the switch. I can download a new cvs sandbox for 5.4
when I know the path if your prefer. What do you advise?

Michael

On 10/17/04 8:04 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Tue, 12 Oct 2004, Markus Neteler wrote:

On Mon, Oct 11, 2004 at 09:14:29PM +0100, Paul Kelly wrote:

I think the way forward now is to create a new branch in CVS and prepare
5.4.0 from it. I'm starting to think now maybe 5.3.1 would be a waste of
effort. I will create a new branch in a few days if there aren't many
objections.

Great!

OK, here is the plan:
On Monday or Tuesday I plan to create a new CVS branch with the latest
revisions of all files in the HEAD as the branch point. The branch will be
called 'releasebranch_5_4'.
There is a script tools/cvsbranch.sh but I decided not to use this, as I
feel it is more convenient and transparent if the whole source tree is
included in the release branch and source distributions. I also feel it is
inappropriate to include a date in the branch tag as the date it was created
is not significant, and it will be used for all 5.4.x releases.

After the branch has been created, any new features added to the CVS HEAD
will not be in the 5.4 releases and will probably never be released, as
development and releases will now all be done in the grass51 CVS module.
Only bugfixes should be committed to the release branch and if in doubt
about if something should be added, it should be discussed on the mailing
list.

After creating the release branch I will update the configure script there
so it uses the alternate build mechanism by default. Then we can prepare
the 5.4.0 release candidate for testing by the middle of this week.

Does this sound like a reasonable plan?

Paul

____________________
C. Michael Barton, Professor of Anthropology
School of Human, Cultural, and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

20

On Mon, 18 Oct 2004, Michael Barton wrote:

I think this is great but need to know what to do with a few updates to
tcltkgrass. I guess I'd call them bug fixes. I added in all the new default
compile command modules that have just been added to 5.4 yesterday, but was
waiting for an answer to my question about r.grow2 so I could add it also. I
can commit what I have tomorrow. But since I'm in Arizona, I fear that you
will have already made the switch. I can download a new cvs sandbox for 5.4
when I know the path if your prefer. What do you advise?

Hello Michael
I suggest you commit the changes to the CVS HEAD as normal now and they won't affect the 5.4.0 release. Then once they are tested perhaps they can be merged into the release branch and become part of 5.4.1.
Or if Markus doesn't mind delaying 5.4.0 further we could put them into it but there would have to be another release candidate and more testing.

If you want to check out the release branch, use
cvs -z3 co -r releasebranch_5_4 grass
Only minor bugfixes should go into the release branch now, then after 5.4.0
is released slightly bigger bugfixes can go in (I would include missing tcltkgrass modules in this), but new features should go to the CVS HEAD or (preferably) 5.7.

Paul