[GRASS5] d.m and d.mon fail after cvs update

GRASS GIS GRASS GIS developer
1

I just cvs updated (20060222)and can no longer start d.m or d.mon.

d.m fails with:

GRASS 6.1.cvs (minnesota_utm):~ > gis.m
Error in startup script: couldn't open "/usr/local/grass-6.1.cvs/etc/gm/pointer.gif": no such file or directory
     while executing
"image create photo -file "$gmpath/pointer.gif""
     (procedure "MapToolBar::create" line 33)
     invoked from within
"MapToolBar::create $map_tb"
     (procedure "MapCanvas::create" line 47)
     invoked from within
"MapCanvas::create"
     (procedure "Gm::startmon" line 11)
     invoked from within
"Gm::startmon"
     (procedure "Gm::create" line 96)
     invoked from within
"Gm::create"
     (procedure "main" line 29)
     invoked from within
"main $argc $argv"
     (file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 777)

and d.mon x0 fails with:

GRASS 6.1.cvs (minnesota_utm):~ > d.mon x0
Problem selecting x0. Will try once more
GRASS 6.1.cvs (minnesota_utm):~ > d.mon
GRASS 6.1.cvs (minnesota_utm):~ >

Any thoughts?

Kirk

2

Kirk R. Wythers wrote:

and d.mon x0 fails with:

GRASS 6.1.cvs (minnesota_utm):~ > d.mon x0
Problem selecting x0. Will try once more
GRASS 6.1.cvs (minnesota_utm):~ > d.mon
GRASS 6.1.cvs (minnesota_utm):~ >

Any thoughts?

Known problem, mentioned in:

  From: Glynn Clements <glynn@gclements.plus.com>
  Subject: [GRASS5] version.h.in broken
  Date: Tue, 21 Feb 2006 23:17:41 +0000
  Message-ID: <17403.40853.814866.311695@cerise.gclements.plus.com>

I've committed a fix (revert version.h.in to the previous version) to
CVS.

--
Glynn Clements <glynn@gclements.plus.com>

3

Kirk,

I had the same problem. Glynn just fixed the d.mon error in CVS. As for
the gis.m error, the pointer.gif file is missing. Does anyone else know
where to get this file? As a temp fix, I copied some other icon
"erase.gif" in the etc/gm dir to
usr/local/grass-6.1.cvs/etc/gm/pointer.gif and it seems to work.

-Andy

On Wed, 2006-02-22 at 10:25 -0600, Kirk R. Wythers wrote:

I just cvs updated (20060222)and can no longer start d.m or d.mon.

d.m fails with:

GRASS 6.1.cvs (minnesota_utm):~ > gis.m
Error in startup script: couldn't open "/usr/local/grass-6.1.cvs/etc/
gm/pointer.gif": no such file or directory
     while executing
"image create photo -file "$gmpath/pointer.gif""
     (procedure "MapToolBar::create" line 33)
     invoked from within
"MapToolBar::create $map_tb"
     (procedure "MapCanvas::create" line 47)
     invoked from within
"MapCanvas::create"
     (procedure "Gm::startmon" line 11)
     invoked from within
"Gm::startmon"
     (procedure "Gm::create" line 96)
     invoked from within
"Gm::create"
     (procedure "main" line 29)
     invoked from within
"main $argc $argv"
     (file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 777)

and d.mon x0 fails with:

GRASS 6.1.cvs (minnesota_utm):~ > d.mon x0
Problem selecting x0. Will try once more
GRASS 6.1.cvs (minnesota_utm):~ > d.mon
GRASS 6.1.cvs (minnesota_utm):~ >

Any thoughts?

Kirk

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

4

Thanks Glenn. I’ll re-run cvs up

On Feb 22, 2006, at 11:56 AM, Glynn Clements wrote:

I’ve committed a fix (revert version.h.in to the previous version) to

CVS.

–

Glynn Clements <glynn@gclements.plus.com>

5

I had this problem, but fixed it in a different way and so need to ask about
it.

I had a strange monitorcap (with double xmon definitions) file that came
with the most recent (13 February) Mac binary from Lorenzo Moretti. Perhaps
this is/was being generated during Mac compiles as this seems to be reported
by Mac folks.

When I fixed the monitorcap file AND commented out the following line...

                #set env(MONITOR_OVERRIDE) "gism"

in the procedure that creates the output PPM and then creates a TclTk image
from thePPM, it worked.

With the fix you mention below, should I try uncommenting the
MONITOR_OVERRIDE statement?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 22 Feb 2006 17:56:41 +0000
To: "Kirk R. Wythers" <kwythers@umn.edu>
Cc: devel grass <grass5@grass.itc.it>
Subject: Re: [GRASS5] d.m and d.mon fail after cvs update

Kirk R. Wythers wrote:

and d.mon x0 fails with:

GRASS 6.1.cvs (minnesota_utm):~ > d.mon x0
Problem selecting x0. Will try once more
GRASS 6.1.cvs (minnesota_utm):~ > d.mon
GRASS 6.1.cvs (minnesota_utm):~ >

Any thoughts?

Known problem, mentioned in:

From: Glynn Clements <glynn@gclements.plus.com>
Subject: [GRASS5] version.h.in broken
Date: Tue, 21 Feb 2006 23:17:41 +0000
Message-ID: <17403.40853.814866.311695@cerise.gclements.plus.com>

I've committed a fix (revert version.h.in to the previous version) to
CVS.

--
Glynn Clements <glynn@gclements.plus.com>

6

Michael Barton wrote:

