[GRASS-dev] Some wxGUI tests on Windows

GRASS GRASS developer
1

Hi,

today I had occasion to test on a colleague's computer the
latest binary package.
Here a list of some issues I came across (tell me which should
become a ticket):

- Map canvas: zoom to RGB layer finishes in the 0..1 space
  (solution might be to zoom to one channel of the RGB set?)

- closing the message window which tells that the digitizer is
  unavailable kills the entire GUI

- r.shaded.relief doesn't show any error but the result is completely NULL.
  Perhaps due to the fact that it is a shell script? If so, I would suggest
  to add a Windows test and to bail out rather than continue unless it
   is substituted with the Python version (6.4.1?).

- i.group does not permit to select a subgroup (apparently the list isn't
   fetched from the group file). Adding it manually works.

- i.maxlik seems to be unable to read the signature file: ill-conditioned
  signatures for all classes. It *seems* to be an issue to read the encoding
  of the ASCII signature file. Any G_getl() which should be G_getl2()?
  If so, what's the purpose of still keeping G_getl()?

Markus

2

Markus wrote:

today I had occasion to test on a colleague's computer the
latest binary package.
Here a list of some issues I came across (tell me which
should become a ticket):

(we need more of this, thanks)

- Map canvas: zoom to RGB layer finishes in the 0..1 space
(solution might be to zoom to one channel of the RGB
set?)

is this the one fixed by Marin yesterday?

- closing the message window which tells that the digitizer
is unavailable kills the entire GUI

- r.shaded.relief doesn't show any error but the result is
completely NULL.
Perhaps due to the fact that it is a shell script?
If so, I would suggest
to add a Windows test and to bail out rather than
continue unless it is substituted with the Python version
(6.4.1?).

I will try to hijack a PC in the office at lunch to confirm.
AFAIK all shell scripts just worked. The only problematic
ones were the wrapper scripts in $GISBASE/etc/gui/scripts/
which had either (not sure which) PATH, PYTHONPATH, PATHEXT,
or post-parser-can't-find-it-anymore problems.

- i.group does not permit to select a subgroup (apparently
the list isn't fetched from the group file). Adding it
manually works.

- i.maxlik seems to be unable to read the signature file:
ill-conditioned signatures for all classes. It *seems* to
be an issue to read the encoding of the ASCII signature file.
Any G_getl() which should be G_getl2()?

grass65:

develbranch_6/lib/imagery$ grep G_getl *
ls_groups.c: while (G_getl(buf, sizeof(buf), ls)) {
ls_groups.c: while (G_getl(buf, sizeof(buf), ls)) {
points.c: while (G_getl(buf, sizeof buf, fd)) {
title.c: G_getl(title, n, fd);

develbranch_6/lib/imagery$ grep fgets *
group.c: while (fgets(buf, sizeof buf, fd)) {

so, yes.

If so, what's the purpose of still keeping G_getl()?

beware if def'n of buffer size of n or n-1 may differ, and
if return type is a little different (I think that's mainly
between fgets() and G_getl2(), but not sure)

Hamish

3

On Thu, Oct 1, 2009 at 8:16 PM, Hamish <hamish_b@yahoo.com> wrote:

Markus wrote:

today I had occasion to test on a colleague's computer the
latest binary package.
Here a list of some issues I came across (tell me which
should become a ticket):

(we need more of this, thanks)

We can do that but we aren't able to compile ourself currently...

- Map canvas: zoom to RGB layer finishes in the 0..1 space
(solution might be to zoom to one channel of the RGB
set?)

is this the one fixed by Marin yesterday?

No idea since I have to use the versions from Colin for the time
being.

- closing the message window which tells that the digitizer
is unavailable kills the entire GUI

... works for you?

- r.shaded.relief doesn't show any error but the result is
completely NULL.
Perhaps due to the fact that it is a shell script?
If so, I would suggest
to add a Windows test and to bail out rather than
continue unless it is substituted with the Python version
(6.4.1?).

Since all say that r.shaded.relief works it might be a problem
here. also using XP.

I will try to hijack a PC in the office at lunch to confirm.
AFAIK all shell scripts just worked. The only problematic
ones were the wrapper scripts in $GISBASE/etc/gui/scripts/
which had either (not sure which) PATH, PYTHONPATH, PATHEXT,
or post-parser-can't-find-it-anymore problems.

- i.group does not permit to select a subgroup (apparently
the list isn't fetched from the group file). Adding it
manually works.

... will open a ticket for this.

- i.maxlik seems to be unable to read the signature file:
ill-conditioned signatures for all classes. It *seems* to
be an issue to read the encoding of the ASCII signature file.
Any G_getl() which should be G_getl2()?

grass65:

develbranch_6/lib/imagery$ grep G_getl *
ls_groups.c: while (G_getl(buf, sizeof(buf), ls)) {
ls_groups.c: while (G_getl(buf, sizeof(buf), ls)) {
points.c: while (G_getl(buf, sizeof buf, fd)) {
title.c: G_getl(title, n, fd);

develbranch_6/lib/imagery$ grep fgets *
group.c: while (fgets(buf, sizeof buf, fd)) {

so, yes.

attached a diff. Makes sense?

If so, what's the purpose of still keeping G_getl()?

beware if def'n of buffer size of n or n-1 may differ, and
if return type is a little different (I think that's mainly
between fgets() and G_getl2(), but not sure)

ok.

Markus

(attachments)

libimg_group_c.diff (472 Bytes)

4

Hi,

2009/10/2 Markus Neteler <neteler@osgeo.org>:

On Thu, Oct 1, 2009 at 8:16 PM, Hamish <hamish_b@yahoo.com> wrote:

Markus wrote:

today I had occasion to test on a colleague's computer the
latest binary package.
Here a list of some issues I came across (tell me which
should become a ticket):

(we need more of this, thanks)

We can do that but we aren't able to compile ourself currently...

I am planning to set up OSGeo BuildBot [1] slave on our new servers -
at least to build binaries for Debian GNU/Linux and MS Windows. Hope
to do it in December, currently no time for that.

Martin

[1] http://wiki.osgeo.org/wiki/How_to_create_new_OSGeo_BuildBot_instance

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

5

Hi

Markus Neteler pisze:

- r.shaded.relief doesn't show any error but the result is completely NULL.
  Perhaps due to the fact that it is a shell script? If so, I would suggest
  to add a Windows test and to bail out rather than continue unless it
   is substituted with the Python version (6.4.1?).

Is there some objectives to replace r.shaded.relief with C code?. It looks like very easy task and I can do that when I have little more time.
Jarek

6

Jarek Jasiewicz wrote:

> - r.shaded.relief doesn't show any error but the result is completely NULL.
> Perhaps due to the fact that it is a shell script? If so, I would suggest
> to add a Windows test and to bail out rather than continue unless it
> is substituted with the Python version (6.4.1?).

Is there some objectives to replace r.shaded.relief with C code?.

What would be the point? The script is essentially a single r.mapcalc
expression.

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

7

Markus Neteler wrote:

No idea since I have to use the versions from Colin for the
time being.

>> - closing the message window which tells that the digitizer
>> is unavailable kills the entire GUI

... works for you?

Yes it does work for me (XP). Selecting the 3D view locks up the desktop
for about 20sec the first time I try it (0% cpu load, not sure what it's
doing, maybe doing a deep search on the disk for the module), but then
shows the pop up error message and goes on its way. Selecting the
digitizer pops up a feature unavail. message without any problem.

I notice that you don't see the message warning you that that stuff is not
there in the msys xterm window until after you exit the GUI. And then it
suggests that you need a newer version of GRASS to fix it, which is perhaps
overly-optimistic.

>> - r.shaded.relief doesn't show any error but the result is
>> completely NULL.

works for me.

>> - i.group does not permit to select a subgroup (apparently
>> the list isn't fetched from the group file). Adding it
>> manually works.

... will open a ticket for this.

>> - i.maxlik seems to be unable to read the signature file:
>> ill-conditioned signatures for all classes. It *seems* to
>> be an issue to read the encoding of the ASCII signature file.
>> Any G_getl() which should be G_getl2()?

...

> so, yes.

attached a diff. Makes sense?

Yes, applied to all branches. (please test)
I also did all the other G_getl()s in lib/imagery.

IIRC these had been low priority as we can assume that all those files
were written by the imagery library, which only uses fprintf(fp, "\n");.
The flaw in that assumption may come from if the GUIs are writing the
POINTS file etc. directly using some native writel tcl/python command,
or if the user had been going about it by hand in a text editor.
As such I'm not fully convinced this will be the cause + solution to the
problem, but at least will rule something obvious out.
Regardless, now the read is newline independent.

any update on bug #707?
  https://trac.osgeo.org/grass/ticket/707

Hamish

8

On Sat, Oct 3, 2009 at 6:59 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus Neteler wrote:

...

attached a diff. Makes sense?

Yes, applied to all branches. (please test)
I also did all the other G_getl()s in lib/imagery.

Anyone able to make a new winGRASS binary available
for me for testing?

...

any update on bug #707?
https://trac.osgeo.org/grass/ticket/707

arrgh, [wxGUI is not starting here since August]
but since it works for the others it should do so for me
as well. I have opened a bug report to figure out if a
security update of wxPython was done with a different
swig version.

Markus

9

Sorry was away and wasn't able to update for a while. A new version is
available now, though Helmut also created a binary just before me. I
think we'll start alternating so we can have more regular versions
coming out. Is every two weeks overkill or does that sound about
right?

Please test the new version with all the problems listed in this
thread and we'll see what is left to be fixed.

-Colin

On Sat, Oct 3, 2009 at 3:23 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Sat, Oct 3, 2009 at 6:59 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus Neteler wrote:

...

attached a diff. Makes sense?

Yes, applied to all branches. (please test)
I also did all the other G_getl()s in lib/imagery.

Anyone able to make a new winGRASS binary available
for me for testing?

...

any update on bug #707?
https://trac.osgeo.org/grass/ticket/707

arrgh, [wxGUI is not starting here since August]
but since it works for the others it should do so for me
as well. I have opened a bug report to figure out if a
security update of wxPython was done with a different
swig version.

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