[GRASS-dev] Re: problem with G_fatal_error

Martin Dobias wonder.sk at gmail.com
Wed Oct 24 14:33:16 EDT 2007


Hi Benjamin,

On 10/23/07, Benjamin Ducke <benjamin.ducke at ufg.uni-kiel.de> wrote:
>
> Maybe this one particular case could be patched up by making a copy of
> GRASS' Vect_open_old_head function (like Vect_open_old_head_no_exit) and
> using that to interface from QGIS?
> I would expect that if there are more problems of that type, they should
> all appear in calls of "open_something" or "close_someting" and maybe
> some basic data retrieval functions, as the
> QGIS interface probably doesn't need much more than these in order to
> interface with GRASS and display GRASS maps?

I think copying the implementation could make it even worse as we
would need to watch any changes in GRASS implementation of such
functions. Or did you mean to copy it inside GRASS?

I've fixed the problem using setjmp/longjmp functions as Glynn suggested.

> Would it be possible to make a list of all GRASS lib functions that
> QGIS calls directly, then look through them and make modified copies
> of everyone that needs a different error handler (maybe putting them
> altogether into a "GRASS_gui_handler" lib or sth. like that)?

Even better would be to make a list of GRASS functions which could end
with fatal error. Now it's fixed only for that particular know case
where it was terminating QGIS, but I guess there might be more such
functions...

> > It needs to be borne in mind that the GRASS libraries were (and are)
> > designed for GRASS, which is a collection of "one-shot" programs (i.e.
> > you run the program with arguments, it does its work, then exits). The
> > design of the libraries is fundamentally unsuitable for persistent
> > programs.
> >
> > If you feel like re-writing the whole of GRASS to propagate all errors
> > up to the individual programs and handle them there (and cleaning up
> > any inconsistent state along the way), I'm sure that the effort will
> > be appreciated.
>
> GRASS has earned our appreciation as a GUI-independent GIS toolbox, but
> the fact remains that a GUI-integrated approach such as QGIS will open
> it up to a multitude of new users and we need to support this in my
> opinion.
> Of course, GRASS' stability throughout the years has much relied on
> the clean, Unix-based design that especially Glynn has been keeping
> in a consistent state, but I am sure we can find bridges here.

The problem is that GRASS support for QGIS was in fact Radim's one-man
project.  Now he's not active in development, so GRASS plugin doesn't
get enough attention from developers. We would really welcome anyone
interested in taking care of the GRASS plugin in QGIS.


> Probably all true from a technical point of view but I sense that
> there is some frustration building up among QGIS developers about
> constantly having to catch-up with the results of the very
> "different" nature and philosophy of GRASS development. We need
> a stronger cooperation between both development teams to concentrate
> on a Win32 GRASS "kernel" that can go into regular QGIS releases.

As written above, we need someone in QGIS team who understands GRASS
internals so that we could avoid more frustration from devs and
users...

Regards
Martin




More information about the grass-dev mailing list