Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Hamish]

Glynn:

>>>  Batch files are a better solution, as they don't affect anything else,
>>>  and it's a simple matter to either delete them or modify PATH to
>>>  ignore them, and use the Python scripts directly.

MMetz:
>>  Sounds good.

Martin:
> I am not sure, what about user scripts?

a new g.batwrap helper program (written in C) to create a .bat wrapper and
put it in the same dir as the target python script?

> It's easier to check if the file is a python script and if so than to
> force to use bundled version of Python. This seems to be a better
> workarround than using bat files.

what would do the checking, g.parser.exe? remember that any solution also needs 
to work 100% from the command line too, so having the GUI's pseudo-command line 
taking care of those things is not a real solution. Even if a user never uses 
the command line on Windows, they will at some point run into the old 
script-called-from-another-script problem.

?


regards,
Hamish

ps- this part of g.extension.py is fundamentally broken:
  line = line.replace("%GISBASE%", "%GRASS_ADDON_PATH%") # options['prefix'])

It's equivalent to trying to do  s+/usr/bin/+$PATH/+  and then run 
"$PATH/g.module". The approach used in g.extension.sh is to split 
$GRASS_ADDON_PATH and use the first dir in the list as "$GRASS_ADDON_PATH1", 
and then use that dir as the first-choice userland exedir destination.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Martin Landa]

Hi,

2014-04-23 21:56 GMT+02:00 Markus Metz :

>> Batch files are a better solution, as they don't affect anything else,
>> and it's a simple matter to either delete them or modify PATH to
>> ignore them, and use the Python scripts directly.
>
> Sounds good.

I am not sure, what about user scripts? It's easier to check if the
file is a python script and if so than to force to use bundled version
of Python. This seems to be a better workarround than using bat files.
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] Handling of Python scripts on MS Windows

[Markus Metz]

On Wed, Apr 23, 2014 at 1:37 AM, Glynn Clements
 wrote:
>
> Markus Metz wrote:
>
>> Therefore it is IMHO not a good idea to rely on a system-wide Python
>> file association on MS Windows,
>
> Regardless of whether or not it's a good idea, it's not entirely
> avoidable.

Sure it is.
>
> If a process "executes" a command using the system's interfaces
> (system(), CreateProcess(), subprocess.Popen(), batch files, etc), and
> that command refers to a Python script, the registry's .py file
> association *will* be used.

You ignore my suggestion to use .bat files calling the embedded script
interpreter, like in GRASS 6.

>
>> and therefore I propose to use the
>> embedded Python version already coming for some years with the
>> WinGRASS installer.
>
> You can only force the use of a specific Python interpreter when
> you control the execution mechanism. Otherwise, the system's file
> associations will be used.

You ignore my suggestion to use .bat files calling the embedded script
interpreter, like in GRASS 6.

>
> Users who aren't willing to live within whatever walled garden you
> provide will have to have a valid system-wide Python installation. In
> that situation, that installation should be used always, not just for
> those cases where you can't interpose your workaround.

You missed the point. I do not want to use a walled garden. Just set
the GRASS environment as currently done and off you go (with .bat
files, not with .py files).

>>
>> I suspect the whole discussion boils down to the question whether we
>> can rely on GRASS-compatible Python file associations on MS Windows or
>> not. I say, we can not.

[Your answer here]

>
> For me, the discussion boils down to:
>
> 1. How invasive is this workaround going to be with regard to the rest
> of GRASS?

For using system-wide .py file associations, nobody tried, so nobody
knows, thus maximal.
>
> 2. How easy is it to disable this workaround and just use the system
> Python instead?.

IMHO an invalid question because an existing Python file association
on MS Windows can change or disappear any time, and a GRASS
installation will not be notified about this change.

>
> Batch files are a better solution, as they don't affect anything else,
> and it's a simple matter to either delete them or modify PATH to
> ignore them, and use the Python scripts directly.

Sounds good.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2262: t.create fails when mapset name contains a dash

[GRASS GIS]

#2262: t.create fails when mapset name contains a dash
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Temporal  | Version:  svn-trunk
 Keywords:  t.create, mapset  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by huhabla):

 Oh, i didn't saw that coming. I need to re-implement the map register name
 creation for space time datasets.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2263: t.register use fp range for CELL maps

[GRASS GIS]

