LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: wwf AT (William W. Ferrell)
  • Subject: [lcdproc] Current developpement question...
  • Date: Thu, 14 Sep 2000 14:14:15 -0600

* Matt
(madmatt AT's
mailer blew these chunks:
> David Glaude wrote:
> | Maybe we could support dynamic reconfiguration of LCDd (if the new screen
> is
> | already compiled in).
> | Just modify the configuration file and send a KILL xxx to the tell LCDd to
> | parse again.
> In some cases, it's necessary to down the entire machine to attach a
> display, (in the case of the hd44780's), but as long as that isn't a
> problem you could change the conf file, and SIGHUP the server to re-read
> the file.
> The only problem is the clients that are connected wouldn't know about the
> new display, only future connected clients. Also what happens if you
> delete a display that is being used? I detect a messy kludge on the
> horizon...

...that can be avoided simply by insisting LCDproc be downed and brought
back up when hardware changes occur.

That's just too much work for too little gain. Most people are gonna set
up their systems and leave them running for days/weeks/months/years.
Displays normally won't change that much.

> | * About yacc/bison & lex/flex I also believe that for simple task, making
> | your own parser is a lot better. I have been using yacc and lex both
> | recently and long ago. They provide a good job but you also take with you
> a
> | (two) full state machine with a lot of various feature that we absolutely
> | don't need where a few lines of code could do the trick.
> | I don't know wich way you wanna go, but except if you want to take that
> | opportunity to learn those tools (always a bit risky) I see no point in
> | using them.
> Funny, the flex/yacc book states the exact opposite...

Heh, that's 'cause they're biased ;)

> Anyway, all the parser code will be hidden behind a nice interface so that
> it can be changed without breaking the rest of the server code. As long as
> the functions return hashes of the options from the file in the same
> format, it won't really matter...

This sounds good. It's one less thing for me to worry about during
development. Matt's right, if we decide later that the combination
sucks, so long as we keep the interface portable and easy we can change
the parser to whatever we want.

> | * Could you repeat where all those new developpent take place... Where is
> | the CVS... a few pointer maybe.

Ken already touched on this, but

William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564

Public key available:
gpg --keyserver --recv-key 7478FC7A

The world really isn't any worse. It's just that the news coverage
is so much better.

Attachment: pgp0QlF7H18i_.pgp
Description: PGP signature

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

Archive powered by MHonArc 2.6.18.

Top of page