[GRASS5] Driver Update

GRASS GRASS developer
21

Hi Glynn

Glynn Clements wrote:

Do you have strace() or similar?

Hmmpf. It figures that strace on SGI is different from Linux. The best I
can do here is provide you with a system call trace, but I don't know if
that will be useful to you. Please let me know if you want it anyway.

If so, a trace of the XDRIVER
process would help a lot. If not, could you add some printf()s to
src/display/devices/lib/main.c and see if that tells us anything.

The following is the output with some fprintf()'s and some comments by
me (preceeded with //)

using default visual which is TrueColor
Visual is read-only or using a private colormap
ncolors: 32768
allocating memory...
About to call prepare_connection_sock
About to call get_connection_sock
Graphics driver [x0] started
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)
About to call Do-work (1)
// Slight pause here
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
About to call close(_wfd)
About to call get_connection_sock
Problem selecting x0. Will try once more
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)
About to call Do-work (1)
// Again the pause
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
About to call close(_wfd)
// d.mon ends
About to call get_connection_sock
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (0)
// These 2 lines are continually printed until I close the monitor
// window

I don't know if this is helpful to you or not. Please let me know if you
want me to place print statements in other places in the code.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

22

Justin Hickey wrote:

> Do you have strace() or similar?

Hmmpf. It figures that strace on SGI is different from Linux. The best I
can do here is provide you with a system call trace, but I don't know if
that will be useful to you. Please let me know if you want it anyway.

Yes; for the XDRIVER process (I'm fairly sure that the client side is OK).

> If so, a trace of the XDRIVER
> process would help a lot. If not, could you add some printf()s to
> src/display/devices/lib/main.c and see if that tells us anything.

The following is the output with some fprintf()'s and some comments by
me (preceeded with //)

using default visual which is TrueColor
Visual is read-only or using a private colormap
ncolors: 32768
allocating memory...
About to call prepare_connection_sock
About to call get_connection_sock
Graphics driver [x0] started
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)

This implies the connection has been accepted.

About to call Do-work (1)

This seems to suggest that it has successfully read and processed one
command.

// Slight pause here
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
About to call close(_wfd)

Uh Oh. Something caused the command loop to terminate; the latest
version of lib/main.c prints an error message if an abnormal
termination occurs. It would be useful to know which of the three
possible cases occurred. The choices are:

            if (setjmp(save))

Indicates that SIGPIPE was caught (write to broken pipe).

            if (get_command(&c) != 0)

Driver got EOF while expecting command; this the "normal" case.

            if (process_command(c))

Driver got EOF while expecting command parameters/data.

About to call get_connection_sock
Problem selecting x0. Will try once more
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)

The client connects a second time. This kind of fault-tolerance is a
bit unexpected; maybe necessary when using FIFOs, though.

About to call Do-work (1)
// Again the pause
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
About to call close(_wfd)

Again, the loop terminates the second time around.

// d.mon ends
About to call get_connection_sock
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (0)
// These 2 lines are continually printed until I close the monitor
// window

Yep; XDRIVER continually alternates between checking for new
connections and processing X events.

I don't know if this is helpful to you or not. Please let me know if you
want me to place print statements in other places in the code.

Before each of the three "break"s from the inner loop would be useful.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

23

On Tue, Apr 24, 2001 at 07:12:41PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> just now I could reproduce a strange monitor behaviour (Eric,
> I told you about this). About once a month or so the monitor
> catches contents from a netscape window (Linux, KDE2).
>
> What I did: The GRASS monitor was open, the i.colors loading pictures.
> Meanwhile I was opening this URL in netscape:
> Bereich Geographie – Naturwissenschaftliche Fakultät – Leibniz Universität Hannover
>
> When closing this window, the GRASS monitor got part of the
> netscape window contents, looking like this:
> Bereich Geographie – Naturwissenschaftliche Fakultät – Leibniz Universität Hannover
> -> crazy_monitor.jpg
>
> This happened a few times in the past (since the socket suport is in),
> and on a colleagues Linux box as well.
>
> For me it's amazing that such things can happen :slight_smile: It doesn't
> disappear, even if I move the GRASS monitor around. The monitor is,
> of course, still working. Seems to be some backingstore problem.

Is the window using backing store ("xwininfo" should say")?

Hi Glynn,
no, it doesn't:

xwininfo
xwininfo: Window id: 0x600002 "GRASS 5.0.0pre1 - Monitor: x0"
  Backing Store State: NotUseful

xdpyinfo |grep -i back
  options: backing-store NO, save-unders NO

I was going to ask about disabling the use of backing store
altogether. XDRIVER already has a fall-back if backing store isn't
supported, i.e. it does all of its rendering into a Pixmap.

Making it do this all of the time would simplify the code, and
possibly improve reliability (the backing store code seems to be a bit
of a kludge; e.g. Panel_save() moves the window to be on screen, which
suggests that the code will have problems if the window isn't
completely visible). The only potential downside which I can see is
memory usage within the X server.

xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 4002

Maybe it is a KDE2/Xfree4.0.2 related problem. In past the backing store
problem was odd in GRASS 5, this was fixed by Eric Miller. This little
problem described above doesn't harm me, I just wanted to report it.

Up to now it didn't appear again.

Thanks,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

24

Glynn Clements wrote:

Justin Hickey wrote:

> > Do you have strace() or similar?
>
> Hmmpf. It figures that strace on SGI is different from Linux. The
> best I can do here is provide you with a system call trace, but I
> don't know if that will be useful to you. Please let me know if you
> want it anyway.

Yes; for the XDRIVER process (I'm fairly sure that the client side is
OK).

Hmmm. To get a trace I need to pass a command line to the trace program.
I think

par d.mon start=x0

will trace the client. How do I trace the XDRIVER?

> using default visual which is TrueColor
> Visual is read-only or using a private colormap
> ncolors: 32768
> allocating memory...
> About to call prepare_connection_sock
> About to call get_connection_sock
> Graphics driver [x0] started
> About to call Do-work (0)
> About to call get_connection_sock
> About to call Do-work (1)

This implies the connection has been accepted.

> About to call Do-work (1)

This seems to suggest that it has successfully read and processed one
command.

> // Slight pause here
> Warning - no response from graphics monitor <x0>.
> Check to see if the mouse is still active.
> ERROR - no response from graphics monitor <x0>.
> About to call close(_wfd)

Uh Oh. Something caused the command loop to terminate; the latest
version of lib/main.c prints an error message if an abnormal
termination occurs. It would be useful to know which of the three
possible cases occurred. The choices are:

            if (setjmp(save))

Indicates that SIGPIPE was caught (write to broken pipe).

            if (get_command(&c) != 0)

Driver got EOF while expecting command; this the "normal" case.

            if (process_command(c))

Driver got EOF while expecting command parameters/data.

I'm using your new code with the fprintf()'s so since nothing was
printed it must be the get_command() function. ... wait ... Just checked
to be sure and yep it's the get_command() function.

I also noted that the "while(1)" loop has no way of exiting if that
means anything ie. the main function never returns. I'm not sure if that
means anything.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

25

Markus Neteler wrote:

Maybe it is a KDE2/Xfree4.0.2 related problem. In past the backing store
problem was odd in GRASS 5, this was fixed by Eric Miller. This little
problem described above doesn't harm me, I just wanted to report it.

This may have been fixed by my most recent commit. Now:

1. backing_store is always set to NotUseful

2. A Pixmap is always created.

3. All rendering is performed on the Pixmap.

4. The Pixmap is made the window's background pixmap, so there is no
need to handle Expose events. A RESPOND command (sent by
R_stabilize()) will force an update using XClearArea.

BTW: Are the "Panel" operations actually used by anything? Neither
CELL nor PNGdriver implement them, and the XDRIVER implementation
looks suspicious. Is there any way to test them?

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

26

Justin Hickey wrote:

> > > Do you have strace() or similar?
> >
> > Hmmpf. It figures that strace on SGI is different from Linux. The
> > best I can do here is provide you with a system call trace, but I
> > don't know if that will be useful to you. Please let me know if you
> > want it anyway.
>
> Yes; for the XDRIVER process (I'm fairly sure that the client side is
> OK).

Hmmm. To get a trace I need to pass a command line to the trace program.
I think

par d.mon start=x0

will trace the client. How do I trace the XDRIVER?

Awkward; Linux' strace can attach to a running process with "-p".

If yours doesn't have this ability, I'm not sure that it can be done;
the driver requires the monitor name to be passed in argv[0], which
seems to exclude running it other via another program.

> Uh Oh. Something caused the command loop to terminate; the latest
> version of lib/main.c prints an error message if an abnormal
> termination occurs. It would be useful to know which of the three
> possible cases occurred. The choices are:
>
> if (setjmp(save))
>
> Indicates that SIGPIPE was caught (write to broken pipe).
>
> if (get_command(&c) != 0)
>
> Driver got EOF while expecting command; this the "normal" case.
>
> if (process_command(c))
>
> Driver got EOF while expecting command parameters/data.

I'm using your new code with the fprintf()'s so since nothing was
printed it must be the get_command() function. ... wait ... Just checked
to be sure and yep it's the get_command() function.

Odd. That one doesn't generate an error because that's how the loop
normally terminates. However, the input functions which get_command()
uses might be mistaken in their detection of EOF.

This certainly narrows it down a bit, though.

I also noted that the "while(1)" loop has no way of exiting if that
means anything ie. the main function never returns. I'm not sure if that
means anything.

No; mon.stop calls R_kill_driver() which sends GRAPH_CLOSE which the
monitor handles by calling exit().

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

27

Glynn Clements wrote:

> I'm using your new code with the fprintf()'s so since nothing was
> printed it must be the get_command() function. ... wait ... Just checked
> to be sure and yep it's the get_command() function.

Odd. That one doesn't generate an error because that's how the loop
normally terminates. However, the input functions which get_command()
uses might be mistaken in their detection of EOF.

This certainly narrows it down a bit, though.

Can you get the latest version of lib/command.c (or apply the attached
patch) to narrow it down a bit more.

--
Glynn Clements <glynn.clements@virgin.net>

(attachments)

command.c.diff (871 Bytes)

28

On Wed, Apr 25, 2001 at 05:48:53PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> Maybe it is a KDE2/Xfree4.0.2 related problem. In past the backing store
> problem was odd in GRASS 5, this was fixed by Eric Miller. This little
> problem described above doesn't harm me, I just wanted to report it.

This may have been fixed by my most recent commit. Now:

1. backing_store is always set to NotUseful

2. A Pixmap is always created.

3. All rendering is performed on the Pixmap.

4. The Pixmap is made the window's background pixmap, so there is no
need to handle Expose events. A RESPOND command (sent by
R_stabilize()) will force an update using XClearArea.

I see. BTW: Now the monitor behaviour is different than before: The image
will be displayed only when it is complete. Of course the same result
as if it would be build up continuously. However, with larger datasets
(and slow machines) users may become nervous why nothing is seen for
a while. I am not sure if this "wait - then display-at-once" is better
than "draw line-by-line" is better (however, you may have reasons for
this change).

BTW: Are the "Panel" operations actually used by anything? Neither
CELL nor PNGdriver implement them, and the XDRIVER implementation
looks suspicious. Is there any way to test them?

Sorry, no idea about this.
The progmangrass50.pdf tells us (chapter23.tex = "28 Writing a Graphics
Driver"):

"28.3.6 Panels
The following routines cooperate to save and restore sections of the display
screen."
[...]

A "find" didn't find it in use anywhere else.

This manual is in CVS
cvs -z3 co progmangrass50

in case you want to update above section.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

29

Markus Neteler wrote:

> > Maybe it is a KDE2/Xfree4.0.2 related problem. In past the backing store
> > problem was odd in GRASS 5, this was fixed by Eric Miller. This little
> > problem described above doesn't harm me, I just wanted to report it.
>
> This may have been fixed by my most recent commit. Now:
>
> 1. backing_store is always set to NotUseful
>
> 2. A Pixmap is always created.
>
> 3. All rendering is performed on the Pixmap.
>
> 4. The Pixmap is made the window's background pixmap, so there is no
> need to handle Expose events. A RESPOND command (sent by
> R_stabilize()) will force an update using XClearArea.

I see. BTW: Now the monitor behaviour is different than before: The image
will be displayed only when it is complete. Of course the same result
as if it would be build up continuously. However, with larger datasets
(and slow machines) users may become nervous why nothing is seen for
a while. I am not sure if this "wait - then display-at-once" is better
than "draw line-by-line" is better (however, you may have reasons for
this change).

I do:

1. The documentation for R_stabilize() suggests that this behaviour is
legitimate, and I wanted reports on clients which didn't like it (e.g.
d.rast.edit).

2. It's more efficient. For XDRIVER, it halves the amount of rendering
(previously every primitive was drawn to both the backing pixmap and
the window). The efficiency issue is more from the point of view of
conserving bandwidth between XDRIVER and the X server than of CPU
usage.

3. It's simpler.

If the "slow" cases can't be readily determined, I'd rather implement
an "auto-flush" mechanism.

> BTW: Are the "Panel" operations actually used by anything? Neither
> CELL nor PNGdriver implement them, and the XDRIVER implementation
> looks suspicious. Is there any way to test them?
Sorry, no idea about this.
The progmangrass50.pdf tells us (chapter23.tex = "28 Writing a Graphics
Driver"):

"28.3.6 Panels
The following routines cooperate to save and restore sections of the display
screen."
[...]

A "find" didn't find it in use anywhere else.

This manual is in CVS
cvs -z3 co progmangrass50

in case you want to update above section.

Do you mean remove them?

If they're not being used, there seems little point fixing the code.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

30

Glynn Clements wrote:

> > BTW: Are the "Panel" operations actually used by anything? Neither
> > CELL nor PNGdriver implement them, and the XDRIVER implementation
> > looks suspicious. Is there any way to test them?
>
> Sorry, no idea about this.
> The progmangrass50.pdf tells us (chapter23.tex = "28 Writing a Graphics
> Driver"):
>
> "28.3.6 Panels
> The following routines cooperate to save and restore sections of the display
> screen."
> [...]
>
> A "find" didn't find it in use anywhere else.
>
> This manual is in CVS
> cvs -z3 co progmangrass50
>
> in case you want to update above section.

Do you mean remove them?

If they're not being used, there seems little point fixing the code.

OK, they are being used in some of the d.* commands, but only ones
which are mouse-driven. So, it doesn't matter if only XDRIVER
implements them.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

31

Hi Glynn

Glynn Clements wrote:

Can you get the latest version of lib/command.c (or apply the
attached patch) to narrow it down a bit more.

OK. I updated my sources did a make distclean and recompile and
unfortunately, neither error message was printed. The output is still
the same.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

32

Justin Hickey wrote:

> Can you get the latest version of lib/command.c (or apply the
> attached patch) to narrow it down a bit more.

OK. I updated my sources did a make distclean and recompile and
unfortunately, neither error message was printed. The output is still
the same.

Well, that narrows it down a bit more, I guess.

We previously established that get_command() is returning non-zero. If
you're not getting the "Premature EOF" message from get_command(),
then the first read1(c) in get_command() must be returning non-zero.

If you're not getting the "Error reading input" message from read1(),
then the read() call in read1() must be returning zero, indicating EOF
from the client. Can you add a "if (n_read == 0) printf(...)" to
read1() just to confirm this beyond doubt?

If so, it looks like the problem is in the client after all.

Also, could you try swapping in the old version of
src/libes/raster/io.c [1] to see if that works?

[1] cvs update -r devices_cleanup_20000420 src/libes/raster/io.c

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

33

Hi Glynn,
hi all,

(cc to GRASS 5).
Thanks for the fix, the d.rast.edit backing store problem is gone now.

So we have to watch out now for any module with backing store problems
(when using the latest Xdriver version). It can be simply fixed like
d.rast.edit. Another candidate is v.digit, there may be more modules
needing the R_stabilize() function.

Markus

On Wed, Apr 25, 2001 at 08:14:20PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> sorry to say, but the backing store is worse now. Try the
> d.rast.edit: it doesn't display the grid any more unless
> you wipe the GRASS monitor with aother window... This was
> o.k. yesterday.

I suspected that this might happen in some cases. However, to my mind
this suggests a bug in the client. progmangrass50.pdf says:

  int
  R_stabilize ( )
  
  Send all pending graphics commands to the graphics driver and cause all
  pending graphics to be drawn (provided the driver is written to comply).
  This routine does more than R_flush and in many instances is the more ap-
  propriate routine fo the two to use.

If this function is called, the window will be updated.

The implication of the above description is that output isn't
guaranteed to actually be displayed until R_stabilize is called, hence
my opinion of it being a bug in the client.

I considered adding code to auto-redraw, but I think that it's better
to fix the clients. Requiring every graphics primitive to update the
window immediately is potentially expensive; in XDRIVER, it doubles
the workload; every primitive has to be drawn both to backing store
and to the window.

In future, it may be desirable to write drivers for other devices
where it is very necessary to have a distinct "force update"
operation.

--
Glynn Clements <glynn.clements@virgin.net>

--
Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

34

Hi Glynn

Glynn Clements wrote:

from the client. Can you add a "if (n_read == 0) printf(...)" to
read1() just to confirm this beyond doubt?

Yes, n_read == 0.

If so, it looks like the problem is in the client after all.

Also, could you try swapping in the old version of
src/libes/raster/io.c [1] to see if that works?

[1] cvs update -r devices_cleanup_20000420 src/libes/raster/io.c

This is the fifo version. Where is the socket version?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

35

Justin Hickey wrote:

> from the client. Can you add a "if (n_read == 0) printf(...)" to
> read1() just to confirm this beyond doubt?

Yes, n_read == 0.

> If so, it looks like the problem is in the client after all.
>
> Also, could you try swapping in the old version of
> src/libes/raster/io.c [1] to see if that works?
>
> [1] cvs update -r devices_cleanup_20000420 src/libes/raster/io.c

This is the fifo version. Where is the socket version?

Duh; should be

cvs update -r devices_cleanup_20000420 src/libes/raster/socket.new/io.c

then move the file into place.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

36

Markus Neteler wrote:

So we have to watch out now for any module with backing store problems
(when using the latest Xdriver version). It can be simply fixed like
d.rast.edit. Another candidate is v.digit, there may be more modules
needing the R_stabilize() function.

I've done a quick scan of anything that might need changes (i.e. by
looking for libraster.a in the build output).

The following are the ones which couldn't be quickly confirmed to be
OK or fixed.

d.display
i.class
i.colors
i.ortho.photo
i.points
i.points3
i.vpoints
v.area
v.digit
r.weight
r.water.fea (src.contrib/CERL)
d.fix.ortho (src.contrib/SCS)

paint/driver/preview
paint/driver/preview2

If anyone is familiar with the usage of these programs, I would
appreciate it if they can check for problems. The nature of the
problem in question is that the display won't be redrawn correctly in
normal use, but will be redrawn if the window is re-exposed (e.g.
after being iconified then deiconified).

The problem can be worked around in the driver (and probably will be
for the release), but I'd rather see the clients fixed first.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

37

Hi Glynn

Glynn Clements wrote:

cvs update -r devices_cleanup_20000420
src/libes/raster/socket.new/io.c

then move the file into place.

CVS was down, so I copied this file from a previous installation and I
still get the same error messages being printed.

Just to check that it was not my system, I ran the old installation and
the monitor worked fine.

So, it looks like we're still stumped.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

38

On Thu, Apr 26, 2001 at 06:59:38PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> So we have to watch out now for any module with backing store problems
> (when using the latest Xdriver version). It can be simply fixed like
> d.rast.edit. Another candidate is v.digit, there may be more modules
> needing the R_stabilize() function.

I've done a quick scan of anything that might need changes (i.e. by
looking for libraster.a in the build output).

The following are the ones which couldn't be quickly confirmed to be
OK or fixed.

Glynn,

I have tested some modules:

d.display

-> not o.k., needs the R_stabilize()

i.class

-> raster is o.k., but the vector lines are not drawn unless you
  accept them.
  Test usage: use i.group to generate a group and a subgroup of at least
  two raster images (could be anything for this). Then start i.class,
  enter some file names as queried, then "define region"/"draw region" to
  draw vector lines as sample areas. Then drawing, the lines *should*
  be seen (the aren't unless you hit the right mouse button to complete).

i.colors

  -> o.k.

i.ortho.photo

  -> o.k.

i.points

  -> o.k.

i.points3

  -> o.k. for display
     Bug: If setting target reference point, nothing happens (not displayed,
          not accpeted). Note: i.points3 is *much* more convenient than
          i.points and it merges i.points and i.vpoints. We should get this
          working.

i.vpoints

  -> raster o.k., vector maps not displayed at all (bug)
     bug: full screen not restored (frames not removed). Anyway, i.points3
     is my recommendation.

v.area

-> o.k.

v.digit

-> o.k. (note: here the digitizing lines are shown which I am missing in
           i.class)

d.fix.ortho (src.contrib/SCS)

-> the digitizing line is not shown yet (needs fix)

---------------------------------------

r.weight
r.water.fea (src.contrib/CERL)
paint/driver/preview
paint/driver/preview2

-> could not test, other volunteers wanted.

A related problem I found:
If you break a displaying module with CTRL-C, the monitor is blocked:
GRASS:~ > d.display
           # displaying something, then CTRL-C to kill due to above problems
GRASS:~ > Monitor <x0>: Premature EOF

GRASS:~ > d.erase
Monitor <x0>: Premature EOF

Same story with d.rast: if you CTRL-C it, the monitor is blocked.
In past this treatment was accepted and the monitor didn't die.
Closing is (of course) still possible. Could you change the treatment of
"Premature EOF" in the monitor to keep the monitor working?

If the user forgets to enter the right mouse button (to leave d.zoom or
another interactive display tool), the monitor is of course blocked as it
waits for the right mouse button. If you already start the next display
command like d.rast, nothing happens (as expected). If you *then* click
right mouse button, the monitor get's back to function and the message
occurs:
Monitor <x0>: Caught SIGPIPE
Then everything is o.k. What I want to say: Could you change the driver to
react in case of "Premature EOF" as when "Caught SIGPIPE" occurs?

Hope this report helps,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

39

Markus Neteler wrote:

> > So we have to watch out now for any module with backing store problems
> > (when using the latest Xdriver version). It can be simply fixed like
> > d.rast.edit. Another candidate is v.digit, there may be more modules
> > needing the R_stabilize() function.
>
> I've done a quick scan of anything that might need changes (i.e. by
> looking for libraster.a in the build output).
>
> The following are the ones which couldn't be quickly confirmed to be
> OK or fixed.

I have tested some modules:

> d.display
-> not o.k., needs the R_stabilize()

Any specific cases? d.display is quite a large program, which is why I
didn't try to fix it there and then.

> i.class
-> raster is o.k., but the vector lines are not drawn unless you
  accept them.
  Test usage: use i.group to generate a group and a subgroup of at least
  two raster images (could be anything for this). Then start i.class,
  enter some file names as queried, then "define region"/"draw region" to
  draw vector lines as sample areas. Then drawing, the lines *should*
  be seen (the aren't unless you hit the right mouse button to complete).

OK; this seems to be confined to draw_region().

> i.points3
  -> o.k. for display
     Bug: If setting target reference point, nothing happens (not displayed,
          not accpeted). Note: i.points3 is *much* more convenient than
          i.points and it merges i.points and i.vpoints. We should get this
          working.

So this bug isn't related to R_stabilize()?

> i.vpoints
  -> raster o.k., vector maps not displayed at all (bug)
     bug: full screen not restored (frames not removed). Anyway, i.points3
     is my recommendation.

So it doesn't need fixing?

> d.fix.ortho (src.contrib/SCS)
-> the digitizing line is not shown yet (needs fix)

get_shift() has the drawing code commented out. Should this be
re-enabled?

A related problem I found:
If you break a displaying module with CTRL-C, the monitor is blocked:
GRASS:~ > d.display
           # displaying something, then CTRL-C to kill due to above problems
GRASS:~ > Monitor <x0>: Premature EOF

GRASS:~ > d.erase
Monitor <x0>: Premature EOF

Same story with d.rast: if you CTRL-C it, the monitor is blocked.
In past this treatment was accepted and the monitor didn't die.
Closing is (of course) still possible. Could you change the treatment of
"Premature EOF" in the monitor to keep the monitor working?

This implies that some state is being retained between connections.
This shouldn't happen, and I can't immediately see how it is
happening. I'll look into it.

If the user forgets to enter the right mouse button (to leave d.zoom or
another interactive display tool), the monitor is of course blocked as it
waits for the right mouse button. If you already start the next display
command like d.rast, nothing happens (as expected). If you *then* click
right mouse button, the monitor get's back to function and the message
occurs:
Monitor <x0>: Caught SIGPIPE
Then everything is o.k. What I want to say: Could you change the driver to
react in case of "Premature EOF" as when "Caught SIGPIPE" occurs?

It does; both cases "break" from the inner loop (get_command,
process_command), close the connection and wait for the next
connection.

Of course, this doesn't necessarily translate into the desired
behaviour; I'll certainly look into improving the robustness driver is
as robust as possible.

NB: The case where the client quits while waiting for a mouse click
shouldn't have changed at all; the Get_location_with_* functions all
have their own event loop, which doesn't return until a button is
pressed. This isn't straightforward to change (it can be done, but
it's potentially de-stabilising).

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

40

Justin Hickey wrote:

> cvs update -r devices_cleanup_20000420
> src/libes/raster/socket.new/io.c
>
> then move the file into place.

CVS was down, so I copied this file from a previous installation and I
still get the same error messages being printed.

Just to check that it was not my system, I ran the old installation and
the monitor worked fine.

So, it looks like we're still stumped.

Very odd. Is my summary from a few messages back correct?

  We previously established that get_command() is returning non-zero. If
  you're not getting the "Premature EOF" message from get_command(),
  then the first read1(c) in get_command() must be returning non-zero.
  
  If you're not getting the "Error reading input" message from read1(),
  then the read() call in read1() must be returning zero, indicating EOF
  from the client. Can you add a "if (n_read == 0) printf(...)" to
  read1() just to confirm this beyond doubt?

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'