I had this problem, but fixed it in a different way and so need to ask about
it.

I had a strange monitorcap (with double xmon definitions) file that came
with the most recent (13 February) Mac binary from Lorenzo Moretti. Perhaps
this is/was being generated during Mac compiles as this seems to be reported
by Mac folks.

When I fixed the monitorcap file AND commented out the following line...

                #set env(MONITOR_OVERRIDE) "gism"

in the procedure that creates the output PPM and then creates a TclTk image
from thePPM, it worked.

With the fix you mention below, should I try uncommenting the
MONITOR_OVERRIDE statement?

The use of MONITOR_OVERRIDE and the fix which I mentioned are
unrelated.

Without the version.h.in fix, monitor drivers will simply segfault at
startup. the fix is necessary to be able to use monitors.

MONITOR_OVERRIDE allows applications to redirect d.* commands to a
specific monitor without using "d.mon select=..." (which will
interfere with the user's use of monitors).

gis.m should always be using MONITOR_OVERRIDE rather than
"d.mon select=gism".

BTW, It is now be possible for gis.m (and similar programs, e.g.
d.out.png) to avoid the use of monitorcap altogether. You can start
monitors directly with e.g. (shell syntax):

  $GISBASE/driver/PNG foo '' ''
  MONITOR_OVERRIDE=foo d.vect fields
  d.mon stop=foo
  # or:
  # $GISBASE/etc/mon.stop foo

without the monitor name having to appear in the monitorcap file.

This doesn't work when using FIFOs, although I don't know if anyone
still uses FIFOs, and I'm inclined to remove FIFO support altogether
unless someone can provide a good reason why it needs to stay.

--
Glynn Clements <glynn@gclements.plus.com>

7

Glynn,

Currently when I use monitor override, I cannot open an xmon window from the
GIS Manager. I get a 'No socket to connect to for monitor <x0>' error.

The way I had it was ...

d.mon start=gism -s
set env(MONITOR_OVERRIDE) "gism"
...display commands
d.mon stop=gism

If I try to start an xmon (e.g., for v.digit), I get the 'No socket...'
error.

If I change to...

d.mon start=gism
...display commands
d.mon stop=gism

I get no error.

I've tried using monitor override to select the xmon for v.digit (or other
module that needs it) and unsetting monitor override after stopping gism.

This is not a big issue now. But when I start redoing the compositing, I'll
want to keep gism running all the time, except when doing a window resize.
Then I'll really need to use monitor override.

Any ideas?

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Thu, 23 Feb 2006 14:59:19 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: "Kirk R. Wythers" <kwythers@umn.edu>, devel grass <grass5@grass.itc.it>
Subject: Re: [GRASS5] d.m and d.mon fail after cvs update

Michael Barton wrote:

I had this problem, but fixed it in a different way and so need to ask about
it.

I had a strange monitorcap (with double xmon definitions) file that came
with the most recent (13 February) Mac binary from Lorenzo Moretti. Perhaps
this is/was being generated during Mac compiles as this seems to be reported
by Mac folks.

When I fixed the monitorcap file AND commented out the following line...

                #set env(MONITOR_OVERRIDE) "gism"

in the procedure that creates the output PPM and then creates a TclTk image
from thePPM, it worked.

With the fix you mention below, should I try uncommenting the
MONITOR_OVERRIDE statement?

The use of MONITOR_OVERRIDE and the fix which I mentioned are
unrelated.

Without the version.h.in fix, monitor drivers will simply segfault at
startup. the fix is necessary to be able to use monitors.

MONITOR_OVERRIDE allows applications to redirect d.* commands to a
specific monitor without using "d.mon select=..." (which will
interfere with the user's use of monitors).

gis.m should always be using MONITOR_OVERRIDE rather than
"d.mon select=gism".

BTW, It is now be possible for gis.m (and similar programs, e.g.
d.out.png) to avoid the use of monitorcap altogether. You can start
monitors directly with e.g. (shell syntax):

$GISBASE/driver/PNG foo '' ''
MONITOR_OVERRIDE=foo d.vect fields
d.mon stop=foo
# or:
# $GISBASE/etc/mon.stop foo

without the monitor name having to appear in the monitorcap file.

This doesn't work when using FIFOs, although I don't know if anyone
still uses FIFOs, and I'm inclined to remove FIFO support altogether
unless someone can provide a good reason why it needs to stay.

--
Glynn Clements <glynn@gclements.plus.com>

8

Michael Barton wrote:

Currently when I use monitor override, I cannot open an xmon window from the
GIS Manager. I get a 'No socket to connect to for monitor <x0>' error.

The way I had it was ...

d.mon start=gism -s
set env(MONITOR_OVERRIDE) "gism"
...display commands
d.mon stop=gism

If I try to start an xmon (e.g., for v.digit), I get the 'No socket...'
error.

If I change to...

d.mon start=gism
...display commands
d.mon stop=gism

I get no error.

You need to unset MONITOR_OVERRIDE after you're done with it, i.e.:

  unset env(MONITOR_OVERRIDE)

I've tried using monitor override to select the xmon for v.digit (or other
module that needs it) and unsetting monitor override after stopping gism.

Either of those should work.

This is not a big issue now. But when I start redoing the compositing, I'll
want to keep gism running all the time, except when doing a window resize.
Then I'll really need to use monitor override.

You can set and unset env(MONITOR_OVERRIDE) while the gism monitor is
running. It only needs to be set while running d.* commands which are
supposed to use a specific monitor.

--
Glynn Clements <glynn@gclements.plus.com>