Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Nikos Alexandris]

Apologies for removing all but Soeren's last post.

* Sören Gebbert:


I would like to put the GRASS test framework into perspective, since i
think that its capabilities are not well known.
The gunittest framework is not about unit tests. It was designed to test
all aspects of the GRASS development. This framework allows you to:

* Implement unit tests for the Python libraries, their mthods and classes
* Implement and run doctests in the source code of the Python libraries
* Run integration tests for all modules, checking correct output for almost
all datatypes in GRASS (raster, vector, 3D raster, space-time datasets,
categories, color definitions, stdout, ...). Module tests are IMHO
integration tests, since module make use of different library methods and
classes and combine them.
* Run C-library tests as unit and integration tests. C-library unit and
integration tests can either be implemented in C or via ctypes in Python
* Run tests on library level, module level or for all libraries and modules
in the whole GRASS source tree using a single command, ...
* Perform regression tests in dedicated test locations, autimatically
triggered by a cronjob or a commit
* The framework allows you to run all library unit tests, before module
integration tests are performed
* It creates temporary mapsest to run without problems in production
locations
* It logs all tests in detail  and generates easy to inspect HTML output at
runtime, so you can check the progress of the tests and its gradually
available results
* It allows on the fly mapset creation and deletion
* It supports temporary region environments
* It support user defined test data for input generation and output
validation

These capabilities allow a wide range of tests to be created, covering most
aspects of the GRASS development, with the exception of the GUI.
So please no excuses that the gunittest framework is not capable of
implementing a test that is required to assure module correctness.


Soeren, could you name some good examples (not to the
manual/s), some real modules with integrated tests?  I am much in need
for good code.

By the way, working code does not necessarily mean good code.  And vice
versa, good code does not mean that it works the way it should.
Yet, broken but "good" code (cleanly documented, tested as much as possible)
can be easily fixed and probably easier optimised.  Working, though
poor/uncommented/untested code, is frequently, if not always, a
big-time-consuming mission.

The question, the way I understand things, is not if and at what extent
we need tests. GRASS-GIS needs them.
However, no matter the effort, tests will almost never be complete.-
That's what I was told by computer scientists, and what I can confirm
with my minimal experiences by doing, for at least two years now, in a
dozen of mini-projects.

Rather, the question is how can we bring, most, of the theory of testing in to
reality, put it in real action, beautify GRASS' code, whether core or
addons.  My understanding is that "our" common understanding is to focus
in raising the overall quality level, make it easy for some-one to read
the code, to understand the code almost as if reading simple text, to enable
some-one to improve or adapt a piece of code relatively fast.

Step-by-step.  Nothing is going to change overnight.
Not to forget, the community is a mixture of members with a high
diversity degree when looking at coding skills.  Everyone should be
invited. And everyone is invited. Experienced developers, are asked
and, with all the respect, (you) carry the responsibility to shed light for
the newcomers in coding for GRASS-GIS.

Allow me please to reiterate what I have repeated indirectly
or directly, some times:  please, dear reader/coder/scripter, 
when you write code, no matter what you write, comment your code,

use longer variable names, don't hesitate to repeat explaining, document
here and there. Test.  Use assertions in your code, even for simple,
single functions. Write code that "invites" the reader.

Yes, testing costs a lot of time.  But, if comparing it with the time
spent afterwards in debugging bad code, therein lies the wish to have spent the 
"less"
time right in the beginning.

Testing will boldly save big, valuable time.-
It'll beautify GRASS-GIS and grow the community.
It'll work for us, not against us.

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

[GRASS-dev] Fixed: GRASS-GIS/grass-ci#1635 (master - c575875)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1635
Status: Fixed

Duration: 15 minutes and 23 seconds
Commit: c575875 (master)
Author: Václav Petráš
Message: d.linegraph: let user provide Y tics [news]

Generated tics disabled when user provided.
No unlabeled tics generated. Printed as provided by
the user (strings, not numbers). Tics out of range simply
ignored.

This is also a workaround for tics with decimal places
(automatic tics work only with integers).


git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69677 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/c3b156359cfc...c5758751a838

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/165401967

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Paulo van Breugel]

On October 5, 2016 23:10:27 Anna Petrášová  wrote:


On Wed, Oct 5, 2016 at 10:46 AM, Moritz Lennert
 wrote:

On 05/10/16 16:29, Paulo van Breugel wrote:



On 05-10-16 15:20, Moritz Lennert wrote:


Maybe we should ask the users of whether this distinction between
modules and core and extensions is really relevant for them, or
whether most are perfectly happy to just install extensions.



Since you are asking :-) , as an user, my main interest is in good
documentation and reproducible examples (which I can than also use to
see if outputs make sense to me as an user). In that respect there is no
inherent difference between core modules and extensions. What is
different is that many (most?) of the core functions are accessible
through the menu. I personally don't find that very important,
especially with the modules tab giving fairly easy access to extensions,
but I can imagine that for new / other users, especially those more
inclined to menu-driven applications, this may make a difference.



Thank you, Paulo, for this feedback.

This means that finding a means to more easily integrate addon modules into
menus might be a task to keep in mind.

Maybe the startup script could check the .grass7/addons directory and
automatically create an 'addons' menu using [1] ? Maybe the mecanism can be
changed in a way to just allow to create toolboxes and that these are
automatically integrated into the main menu ?

Just brainstorming, here...

Moritz


[1] https://grass.osgeo.org/grass70/manuals/wxGUI.toolboxes.html


Hmm, this is already implemented (several years I would say). Look
into the tab Modules in layer manager. At least we now know, that
nobody here is using it...


I do use it. As I mentioned above, I find it a convenient way to access / 
find extensions. My point was that others might prefer to have access to 
these functions through the menu bar. And initially I was one of them, for 
some reason it took me time to get used using this modules tab, and to 
realize / internalize that the modules tab is in fact more powerful having 
the search function.


So I guess it is a matter of preference, which in turn will often depend on 
what a person is used to. I have seen a similar discussion concerning 
moving functions to the processing toolbox, but keeping a link to these 
functions in the menu.



Before adding additional menu Addons, I suggest reading
https://trac.osgeo.org/grass/ticket/1742


But yes, there are other issues to consider, like space on the menu bar,, true.




Anna



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



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

Re: [GRASS-dev] g.gui.tplot: AttributeError: 'module' object has no attribute 'EVT_COMBOBOX_CLOSEUP'

[Anna Petrášová]

On Mon, Oct 3, 2016 at 6:14 PM, Blumentrath, Stefan
 wrote:
> Hi,
>
>
>
> In the context of https://trac.osgeo.org/grass/ticket/3057 I just tested
> g.gui.tplot from GRASS 7.2 (r68908) on a STRDS and got the following error
> message:
>
>
>
> Traceback (most recent call last):
>
>   File "/usr/local/grass-7.2.svn/scripts/g.gui.tplot", line
>
> 130, in 
>
> main()
>
>   File "/usr/local/grass-7.2.svn/scripts/g.gui.tplot", line
>
> 116, in main
>
> frame = TplotFrame(parent=None,
>
> giface=StandaloneGrassInterface())
>
>   File
>
> "/usr/local/grass-7.2.svn/gui/wxpython/tplot/frame.py", line
>
> 106, in __init__
>
> self._layout()
>
>   File
>
> "/usr/local/grass-7.2.svn/gui/wxpython/tplot/frame.py", line
>
> 230, in _layout
>
> self.datasetSelectV.Bind(wx.EVT_COMBOBOX_CLOSEUP,
>
> AttributeError: 'module' object has no attribute
>
> 'EVT_COMBOBOX_CLOSEUP'
>
>
>
> I am on Ubuntu 14.04 LTS. Is that related to #3057? Any other ideas?

not related. This GUI event is apparently not supported. From documentation:
Notice that this event is only supported by wxMSW, wxGTK with GTK+
2.10 or later, and OSX/Cocoa.
What version of gtk do you use?
Anyway, we have to replace this event. It would be best to create a
ticket for this.

Anna

>
>
>
> Cheers
>
> Stefan
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Anna Petrášová]

On Wed, Oct 5, 2016 at 10:46 AM, Moritz Lennert
 wrote:
> On 05/10/16 16:29, Paulo van Breugel wrote:
>>
>>
>> On 05-10-16 15:20, Moritz Lennert wrote:
>>>
>>> Maybe we should ask the users of whether this distinction between
>>> modules and core and extensions is really relevant for them, or
>>> whether most are perfectly happy to just install extensions.
>>
>>
>> Since you are asking :-) , as an user, my main interest is in good
>> documentation and reproducible examples (which I can than also use to
>> see if outputs make sense to me as an user). In that respect there is no
>> inherent difference between core modules and extensions. What is
>> different is that many (most?) of the core functions are accessible
>> through the menu. I personally don't find that very important,
>> especially with the modules tab giving fairly easy access to extensions,
>> but I can imagine that for new / other users, especially those more
>> inclined to menu-driven applications, this may make a difference.
>>
>
> Thank you, Paulo, for this feedback.
>
> This means that finding a means to more easily integrate addon modules into
> menus might be a task to keep in mind.
>
> Maybe the startup script could check the .grass7/addons directory and
> automatically create an 'addons' menu using [1] ? Maybe the mecanism can be
> changed in a way to just allow to create toolboxes and that these are
> automatically integrated into the main menu ?
>
> Just brainstorming, here...
>
> Moritz
>
>
> [1] https://grass.osgeo.org/grass70/manuals/wxGUI.toolboxes.html

Hmm, this is already implemented (several years I would say). Look
into the tab Modules in layer manager. At least we now know, that
nobody here is using it...
Before adding additional menu Addons, I suggest reading
https://trac.osgeo.org/grass/ticket/1742


Anna

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

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

Hi,

2016-10-05 15:20 GMT+02:00 Moritz Lennert :

> On 05/10/16 14:24, Sören Gebbert wrote:
>
>> Hi,
>>
>> 2016-10-05 10:20 GMT+02:00 Moritz Lennert > >:
>>
>> [sent this from the wrong address, so it didn't get through to the
>> list]
>>
>>
>>  Message d'origine 
>> Envoyé : 5 octobre 2016 00:41:20 GMT+02:00
>>
>>
>>
>> Le 4 octobre 2016 22:55:35 GMT+02:00, "Anna Petrášová"
>> > a écrit :
>> >On Tue, Oct 4, 2016 at 4:22 PM, Markus Metz
>> >> > wrote:
>> >> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
>> >> > > wrote:
>> >>> Hi,
>> 
>> 
>>  >
>>  > You are very welcome to write the missing tests for core
>> modules.
>>  >
>>  > However, i don't understand the argument that because many core
>> >modules
>>  > have
>>  > no tests, therefore new modules don't need them. If developers
>> of
>> >addon
>>  > module are serious about the attempt to make their modules
>> usable
>> >and
>>  > maintainable for others, then they have to implement tests. Its
>> >and
>>  > integral
>>  > part of the development process and GRASS has a beautiful test
>>  > environment
>>  > hat makes writing tests easy. Tests and documentation are part
>> of
>> >coding
>>  > and
>>  > not something special. I don't think this is a hard
>> requirement.
>>  >
>>  > There is a nice statement that is not far from the truth:
>> >Untested code
>>  > is
>>  > broken code.
>> 
>>  these gunittests only test if a module output stays the same.
>> This
>> >>>
>> >>>
>> >>> This is simply wrong, please read the gunittest documentation.
>> >>
>> >> but then why does
>> >>>
>> >>> The gunittest for the v.stream.order addon is an example how its
>> >done:
>> >>>
>> >https://trac.osgeo.org/grass/browser/grass-addons/grass7/ve
>> ctor/v.stream.order/testsuite/test_stream_order.py
>> > ctor/v.stream.order/testsuite/test_stream_order.py>
>> >>
>> >> assume certain order numbers for features 4 and 7? What if these
>> >order
>> >> numbers are wrong?
>> >>
>> >> Recently I fixed bugs in r.stream.order, related to stream length
>> >> calculations which are in turn used to determine stream orders. The
>> >> gunittest did not pick up 1) the bugs, 2) the bug fixes.
>> >>
>> >>>
>> >>> You can write gunittests that will test every flag, every option,
>> >their
>> >>> combination and any output of a module. I have implemented plenty
>> of
>> >tests,
>> >>> that check for correct error handling. Writing tests is effort,
>> but
>> >you have
>> >>> to do it anyway. Why not implementing a gunittest for every
>> feature
>> >while
>> >>> developing the module?
>> 
>> 
>>  My guess for the r.stream.* modules is at least 40 man hours of
>>  testing to make sure they work correctly. That includes
>> evaluation
>> >of
>>  float usage, handling of NULL data, comparison of results with
>> and
>>  without the -m flag. Testing should be done with both high-res
>> >(LIDAR)
>>  and low-res (e.g. SRTM) DEMs.
>> >>>
>> >>>
>> >>> Tests can be performed on artificial data that tests all aspects
>> of
>> >the
>> >>> algorithm. Tests that show the correctness of the algorithm for
>> >specific
>> >>> small cases should be preferred. However, large data should not be
>> >an
>> >>> obstacle to write a test.
>> >>
>> >> I agree, for tests during development, not for gunittests.
>> >>
>> >> From the examples I read, gunittests expect a specific output. If
>> the
>> >> expected output (obtained with an assumed correct version of the
>> >> module) is wrong, the gunittest is bogus. gunittests are ok to make
>> >> sure the output does not change, but not ok to make sure the output
>> >is
>> >> correct. Two random examples are r.stream.order and r.univar.
>> >
>> >
>> >I am not sure why are we discussing this, it's pretty obvious that
>> >gunittests can serve to a) test inputs/outputs b) catch changes in
>> >results (whether correct or incorrect) c) test correctness of
>> results.
>> >It just depends how you write them, and yes, for some modules c) is
>> >more difficult to implement than for others.
>>
>>
>> Well, I agree with Markus that unittests are not a panacea and that
>> we should not fall into 

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Moritz Lennert]

On 05/10/16 17:14, Paulo van Breugel wrote:



On 05-10-16 16:50, Sören Gebbert wrote:



2016-10-05 16:46 GMT+02:00 Moritz Lennert
>:

On 05/10/16 16:29, Paulo van Breugel wrote:


On 05-10-16 15 :20, Moritz Lennert wrote:

Maybe we should ask the users of whether this distinction
between
modules and core and extensions is really relevant for
them, or
whether most are perfectly happy to just install extensions.


Since you are asking :-) , as an user, my main interest is in good
documentation and reproducible examples (which I can than also
use to
see if outputs make sense to me as an user). In that respect
there is no
inherent difference between core modules and extensions. What is
different is that many (most?) of the core functions are
accessible
through the menu. I personally don't find that very important,
especially with the modules tab giving fairly easy access to
extensions,
but I can imagine that for new / other users, especially those
more
inclined to menu-driven applications, this may make a difference.


Thank you, Paulo, for this feedback.

This means that finding a means to more easily integrate addon
modules into menus might be a task to keep in mind.

Maybe the startup script could check the .grass7/addons directory
and automatically create an 'addons' menu using [1] ? Maybe the
mecanism can be changed in a way to just allow to create toolboxes
and that these are automatically integrated into the main menu ?

Just brainstorming, here...


How about g.extension will create a menu entry based on the modules
keywords when it installs the module? And it will remove the entry
when the module gets removed?


These sound like interesting options. I don't have a very good idea what
would be the best approach, but I would caution against full freedom for
the module to install itself in any location in the menu. I am having in
mind how some QGIS addons create menu items, including in the top-level
menu, resulting in what for me is a more chaotic bloated environment. In
that sense, perhaps there could even be an option at installation to
prevent the module from creating a menu item.


The current toolboxes mecanism allows for a specific "user modules" menu 
which automatically contains anything which is in the 
.grass7/toolboxes/toolboxes.xml file. So if we just put all addons 
there, this might avoid the chaos you are talking about.


And as g.extension already does the work of reading the module 
description and keyword, it shouldn't be too complicated to integrate 
each new module into a toolbox named by the first keyword (raster, 
vector, imagery, etc) and to use its description as label.


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

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Paulo van Breugel]

On 05-10-16 16:50, Sören Gebbert wrote:



2016-10-05 16:46 GMT+02:00 Moritz Lennert 
>:


On 05/10/16 16:29, Paulo van Breugel wrote:


On 05-10-16 15 :20, Moritz Lennert wrote:

Maybe we should ask the users of whether this distinction
between
modules and core and extensions is really relevant for
them, or
whether most are perfectly happy to just install extensions.


Since you are asking :-) , as an user, my main interest is in good
documentation and reproducible examples (which I can than also
use to
see if outputs make sense to me as an user). In that respect
there is no
inherent difference between core modules and extensions. What is
different is that many (most?) of the core functions are
accessible
through the menu. I personally don't find that very important,
especially with the modules tab giving fairly easy access to
extensions,
but I can imagine that for new / other users, especially those
more
inclined to menu-driven applications, this may make a difference.


Thank you, Paulo, for this feedback.

This means that finding a means to more easily integrate addon
modules into menus might be a task to keep in mind.

Maybe the startup script could check the .grass7/addons directory
and automatically create an 'addons' menu using [1] ? Maybe the
mecanism can be changed in a way to just allow to create toolboxes
and that these are automatically integrated into the main menu ?

Just brainstorming, here...


How about g.extension will create a menu entry based on the modules 
keywords when it installs the module? And it will remove the entry 
when the module gets removed?


These sound like interesting options. I don't have a very good idea what 
would be the best approach, but I would caution against full freedom for 
the module to install itself in any location in the menu. I am having in 
mind how some QGIS addons create menu items, including in the top-level 
menu, resulting in what for me is a more chaotic bloated environment. In 
that sense, perhaps there could even be an option at installation to 
prevent the module from creating a menu item.





Best regards
Soeren


Moritz


[1] https://grass.osgeo.org/grass70/manuals/wxGUI.toolboxes.html


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





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

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Moritz Lennert]

On 05/10/16 16:29, Paulo van Breugel wrote:


On 05-10-16 15:20, Moritz Lennert wrote:

Maybe we should ask the users of whether this distinction between
modules and core and extensions is really relevant for them, or
whether most are perfectly happy to just install extensions.


Since you are asking :-) , as an user, my main interest is in good
documentation and reproducible examples (which I can than also use to
see if outputs make sense to me as an user). In that respect there is no
inherent difference between core modules and extensions. What is
different is that many (most?) of the core functions are accessible
through the menu. I personally don't find that very important,
especially with the modules tab giving fairly easy access to extensions,
but I can imagine that for new / other users, especially those more
inclined to menu-driven applications, this may make a difference.



Thank you, Paulo, for this feedback.

This means that finding a means to more easily integrate addon modules 
into menus might be a task to keep in mind.


Maybe the startup script could check the .grass7/addons directory and 
automatically create an 'addons' menu using [1] ? Maybe the mecanism can 
be changed in a way to just allow to create toolboxes and that these are 
automatically integrated into the main menu ?


Just brainstorming, here...

Moritz


[1] https://grass.osgeo.org/grass70/manuals/wxGUI.toolboxes.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

2016-10-05 16:46 GMT+02:00 Moritz Lennert :

> On 05/10/16 16:29, Paulo van Breugel wrote:
>
>>
>> On 05-10-16 15:20, Moritz Lennert wrote:
>>
>>> Maybe we should ask the users of whether this distinction between
>>> modules and core and extensions is really relevant for them, or
>>> whether most are perfectly happy to just install extensions.
>>>
>>
>> Since you are asking :-) , as an user, my main interest is in good
>> documentation and reproducible examples (which I can than also use to
>> see if outputs make sense to me as an user). In that respect there is no
>> inherent difference between core modules and extensions. What is
>> different is that many (most?) of the core functions are accessible
>> through the menu. I personally don't find that very important,
>> especially with the modules tab giving fairly easy access to extensions,
>> but I can imagine that for new / other users, especially those more
>> inclined to menu-driven applications, this may make a difference.
>>
>>
> Thank you, Paulo, for this feedback.
>
> This means that finding a means to more easily integrate addon modules
> into menus might be a task to keep in mind.
>
> Maybe the startup script could check the .grass7/addons directory and
> automatically create an 'addons' menu using [1] ? Maybe the mecanism can be
> changed in a way to just allow to create toolboxes and that these are
> automatically integrated into the main menu ?
>
> Just brainstorming, here...
>

How about g.extension will create a menu entry based on the modules
keywords when it installs the module? And it will remove the entry when the
module gets removed?

Best regards
Soeren


>
> Moritz
>
>
> [1] https://grass.osgeo.org/grass70/manuals/wxGUI.toolboxes.html
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Paulo van Breugel]

On 05-10-16 15:20, Moritz Lennert wrote:

On 05/10/16 14:24, Sören Gebbert wrote:

Hi,

2016-10-05 10:20 GMT+02:00 Moritz Lennert >:

[sent this from the wrong address, so it didn't get through to 
the list]



 Message d'origine 
Envoyé : 5 octobre 2016 00:41:20 GMT+02:00



Le 4 octobre 2016 22:55:35 GMT+02:00, "Anna Petrášová"
> a écrit :
>On Tue, Oct 4, 2016 at 4:22 PM, Markus Metz
>> wrote:
>> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
>> > wrote:
>>> Hi,


 >
 > You are very welcome to write the missing tests for core 
modules.

 >
 > However, i don't understand the argument that because many 
core

>modules
 > have
 > no tests, therefore new modules don't need them. If 
developers of

>addon
 > module are serious about the attempt to make their modules 
usable

>and
 > maintainable for others, then they have to implement 
tests. Its

>and
 > integral
 > part of the development process and GRASS has a beautiful 
test

 > environment
 > hat makes writing tests easy. Tests and documentation are 
part of

>coding
 > and
 > not something special. I don't think this is a hard 
requirement.

 >
 > There is a nice statement that is not far from the truth:
>Untested code
 > is
 > broken code.

 these gunittests only test if a module output stays the 
same. This

>>>
>>>
>>> This is simply wrong, please read the gunittest documentation.
>>
>> but then why does
>>>
>>> The gunittest for the v.stream.order addon is an example how its
>done:
>>>
>https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py

>>
>> assume certain order numbers for features 4 and 7? What if these
>order
>> numbers are wrong?
>>
>> Recently I fixed bugs in r.stream.order, related to stream length
>> calculations which are in turn used to determine stream 
orders. The

>> gunittest did not pick up 1) the bugs, 2) the bug fixes.
>>
>>>
>>> You can write gunittests that will test every flag, every 
option,

>their
>>> combination and any output of a module. I have implemented 
plenty of

>tests,
>>> that check for correct error handling. Writing tests is 
effort, but

>you have
>>> to do it anyway. Why not implementing a gunittest for every 
feature

