[GRASS-dev] [GRASS GIS] #2327: r.diversity = Illegal areas disposition
#2327: r.diversity = Illegal areas disposition -+-- Reporter: sands| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Raster | Version: svn-trunk Keywords: r.diversity |Platform: MSWindows 7 Cpu: x86-64 | -+-- When running r.diversity in GRASS GIS 7.1svn [60382] on Windows 7 64 (but with Python 2.7 win32) I get ERROR: Illegal areas disposition With Helmut Kudrnovsky's help, I commented out lines 147-149 and 272-275 in r.diversity.py to keep the conf file and check it's contents, which appear fine: conf_diversity_3.0: SAMPLINGFRAME 0|0|1|1 SAMPLEAREA -1|-1|0.00631578947368|0.00569259962049 MOVINGWINDOW I would appreciate any suggestions on what the error could be. # CODE: Using nc_spm_08_grass7 g.gisenv set=DEBUG=1 g.region rast=lsat5_1987_10@landsat r.diversity --verbose input=lsat7_2002_10@PERMANENT prefix=t method=simpson,pielou Results: D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: grass.script.core.start_command(): r.li.simpson input=lsat7_2002_10@PERMANENT conf=conf_diversity_3.0 output=t_simpson_size_3.0 D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster(): name=MASK mapset=landsat D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: r.li.daemon pathSetup: [C:\Users\Sands\AppData\Roa ming\GRASS7\r.li\conf_diversity_3.0] ERROR: Illegal areas disposition D1/1: grass.script.core.start_command(): r.li.pielou input=lsat7_2002_10@PERMANENT conf=conf_diversity_3.0 output=t_pielou_size_3.0 D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster2(): name=lsat7_2002_10 mapset=PERMANENT D1/1: G_find_raster(): name=MASK mapset=landsat D1/1: G_find_raster2(): name=lsat7_2002_10@PERMANENT mapset= D1/1: r.li.daemon pathSetup: [C:\Users\Sands\AppData\Roa ming\GRASS7\r.li\conf_diversity_3.0] ERROR: Illegal areas disposition (Fri Jun 06 07:24:02 2014) Command finished (0 sec) -- Ticket URL: http://trac.osgeo.org/grass/ticket/2327 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-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste
Huidae Cho wrote: I was thinking about the same thing. Maybe add char *exclusive_group to Option and Flag and G_parser() takes care of exclusiveness? There are two relatively straightforward cases for option interdependencies: 1. At most one option from a set may be provided (mutual exclusivity). 2. At least one option from a set must be provided (more general form of the -required field). Both of these requirements may apply, i.e. exactly one option from a set must be provided. But there may still be cases where that isn't sufficient, and you'd need generalised boolean expressions. E.g. Where you need either A or both of B and C. Or if you use A then B is required, otherwise it's invalid. It would be a fairly simple matter to add a function to evaluate a boolean expression supplied by the module. But that wouldn't be much help either to the GUI (which ideally would use the interdependency information to e.g. grey out invalid options) or for generating error messages (we want something more informative than that combination of options isn't valid). So, in the first instance I'd suggest adding: // at most one option from a set void G_option_exclusive(const char *opt, ...); // at least one option from a set void G_option_required(const char *opt, ...); // if the first option is present, at least one of the other // options must also be present void G_option_requires(const char *opt, ...); All functions take a NULL-terminated list of option/flag names (leading - indicates a flag). The argument-checking code would be migrated to the new functions. Any cases which still cannot be expressed would be reported to the list for further consideration. Once we've either covered all of the cases or concluding that any remaining cases cannot reasonably be incorporated into any general framework, we can work on exporting this information via --interface-description etc. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On 05/06/14 21:14, Martin Landa wrote: Hi, 2014-06-05 17:36 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: consensus is somehow courageous to say, bearing in mind that Glynn simply reverts any other solution regardless that it breaks the whole GRASS on Windows (try to install 7.1, completely useless, even no answer, break is just OK). Well, someone need to implement it, even some of us are not probably happy about that, we need to take care about user scripts and so on. It's somehow funny, because 7.0 simply works (same was for 7.1 some days ago). Have you looked at the reason for Glynn's revert ? Do you have a better suggestion to solve the problem at hand ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Markus Neteler wrote: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. 2. If we know that the program is a script, the interpreter can be specified explicitly (i.e. python path/to/script.py). This keeps the shell out of the picture. ... how much effort is the latter? Check file type and path to file? No. The latter involves the caller knowing that it's invoking a script and explcitly invoking it via the interpreter. Attempting to determine this within the library is problematic, as we would need to mimic the mechanisms which the platform uses for invoking scripts. E.g. * If the program argument isn't a full path, we need to scan %PATH% for it. * If it lacks an extension, we also need to scan %PATHEXT%. * There's also the question of whether such treatment should be applied for any script, or just those which are part of GRASS. Using batch files has the advantage that we can just execute the command without worrying about any of this. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Enhancement request: print name(s) of generated map(s) upon completion
On 05/06/14 22:38, Markus Neteler wrote: On Thu, Jun 5, 2014 at 9:28 PM, Rashad M mohammedrasha...@gmail.com wrote: Hi, I would like to add a +1 to Mortiz here. This enhancement should be in the verbose. Like there are debug level for message. These message can be like level in verbose. say --verbose=1 I would suggest to do the opposite. Since percentage output is there, it would be helpful to - vector: put e.g. most of the many topology related messages (v.clean, v.in.ogr) into verbose, - raster: do the same for candidates like r.watershed, many messages... == But then tell the user what has been produced! The point is: if you run stuff on command line/in batch jobs, you want to know the outcome, not how many tiny interim steps have been done. Sure I can scroll back but GRASS could also simply tell me. I agree with you on the suggestion to output less of the topological info. I'm still not convinced by the need for printing the names of maps that are created. Just my 0.02 cents (from my teaching experience with GIS experts but GRASS newbies), Same here :-) Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Martin Landa wrote: ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. I had the feeling that this was the consensus (or at least with lack of clear dissension) we had reached: consensus is somehow courageous to say, bearing in mind that Glynn simply reverts any other solution regardless that it breaks the whole GRASS on Windows The reason I do this is because GRASS has a long history of dealing with bugs using ugly hacks, which typically introduce equal-but-opposite bugs. This then means that any attempt to fix the underlying bug breaks everything. It also results in incomplete fixes, which are then fixed further by adding yet more code, with each iteration getting progressively uglier due to interactions with earlier layers. If something doesn't actually work, I'd rather everyone be aware of that and try to find an actual solution, rather than just papering over the cracks and pretending that the issue has been solved. E.g. if run_command() has problems with using a vertical bar character in an argument, modifying specific cases to avoid using a vertical bar doesn't fix the actual problem. Removing the shell from the equation fixes the actual problem (and possibly other problems related to the shell, e.g. ANSI-vs-OEM codepage issues). Escaping arguments should fix that specific problem (but not others), provided that we can accurately determine the shell's rules (Good Luck With That; the bash manual runs to ~82 pages; I've never seen anything like that for cmd.exe). -- Glynn Clements gl...@gclements.plus.com ___ 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: normal | Milestone: 7.1.0 Component: Python | Version: svn-trunk Keywords: script |Platform: All Cpu: Unspecified | -+-- Comment(by glynn): Replying to [ticket:2326 wenzeslaus]: The later is actually a motivation for this ticket because I see this as a critical issue which is very dangerous for [https://gis.stackexchange.com/questions/99773/problems-running-grass- mapcalc/ beginners] (writing scripts with `run_command` or others) and not checking the return code or stderr with an expectation that the function will report the error (in Python sense, thus raising an exception). Personally, I'd suggest just modifying the existing functions to raise exceptions if the command fails. Scripts which want to do their own error handling can just use start_command() directly; the higher-level functions are only trivial wrappers around this. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2326#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] #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: normal | Milestone: 7.1.0
Component: Python | Version: svn-trunk
Keywords: script |Platform: All
Cpu: Unspecified |
-+--
Comment(by zarch):
Replying to [ticket:2326 wenzeslaus]:
Also, I'm not sure what is the PyGRASS's answer to this problem.
[[BR]]
At the moment in the Module class the returncode is not checked at all.
{{{
#!python
from subprocess import PIPE
from grass.pygrass.modules import Module
greg = Module('g.region', flags='p', rast='ELEV', stdout_=PIPE,
stderr_=PIPE)
greg.popen.returncode
1
greg.outputs.stderr
'ERROR: Raster map ELEV not found\n'
}}}
[[BR]]
I can modify the Module class behaviour changing the default parameters
for stdout_ and stderr_ to PIPE (at the moment are None), and raise a
RuntimeError if the returncode is not 0.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2326#comment:2
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-SVN] r60713 - in grass/trunk: include lib/gis
Author: hcho Date: 2014-06-05 10:32:48 -0700 (Thu, 05 Jun 2014) New Revision: 60713 Modified: grass/trunk/include/gis.h grass/trunk/lib/gis/parser.c Log: The exclusive member of the Option and Flag structures is a comma-separated string. Whitespaces are not ignored. Each name separated by comma can be used to group options/flags together, make them mutually exclusive, or make one of them conditionally required. Reverted. This issue warrants an actual discussion. A discussion which I've been trying to have for *years*. -- Glynn Clements gl...@gclements.plus.com ___ 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: normal | Milestone: 7.1.0 Component: Python | Version: svn-trunk Keywords: script |Platform: All Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:2 zarch]: I can modify the Module class behaviour changing the default parameters for stdout_ and stderr_ to PIPE That's probably unwise. It would force the caller to either explicitly set them to None or to consume the output, e.g. via the .communicate() method. I wouldn't be surprised if many scripts do neither; the result being that the call works fine unless it writes more than a buffer's worth of output, in which case it will just hang. I also wouldn't be surprised if scripts try to re-implement logic similar to .communicate() but get it wrong. You need to use either threads or non- blocking I/O. If you perform a blocking read on either pipe and more than a buffer's worth of data is written to the other pipe, you get deadlock (i.e. the script hangs). Also, when both stdout and stderr are associated with different pipes, it's impossible to reconstruct the normal output because there's no way to determine the relative order. Meaning that you can't e.g. associate an error message with any particular line of progress output. This is why the support for stdout=PIPE, stderr=STDOUT exists. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2326#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: normal | Milestone: 7.1.0
Component: Python | Version: svn-trunk
Keywords: script |Platform: All
Cpu: Unspecified |
-+--
Comment(by glynn):
Replying to [ticket:2326 wenzeslaus]:
I missed this issue in my previous reply:
{{{
proc.stdin.write(proj_in)
proc.stdin.close()
proc.stdin = None
proj_out, errors = proc.communicate()
}}}
You need to use
{{{
proj_out, errors = proc.communicate(proj_in)
}}}
If you try to .write() the data to stdin, and the child process prints
progress/error/etc messages as it processes the input, you'll get deadlock
if the amount of data written to either pipe exceeds the amount which will
fit in the pipe's buffer.
The .communicate() method uses either non-blocking I/O (Unix) or threads
(Windows) in order to consume output as it becomes available, rather than
waiting until all data has been written to stdin and hoping that the
pipe's buffer can contain everything written to stdout/stderr in the
meantime.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2326#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-SVN] r60713 - in grass/trunk: include lib/gis
2014-06-06 9:52 GMT+02:00 Glynn Clements gl...@gclements.plus.com: Reverted. This issue warrants an actual discussion. A discussion which I've been trying to have for *years*. cool Glynn! Please could you provide your solution at least or you will just continue reverting other people work in the better case or breaking the whole software in the worse case. Your behaviour is starting to be absolutely *unaccepteble* for me!!! You behave like a king with absolute power, funny... 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-SVN] r60713 - in grass/trunk: include lib/gis
2014-06-06 12:52 GMT+02:00 Martin Landa landa.mar...@gmail.com: 2014-06-06 9:52 GMT+02:00 Glynn Clements gl...@gclements.plus.com: This issue warrants an actual discussion. A discussion which I've been trying to have for *years*. I remember some mails at ML some years ago, but without any *real* outcome (wiki page, see for RFC's from GDAL project). Simply *nothing* happen during the last years. And BTW, you are almost never discussing your implementations on ML, you just commit it without no discussion. Same with your reverts. No discussion. So from this POV your explanation for the revert is somehow weak. 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] #2258: t.create creates DB always in the PERMANENT
#2258: t.create creates DB always in the PERMANENT -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Temporal | Version: svn-releasebranch70 Keywords: t.register |Platform: Unspecified Cpu: Unspecified | -+-- Changes (by neteler): * version: unspecified = svn-releasebranch70 Comment: Replying to [comment:5 huhabla]: Replying to [comment:4 glynn]: Replying to [comment:3 huhabla]: There is a reason why the temporal database is generated and used by default in the PERMANENT directory. Does it handle the case where the user lacks the filesystem permissions to write to PERMANENT? There is no explicit error handling implemented. The creation process will terminate with a Python exception. Here in our shared /network and multi-user grassdata/ we have exactly this problem: while I am the PERMANENT owner, my colleague cannot write into the DB. As a compromise, t.create should advertise t.connnect as a solution to the problem, otherwise users get immediately stuck. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2258#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-SVN] r60713 - in grass/trunk: include lib/gis
All, I can feel strong frictions between Glynn and some of us. I was shocked when Glynn simply broke 7.1 on Windows. From my experience, I can see that he is more of a purist and doesn't like workarounds and hacks. I totally understand his points, but just because there is an issue doesn't make it any more acceptable to break other people's solutions that have been proved to work for a long time, *without* providing his own better solution. I don't mind any existing code being replaced by more correct solutions, but simply reverting it and breaking the whole system is not acceptable at all. I think that the whole system *should* always be in a working condition no matter what magic was used in the code. If that magic is hackery, dirty or whatever, it has to be *fixed*, not just removed. If he submitted a part of his solution in the middle, it's not acceptable again because he should have submitted a whole solution to make sure the system is at least not worse than before. Now, regarding my exclusive hack or implementations without any discussion, first, I apologize for not discussing this issue before submitting my implementations. Putting aside who's right and who's wrong, it's very frustrating and demotivating to see hours of effort is gone in seconds of typing with no better solutions coming in. As Martin said, I saw a lot of core implementations from Glynn without clear discussions and he often insists that he's right and he even said that he would revert any changes he doesn't like. Looks like, any core changes have to be approved by Glynn after serious discussions with him? He may be one of the best developers in the team, but does it give him exclusive rights to revert or break things with no solutions? I don't know. Maybe, I was just simply wrong because I didn't have any discussion before submitting the exclusive implementations and don't have rights to complain about the revert. Now, I'm not sure what to discuss and what not to. I even posted a couple of messages calling for a discussion, but they got no attention at all. This kind of experience just demotivates and pushes me away from real implementations and keeps me fixing small bugs and typos here and there. Last, I have a strong feeling that we really need defined procedures that we can follow when making changes to the core and even individual modules. Otherwise, this same situation will arise again and again. Best, Huidae ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60713 - in grass/trunk: include lib/gis
Hi, just to add my 2 cent: 2014-06-06 16:35 GMT+02:00 Huidae Cho gras...@gmail.com: All, I can feel strong frictions between Glynn and some of us. I was shocked when Glynn simply broke 7.1 on Windows. From my experience, I can see that he is more of a purist and doesn't like workarounds and hacks. I totally IMHO that has nothing to do with purism or with liking or not liking workarounds and hacks. It is a decision made on common sense to keep complex code bases maintainable. understand his points, but just because there is an issue doesn't make it any more acceptable to break other people's solutions that have been proved to work for a long time, *without* providing his own better solution. I don't mind any existing code being replaced by more correct solutions, but simply reverting it and breaking the whole system is not acceptable at all. Actually, hacks and workarounds shouldn't be committed in the first place if the problem isn't fully understand. Usually the workaround/hack will be accepted as a working solution (if it works for several people) and nobody will try again to implement a reasonable solution that actually fix the problem. The danger is that such an approach leads to new errors that are even more difficult to fix and nobody is aware anymore what the root of the problem was. So the pragmatic solution is: Don't allow workarounds/hacks even if it breaks the software to force developers to implement reasonable solutions. I think that the whole system *should* always be in a working condition no matter what magic was used in the code. If that magic is hackery, dirty or whatever, it has to be *fixed*, not just removed. If he submitted a part of his solution in the middle, it's not acceptable again because he should have submitted a whole solution to make sure the system is at least not worse than before. Now, regarding my exclusive hack or implementations without any discussion, first, I apologize for not discussing this issue before submitting my implementations. Putting aside who's right and who's wrong, it's very frustrating and demotivating to see hours of effort is gone in seconds of typing with no better solutions coming in. As Martin said, I saw a lot of core implementations from Glynn without clear discussions and he often insists that he's right and he even said that he would revert any changes he doesn't like. Looks like, any core changes have to be approved by Glynn after serious discussions with him? He may be one of the best developers in the team, but does it give him exclusive rights to revert or break things with no solutions? I don't know. Why should Glynn provide always a solution when he tries to keep the GRASS code in libgis and libraster in a maintainable state by reverting bad solutions? You can see it as a hint to provide a better solution. It is sometimes quite undiplomatic to revert changes by simply stating this doesn't solve the problem. But the correct approach to apply changes would be to commit a change request in trac wiki so that the changes/patches/code can be discussed in the first place. I hope that all of us will consider this approach. However, since i am the lead developer of the temporal framework i will not discuss all changes that i will make in the core of the framework. Simply because i am (hopefully) aware of what i am doing and i am the conceptual mind behind it, feeling fully responsible for it. I will not do this with any other part of GRASS (except temporal modules and maybe the gpde and voxel libraries, since i feel responsibility for them as well). I think the same is true for Glynn and many other developers. I guess that Martin Landa and Markus Metz will revert any hack/workaround that i will implement in the vector library without discussion if they see that my code is a bad solution (at least i hope they will do it). Well i can say in this case If you don't agree to my solution then provide a better one but here i miss the point that i actually don't understand what i was doing wrong. Maybe, I was just simply wrong because I didn't have any discussion before submitting the exclusive implementations and don't have rights to complain about the revert. Now, I'm not sure what to discuss and what not to. I even posted a couple of messages calling for a discussion, but they got no attention at all. This kind of experience just demotivates and pushes me away from real implementations and keeps me fixing small bugs and typos here and there. I think this is the usual friction in open source software development. Please don't feel demotivated, working with people together from different parts of the world with different cultural backgrounds is always challenging. It is sometimes hard to fully understand the motivation/opinion of each other. But it think the GRASS developers are doing very well, i didn't saw here real flame wars that are common in other open source projects (Linux Kernel ...). Everyone is in
Re: [GRASS-dev] [GRASS-SVN] r60713 - in grass/trunk: include lib/gis
Martin Landa wrote: This issue warrants an actual discussion. A discussion which I've been trying to have for *years*. I remember some mails at ML some years ago, but without any *real* outcome (wiki page, see for RFC's from GDAL project). Simply *nothing* happen during the last years. And BTW, you are almost never discussing your implementations on ML, you just commit it without no discussion. Implementation doesn't require discussion. Either it works or it doesn't; no-one cares how. Interface requires discussion. The design will affect anyone wanting to write a module. It will affect whoever deals with the GUI side of it (which isn't me). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist list multiple types from all mapsets
On Tue, Jun 3, 2014 at 3:43 AM, Huidae Cho gras...@gmail.com wrote: I tested g.mlist with the attached script. I started from test_g_list.py and replaced g.list with g.mlist -p and g.list -f with g.mlist -f. g.mlist passed the test, which means g.list == g.mlist -p g.list -f == g.mlist -f. More tests needed. g.mlist does not complain about not existing mapset: $ g.mlist pattern=lsat* type=rast mapset=xx [no output] $ echo $? 0 By the way, is multiple for mapset a planned feature? Or it is too much? Pattern for mapset seems too much for sure. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60713 - in grass/trunk: include lib/gis
Huidae Cho wrote: I can feel strong frictions between Glynn and some of us. I was shocked when Glynn simply broke 7.1 on Windows. From my experience, I can see that he is more of a purist and doesn't like workarounds and hacks. I totally understand his points, but just because there is an issue doesn't make it any more acceptable to break other people's solutions that have been proved to work for a long time, *without* providing his own better solution. I don't mind any existing code being replaced by more correct solutions, but simply reverting it and breaking the whole system is not acceptable at all. I think that the whole system *should* always be in a working condition no matter what magic was used in the code. If that magic is hackery, dirty or whatever, it has to be *fixed*, not just removed. If he submitted a part of his solution in the middle, it's not acceptable again because he should have submitted a whole solution to make sure the system is at least not worse than before. Sometimes that's not possible. Sometimes the job cannot be done by any one person. So if no-one is allowed to start anything they can't finish single-handedly, such issues will never be solved. Now, regarding my exclusive hack or implementations without any discussion, first, I apologize for not discussing this issue before submitting my implementations. Putting aside who's right and who's wrong, it's very frustrating and demotivating to see hours of effort is gone in seconds of typing with no better solutions coming in. I outlined a possible solution as soon as I read your message. What are your objections to it? [I'm being facetious. Partly. I'm aware that the change had already been done before my message was posted. But the point about appearing to start a discussion then not waiting for a reply (or even following up in the thread to state that somehting had been done) is serious.] As Martin said, I saw a lot of core implementations from Glynn without clear discussions and he often insists that he's right and he even said that he would revert any changes he doesn't like. Looks like, any core changes have to be approved by Glynn after serious discussions with him? He may be one of the best developers in the team, but does it give him exclusive rights to revert or break things with no solutions? I don't know. It's hard to address your comments without seeing any specifics. But AFAICT, there are two issues here. 1. I've made major structural changes (e.g. display re-write) which weren't discussed in detail (because that would have taken decades and I'm not assuming that I'll live to 100). But the broad outline was discussed long before any changes started. 2. When I've said if you do X, I'll revert it, it's for a reason, and I'm always willing to discuss the issue. Usually, such a position is a desperate response to someone a) stating (or, more likely, implying) that they're going to make an ill-advised change and b) trying to avoid discussing the merits of it (in fact, the change or threat of change is often seems like an attempt to forestall discussion). It may come across as being dictatorial, but that's more psychology than fact. Trying to evade discussion by imposing something as a /fait accompli/ is actually rather more dictatorial. By coming straight out and saying I'll revert that, I'm just telling them not to expect the screw discussion, make facts on the ground approach to work. Even if it means looking like the bad guy. Note: I don't consider the change being discussed here to be an instance of that. I think that it was just an unfortunate coincidence of Huidae being impatient and me not having the time to read my list mail that day. This has been up for discussion for years, and a few more days wouldn't have hurt. Maybe, I was just simply wrong because I didn't have any discussion before submitting the exclusive implementations and don't have rights to complain about the revert. Now, I'm not sure what to discuss and what not to. I even posted a couple of messages calling for a discussion, but they got no attention at all. This kind of experience just demotivates and pushes me away from real implementations and keeps me fixing small bugs and typos here and there. Last, I have a strong feeling that we really need defined procedures that we can follow when making changes to the core and even individual modules. Otherwise, this same situation will arise again and again. We don't need defined procedures (if we do need them, we're screwed, because they aren't likely to happen). But if there's a realistic prospect that other people might have different ideas, at least try to get it discussed first (and don't assume that people are scanning the list 24/7; we live in different time zones, and some of us might occassionally miss a whole day). That might sound hypocritical in light of ... recent events regarding the scripts-on-Windows issue. But that issue had actually
Re: [GRASS-dev] GRASS 7.0beta3 planning
On Sun, May 25, 2014 at 11:23 PM, Markus Neteler nete...@osgeo.org wrote: Hi, as Martin stated in a recent ticket comment, beta3 should be released asap. I would like to get first the pygrass changes backported (not difficult including the manual improvements). Maybe we skip the pygrass sphinx docs for RC3? ... the OSGeoLive feature freeze for the FOSS4G Portland conf is upcoming. But other pygrass fixes should be backported. Markus ___ 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 Thu, Jun 5, 2014 at 5:47 PM, Moritz Lennert moritz.lenn...@ulb.ac.be wrote: ... As I've already told Markus off-list, I think that in order for this to work we would need a clearly defined release-process with clear announcements of the different steps (pre-freeze warning sufficiently early, freeze announcement, pre-tag announcement, etc) and a strict respect of the rules during this process (i.e. no non bugfix commits during a freeze), etc. It doesn't seem to happen. Please note ... the OSGeoLive feature freeze for the FOSS4G Portland conf is upcoming. Would be a pity to not even see 6.4.4 therein! I'm not convinced that a time-based release-policy is the solution, but I think a more clearly defined release-process policy might help in avoiding frustrations. So let's see then... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7.0beta3 planning
On Fri, Jun 6, 2014 at 3:41 PM, Markus Neteler nete...@osgeo.org wrote: Maybe we skip the pygrass sphinx docs for RC3? Anyway we mostly focus on the online documentation being up to date, right? ... the OSGeoLive feature freeze for the FOSS4G Portland conf is upcoming. This would be nice. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Week 3: GRASS GIS 3D flowlines
Hi all, 1. What did you get done this week: I have a prototype generating flowlines, I tested it so far on artificial data. More on the wiki [1]. The code is here [2]. 2. What do you plan on doing next week? I would like to test it on different data and implement 3D flow accumulation. 3. Are you blocked on anything? No. [1] http://trac.osgeo.org/grass/wiki/GSoC/2014/ImplementationOf3DRasterFlowLine [2] http://trac.osgeo.org/grass/browser/sandbox/annakrat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] gsoc2014 grass metadata week 3
Hi all, Below is my weekly report: *Work done* Consulted design of metadata editor with mentors. Consulted current implementation of v.info.iso and r.info.iso Search for alternatives to Jinja templates (current implementation) Learned basics of wxPython *Work to be done in the next week* For 18 of Jun I have to study thoroughly for bachelor exam (proposed in timeline). We came up with a plan for next week: - after update of r.info module to adapt current code, - to polish and to comment code of v.info.so and r.info.iso, - to publish modules v.info.iso and r.info.iso to GRASS addons, - to present on wiki page the design of GUI editor for open discussion. *blocks* no ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2258: t.create creates DB always in the PERMANENT
#2258: t.create creates DB always in the PERMANENT -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Temporal | Version: svn-releasebranch70 Keywords: t.register |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by huhabla): Replying to [comment:7 neteler]: Replying to [comment:5 huhabla]: Replying to [comment:4 glynn]: Replying to [comment:3 huhabla]: There is a reason why the temporal database is generated and used by default in the PERMANENT directory. Does it handle the case where the user lacks the filesystem permissions to write to PERMANENT? There is no explicit error handling implemented. The creation process will terminate with a Python exception. Here in our shared /network and multi-user grassdata/ we have exactly this problem: while I am the PERMANENT owner, my colleague cannot write into the DB. As a compromise, t.create should advertise t.connnect as a solution to the problem, otherwise users get immediately stuck. Please try r60732, i have improved the error messages in case the database creation or access fails. Database connection failures will now result in a fatal error rather then Python traceback. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2258#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
