[GRASS-dev] proposal for g.search module

Jachym_Cepicky · November 27, 2015, 3:51pm

Hi all,

I’ve tried to implement command line alternative to module search based on keywords, which is available in the gui - it’s called g.search

Any chance, you might find this useful ? Any comment to the source code and outputs?

https://github.com/jachym/g.search

Jachym

wenzeslaus · November 27, 2015, 4:12pm

On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <jachym.cepicky@gmail.com>
wrote:

Hi all,

I've tried to implement command line alternative to module search based on
keywords, which is available in the gui - it's called g.search

Any chance, you might find this useful ? Any comment to the source code
and outputs?

https://github.com/jachym/g.search

I think it is awesome:

$ g.extension extension=g.search url=https://github.com/jachym/g.search
$ g.search MLC

i.gensig
Description: Generates statistics for i.maxlik from raster map.
Keywords: imagery,classification,supervised classification,Maximum
Likelihood Classification,MLC,signatures

i.maxlik
Description: Classifies the cell spectral reflectances in imagery data.
Classification is based on the spectral signature information generated by
either i.cluster, g.gui.iclass, or i.gensig.
Keywords: imagery,classification,Maximum Likelihood Classification,MLC

The code is minimalistic, so the duplication with GUI code is minimal or
none.

I suggest to put it to trunk, but to consider the name first. g.search
sounds good but does it search modules or maps or both? Are the maps a
possible extension of the current functionality?

Vaclav

Jachym_Cepicky · November 27, 2015, 11:06pm

ahoj Vašku,

not sure about the maps. wouldn’t be better to extend g.list?

about the name: g.module.search?

need to work on the output a bit more…

would -g flag be useful as well?

glad you like it

jachym

···

On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <jachym.cepicky@gmail.com> wrote:

Hi all,

I’ve tried to implement command line alternative to module search based on keywords, which is available in the gui - it’s called g.search

Any chance, you might find this useful ? Any comment to the source code and outputs?

https://github.com/jachym/g.search

I think it is awesome:

$ g.extension extension=g.search url=https://github.com/jachym/g.search
$ g.search MLC

i.gensig
Description: Generates statistics for i.maxlik from raster map.
Keywords: imagery,classification,supervised classification,Maximum Likelihood Classification,MLC,signatures

i.maxlik
Description: Classifies the cell spectral reflectances in imagery data. Classification is based on the spectral signature information generated by either i.cluster, g.gui.iclass, or i.gensig.
Keywords: imagery,classification,Maximum Likelihood Classification,MLC

The code is minimalistic, so the duplication with GUI code is minimal or none.

I suggest to put it to trunk, but to consider the name first. g.search sounds good but does it search modules or maps or both? Are the maps a possible extension of the current functionality?

Vaclav

wenzeslaus · November 28, 2015, 1:24am

On Fri, Nov 27, 2015 at 6:06 PM, Jachym Cepicky <jachym.cepicky@gmail.com>
wrote:

ahoj Vašku,

not sure about the maps. wouldn't be better to extend g.list?

Perhaps, the search could include title names as well - this would be the
extension to g.list. This makes sense as you usually know if you are
searching maps/groups/... or modules.

On the other hand, g.search could provide unified simple search interface
for searching/listing maps and modules - a simple "fulltext" search for
word. This would wrap more general g.list pattern search interface. There
is few other things we could search: Mapsets, Locations, and color tables.
But let's ignore this for now.

about the name: g.module.search?

g.search aspect
g.module.search aspect
g.search.module aspect

g.module.search sounds good. In GUI the tree and search tab is called
Search modules, renamed from ambiguous Module search. Your original
g.search is shorter and since it will be used in the command line, we
should probably keep it short. So, at the end, I would keep g.search unless
somebody is against that.

need to work on the output a bit more...

Also, keep in mind that the XML may change at one point. See explanations
in:

[GRASS-dev] wxgui_items.xml: outdated
https://lists.osgeo.org/pipermail/grass-dev/2015-October/077137.html

would -g flag be useful as well?

Certainly, although not for me now.

glad you like it

I suggest to put it to trunk as soon as you are comfortable with the code
and basic features.

jachym

On Fri, Nov 27, 2015, 17:13 Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <
jachym.cepicky@gmail.com> wrote:

Hi all,

I've tried to implement command line alternative to module search based
on keywords, which is available in the gui - it's called g.search

Any chance, you might find this useful ? Any comment to the source code
and outputs?

https://github.com/jachym/g.search

I think it is awesome:

$ g.extension extension=g.search url=https://github.com/jachym/g.search
$ g.search MLC

i.gensig
    Description: Generates statistics for i.maxlik from raster map.
    Keywords: imagery,classification,supervised classification,Maximum
Likelihood Classification,MLC,signatures

i.maxlik
    Description: Classifies the cell spectral reflectances in imagery
data. Classification is based on the spectral signature information
generated by either i.cluster, g.gui.iclass, or i.gensig.
    Keywords: imagery,classification,Maximum Likelihood Classification,MLC

The code is minimalistic, so the duplication with GUI code is minimal or
none.

I suggest to put it to trunk, but to consider the name first. g.search
sounds good but does it search modules or maps or both? Are the maps a
possible extension of the current functionality?

Vaclav

Jachym_Cepicky · November 28, 2015, 10:09am

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
…

OR and AND flag

terminal output, shell script output, json output

this starts to be pretty heavy module

···

On Fri, Nov 27, 2015 at 6:06 PM, Jachym Cepicky <jachym.cepicky@gmail.com> wrote:

ahoj Vašku,

not sure about the maps. wouldn’t be better to extend g.list?

Perhaps, the search could include title names as well - this would be the extension to g.list. This makes sense as you usually know if you are searching maps/groups/… or modules.

On the other hand, g.search could provide unified simple search interface for searching/listing maps and modules - a simple “fulltext” search for word. This would wrap more general g.list pattern search interface. There is few other things we could search: Mapsets, Locations, and color tables. But let’s ignore this for now.

about the name: g.module.search?

g.search aspect
g.module.search aspect
g.search.module aspect

g.module.search sounds good. In GUI the tree and search tab is called Search modules, renamed from ambiguous Module search. Your original g.search is shorter and since it will be used in the command line, we should probably keep it short. So, at the end, I would keep g.search unless somebody is against that.

need to work on the output a bit more…

Also, keep in mind that the XML may change at one point. See explanations in:

[GRASS-dev] wxgui_items.xml: outdated
https://lists.osgeo.org/pipermail/grass-dev/2015-October/077137.html

would -g flag be useful as well?

Certainly, although not for me now.

glad you like it

I suggest to put it to trunk as soon as you are comfortable with the code and basic features.

jachym

On Fri, Nov 27, 2015, 17:13 Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <jachym.cepicky@gmail.com> wrote:

Hi all,

I’ve tried to implement command line alternative to module search based on keywords, which is available in the gui - it’s called g.search

Any chance, you might find this useful ? Any comment to the source code and outputs?

https://github.com/jachym/g.search

I think it is awesome:

$ g.extension extension=g.search url=https://github.com/jachym/g.search
$ g.search MLC

i.gensig
Description: Generates statistics for i.maxlik from raster map.
Keywords: imagery,classification,supervised classification,Maximum Likelihood Classification,MLC,signatures

i.maxlik
Description: Classifies the cell spectral reflectances in imagery data. Classification is based on the spectral signature information generated by either i.cluster, g.gui.iclass, or i.gensig.
Keywords: imagery,classification,Maximum Likelihood Classification,MLC

The code is minimalistic, so the duplication with GUI code is minimal or none.

I suggest to put it to trunk, but to consider the name first. g.search sounds good but does it search modules or maps or both? Are the maps a possible extension of the current functionality?

Vaclav

wenzeslaus · November 28, 2015, 2:29pm

On Sat, Nov 28, 2015 at 5:09 AM, Jachym Cepicky <jachym.cepicky@gmail.com>
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
g.search.data aspect

which is longer than g.search but unlike `g.search type=module`, g.search.*
will be auto-completed. Also it is still simpler than the shortest possible
equivalent with g.list (`g.list rast p=*aspect*`).

OR and AND flag

terminal output, shell script output, json output

Yes, the default should be whatever is appropriate for the interactive use
in the command line.

Shell script is GRASS standard but I think we should support other
standards as well. For complicated output JSON is appropriate. There is
only one module AFAIK, v.what, which supports JSON output because the shell
style was just not enough. Some projects also generate lightweight markups
which is an interesting option.

https://grass.osgeo.org/grass71/manuals/v.what.html

this starts to be pretty heavy module

You are right, so perhaps the g.search.* approach is the way around it. We
can solve each case individually but we will provide consistency because
the basic syntax will be:

g.search.<type> <text>

Yann4 · November 28, 2015, 2:52pm

+1 awesomeness
+1 for trunk

On 27/11/2015 17:12, Vaclav Petras wrote:

On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <jachym.cepicky@gmail.com>
wrote:

Hi all,

I've tried to implement command line alternative to module search based on
keywords, which is available in the gui - it's called g.search

Any chance, you might find this useful ? Any comment to the source code
and outputs?

https://github.com/jachym/g.search

I think it is awesome:

$ g.extension extension=g.search url=https://github.com/jachym/g.search
$ g.search MLC

i.gensig
     Description: Generates statistics for i.maxlik from raster map.
     Keywords: imagery,classification,supervised classification,Maximum
Likelihood Classification,MLC,signatures

i.maxlik
     Description: Classifies the cell spectral reflectances in imagery data.
Classification is based on the spectral signature information generated by
either i.cluster, g.gui.iclass, or i.gensig.
     Keywords: imagery,classification,Maximum Likelihood Classification,MLC

The code is minimalistic, so the duplication with GUI code is minimal or
none.

I suggest to put it to trunk, but to consider the name first. g.search
sounds good but does it search modules or maps or both? Are the maps a
possible extension of the current functionality?

Vaclav

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

--
-----
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

Jachym_Cepicky · November 28, 2015, 4:27pm

OK guys,

if nobody protests, I’ll prepare basic framework for g.search.* modules and let you know, once it’s about to be ready

Jachym

so 28. 11. 2015 v 15:52 odesílatel Yann <ychemin@gmail.com> napsal:

+1 awesomeness
+1 for trunk

On 27/11/2015 17:12, Vaclav Petras wrote:

On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <jachym.cepicky@gmail.com>
wrote:

Hi all,

I’ve tried to implement command line alternative to module search based on
keywords, which is available in the gui - it’s called g.search

Any chance, you might find this useful ? Any comment to the source code
and outputs?

https://github.com/jachym/g.search

I think it is awesome:

$ g.extension extension=g.search url=https://github.com/jachym/g.search
$ g.search MLC

i.gensig
Description: Generates statistics for i.maxlik from raster map.
Keywords: imagery,classification,supervised classification,Maximum
Likelihood Classification,MLC,signatures

i.maxlik
Description: Classifies the cell spectral reflectances in imagery data.
Classification is based on the spectral signature information generated by
either i.cluster, g.gui.iclass, or i.gensig.
Keywords: imagery,classification,Maximum Likelihood Classification,MLC

The code is minimalistic, so the duplication with GUI code is minimal or
none.

I suggest to put it to trunk, but to consider the name first. g.search
sounds good but does it search modules or maps or both? Are the maps a
possible extension of the current functionality?

Vaclav

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

–

Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

martinl · November 28, 2015, 4:34pm

Hi Jachym,

2015-11-28 17:27 GMT+01:00 Jachym Cepicky <jachym.cepicky@gmail.com>:

if nobody protests, I'll prepare basic framework for g.search.* modules and
let you know, once it's about to be ready

absolutely cool, thanks for your work! Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

neteler · November 28, 2015, 11:04pm

Hi Jachym,

On Fri, Nov 27, 2015 at 4:51 PM, Jachym Cepicky
<jachym.cepicky@gmail.com> wrote:

Hi all,

I've tried to implement command line alternative to module search based on
keywords, which is available in the gui - it's called g.search

GRASS 7.1.svn (nc_spm_08_grass7):~ > g.extension g.search
url=https://github.com/jachym/g.search
Fetching <g.search> from
<https://github.com/jachym/g.search/archive/master.zip> (be patient)...
Compiling...
Installing...
Installation of <g.search> successfully finished

GRASS 7.1.svn (nc_spm_08_grass7):~ > g.search watershed

r.watershed
Description: Calculates hydrological parameters and RUSLE factors.
Keywords: raster,hydrology,watershed

r.water.outlet
Description: Creates watershed basins from a drainage direction map.
Keywords: raster,hydrology,watershed

r.basins.fill
Description: Generates watershed subbasins raster map.
Keywords: raster,hydrology,watershed

So cool!!! Thank you,

Markus

lucadelu · November 29, 2015, 12:19am

On 29 November 2015 at 00:04, Markus Neteler <neteler@osgeo.org> wrote:

Hi Jachym,

Hi Jachym,

So cool!!! Thank you,

+1, really cool

Markus

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Jachym_Cepicky · November 29, 2015, 12:06pm

Guys,

I would like to declare g.search.module “done” - I’ve introduced some more functions (reusable for other g.search.* modules), colorized terminal output (-c), shell script (-g) and json (-j) output, added sniffing in manual pages too (-m), better terminal output (line width <= 79 characters)

please let me know, how you feel about it

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

thanks for feedback

jachym

ne 29. 11. 2015 v 1:19 odesílatel Luca Delucchi <lucadeluge@gmail.com> napsal:

On 29 November 2015 at 00:04, Markus Neteler <neteler@osgeo.org> wrote:

Hi Jachym,

Hi Jachym,

So cool!!! Thank you,

+1, really cool

Markus

–
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Jachym_Cepicky · November 29, 2015, 9:06pm

Guys,

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

i would like to move colorize, print_results from g.search.module to some reachable place within existing grass python code base - any hint?

Jachym

ne 29. 11. 2015 v 13:06 odesílatel Jachym Cepicky <jachym.cepicky@gmail.com> napsal:

Guys,

I would like to declare g.search.module “done” - I’ve introduced some more functions (reusable for other g.search.* modules), colorized terminal output (-c), shell script (-g) and json (-j) output, added sniffing in manual pages too (-m), better terminal output (line width <= 79 characters)

please let me know, how you feel about it

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

thanks for feedback

jachym

ne 29. 11. 2015 v 1:19 odesílatel Luca Delucchi <lucadeluge@gmail.com> napsal:

On 29 November 2015 at 00:04, Markus Neteler <neteler@osgeo.org> wrote:

Hi Jachym,

Hi Jachym,

So cool!!! Thank you,

+1, really cool

Markus

–
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

wenzeslaus · November 30, 2015, 4:10am

On Sun, Nov 29, 2015 at 7:06 AM, Jachym Cepicky <jachym.cepicky@gmail.com>
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 <jachym.cepicky@gmail.com>
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 <jachym.cepicky@gmail.com>
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.

Jachym_Cepicky · November 30, 2015, 8:27am

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 <wenzeslaus@gmail.com> napsal:

···

On Sun, Nov 29, 2015 at 7:06 AM, Jachym Cepicky <jachym.cepicky@gmail.com> 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 <jachym.cepicky@gmail.com> 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 <jachym.cepicky@gmail.com> 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.

wenzeslaus · November 30, 2015, 3:18pm

On Mon, Nov 30, 2015 at 3:27 AM, Jachym Cepicky <jachym.cepicky@gmail.com>
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.

Jachym_Cepicky · November 30, 2015, 9:12pm

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 <wenzeslaus@gmail.com> napsal:

···

On Mon, Nov 30, 2015 at 3:27 AM, Jachym Cepicky <jachym.cepicky@gmail.com> 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.

neteler · November 30, 2015, 9:22pm

Hi

On Sat, Nov 28, 2015 at 3:29 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Sat, Nov 28, 2015 at 5:09 AM, Jachym Cepicky <jachym.cepicky@gmail.com>
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

wenzeslaus · November 30, 2015, 9:31pm

On Mon, Nov 30, 2015 at 4:12 PM, Jachym Cepicky <jachym.cepicky@gmail.com>
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 `<standard input>', 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.

wenzeslaus · November 30, 2015, 9:33pm

On Mon, Nov 30, 2015 at 4:22 PM, Markus Neteler <neteler@osgeo.org> 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.