Re: [GRASS-dev] GRASS QGIS: the future
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 for the case when print error routine itself ends up with call to G_fatal_error()? It's there to prevent infinite recursion, whether from the printing code, a fatal error handler, or whatever. May be the busy variable made global and added a function to clear it? That might be going a bit too far. OTOH, it can't be cleared prior to calling the handler because it's intended to protect against the case of a handler generating a fatal error. I ment some G_fatal_error_recover() which would be called as last thing from QGIS error routine. One possibility would be to add explicit support for longjmp()ing out, e.g. adding G_error_longjmp(jmp_buf env, int val) which would clear the busy flag then perform the longjmp. That would avoid exposing the internals more than is necessary. Sounds good. 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 error handler isn't limited to fatal errors, but is also used for messages and warnings. G_add_error_handler() is used by GRASS itself? Perhaps we need a dedicated fatal error handler for this purpose? It would be called immediately prior to the final exit() call. It would not be allowed to call GRASS functions or to return. The busy flag could be cleared before calling it. Whatever allows to recover from fatal error will help. I would prefer however not changing semantics too much so that GRASS 6, 7.0.0beta1 and 7.x.x may be easily supported by the same code with only few ifdefs. Radim -- 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] Metadata GRASS (GSOC)
Hi, I was wondering was whether it would be possible to extract from pycsw just the part for reading/writing the xml meta-data, without all the overhead linked to its status as a server. More generally, I just think that we can't be the only ones working on metadata in a Python environment and that we maybe not have to reinvent the wheel. I got news that OWSLib can be used for parse XML according ISO without dependence on pycsw server. In addition I found that there is a pycsw package in UbuntuGIS and also there is a plan to develop package for Debian with the development should start probably after couple of months. OWSLib have dependence only on lxml so this is not a barrier. If we use OWSLib for first task, it could to ensure a smoother continuity to develop second task- pywps. Matej ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Metadata GRASS (GSOC)
I heard yesterday that EPA is releasing a new version of their metadata tool , doing away with the access database and writing everything to xml files. It's being written in C#, but they plan on putting the source code on github. Not sure of the timeline. Doug On Sat, May 17, 2014 at 3:19 AM, Matej Krejci matejkre...@gmail.com wrote: Hi, I was wondering was whether it would be possible to extract from pycsw just the part for reading/writing the xml meta-data, without all the overhead linked to its status as a server. More generally, I just think that we can't be the only ones working on metadata in a Python environment and that we maybe not have to reinvent the wheel. I got news that OWSLib can be used for parse XML according ISO without dependence on pycsw server. In addition I found that there is a pycsw package in UbuntuGIS and also there is a plan to develop package for Debian with the development should start probably after couple of months. OWSLib have dependence only on lxml so this is not a barrier. If we use OWSLib for first task, it could to ensure a smoother continuity to develop second task- pywps. Matej ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Radim Blazek 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 error handler isn't limited to fatal errors, but is also used for messages and warnings. G_add_error_handler() is used by GRASS itself? The raster library installs a handler which calls Rast__unopen_all(). The vector and DBMI libraries provide interfaces to it, although I don't know how (or if) these are used at present. Perhaps we need a dedicated fatal error handler for this purpose? It would be called immediately prior to the final exit() call. It would not be allowed to call GRASS functions or to return. The busy flag could be cleared before calling it. Whatever allows to recover from fatal error will help. I would prefer however not changing semantics too much so that GRASS 6, 7.0.0beta1 and 7.x.x may be easily supported by the same code with only few ifdefs. 7.x doesn't aim for compatibility with 6.x. I'd suggest resolving this prior to any 7.0 pre-release/beta/RC. Currently, lonjmp()ing out of a handler registered with G_set_error_routine() will skip any handlers registered with G_add_error_handler(). Another option is to change GRASS_SIGSEGV_ON_ERROR to call abort() (i.e. raise SIGABRT rather than SIGSEGV), then code can install a signal handler for SIGABRT and siglongjmp() out of that (installing a handler for SIGSEGV is unwise, as you can't easily distinguish a raise()d SIGSEGV from one caused by e.g. memory corruption). Actually, I'm going to make that change regardless. Whether this is sufficient or whether we still need a dedicated termination handler remains open for discussion. -- 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] #1628: segfault in r.walk
GRASS GIS wrote: I have removed the lib/sites dependency of v.vol.rst in 7.x in r60272 (trunk) and r60273 (relbr7). That appears to leave v.in.sites as the only client of lib/sites. And it only uses the oldsite functionality (i.e. reading GRASS 5.x sites maps), as opposed to using the legacy sites API to access vector maps): grass= SELECT i.symbol, i.object grass- FROM obj_exp e, obj_imp i grass- WHERE e.object LIKE 'lib/sites/%' AND e.symbol = i.symbol ; symbol|object -+--- G_site_new_struct | vector/v.in.sites/OBJ.x86_64-unknown-linux-gnu/main.o G_site_free_struct | vector/v.in.sites/OBJ.x86_64-unknown-linux-gnu/main.o G_oldsite_describe | vector/v.in.sites/OBJ.x86_64-unknown-linux-gnu/main.o G_oldsite_get | vector/v.in.sites/OBJ.x86_64-unknown-linux-gnu/main.o G_oldsites_open_old | vector/v.in.sites/OBJ.x86_64-unknown-linux-gnu/main.o (5 rows) Is there any reason to retain lib/sites as a separate library, rather than simply merging it into v.in.sites? There isn't a ctypes wrapper for it, so I'm reasonably sure it isn't used elsewhere in GRASS. [Radim: does QGIS use it?] -- 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] #2293: MapSwipe query maps
#2293: MapSwipe query maps +--- Reporter: lucadelu| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: MapSwipe, query, wxGUI |Platform: All Cpu: Unspecified | +--- Comment(by annakrat): I added query functionality in r60290. It displays query results from both windows together in one dialog since it was the easiest way to implement it. The dialog could have 2 trees of query results but that would require more changes. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2293#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
[GRASS-dev] [GRASS GIS] #2296: r.stream.* - unify some functions (avoid code duplication)
#2296: r.stream.* - unify some functions (avoid code duplication)
-+--
Reporter: hellik | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: major| Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.* |Platform: All
Cpu: All |
-+--
the r.stream.*-modules were recently added to trunk.
to avoid code duplication, some functions should be unified over these
modules in a lib(?) because following files are the same over all
r.stream.*-modules:
{{{
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.channel/io.c
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.distance/io.c
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.order/io.c
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.segment/io.c
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.snap/io.c
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.stats/io.c
http://trac.osgeo.org/grass/browser/grass-
addons/grass7/raster/r.stream.basins/io.c
}}}
{{{
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.channel/io.h
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.distance/io.h
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.order/io.h
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.segment/io.h
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.snap/io.h
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.stream.stats/io.h
http://trac.osgeo.org/grass/browser/grass-
addons/grass7/raster/r.stream.basins/io.h
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2296
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] wxGUI customized toolboxes: handler for non-GRASS commands
Hi Yann,
it's grayed out because it tests if it's a working grass command (for
example r.in.lidar is grayed when you don't compile grass with liblas). You
can try to apply this patch which tests if the command looks like grass
command (regular expression) and if it is not, it doesn't disable it in
menu.
Index: gui_core/menu.py
===
--- gui_core/menu.py (revision 60284)
+++ gui_core/menu.py (working copy)
@@ -18,7 +18,7 @@
@author Robert Szczepanek (menu customization)
@author Vaclav Petras wenzeslaus gmail.com (menu customization)
-
+import re
import wx
from core import globalvar
@@ -91,7 +91,8 @@
cmd = utils.split(str(command))
except UnicodeError:
cmd = utils.split(EncodeString((command)))
-if cmd and cmd[0] not in globalvar.grassCmd:
+if cmd and cmd[0] not in globalvar.grassCmd and \
+ re.match('[rvdipmgt][3bs]?\.([a-z0-9\.])+', cmd[0]):
menuItem.Enable(False)
rhandler = eval('self.parent.' + handler)
On Fri, May 16, 2014 at 12:30 AM, Yann Chemin yche...@gmail.com wrote:
in svn/gui/wxpython/lmgr/frame.py
line 758
by adding:
def RunCmd(self, event = None, cmd = []):
!Run command to system from menu
if event:
cmd = self.GetMenuCmd(event)
os.system(cmd)
I am not sure if this is needed. I would say it might work without this
change but you have to try it out.
Best,
Anna
it should handle it, however, it seems that a flag is needed to enable
the possibility to click the command from the created menu. It is
still grey/shadowed.
On 16/05/2014, Yann Chemin yche...@gmail.com wrote:
To be precise, the non-GRASS programs have their own GUI already, and
the calls need only one word.
On 16/05/2014, Yann Chemin yche...@gmail.com wrote:
Hi,
I would like to make a customized toolbox to call some non-GRASS CLI
programs.
Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
grey/shadowed so that no mouse click is allowed on them.
thanks
Yann
--
--
--
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands
Hi Anna,
Patch works great ! Needs RunMenuCmd and all goes to perfection. Any
chance to have it included in the SVN tree?
Thank you
Yann
On 18/05/2014, Anna Petrášová kratocha...@gmail.com wrote:
Hi Yann,
it's grayed out because it tests if it's a working grass command (for
example r.in.lidar is grayed when you don't compile grass with liblas). You
can try to apply this patch which tests if the command looks like grass
command (regular expression) and if it is not, it doesn't disable it in
menu.
Index: gui_core/menu.py
===
--- gui_core/menu.py (revision 60284)
+++ gui_core/menu.py (working copy)
@@ -18,7 +18,7 @@
@author Robert Szczepanek (menu customization)
@author Vaclav Petras wenzeslaus gmail.com (menu customization)
-
+import re
import wx
from core import globalvar
@@ -91,7 +91,8 @@
cmd = utils.split(str(command))
except UnicodeError:
cmd = utils.split(EncodeString((command)))
-if cmd and cmd[0] not in globalvar.grassCmd:
+if cmd and cmd[0] not in globalvar.grassCmd and \
+ re.match('[rvdipmgt][3bs]?\.([a-z0-9\.])+', cmd[0]):
menuItem.Enable(False)
rhandler = eval('self.parent.' + handler)
On Fri, May 16, 2014 at 12:30 AM, Yann Chemin yche...@gmail.com wrote:
in svn/gui/wxpython/lmgr/frame.py
line 758
by adding:
def RunCmd(self, event = None, cmd = []):
!Run command to system from menu
if event:
cmd = self.GetMenuCmd(event)
os.system(cmd)
I am not sure if this is needed. I would say it might work without this
change but you have to try it out.
Best,
Anna
it should handle it, however, it seems that a flag is needed to enable
the possibility to click the command from the created menu. It is
still grey/shadowed.
On 16/05/2014, Yann Chemin yche...@gmail.com wrote:
To be precise, the non-GRASS programs have their own GUI already, and
the calls need only one word.
On 16/05/2014, Yann Chemin yche...@gmail.com wrote:
Hi,
I would like to make a customized toolbox to call some non-GRASS CLI
programs.
Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
grey/shadowed so that no mouse click is allowed on them.
thanks
Yann
--
--
--
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
