code I item #298, was opened at 2007-02-17 15:31
Status: Open
Priority: 3
Submitted By: Maciej Sieczka (msieczka)
Assigned to: Nobody (None)
Summary: v.digit does not start from gis.m
Issue type: module bug
Issue status: None
GRASS version: CVS HEAD
GRASS component: gis.m
Operating system: all
Operating system version:
GRASS CVS checkout date, if applies (YYMMDD): 070217
Initial Comment:
1. add a vector
2. highlight it
3. press "Digitize map"
An X monitor is spawned, but v.digit does not start. Repeat point 3 - another X mon pops up, still no v.digit.
Rather than using "spawn", you could try "exec", but you need to
redirect the standard descriptors, otherwise exec won't return. E.g.
(untested):
global devnull
exec d.mon start=$xmon >$devnull 2>$devnull
Although the d.mon process terminates once the monitor is accepting
connections, the monitor will inherit the stdout/stderr pipes which
Tcl's exec command creates, and exec won't return until these are
closed (it returns the entire output from the command as its result).
OTOH, I've been re-writing v.digit not to require a monitor, so
hopefully this issue should soon be moot.
Your idea works like charm. Attached it as patch for faster commiting.
Only thing that makes me wonder - that "spawn" call was there since
May 8 2006 [1] - why it was problem only for 6.3? Or noone was using
ever v.digit from gis.m??
Rather than using "spawn", you could try "exec", but you need to
redirect the standard descriptors, otherwise exec won't return. E.g.
(untested):
global devnull
exec d.mon start=$xmon >$devnull 2>$devnull
Although the d.mon process terminates once the monitor is accepting
connections, the monitor will inherit the stdout/stderr pipes which
Tcl's exec command creates, and exec won't return until these are
closed (it returns the entire output from the command as its result).
OTOH, I've been re-writing v.digit not to require a monitor, so
hopefully this issue should soon be moot.
Your idea works like charm. Attached it as patch for faster commiting.
Hmm. Do we always want to discard the output?
"spawn" will send the output to gis.m's stdout/stderr (e.g. the
terminal), similar to using:
exec d.mon start=$xmon >@stdout 2>@stderr
However, explicitly redirecting in this way can be problematic on
Windows, apparently.
I have no preference either way, but we should probably see if anyone
else does.
Only thing that makes me wonder - that "spawn" call was there since
May 8 2006 [1] - why it was problem only for 6.3? Or noone was using
ever v.digit from gis.m??
The problem is timing-dependent. If the monitor is already running,
there won't be a problem. If the monitor manages to initialise before
v.digit gets around to connecting to it, there won't be a problem.
It's possible that recent changes to the display architecture have
affected the timing in some way.
In any case, waiting for d.mon to complete is The Right Thing so far
as guarantee_xmon is concerned, IMHO.