TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: Mark on June 23, 2004, 07:13:01 AM
-
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?
-
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! :(
-
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!!
-
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. :roll:
Cheers for now. :)
-
*cough!* XML
-
*cough!* XML
Good point. A capable, albeit bloated format. :)
-
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.
-
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.
-
*cough!* XML
think of it from the users perspective. can joe user figure it out?
-
... 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. :roll: )
-
...( I hope you don't interpret my participation thus far as antagonistic; sometimes I don't read to well of boards like this. :roll: )...
...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!
-
( I hope you don't interpret my participation thus far as antagonistic; sometimes I don't read to well of boards like this. :roll: )
No, not at all.
-
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?
-
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 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.
-
I think we need to define our audience, when I first thought of this I was thinking about the end user of what ever program that includes our function when in fact I should have been thinking about the programmer who is going to included this function in his program.
-
Yah......leave the ol' Bear out in the cold....up a creek w/o a paddle....the un-bear, un-wanted, un-appreciated & un-derfed.....(sob!)
-
I think our target audence shoule be old men who like to canoe. (whatda think?)
Mark, I think we are talking about a "standard" For every procedure we create we would need to read that file to get the users settings and set those values as their default. So lets say that instead of ...OMG! I think i might have an idea; Let me mull on this a sec.
-
I think our target audence shoule be old men who like to canoe. (whatda think?)
I think most guys like a bit of canoe here and there. :)
Oh, did I share too much?
-
lol. ummm, yep!
Here is what i was thinking about:
Lets take a general procedure idea of setting up layers in a drawing. (This might be a bad example but bear with me)
Lets say that the user has several diff main clients each with their own "standards" we could retrieve the file and read the layers and their settings from the drawing directory. The application will work with multiple diff "clients" cause all they need is a file in that dir with values.
..ok that was a bad example.
-
How about this for the specs?
This function will have the ability to read, write and replace variable values placed in a ascii file. The variable and value shall be separated by one '=', no spaces allowed on either side of the '='. All lines that begin with the comment character will be ignored.
function shall require three(3) arguments
1) file name and path if needed
2) what is the comment character
3) what is the function going to do, i.e. read, write or replace a var.
Example:
(defun func (filename "#" "r" / local vars)
( .........
)
-
My own inclination is to initially forgo the identification of any functions, instead defining the standard with regards to what type of data we wish to store, what kind of layering of that data might be required, and then determine what functionaility is required to retrieve and maintain the information hosted by the container as defined. This is frequently an iterative process.
However, given that the properties and methods often suggest what a container can host, perhaps a review of this info (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/unicode_layer_ini_file_functions.asp) would serve as a starting point. :)
-
Ok, Ok. I was thinking about this on my drive home. How about this: Keep it simple stupid Lets not worry about what the config file is for or its data. Lets work on a procedure to just write information to a ascii file. Reason: Lets say that i had a big application that needed a config file or a storage file we should cerate a procedure to read and write to a file... My point is; I dont think we should wory about syntax, just let the programer worry about that.
(defun ConfigFileGen (file comment info value)
~open file~
~ add comment ~
~add info~ ~add value~
*recurse thru untill done*
)
-
Maybe I can help. Here is a little snippet from my dwgtrkr.lsp:
(defun configfilesetup ()
(setq file (open "x:\\xxx\\config.asc" "a")
empt (strcat "")
firs (strcat "xxxxxxx" setting1 "")
scnd (strcat "xxxxxxx" setting2 "")
thir (strcat "xxxxxxx" setting3 "")
)
(write-line empt file)
(write-line firs file)
(write-line scnd file)
(write-line thir file)
(close file)
(princ)
)
Maybe it will help, and maybe not. figured i would try.
-
I would agree with Mr. Puckett. It's all about data. No data, no need.
What kind of data would you want to process and which facilities do you want to offer?
The coding is the easy part.
-
>What kind of data would you want to process
variable=value
>which facilities do you want to offer?
read, write and modify
I hate to sound redundant but........, I guess I'm missing something here. *mark is confused* :D
-
Ok, then that's settled .. on with the coding :)
-
>What kind of data would you want to process
variable=value
Would that be the only requirement? Should data be grouped? Conditional? Any special identification?
What I'm driving at could for example be a utility that reads a range of settings in a drawing where each kind of data could hold different attributes. For example, say you want to export layers, dimstyles and some system variables.
To identify a layer, you would have to deal with multiple values (or attributes), e.g.:
LAYER=name;color;ltype;lweight;plot
whereas system variables would simply be identified by name=value
Dimstyles could be enclosed in a special syntax:
[Dimstyle=name]
DIMSCALE=1.0
DIMEXE=2.0
DIMTXSTY=Standard
[Dimstyle]
And so on ...
-
I'm not ignoring you Stig, I'm thinking ............ :D
I now understand what you and Michael where talking about. Sorry for being so........ um.... ignorant!!
-
Thinking is good :)
-
PS You forgot Keith.....where IS he, anyhow? This sounds like sumpin he'd like to play with.
I have been ugh ... working ... internet is down at work and I can't connect until I get home, unless I want to connect at 19k .. much too painful to sit and watch the blank screen to download the next selected link ....
Anyway, It seems like a good idea folks .... and I agree with Stig we do need to define a setting group.
I suggest something along the following to begin defining the standard .....
Groups should be used, groups should be divided into segments headed by a group name
In this group you can have an unlimited number of subgroups. Each of these subgroups can be set apart just like coding in C++, with a simple twist.
For example:
[dimstyle]
dimension1={
Dimexe=1.0
Dimaso=2
}
dimension2={
Dimexe=1.0
Dimaso=1
}
[layer]
wall={
color=yellow
linetype=continuous
lineweight=0.1
plot=1
}
[sysvars]
clayer=wall
cmdecho=1
-
Very nice, clean and consequent, Keith.
Mark, before everything comes of course the question of what it should be used for. When you said "joe user" I took it that the average user should be allowed to set up things that are not programming related.
If it's merely for settings used privately by a custom application then it would probably be enough with a bunch of variable=value's
-
Very nice, clean and consequent, Keith.
Mark, before everything comes of course the question of what it should be used for. When you said "joe user" I took it that the average user should be allowed to set up things that are not programming related.
If it's merely for settings used privately by a custom application then it would probably be enough with a bunch of variable=value's
that was my original thought but after Michael mentioned the other possiblities I don't feel that way anymore. After all if the function can do all that then there is no need for the user to ever see the file.
I like Keith's idea also.
-
Well lets coe up with some solid ideas so we can get this thing done ... or not ...
-
What about comments? Are we going to have a definitive comment character? Like ';' or '#' ?
I see know easy way of coding for in-line comments, it could be done but is it worth it?
[dimstyle] # in-line comment
dimension1={
Dimexe=1.0
Dimaso=2
}
-
Sorry folks, I'm not ignoring this thread, but between <cough> the excitement yesterday and the new standards forum, this thread got back burnered.
However, being a stick in the mud, I am still not seeing why the .ini format could not address the need identified thus far. While I would enjoy helping hammer out a new spec, nothing I've seen so far seems to warrant it, but I fully acknowledge that I have been wrong many times before. :)