[lcdproc] Hashes to Hashes and config file to config file.

Andre Breiler andreb@rd.bbc.co.uk
Mon, 26 Mar 2001 18:25:32 +0100 (BST)


On Mon, 26 Mar 2001, David Glaude wrote:

> >From: William W. Ferrell [mailto:wwf@frontierdev.com]
> >Sent: lundi 26 mars 2001 17:36
> >Subject: Re: [lcdproc] TCP or .so
> >
> >--- joris@robijn.net's mailer spewed these beefy chunks ---
> >> I hope you noticed that we were talking about the widget language. I 
> >> could use a hash table here, it could speed things up.
> >
> 
> HASHING
>
> I suggest anybody interested in that part to have a look at:
> GPERF http://www.cco.caltech.edu/cco/texinfo/libgplusplus/gperf_3.html
> because it is the GNU one.

This is the only reason to have a hash for a /config file/, it's allready
here and implemented :)
I think it's not worth the effort to use a hash for config file (with
max of few hundred lines). Because you need the axtra time only once on
startup.

An hash it's best used in a place where you have a lot of lookups (yep I
know here are other conditions to look at).

So I would use a hash for the widget/screen/client id's but not for the
config (an sorted array/list is the maximum effort I would do).

> >[MtxOrb]
> >serial_device=/dev/ttyS0
> >serial_baud=19200
> >serial_stop_bits=1
> >serial_data_bits=8
> >serial_parity=N
> >
> >It's more verbose, but guarantees parsing will be easier, and stops the
> >driver having to worry about it. It can simply "assume" a configuration
> >if the more advanced serial settings aren't specified, or if it wants to
> >be a tightwad, could refuse to run (perhaps report an error to LCDd, or
> >gracelessly crash and burn like v0.4 does ;) if the options aren't set.
> 
> If I remember the way v0.4 work, we have an init function for the driver
> and the driver get something like a string (that need to be parsed).
> Maybe we could have a (argv,argc) kind of argument (list of string).
> Each of those string would be in the format "xxx=yyy".

I've used a similar approach. The driver supplies a an array/struct/buffer 
with options and type of values to the server (like: serial_speed, int).  
In this case the server can parse all the option (ok not all but most) and
pass these to the driver.

Bye Andre'
-- 
Andre' Breiler                       |   Tel: +44 1737 839532
BBC Internet Services                | Email: andre.breiler@rd.bbc.co.uk 
Kingswood Warren,Tadworth,Surrey,UK  |   URL: http://support.bbc.co.uk/
Mail me.  Don't phone if possible. And use a Subject line.



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net