python parser for dotconf file

Hemant Goyal goyal.hemant at gmail.com
Wed Jul 9 12:51:08 EDT 2008


Hi Hynek,

I was working on the parser the whole day today, and have developed
something that we can at least start working with. I like the idea of simply
commenting out the parameters instead of deleting them. That will require me
to make certain changes to the current code, I'll make those changes after
your feedback.

You can get the latest code (with proper documentation and examples) at:
http://www.nsitonline.in/hemant/stuff/pydotconf/pydotconf-0.9.tar.gz


I think in case of AddModule, this should be only one
> dotConfObject which is a list. The object should know,
> that its first level of list is being represented by multiple
> option lines.


Hmmm, I can build a  Ismultiline attribute into the object to handle this.
Lets see..

In case these lines are scatered around the config file
> and it is necessary to modify them, I'd say that the all
> the corresponding AddModule lines in the output
> should be written to the configuration file at the place
> where the first AddModule line occurs and the other
> original AddModule lines that do not immediatelly
> follow should be commented out or deleted.


Thats pretty much what is happening, at the moment, writing back to the
place where the original line was difficult, so I write them at the end of
the file. Please take a look at the present process once, and then I will
make changes as required.

I don't understand this very well. So the python library is used for initial
> speechd configuration? Or is some reconfiguration on-the-fly being done?
> What do you mean by preserving speech synthesis settings? What kind of
> settings?


We have two types of clients in OLPC:

   1. sugar - main client
      1. whatever settings are applied to this client for speech synthesis
      (pitch, language, volume, rate, etc) should automatically be inherited by
      the secondary clients. So we change the default settings in speechd.conf
      every time  changes are made by the user in a GUI for controlling
      speech-dispatcher settings. So whenever a secondary client connects to
      speech-dispatcher the settings that were chosen for the sugar
client will be
      applied as default for the secondary client.
      2. Now the changes in the settings will also be made on the fly for
      the connection between sugar and speech-dispatcher.
      2. activities - secondary clients
      1. Inherit default sugar settings
      2. Can change and apply client-specific settings over the sugar
      settings that we have stored in speechd.conf

I hope this clarifies the process?

Again I was a little excited about the parser so I wrote a prototype in a
hurry. I'll release another version after feedback this time :).

Best,
Hemant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080709/f6dcb5b5/attachment.html>


More information about the Devel mailing list