>while
>>> developing the module?


 My guess for the r.stream.* modules is at least 40 man hours of
 testing to make sure they work correctly. That includes 
evaluation

>of
 float usage, handling of NULL data, comparison of results 
with and

 without the -m flag. Testing should be done with both high-res
>(LIDAR)
 and low-res (e.g. SRTM) DEMs.
>>>
>>>
>>> Tests can be performed on artificial data that tests all 
aspects of

>the
>>> algorithm. Tests that show the correctness of the algorithm for
>specific
>>> small cases should be preferred. However, large data should 
not be

>an
>>> obstacle to write a test.
>>
>> I agree, for tests during development, not for gunittests.
>>
>> From the examples I read, gunittests expect a specific output. 
If the

>> expected output (obtained with an assumed correct version of the
>> module) is wrong, the gunittest is bogus. gunittests are ok to 
make
>> sure the output does not change, but not ok to make sure the 
output

>is
>> correct. Two random examples are r.stream.order and r.univar.
>
>
>I am not sure why are we discussing this, it's pretty obvious that
>gunittests can serve to a) test inputs/outputs b) catch changes in
>results (whether correct or incorrect) c) test correctness of 
results.

>It just depends how you write them, and yes, for some modules c) is
>more difficult to implement than for others.


Well, I agree with Markus that unittests are not a panacea and that
we should not fall into the trap of thinking that these tests will
guarantee that the results of our modules are correct.


Then i live in a parallel universe. Simple question: How do you test
your software? How do you assure the correct functionality of your
software? Why is it impossible to implement your approach of testing in
a dedicated gunittest? How do you assure software quality, if you don't
provide tools so 

Re: [GRASS-dev] Working with TGIS without starting GRASS explicitly

[Laurent C.]

Hi Sören,

Thanks for your answer. I did something similar and it works well under
Linux.
Making those hacks works with Windows seems to be a bit more complex,
though.

Regards,
Laurent

