On Wed, Apr 23, 2014 at 4:02 PM, Sören Gebbert
Vector lib does not call G_fatal_error(), it was written in parallel
with QGIS plugin with vector editing in mind. I hope it is still true.
I fear that might be not the case anymore. For example, all memory
allocation functions G_calloc(),
Sören Gebbert wrote:
Vector lib does not call G_fatal_error(), it was written in parallel
with QGIS plugin with vector editing in mind. I hope it is still true.
I fear that might be not the case anymore. For example, all memory
allocation functions G_calloc(), G_malloc() and G_realloc()
2014-04-20 11:38 GMT+02:00 Martin Landa landa.mar...@gmail.com:
Hi,
2014-04-20 1:34 GMT+02:00 Sören Gebbert soerengebb...@googlemail.com:
Hence the wrapper will not only do simple function wrapping, it will
also implement a higher level interface:
[...]
what about to create a trac wiki
On Tue, Apr 22, 2014 at 4:49 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
IMHO we GRASS developers are too stubborn to change the design of
GRASS GIS to work as library with persistent applications. This would
require rewriting plenty of core functionality and modification of all
Hi Radim,
2014-04-23 14:50 GMT+02:00 Radim Blazek radim.bla...@gmail.com:
On Tue, Apr 22, 2014 at 4:49 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
IMHO we GRASS developers are too stubborn to change the design of
GRASS GIS to work as library with persistent applications. This would
On Fri, Apr 18, 2014 at 2:19 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
Hi Radim,
IMHO we GRASS developers are too stubborn to change the design of
GRASS GIS to work as library with persistent applications. This would
require rewriting plenty of core functionality and modification
Hi Radim,
2014-04-22 16:03 GMT+02:00 Radim Blazek radim.bla...@gmail.com:
On Fri, Apr 18, 2014 at 2:19 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
Hi Radim,
IMHO we GRASS developers are too stubborn to change the design of
GRASS GIS to work as library with persistent applications.
Hi,
2014-04-20 1:34 GMT+02:00 Sören Gebbert soerengebb...@googlemail.com:
Hence the wrapper will not only do simple function wrapping, it will
also implement a higher level interface:
[...]
what about to create a trac wiki page dedicated to RFC and collect
this notes there... ?
Martin
--
2014-04-19 0:59 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
[...]
You're misunderstanding a key point.
Misunderstanding is usually a question of the point of view or level
of doggedness. Especially when someone is speaking about a key
point ;-)
Returning from G_fatal_error() won't
Hi Martin,
On Fri, 18. Apr 2014 at 12:20:15 +0200, Martin Landa wrote:
[...] I still think that we should provide in GRASS API function like
G_set_fatal_error() with default value G_FATAL_ERROR_EXIT (current
behaviour). The second option would be G_FATAL_ERROR_RETURN with big big
warning in
Martin Landa wrote:
Returning from G_fatal_error() won't leave GRASS libraries in an
unpredictable state. It's escaping from G_fatal_error() via e.g.
Returning from G_fatal_error() will typically result in a
(more-or-less immediate) segfault when the caller tries to use data
structures
Vaclav Petras wrote:
The key feature of G_fatal_error() isn't printing error messages. The
key feature is that it doesn't return.
This is one of the problems of G_fatal_error(), it does not gives good
error messages to the user. User gets G_malloc: unable to allocate %lu
bytes of
G_fatal_error() is too low level not only for messages but in general,
for
Python libraries wrapping GRASS library, it does not allow to throw an
exception in case of an error. And the same applies for C++ wrappers.
If you want to turn fatal errors into exceptions, the correct way to
do
Hi,
2014-04-18 11:31 GMT+02:00 Radim Blazek radim.bla...@gmail.com:
[]
Unfortunately GRASS 7 moved ahead towards its aim to make life harder
for anyone trying to use the GRASS libraries [1]. Basically more and
personally I am not fan of this approach. I still think that we should
provide
Hi Radim,
IMHO we GRASS developers are too stubborn to change the design of
GRASS GIS to work as library with persistent applications. This would
require rewriting plenty of core functionality and modification of all
C-modules. But there is a solution for persistent applications, called
Remote
Martin Landa wrote:
Unfortunately GRASS 7 moved ahead towards its aim to make life harder
for anyone trying to use the GRASS libraries [1]. Basically more and
personally I am not fan of this approach. I still think that we should
provide in GRASS API function like G_set_fatal_error()
On Fri, Apr 18, 2014 at 6:59 PM, Glynn Clements gl...@gclements.plus.comwrote:
The key feature of G_fatal_error() isn't printing error messages. The
key feature is that it doesn't return.
This is one of the problems of G_fatal_error(), it does not gives good
error messages to the user. User
On 28/03/14 15:16, Paolo Cavallini wrote:
Il 28/03/2014 15:04, Martin Dobias ha scritto:
On Fri, Mar 28, 2014 at 11:48 AM, Paolo Cavallini cavall...@faunalia.it wrote:
* to add GRASS browsing capabilities in QGIS file browser
The support for GRASS is already in the browser - if you enter a
On Tue, Apr 8, 2014 at 2:18 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 28/03/14 15:16, Paolo Cavallini wrote:
Il 28/03/2014 15:04, Martin Dobias ha scritto:
On Fri, Mar 28, 2014 at 11:48 AM, Paolo Cavallini cavall...@faunalia.it
wrote:
* to add GRASS browsing capabilities in
Radim Blazek radim.bla...@gmail.com writes:
On Tue, Apr 8, 2014 at 2:18 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 28/03/14 15:16, Paolo Cavallini wrote:
Il 28/03/2014 15:04, Martin Dobias ha scritto:
On Fri, Mar 28, 2014 at 11:48 AM, Paolo Cavallini cavall...@faunalia.it
On Tue, Apr 8, 2014 at 3:54 PM, Rainer M Krug rai...@krugs.de wrote:
Radim Blazek radim.bla...@gmail.com writes:
On Tue, Apr 8, 2014 at 2:18 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 28/03/14 15:16, Paolo Cavallini wrote:
Il 28/03/2014 15:04, Martin Dobias ha scritto:
On
On 08/04/14 15:31, Radim Blazek wrote:
On Tue, Apr 8, 2014 at 2:18 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 28/03/14 15:16, Paolo Cavallini wrote:
Il 28/03/2014 15:04, Martin Dobias ha scritto:
On Fri, Mar 28, 2014 at 11:48 AM, Paolo Cavallini cavall...@faunalia.it
wrote:
One last addition to this from my side:
Since, as I mentioned, we have evaluated many of the
issues discussed in this thread in the design of the
GRASS plug-in for SEXTANTE/gvSIG CE, here are some things
you might want to take into consideration:
On 28/03/14 11:48, Paolo Cavallini wrote:
Il
Il 28/03/2014 15:16, Paolo Cavallini ha scritto:
Il 28/03/2014 15:04, Martin Dobias ha scritto:
The support for GRASS is already in the browser - if you enter a
directory that is a GRASS database, it will detect it and show
locations/mapsets/maps/layers.
In the GRASS plugin there are a few
Il 27/03/2014 12:33, Nathan Woodrow ha scritto:
I would vote for dropping the plugin and just updating the processing
plugin. Having both ways is bad for us and bad for users, even worse
when some functions are missing from one but not in the other.
I understand well the point; however, the
...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: 27. mars 2014 12:41
To: Nathan Woodrow
Cc: qgis-developer; grass-dev
Subject: Re: [Qgis-developer] GRASS QGIS: the future
Il 27/03/2014 12:33, Nathan Woodrow ha scritto:
I would vote for dropping the plugin and just updating the processing
plugin. Having
...
Cheers
Stefan
-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Sent: 27. mars 2014 13:36
To: Blumentrath, Stefan
Cc: Paolo Cavallini; Nathan Woodrow; qgis-developer; grass-dev
Subject: Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
I'm not much
On Thu, Mar 27, 2014 at 9:38 AM, Blumentrath, Stefan
stefan.blumentr...@nina.no wrote:
I also understand that at some point in time one will have to use GRASS
directly in order to access full functionality (e.g. ortho-rectification,
nviz, mapswipe, animation and stuff), which makes the way
-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Sent: 27. mars 2014 13:36
To: Blumentrath, Stefan
Cc: Paolo Cavallini; Nathan Woodrow; qgis-developer; grass-dev
Subject: Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
I'm not much of a QGIS-as-GRASS
29 matches
Mail list logo
