Topic: Group project

[Mark]

I have an idea for a group project. Create a standard function that reads some type of config file and return the values in a association list of variable and value. The function should accept at least one argument, the name/location of the config file to read, with the possibility of a comment character.

Example:
# config file to read
# <-- denotes a comment
Variable=value
# or
Variable value
# end of config file

in return from our function we would get an association list in the form of;
(("variable" . value))

thoughts?

[MP]

Sounds like an INI FILE to LIST type of thing (defun INI->LIST ( FileName ) ...), and I believe (or logic suggests) it has already been done (several times over).

However, if it's for the sake of an exercise it would be fun, with the strict provision that the participants draw solely from their own grey matter; no other forums, newsgroups etc. used as resources.

If I had the time I would have kicked this off with an outline of all the perceived required functions, but alas.

I would say that you'd want the ability to read from, publish to, replace, find ...

... gotto head off to work now, doh!

[Mark]

Sounds like an INI FILE to LIST type of thing (defun INI->LIST ( FileName ) ...), and I believe (or logic suggests) it has already been done (several times over).

True, it has been done for an .ini file, however I was thinking something other than the INI format.
 

I would say that you'd want the ability to read from, publish to, replace, find ...

I had not thought of the last two, good idea.

... gotto head off to work now, doh!

Don't you just hate that!!

[MP]

True, it has been done for an .ini file, however I was thinking something other than the INI format.

Help me out Mark, how does "variable=value" differ from the ini format, and ... what would be the benefit(s) of establishing a different format? I think to fully answer that you'd have to identify where the ini format comes up short and could be improved upon (challenge extended).
 

... gotto head off to work now, doh!

Don't you just hate that!!

Yes and no.

Cheers for now.

[JohnK]

*cough!* XML

[MP]

*cough!* XML

Good point. A capable, albeit bloated format.

[JohnK]

lol. But zero to no updating required. Once your able to "talk to the parser" all your work is done. You never have to worry about format changes or anything like that.

[Mark]

 Help me out Mark, how does "variable=value" differ from the ini format, and ... what would be the benefit(s) of establishing a different format?

It doesn't, but we could make the separator anything, the '=' seemed like the easiest to program and understand from the users perspective. The .ini files typically use headers(?) as in '[foobar]' which is more than I was thinking in terms of programming. The benefits of establishing our own format would be just that, it's ours, something different. I'm not knocking the INI format here, it's very easy to understand, it's just that it's already been done. Of course creating a format that hasn't might be more of a challenge than writing the function that reads it!

One of the things we should consider (maybe the most) is from a users perspective. How easy will it be for the average user to understand the format of the config file.

[Mark]

*cough!* XML

think of it from the users perspective. can joe user figure it out?

[MP]

... we could make the separator anything, the '=' seemed like the easiest to program and understand from the users perspective. The .ini files typically use headers(?) as in '[foobar]' which is more than I was thinking in terms of programming. The benefits of establishing our own format would be just that, it's ours, something different. I'm not knocking the INI format here, it's very easy to understand, it's just that it's already been done. Of course creating a format that hasn't might be more of a challenge than writing the function that reads it!

One of the things we should consider (maybe the most) is from a users perspective. How easy will it be for the average user to understand the format of the config file.

It sounds to me like a specifification needs to be developed, and as such, you need to open this discussion to those "users" you refer to that need to have this "easy" format, lest "we" construct a great new format that meets "our" needs as bit pushers but leaves users scritchin' their nuggins.

( I hope you don't interpret my participation thus far as antagonistic; sometimes I don't read to well of boards like this. )

[JohnK]

...( I hope you don't interpret my participation thus far as antagonistic; sometimes I don't read to well of boards like this. )...

...I got a smile on my face. (I read things said on this board "positivley" first.) No one is gonna take what you say neg. Here watch:

Mark is an orange picker!!!
Dent is an old man!!
T-Bear couldnt canoe out of a paper bag!
Craig dosent know what HTML is!
...

Hey, that was kinda fun!

[Mark]

( I hope you don't interpret my participation thus far as antagonistic; sometimes I don't read to well of boards like this. )

No, not at all.

[JohnK]

Ok Mark i think i am starting to understand you now, but i guess I wanted an example usage for this app.
Drawing properties, or for future applications that we write?

[Mark]

OK, let me backup a minute. MPuckett mentioned earlier "I would say that you'd want the ability to read from, publish to, replace, find" If the function can do all of those things why am I hung-up on the format of the config file *shrug* who knows! Anyway moving right along.......

[t-bear]

T-Bear can't get his canoe INTO a paper bag!








See, I *was* paying attention!
I haven't got a clue, but I'm paying attention.



PS  You forgot Keith.....where IS he, anyhow? This sounds like sumpin he'd like to play with.