2016-09-24 4:35 GMT-05:00 Sören Gebbert :
> Hi Laurent,
> i have attached a Python script that shows the handling of tgis.init() in
a
> subprocess in case location and mapsets change using grass72.
> The following output was generated with this script, it seems to work on
my
> system:
>
> soeren@knecht:~$ python test_tgis.py
> New envrionment: {u'MAPSET': u'PERMANENT', u'GISDBASE':
> u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08_grass7'}
> TGIS init:
> database: /home/soeren/grassdata
> location: nc_spm_08_grass7
> mapset: PERMANENT
> New envrionment: {u'MAPSET': u'user1', u'GISDBASE':
> u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08_grass7'}
> TGIS init:
> database: /home/soeren/grassdata
> location: nc_spm_08_grass7
> mapset: user1
> New envrionment: {u'MAPSET': u'PERMANENT', u'GISDBASE':
> u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08'}
> TGIS init:
> database: /home/soeren/grassdata
> location: nc_spm_08
> mapset: PERMANENT
> New envrionment: {u'MAPSET': u'user1', u'GISDBASE':
> u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08'}
> TGIS init:
> database: /home/soeren/grassdata
> location: nc_spm_08
> mapset: user1
>
>
> Best regards
> Soeren
>
>
> 2016-09-24 5:32 GMT+02:00 Laurent C. :
>>
>> Hi Sören,
>>
>> I followed you suggestion and now each simulation run in its own process
>> using the multiprocessing library. It works well, thanks.
>> However, there was indeed something strange going on:
>> The new mapset, location and accessible mapsets were set properly, as
seen
>> by the output of g.mapset and g.mapsets
>> However, the output of ciface.available_mapsets() and therefore
>> core.get_available_temporal_mapsets() were not updated after the first
>> simulation, so tgis.init() were failing, not seeing the new current
mapset
>> in its own list of available mapsets.
>>
>> Below was the output of the software:
>>
>> g.mapset -p
>> swashes_1d_1000m
>> g.mapsets -p
>> Accessible mapsets:
>> swashes_1d_1000m PERMANENT
>> ciface.available_mapsets()
>> ['swashes_1d_1000m', 'PERMANENT']
>> get_available_temporal_mapsets()
>> {'swashes_1d_1000m': ('sqlite',
>> '/home/laurent/grassdata/flood_test/swashes_1d_1000m/tgis/sqlite.db')}
>> Starting simulation for configuration file macdo1000.ini...
>> [...]
>> g.mapset -p
>> hull
>> g.mapsets -p
>> Accessible mapsets:
>> hull PERMANENT hull_rain
>> ciface.available_mapsets()
>> ['swashes_1d_1000m', 'PERMANENT']
>> get_available_temporal_mapsets()
>> {'swashes_1d_1000m': ('sqlite',
>> '/home/laurent/grassdata/flood_test/swashes_1d_1000m/tgis/sqlite.db')}
>> ERROR: Unable to execute sql statement. There is no temporal database
>> connection defined for mapset 
>>
>> It seems that tgis.init() is not doing what it is supposed to, according
>> to the documentation:
>>
>> "Re-run this function in case the following GRASS variables change while
>> the process runs:
>> - MAPSET
>> - LOCATION_NAME
>> - GISDBASE
>> - TGIS_DISABLE_MAPSET_CHECK
>> - TGIS_DISABLE_TIMESTAMP_WRITE
>> "
>>
>> Thanks again.
>>
>> Regards,
>> Laurent
>>
>> 2016-09-22 13:52 GMT-05:00 Sören Gebbert :
>> > Hi Laurent,
>> > the temporal framework was neither tested nor designed to work in a
>> > script
>> > that changes the location while running. I would suggest to run the
>> > temporal
>> > framework related code in a subprocess that is created each time the
>> > location or mapset changes. Unfortunately i have no other suggestion.
>> >
>> > However, have you tested your code with grass 7.2 or 7.3? Many
>> > improvements
>> > have been implement in the recent version that would be beneficial to
>> > use.
>> >
>> > Best regards
>> > Soeren
>> >
>> > 2016-09-22 2:47 GMT+02:00 Laurent C. :
>> >>
>> >> Hello all,
>> >>
>> >> I've ran into another related issue.
>> >> One of the goal of running the software outside of GRASS shell is to
>> >> batch process simulations in various Locations/mapsets.
>> >>
>> >> I set the GRASS session for each case. The simulation works well for
>> >> the first case.
>> >> However when starting the second case, tgis.init() fails with the
>> >> following error:
>> >>
>> >> ERROR: Unable to execute sql statement. There is no temporal database
>> >> connection defined for mapset 
>> >>
>> >> The mapset and location are properly set.
>> >> If this case is run first, it works well and it's the second one that
>> >> fail.
>> >> Running t.connect -c between two cases does not solve the problem.
>> >> Actually, t.connect -p shows the correct connection parameters, but
>> >> tgis.init() still fails.
>> >>
>> >> Regards,
>> >> Laurent
>> >>
>> >>
>> >> 2016-09-21 18:27 GMT-05:00 Laurent C. :
>> >> > Hi Sören,
>> >> >
>> >> > Setting LD_LIBRARY_PATH is 

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Moritz Lennert]

On 05/10/16 14:24, Sören Gebbert wrote:

Hi,

2016-10-05 10:20 GMT+02:00 Moritz Lennert >:

[sent this from the wrong address, so it didn't get through to the list]


 Message d'origine 
Envoyé : 5 octobre 2016 00:41:20 GMT+02:00



Le 4 octobre 2016 22:55:35 GMT+02:00, "Anna Petrášová"
> a écrit :
>On Tue, Oct 4, 2016 at 4:22 PM, Markus Metz
>> wrote:
>> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
>> > wrote:
>>> Hi,


 >
 > You are very welcome to write the missing tests for core modules.
 >
 > However, i don't understand the argument that because many core
>modules
 > have
 > no tests, therefore new modules don't need them. If developers of
>addon
 > module are serious about the attempt to make their modules usable
>and
 > maintainable for others, then they have to implement tests. Its
>and
 > integral
 > part of the development process and GRASS has a beautiful test
 > environment
 > hat makes writing tests easy. Tests and documentation are part of
>coding
 > and
 > not something special. I don't think this is a hard requirement.
 >
 > There is a nice statement that is not far from the truth:
>Untested code
 > is
 > broken code.

 these gunittests only test if a module output stays the same. This
>>>
>>>
>>> This is simply wrong, please read the gunittest documentation.
>>
>> but then why does
>>>
>>> The gunittest for the v.stream.order addon is an example how its
>done:
>>>

>https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py


>>
>> assume certain order numbers for features 4 and 7? What if these
>order
>> numbers are wrong?
>>
>> Recently I fixed bugs in r.stream.order, related to stream length
>> calculations which are in turn used to determine stream orders. The
>> gunittest did not pick up 1) the bugs, 2) the bug fixes.
>>
>>>
>>> You can write gunittests that will test every flag, every option,
>their
>>> combination and any output of a module. I have implemented plenty of
>tests,
>>> that check for correct error handling. Writing tests is effort, but
>you have
>>> to do it anyway. Why not implementing a gunittest for every feature
>while
>>> developing the module?


 My guess for the r.stream.* modules is at least 40 man hours of
 testing to make sure they work correctly. That includes evaluation
>of
 float usage, handling of NULL data, comparison of results with and
 without the -m flag. Testing should be done with both high-res
>(LIDAR)
 and low-res (e.g. SRTM) DEMs.
>>>
>>>
>>> Tests can be performed on artificial data that tests all aspects of
>the
>>> algorithm. Tests that show the correctness of the algorithm for
>specific
>>> small cases should be preferred. However, large data should not be
>an
>>> obstacle to write a test.
>>
>> I agree, for tests during development, not for gunittests.
>>
>> From the examples I read, gunittests expect a specific output. If the
>> expected output (obtained with an assumed correct version of the
>> module) is wrong, the gunittest is bogus. gunittests are ok to make
>> sure the output does not change, but not ok to make sure the output
>is
>> correct. Two random examples are r.stream.order and r.univar.
>
>
>I am not sure why are we discussing this, it's pretty obvious that
>gunittests can serve to a) test inputs/outputs b) catch changes in
>results (whether correct or incorrect) c) test correctness of results.
>It just depends how you write them, and yes, for some modules c) is
>more difficult to implement than for others.


Well, I agree with Markus that unittests are not a panacea and that
we should not fall into the trap of thinking that these tests will
guarantee that the results of our modules are correct.


Then i live in a parallel universe. Simple question: How do you test
your software? How do you assure the correct functionality of your
software? Why is it impossible to implement your approach of testing in
a dedicated gunittest? How do you assure software quality, if you don't
provide tools so that other developers are able to test your software
for correctness? 

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Sören Gebbert]

Hi,

2016-10-05 10:20 GMT+02:00 Moritz Lennert :

> [sent this from the wrong address, so it didn't get through to the list]
>
>
>  Message d'origine 
> Envoyé : 5 octobre 2016 00:41:20 GMT+02:00
>
>
>
> Le 4 octobre 2016 22:55:35 GMT+02:00, "Anna Petrášová" <
> kratocha...@gmail.com> a écrit :
> >On Tue, Oct 4, 2016 at 4:22 PM, Markus Metz
> > wrote:
> >> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
> >>  wrote:
> >>> Hi,
> 
> 
>  >
>  > You are very welcome to write the missing tests for core modules.
>  >
>  > However, i don't understand the argument that because many core
> >modules
>  > have
>  > no tests, therefore new modules don't need them. If developers of
> >addon
>  > module are serious about the attempt to make their modules usable
> >and
>  > maintainable for others, then they have to implement tests. Its
> >and
>  > integral
>  > part of the development process and GRASS has a beautiful test
>  > environment
>  > hat makes writing tests easy. Tests and documentation are part of
> >coding
>  > and
>  > not something special. I don't think this is a hard requirement.
>  >
>  > There is a nice statement that is not far from the truth:
> >Untested code
>  > is
>  > broken code.
> 
>  these gunittests only test if a module output stays the same. This
> >>>
> >>>
> >>> This is simply wrong, please read the gunittest documentation.
> >>
> >> but then why does
> >>>
> >>> The gunittest for the v.stream.order addon is an example how its
> >done:
> >>>
> >https://trac.osgeo.org/grass/browser/grass-addons/grass7/
> vector/v.stream.order/testsuite/test_stream_order.py
> >>
> >> assume certain order numbers for features 4 and 7? What if these
> >order
> >> numbers are wrong?
> >>
> >> Recently I fixed bugs in r.stream.order, related to stream length
> >> calculations which are in turn used to determine stream orders. The
> >> gunittest did not pick up 1) the bugs, 2) the bug fixes.
> >>
> >>>
> >>> You can write gunittests that will test every flag, every option,
> >their
> >>> combination and any output of a module. I have implemented plenty of
> >tests,
> >>> that check for correct error handling. Writing tests is effort, but
> >you have
> >>> to do it anyway. Why not implementing a gunittest for every feature
> >while
> >>> developing the module?
> 
> 
>  My guess for the r.stream.* modules is at least 40 man hours of
>  testing to make sure they work correctly. That includes evaluation
> >of
>  float usage, handling of NULL data, comparison of results with and
>  without the -m flag. Testing should be done with both high-res
> >(LIDAR)
>  and low-res (e.g. SRTM) DEMs.
> >>>
> >>>
> >>> Tests can be performed on artificial data that tests all aspects of
> >the
> >>> algorithm. Tests that show the correctness of the algorithm for
> >specific
> >>> small cases should be preferred. However, large data should not be
> >an
> >>> obstacle to write a test.
> >>
> >> I agree, for tests during development, not for gunittests.
> >>
> >> From the examples I read, gunittests expect a specific output. If the
> >> expected output (obtained with an assumed correct version of the
> >> module) is wrong, the gunittest is bogus. gunittests are ok to make
> >> sure the output does not change, but not ok to make sure the output
> >is
> >> correct. Two random examples are r.stream.order and r.univar.
> >
> >
> >I am not sure why are we discussing this, it's pretty obvious that
> >gunittests can serve to a) test inputs/outputs b) catch changes in
> >results (whether correct or incorrect) c) test correctness of results.
> >It just depends how you write them, and yes, for some modules c) is
> >more difficult to implement than for others.
>
>
> Well, I agree with Markus that unittests are not a panacea and that we
> should not fall into the trap of thinking that these tests will guarantee
> that the results of our modules are correct.
>

Then i live in a parallel universe. Simple question: How do you test your
software? How do you assure the correct functionality of your software? Why
is it impossible to implement your approach of testing in a dedicated
gunittest? How do you assure software quality, if you don't provide tools
so that other developers are able to test your software for correctness?
Regression tests are not possible then, because the effect of changes in
the core libraries can not be easily detected in modules without tests.

Can you explain to me why the developers of the sophisticated software
system VTK [1] implement unit and integration tests for all software
components to assure the correct functionality of the framework? They
didn't saw the trap? They are delusional to think that tests assure
software quality?

Why is test driven development [2] an integral part of agile software

[GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Moritz Lennert]

[sent this from the wrong address, so it didn't get through to the list]


 Message d'origine 
Envoyé : 5 octobre 2016 00:41:20 GMT+02:00



Le 4 octobre 2016 22:55:35 GMT+02:00, "Anna Petrášová"  
a écrit :
>On Tue, Oct 4, 2016 at 4:22 PM, Markus Metz
> wrote:
>> On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
>>  wrote:
>>> Hi,


 >
 > You are very welcome to write the missing tests for core modules.
 >
 > However, i don't understand the argument that because many core
>modules
 > have
 > no tests, therefore new modules don't need them. If developers of
>addon
 > module are serious about the attempt to make their modules usable
>and
 > maintainable for others, then they have to implement tests. Its
>and
 > integral
 > part of the development process and GRASS has a beautiful test
 > environment
 > hat makes writing tests easy. Tests and documentation are part of
>coding
 > and
 > not something special. I don't think this is a hard requirement.
 >
 > There is a nice statement that is not far from the truth:
>Untested code
 > is
 > broken code.

 these gunittests only test if a module output stays the same. This
>>>
>>>
>>> This is simply wrong, please read the gunittest documentation.
>>
>> but then why does
>>>
>>> The gunittest for the v.stream.order addon is an example how its
>done:
>>>
>https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py
>>
>> assume certain order numbers for features 4 and 7? What if these
>order
>> numbers are wrong?
>>
>> Recently I fixed bugs in r.stream.order, related to stream length
>> calculations which are in turn used to determine stream orders. The
>> gunittest did not pick up 1) the bugs, 2) the bug fixes.
>>
>>>
>>> You can write gunittests that will test every flag, every option,
>their
>>> combination and any output of a module. I have implemented plenty of
>tests,
>>> that check for correct error handling. Writing tests is effort, but
>you have
>>> to do it anyway. Why not implementing a gunittest for every feature
>while
>>> developing the module?


 My guess for the r.stream.* modules is at least 40 man hours of
 testing to make sure they work correctly. That includes evaluation
>of
 float usage, handling of NULL data, comparison of results with and
 without the -m flag. Testing should be done with both high-res
>(LIDAR)
 and low-res (e.g. SRTM) DEMs.
