Re: [GRASS-dev] [GRASS GIS] #2338: r.horizon rename parameters
#2338: r.horizon rename parameters -+-- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.horizon|Platform: All Cpu: All | -+-- Comment(by zarch): Replying to [comment:5 wenzeslaus]: Please read #2136 and look how many modules are using particular names. So I change: horizon = basename, ok? I wrote two functions, one that return the number of decimals in a string, and another one that return a format string given the basename, the number of digits and decimals that we want to use. I attached the code with two functions plus some tests in main() [0]. Considering that these functionalities are shared between modules I think we should put them somewhere in the GARSS C API... Where should we put them? Any ideas? Pietro [0] http://trac.osgeo.org/grass/attachment/ticket/2338/main.c -- Ticket URL: http://trac.osgeo.org/grass/ticket/2338#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2332: change r.horizon output names from angle index to angle
#2332: change r.horizon output names from angle index to angle
-+--
Reporter: zarch| Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: svn-trunk
Keywords: r.horizon|Platform: All
Cpu: All |
-+--
Comment(by zarch):
ok, the code is almost ready, this is how it behaves:
{{{
$ r.horizon elevation=elevation step=0.05 end=0.2 basename=rmvm --o
Calculating map 1 of 10 (angle 0.00, raster map rmvm_000.00)
100%
Calculating map 2 of 10 (angle 0.05, raster map rmvm_000.05)
100%
Calculating map 3 of 10 (angle 0.10, raster map rmvm_000.10)
100%
Calculating map 4 of 10 (angle 0.15, raster map rmvm_000.15)
100%
$ r.horizon elevation=elevation step=0.5 end=2 basename=rmvm --o
Calculating map 1 of 4 (angle 0.00, raster map rmvm_000.0)
100%
Calculating map 2 of 4 (angle 0.50, raster map rmvm_000.5)
100%
Calculating map 3 of 4 (angle 1.00, raster map rmvm_001.0)
100%
Calculating map 4 of 4 (angle 1.50, raster map rmvm_001.5)
100%
$ r.horizon elevation=elevation step=5 end=20 basename=rmvm --o
Calculating map 1 of 4 (angle 0.00, raster map rmvm_000)
100%
Calculating map 2 of 4 (angle 5.00, raster map rmvm_005)
100%
Calculating map 3 of 4 (angle 10.00, raster map rmvm_010)
100%
Calculating map 4 of 4 (angle 15.00, raster map rmvm_015)
100%
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2332#comment:3
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2326: Command functions in grass.script.core miss a correct error reporting
#2326: Command functions in grass.script.core miss a correct error reporting
+---
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: major | Milestone: 7.1.0
Component: Python | Version: svn-trunk
Keywords: script, exceptions |Platform: All
Cpu: Unspecified |
+---
Comment(by glynn):
Replying to [comment:6 wenzeslaus]:
Here are my suggestions for changes in `grass.script.core`.
These changes are excessive. All that is required is to check the exit
code and generate an error if it is non-zero. If the child process returns
a zero exit code, the existing behaviour should not be affected.
In particular, stderr should not be captured. It isn't limited to errors
(e.g. messages and percentages are written to stderr), and such
information should normally be sent to the terminal as its generated.
Also, checking kwargs![args] isn't useful.
In most cases, the failure to check exit codes was inherited from the
original shell script. run_command() replaces simple command execution,
read_command() replaces backticks. pipe_command() and feed_command() are
used for a GRASS command at one end of a pipeline. write_command()
replaces echo data | command.
My suggestion would be that the functions which wait for the process to
terminate (run_command, read_command, write_command) should call a
check_status() function, e.g.
{{{
def check_status(p, args, kwargs):
if p.wait() == 0:
return 0
raise CalledCommandError(p.returncode, args, kwargs)
}}}
run_command() and write_command() would replace
{{{
return p.wait()
}}}
with
{{{
return check_status(p)
}}}
This usage pattern would allow check_status() to be modified to provide
more options regarding error handling, e.g. raise an exception, call
fatal(), or just return the exit code, with the behaviour controlled by a
variable or a keyword argument.
Alternatively, we could just modify the Popen wrapper to provide a
modified .wait() method which does this automatically. This would probably
do the right thing for scripts which use start_command() etc and
subsequently call p.wait() themselves.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2326#comment:8
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows
#2333: choose python interpreter during the GRASS installation on windows --+- Reporter: zarch | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: 7.1.0 Component: Python| Version: svn-trunk Keywords: windows installer python interpreter |Platform: MSWindows 8 Cpu: All | --+- Comment(by glynn): Replying to [comment:15 martinl]: If I interpreted correctly [0], the solution should be to generate the .bat files for each GRASS module/scripts written in python, right?. no, r60679 simply broke running all commands (ie. also running exe files from python), see the traceback from the previous comment. Ugh. So without shell=True it requires an explicit .exe suffix if the program has a dot in its name. And with shell=True, it interprets characters such as |, , and I don't know what else. So, do we mimic the shell (locate the program and determine its suffix), or use it (and determine the escaping rules so that special character get passed through to the underlying program correctly)? I still don't consider the previous approach (use the shell, don't bother escaping anything) to be a viable solution. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2333#comment:19 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows
#2333: choose python interpreter during the GRASS installation on windows
--+-
Reporter: zarch | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal| Milestone: 7.1.0
Component: Python| Version: svn-trunk
Keywords: windows installer python interpreter |Platform: MSWindows 8
Cpu: All |
--+-
Comment(by martinl):
Replying to [comment:19 glynn]:
So, do we mimic the shell (locate the program and determine its suffix),
or use it (and
There was something similar installed for Python scripts (1). One option
would be to load all commands to an internal directory (similarly to
wxGUI) when loading python script library
{{{
{ 'bat': [], 'exe': ['g.parser', ...] }
}}}
rather then determining it's suffix for every command separately.
I still don't consider the previous approach (use the shell, don't
bother escaping anything) to be a viable solution.
Using `shell=True` seems to be less problematic to me, is it problem to
determine escaping rules for special characters (I know only about pipe
problem till now).
(1)
http://trac.osgeo.org/grass/changeset/60679/grass/trunk/lib/python/script/core.py
(L56)
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2333#comment:20
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2338: r.horizon rename parameters
#2338: r.horizon rename parameters -+-- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.horizon|Platform: All Cpu: All | -+-- Comment(by neteler): Replying to [comment:3 martinl]: Replying to [comment:2 hcho]: +1. I prefer prefix over output_prefix because it's shorter. Yes, prefix= like in r.texture. At least standardize it: Also keeping consistency with other modules would be nice (probably good to have standardized option for modules which produce maps with given prefix/postfix?) Yes, that should go into the parser. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2338#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2339: wxGUI.Nviz flickering
#2339: wxGUI.Nviz flickering +--- Reporter: hcho| Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: Nviz|Platform: Linux Cpu: x86-64 | +--- Comment(by neteler): I have the same flickering issue (Fedora 20, 64bit). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2339#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2338: r.horizon rename parameters
#2338: r.horizon rename parameters -+-- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.horizon|Platform: All Cpu: All | -+-- Comment(by martinl): Replying to [comment:7 neteler]: Replying to [comment:3 martinl]: Replying to [comment:2 hcho]: +1. I prefer prefix over output_prefix because it's shorter. Yes, prefix= like in r.texture. At least standardize it: Some modules are using `basename` I guess. We should standardize it before releasing 7.0... -- Ticket URL: http://trac.osgeo.org/grass/ticket/2338#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.4 planning
On Sat, Jun 14, 2014 at 3:20 PM, Markus Neteler nete...@osgeo.org wrote: On Fri, Jun 13, 2014 at 4:47 PM, Markus Neteler nete...@osgeo.org wrote: I'll try to do prepare RC1 later today or tomorrow. I have done the tagging: release_20140614_grass_6_4_4RC1 Needs improvement: http://trac.osgeo.org/grass/wiki/Release/6.4.4RC1-News ... also a volunteer is seeked who scans the updates in the post-6.4.3 ChangeLog and merges them into above trac page. Markus All the other news and CMS updates (will do later) + binary complilations need to be done, too. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2340: Rename i.landsat.rgb
#2340: Rename i.landsat.rgb ---+ Reporter: neteler| Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Imagery| Version: svn-trunk Keywords: i.landsat.rgb |Platform: All Cpu: Unspecified| ---+ Since i.landsat.rgb is not limited at all to be used with LANDSAT, the module should be renamed to a more generic name. Eg. i.rgb.balance? This should happen before the 7.0.0 release. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2340 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2341: GRASS 7.0.0. r.viewshed issue
#2341: GRASS 7.0.0. r.viewshed issue -+-- Reporter: AJWatson | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: viewshed |Platform: MSWindows 8 Cpu: Unspecified | -+-- Attempting to run r.viewshed command on 90bn cells. Grass failed to carry it out. I changed the g.region res=25 and it has worked now. It may be worth looking into. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2341 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.4 planning
Hi, 2014-06-17 19:54 GMT+02:00 Markus Neteler nete...@osgeo.org: Needs improvement: http://trac.osgeo.org/grass/wiki/Release/6.4.4RC1-News ... also a volunteer is seeked who scans the updates in the post-6.4.3 ChangeLog and merges them into above trac page. I went through svn log and tried to updated trac accordingly. Part of the log messages were very *cryptic*, PLEASE COMITTERS, TRY TO WRITE YOUR LOGS IN READABLE WAY (TO BE REUSED FOR NEWS), ie. name of module/library: description (possible trac ticket or merge commit). THANKS. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1839: Install.make should honor $DESTDIR
#1839: Install.make should honor $DESTDIR --+- Reporter: vince | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Installation | Version: svn-trunk Keywords: DESTDIR |Platform: MacOSX Cpu: OSX/Intel | --+- Comment(by annakrat): Can someone (who understands it) review the patch and apply it? I got offlist a request to apply it since it is needed for creating grass7 package for Macports. Thanks -- Ticket URL: http://trac.osgeo.org/grass/ticket/1839#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2332: change r.horizon output names from angle index to angle
#2332: change r.horizon output names from angle index to angle -+-- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Default | Version: svn-trunk Keywords: r.horizon|Platform: All Cpu: All | -+-- Comment(by annakrat): Replying to [comment:3 zarch]: ok, the code is almost ready, this is how it behaves: That looks great, the only thing I am not sure about is the end parameter which is not included. That might be confusing for the user because it's more programming approach than what users are used to. But I agree with it as far as it is mentioned in the label/description of the parameter. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2332#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2338: r.horizon rename parameters
#2338: r.horizon rename parameters -+-- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.horizon|Platform: All Cpu: All | -+-- Comment(by wenzeslaus): Replying to [comment:7 neteler]: Replying to [comment:3 martinl]: Replying to [comment:2 hcho]: +1. I prefer prefix over output_prefix because it's shorter. Yes, prefix= like in r.texture. At least standardize it: As I was saying in in #2136: I don't like prefix because it is not a prefix. In my point of view, we are suffixing the analyses name or state description to the given string. I prefer basename because it is what it is. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2338#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2332: change r.horizon output names from angle index to angle
#2332: change r.horizon output names from angle index to angle -+-- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Default | Version: svn-trunk Keywords: r.horizon|Platform: All Cpu: All | -+-- Comment(by wenzeslaus): Replying to [comment:2 zarch]: Replying to [comment:1 annakrat]: Could we set the number of digits automatically based on the number of decimal digits of the step and number of digits of the maximum angle? For example when horizon_step is 0.5 and maximum angle is 50, the maps would be named h_06.5, h_07.0, h_07.5 and so on. I don't like the dot there, though, since it's not valid for vector maps and that's a source of confusion then. I don't like either, but I don't see any better solution, do you? The only possibility I see is to replace this dot with an underscore, too: h_06_5, h_07_0, h_07_5. But the names are not so nice anymore but wouldn't use colon for hour neither (h_06:30 vs h_06_30), so maybe the underscore is actually quite good. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2332#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
