[GRASS-dev] G_percent() usage; freeze; backport "Fix bug in G_is_c_null_value()"?

re r34762, etc.

G_percent() should stay at the start of the for loop. If the loop takes
a long time to run, 0% should print before the first iteration has begun,
and final 99/100% message in loop should not be printed before the last
iteration is complete. Otherwise it seems to stall at 99% done, etc.

and in general, IMO we should try start to freeze devbr6 for all but
bugfixes now, with or without releasebranch_6_4 being cut yet.
Otherwise we never finish.. In my mind the things to complete before
6.4.0rc1 were to finalize the module list and freeze the library API,
and we are ready to do that.

Other projects declare a (non buggy) message freeze as well, to let
the translation teams catch up before release. Do we want to do that
as well? Wait until last rc or 2 before final release for that??

Glynn: is r34747 "Fix bug in G_is_c_null_value()" to be backported?

thanks,
Hamish

Hi,

2008/12/7 Hamish <hamish_b@yahoo.com>:

re r34762, etc.

G_percent() should stay at the start of the for loop. If the loop takes
a long time to run, 0% should print before the first iteration has begun,
and final 99/100% message in loop should not be printed before the last
iteration is complete. Otherwise it seems to stall at 99% done, etc.

sorry, I got impression that G_percent should stay in the end of the
loop. G_percent() doxygen string updated (r34774).

Martin

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

Hamish wrote:

Glynn: is r34747 "Fix bug in G_is_c_null_value()" to be backported?

No; the change which introduced the bug (r34445) wasn't backported.

However, I suggest syncing G_is_c_null_value() (and possibly other
parts of null_val.c) to 7.0.

Doing this with "svn merge" isn't practical as some of the changes
were part of large-scale clean-ups (r34445, r34484).

The original code is over-complex as a result of trying to handle
arbitrary sizes for CELL, FCELL and DCELL. But I suspect that a lot
more than just null handling would break if those types weren't 4, 4
and 8 bytes respectively.

If you want to sync the whole file, you'll also need to sync the
prototypes in gisdefs.h, as some gratuitous "int" returns were changed
to "void". I don't think that anything actually checked the return
types, so it shouldn't be necessary to change anything else (unlike
e.g. G_get_window(), where many modules checked the return value even
though it would always be 1).

--
Glynn Clements <glynn@gclements.plus.com>