LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: dglaude AT (David Glaude)
  • Subject: [lcdproc] Current developpement question...
  • Date: Fri, 15 Sep 2000 15:09:52 +0200

-----Original Message-----
>From: William W. Ferrell
>[mailto:wwf AT]
>Sent: Thursday, September 14, 2000 10:14 PM
>To: Matt
>Cc: LCDproc mailing list
>Subject: Re: [lcdproc] Current developpement question...

>...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.

I agree, if any hardware change are done... restart the server.
And let's try to make the client smart in reconnecting to the new server
(same place).
However you sometime have to wait a few minute before the server can
reconnect to the same TCP port.

Now in the opposite direction, we where talking about virtual screen made of
multiple screen side by side
or on top of each other. What if you want to change the geometry... restart
the server?

So if you go for the "restart the server" what is left of dynamic
I still believe that dynamic screen/driver apply for networked screen (Laser
Jet or telnet monitoring or ...).
I whould love to be able to telnet the server, say "Hello I am VT100 I want
a 20*4 copy of lcd screen"
and get the cursus driver sending a copy of the physical LCD to my remote
That way we could build a public LCDd server with news/ticker/weather
forcast and anyone could:
1) Telnet (and resize the screen).
2) Attach (how?) with a LCDclient and a physical LCD screen.
Somehow make LCDd a message broker between client (lcdproc), physical LCD,
and remote physical/virtual LCD.

>> | * About yacc/bison & lex/flex I also believe that for simple task,
>> | 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
>> | 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 ;)

Just to give you my practical experience about flex/bison, here is the
relevant files from my last small little project relative to the macro
processing of a language. All of this is on a windows intel platform but
using GNU tools:

-rw-r--r-- 1 dglaude Administ 17673 Sep 15 00:13 BISON.SIMPLE
-rw-r--r-- 1 dglaude Administ 3598 Aug 9 08:53 LType.l
-rw-r--r-- 1 dglaude Administ 46353 Sep 15 00:30 ltype.c
-rw-r--r-- 1 dglaude Administ 14469 Sep 15 15:06 ltype.o

-rw-r--r-- 1 dglaude Administ 4031 Jul 27 22:51 YType.y
-rw-r--r-- 1 dglaude Administ 26716 Sep 15 15:05 ytype.c
-rw-r--r-- 1 dglaude Administ 541 Sep 15 15:05 ytype.h
-rw-r--r-- 1 dglaude Administ 8214 Sep 15 15:05 ytype.o

More likely the parser for LCDd won't be that big, but for those of you
focussing on space, the *.o files seems big.


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

Archive powered by MHonArc 2.6.18.

Top of page