On Fri, Apr 18, 2014 at 6:43 PM, Glynn Clements 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 r
On Fri, Apr 18, 2014 at 6:59 PM, Glynn Clements 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
Vaclav Petras wrote:
> Note that for C/C++ code we have a similar issue. In the source code,
> includes are in `include` but in distribution they are in `include/grass`
> so you have to do
>
> #include grass/raster.h
>
> but if you are editing source code in some clever editor and you want to
>
FYI
-- Forwarded message --
From: Alex Mandel
Date: Fri, Apr 18, 2014 at 6:39 PM
Subject: [OSGeo-Discuss] Downtime Notice for many OSGeo Hosted sites
To: OSGeo Discussions
Cc: grass-user , qgis-developer
, "mapserver-us...@lists.osgeo.org"
, OpenLayers User list
The following
Radim Blazek 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 err
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_err
Markus Neteler wrote:
> The next limit would be the operating system. Default Linux allows
> 1024 files to be opened, which can be increased in
> /etc/security/limits.conf
Note that, in 7.0, each raster map requires two open files: one for
the cell/fcell file, one for the null bitmap.
FWIW, on
#2257: Clicking on layer group in layer manager gives error
--+-
Reporter: wenzeslaus| Owner: grass-dev@…
Type: defect| Status: new
Priority:
On Fri, Apr 18, 2014 at 10:44 AM, Martin Landa wrote:
> > The same layout for src and dist would be good for editing because then
> > editors, python and other tools can just use the layout in src and it
> will
> > work. This would mean that things which are now in `lib/python` should
> go to
> >
#2254: Option to save bivariate scatterplot as svg file
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Mil
Hi,
2014-04-18 11:15 GMT+02:00 Pietro :
> I would like to split GRASS in three main parts:
> - grass-lib
> - grass-cli
> - grass-gui
I was thinking about splitting `grass` package at least manually for
OSGeo4W framework. This idea makes sense to me. Martin
Hi,
2014-04-17 21:30 GMT+02:00 Vaclav Petras :
> I'm for the reform. Please, consider also other related issues.
great :-)
> The same layout for src and dist would be good for editing because then
> editors, python and other tools can just use the layout in src and it will
> work. This would me
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
#2255: g.mlist warnings for layers found in other mapsets
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | M
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
Let me try to clarify with an example. Suppose I have two different
mapsets, Ethiopia and Ethiopiabackup, each with a number of layers with the
same name. Now, if I use (just selecting 1 layer to keep the example short):
*g.mlist type=rast pattern=fireprob_rf1 mapset=Ethiopia*
Gives me:
*fire
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
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 Pro
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
#2256: No projection for web service layer
+---
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: major
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
#2255: g.mlist warnings for layers found in other mapsets
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | M
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 w
In Ubuntu, I could expand the number of opened files by:
#PCA will require the extension of ulimit for open files in Ubuntu
sudo vi /etc/security/limits.conf
#There you should enter:
#usernamehardnofile 65000
#usernamesoftnofile 1
#before # En
Hi,
2014-04-18 11:31 GMT+02:00 Radim Blazek :
[]
> 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 funct
#2255: g.mlist warnings for layers found in other mapsets
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | M
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 Vaclav,
actually I'm a bit more extremist... :-)
I would like to split GRASS in three main parts:
- grass-lib
- grass-cli
- grass-gui
often we have these things mixed to each other, for example a lot of
GRASS modules implement functions that could be moved to grass/lib
(e.g. r.stats). I would
#2047: GRASS doesn't build on FreeBSD
-+--
Reporter: lbartoletti | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.4
#2254: Option to save bivariate scatterplot as svg file
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Mil
#2224: Raster names bivariate scatterplot on axes
--+-
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: closed
Priority: normal | Milest
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: reopened
Priority: critical | Milesto
#2138: winGRASS6.4.svn - addon python script status?
--+-
Reporter: hellik | Owner: martinl
Type: defect | Status: closed
Priority: critical | Milesto
36 matches
Mail list logo