#2263: t.register use fp range for CELL maps
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  minor |   Milestone:  7.0.0
Component:  Temporal  | Version:  svn-trunk
 Keywords:  t.register, CELL  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:2 huhabla]:
 > This warning is emitted by Rast_read_range() in lib/raster/range.c and
 will only appear in case there is no data in a raster map.

 right, see #2264

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2263: t.register use fp range for CELL maps

[GRASS GIS]

#2263: t.register use fp range for CELL maps
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  minor |   Milestone:  7.0.0
Component:  Temporal  | Version:  svn-trunk
 Keywords:  t.register, CELL  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by huhabla):

 This warning is emitted by Rast_read_range() in lib/raster/range.c and
 will only appear in case there is no data in a raster map.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2264: t.rast.univar fails when r.univar fails

[GRASS GIS]

#2264: t.rast.univar fails when r.univar fails
-+--
 Reporter:  martinl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Temporal | Version:  svn-trunk
 Keywords:  t.rast.univar, r.univar  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 t.rast.univar fails when called r.univar prints no output

 {{{
 Traceback (most recent call last):
   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/scripts/t.rast.univar", line 67, in 
 main()
   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/scripts/t.rast.univar", line 63, in main
 "strds", input, where, extended, header, fs)
   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/temporal/univar_statistics.py", line 86, in
 print_gridded_dataset_univar_statistics
 string += fs + str(stats["mean"]) + fs + str(stats["min"])
 KeyError: 'mean'
 }}}

 attachment:univar.diff prints a warning

 {{{
 WARNING: Unable to get statistics for raster map
 
 }}}

 Actually commands fail when the map contains no data:

 {{{
 r.info terra_lst_day20020206
 ...
 |   Range of data:min = -nan  max = -nan
 |
 ...
 }}}

 ->

 {{{
 r.univar terra_lst_day20020206 --q
 }}}

 no output printed. It should fail or better to print 'nan' values.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2263: t.register use fp range for CELL maps

[GRASS GIS]

#2263: t.register use fp range for CELL maps
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  minor |   Milestone:  7.0.0
Component:  Temporal  | Version:  svn-trunk
 Keywords:  t.register, CELL  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
Description changed by martinl:

Old description:

> When registering CELL maps by `t.register`, the command print warning
>
> {{{
> WARNING: Unable to read fp range file for
> }}}

New description:

 When registering CELL maps by `t.register`, the command prints warning

 {{{
 WARNING: Unable to read fp range file for <...>
 }}}

--

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2263: t.register use fp range for CELL maps

[GRASS GIS]

#2263: t.register use fp range for CELL maps
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  minor |   Milestone:  7.0.0
Component:  Temporal  | Version:  svn-trunk
 Keywords:  t.register, CELL  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
 When registering CELL maps by `t.register`, the command print warning

 {{{
 WARNING: Unable to read fp range file for
 }}}

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2262: t.create fails when mapset name contains a dash

[GRASS GIS]

#2262: t.create fails when mapset name contains a dash
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Temporal  | Version:  svn-trunk
 Keywords:  t.create, mapset  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
 Steps to reproduce:

 {{{
 g.mapset -c mapset-test
 }}}

 {{{
 t.connect database=/opt/grassdata/nc_spm_08_grass7/mapset-
 test/tgis/sqlite.db
 }}}

 {{{
 t.create output=test title="test" desc="test"

 CREATE TABLE  test_mapset-test_raster_register (
   id VARCHAR NOT NULL, -- This colum is a primary key storing the
 registered raster map.ids
   PRIMARY KEY (id)
 );
 CREATE INDEX test_mapset-test_raster_register_index ON test_mapset-
 test_raster_register (id);INSERT INTO strds_base ( name  ,creator  ,mapset
 ,creation_time  ,modification_time  ,temporal_type  ,id  ,semantic_type )
 VALUES ('test' ,'landa' ,'mapset-test' ,'2014-04-23 19:35:19.818196'
 ,'2014-04-23 19:35:19.818210' ,'absolute' ,'test@mapset-test' ,'mean') ;
 INSERT INTO strds_absolute_time ( start_time  ,granularity  ,id  ,map_time
 ,end_time ) VALUES (NULL ,NULL ,'test@mapset-test' ,NULL ,NULL) ;
 INSERT INTO strds_spatial_extent ( north  ,bottom  ,west  ,top  ,proj
 ,east  ,id  ,south ) VALUES (NULL ,NULL ,NULL ,NULL ,'XY' ,NULL ,'test
 @mapset-test' ,NULL) ;
 INSERT INTO strds_metadata ( max_min  ,description  ,ewres_min  ,title
 ,min_max  ,nsres_min  ,nsres_max  ,number_of_maps  ,raster_register
 ,command  ,min_min  ,ewres_max  ,id  ,max_max  ,aggregation_type ) VALUES
 (NULL ,'test' ,NULL ,'test' ,NULL ,NULL ,NULL ,NULL ,'test_mapset-
 test_raster_register' ,'# 2014-04-23 19:35:19
 t.create output="test" title="test" desc="test"
 ' ,NULL ,NULL ,'test@mapset-test' ,NULL ,NULL) ;

   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/scripts/t.create", line 83, in 
 main()
   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/scripts/t.create", line 79, in main
 semantic, None, grass.overwrite())
   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/temporal/open_stds.py", line 169, in
 open_new_space_time_dataset
 sp.insert(dbif)
   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/temporal/abstract_space_time_dataset.py", line 367,
 in insert
 dbif.execute_transaction(statement)
   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/temporal/core.py", line 955, in execute_transaction
 self.cursor.executescript(statement)
 sqlite3.OperationalError: near "-": syntax error
 }}}

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2223: v.buffer flags -s and -c not working(?)

[GRASS GIS]

#2223: v.buffer flags -s and -c not working(?)
-+--
 Reporter:  jbrauner |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:  v.buffer |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:3 jbrauner]:
 > Isn't at least winGRASS (sorry my Linux box is broken at the moment)
 compiled with GEOS support? As far as I can conclude from the build
 information (see below) and the extended

 yes, it's compiled with GEOS support.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2261: failed pygrass doctest

