Re: [GRASS-dev] [GRASS-SVN] r66990 - in grass/trunk/scripts: . g.search.module g.search.module/testsuite

[Martin Landa]

Hi Markus,

2015-11-30 22:12 GMT+01:00 Markus Neteler :

> while I like all this very much, I would prefer to remove this
> ".module" from the name and the directory name.
> We do not use .module anywhere since it is redundant.
> Or is there a particular reason for this?

see relevant discussion at
https://lists.osgeo.org/pipermail/grass-dev/2015-November/077524.html

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Vaclav Petras]

On Mon, Nov 30, 2015 at 4:22 PM, Markus Neteler  wrote:

> > Considering the fact that an important/main use case is interactive
> usage in
> > the command line, I now lean towards:
> >
> > g.search.module aspect
>
> I would suggest to not use the singular "module" but plural "modules"
> which would better explain itself.
> We are searching in multiple modules, aren't we?
>
> So my suggestion:
> g.search.modules


Right! We are also getting multiple modules as a result. The GUI tab is
called Search modules, I've mentioned here myself but then forgot about it.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66990 - in grass/trunk/scripts: . g.search.module g.search.module/testsuite

[Markus Neteler]

On Mon, Nov 30, 2015 at 10:09 PM,   wrote:
> Author: jachym
> Date: 2015-11-30 13:09:22 -0800 (Mon, 30 Nov 2015)
> New Revision: 66990
>
> Added:
>grass/trunk/scripts/g.search.module/
>grass/trunk/scripts/g.search.module/Makefile
>grass/trunk/scripts/g.search.module/g.search.module.html
>grass/trunk/scripts/g.search.module/g.search.module.py
>grass/trunk/scripts/g.search.module/testsuite/
>grass/trunk/scripts/g.search.module/testsuite/test_g_search_module.py
> Modified:
>grass/trunk/scripts/Makefile
> Log:
> Adding new g.search.module script


Hi Jachym

while I like all this very much, I would prefer to remove this
".module" from the name and the directory name.
We do not use .module anywhere since it is redundant.
Or is there a particular reason for this?

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

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

OK guys,

the script called g.search.module is now in trunk, I've added tests (Vašek:
they seem to be far too verbose to me, anything I could do about that?)

I've left the colorize and print_output functions in the file, reason:
better code structure would have to be implemented (read: IMHO decorator at
least for colorize should be used and I'm to doubt for now to get working)

still hope, it's ok for you as it is now, if not, just let me know

cheers and thanks for help

Jachym

po 30. 11. 2015 v 16:19 odesílatel Vaclav Petras 
napsal:

> On Mon, Nov 30, 2015 at 3:27 AM, Jachym Cepicky 
> wrote:
>
>> about the tests - generally yes, I'm writing it. Are you referring to
>> r3.info or to g.search.* modules?  I could not found any example to
>> r3.info tests
>>
>
> I meant r3.info as it is more critical but g.search.* is similar just not
> critical.
>
>
> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#tests-of-grass-modules
>
> https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_r_mapcalc.py#L80
>
> https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/testsuite/test_assertions.py
>
>
>>
>> I've rewritten r3.info so that the code is the same, as r.info (with -e
>> flag) - but I can not tell, I'm satisfied with the result
>>
>
> I also cannot tell.
>
> https://trac.osgeo.org/grass/changeset/66983
> https://trac.osgeo.org/grass/changeset/66984
>
>
>> (there are line breaks and quotes in the strings, what IMHO is really not
>> good)
>>
>
> The comments, history or whatever it is is written as shell command for r
> and r3, so the strings are in quotes (to be general) and long lines are
> broken and continuation is done by backslash. With r3.info I now get:
>
> comments="r3.flow input="test1" flowaccumulation="test2" unit="cell"
> step=0.25\ limit=2000 max_error=1e-5 direction="down""
>
> I'm not sure how exactly this compares to r.info. Vectors have this in
> some better way but it's part of the format and I'm not familiar with it.
>
>
>> My time resources allocatable to this task are slowly reaching to their
>> end. I would need clear decision from you guys (since you are in charge to
>> mess around GRASS code base):
>>
>> Where to put print_output & supporting functions?
>>
>
> print_output can go to lib/python/script/utils.py (grass.script.utils).
> The others probably too, although I would mark them as experimental (not
> guaranteed API).
>
>
>> Where to write tests for them?
>>
>
> In a file in the testsuite directory at the level of the tested file, i.e.
> lib/python/script/testsuite for lib/python/script/utils.py.
>
> (I assume standard unittest package is being used)
>>
>
> unittest and grass.gnunittest, please see
>
> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html
>
>
>> Can I omit g.search.data for now? (I would like to put some better code
>> structure, as I can see it more clear now) - so I would put only
>> g.search.module for now to GRASS trunk?
>>
>
> Sure.
>
> Thanks! I'm looking forward to it.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66990 - in grass/trunk/scripts: . g.search.module g.search.module/testsuite

