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 <[email protected]> napsal: > > On Sun, Nov 29, 2015 at 7:06 AM, Jachym Cepicky <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