>>>
>>>
>>> Tests can be performed on artificial data that tests all aspects of
>the
>>> algorithm. Tests that show the correctness of the algorithm for
>specific
>>> small cases should be preferred. However, large data should not be
>an
>>> obstacle to write a test.
>>
>> I agree, for tests during development, not for gunittests.
>>
>> From the examples I read, gunittests expect a specific output. If the
>> expected output (obtained with an assumed correct version of the
>> module) is wrong, the gunittest is bogus. gunittests are ok to make
>> sure the output does not change, but not ok to make sure the output
>is
>> correct. Two random examples are r.stream.order and r.univar.
>
>
>I am not sure why are we discussing this, it's pretty obvious that
>gunittests can serve to a) test inputs/outputs b) catch changes in
>results (whether correct or incorrect) c) test correctness of results.
>It just depends how you write them, and yes, for some modules c) is
>more difficult to implement than for others.


Well, I agree with Markus that unittests are not a panacea and that we should 
not fall into the trap of thinking that these tests will guarantee that the 
results of our modules are correct.

However, I do agree that these tests are useful in detecting if any changes to 
the code change the output, thus raising a flag that the developer has to at 
least take into account.

I'll try to write some tests for the OBIA tools when I find the time, although 
I do agree with Markus that it wouldn't be useful to try to write tests that 
would cover each and every possible corner case...

In the meantime, g.extension is wonderful tool 

Moritz

>
>Anna
>
>>
>> Markus M
>>
>>>
>>> Best regards
>>> Soeren
>>>

 my2c

 Markus M

 >
 > Best
 > Sören
 >
 >>
 >> One thing we could think about is activating the toolbox idea a
>bit
 >> more
 >> and creating a specific OBIA toolbox in addons.
 >>
 >>> Identified candidates could be added to core once they fulfill
>the
 >>> requirements above. Would that happen only in minor releases or
>would
 >>> that also be possible in point releases?
 >>
 >>
 >> Adding modules to core is not an API change, so I don't see why
>they
 >> can't
 >> be added at any time. But then again, having a series of new
>modules
 >> can be
 >> sufficient 

Re: [GRASS-dev] [GRASS GIS] #3115: v.kriging: segfault if a parameter is not set

[GRASS GIS]

#3115: v.kriging: segfault if a parameter is not set
-+-
  Reporter:  mlennert|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Addons  |Version:  unspecified
Resolution:  |   Keywords:  v.kriging required parameter
   CPU:  |  segfault
  Unspecified|   Platform:  Unspecified
-+-

Comment (by mlennert):

 Response from Eva on the ML:

 On 04/10/16 22:00, Eva Stopková wrote:
 > 2016-08-04 15:42 GMT+02:00 GRASS GIS  >:
 >
 > #3115: v.kriging: segfault if a parameter is not set
 >
 -+-
 >  Reporter:  mlennert |  Owner:
 > grass-dev@…
 >  Type:  defect   | Status:  new
 >  Priority:  normal   |  Milestone:
 7.0.5
 > Component:  Addons   |Version:
 > unspecified
 >  Keywords:  v.kriging required parameter |CPU:
 > Unspecified
 >   segfault   |
 >  Platform:  Unspecified  |
 >
 -+-
 >  In the v.kriging addon, when I only provide the parameters marked
 as
 >  required (+ the -2 flag for 2D interpolation) I get the following:
 >
 >
 >  {{{
 >  v.extract elev_lid792_randpts out=elev_lid792_selected random=500
 --o
 >  v.kriging -2 input=elev_lid792_selected@user1 phase=initial
 > icolumn=value
 >  WARNING: Not recommended to process for sparse or spatially
 > heterogeneous
 >   data. The result can be inaccurate - trying to solve
 asap...
 >  Reading coordinates...
 >  Segmentation fault
 >  }}}
 >
 >  I have to add the report parameter for it to work:
 >
 >
 >  {{{
 >  v.kriging -2 input=elev_lid792_selected@user1 phase=initial
 > icolumn=value
 >  report=report.txt
 >  }}}
 >
 >
 > I have fixed the bug like this: if the report name is missing, just
 > initial phase (preliminary experimental variogram computation) is
 > performed and the user is asked to repeat it with non-empty report
 > parameter if he wish to continue with theoretical variogram and
 > interpolation.
 >
 >
 >  At this stage, two unasked-for files are in the same directory:
 > dataE.dat
 >  and
 >  variogram_hz_tmp.txt.
 >
 >  Required parameters should be declared as such and not lead to a
 > segfault.
 >  And any temporary files created during the run of the module should
 be
 >  erased at the end.
 >
 >
 > These temporary files are necessary, as they store settings and results
 > from previous phases to be available in current phase of interpolation.
 > And the process needs to be splitted into phases, because there is an
 > interaction with the user needed (theoretical parameters settings
 > according to experimental variogram). Unfortunatelly, this is not
 > possible to manage interactively during module performance.
 >
 > As these files are unasked-for indeed, I have added the information
 > about them into command output: If initial phase is successfully
 > accomplished, the user is warned not to erase temporary files
 >  and . They are deleted in middle
 > (final) phase automatically, but in previous module version, the user
 > had been informed just in case that they were missing accidentally.
 >

 Changes are in r69676.

 This sounds like a good solution. Thank you !

 Another option would be to split the module into three modules. That way
 for each phase you can clearly define the inputs and outputs. It might
 make it clearer for the user. On the other hand, I understand the
 reasoning behind one module for kriging...

 IMHO, this really calls for a GUI wrapper above the module (or modules)
 that makes the different calls, based on interactive input from the user.

 Moritz

 P.S. When responding to bug tickets, it is always better to do this within
 the bug tracker, including a reference to the changeset in svn, so that
 your responses are logged there.

--
Ticket URL: 
GRASS GIS 

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