Re: [GRASS-dev] grass is a monad?

2010-02-09 Thread Radim Blazek
On Mon, Feb 8, 2010 at 11:03 PM, Glynn Clements wrote: > Actually, I would suggest QGIS/vdigit isolating actions within a child > process, rather than complicating the rest of GRASS for the sake of > two programs, one of which isn't part of GRASS and the other was > designed incorrectly from the o

Re: [GRASS-dev] grass is a monad?

2010-02-08 Thread Glynn Clements
Radim Blazek wrote: > > Also, what kind of fatal errors can occur while in the middle of > > vector editing that could reasonably be recovered from? > > Probably I don't understand the question, for any error I would prefer > to give a decent message > (in window box) and stop editing (even with

Re: [GRASS-dev] grass is a monad?

2010-02-08 Thread Radim Blazek
On Mon, Jan 18, 2010 at 3:33 AM, Glynn Clements wrote: >> Everything except vector editing. I don't see any reasonable >> possibility to do interactive vector editing via a GRASS module. For >> vector editing, I need immediate response which is visualized on >> display (e.g. if a vertex was moved

Re: [GRASS-dev] grass is a monad?

2010-01-17 Thread Glynn Clements
Radim Blazek wrote: > > This too is Not A Bug. Not isolating distinct operations in distinct > > processes *is* a bug. > > I can imagine almost everything done via GRASS modules. Yes, it is > annoying to run a GRASS module (probably I have to write a new one to > be sure, that the output/options

Re: [GRASS-dev] grass is a monad?

2010-01-17 Thread Radim Blazek
On Thu, Jan 14, 2010 at 10:35 PM, Glynn Clements wrote: > This too is Not A Bug. Not isolating distinct operations in distinct > processes *is* a bug. I can imagine almost everything done via GRASS modules. Yes, it is annoying to run a GRASS module (probably I have to write a new one to be sure,

Re: [GRASS-dev] grass is a monad?

2010-01-15 Thread Glynn Clements
Maris Nartiss wrote: > Some rumbling form bad code author. > Still I don't see why GRASS modules would not benefit from ability to > clean up after themselves in case of failure. Removing temporary maps, > closing open DB connections etc. are good reasons why GRASS modules > should do error check

Re: [GRASS-dev] grass is a monad?

2010-01-15 Thread Maris Nartiss
Some rumbling form bad code author. Still I don't see why GRASS modules would not benefit from ability to clean up after themselves in case of failure. Removing temporary maps, closing open DB connections etc. are good reasons why GRASS modules should do error checking by themselves, unless it IS a

Re: [GRASS-dev] grass is a monad?

2010-01-14 Thread Glynn Clements
Paul Kelly wrote: > So, I feel the idea behind Glynn's comments (and one that I guess I would > agree with) is that we encourage other projects to use GRASS by calling > the modules directly. As GRASS has so few developers compared to the > massive body of code, putting in extra development ti

Re: [GRASS-dev] grass is a monad?

2010-01-14 Thread Paul Kelly
On Thu, 14 Jan 2010, Paolo Cavallini wrote: Hi all. Reading the recent post of Glynn: Right now, I'm actively trying to think of ways to make life harder for anyone trying to use the GRASS libraries for anything except GRASS modules. http://trac.osgeo.org/grass/ticket/869#comment:1 I wonder i

[GRASS-dev] grass is a monad?

2010-01-14 Thread Paolo Cavallini
Hi all. Reading the recent post of Glynn: Right now, I'm actively trying to think of ways to make life harder for anyone trying to use the GRASS libraries for anything except GRASS modules. http://trac.osgeo.org/grass/ticket/869#comment:1 I wonder if this is somehow a view shared by GRASS-PSC, a