[Markus Neteler]

On Mon, Nov 30, 2015 at 10:15 PM, Martin Landa  wrote:
> Hi Markus,
>
> 2015-11-30 22:12 GMT+01:00 Markus Neteler :
>
>> while I like all this very much, I would prefer to remove this
>> ".module" from the name and the directory name.
>> We do not use .module anywhere since it is redundant.
>> Or is there a particular reason for this?
>
> see relevant discussion at
> https://lists.osgeo.org/pipermail/grass-dev/2015-November/077524.html

ah I see! I guess my confusion arises from the fact that the singular
"module" is used and not "modules" which would better explain itself.

I'll write in the other thread.

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

Re: [GRASS-dev] proposal for g.search module

[Vaclav Petras]

On Mon, Nov 30, 2015 at 4:12 PM, Jachym Cepicky 
wrote:

> the script called g.search.module is now in trunk, I've added tests
>

Great. It is really fast (without -m). It will be useful.


> (Vašek: they seem to be far too verbose to me, anything I could do about
> that?)
>

Yes, partially. The it is written with verbosity rather higher than lower
but some things would need more programming. No quiet option available now
but at least some basic form might be relatively easy to add.


>
> I've left the colorize and print_output functions in the file, reason:
> better code structure would have to be implemented (read: IMHO decorator at
> least for colorize should be used and I'm to doubt for now to get working)
>

Yes, perhaps we should let it settle.

Now I see that termcolor is not necessarily installed (I had no reason to
install it so far), so some better error handing is needed.

With -m, I'm getting a lot of these:

g.search.module search -m
warning: file `', around line 172:
  table wider than line width

I get those with test as well and additionally also:

==
FAIL: test_json_output (__main__.TestSearchModule)
--
Traceback (most recent call last):
  File "./test_g_search_module.py", line 37, in test_json_output
self.assertEqual(stdout[3]['name'], 'r.basins.fill', 'r.basins.fill')
AssertionError: r.basins.fill
u'r.sim.water' != 'r.basins.fill'

==
FAIL: test_shell_outout (__main__.TestSearchModule)
--
Traceback (most recent call last):
  File "./test_g_search_module.py", line 45, in test_shell_outout
self.assertEqual(stdout[3], 'r.basins.fill')
AssertionError: 'r.sim.water' != 'r.basins.fill'
- r.sim.water
+ r.basins.fill

Can't investigate more now but I'm definitively looking forward to using it.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Markus Neteler]

Hi

On Sat, Nov 28, 2015 at 3:29 PM, Vaclav Petras  wrote:
>
> On Sat, Nov 28, 2015 at 5:09 AM, Jachym Cepicky 
> wrote:
>>
>> Vašku, if we agree on adding more search engines to g.search, I suggest to
>> define the features and interface (--help output) now and I can start think
>> about more generic concept of the code
>>
>> modules
>> maps, groups
>> mapsets
>> locations?
>> regions
>> ...
>
> Considering the fact that an important/main use case is interactive usage in
> the command line, I now lean towards:
>
> g.search.module aspect

I would suggest to not use the singular "module" but plural "modules"
which would better explain itself.
We are searching in multiple modules, aren't we?

So my suggestion:
g.search.modules

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

[GRASS-dev] Activating pyspatialite in the wingrass addon build server

[Helmut Kudrnovsky]

Hi,

some days ago I've added a new addon which uses pyspatialite for connecting
to sqlite/spatialite databases.

could be pyspatialite activated in the wingrass addon build server?

pyspatialite is available in the OSGeo4W stack.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Activating-pyspatialite-in-the-wingrass-addon-build-server-tp5239197.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Vaclav Petras]

On Mon, Nov 30, 2015 at 3:27 AM, Jachym Cepicky 
wrote:

> about the tests - generally yes, I'm writing it. Are you referring to
> r3.info or to g.search.* modules?  I could not found any example to
> r3.info tests
>

I meant r3.info as it is more critical but g.search.* is similar just not
critical.

https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#tests-of-grass-modules
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_r_mapcalc.py#L80
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/testsuite/test_assertions.py


>
> I've rewritten r3.info so that the code is the same, as r.info (with -e
> flag) - but I can not tell, I'm satisfied with the result
>

I also cannot tell.

https://trac.osgeo.org/grass/changeset/66983
https://trac.osgeo.org/grass/changeset/66984


> (there are line breaks and quotes in the strings, what IMHO is really not
> good)
>

The comments, history or whatever it is is written as shell command for r
and r3, so the strings are in quotes (to be general) and long lines are
broken and continuation is done by backslash. With r3.info I now get:

comments="r3.flow input="test1" flowaccumulation="test2" unit="cell"
step=0.25\ limit=2000 max_error=1e-5 direction="down""

I'm not sure how exactly this compares to r.info. Vectors have this in some
better way but it's part of the format and I'm not familiar with it.


> My time resources allocatable to this task are slowly reaching to their
> end. I would need clear decision from you guys (since you are in charge to
> mess around GRASS code base):
>
> Where to put print_output & supporting functions?
>

print_output can go to lib/python/script/utils.py (grass.script.utils). The
others probably too, although I would mark them as experimental (not
guaranteed API).


> Where to write tests for them?
>

In a file in the testsuite directory at the level of the tested file, i.e.
lib/python/script/testsuite for lib/python/script/utils.py.

(I assume standard unittest package is being used)
>

unittest and grass.gnunittest, please see

https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html


> Can I omit g.search.data for now? (I would like to put some better code
> structure, as I can see it more clear now) - so I would put only
> g.search.module for now to GRASS trunk?
>

Sure.

Thanks! I'm looking forward to it.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Convenient download of the new logo is missing

[Vaclav Petras]

Hi all,

the new cleaned up logo for GRASS GIS with the bold+thin text is available
online [1] only in zip download where SVG requires the special font and PNG
not that flexible for scaling since the thin text (GIS) is might be badly
re-sampled.

Please, can somebody with the right fonts installed provide SVG with text
as vectors and a PDF?

Thanks,
Vaclav

[1] https://grass.osgeo.org/download/logos/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Activating pyspatialite in the wingrass addon build server

[Martin Landa]

Hi,

2015-11-30 17:57 GMT+01:00 Helmut Kudrnovsky :
> some days ago I've added a new addon which uses pyspatialite for connecting
> to sqlite/spatialite databases.
>
> could be pyspatialite activated in the wingrass addon build server?
>
> pyspatialite is available in the OSGeo4W stack.

done, I started to collect addons dependecies at [1]. Ma

[1] 
https://svn.osgeo.org/grass/grass-addons/tools/wingrass-packager/dependecies.txt

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Activating pyspatialite in the wingrass addon build server

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi,
> 
> 2015-11-30 17:57 GMT+01:00 Helmut Kudrnovsky 

> hellik@

> :
>> some days ago I've added a new addon which uses pyspatialite for
>> connecting
>> to sqlite/spatialite databases.
>>
>> could be pyspatialite activated in the wingrass addon build server?
>>
>> pyspatialite is available in the OSGeo4W stack.
> 
> done, I started to collect addons dependecies at [1]. Ma
> 
> [1]
> https://svn.osgeo.org/grass/grass-addons/tools/wingrass-packager/dependecies.txt
> 
> -- 
> Martin Landa


Thanks a lot. 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Activating-pyspatialite-in-the-wingrass-addon-build-server-tp5239197p5239214.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Convenient download of the new logo is missing

[Vincent Bain]

oops,
I did it in a hurry, and forgot to vectorize the slogan as well

sorry, will fix it on wednesday

V.

Le lundi 30 novembre 2015 à 13:38 -0500, Vaclav Petras a écrit :
> Hi all,
> 
> the new cleaned up logo for GRASS GIS with the bold+thin text is
> available online [1] only in zip download where SVG requires the
> special font and PNG not that flexible for scaling since the thin text
> (GIS) is might be badly re-sampled.
> 
> 
> Please, can somebody with the right fonts installed provide SVG with
> text as vectors and a PDF?
> 
> 
> Thanks,
> 
> Vaclav
> 
> [1] https://grass.osgeo.org/download/logos/
> 
> ___
> 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] Convenient download of the new logo is missing

[Vincent Bain]

Hello Vaclav,
you are right, it's not very convenient.

attached is an archive containing files I hope you need ("vf" for
vectorized fonts).

Bye,

Vincent


Le lundi 30 novembre 2015 à 13:38 -0500, Vaclav Petras a écrit :
> Hi all,
> 
> the new cleaned up logo for GRASS GIS with the bold+thin text is
> available online [1] only in zip download where SVG requires the
> special font and PNG not that flexible for scaling since the thin text
> (GIS) is might be badly re-sampled.
> 
> 
> Please, can somebody with the right fonts installed provide SVG with
> text as vectors and a PDF?
> 
> 
> Thanks,
> 
> Vaclav
> 
> [1] https://grass.osgeo.org/download/logos/
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



grass_gis_logo_2015_vf.tar.gz
Description: application/compressed-tar
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Convenient download of the new logo is missing

[Vaclav Petras]

On Mon, Nov 30, 2015 at 2:26 PM, Vincent Bain  wrote:

>
> attached is an archive containing files I hope you need ("vf" for
> vectorized fonts).


Thanks! This is exactly what I need now. Well, actually what I need right
now is a cropped PDF, so no page and no borders (file attached, done with
pdfcrop).


grass_gis.pdf
Description: Adobe PDF document
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Convenient download of the new logo is missing

[Vincent Bain]

here it is !

V.

Le lundi 30 novembre 2015 à 15:08 -0500, Vaclav Petras a écrit :
> 
> On Mon, Nov 30, 2015 at 2:26 PM, Vincent Bain  wrote:
> 
> attached is an archive containing files I hope you need ("vf"
> for
> vectorized fonts).
> 
> 
> Thanks! This is exactly what I need now. Well, actually what I need
> right now is a cropped PDF, so no page and no borders (file attached,
> done with pdfcrop).
> 



logo_variant_vf.pdf
Description: Adobe PDF document
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [OSGeo-Discuss] Call For papers Geospatial devroom @FOSDEM 2016

[Margherita Di Leo]

Hi All,

this is a gentle reminder that the deadline for talk proposals is tomorrow,
**1st December 2015**.
Looking forward to see your contributions.

Thank you and best regards,


On Mon, Nov 2, 2015 at 8:22 AM, Johan Van de Wauw  wrote:

> Please forward!
>
> FOSDEM is a free and non-commercial event bringing together about 5000
> developers in Brussels, Belgium. The goal is to provide open source
> software developers and communities a place to meet and share
> thoughts. The participation is free of charge, although donations are
> welcome. The next edition will take place the last weekend ofJanuary
> 30 - 31 2016. This year for the second time there will be a Geospatial
> devroomon Sunday 31/1/2016, organised by members of the OSGeo,
> Locationtech and OpenStreetMap communities.
>
> Geospatial technology is becoming rapidly mainstream. The idea
> underpinning the geospatial devroom is bringing together developers
> with different backgrounds to disclosethe opportunities offered by
> cutting-edge open source geospatial technologies. Due to the success
> of last years devroom, a Belgium local chapter of OSGeo, OSGeo.be was
> founded, and is now taking part of the organisation of the devroom as
> driving community.
>
> The Geospatial devroom is the place to talk about the state of the art
> of open, geo-related data, free and open source geospatial software
> and its ecosystem. This includes standards and tools, e.g. spatial
> databases, online mapping tools, geospatial services, used for
> collecting, storing, delivering, analysing, and visualizing geodata.
> We welcome submissions about:
>
> * Web and desktop GIS applications
> * Interoperable geospatial web services and specifications
> * Collection of data using sensors/drones/satellites
> * Open hardware for geospatial applications
> * Geo-analytic algorithms/libraries
> * Geospatial extensions for classical databases (indexes, operations)
> and dedicated databases
> * Collaborative editing/versioning of geodata
> * Big geodata, scalable GIS applications
> * Volunteered Geograpic information - Crowdsourced data
>
> HOW TO SUBMIT YOUR PROPOSAL FOR A TALK
>
> Are you thrilled to present your work to other open source developers?
> Would you like to run a discussion? Any other ideas? Please submit
> your proposal using the Pentabarf event planning tool at:
>
> https://penta.fosdem.org/submission/FOSDEM16
>
> Make sure to select the 'Geospatial devroom' as  'Track'. Please,
> specify in the notes if you prefer for your presentation either a
> short timeslot (lightning talks ~10 minutes) or along timeslot (20
> minutes presentation + discussion). However, note that time slots are
> indicative and will be assigned according to the needs of the session.
>
> The DEADLINE for submissions is Tuesday **1st December 2015**.
> Notification of acceptance will be sent to the Authors by Friday
> 11/12/2015 at the latest.
>
> Should you have any questions, please do not hesitate to get in touch
> with the organisers of the devroom at fosdem-geospat...@gisky.be!
>
> Johan Van de Wauw
> Margherita Di Leo
> Astrid Emde
> Anne Ghisla
> Martin Hammitzsch
> Andy Petrella
> Dirk Frigne
> Olivier Courtin
> Thomas Gratier
> ___
> Discuss mailing list
> disc...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss




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

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

Well,

about the tests - generally yes, I'm writing it. Are you referring to
r3.info or to g.search.* modules?  I could not found any example to r3.info
tests

I've rewritten r3.info so that the code is the same, as r.info (with -e
flag) - but I can not tell, I'm satisfied with the result (there are line
breaks and quotes in the strings, what IMHO is really not good)

My time resources allocatable to this task are slowly reaching to their
end. I would need clear decision from you guys (since you are in charge to
mess around GRASS code base):

Where to put print_output & supporting functions?
Where to write tests for them? (I assume standard unittest package is being
used)
Can I omit g.search.data for now? (I would like to put some better code
structure, as I can see it more clear now) - so I would put only
g.search.module for now to GRASS trunk?

Thanks

Jachym

po 30. 11. 2015 v 5:10 odesílatel Vaclav Petras 
napsal:

>
> On Sun, Nov 29, 2015 at 7:06 AM, Jachym Cepicky 
> wrote:
>
>> the code is in the same repository but packed in the g.search.module
>> directory now, not sure, if the g.extension will work again
>
>
> g.extension supports only directories which have Makefile, i.e. Makefile
> must be in the root directory of the repository. See r.modis (it might be
> more complicated then you need):
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.modis
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.green
>
> On Sun, Nov 29, 2015 at 4:06 PM, Jachym Cepicky 
> wrote:
>
>> I've patched r3.info a bit (not sure, whether it's ok)
>> https://trac.osgeo.org/grass/changeset/66983/ for potential better
>> g.search.data output
>>
>
> Not really looked to the source code but with the commands:
>
> r3.mapcalc "test1 = rand(0, 1)" -s
> r3.flow in=test1 flowaccumulation=test2
> r3.info test2 -gh
>
> I get:
>
> ...
> description="generated by r3.flow"
> comments_0=comments_1=""
>
> (comments at the same row)
>
> BTW, have you considered writing a test? :)
>
> On Sun, Nov 29, 2015 at 4:06 PM, Jachym Cepicky 
> wrote:
>
>>
>> i would like to move colorize, print_results from g.search.module to some
>> reachable place within existing grass python code base - any hint?
>>
>
> There are three options, not sure now what is better:
>
> grass.script.utils (scripting related, grass specific)
> grass.utils (more general functions, to be created)
> grass.tools (compilation, html related, to be created)
>
> We will need grass.tools at some point anyway to organize the code which
> now spreads over several files in tools and man directories.
>
> Not that you can also keep some functions in a "package directory" inside
> the addon like in r.modis but at least print_results looks like it should
> go to trunk.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev