[GRASS-dev] [GRASS-SVN] r53518 - grass/trunk/lib/temporal/lib

GRASS GIS GRASS GIS developer
1

Hi,

2012/10/21 <svn_grass@osgeo.org>:

Author: neteler
Date: 2012-10-20 23:39:16 -0700 (Sat, 20 Oct 2012)
New Revision: 53518

Modified:
   grass/trunk/lib/temporal/lib/default_name.c
Log:
fix debug level

[...]

- G_debug(1,
+ G_debug(0,
            "Creating new default TGIS DB params with tgis_set_default_connection()");

debug level 0 seems to be illegal. Either use debug '1' or change
G_debug() to G_message().

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

2

On Sun, Oct 21, 2012 at 3:56 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/10/21 <svn_grass@osgeo.org>:

Author: neteler
Date: 2012-10-20 23:39:16 -0700 (Sat, 20 Oct 2012)
New Revision: 53518

Modified:
   grass/trunk/lib/temporal/lib/default_name.c
Log:
fix debug level

[...]

- G_debug(1,
+ G_debug(0,
            "Creating new default TGIS DB params with tgis_set_default_connection()");

debug level 0 seems to be illegal.

Why this?

Either use debug '1' or change G_debug() to G_message().

Then G_debug() doesn't make much sense to me.

Also

[neteler@north grass64]$ grep 'G_debug(0' */*/*.c
vector/v.perturb/myrng.c: G_debug(0,"%g",numbers[i]);
[neteler@north grass64]$ grep 'G_debug(0' */*/*/*.c
lib/vector/Vlib/dgraph.c: G_debug(0, "exact=%d orig=%d",
res, res2);
vector/lidar/v.lidar.growing/ConvexHull.c: G_debug(0, "run-time error...");
vector/lidar/v.lidar.growing/ConvexHull.c: G_debug(0, "%s", error_text);
vector/v.lrs/v.lrs.label/main.c: G_debug(0, " line = %d / %d",
line, nlines);
vector/v.lrs/v.lrs.label/main.c: G_debug(0, " %d reference
segments selected", nrseg);

[neteler@north grass70]$ grep 'G_debug(0' */*/*.c
display/d.vect/label.c: G_debug(0, "ncentroids (ogr) = %d", nlines);
lib/gis/token.c: G_debug(0, "%d=[%s]", i, tokens[i]);
raster3d/r3.in.ascii/main.c: G_debug(0,
"invalid value at col=%d row=%d depth=%d last_value=[%s]",
vector/v.lidar.growing/ConvexHull.c: G_debug(0, "run-time error...");
vector/v.lidar.growing/ConvexHull.c: G_debug(0, "%s", error_text);
vector/v.perturb/myrng.c: G_debug(0,"%g",numbers[i]);

It is not usual at least...

Markus

3

Hi,

2012/10/21 Markus Neteler <neteler@osgeo.org>:

debug level 0 seems to be illegal.

Why this?

then this debug message will be printed *always*. In the manual we
claim that `g.gisenv set=DEBUG=0` turn of all debug messages.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

4

Hi,

2012/10/21 Markus Neteler <neteler@osgeo.org>:

Either use debug '1' or change G_debug() to G_message().

Then G_debug() doesn't make much sense to me.

why, we use different debug levels, 1-5.

[neteler@north grass64]$ grep 'G_debug(0' */*/*.c
vector/v.perturb/myrng.c: G_debug(0,"%g",numbers[i]);
[neteler@north grass64]$ grep 'G_debug(0' */*/*/*.c
lib/vector/Vlib/dgraph.c: G_debug(0, "exact=%d orig=%d",
res, res2);
vector/lidar/v.lidar.growing/ConvexHull.c: G_debug(0, "run-time error...");
vector/lidar/v.lidar.growing/ConvexHull.c: G_debug(0, "%s", error_text);
vector/v.lrs/v.lrs.label/main.c: G_debug(0, " line = %d / %d",
line, nlines);
vector/v.lrs/v.lrs.label/main.c: G_debug(0, " %d reference
segments selected", nrseg);

[neteler@north grass70]$ grep 'G_debug(0' */*/*.c
display/d.vect/label.c: G_debug(0, "ncentroids (ogr) = %d", nlines);
lib/gis/token.c: G_debug(0, "%d=[%s]", i, tokens[i]);
raster3d/r3.in.ascii/main.c: G_debug(0,
"invalid value at col=%d row=%d depth=%d last_value=[%s]",
vector/v.lidar.growing/ConvexHull.c: G_debug(0, "run-time error...");
vector/v.lidar.growing/ConvexHull.c: G_debug(0, "%s", error_text);
vector/v.perturb/myrng.c: G_debug(0,"%g",numbers[i]);

seems to be bogus for me. Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

5

On Sun, Oct 21, 2012 at 6:17 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/10/21 Markus Neteler <neteler@osgeo.org>:

debug level 0 seems to be illegal.

Why this?

then this debug message will be printed *always*.

That looks like a bug in this case.

In the manual we
claim that `g.gisenv set=DEBUG=0` turn of all debug messages.

Yes, so I would expect G_debug(0, ...) to behave like this.

Markus

6

2012/10/21 Markus Neteler <neteler@osgeo.org>:

debug level 0 seems to be illegal.

Why this?

then this debug message will be printed *always*.

That looks like a bug in this case.

well, `g.gisenv set=DEBUG=-1` will work. But AFAIR we used `DEBUG=0`
to turn off all debug messages. So first legal level should be 1.

In the manual we
claim that `g.gisenv set=DEBUG=0` turn of all debug messages.

Yes, so I would expect G_debug(0, ...) to behave like this.

DEBUG=0 defines first printed debug level. So DEBUG=0 indicates that
all debug messages with level >= 0 will be printed out.

I think that `G_debug(0, ...)` should be changed to `G_debug(1, ...)`
in the code.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

7

On Sun, Oct 21, 2012 at 6:27 PM, Martin Landa <landa.martin@gmail.com> wrote:

2012/10/21 Markus Neteler <neteler@osgeo.org>:

debug level 0 seems to be illegal.

Why this?

then this debug message will be printed *always*.

That looks like a bug in this case.

well, `g.gisenv set=DEBUG=-1` will work. But AFAIR we used `DEBUG=0`
to turn off all debug messages. So first legal level should be 1.

In the manual we
claim that `g.gisenv set=DEBUG=0` turn of all debug messages.

Yes, so I would expect G_debug(0, ...) to behave like this.

DEBUG=0 defines first printed debug level. So DEBUG=0 indicates that
all debug messages with level >= 0 will be printed out.

I think that `G_debug(0, ...)` should be changed to `G_debug(1, ...)`
in the code.

Martin

btw, this change of the debug level is not related do the message
(Michael was asking about):

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

this is G_important_message and comes from
lib/temporal/t.connect/main.c. As I understand it, you get it only for
the first time when the temporal database is created so it should stay
there.

Anna

8

On Sun, Oct 21, 2012 at 6:42 PM, Anna Kratochvílová
<kratochanna@gmail.com> wrote:

btw, this change of the debug level is not related do the message
(Michael was asking about):

Yes, I have realized that today...

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

this is G_important_message and comes from
lib/temporal/t.connect/main.c. As I understand it, you get it only for
the first time when the temporal database is created so it should stay
there.

Honestly I am not sure: When creating a new mapset, nothing is
printed (like that a SQLite DB is created for the attributes or the
search path initialized etc).

Markus

9

Hi,

2012/10/21 Anna Kratochvílová <kratochanna@gmail.com>:

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

this is G_important_message and comes from
lib/temporal/t.connect/main.c. As I understand it, you get it only for
the first time when the temporal database is created so it should stay
there.

probably it should be done when user runs any t.* for the first time.
Otherwise it's not necessary and for some users can be confusing.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

10

On Sun, Oct 21, 2012 at 6:49 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/10/21 Anna Kratochvílová <kratochanna@gmail.com>:

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

this is G_important_message and comes from
lib/temporal/t.connect/main.c. As I understand it, you get it only for
the first time when the temporal database is created so it should stay
there.

probably it should be done when user runs any t.* for the first time.

I think, this is the implemented behaviour, maybe Soeren can explain it better.

Anna

Otherwise it's not necessary and for some users can be confusing.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

11

On 21 October 2012 18:59, Anna Kratochvílová <kratochanna@gmail.com> wrote:

On Sun, Oct 21, 2012 at 6:49 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/10/21 Anna Kratochvílová <kratochanna@gmail.com>:

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

this is G_important_message and comes from
lib/temporal/t.connect/main.c. As I understand it, you get it only for
the first time when the temporal database is created so it should stay
there.

probably it should be done when user runs any t.* for the first time.

I think, this is the implemented behaviour, maybe Soeren can explain it better.

I thought this too but I just got the "Create temporal database"
message when I was _not_ using any temporal module. (Unfortunately,
I'm not sure what I was doing, maybe just starting grass, gui, ...?)

Anna

Otherwise it's not necessary and for some users can be confusing.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

12

On Sun, Oct 21, 2012 at 6:14 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Oct 21, 2012 at 3:56 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/10/21 <svn_grass@osgeo.org>:

Author: neteler
Date: 2012-10-20 23:39:16 -0700 (Sat, 20 Oct 2012)
New Revision: 53518

Modified:
   grass/trunk/lib/temporal/lib/default_name.c
Log:
fix debug level

[...]

- G_debug(1,
+ G_debug(0,
            "Creating new default TGIS DB params with tgis_set_default_connection()");

debug level 0 seems to be illegal.

Why this?

Either use debug '1' or change G_debug() to G_message().

Then G_debug() doesn't make much sense to me.

Also

[neteler@north grass64]$ grep 'G_debug(0' */*/*.c
vector/v.perturb/myrng.c: G_debug(0,"%g",numbers[i]);
[neteler@north grass64]$ grep 'G_debug(0' */*/*/*.c
lib/vector/Vlib/dgraph.c: G_debug(0, "exact=%d orig=%d",
res, res2);
vector/lidar/v.lidar.growing/ConvexHull.c: G_debug(0, "run-time error...");
vector/lidar/v.lidar.growing/ConvexHull.c: G_debug(0, "%s", error_text);
vector/v.lrs/v.lrs.label/main.c: G_debug(0, " line = %d / %d",
line, nlines);
vector/v.lrs/v.lrs.label/main.c: G_debug(0, " %d reference
segments selected", nrseg);

[neteler@north grass70]$ grep 'G_debug(0' */*/*.c
display/d.vect/label.c: G_debug(0, "ncentroids (ogr) = %d", nlines);
lib/gis/token.c: G_debug(0, "%d=[%s]", i, tokens[i]);
raster3d/r3.in.ascii/main.c: G_debug(0,
"invalid value at col=%d row=%d depth=%d last_value=[%s]",
vector/v.lidar.growing/ConvexHull.c: G_debug(0, "run-time error...");
vector/v.lidar.growing/ConvexHull.c: G_debug(0, "%s", error_text);
vector/v.perturb/myrng.c: G_debug(0,"%g",numbers[i]);

All those G_debug(0, ...) instances are most probably leftovers from
development of the respective modules/libraries. At least I use
sometimes G_debug(0, ...) during development for debugging of
particular components because these are always printed. If everything
works fine, I change the debug level to something > 0. G_debug(0, ...)
does not belong into svn, but is a useful feature during development
with your local copy.

my 2c

Markus M

13

Hi all,
the temporal database creation message will be printed every time the
database needs to be created when a temporal GIS related module call's
tgis.init(). The default behavior is that the database is created in
PERMANENT/tgis.db which is then used by every mapset that will be
created.

The Python method tgis.init() checks if the temporal database was
created properly and simply returns if that is the case, otherwise it
will be created using several large SQL scripts (so it takes some
seconds). The check must be performed by every t.* module and the GUI
part to list space time datasets, because the temporal GIS backend
(sqlite3 or postgresql) and the path/connection details can be changed
at run time for every mapset separately.

By default this message will appear only once.

In case no t.* module was called first this message will appear when
the GUI is opened for the first time in a new location or when the
tgis database connection/backend was changed, since the "GUI" calls
tgis.init() (Tree widget to list raster, vector and space time
datasets) to be able to list space time datasets.

Sorry for confusion, should i disable the message?

Should i move the temporal database creation in the grass7 start part?

Best regards
Soeren

2012/10/21 Anna Kratochvílová <kratochanna@gmail.com>:

On Sun, Oct 21, 2012 at 6:49 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/10/21 Anna Kratochvílová <kratochanna@gmail.com>:

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

this is G_important_message and comes from
lib/temporal/t.connect/main.c. As I understand it, you get it only for
the first time when the temporal database is created so it should stay
there.

probably it should be done when user runs any t.* for the first time.

I think, this is the implemented behaviour, maybe Soeren can explain it better.

Anna

Otherwise it's not necessary and for some users can be confusing.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

14

Sorry for confusion, should i disable the message?

I consider it as confusing (for user) only when starting GUI. When
using t.* module I would expect some t-related messages.

15

Hi,

2012/10/21 Markus Metz <markus.metz.giswork@gmail.com>:

All those G_debug(0, ...) instances are most probably leftovers from
development of the respective modules/libraries. At least I use
sometimes G_debug(0, ...) during development for debugging of
particular components because these are always printed. If everything
works fine, I change the debug level to something > 0. G_debug(0, ...)
does not belong into svn, but is a useful feature during development
with your local copy.

probably adding warning message to G_debug() would be meaningful(?) Eg.

Index: lib/gis/debug.c

--- lib/gis/debug.c (revision 53519)
+++ lib/gis/debug.c (working copy)
@@ -71,6 +71,10 @@
     G_init_debug();

     if (grass_debug_level >= level) {
+ if (level < 1 || level > 5)
+ G_warning(_("Invalid debug level %d. Recommended levels are 1-5."),
+ level);
+
        va_start(ap, msg);

        filen = getenv("GRASS_DEBUG_FILE");

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

16

On Sun, Oct 21, 2012 at 8:03 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Sorry for confusion, should i disable the message?

I consider it as confusing (for user) only when starting GUI. When
using t.* module I would expect some t-related messages.

I moved the init function so that it is called only for gui forms with
temporal element types (r53520).

Anna

17

Hi,

2012/10/21 Anna Kratochvílová <kratochanna@gmail.com>:

I consider it as confusing (for user) only when starting GUI. When
using t.* module I would expect some t-related messages.

I moved the init function so that it is called only for gui forms with
temporal element types (r53520).

thanks. Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

18

On Sun, Oct 21, 2012 at 8:10 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/10/21 Markus Metz <markus.metz.giswork@gmail.com>:

All those G_debug(0, ...) instances are most probably leftovers from
development of the respective modules/libraries. At least I use
sometimes G_debug(0, ...) during development for debugging of
particular components because these are always printed. If everything
works fine, I change the debug level to something > 0. G_debug(0, ...)
does not belong into svn, but is a useful feature during development
with your local copy.

probably adding warning message to G_debug() would be meaningful(?) Eg.

Index: lib/gis/debug.c

--- lib/gis/debug.c (revision 53519)
+++ lib/gis/debug.c (working copy)
@@ -71,6 +71,10 @@
     G_init_debug();

     if (grass_debug_level >= level) {
+ if (level < 1 || level > 5)
+ G_warning(_("Invalid debug level %d. Recommended levels are 1-5."),
+ level);
+
        va_start(ap, msg);

        filen = getenv("GRASS_DEBUG_FILE");

I don't see a reason for this, it's IMHO neither a bugfix nor an
enhancement. G_debug(0, ...) messages will be printed nevertheless,
which is a good thing because (at least for me) it helps debugging new
code before submission. When the new code is tested and ready for
submission, G_debug(0, ...) must be changed by the developer to some
higher level before submission. This is easy enough to catch and fix.

my2c

Markus M