[GRASS5] cvs updates completed successfully.

GRASS GIS GRASS GIS developer
1

I want to thank Glynn, Paul, and Hamish for their advice with the arcane world of the CVS.

I completed the updates I started a couple days ago (GIS Manager, and r.univar.sh and r.shaded.relief scripts) and restored Glynn’s prior updates to scripts I had modified. As all of you noted, I cannot remove the /scripts/r.univar directory. Bernard or someone else will have to do that. However, GRASS should build the r.univar.sh script correctly now.

Michael

Michael Barton, Professor & Curator
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

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike.
Thanks for your work. GRASS looks great now! I believe Leonardo wrote you
about the problems we encountered with zoom, pan etc. Were you able to fix
them?
All the best.
pc

At 20:27, venerdì 17 settembre 2004, Michael Barton has probably written:

I want to thank Glynn, Paul, and Hamish for their advice with the arcane
world of the CVS.

I completed the updates I started a couple days ago (GIS Manager, and
r.univar.sh and r.shaded.relief scripts) and restored Glynn¹s prior updates
to scripts I had modified. As all of you noted, I cannot remove the
/scripts/r.univar directory. Bernard or someone else will have to do that.
However, GRASS should build the r.univar.sh script correctly now.

Michael

______________________________
Michael Barton, Professor & Curator
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

- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
Only free software: www.gnu.org / www.linux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBSzUm/NedwLUzIr4RAkL+AKCdTPhEQ0cEWUMdGG4hybTvocYxUQCfdNTa
0HUGBhgW7INizvCqzg3tT0g=
=X9qJ
-----END PGP SIGNATURE-----

3

Michael Barton wrote:

I completed the updates I started a couple days ago (GIS Manager, and
r.univar.sh and r.shaded.relief scripts) and restored Glynn¹s prior updates
to scripts I had modified. As all of you noted, I cannot remove the
/scripts/r.univar directory. Bernard or someone else will have to do that.
However, GRASS should build the r.univar.sh script correctly now.

Nope. scripts/Makefile has r.univar in SUBDIRS, but that directory no
longer exists.

What exactly was the reason for renaming that directory?

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

4

This is strange. I looked at the Makefile via the web CVS yesterday and it
had r.univar.sh rather than r.univar listed. I was unable to update the
Makefile and I assumed that it was because it was already updated.

The reason for renaming it is that there is a binary module also named
r.univar. According to Markus, r.univar (binary) will eventually have all
the functionality (and more?) of r.univar.sh (script). However, it is still
under development so we are keeping the script for awhile.

Michael

On 9/17/04 6:33 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:

Michael Barton wrote:

I completed the updates I started a couple days ago (GIS Manager, and
r.univar.sh and r.shaded.relief scripts) and restored Glynn¹s prior updates
to scripts I had modified. As all of you noted, I cannot remove the
/scripts/r.univar directory. Bernard or someone else will have to do that.
However, GRASS should build the r.univar.sh script correctly now.

Nope. scripts/Makefile has r.univar in SUBDIRS, but that directory no
longer exists.

What exactly was the reason for renaming that directory?

____________________
C. Michael Barton, Professor
School of Human Diversity 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>

5

Paolo,

I've been in correspondence with Leonardo. I'm not sure why he (and you?)
are having problems. The first thing is to see if both commands work
correctly from the command line. Both should give you a response in the
GRASS xterminal. You must have a monitor *open* and *selected* and with a
*map displayed* in it for these to work correctly.

If you don't have a selected monitor with a map and run d.zoom (no
arguments) from the command line, it will send you to the d.zoom tcltk gui.
D.zoom -p will generate an error in this context.

If you are not getting this behavior, I wonder if you have a slightly
outdated version of GRASS 5.7. These menus only work properly with pretty
recent versions. I am running an August 31 build (Mac OSX). There have been
some improvements since then, of course, but the menus seem to work OK on
that build.

One thing I've noticed that is a bit odd. When I using files over a network,
d.zoom and d.pan may take a few seconds to open an xterm. Other times it
comes up quickly. Very subjectively, it almost seems that it takes a
slightly longer time to open the xterm the longer I work in a given session.
Don't know what is causing this delay.

Michael Barton

On 9/17/04 12:04 PM, "Paolo Cavallini" <cavallini@faunalia.it> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike.
Thanks for your work. GRASS looks great now! I believe Leonardo wrote you
about the problems we encountered with zoom, pan etc. Were you able to fix
them?
All the best.
pc

