[GRASS-dev] [GRASS GIS] #2285: Repetitive d.rast calls for wx0 monitor from command line

GDAL · May 10, 2014, 1:47pm

#2285: Repetitive d.rast calls for wx0 monitor from command line
---------------------+------------------------------------------------------
Reporter: hcho | Owner: grass-dev@…
     Type: defect | Status: new
Priority: major | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Keywords: | Platform: Linux
      Cpu: x86-64 |
---------------------+------------------------------------------------------
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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285>
GRASS GIS <http://grass.osgeo.org>

GDAL · May 10, 2014, 1:49pm

#2285: Repetitive d.rast calls for wx0 monitor from command line
----------------------+-----------------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Keywords: | Platform: Linux
Cpu: x86-64 |
----------------------+-----------------------------------------------------
Changes (by hcho):

* priority: major => critical

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285#comment:1>
GRASS GIS <http://grass.osgeo.org>

GDAL · May 10, 2014, 4:42pm

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

* keywords: => d.mon

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285#comment:2>
GRASS GIS <http://grass.osgeo.org>

GDAL · May 13, 2014, 3:29am

#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 hcho):

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

Comment:

Fixed in r60215.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285#comment:3>
GRASS GIS <http://grass.osgeo.org>

GDAL · May 13, 2014, 6:47am

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

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

Comment:

I take liberty to reopen for backport to relbr7, especially since the
priority was "critical".

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285#comment:4>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 17, 2014, 9:43pm

#2285: Repetitive d.rast calls for wx0 monitor from command line
-----------------------+----------------------------------------------------
  Reporter: hcho | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: critical | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Resolution: | Keywords: d.mon
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------

Comment(by wenzeslaus):

I don't understand the whole concept behind `d.mon wx*` and how this
display architecture is supposed to work for GUI.

I would say that no variables for rendering inside GUI (including `d.mon
wx*`) should not use `os.environ` directly nor they should use `g.gisenv`
without creating a local copy of it first. The `env` parameter of `Popen`
object should be used for all environmental changes (custom GRASS GIS
file-based environment (rc file path) should be passed there too).

However, if you think you tested r60215 and that it make sense, you can
backport it at some point but I must say that `d.mon wx*` never guarantied
that it will work from a script and the fact that it works for you might
be just luck. Also batch rendering in general is for anyway only for
advanced users which may notice that they should not play with `d.mon` and
`g.gui` at the same time, in other words I don't think this is so
critical.

But don't take me wrong, I'm annoyed by this too, and I want to use `d.mon
wx*` from my scripts and with my scripts, so I'm happy to see r60215 and
also r60376 (change environment only for subprocesses).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285#comment:5>
GRASS GIS <http://grass.osgeo.org>

GDAL · July 23, 2014, 12:06pm

#2285: Repetitive d.rast calls for wx0 monitor from command line
-----------------------+----------------------------------------------------
  Reporter: hcho | Owner: grass-dev@…
      Type: defect | Status: reopened
  Priority: critical | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Resolution: | Keywords: d.mon
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------

Comment(by neteler):

Backported to relbr7 in r61369 and r61370.

The race condition seems to be gone but the final draw seems not to be
done
unless I run another d.legend for example. More testers welcome.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285#comment:6>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 24, 2014, 6:56am

#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 <a
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.

--

Comment:

Problem reported in the ticket has been solved, closing.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2285#comment:7>
GRASS GIS <http://grass.osgeo.org>