[GRASS GIS]

#2261: failed pygrass doctest
-+--
 Reporter:  lucadelu |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.1.0
Component:  Python   | Version:  svn-trunk
 Keywords:  pygrass doctest  |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by lucadelu):

 Please try with a trunk version major of r59907 and a clean
 [http://grass.osgeo.org/sampledata/north_carolina/nc_basic_spm_grass7.tar.gz
 nc basic location]

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2261: failed pygrass doctest

[GRASS GIS]

#2261: failed pygrass doctest
-+--
 Reporter:  lucadelu |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.1.0
Component:  Python   | Version:  svn-trunk
 Keywords:  pygrass doctest  |Platform:  All  
  Cpu:  Unspecified  |  
-+--
 I spend a while to test the doctest of pygrass.

 I fixed several, but there are still some broken. Please check the
 following files

 {{{
 modules/shortcuts.py
 modules/grid/grid.py
 raster/__init__.py
 raster/abstract.py
 raster/category.py
 raster/history.py
 vector/__init__.py
 vector/find.py
 }}}

 When all the doctest will work we should backport to release branch 70

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2260: wxGUI: encoding error in French locale when trying to delete layer with opacity level set

[GRASS GIS]

#2260: wxGUI: encoding error in French locale when trying to delete layer with
opacity level set
+---
 Reporter:  mlennert|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  wxGUI   | Version:  unspecified  
 Keywords:  wxGUI opacity encoding  |Platform:  Unspecified  
  Cpu:  Unspecified |  
+---

Comment(by annakrat):

 Please try r59906 in trunk and following commits in branches.

-- 
Ticket URL: 
GRASS GIS 

___
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

[Sören Gebbert]

Hi Radim,

2014-04-23 14:50 GMT+02:00 Radim Blazek :
> On Tue, Apr 22, 2014 at 4:49 PM, Sören Gebbert
>  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
 C-modules. But there is a solution for persistent applications, called
 Remote Procedure Call (RPC), more below.
>>>
>>> It sounds interesting but it seems to be a huge work an far future. I
>>
>> Its far less work then modifying GRASS libraries to run with
>> persistent applications.
>
> We have already the providers and the plugin working with GRASS 6, I
> just want to upgrade it to GRASS 7. The only problem I found so far is
> that G__get_window() and Rast_get_cellhd() call G_fatal_error(). I can
> only dedicate few hours/max days of my free time to that, so I have to
> consider well what is less work, RPC is not.

Yes, i absolutely understand this.

>
>> We need
>> such an approach anyway, since vector editing is a GUI task -> GUI is
>> a persistent
>> application -> we need an exit safe interface to the GRASS libraries
>> to implement a reliable
>> vector editing GUI in GRASS itself.
>
> 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(), G_malloc() and G_realloc() will call
G_fatal_error() in case the memory allocation fails. As far as i can
tell the vector library make often use of this functions. So we have
the problem that basic core functions call G_fatal_error() that are
used all over the place in GRASS GIS.

>
>>> am also concerned about complexity, e.g. starting / keeping running
>>> servers on various platforms. I can imagine endless bug reports about
>>> "server not running". I am looking for something which will not
>>
>> Since only QGIS is spawning the "server" process, it is always able to
>> check if the
>> process is running and can restart it when needed. We already make use
>> of this concept in GRASS
>> and it works nicely[1]. Spawning of processes and keeping track of
>> them is an easy task with Qt,
>> and it is completely OS independent. The Qt Bitcoin client for example
>> makes use of RPC
>> and runs on Windows, Mac OS and various Linux systems. So i don't see
>> a problem here.
>
> The raster provider is already using something like that. Raster data
> are read from executed GRASS module output (a module written for that
> in QGIS in fact) and identify tool keeps another GRASS module running
> and it is communicating with that through a  pipe. I wrote that as an
> experiment and because I know, how much unnecessary additional code
> and potential problems it is, I don't want to continue in that
> direction.

Ok.

>
>>> require permanent assistance. It is not KISS enough for me.
>>
>> What would be a better KISS solution?
>>
>> IMO the RPC approach will make the implementation of the QGIS-GRASS
>> data provider and the
>> plugin simpler. There will be no mixing of C++ and C-code anymore.
>
> We are no starting the plugin from scratch, it is already written, we
> just need to make it work with GRASS 7.
>
>> No setjmp/longjmp/exception workaround that is really complex
>
> Why?

If you patch GRASS to use setjmp/longjmp to implement an exception
like behavior then you need to write clean up code for static
variables and dynamically allocated memory. A G_fatal_error() call can
be deeply nested in a library function. Cleaning only the static
variables to be in usable state will lead to problematic memory leaks.
So it is a complex task in GRASS.

Using setjmp/longjmp in QGIS wrapping all GRASS functions that might
call G_fatal_error() is complex, since a G_fatal_error() call can be
deeply nested in a library function. You need to keep track of this
resulting in plenty setjmp wrappers around GRASS functions.
You need to cleanup global static structures as well and you will have
no control over pointers pointing to dynamic allocated memory that got
lost in a longjmp.

IMHO booth cases require plenty of work to make them usable.

Having a kind of garbage collector in GRASS, implemented in the
G_*alloc() functions, may solve many problems. But i have no idea
howto implement the garbage collector to detect pointers that got
orphaned in a longjmp to automagically clean them.

The next step would be to centralize global variables to clean them up
more easily (as Glynn mentioned).

>
>> and will not prevent QGIS from
>> terminating or segfaulting eventually in case of a fatal error.
>
> Why?

Because of the undefined state of global variables and structures and
because of potential memory leaks that may sum up making QGIS
unusable.

Best regards
Soeren

>
> Radim
>
>> The QGIS GRASS data provider/plugin will be a clean C++ implementation
>> using the thrift library.
>

Re: [GRASS-dev] GRASS & QGIS: the future

[Radim Blazek]

On Wed, Apr 23, 2014 at 10:09 AM, Paolo Cavallini  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 and editing
>> The Processing plugin is good for users who don't want to use GRASS
>> data format at all. The GRASS plugin is GRASS GUI alternative for true
>> GRASS users.
>
> Yes, got it. The question is: what is the real advantage to use grass
> alone, instead of jointly with other tols in Processing?

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.

> I see two major ones:
> * Processing is blocking the main QGIS canvas, which for very long
> analyses is unacceptable
> * import-export overhead is a serious issue for complex vectors.

There is the GRASS Direct lib which allows GRASS raster modules to
read/write data through QGIS providers. I is currently disabled, needs
some fixes but it was mostly working. If fixed, it can be easily used
in Processing, I think.

Radim
___
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

[Radim Blazek]

On Tue, Apr 22, 2014 at 4:49 PM, Sören Gebbert
 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
>>> C-modules. But there is a solution for persistent applications, called
>>> Remote Procedure Call (RPC), more below.
>>
>> It sounds interesting but it seems to be a huge work an far future. I
>
> Its far less work then modifying GRASS libraries to run with
> persistent applications.

We have already the providers and the plugin working with GRASS 6, I
just want to upgrade it to GRASS 7. The only problem I found so far is
that G__get_window() and Rast_get_cellhd() call G_fatal_error(). I can
only dedicate few hours/max days of my free time to that, so I have to
consider well what is less work, RPC is not.

> We need
> such an approach anyway, since vector editing is a GUI task -> GUI is
> a persistent
> application -> we need an exit safe interface to the GRASS libraries
> to implement a reliable
> vector editing GUI in GRASS itself.

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.

>> am also concerned about complexity, e.g. starting / keeping running
>> servers on various platforms. I can imagine endless bug reports about
>> "server not running". I am looking for something which will not
>
> Since only QGIS is spawning the "server" process, it is always able to
> check if the
> process is running and can restart it when needed. We already make use
> of this concept in GRASS
> and it works nicely[1]. Spawning of processes and keeping track of
> them is an easy task with Qt,
> and it is completely OS independent. The Qt Bitcoin client for example
> makes use of RPC
> and runs on Windows, Mac OS and various Linux systems. So i don't see
> a problem here.

The raster provider is already using something like that. Raster data
are read from executed GRASS module output (a module written for that
in QGIS in fact) and identify tool keeps another GRASS module running
and it is communicating with that through a  pipe. I wrote that as an
experiment and because I know, how much unnecessary additional code
and potential problems it is, I don't want to continue in that
direction.

>> require permanent assistance. It is not KISS enough for me.
>
> What would be a better KISS solution?
>
> IMO the RPC approach will make the implementation of the QGIS-GRASS
> data provider and the
> plugin simpler. There will be no mixing of C++ and C-code anymore.

We are no starting the plugin from scratch, it is already written, we
just need to make it work with GRASS 7.

> No setjmp/longjmp/exception workaround that is really complex

Why?

> and will not prevent QGIS from
> terminating or segfaulting eventually in case of a fatal error.

Why?

Radim

> The QGIS GRASS data provider/plugin will be a clean C++ implementation
> using the thrift library.
> It will be better maintainable since developers do not need to know
> all the different
> GRASS libraries (gis, raster, vector, database) but only the RPC
> interface that make
> use of a subset of the GRASS library functions, bundling them in an
> object oriented API.
> QGIS do not need to link against GRASS libraries anymore, future GRASS
> versions will be supported out of the box.
>
> This is much more KISS then the current approach.
>
> Best regards
> Soeren
>
> [1] 
> http://grass.osgeo.org/programming7/namespacepython_1_1temporal_1_1c__libraries__interface.html
>>
>> Radim
>>
>>> 2014-04-18 11:31 GMT+02:00 Radim Blazek :
 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 life harder
 for anyone trying to use the GRASS libraries" [1]. 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 again about
 hacks we can use:

 1) add a requirement that GRASS 7 used with QGIS must be compiled with
 -fexceptions

 2) add a requirement that a patch (it is a single line comment in
 fact) must be applied to GRASS 7 to make it usable with QGIS

 3) use setjmp()/longjmp()

 4) let QGIS crash whenever GRASS lib function fails
>>>
>>> I fear that none of these suggestions are good working solutions,
>>> since in case a fatal error or a segfault occurs nothing (no
>>> exception, no setjmp) will prevent QGIS from crashing. So i would like
>>> to suggest the following:
>>>
>>> 5.) Using a RPC interface for map metadata, vector and raster map
>>> ac

Re: [GRASS-dev] GRASS & QGIS: the future

[Radim Blazek]

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 advantage over longjmp()?

I don't know, probably no.

Radim
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS 7.0.0beta2 released

[Moritz Lennert]

On 23/04/14 09:18, Markus Neteler wrote:

We are pleased to announce the second beta release of a new version of
GRASS GIS 7.0.0.

See also our detailed announcement:
http://trac.osgeo.org/grass/wiki/Release/7.0.0beta-News

Source code package:
http://grass.osgeo.org/grass70/source/
-> grass-7.0.0beta2.tar.gz

SVN branch:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0

SVN tag:
http://trac.osgeo.org/grass/browser/grass/tags/release_20140420_grass_7_0_0beta2

Please test on "any" platform.


Compilation and first rapid test shows no problems on Debian Testing 
(except for #2260 just reported, but which is valid for all branches). 
No time for more just now.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2260: wxGUI: encoding error in French locale when trying to delete layer with opacity level set

[GRASS GIS]

#2260: wxGUI: encoding error in French locale when trying to delete layer with
opacity level set
+---
 Reporter:  mlennert|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  wxGUI   | Version:  unspecified  
 Keywords:  wxGUI opacity encoding  |Platform:  Unspecified  
  Cpu:  Unspecified |  
+---
 {{{
 > locale
 LANG=fr_BE
 LANGUAGE=fr_BE
 LC_CTYPE=fr_BE.UTF-8
 LC_NUMERIC=C
 LC_TIME=fr_BE.UTF-8
 LC_COLLATE=fr_BE.UTF-8
 LC_MONETARY=fr_BE.UTF-8
 LC_MESSAGES=fr_BE.UTF-8
 LC_PAPER=fr_BE.UTF-8
 LC_NAME=fr_BE.UTF-8
 LC_ADDRESS=fr_BE.UTF-8
 LC_TELEPHONE=fr_BE.UTF-8
 LC_MEASUREMENT=fr_BE.UTF-8
 LC_IDENTIFICATION=fr_BE.UTF-8
 LC_ALL=
 }}}


 - Add a layer.

 - Set its opacity level.

 - Try to delete the layer from the layer manager:


 {{{
 Traceback (most recent call last):
   File
 "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/gui/wxpython/lmgr/frame.py", line
 2050, in OnDeleteLayer

 name = str(self.GetLayerTree().GetItemText(item))
 UnicodeEncodeError
 :
 'ascii' codec can't encode character u'\xe9' in position 19:
 ordinal not in range(128)
 }}}

 Bug present in all branches.

-- 
Ticket URL: 
GRASS GIS 

___
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

[Sören Gebbert]

2014-04-20 11:38 GMT+02:00 Martin Landa :
> Hi,
>
> 2014-04-20 1:34 GMT+02:00 Sören Gebbert :
>
>> 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... ?

https://trac.osgeo.org/grass/wiki/Grass7/RPCInterface

>
> 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 GIS] #2223: v.buffer flags -s and -c not working(?)

[GRASS GIS]

#2223: v.buffer flags -s and -c not working(?)
-+--
 Reporter:  jbrauner |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:  v.buffer |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by jbrauner):

 Replying to [comment:1 neteler]:
 > To my knowledge v.buffer only works properly when compiled with GEOS
 support.

 Isn't at least winGRASS (sorry my Linux box is broken at the moment)
 compiled with GEOS support? As far as I can conclude from the build
 information (see below) and the extended list of available operators for
 v.select it seems very likely to me. Sorry if this is an unqualified
 comment :)

 Cheers,

 Johannes


 {{{
 g.version -bre
 }}}
 {{{
 GRASS 7.1.svn (2014)
  ./configure [... snip ...] --with-
 geos=/c/osgeo4w/usr/src/grass_trunk/mswindows/osgeo4w/geos-config [...
 snip ...]
 libgis Revision: 59317
 libgis Date: 2014-03-24 20:38:32 +0100 (po, 24 III 2014)
 PROJ.4: 4.8.0
 GDAL/OGR: 1.10.1
 GEOS: 3.4.2
 SQLite: 3.7.17
 }}}

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS & QGIS: the future

[Paolo Cavallini]

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 intended final
> implementation.
> 
>> BTW, GRASS6 vectors apparently cannot be loaded from QGIS browser as a
>> whole.
>>
>> This, coupled with several serious regressions I found, may mean that
>> GRASS support in QGIS is essentially broken,
> 
> You are talking about GRASS 6 support? What are serious regressions?

* creating a new location is partly broken (cannot take the extent from
the canvas, at least for some projections); a minor issue, but a serious
concern for new users
* the region resolution cannot be changed interactively.

> 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 and editing
> The Processing plugin is good for users who don't want to use GRASS
> data format at all. The GRASS plugin is GRASS GUI alternative for true
> GRASS users.

Yes, got it. The question is: what is the real advantage to use grass
alone, instead of jointly with other tols in Processing?
I see two major ones:
* Processing is blocking the main QGIS canvas, which for very long
analyses is unacceptable
* import-export overhead is a serious issue for complex vectors.

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS GIS 7.0.0beta2 released

[Markus Neteler]

We are pleased to announce the second beta release of a new version of
GRASS GIS 7.0.0.

See also our detailed announcement:
http://trac.osgeo.org/grass/wiki/Release/7.0.0beta-News

Source code package:
http://grass.osgeo.org/grass70/source/
-> grass-7.0.0beta2.tar.gz

SVN branch:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0

SVN tag:
http://trac.osgeo.org/grass/browser/grass/tags/release_20140420_grass_7_0_0beta2

Please test on "any" platform.

The GRASS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev