[GRASS5] Bug report 2 for GRASS 5.7

Here is the next series of bug reports for GRASS 5.7. Note that there seems to be a very serious error for d.vect.chart that could cause system problems. I didn't find any of these in the bug tracker.

Many thanks to Radim for responding rapidly on the last set I sent in.

Michael Barton
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671

++++++++++++++++++ start here +++++++++++++++++++++++++

d.vect.chart

This EDA utility is a great idea (I suggest adding star graphs), but something is very wrong. No graphs are drawn. After more than 5 minutes there was nothing but constant disk access. All other activities were slowed down enormously. I eventually lost 2 Gb disk space, was unable to stop the disk activity and had to reboot. I. regained most of the disk space, but still seem to have lost 180 Mb.

Bravely, I tried again with smaller file (12 records).

d.vect.chart map=temprank_SA field=1 ctype=pie columns=MP_TOOLS,UP_TOOLS,NEOL_TOOLS sizecol=LITHICS size=20 scale=1 ocolor=black

Again, I had no graphs after 5+ minutes, but was clearly using system resources. All other activities (including typing and using a mouse) were greatly slowed down.

This time I was prepared. I quit GRASS and X11. Then I checked the process viewer. d.vect.chart was still using 5-10% CPU capacity and 33% memory. I killed it (+/- gracefully). THEN, XDRIVER showing as using up to 100% CPU capacity, though no memory. XDRIVER wouldn't quit gracefully and I had to force quit it. Again lost 1.5 Gb disk space. Got it all back this time after a reboot. I assume that the disk space is getting tied up in memory swap, though I couldn't find any file created or modified during operation that matches this space (checked before reboot).

This seems like a very serious problem with a very nice addition to GRASS.

***************************************
db.select

The following command works fine in command line (though the example given in docs is incorrect), but does not work in autogenerated GUI

db.select driver=dbf sql='select * from temprank_SA where STRATUM="SA"' fs=|
Sorry <*> is not a valid option
Sorry <from> is not a valid option
Sorry <temprank_SA> is not a valid option
Sorry <where> is not a valid option
Sorry, <STRATUM> is not a valid parameter

*****************************************
g.rename

g.rename works for all map types in GRASS 5.3 and the documentation says it works for all types in GRASS 5.7. But when I tried to rename a vector, I got the following error:

g.rename vect=roads,roads57
WARNING: Vectors are not supported by g.rename

On Monday 05 April 2004 23:50, Michael Barton wrote:

d.vect.chart

This EDA utility is a great idea (I suggest adding star graphs), but
something is very wrong. No graphs are drawn. After more than 5 minutes
there was nothing but constant disk access. All other activities were
slowed down enormously. I eventually lost 2 Gb disk space, was unable
to stop the disk activity and had to reboot. I. regained most of the
disk space, but still seem to have lost 180 Mb.

Bravely, I tried again with smaller file (12 records).

d.vect.chart map=temprank_SA field=1 ctype=pie
columns=MP_TOOLS,UP_TOOLS,NEOL_TOOLS sizecol=LITHICS size=20 scale=1
ocolor=black

Again, I had no graphs after 5+ minutes, but was clearly using system
resources. All other activities (including typing and using a mouse)
were greatly slowed down.

This time I was prepared. I quit GRASS and X11. Then I checked the
process viewer. d.vect.chart was still using 5-10% CPU capacity and 33%
  memory. I killed it (+/- gracefully). THEN, XDRIVER showing as using
up to 100% CPU capacity, though no memory. XDRIVER wouldn't quit
gracefully and I had to force quit it. Again lost 1.5 Gb disk space.
Got it all back this time after a reboot. I assume that the disk space
is getting tied up in memory swap, though I couldn't find any file
created or modified during operation that matches this space (checked
before reboot).

This seems like a very serious problem with a very nice addition to
GRASS.

No idea, it takes 1m27.863s for 9784 points with 2 columns on my PC.
All my activity is mooving from d.* to qgis.

*****************************************
g.rename

g.rename works for all map types in GRASS 5.3 and the documentation
says it works for all types in GRASS 5.7. But when I tried to rename a
vector, I got the following error:

g.rename vect=roads,roads57
WARNING: Vectors are not supported by g.rename

Known, not yet done, g.copy+d.remove for now.
I can also append answer for your future report: "g.copy vect= is slow".
Yes, must be optimised, i.e. copy files if native and support copy
table by drivers.

Radim