[GRASS5] Grass monitor library
glynn.clements at virgin.net
Sun Jul 29 00:24:47 EDT 2001
pcpa at conectiva.com.br wrote:
> > > It clearly also needs some better error handling, bounds checking,
> > and at
> > > least for the code that use fifos, there are several places were it
> > can block
> > > forever.
> > >
> > > What is the current status of the monitors code at
> > src/display/devices/?
> > It's now in a state where, once GRASS 5.0 is released, we can throw
> > the whole thing in the bin and start again from scratch.
> > Seriously.
> I have some time constraints in the project where I am using grass (but
> it will be open source, and I am trying to make it generic enough to allow
> others to use the same codebase), else I would volunteer to write some of
> the code. But basically, I think all monitors should share the same
> library, i.e. only one SWITCHER.c file,
You're using a significantly outdated version of GRASS. Removing
SWITCHER.c was one of the first of many changes which I made to the
> and have several funcion pointers
> in a structure, to call the proper interfaces. There should be some
> padronization to decide about LSB/MSB format when sending/receiving data.
Not really much point at present; the clients have to run on the same
host as the monitor. Byte ordering might be an issue for a new
> And the library should export some sort of asynchronous interface, to avoid
> needs for forking and poll´ing on different file descriptors...
Yep; the polling sucks, but at the time it was the simplest way to
implement both XDRIVER (which has to handle the connection to the X
server as well as the rasterlib connection) and the other drivers
(which only have the rasterlib connection) with a common code base.
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev