LCDproc development and user support list

Text archives Help

[lcdproc] More questions, etc.

Chronological Thread 
  • From: natey AT (Nathan Yawn)
  • Subject: [lcdproc] More questions, etc.
  • Date: Fri, 08 Sep 2000 22:21:54 -0500

First, thanks for all the info on LCdproc and where's it's headed. Of
course, the answers raises even more questions, most of them
"philosophical" in nature. I'm sorry if these have been discussed
before, but I wasn't here to see it, so please humor me. :) BTW, I'm
happy to help with the infrastructure of LCDproc too, I'm not just here
to upload a driver and run. ;)

I have hacked togeather a driver for my hardware under v0.4.
problem is that my LCD is 20x2, and so lcd.c needs to be edited so that
the base driver is set as 20x2, because apparently this is the value
that is reported to clients, instead of the value from a particular
driver, so far as I can tell. I'd post the driver code, but there
wouldn't be much point, since no one else has this hardware yet. ;)

Anyway, more of my my questions/comments:

1. It sounds like the plan is to have a shared object/library from
which the server calls functions ( If so, why? It
seems like only the server would access it. This wouldn't do anything
for code reuse, it would just make 2 files from one, adding to the
complexity of installation. The last thing everyone's machine needs is
Yet Another Shared Library.

(A single shared library accessed by any/all clients, on the other hand,
makes good sense to me.)

2. This was originally a question about loading drivers at runtime, but
as I see now, someone has beaten me to the suggestion. I think it's a
good idea too, it fits in well with LCDproc's function pointer handling
of drivers.

3. Will a single server be allowed to control multiple pieces of
hardware? This could be a very interesting question when dealing with
disparate hardware, and relates to the next question...

4. Does a client know the size of the LCD? If yes, does it need to?
It would make for a more complex server, but it's possible to make it
the server's responsibility to see that everything is displayed.
However, this might impose some extra limits on clients...

I think that covers the questions, anyway...

BTW, I've had experience writing parsers both from scratch and
flex+bison. Unless you're planning on something really spectacular,
writing a parser from scratch will probably be easier and better. When
you write the parser yourself, you have absolute control over exactly
what happens, for error conditions and so on. When I use flex+bison,
I'm never exactly sure what's happening. Also, flex+bison are probably
overkill for parsing a "parameter, value" config file. The real power
of flex+bison lies in its ability to parse scripting languages and the
like. If the point is to learn flex+bison, then by all means go for it
(that's what I did!). But if you just want a parser, I recommend
writing it yourself. I've also got some code I can donate if you're

Nathan Yawn
natey AT

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page