[GRASS5] Volunteer wanted for CELL driver color problem

Malcolm Blue mblue at nb.sympatico.ca
Thu Apr 19 19:10:52 EDT 2001


Glynn,

I have a minor change that I was planning to make to the sockets version of
SWITCHER.c to make these workable with Win98 version of Cygwin.  These won't be
needed for fifo version, since fifo doesn't work on Cygwin.  Should I make these
changes to fifo version anyway (even if just to avoid questions later)?

I will wait until you finish your changes, to avoid versioning problems.  Are you
going to check your changes in at once or should I wait for your go ahead (I
probably won't be ready until Sunday anyway)?

BTW.  For the sleep(1) change, in order to avoid confusing the user, why don't we
retry the select a couple of times with a sleep(1) in between, before issuing a
message.  This should take care of the slower programs (i.e. CELL) and faster
machines, since both seem to be causing problems, without alarming users
needlessly.  Also, both CELL and XDRIVER need sleep(1) as identified by Bob
Covill's experience with the monitor.

Thanks,

Malcolm


Glynn Clements wrote:

> Markus Neteler wrote:
>
> > GRASS:~ > d.mon CELL
> > Graphics driver [CELL] started
> > Wait for 'READY'
> > Socket is already in use or not accepting connections.
> > Use d.mon to select a monitor
> > Problem selecting CELL. Will try once more
> > READY
> >
> >  -> I had included your proposed "sleep(1)" in d.mon/cmd/main.c
> >
> > Probably we should distinguish between CELL start (with sleep) and XDRIVER
> > start (without sleep). I have a 1GHz Athlon board here.
>
> Ideally d.mon would retry the select until success or timeout (at
> least in the auto-select case).
>
> > However, I think Glynn is looking into this as well now for a cleanup.
>
> Yep; having compared the fifo.orig/sockets.new versions of SWITCHER.c
> (in both devices/lib and devices/XDRIVER/XDRIVER24), there are a
> number of differences which have nothing to do with FIFO/socket
> differences. Specifically:
>
> 1. XDRIVER24/socket.new version has debug code removed.
>
> 2. XDRIVER24/fifo.orig version has "#ifdef ORIG" code; the other three
> don't.
>
> 3. Both fifo.orig versions have "#ifndef __CYGWIN__" around the FONT
> and TEXT cases; the socket.new versions don't.
>
> 4. Various minor differences which seem equally applicable to all
> versions, but presumably only went into whichever version the author
> was using/considering at the time. This includes my warning
> elimination patches, which were only made to the files which were
> actually listed in compile_warnings.log.
>
> Also, the fifo.orig versions have the {check,get}_connection()
> functions in connect.c, whilst the socket.new versions inline the
> equivalent code.
>
> There are two versions of XDRIVER/lib/connect.c (the socket.new
> version being empty), but not of lib/connect.c, CELL/connect.c,
> HTMLMAP/connect.c or PNGdriver/connect.c.
>
> Furthermore, all of the various connect.c files are almost identical,
> which is as I would expect; how to transport the data and what to do
> with it are orthogonal. The differences appear to be "fixes" which
> only made it into one version or another.
>
> My plan is to:
>
> a) Remove all of the debug code. The (presumably) most heavily used
> version (XDRIVER24/socket.new) seems to live without it. And gdb is
> free.
>
> b) Remove the "#ifdef ORIG" code; three out of four versions seem OK
> without it.
>
> c) Remove the "#ifndef __CYGWIN__" around the FONT and TEXT cases. The
> socket versions seem OK without it.
>
> d) Create {check,get}_connection() for the socket version.
>
> e) Remove the myriad versions of connect.c and just leave the one in
> devices/lib.
>
> f) Define USE_G_FIFO/USE_G_IPC analogous to USE_G_SOCKS. Use these to
> conditionalise code and, ultimately, eliminate README.xdriver.
>
> g) I'm going to leave src/libes/raster/io.c until later.
>
> Any objections?
>
> BTW, is anyone actually using the IPC version? Or, for that matter, is
> anything other than the socket version getting tested regularly?
>
> --
> Glynn Clements <glynn.clements at virgin.net>
>
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'


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



More information about the grass-dev mailing list