Re: [GRASS-dev] i.spectral limited to 400 files
On Sat, Apr 19, 2014 at 12:12 AM, Glynn Clements gl...@gclements.plus.com wrote: ... I have taken liberty to add your comments to http://grasswiki.osgeo.org/wiki/Large_raster_data_processing#Number_of_open_files_limitation Feel free to edit the Wiki. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
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 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 which contain garbage (because the callee never initialised
them, but raised a fatal error instead).
Well, and what do you think that I meant by unpredictable state?
The simplest example is G__malloc():
buf = malloc(n);
if (!buf) {
...
G_fatal_error(_(G_malloc: unable to allocate %lu bytes of memory at
%s:%d),
(unsigned long) n, file, line);
}
return buf;
If malloc() returns NULL and the subsequent G_fatal_error() call
returns, G__malloc() will return NULL to its caller. Which will
segfault as soon as it tries to store something in the allocated
memory.
You chose very specific case of course. There is probably something
you don't want to understand. In the core libraries (gis, vector,
raster, imagery) there are 553(!) places where G_fatal_error() is
called. Some time ago you introduced G_fatal_error() even to the
function which tries to open raster map [1]. So if the raster map
doesn't exists the function is calling exit()! This is something which
makes life harder for anyone who want to use GRASS libraries (as you
already mentioned) with one exception - modules - standalone programs,
where you don't need to specify `if` statement. You can hardly explain
to someone that our libraries call fatal exit even when raster map is
not found. Yes, you can if don't want to change your opinion
regardless any input from outside world. For such cases, like opening
raster map would G_set_fatal_error() simply make sense.
It achieves this by calling exit() (or optionally raising SIGSEGV; why
it didn't use SIGABRT, I have no idea). Calling longjmp() would work.
If it was C++, raising an exception would work. Returning will *not*
work.
[...]
Martin
[1]
http://trac.osgeo.org/grass/changeset/40209/grass/trunk/lib/raster/opencell.c
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2138: winGRASS6.4.svn - addon python script status?
#2138: winGRASS6.4.svn - addon python script status? --+- Reporter: hellik | Owner: martinl Type: defect | Status: reopened Priority: critical | Milestone: 6.4.4 Component: Addons | Version: svn-releasebranch64 Resolution: |Keywords: wingrass, addon, python Platform: MSWindows 7 | Cpu: x86-64 --+- Comment(by martinl): In r59799 I fixed bug when install exe addons. So please test the next build which should allow to install and launch py/sh/exe addons. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2138#comment:30 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] [Qgis-developer] GRASS QGIS: the future
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 the API manual that you are living GRASS libraries in completely unpredictable state and you should immediately stop an application which is using GRASS libraries. I also don't think that would help much. You would still need to use G_set_error_routine to track that there was an fatal error and in turn avoid a crash by not touching the result when the call returns - and keep away from calling other library function because of the unpredictable state of the library. On Fri, 18. Apr 2014 at 23:59:25 +0100, Glynn Clements wrote: It achieves this by calling exit() (or optionally raising SIGSEGV; why it didn't use SIGABRT, I have no idea). Calling longjmp() would work. If it was C++, raising an exception would work. Returning will *not* work. I guess there are also library calls inside the libraries themselves and those would not be aware that there is a need to handle invalid results and might crash before the toplevel caller has a chance know of the error. I think that's Glynn's keypoint. Using setjmp()/longjmp() or throwing C++ exceptions (with the libraries built with -fexceptions) in the error routine would take you back to the caller that is aware of the error. That avoids the crash, but also leaves the library in an unpredictable state. To avoid that there's no other way than returning and handling all the errors properly. Probably huge amount of work with not much gain for GRASS. The RPC approach will IMHO be less work and also cause less friction. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2138: winGRASS6.4.svn - addon python script status?
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Addons | Version: svn-releasebranch64
Resolution: |Keywords: wingrass, addon, python
Platform: MSWindows 7 | Cpu: x86-64
--+-
Comment(by hellik):
Replying to [comment:27 martinl]:
Replying to [comment:26 hellik]:
the r.basin-wxgui pops up, enter all parameters and press start button
{{{
r.basin.py map=elevation@PERMANENT prefix=j easting=636654.791181
northing=218824.126649 threshold=20
}}}
you are right, please try the next build - see r59782
tested with
{{{
System Info
GRASS Version: 6.4.4svn
GRASS SVN Revision: 59785
GDAL/OGR: 1.10.1
PROJ4: Rel. 4.8.0, 6 March 2012
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)
}}}
it works now, thanks for fixing it.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2138#comment:31
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] [GRASS GIS] #1214: r.li.edgedensity: segmentation fault
#1214: r.li.edgedensity: segmentation fault --+- Reporter: neteler | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 6.4.4 Component: Raster| Version: svn-releasebranch64 Keywords: r.li.edgedensity |Platform: All Cpu: x86-64| --+- Comment(by neteler): After make distclean it runs fine. I added two new test scripts: * raster/r.li/r.li.testing_nc_asc.sh * raster/r.li/r.li.testing_sp_mov.sh Whole maplayer versus moving window. Both produce identical results in GRASS 6 and 7, respectively. I think the bug(s) have been solved and the ticket can be closed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1214#comment:14 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] [GRASS GIS] #2038: wingrass7: v.db.addcolumn fails in attribute table manager
#2038: wingrass7: v.db.addcolumn fails in attribute table manager -+-- Reporter: hellik | Owner: martinl Type: defect | Status: assigned Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: wingrass, vector, attribute |Platform: MSWindows 7 Cpu: x86-64 | -+-- Changes (by martinl): * cc: grass-dev@… (added) * owner: grass-dev@… = martinl * status: new = assigned -- Ticket URL: http://trac.osgeo.org/grass/ticket/2038#comment:4 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] [GRASS GIS] #2038: wingrass7: v.db.addcolumn fails in attribute table manager
#2038: wingrass7: v.db.addcolumn fails in attribute table manager -+-- Reporter: hellik | Owner: grass-dev@… Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: wingrass, vector, attribute |Platform: MSWindows 7 Cpu: x86-64 | -+-- Comment(by martinl): I try to reproduce it with latest SVN build, but it worked. Could you try it again please? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2038#comment:3 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] [GRASS GIS] #1464: Bug on v.buffer
#1464: Bug on v.buffer --+- Reporter: leonidas | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Vector| Version: svn-trunk Keywords: v.buffer |Platform: All Cpu: All | --+- Comment(by martinl): Replying to [comment:5 neteler]: Replying to [comment:4 mmetz]: Fixed in trunk in r51580, as long as GRASS is compiled with GEOS. Neither one of the two GRASS-internal buffering methods is working correctly. Moreover, the GEOS method is the only one allowing for internal buffers with negative distances. Should we disable v.buffer if GEOS is not available (rather have no result than a wrong result)? I suppose that GEOS is available for all relevant platforms nowadays (and it became official OSGeo project yesterday). So I support this suggestion. +1 for disabling `v.buffer` when GRASS not compiled against GEOS. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1464#comment:6 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] [GRASS GIS] #1061: Merge DB connet/DB Login/DB Test in one module
#1061: Merge DB connet/DB Login/DB Test in one module --+- Reporter: vesnikos | Owner: grass-dev@… Type: enhancement | Status: closed Priority: minor| Milestone: 7.0.0 Component: Database | Version: svn-trunk Resolution: invalid |Keywords: db.connect, db.login Platform: Linux| Cpu: x86-32 --+- Changes (by martinl): * status: new = closed * resolution: = invalid Comment: I think it perfectly follows logic of little Unix programs which are doing just one thing. I would say that we will stay with that. The GUI front-end is another question. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1061#comment:2 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] [GRASS GIS] #2038: wingrass7: v.db.addcolumn fails in attribute table manager
#2038: wingrass7: v.db.addcolumn fails in attribute table manager --+- Reporter: hellik | Owner: martinl Type: defect | Status: closed Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: fixed|Keywords: wingrass, vector, attribute Platform: MSWindows 7 | Cpu: x86-64 --+- Changes (by martinl): * status: assigned = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/2038#comment:5 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] TOC in HTML manual pages
Hi, I'm excited about the new TOC in HTML manual pages. There are some styling issues (bullet for every second item), and looking to the HTML code, the generator is creating both table and ul which is not good. ul should be enough. http://grass.osgeo.org/grass71/manuals/r.mapcalc.html Anyway, I've tried different approach and here is my prototype: https://googledrive.com/host/0B_7Sygt2HTPDamFPOEZpU0h1ZG8/r.mapcalc.html The TOC is generated by JavaScript, so it is available only when JS is available (and thus probably also CSS is available). The header contains empty div into which TOC is generated. The other difference is the CSS, we can compare what is better. The not so wide page content as it is currently in trunk actually quite good. However, CSS and HTML is not (yet) optimized for wxHtmlWindow. You have to hover over TOC to make the TOC itself visible. There is also a warning box with a link to a another versions of documentation (e.g. from trunk to release). And also title of the page. But this is unrelated to TOC. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #734: wxGui sqlbuilder: a few bugs
#734: wxGui sqlbuilder: a few bugs +--- Reporter: hamish | Owner: martinl Type: defect | Status: assigned Priority: major | Milestone: 6.4.4 Component: wxGUI | Version: 6.4.0 RCs Keywords: sqlbuilder |Platform: All Cpu: x86-64 | +--- Comment(by martinl): Replying to [comment:5 neteler]: * Windows falls into busy state, i.e. the wxGUI blocks Do you mean when you click on 'Get all values' or 'Get sample values'? It should be fixed in r59802. -- Ticket URL: http://trac.osgeo.org/grass/ticket/734#comment:8 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] TOC in HTML manual pages
Hi, 2014-04-19 17:45 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: Anyway, I've tried different approach and here is my prototype: https://googledrive.com/host/0B_7Sygt2HTPDamFPOEZpU0h1ZG8/r.mapcalc.html I like your changes, two small notes: * GRASS GIS 7 label is too big ;-) * link to GRASS 6 could point directly to the manual page of given module Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
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 which contain garbage (because the callee never initialised them, but raised a fatal error instead). Well, and what do you think that I meant by unpredictable state? I assumed that you meant the same thing that I do when I point out that longjmp()ing out of a fatal error handling will leave the libraries' data in an unpredictable state, i.e. that a *subsequent* call to a GRASS library function may result in a crash. Having G_fatal_error() return will usually cause an immediate crash, without needed any subsequent calls. The simplest example is G__malloc(): You chose very specific case of course. I chose the simplest example. But the more general case is: 1. Code performs a task which can either fail or succeed. 2a. On success, some form of result is stored in one or more variables. 2b. On failure, the code calls G_fatal_error(). 3. The code uses the values of the variables assigned in 2a, taking it for granted that they contain valid values (because if 1 had failed, the G_fatal_error() call in 2b ensures that we wouldn't be here). If G_fatal_error() can return, practically any function which calls it will either attempt to use garbage data, or will (silently) return garbage data to its caller. There is probably something you don't want to understand. In the core libraries (gis, vector, raster, imagery) there are 553(!) places where G_fatal_error() is called. Some time ago you introduced G_fatal_error() even to the function which tries to open raster map [1]. So if the raster map doesn't exists the function is calling exit()! This is something which makes life harder for anyone who want to use GRASS libraries (as you already mentioned) with one exception - modules - standalone programs, Modules aren't an exception, they're the rule. People wanting to use GRASS libraries in a persistent application are the exception. It's the latter category that's doing the not understanding. Specifically, they don't understand the magnitude of the cost involved in propagating errors all the way to the top-most level using status returns at each step. This cost is why modern languages have exceptions. Unfortunately: 1. C doesn't have exceptions. The closest thing it has is setjmp/longjmp. 2. Exceptions eliminate much of the cost, but not all of it. You still have to write exception-safe code. But the difference is significant enough that I wouldn't object to the (comparatively minor) added complexity resulting from making code exception-safe. Apart from anything else, the added complexity would be limited to the implementation of library functions; it doesn't impose a unreasonable burden on the callers in the way that using status returns does. -- 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-SVN] r59812 - in grass/branches/releasebranch_7_0: man tools
Martin, I'm not sure if this [59812] is appropriate because it is not
stabilized yet [59816] and overall, it is a new feature although it is just
in documentation.
https://trac.osgeo.org/grass/changeset/59812
https://trac.osgeo.org/grass/changeset/59816
On Sat, Apr 19, 2014 at 2:38 PM, svn_gr...@osgeo.org wrote:
Author: martinl
Date: 2014-04-19 11:38:08 -0700 (Sat, 19 Apr 2014)
New Revision: 59812
Modified:
grass/branches/releasebranch_7_0/man/build_html.py
grass/branches/releasebranch_7_0/man/grassdocs.css
grass/branches/releasebranch_7_0/tools/mkhtml.py
Log:
Backport TOC manual generation from trunk
Modified: grass/branches/releasebranch_7_0/man/build_html.py
===
--- grass/branches/releasebranch_7_0/man/build_html.py 2014-04-19
18:33:48 UTC (rev 59811)
+++ grass/branches/releasebranch_7_0/man/build_html.py 2014-04-19
18:38:08 UTC (rev 59812)
@@ -48,7 +48,7 @@
header2_tmpl = string.Template(\
r link rel=stylesheet href=grassdocs.css type=text/css
/head
-body bgcolor=#FF
+body style=width: 99%
!-- this file is generated by man/build_html.py --
@@ -249,7 +249,7 @@
r
link rel=stylesheet href=grassdocs.css type=text/css
/head
-body bgcolor=white
+body style=width: 99%
img src=grass_logo.png alt=GRASS logohr align=center size=6
noshade
h2Topics/h2
@@ -261,7 +261,7 @@
r
link rel=stylesheet href=grassdocs.css type=text/css
/head
-body bgcolor=white
+body style=width: 99%
img src=grass_logo.png alt=GRASS logohr align=center size=6
noshade
h2Keywords - Index of GRASS GIS modules/h2
Modified: grass/branches/releasebranch_7_0/man/grassdocs.css
===
--- grass/branches/releasebranch_7_0/man/grassdocs.css 2014-04-19
18:33:48 UTC (rev 59811)
+++ grass/branches/releasebranch_7_0/man/grassdocs.css 2014-04-19
18:38:08 UTC (rev 59812)
@@ -14,6 +14,7 @@
background: white;
color: black;
font-family: arial,sans-serif;
+width: 80%;
}
h1{
@@ -49,7 +50,7 @@
}
div.code{
-width: 95%;
+width: 100%;
color : black;
background-color: rgb(90%, 90%, 90%);
padding-left: 1em;
@@ -86,3 +87,32 @@
td {
padding: 5px;
}
+
+div.toc{
+background-color: transparent;
+position: fixed;
+border: solid 1px rgb(25%, 60%, 25%);
+top: 5px;
+right: 5px;
+width: 17%;
+line-height: 120%;
+font-weight: bold;
+font-size: small;
+font-family: arial,sans-serif;
+}
+
+li.toc {
+ margin-left: -15px;
+ padding: 3px 3px; 3px; 3px;
+ color: rgb(25%, 60%, 25%);
+}
+
+ul.toc {
+ margin-top: 3px;
+ margin-bottom: 3px;
+}
+
+a.toc {
+color: rgb(25%, 60%, 25%);
+text-decoration: none;
+}
Modified: grass/branches/releasebranch_7_0/tools/mkhtml.py
===
--- grass/branches/releasebranch_7_0/tools/mkhtml.py2014-04-19
18:33:48 UTC (rev 59811)
+++ grass/branches/releasebranch_7_0/tools/mkhtml.py2014-04-19
18:38:08 UTC (rev 59812)
@@ -2,12 +2,12 @@
#
-# MODULE: mkhtml.py
+# MODULE: Builds manual pages
# AUTHOR(S):Markus Neteler
# Glynn Clements
# Martin Landa landa.martin gmail.com
# PURPOSE: Create HTML manual page snippets
-# COPYRIGHT:(C) 2007, 2009, 2011-2012 by Glynn Clements
+# COPYRIGHT:(C) 2007-2014 by Glynn Clements
#and the GRASS Development Team
#
# This program is free software under the GNU General
@@ -21,6 +21,7 @@
import string
import re
from datetime import datetime
+from HTMLParser import HTMLParser
pgm = sys.argv[1]
@@ -61,6 +62,7 @@
/html
)
+
def read_file(name):
try:
f = open(name, 'rb')
@@ -70,11 +72,101 @@
except IOError:
return
+
+def create_toc(src_data):
+class MyHTMLParser(HTMLParser):
+def __init__(self):
+self.reset()
+self.idx = 1
+self.tag_curr = ''
+self.tag_last = ''
+self.process_text = False
+self.data = []
+self.tags_allowed = ('h1', 'h2', 'h3')
+self.tags_ignored = ('img')
+self.text = ''
+
+def handle_starttag(self, tag, attrs):
+if tag in self.tags_allowed:
+self.process_text = True
+self.tag_last = self.tag_curr
+self.tag_curr = tag
+
+def handle_endtag(self, tag):
+if tag in self.tags_allowed:
+self.data.append((tag, '%s_%d' % (tag, self.idx),
+ self.text))
+self.idx += 1
+self.process_text = False
+self.text = ''
+
+
Re: [GRASS-dev] [GRASS-SVN] r59812 - in grass/branches/releasebranch_7_0: man tools
Hi, 2014-04-19 22:55 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: Martin, I'm not sure if this [59812] is appropriate because it is not stabilized yet [59816] and overall, it is a new feature although it is just in documentation. https://trac.osgeo.org/grass/changeset/59812 https://trac.osgeo.org/grass/changeset/59816 well, the goal was to introduce TOC to beta2. But you are right, it should be tested in the better way, there is none strong request for beta2: in beta1 addons are broken. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r59812 - in grass/branches/releasebranch_7_0: man tools
2014-04-19 23:00 GMT+02:00 Martin Landa landa.mar...@gmail.com: well, the goal was to introduce TOC to beta2. But you are right, it better to say a wish... Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r59812 - in grass/branches/releasebranch_7_0: man tools
Hi Vaclav, On Sat, Apr 19, 2014 at 10:55 PM, Vaclav Petras wenzesl...@gmail.com wrote: Martin, I'm not sure if this [59812] is appropriate because it is not stabilized yet [59816] and overall, it is a new feature although it is just in documentation. https://trac.osgeo.org/grass/changeset/59812 https://trac.osgeo.org/grass/changeset/59816 Martin was so kind to backport in upon my wish-request. So blame me :) We tested it on different browsers and different Linuxes, online and offline. Also, it is important to get beta2 out, and it should come with a better manual. No problem to them come up with a different approach as suggested by you and redo it again. But we don't know if JS will work while we have tested things with div so far. Small steps... So, don't worry that anyone wants to stop anyone else from revisiting the TOC mechanism completely :) But we need something now (and we have it). Newer approaches may evolve of course. Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
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 memory at %s:%d but does not have any idea when and why this happened and what to do about it. If the module calling G_malloc() had the chance to report error by itself, it could suggest to user to change some parameter or use a smaller map. It could, but 99% of the time it won't. Instead, it will either assume that the returned pointer is valid, or provide some vacuous message such as out of memory (without the reference to the source file, line number or requested size that is given at present). So in a handful of cases, you'd get a better error message, while the rest will be even worse. At least the current situation ensures that there are enough clues that the GRASS developers can provide assistance to the user upon request. When I replaced status returns with fatal errors in a number of core functions (r40209, r40217, r40701), in some of the cases where the function's return type changed from int to void, not a single error was generated; IOW, not one of the callers actually bothered to check whether the call succeeded. Similarly, in cases where an int/pointer return value could be negative or null to indicate an error, the cases where the (now redundant) error tests needed to be removed from the callers were often a minority, sometimes a very small minority, occasionally zero. With G_fatal_error(), the requirement for the caller to check for errors is removed, and with it the possibility that the caller will either fail to check for errors, or produce an entirely useless error message (although I think that we've now eliminated all of the G_fatal_error(oops!) cases; no, I'm not joking). 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 it is to use setjmp/longjmp (and contribute patches to make any intervening code exception-safe). -- 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-SVN] r59812 - in grass/branches/releasebranch_7_0: man tools
On Sat, Apr 19, 2014 at 5:10 PM, Markus Neteler nete...@osgeo.org wrote: Hi Vaclav, On Sat, Apr 19, 2014 at 10:55 PM, Vaclav Petras wenzesl...@gmail.com wrote: Martin, I'm not sure if this [59812] is appropriate because it is not stabilized yet [59816] and overall, it is a new feature although it is just in documentation. https://trac.osgeo.org/grass/changeset/59812 https://trac.osgeo.org/grass/changeset/59816 Martin was so kind to backport in upon my wish-request. So blame me :) We tested it on different browsers and different Linuxes, online and offline. Also, it is important to get beta2 out, and it should come with a better manual. No problem to them come up with a different approach as suggested by you and redo it again. But we don't know if JS will work while we have tested things with div so far. Small steps... So, don't worry that anyone wants to stop anyone else from revisiting the TOC mechanism completely :) But we need something now (and we have it). Newer approaches may evolve of course. All right then. I was not asking because of my JS proposal, but mainly because it is an exception to no-new-features policy. Anyway, I'm glad you work on manual now. Vaclav Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r59812 - in grass/branches/releasebranch_7_0: man tools
On Sat, Apr 19, 2014 at 11:26 PM, Vaclav Petras wenzesl...@gmail.com wrote: ... All right then. I was not asking because of my JS proposal, but mainly because it is an exception to no-new-features policy. I am not aware that we are in feature freeze mode. We have a beta1 which some people even did not want to see and call it tech preview (whatever that is). Due to the release history the word beta was chosen as it existed since 4.2.1betaX (that was back in 1998 or so). Some others even don't want the releasebranch_7_0 at all... Rather than freezing development altogether, especially keeping the goodies away from the normal user I prefer to keep the ball rolling and go on. We should really not discuss every minor backport, at least I have no time for that. Anyway, I'm glad you work on manual now. Yes, the scope is to de-ugly-fy it a bit. Much more could be done, especially adding examples (hey power-users, please donate some, even here in the list!). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
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 it is to use setjmp/longjmp (and contribute patches to make any intervening code exception-safe). As I wrote before, I hope that RPC approach suggested here by Soeren will work for languages with exceptions and for persistent applications while GRASS modules will benefit from the advantages of GRASS library with G_fatal_error() with exit(). Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Vaclav Petras wrote: 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 fatal errors. The reason is to avoid pushing the burden of error handling onto their callers. The fact is that no library should use exit() or similar things if it wants to be general. GRASS library is intended to be used only for building GRASS modules, thus it is specialized for them, thus it uses G_fatal_error() with exit(). (At least there is a believe that exit makes it easier.) It's not exit() per se, but the __attribute__((noreturn)) semantics which makes things easier. IOW, calling G_fatal_error() ensures that the remainder of the function will not be executed, and control will not be returned to the caller. Calling abort() or longjmp() or or anything else which doesn't return would work equally well. Essentially, G_fatal_error() generates an exception, something which escapes from the normal flow of control. It's sometimes referred to as the Samurai Principle: return victorious, or don't return at all. Note that libpng uses the same idiom. By default, errors result in a longjmp(); the caller must use setjmp() to register an error handler. If you compile with PNG_NO_SETJMP (or don't use setjmp), it uses PNG_ABORT(), which calls abort(). This can be overridden, subject to a constraint which should be familiar by now: You can #define PNG_ABORT() to a function that does something more useful than abort(), as long as your function does not return. As a result using GRASS functions outside the scope of GRASS modules requires another library. It would be nice to have two libraries, one for GRASS modules (with exit()) and one for everybody else. Hopefully, it would be possible to share the same code to some extent. Alternative is to use the RPC wrapper as suggested earlier by Soeren, as far as I understand this has the same result. The questions are what is less work, less duplication, what has easier maintenance and what is easier to do for all the platforms. 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 state held on the server, e.g. any open maps no longer exist. Using setjmp/longjmp would be more useful, but it would require some effort to add clean-up code to functions so that core data structures aren't left in an inconsistent state. E.g. rather than sequentially overwriting the fields of a structure with values obtained from functions which can generate a fatal error, you first obtain the values and store them in variables, then fill in the structure last, so that a failure doesn't result in a structure which is only partially updated. -- 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 QGIS: the future
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 state held on the server, e.g. any open maps no longer exist. Exactly! Hence the wrapper will not only do simple function wrapping, it will also implement a higher level interface: * map metadata read access as single client function will do on the server side: open map; read metadata; close map; send data * fast raster and vector map read access as single client function will do on server side: open map; read requested map into memory based on bounding box and render resolution; close map; send data * vector editing: keep a single vector map in update state open in a dedicated grass vector editing process. In case of a fatal error, this map may be lost or corrupted. It is important that this process will not be used for other purposes than single vector map editing. * vector analysis functionality that need to keep vector maps open in read only state for fast topological access. Information's about the open vector maps (i. e. the position of the next line to be read) may be lost in case the server process terminates. * Same for raster map analysis The client will detect if the server was terminated and will raise an exception. In QGIS that will be the data provider classes. The dedicated raster display module in QGIS is a nice starting point to implement a RPC function that will read a raster map as RGB color array based on extent and resolution information into a byte array that will be send via thrift (using thrift binary protocol) to the client. The RPC interface should only support meaningful functions to be used in a GUI, that's its only purpose. It should not be used to implement processing algorithms or GRASS modules. But it will in addition provide capabilities to use several processes to read different chunks of the same map in the GUI, hence parallel read only map access. This can be nicely done using a pool of GRASS server processes. Using setjmp/longjmp would be more useful, but it would require some effort to add clean-up code to functions so that core data structures aren't left in an inconsistent state. There are plenty of functions using global variables in GRASS. Also, persistent applications may change the location and therefore the projection several times on run-time. Are the GRASS libraries able to handle this correctly? The suggested RPC server processes can be restarted in this case. Best regards Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] TOC in HTML manual pages
Vaclav Petras wrote: I'm excited about the new TOC in HTML manual pages. There are some styling issues (bullet for every second item), and looking to the HTML code, the generator is creating both table and ul which is not good. ul should be enough. A more significant issue is that it overlooks the fact that the HTML files are the source files for the Unix (nroff) manual pages, where a ToC is just pointless junk. Fixed in r59825. http://grass.osgeo.org/grass71/manuals/r.mapcalc.html Anyway, I've tried different approach and here is my prototype: Please don't end up breaking the Unix manual pages (again) in the process. Whatever you do, ensure that the generated HTML is actually conformant (to HTML 4 transitional); g.html2man isn't fault-tolerant. -- 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] Who wants GUI and who does not and why
On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
