[GRASS5] Bugtracker usage.

Just took a look at the bug-tracker for GRASS running at:
  http://intevation.de/rt/webrt/?q_queue=grass

It looks like we should utilise it a little bit more.

All developers with cvs write access should have access to the
bugtracker. Mail me if you do not know how to log in there.

To all developers: Please check if bugs are already cleared out
or try to get back to the person reporting the bugs for more details
if we cannot resolve it?

Help us to keep the bug-tracker clean and useful.
  + If you have more information on a bug make sure that it is
    inserted in the bug-tracker.

  + If you plan to fix the bug or it is in your responsibility,
  please "take" the bug.

Yesterday I killed a couple of these nasty spams for a start.

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (www.fsfeurope.org)

Bernhard

you are right - I looked at the bug tracker and it needs some serious
clean-up. I tried to go through it and sort it a little bit out -
here is what I managed to find out:

(I don't have permissions for doing modifications in the bug reports
(and I probably should not have as I am not a programmer) and I don't
want to bother Markus with this - so maybe you or somebody else who
has a permission can double check what I have found and remove/close
those bugs that are fixed or are not bugs.

Some bugs do not seem to be bugs, just people not having things
properly installed - those should be removed - e.g

755,753, 219, 199

this seems to be feature rather than bug
270

some are related to pretty old versions of GRASS and/or appear to be fixed
(I cannot tell as they are out of my range of expertise
269 (5beta1?), 261, 195

this seems to be fixed
252, 230 (it works for me in pre1), 112, 108

I contacted the user that reported r.slope.aspect bug (756)
that I may possibly fix to get some more info (I don't have the problem
that he reports)

On a separate issue - as we are getting up and running GRASS here
I found that people are dowloading all kinds of versions
of GRASS thinking that they have the latest one:
e.g. dowload cvs (march2001?) and then update (probably incorrectly) so
e.g. nviz script did not get updated
or downloading beta11 (is it still there?)
It would be good to minimize the versions that are out there or make
it more prone to people installing old versions and/or not updating
properly.
Maybe keep just weekly CVS snapshot so that the CVS version is never
older than the latest release?

It appears clear to me that I should get 5.0.0.pre1 or cvs snapshot
but somehow not everybody is doing that.

thanks,

Helena

Bernhard Reiter wrote:

Just took a look at the bug-tracker for GRASS running at:
        http://intevation.de/rt/webrt/?q_queue=grass

It looks like we should utilise it a little bit more.

All developers with cvs write access should have access to the
bugtracker. Mail me if you do not know how to log in there.

To all developers: Please check if bugs are already cleared out
or try to get back to the person reporting the bugs for more details
if we cannot resolve it?

Help us to keep the bug-tracker clean and useful.
        + If you have more information on a bug make sure that it is
                inserted in the bug-tracker.

        + If you plan to fix the bug or it is in your responsibility,
        please "take" the bug.

Yesterday I killed a couple of these nasty spams for a start.

        Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (www.fsfeurope.org)

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature

On Fri, Jul 27, 2001 at 07:32:36PM -0500, Helena wrote:

It appears clear to me that I should get 5.0.0.pre1 or cvs snapshot
but somehow not everybody is doing that.

The 5.0.0pre1 is getting pretty old. We should be using a cvs snapshot
of the tagged "april..." release. Markus asked about releasing the cvs
version as 5.0 "final" and everybody seemed to concur. So, I guess
we'll be waiting for Markus to get transitioned.

Bernhard Reiter wrote:

> Just took a look at the bug-tracker for GRASS running at:
> http://intevation.de/rt/webrt/?q_queue=grass
>
> It looks like we should utilise it a little bit more.

I must admit, I don't look at it very often. It's a great set up, but I
tend to forget about it for long periods...

--
Eric G. Miller <egm2@jps.net>

Helena wrote:

Bernhard

you are right - I looked at the bug tracker and it needs some serious
clean-up. I tried to go through it and sort it a little bit out -
here is what I managed to find out:

(I don't have permissions for doing modifications in the bug reports
(and I probably should not have as I am not a programmer) and I don't
want to bother Markus with this - so maybe you or somebody else who
has a permission can double check what I have found and remove/close
those bugs that are fixed or are not bugs.

Some bugs do not seem to be bugs, just people not having things
properly installed - those should be removed - e.g

755,753, 219, 199

#199 Nviz2.2 segmentation violation
#219 nviz2.2: BUG IN DYNAMIC LINKER
#753 tcltkgrass menu system says xterm not found with Xfree 4.0
#755 help (again)

OK; I've marked these as resolved.

this seems to be feature rather than bug
270

OK; marked as resolved.

some are related to pretty old versions of GRASS and/or appear to be fixed
(I cannot tell as they are out of my range of expertise
269 (5beta1?), 261, 195

#269 Grass5 and NFS

I think that this is still present. Eric commented on this.

In looking into this, I noticed that src/libes/raster/io.c will create
the directory with mode 777 if it doesn't exist (it should be 1777).
I've committed a fix for this particular issue.

Fixing the NFS issue is a bit more involved; if this is done as per
Eric's suggestion, the monitor socket (and possibly FIFOs) should also
be moved to below e.g. $HOME/.grass5. That would also make debugging
monitors easier.

#261 GRASS_PAGER: todo list

This is sort of done. The libraries still have hardcoded references to
"more"; allowing the user to override this is potentially problematic,
as programs which call library functions might not be expecting those
functions to invoke a curses program (i.e. less) which could mess up
the terminal.

This is classified as a "wish", so I've left it.

#195 r.mapcalc: not present on Max OSX binaries

Can someone check the MacOSX binary distribution?

If r.mapcalc is absent, my guess is that the build system didn't have
lex and yacc on it (a few other programs would also fail to be built,
but r.mapcalc would be the most noticeable).

this seems to be fixed
252, 230 (it works for me in pre1), 112, 108

#252 r.to.sites: -z does not output third dimension

I'm wondering if the submitter misunderstood (e.g. thought that
r.to.sites would magically obtain the elevation from somewhere).
I can't see a problem either, so marked as resolved.

#230 Seg fault in r.report

The submitter reports that b11 (2001/02) worked, but the 2001/03/26
snapshot didn't. But "cvs log" indicates that r.report didn't change
between those dates. Marked as resolved.

#112 Empty /usr/local/bin/grass5 file

This is currently taken by jhickey; I'll leave it for him to choose
whether to close it.

The "thread" goes on to discuss the Solaris-gcc-varargs issue.

I sent an updated configure.in to Markus for testing, but as he's
offline at the moment, I'm just going to commit it and wait for
complaints.

Basically, the new version only looks for headers and libraries in the
places that the compiler/linker looks by default, unless you
explicitly specify additional directories via configure arguments.

#108 s.geom : where is it?

Removed due to non-GPL status. Markus' comments suggest it is
superseded by s.delaunay and s.voronoi, so marked as resolved.

I contacted the user that reported r.slope.aspect bug (756)
that I may possibly fix to get some more info (I don't have the problem
that he reports)

On a separate issue - as we are getting up and running GRASS here
I found that people are dowloading all kinds of versions
of GRASS thinking that they have the latest one:
e.g. dowload cvs (march2001?) and then update (probably incorrectly) so
e.g. nviz script did not get updated
or downloading beta11 (is it still there?)
It would be good to minimize the versions that are out there or make
it more prone to people installing old versions and/or not updating
properly.
Maybe keep just weekly CVS snapshot so that the CVS version is never
older than the latest release?

It appears clear to me that I should get 5.0.0.pre1 or cvs snapshot
but somehow not everybody is doing that.

Once 5.0.0 is released, we might wish to discourage the use of CVS (or
snapshots thereof) by people who don't know how to submit usable bug
reports (test cases, backtraces, etc) and aren't planning on keeping
up-to-date with development.

It's not (too much of) a problem to make the effort to track down bugs
in a single, commonly used version, nor to investigate reliable
reports in an arbitrary version. But trying to locate bugs which might
not even exist in a version that may no longer be relevant probably
isn't worth the effort.

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

Helena,

thanks for starting the cleaning up.

You actually have a login and permission to change the bugs' status
and add comments. So if you have comments to single bugs you could
also add them to the bug database using the web interface or mail. :slight_smile:

And if you feel that some bugs need to be closed,
just add the reason and do it.

If we ask a user for more feedback and wait a certain amount of
time witout getting the necessary details to recreate the bug we
should close the bug giving this reason.

We should make sure that each bug reporter is informed when the bug
status changes. If there is a valid email address for the requestor,
this is done automatically by the bug-tracker.

  Bernhard

On Fri, Jul 27, 2001 at 07:32:36PM -0500, Helena wrote:

you are right - I looked at the bug tracker and it needs some serious
clean-up. I tried to go through it and sort it a little bit out -
here is what I managed to find out:

(I don't have permissions for doing modifications in the bug reports
(and I probably should not have as I am not a programmer)

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

I am meeting with collegues from comp. science at Duke who have developed
some great open source
tools for GIS. It is in C++. I would greatly appreciate any feedback that
you could give me about
the use of C++ for GRASS modules/libraries, in particular - has anybody
done it or doing it?
Is it desirable or should all the code be in C to minimize compilation
problems?

thanks,

Helena

Helena wrote:

I am meeting with collegues from comp. science at Duke who have
developed some great open source tools for GIS. It is in C++. I
would greatly appreciate any feedback that you could give me about
the use of C++ for GRASS modules/libraries, in particular - has
anybody done it or doing it?

Is it desirable or should all the code be in C to minimize
compilation problems?

Ideally libraries should be in C. Using C++ isn't out of the question
(e.g. GDAL is C++), but it does create some problems. At a minimum,
libraries should be usable from C.

BTW, there's a guide to writing portable C++ at

  http://www.mozilla.org/hacking/portable-cpp.html

Some of it is specific to Mozilla, but most of it is generally
applicable.

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

Helena wrote:

>

I am meeting with collegues from comp. science at Duke who have developed
some great open source
tools for GIS. It is in C++. I would greatly appreciate any feedback that
you could give me about
the use of C++ for GRASS modules/libraries, in particular - has anybody
done it or doing it?
Is it desirable or should all the code be in C to minimize compilation
problems?

I would like to know about their work (WEB site). We need a good
vector library. I started some search and found a few (all in C++).

For myself, I am confortable with C++.

Helena, can you give me some feedback.

THANKS

thanks,

Helena

_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

On Sun, Jul 29, 2001 at 05:55:31PM -0500, Helena wrote:

I am meeting with collegues from comp. science at Duke who have developed
some great open source tools for GIS. It is in C++.
I would greatly appreciate any feedback that
you could give me about
the use of C++ for GRASS modules/libraries, in particular - has anybody
done it or doing it?

There is no problem in having additional GRASS modules with C++ code in it.

Is it desirable or should all the code be in C to minimize compilation
problems?

I would think that core modules and libraries should be C if possible.
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

Thank you all for your feedback, it was very helpful.
For those who want to know more here are some websites:

http://www.cs.duke.edu/TPIE/
http://www.cs.duke.edu/geo*/terraflow/
(look at the performance and comparison with r.watershed, although I am
not sure whether it was run with all the right options, but I assume it was)

I met with prof. Lars Arge and Laura Toma. It was David Finlayson
from this list who recommended Laura and their terraflow, see
http://www.cs.duke.edu/geo*/terraflow/current.html
The performance is quite impressive.
And there is a potential for more than the flowrouting.
However, implementation in GRASS does not seem to be straightforward as
TPIE is templated classes and functions in C++.

I will keep you posted about any new developments (and questions),

Helena

Bernhard Reiter wrote:

On Sun, Jul 29, 2001 at 05:55:31PM -0500, Helena wrote:

> I am meeting with collegues from comp. science at Duke who have developed
> some great open source tools for GIS. It is in C++.
> I would greatly appreciate any feedback that
> you could give me about
> the use of C++ for GRASS modules/libraries, in particular - has anybody
> done it or doing it?

There is no problem in having additional GRASS modules with C++ code in it.

> Is it desirable or should all the code be in C to minimize compilation
> problems?

I would think that core modules and libraries should be C if possible.
        Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature