Re: [GRASS-dev] [GRASS GIS] #1465: Out-of-place builds unsupported

2014-10-23 Thread GRASS GIS 
#1465: Out-of-place builds unsupported
-+--
 Reporter:  strk |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Compiling| Version:  svn-trunk
 Keywords:   |Platform:  Linux
  Cpu:  All  |  
-+--

Comment(by neteler):

 Some improvement done in r62246, see

 http://lists.osgeo.org/pipermail/grass-dev/2014-October/071293.html

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

2014-10-23 Thread Helmut Kudrnovsky 
Moritz Lennert wrote
> On 23/10/14 02:53, Vaclav Petras wrote:
>>
>>
>> On Wed, Oct 22, 2014 at 8:28 PM, Glynn Clements
>> <

> glynn@.plus

>   glynn@.plus

> >> wrote:
>>
>>
>> Martin Landa wrote:
>>
>> > > Given the history of the Python issue I shall not complain about
>> a missing Unix shell on Windows...
>> >
>> > switching to msys shell is easy, just change in env.bat file
>> >
>> > REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>> >
>> > to
>> >
>> > set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>> >
>> > Probably we could add new item to start menu as it's in G6.
>>
>> Does the Windows installer still contain MSys? If so, why?
>>
>> I'm afraid we have an issue with what we want. Do we want to remove msys
>> in favor of native command line or do we want to have msys available
>> because it is much better then the MS Windows native command line.
>>
>> I personally don't care much and I prefer whatever works better. (I'm
>> not using MS Windows, I have the real unix-like command line on my
>> system.)
> 
> For me the whole idea of the last 10 years of work on getting GRASS 
> usable on Windows was to get rid of the need of *nix emulation. Msys was 
> the last remnant of that, and if we can get rid of it and make GRASS 
> into a "real Windows native" than I'm all for it.
> 
> Moritz

FWIW I'm in favour for keeping it. 

although winGRASS is able to run without it, there are some nice and for
daily life useful gnu tools coming with msys  (e.g. grep ...), IMO it
doesn't harm to ship it with winGRASS.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/WinGRASS71svn-using-Windows-shell-not-bourne-shell-thogh-MSYS-is-installed-tp5168808p5169075.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2136: Create standard options for map or file base name (prefix)

2014-10-23 Thread GRASS GIS 
#2136: Create standard options for map or file base name (prefix)
-+--
 Reporter:  wenzeslaus   |   Owner:  grass-dev@…
  
 Type:  defect   |  Status:  new
  
 Priority:  blocker  |   Milestone:  7.0.0  
  
Component:  Parser   | Version:  svn-releasebranch64
  
 Keywords:  base name, prefix, basename  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by zarch):

 Replying to [comment:32 annakrat]:
 > If there are no objections, I will backport it so that
 > we can start to use it in modules. We just have to agree
 > on the default separator. We had some discussion about
 > it with Vaclav and Markus some time ago and one underscore
 > seems to be the best option.

 +1

 No objections from my side and one underscore it looks fine to me.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

2014-10-23 Thread Moritz Lennert 

On 23/10/14 09:44, Helmut Kudrnovsky wrote:

Moritz Lennert wrote

On 23/10/14 02:53, Vaclav Petras wrote:



On Wed, Oct 22, 2014 at 8:28 PM, Glynn Clements
<



glynn@.plus



  > wrote:



 Martin Landa wrote:

 > > Given the history of the Python issue I shall not complain about
a missing Unix shell on Windows...
 >
 > switching to msys shell is easy, just change in env.bat file
 >
 > REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
 >
 > to
 >
 > set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
 >
 > Probably we could add new item to start menu as it's in G6.

 Does the Windows installer still contain MSys? If so, why?

I'm afraid we have an issue with what we want. Do we want to remove msys
in favor of native command line or do we want to have msys available
because it is much better then the MS Windows native command line.

I personally don't care much and I prefer whatever works better. (I'm
not using MS Windows, I have the real unix-like command line on my
system.)


For me the whole idea of the last 10 years of work on getting GRASS
usable on Windows was to get rid of the need of *nix emulation. Msys was
the last remnant of that, and if we can get rid of it and make GRASS
into a "real Windows native" than I'm all for it.

Moritz


FWIW I'm in favour for keeping it.

although winGRASS is able to run without it, there are some nice and for
daily life useful gnu tools coming with msys  (e.g. grep ...), IMO it
doesn't harm to ship it with winGRASS.


http://sourceforge.net/projects/unxutils/ ?

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

[GRASS-dev] [GRASS GIS] #2460: v.out.postgis doesn't export attribute table

2014-10-23 Thread GRASS GIS 
#2460: v.out.postgis doesn't export attribute table
---+
 Reporter:  martin |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:   
Component:  Default| Version:  svn-trunk
 Keywords:  v.out.postgis  |Platform:  Linux
  Cpu:  x86-64 |  
---+
 Attribute table has one column.[[BR]]
 "v.out.ogr" creates a proper column in PostGIS accordingly,
 "v.out.postgis" doesn't.

 {{{
 GRASS 7.1.svn > v.out.postgis input=newcs_errorW_full type=area
 olayer=newcs_full_pg \
 dsn="PG:host=${PGHOST} dbname=${PGDATABASE} user=${PGUSER}" \
 options="FID=ogc_fid, GEOMETRY_NAME=wkb_geometry, SPATIAL_INDEX=YES,
 PRIMARY_KEY=YES, SRID=4326" \
 --verbose --overwrite
 WARNING: PostGIS layer  already exists and will be
  overwritten
 Using PostGIS format
 Building spatial index on ...
 Copying features (polygon)...
  100%
 Exporting areas...
  100%
 Building topology for vector map ...
 Using external data format 'PostgreSQL' (feature type 'polygon')
 Building pseudo-topology over simple features...
 Registering primitives...
 26401 primitives registered
 4296855 vertices registered
 Topology was built
 Number of nodes: 11427
 Number of primitives: 26401
 Number of points: 0
 Number of lines: 0
 Number of boundaries: 14330
 Number of centroids: 12071
 Number of areas: 14330
 Number of isles: 14330
 v.out.postgis complete. 12071 features (polygon type) written to
 .
 }}}


 {{{
 landcover=> \d newcs_full_pg
   Table "public.newcs_full_pg"
 Column|  Type  |
 Modifiers
 
--++-
  ogc_fid  | integer| not null default
 nextval('newcs_full_pg_ogc_fid_seq'::regclass)
  cat  | integer|
  wkb_geometry | geometry(Polygon,4326) |
 Indexes:
 "newcs_full_pg_pkey" PRIMARY KEY, btree (ogc_fid)
 "newcs_full_pg_cat_idx" btree (cat)
 "newcs_full_pg_wkb_geometry_idx" gist (wkb_geometry)
 }}}


 {{{
 GRASS 7.1.svn > v.out.ogr input=newcs_errorW_full type=area
 olayer=newcs_full_ogr format=PostgreSQL \
 dsn="PG:host=${PGHOST} dbname=${PGDATABASE} user=${PGUSER}" \
 --verbose --overwrite
 Warning 1: Multi-column primary key in 'fgs_overrides' detected but not
 supported.
 WARNING: OGR layer  already exists and will be overwritten
 Exporting 12071 areas (may take some time)...
  100%
 v.out.ogr complete. 12071 features (Polygon type) written to
  (PostgreSQL format).
 }}}


 {{{
 landcover=> \d newcs_full_ogr
Table "public.newcs_full_ogr"
 Column|  Type   |
 Modifiers
 
--+-+--
  ogc_fid  | integer | not null default
 nextval('newcs_full_ogr_ogc_fid_seq'::regclass)
  wkb_geometry | geometry(Polygon,4326)  |
  cat  | integer |
  pglayer  | character varying(1000) |
 Indexes:
 "newcs_full_ogr_pk" PRIMARY KEY, btree (ogc_fid)
 "newcs_full_ogr_geom_idx" gist (wkb_geometry)
 }}}

-- 
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] #2457: DBF driver: stub functions for SQL TRANSACTION

2014-10-23 Thread GRASS GIS 
#2457: DBF driver: stub functions for SQL TRANSACTION
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.5
Component:  Database | Version:  svn-releasebranch64  
 Keywords:  dbf, sql |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [comment:5 neteler]:
 > Replying to [comment:4 mlennert]:
 > > You still are missing the additions to the other files mentioned.
 >
 > Ops, right.
 > Updated patch attached, now it complains about double defined BEGIN...

 After running make in lib/db/sqlp/ there is a file lex.yy.c which has the
 following line 125:


 {{{
 #define BEGIN (yy_start) = 1 + 2 *
 }}}

 My wild guess is that this causes your problem, but I'm way out of my
 league here (don't even know where this line comes from in that file), so
 you would have to consult with a lex/yacc guru.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

2014-10-23 Thread Helmut Kudrnovsky 
Moritz Lennert wrote
>>
>> FWIW I'm in favour for keeping it.
>>
>> although winGRASS is able to run without it, there are some nice and for
>> daily life useful gnu tools coming with msys  (e.g. grep ...), IMO it
>> doesn't harm to ship it with winGRASS.
> 
> http://sourceforge.net/projects/unxutils/ ?
> 
> Moritz

keep in mind, someone has to maintain such things for winGRASS. as msys is
the winGRASS build environment, it's already there ...




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/WinGRASS71svn-using-Windows-shell-not-bourne-shell-thogh-MSYS-is-installed-tp5168808p5169112.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2296: r.stream.* - unify some functions (avoid code duplication)

2014-10-23 Thread GRASS GIS 
#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  |  
-+--
Changes (by neteler):

  * milestone:  7.1.0 => 7.0.0


Comment:

 Replying to [ticket:2296 hellik]:
 > 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

 The io.c and files I had sync'ed in r60127. Not sure if it is worth to
 move them into
 an own library.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

2014-10-23 Thread Margherita Di Leo 
Hi,

On Tue, Oct 7, 2014 at 6:22 PM, Martin Landa  wrote:

> Hi,
>
> 2014-10-07 17:32 GMT+02:00 Markus Neteler :
>
> [...]
>
> > Concerning the release branch of GRASS 7, in r59606 the r.stream.*
> > modules got disabled.
> > If they are not yet production ready, should we move them back to Addons?
>
> MarkusM: Is there any chance to fix them before releasing G70?
>
> If not I would suggest to move them back to Addons... Martin
>
>
> Can I urge please to take a decision, either ways.

Thank you,
madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

2014-10-23 Thread Markus Neteler 
On Thu, Oct 23, 2014 at 5:19 PM, Margherita Di Leo  wrote:
> On Tue, Oct 7, 2014 at 6:22 PM, Martin Landa  wrote:
>> 2014-10-07 17:32 GMT+02:00 Markus Neteler :
>>
>> [...]
>>
>> > Concerning the release branch of GRASS 7, in r59606 the r.stream.*
>> > modules got disabled.

Related:
http://trac.osgeo.org/grass/ticket/2296

>> > If they are not yet production ready, should we move them back to
>> > Addons?
>>
>> MarkusM: Is there any chance to fix them before releasing G70?
>>
>> If not I would suggest to move them back to Addons... Martin
>>
> Can I urge please to take a decision, either ways.

In case of moving them back to Addons, it would be r.stream.* except
for r.stream.extract.

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

Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

2014-10-23 Thread Martin Landa 
Hi,

2014-10-23 17:23 GMT+02:00 Markus Neteler :

>> Can I urge please to take a decision, either ways.
>
> In case of moving them back to Addons, it would be r.stream.* except
> for r.stream.extract.

any opinion from MarkusM who disabled r.streams.* modules in releasebranch_70?

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

[GRASS-dev] tests failed

2014-10-23 Thread Anna Petrášová 
Hi,

a lot of tests are failing:
http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html

it seems that

http://trac.osgeo.org/grass/changeset/62349

causes a lot failures. Problems are in some temporal modules, pygrass and
gunittests tests.

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

Re: [GRASS-dev] tests failed

2014-10-23 Thread Martin Landa 
Hi,

2014-10-23 21:10 GMT+02:00 Anna Petrášová :
> it seems that
>
> http://trac.osgeo.org/grass/changeset/62349
>
> causes a lot failures. Problems are in some temporal modules, pygrass and
> gunittests tests.

hm, Soeren/Pietro any idea why it fails? Thanks, 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] #2136: Create standard options for map or file base name (prefix)

2014-10-23 Thread GRASS GIS 
#2136: Create standard options for map or file base name (prefix)
-+--
 Reporter:  wenzeslaus   |   Owner:  grass-dev@…
  
 Type:  defect   |  Status:  new
  
 Priority:  blocker  |   Milestone:  7.0.0  
  
Component:  Parser   | Version:  svn-releasebranch64
  
 Keywords:  base name, prefix, basename  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by annakrat):

 I changed the default basename in r62364 and backported r61095 in r62366.

-- 
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] #2457: DBF driver: stub functions for SQL TRANSACTION

2014-10-23 Thread GRASS GIS 
#2457: DBF driver: stub functions for SQL TRANSACTION
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.5
Component:  Database | Version:  svn-releasebranch64  
 Keywords:  dbf, sql |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 > After running make in lib/db/sqlp/ there is a file lex.yy.c which has
 the following line 125:
 >
 {{{
 #define BEGIN (yy_start) = 1 + 2 *
 }}}
 >
 > My wild guess is that this causes your problem, but I'm way out of my
 league here (don't even know where this line comes from in that file),

 It's part of the boilerplate code which built into flex itself.

 The bottom line is that you can't use "BEGIN" as a token identifier
 (REJECT, ECHO and INITIAL are also unavailable; the other macro names are
 unlikely to result in innocent collisions). Add a trailing underscore or
 change the case to avoid a conflict.

 Also the patch attempts to define the TRANSACTION token twice:

 {{{
 %token BEGIN TRANSACTION
 %token COMMIT TRANSACTION
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

2014-10-23 Thread Glynn Clements 

Vaclav Petras wrote:

> I'm afraid we have an issue with what we want. Do we want to remove msys
> in favor of native command line or do we want to have msys available
> because it is much better then the MS Windows native command line.

Nothing stops the user from installing MSys if they want it. In fact,
users who are likely to want it may already have it installed, so we
shouldn't be installing a second copy (which may conflict with their
existing copy; even if it doesn't, they now have to configure and
maintain two copies).

We shouldn't be forcing it on people. Whether it's "better" isn't the
issue. It's not what Windows users will be familiar with. It's not
what's going to be described if users search for documentation on
"Windows command line".

GRASS 6 has to bundle MSys because GRASS 6 won't work without it. That
shouldn't be the case for GRASS 7.

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

Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

2014-10-23 Thread Vaclav Petras 
On Thu, Oct 23, 2014 at 7:08 PM, Glynn Clements 
wrote:

>
> Vaclav Petras wrote:
>
> > I'm afraid we have an issue with what we want. Do we want to remove msys
> > in favor of native command line or do we want to have msys available
> > because it is much better then the MS Windows native command line.
>
> Nothing stops the user from installing MSys if they want it. In fact,
> users who are likely to want it may already have it installed, so we
> shouldn't be installing a second copy (which may conflict with their
> existing copy; even if it doesn't, they now have to configure and
> maintain two copies).
>
> We shouldn't be forcing it on people. Whether it's "better" isn't the
> issue. It's not what Windows users will be familiar with. It's not
> what's going to be described if users search for documentation on
> "Windows command line".
>
> GRASS 6 has to bundle MSys because GRASS 6 won't work without it. That
> shouldn't be the case for GRASS 7.
>
> This sounds reasonable. If users want something better then what MS
provides they should install it, as you say, or they should install
different OS or use Python for scripting, I would say.

I would also oppose adding new items to the start menu if we would come to
this. Users are confused enough from the (already) provided options.

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

Re: [GRASS-dev] [GRASS GIS] #1681: WXGUI vector editing fails with python unicode error

2014-10-23 Thread GRASS GIS 
#1681: WXGUI vector editing fails with python unicode error
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  encoding |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Replying to [comment:4 annakrat]:
 > I extended the diff and it seems to work somehow so I committed it in
 r61897. Needs testing.

 Can this be backported?

-- 
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] #2150: Cannot call Python scripts from Python on MS Windows

2014-10-23 Thread GRASS GIS 
#2150: Cannot call Python scripts from Python on MS Windows
---+
 Reporter:  wenzeslaus |   Owner:  grass-dev@…  

 Type:  defect |  Status:  new  

 Priority:  blocker|   Milestone:  7.0.0

Component:  Python | Version:  svn-releasebranch64  

 Keywords:  packaging, MAXREPEAT, scripts  |Platform:  MSWindows 7  

  Cpu:  Unspecified|  
---+

Comment(by neteler):

 What is the state of this ticket? Can it be closed?

-- 
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] #2258: t.create creates DB always in the PERMANENT

2014-10-23 Thread GRASS GIS 
#2258: t.create creates DB always in the PERMANENT
-+--
 Reporter:  martinl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  Temporal | Version:  svn-releasebranch70  
 Keywords:  t.register   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Replying to [comment:14 huhabla]:
 > Work in progress. I have applied the patches from #2408 in r61956 and
 r61957. This is the basis for a larger patch, that enables distributed
 temporal datasets (patch is attached, but very experimental). I will
 switch to mapset specific temporal databases in case the new approach
 works stable.

 Is the attached patch the mentioned "larger patch"? What is the state of
 this ticket?

-- 
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] #2285: Repetitive d.rast calls for wx0 monitor from command line

2014-10-23 Thread GRASS GIS 
#2285: Repetitive d.rast calls for wx0 monitor from command line
---+
  Reporter:  hcho  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  7.0.0
 Component:  Display   | Version:  svn-trunk
Resolution:  fixed |Keywords:  d.mon
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by neteler):

  * status:  reopened => closed
  * resolution:  => fixed


Old description:

> I was drawing 168 raster maps on the wx monitor from a shell script:
> {{{
> #!/bin/sh
> maps=`g.mlist rast pattern="n[0-9]*w[0-9]*_1" sep=,`
> g.region rast=$maps res=00:01:00
> d.erase
> for i in `echo $maps | sed 's/,/ /g'`
> do
> d.rast $i
> done
> }}}
> after starting and selecting a wx monitor. I'm getting the following
> error messages and not all the raster maps are displayed:
> {{{
>  100%
>  100%
>  100%
>  100%
>  100%
>  100%
>  100%
> ERROR: No graphics device selected. Use d.mon to select graphics device.
> ERROR: No graphics device selected. Use d.mon to select graphics device.
> ERROR: No graphics device selected. Use d.mon to select graphics device.
>  100%
>  100%
>  100%
> }}}
>
> I digged into the wx monitor script (gui/wxpython/mapdisp/main.py
> DMonMap.Render) and found that it unsets MONITOR (because
> GRASS_RENDER_IMMEDIATE doesn't like monitors) before calling d.rast and
> then restores it:
> {{{
> currMon = grass.gisenv()['MONITOR']
>
> RunCommand('g.gisenv',
>unset = 'MONITOR') # GRASS_RENDER_IMMEDIATE doesn't
> like monitors
>
> ret = Map.Render(self, *args, **kwargs)
>
> RunCommand('g.gisenv',
> set = 'MONITOR=%s' % currMon)
> }}}
>
> So far, so good. Unfortunately, the wx monitor is running in a different
> process than d.rast calls from command line. Many d.rast calls cannot see
> the MONITOR variable while the monitor is rendering existing maps, which
> causes the above error.

New description:

 I was drawing 168 raster maps on the wx monitor from a shellsort() from http://trac.osgeo.org/grass/ticket/2285#comment:7>
GRASS GIS 

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