On Tue, Jul 29, 2014 at 11:00 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Neteler wrote:
Can you try the attached patch? The new function should be used like:
if (setjmp(*G_fatal_longjmp(1))) {
// this will be executed on fatal errors
}
On Fri, May 30, 2014 at 12:38 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Radim Blazek wrote:
Can you try the attached patch? The new function should be used like:
if (setjmp(*G_fatal_longjmp(1))) {
// this will be executed on fatal errors
}
Works.
On Fri, May 30, 2014 at 12:38 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Radim Blazek wrote:
Can you try the attached patch? The new function should be used like:
if (setjmp(*G_fatal_longjmp(1))) {
// this will be executed on fatal errors
}
Works.
On Fri, May 30, 2014 at 9:33 PM, Markus Neteler nete...@osgeo.org wrote:
On Fri, May 30, 2014 at 12:38 AM, Glynn Clements
...
Committed in r60590.
The only aspect which might be invasive is that defs/gis.h now
includes setjmp.h for the jmp_buf declaration. Although this is a
standard C
On Wed, May 28, 2014 at 1:49 AM, Glynn Clements
gl...@gclements.plus.com wrote:
But I still think that the global error handler is the wrong place for
a longjmp(). Its original purpose was to allow the standard
notification mechanism (stderr, log file, and/or email) to be replaced
with a
On Sat, May 17, 2014 at 7:16 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Also, currently the global error handler (G_set_error_routine) is
called before the non-exclusive handlers (G_add_error_handler), so
those will never be called if the global handler lonjmp()s out. The
global
On Fri, Apr 18, 2014 at 12:27 PM, Paolo Cavallini cavall...@faunalia.it wrote:
Thanks for this. If I understand well, this means:
* we can load GRASS7 vectors through QGIS browser
* we cannot load GRASS7 rasters
Raster provider is also upgraded (bf6effdd).
* the qgis-grass-plugin is not
Dne 16.5.2014 18:36 Glynn Clements gl...@gclements.plus.com napsal(a):
Radim Blazek wrote:
There is a problem in G_fatal_error():
static int busy
if (busy)
exit(EXIT_FAILURE);
busy = 1;
second G_fatal_error() call always exits.
The busy check is there
On Sat, Apr 19, 2014 at 12:43 AM, Glynn Clements
gl...@gclements.plus.com wrote:
3) use setjmp()/longjmp()
That is the sane option.
But bear in mind that subsequently calling any GRASS function is
entirely at your own risk. A call to G_fatal_error() often means
that internal data
Il 23/04/2014 15:12, Radim Blazek ha scritto:
I am not even trying to ask that question. As long as there are GRASS
users using the QGIS plugin, it should not be thrown away.
agreed fully, of course. The issue is: how much work is required for
this? and: who is goig to invest on it?
There is
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(),
Il 22/04/2014 15:55, Radim Blazek ha scritto:
Thanks for this. If I understand well, this means:
* we can load GRASS7 vectors through QGIS browser
* we cannot load GRASS7 rasters
* the qgis-grass-plugin is not functional with GRASS7
Yes. We are talking about current master, not about
* Processing is blocking the main QGIS canvas, which for very long
analyses is unacceptable
That should be a matter of putting Processing algorithm in a different
thread. We had it like that, but it proved to be rather unstable, so it was
termporarily disabled, but i hope i can do further
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 Wed, Apr 23, 2014 at 1:11 AM, Glynn Clements 1) add a
requirement that GRASS 7 used with QGIS must be compiled with
-fexceptions
By itself, this will do nothing.
I mean to allow to throw exception from the function set by
G_set_error_routine().
Does using a C++ exception have any
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
On Wed, Apr 23, 2014 at 10:09 AM, Paolo Cavallini cavall...@faunalia.it wrote:
The Processing plugin may substitute GRASS Tools part of the plugin
(i.e. modules GUI), it cannot help with:
- mapset creation
- vector/raster maps visualization
- vector digitizing
- region visualization
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 12:27 PM, Paolo Cavallini cavall...@faunalia.it wrote:
Il 18/04/2014 11:31, Radim Blazek ha scritto:
I have upgraded the vector provider to GRASS 7, layers may be added
by drag from browser. The raster and the plugin are disabled. Be
careful about multiple versions on
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
On Sat, Apr 19, 2014 at 12:43 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Basically more and more low level functions are calling exit()
instead of returning error code if something failed. As I am not
willing to implement GRASS module call for each simple function, we
have to think
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
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 Glynn,
An RPC wrapper would move the execution of GRASS functions into a new
process (i.e. a server). If the call generates a fatal error, the
server dies, the client detects this and reports an error rather than
a result.
The main problem with this is that any error loses the entire
I have upgraded the vector provider to GRASS 7, layers may be added
by drag from browser. The raster and the plugin are disabled. Be
careful about multiple versions on the same system
(LD_LIBRARY_PATH..., check with ldd if does not work).
Unfortunately GRASS 7 moved ahead towards its aim to make
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,
Il 18/04/2014 11:31, Radim Blazek ha scritto:
I have upgraded the vector provider to GRASS 7, layers may be added
by drag from browser. The raster and the plugin are disabled. Be
careful about multiple versions on the same system
(LD_LIBRARY_PATH..., check with ldd if does not
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
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 Fri, Apr 18, 2014 at 6:43 PM, Glynn Clements gl...@gclements.plus.comwrote:
Unfortunately GRASS 7 moved ahead towards its aim to make life harder
for anyone trying to use the GRASS libraries [1].
That isn't actually the reason why various functions have had status
returns changed to
On Thu, Mar 27, 2014 at 12:18 PM, Markus Neteler nete...@osgeo.org wrote:
Hi Paolo,
(note: I'm not ready qgis-dev, not sure if this email reaches it)
...
* new modules will not be available in QGIS.
There might be only a few which could be of interest here (e.g. the
highly specialized
Il 28/03/2014 08:34, Paolo Cavallini ha scritto:
Thanks to all for the interesting comments. Obviously we have a varied
and rich ecosystem here, that's why I want to preserve it.
Obviously we all want to have all. IMHO the points are:
* can we (GRASS+QGIS) agree on a specific course of
Hi Paolo,
2014-03-27 11:18 GMT+01:00 Paolo Cavallini cavall...@faunalia.it:
Hi all.
I learned during dinner that GRASS7 RC1 is due very soon. This opens the
issue of its functioning in QGIS. IMHO:
* the qgis-grass-plugin might stop working (this has to be tested)
Yes, it will stop working,
I updated all existing modules incl the newly included r.stream.*.
A few more new modules might be interesting to add. That's easy...
Markus
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
On Fri, Mar 28, 2014 at 11:16 AM, Paolo Cavallini cavall...@faunalia.itwrote:
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
Il 28/03/2014 15:51, Markus Neteler ha scritto:
I have submitted the Processing for GRASS GIS 7 to Pirmin and Victor
for git upload.
Now the user has GRASS 6 and 7 both supported in Processing.
good news, thanks. are you referring to the upgraded and new modules?
all the best.
--
Paolo
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
directory that is a GRASS database, it
Hi all,
On Thu, Mar 27, 2014 at 12:18 PM, Markus Neteler nete...@osgeo.org wrote:
Hi Paolo,
(note: I'm not ready qgis-dev, not sure if this email reaches it)
On Thu, Mar 27, 2014 at 11:18 AM, Paolo Cavallini cavall...@faunalia.it
wrote:
Hi all.
I learned during dinner that GRASS7 RC1 is
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
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
directory that is a GRASS database, it will detect it and show
locations/mapsets/maps/layers.
Hi Paolo,
(note: I'm not ready qgis-dev, not sure if this email reaches it)
On Thu, Mar 27, 2014 at 11:18 AM, Paolo Cavallini cavall...@faunalia.it wrote:
Hi all.
I learned during dinner that GRASS7 RC1 is due very soon. This opens the
issue of its functioning in QGIS. IMHO:
* the
Il 27/03/2014 12:18, Markus Neteler ha scritto:
* upgrading Processing GRASS modules
I'll do that. I already started with Pirmin and Victor to discuss it.
good news
* changing the current Processing behaviour, avoiding the import-export
phase when piping consecutive GRASS commands; this
On 27 March 2014 11:18, Paolo Cavallini cavall...@faunalia.it wrote:
Hi all.
Hi all,
I learned during dinner that GRASS7 RC1 is due very soon. This opens the
issue of its functioning in QGIS. IMHO:
* the qgis-grass-plugin might stop working (this has to be tested)
I test to compile QGIS
...
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
-
From: grass-dev-boun...@lists.osgeo.org
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Benjamin Ducke
Sent: 27 March 2014 14:31
To: grass-dev
Subject: Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
In the gvSIG CE project, we had to make the same type of decisions and came
On 03/27/2014 08:05 AM, Saber Razmjooei wrote:
Hi all,
Here is my wish list:
- To be able to access GRASS data within QGIS. Similar to PostGIS and other
GDAL/OGR data sources, it should be up to users to create GRASS
geodatabase/location/mapsets. QGIS will be able to simply add layers for
49 matches
Mail list logo