At 20:27, venerdì 17 settembre 2004, Michael Barton has probably written:

I want to thank Glynn, Paul, and Hamish for their advice with the arcane
world of the CVS.

I completed the updates I started a couple days ago (GIS Manager, and
r.univar.sh and r.shaded.relief scripts) and restored Glynn¹s prior updates
to scripts I had modified. As all of you noted, I cannot remove the
/scripts/r.univar directory. Bernard or someone else will have to do that.
However, GRASS should build the r.univar.sh script correctly now.

Michael

______________________________
Michael Barton, Professor & Curator
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

- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
GPG key @: hkp://wwwkeys.pgp.net Info on the Replicated WWW Based PGP 5.0 Key Server System
https://www.biglumber.com
Only free software: www.gnu.org / www.linux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBSzUm/NedwLUzIr4RAkL+AKCdTPhEQ0cEWUMdGG4hybTvocYxUQCfdNTa
0HUGBhgW7INizvCqzg3tT0g=
=X9qJ
-----END PGP SIGNATURE-----

____________________
C. Michael Barton, Professor
School of Human Diversity 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>

6

Michael Barton wrote:

This is strange. I looked at the Makefile via the web CVS yesterday and it
had r.univar.sh rather than r.univar listed. I was unable to update the
Makefile and I assumed that it was because it was already updated.

I'm referring to scripts/Makefile, not scripts/r.univar.sh/Makefile.

The reason for renaming it is that there is a binary module also named
r.univar. According to Markus, r.univar (binary) will eventually have all
the functionality (and more?) of r.univar.sh (script). However, it is still
under development so we are keeping the script for awhile.

I was asking why you renamed the directory; I know why you renamed the
script.

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

7

On 9/18/04 2:43 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:

I'm referring to scripts/Makefile, not scripts/r.univar.sh/Makefile.

I was too. That's what's strange. I did look yesterday morning. In fact
Hamish updated this Makefile a few days ago to have r.univar.sh. So I am
baffled as to why it is now showing r.univar (with Hamish still listed as
updating it).

The reason for renaming it is that there is a binary module also named
r.univar. According to Markus, r.univar (binary) will eventually have all
the functionality (and more?) of r.univar.sh (script). However, it is still
under development so we are keeping the script for awhile.

I was asking why you renamed the directory; I know why you renamed the
script.

I renamed the directory because I thought it ought to match the script.

If it is better to do it another way, please do so.

Michael

____________________
C. Michael Barton, Professor
School of Human Diversity 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>

8

Michael Barton wrote:

> I'm referring to scripts/Makefile, not scripts/r.univar.sh/Makefile.

I was too. That's what's strange. I did look yesterday morning. In fact
Hamish updated this Makefile a few days ago to have r.univar.sh. So I am
baffled as to why it is now showing r.univar (with Hamish still listed as
updating it).

The log entry for that commit says:

  revision 1.26
  date: 2004/09/16 03:16:44; author: hamish; state: Exp; lines: +1 -0
  re-enable (renamed) r.univar.sh

However, the actual change was:

  $ cvs diff -r 1.25 -r 1.26 scripts/Makefile
  Index: scripts/Makefile
  ===================================================================
  RCS file: /grassrepository/grass51/scripts/Makefile,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- scripts/Makefile 22 Jul 2004 05:46:51 -0000 1.25
  +++ scripts/Makefile 16 Sep 2004 03:16:44 -0000 1.26
  @@ -31,6 +31,7 @@
     r.reclass.area \
     r.regression.line \
     r.shaded.relief \
  + r.univar \
     v.build.all
   
   default: subdirs

>> The reason for renaming it is that there is a binary module also named
>> r.univar. According to Markus, r.univar (binary) will eventually have all
>> the functionality (and more?) of r.univar.sh (script). However, it is still
>> under development so we are keeping the script for awhile.
>
> I was asking why you renamed the directory; I know why you renamed the
> script.

I renamed the directory because I thought it ought to match the script.

If it is better to do it another way, please do so.

It would have been better to have kept the original directory, as that
would have preserved the history.

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

9

> I'm referring to scripts/Makefile, not scripts/r.univar.sh/Makefile.

I was too. That's what's strange. I did look yesterday morning. In
fact Hamish updated this Makefile a few days ago to have r.univar.sh.
So I am baffled as to why it is now showing r.univar (with Hamish
still listed as updating it).

Ok, we have:

grass51/scripts/r.univar/ (now empty)
grass51/scripts/r.univar.sh/ (now populated)

grass51/scripts/Makefile (which script directories to look into)

the Makefile [generally] works on stuff at the same directory level.
i.e. the names listed in "grass51/scripts/Makefile" refer to the
directories that 'make' should descend into, where it will look for new
Makefiles. It does not have anything to do with the final name of the
module besides being convenient. Thus a generic name (like r.univar/) was
fine for the directory name as it gets the idea across with the minimum
unnecessary yet unambiguous information. ie it didn't really matter as long
as the directory structure and scritps/Makefile agreed.

The final name for the module is defined in the Makefile that is in the
source code directory (grass51/scripts/r.univar.sh/Makefile; "PGM = x.foo").
For scripts "make"ing just means copying to $GISBASE/scripts/, so the script
name does have to be correct there. For C code, all you have to do is rename
PGM in the module/Makefile file to rename the module.

The problem with renaming & moving directories in CVS is that you lose
the modification history. It still exists in the Attic/ (why you shouldn't
delete old directories) but is rather confusing to follow the history that
way. Thus it is better to try and avoid renaming files and the directory
structures if at all possible. Limitation of CVS, but somewhat logical I
guess from the perspective of keeping the change history intact.

>> The reason for renaming it is that there is a binary module also
>> named r.univar. According to Markus, r.univar (binary) will
>> eventually have all the functionality (and more?) of r.univar.sh
>> (script). However, it is still under development so we are keeping
>> the script for awhile.
>
> I was asking why you renamed the directory; I know why you renamed
> the script.

I renamed the directory because I thought it ought to match the
script.

as above, that isn't required and should be avoided unless there is a
compelling reason.

If it is better to do it another way, please do so.

I've just modified grass51/scripts/Makefile to reflect the new directory
name. Everything should be working now, no further changes required.

Hamish

10

Thanks both for explaining this and for finishing this last important
detail.

Michael

On 9/18/04 7:23 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

I'm referring to scripts/Makefile, not scripts/r.univar.sh/Makefile.

I was too. That's what's strange. I did look yesterday morning. In
fact Hamish updated this Makefile a few days ago to have r.univar.sh.
So I am baffled as to why it is now showing r.univar (with Hamish
still listed as updating it).

Ok, we have:

grass51/scripts/r.univar/ (now empty)
grass51/scripts/r.univar.sh/ (now populated)

grass51/scripts/Makefile (which script directories to look into)

the Makefile [generally] works on stuff at the same directory level.
i.e. the names listed in "grass51/scripts/Makefile" refer to the
directories that 'make' should descend into, where it will look for new
Makefiles. It does not have anything to do with the final name of the
module besides being convenient. Thus a generic name (like r.univar/) was
fine for the directory name as it gets the idea across with the minimum
unnecessary yet unambiguous information. ie it didn't really matter as long
as the directory structure and scritps/Makefile agreed.

The final name for the module is defined in the Makefile that is in the
source code directory (grass51/scripts/r.univar.sh/Makefile; "PGM = x.foo").
For scripts "make"ing just means copying to $GISBASE/scripts/, so the script
name does have to be correct there. For C code, all you have to do is rename
PGM in the module/Makefile file to rename the module.

The problem with renaming & moving directories in CVS is that you lose
the modification history. It still exists in the Attic/ (why you shouldn't
delete old directories) but is rather confusing to follow the history that
way. Thus it is better to try and avoid renaming files and the directory
structures if at all possible. Limitation of CVS, but somewhat logical I
guess from the perspective of keeping the change history intact.

The reason for renaming it is that there is a binary module also
named r.univar. According to Markus, r.univar (binary) will
eventually have all the functionality (and more?) of r.univar.sh
(script). However, it is still under development so we are keeping
the script for awhile.

I was asking why you renamed the directory; I know why you renamed
the script.

I renamed the directory because I thought it ought to match the
script.

as above, that isn't required and should be avoided unless there is a
compelling reason.

If it is better to do it another way, please do so.

I've just modified grass51/scripts/Makefile to reflect the new directory
name. Everything should be working now, no further changes required.

Hamish

____________________
C. Michael Barton, Professor
School of Human Diversity 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>