[mOved] New lib for ".ini" files - Page 4

Here's a fixed version (still not runtime-tested, but it compiles without warnings now):

#define FAIL 1
#define SUCCESS 0
short conflib__get_string_key(const char *file, const char *section, const char *key, char *value, long max_length, const char *defaut) 
{ 
  FILE *f=fopen(file,"r"); 
  if (!f) return FAIL; 
  char sechead[strlen(section)+3]; 
  sprintf(sechead,"[%s]",section); 
  int r; 
  do { 
    r=fscanf(f,sechead); 
    if (r>0) goto secfound; else if (!r) r=fscanf(f,"%*s"); 
  } while (r!=EOF); 
 notfound: 
  strncpy(value,defaut,max_length); 
  value[max_length+1]=0; 
  goto valfound; 
 secfound:; 
  char valhead[strlen(key)+18]; 
  sprintf(valhead,"%s = \"%%%lds\"",key,max_length); 
  do { 
    if (fscanf(f,"[%*s]")) goto notfound; 
    r=fscanf(f,valhead); 
    if (r>0) goto valfound; else if (!r) r=fscanf(f,"%*s"); 
  } while (r!=EOF); 
  goto notfound; 
 valfound: 
  fclose(f); 
  return SUCCESS; 
}

Flanker
: - in your example, you don't take care of file searching (you must create the file when it doesn't exist,

Even when reading? Why?
When writing, sure, fopen takes care of that.

you must search in a single system folder,

Well, fopen looks in a single folder, the current folder. If you want a fixed folder instead:

  char filename[strlen(file)+6];
  sprintf(filename,"main\%s",file);
  FILE *f=fopen(filename,"r");

It's all easy in C.

I honestly don't understand what you're trying to prove us, Kevin

That there is no need for ini files whatsoever? That it is very easy to implement and that Flanker or assembly sucks? Even so, that everyone should reimplement this from scratch in their own project and that this library should not exist? Or that it should be a static library and that every program using read-write support should eat 6 extra kb?

I disagree with all of the above and I wonder what your point is...

Well, most of this...
* There is not much point in using INI files over binary config files on the calculator.
* It is very easy to implement.
* If at all a library is used, it should be a static library, or at the very least there should be both versions as for geogeo's PolySnd. And that static library could be smaller than my sample code. *scanf is known to be a source of bloat.

* wrong, a number of reasons have been given, to which you didn't answer so I assume you accept them? (see my post ./76, squale's ./75)
* wrong again, Flanker and I have explained to you to what extent your implementation was "rough"; and it's harder to implement if you want it to be size-efficient
* actually, I don't want to troll on this last point, as it has nothing to do with what you were saying previously (you were only criticizing flanker's implementation...) and as it has already been discussed many times in the past

Pollux :
* wrong, a number of reasons have been given, to which you didn't answer so I assume you accept them? (see my post ./76, squale's ./75)

Well, I, for one, am definitely not going to compile in kernel mode and link to a kernel library just to be able to parse a few debug options. If anything, I'd use something like my code, I don't care if it is huge if I am going to disable it for the release anyway.

* wrong again, Flanker and I have explained to you to what extent your implementation was "rough";

I fixed the quote issue (just a straight change to the format string), any more bugs?

and it's harder to implement if you want it to be size-efficient

For debug-only stuff, I couldn't care less about size-efficiency. For release stuff, I'd never use a text-mode INI file, binary config files are much more size-efficient.

Kevin Kofler
:

Pollux
:

* There is not much point in using INI files over binary config files on the calculator.

* wrong, a number of reasons have been given, to which you didn't answer so I assume you accept them? (see my post ./76, squale's ./75)

Well, I, for one, am definitely not going to compile in kernel mode and link to a kernel library just to be able to parse a few debug options. If anything, I'd use something like my code, I don't care if it is huge if I am going to disable it for the release anyway.

* you didn't answer to ./76
* the initial need for ini files is totally orthogonal to conflib being a kernel library -- don't change subjects

* wrong again, Flanker and I have explained to you to what extent your implementation was "rough";

I fixed the quote issue (just a straight change to the format string), any more bugs?

You can't write to the .ini... And this implies a lot more code... Not to mention that in order to deal with escape codes, you would have to parse manually ^^

Pollux :
* you didn't answer to ./76

OK:

Pollux
:* it easily ensures backwards compatibility as new features are introduced; it allows common configuration parameters to be shared across several programs

All this can be done with properly-designed binary configuration files.

* if you impose the order in which you parse, yes; but conflib allows sections and definitions to be moved around within the file, just as it allows you to keep unchanged keys that you can't handle (think of this config file :

[DefaultApplications]
TextViewer = "AMSTextEdit"
TextEditor = "AMSTextEdit"

- your favourite text viewer could modify the default text viewer, even though it doesn't even know about the TextEditor key! thus it also provides some form of forward compatibility)

Well, IMHO, if they don't know about each other, they shouldn't be poking around in the same config file.

So far for ./76.

* the initial need for ini files is totally orthogonal to conflib being a kernel library -- don't change subjects

I'm not changing subjects, I'm only explaining why I'm showing how easy it is to implement this yourself...

* wrong again, Flanker and I have explained to you to what extent your implementation was "rough";

I fixed the quote issue (just a straight change to the format string), any more bugs?

You can't write to the .ini... And this implies a lot more code...

Why would I need that? If I have the program write a config file, I write it out in binary, not text. Only hand-edited config files need text mode.

Not to mention that in order to deal with escape codes, you would have to parse manually ^^

Well, I never claimed to support escapes.

Well, it happened that Flanker felt a config lib should be useful. Some people agreed to that. Therefore, the lib exists (©). If you don't like it, don't use it, what's the matter ?

And shall I remind the subject is not nostub vs kernel ?

Kevin Kofler
:

Pollux
: * it easily ensures backwards compatibility as new features are introduced; it allows common configuration parameters to be shared across several programs

All this can be done with properly-designed binary configuration files.

Obviously (a text file being some kind of binary file ), but that means more work (write a spec...), and quite a bit of parsing.

* if you impose the order in which you parse, yes; but conflib allows sections and definitions to be moved around within the file, just as it allows you to keep unchanged keys that you can't handle (think of this config file :

[DefaultApplications]
TextViewer = "AMSTextEdit"
TextEditor = "AMSTextEdit"

- your favourite text viewer could modify the default text viewer, even though it doesn't even know about the TextEditor key! thus it also provides some form of forward compatibility)

Well, IMHO, if they don't know about each other, they shouldn't be poking around in the same config file.

That's your point of view. But in situations like the one I mentioned, it's clearly useful to have such a common configuration file

Pollux :
Obviously (a text file being some kind of binary file ), but that means more work (write a spec...), and quite a bit of parsing.

With a properly-done spec, there should be little to no parsing. Just use a structure containing any fixed-length data and offsets to any variable-length strings. Then there is nothing to parse, just structure accesses. And any future extensions can be added to the end of the structure with no problems whatsoever.

Things are not so easy
The format you're giving will be a mess to maintain if, say, you want to change the size of an integer field; and if you happen to remove some fields or change their meaning, you'll have to do a lot of bugware to maintain compatibility with old versions...

Pollux
: The format you're giving will be a mess to maintain if, say, you want to change the size of an integer field;

Well, you don't. You have to get it right the first time. I did say "properly done". If you are unsure, just put in unsigned long long.

Kevin> If you don't feel this library useful, just don't use it, as Ximoon said.

Of course it can be rewritten for each program, but the point of a library is to avoid to write a lot of code, by using it.

Finally, I think it may be useful for some programs, and INI files are really easier to use than binary files espacially for users.

Kevin Kofler
:

Pollux
: The format you're giving will be a mess to maintain if, say, you want to change the size of an integer field;

Well, you don't. You have to get it right the first time. I did say "properly done". If you are unsure, just put in unsigned long long.

If you think you will never change your spec in a projet, your projets will always break down...

Sasume :
Finally, I think it may be useful for some programs, and INI files are really easier to use than binary files espacially for users.

Yes,I was thinking about saveing and reloading games for example, and a nice idea would be to have a standardized file for programs, so that many program could use one only file.

Even when reading? Why?

size optimization

* There is not much point in using INI files over binary config files on the calculator.

If you don't want to lose space or time to code a nice interface which will bloat your program. If my program is only 200bytes long, I don't want to add an interface and a file-managing system which will take 4 or 5 kB

Well, fopen looks in a single folder, the current folder. If you want a fixed folder instead:

Thx, I know how to code this in C

* It is very easy to implement.

of course, but how heavy will be your lib ?
The weight of ConfLib is only 2289 bytes

* If at all a library is used, it should be a static library, or at the very least there should be both versions as for geogeo's PolySnd. And that static library could be smaller than my sample code. *scanf is known to be a source of bloat.

If you use any write function, you'll use more than 80% of my code
Today, I already have 4 progs which use Conf Lib. w(PreOS+Conflib) < 4 x w(your implementation)

All this can be done with properly-designed binary configuration files.

wrong.

With a properly-done spec, there should be little to no parsing. Just use a structure containing any fixed-length data and offsets to any variable-length strings. Then there is nothing to parse, just structure accesses. And any future extensions can be added to the end of the structure with no problems whatsoever.

- such a format is perfect for sharing config files between applications. The lib is common to all applications which want to use the config file, so we can easily share the config file. If 2 applications A and B uses the same config file for one key, and if a new version of A must use differents keys, the config file remain unchanged, and B needn't to be changed. Consider the "system" folder of PreOS. Its place is in a config file, by example, like the default shell (launched by shift-on).

Well, IMHO, if they don't know about each other, they shouldn't be poking around in the same config file.

They can share some keys, even they have some "private" keys. Sections exist for this purpose

By the way, how does get_string_key handle an inexistent key ? It doesn't create it, right ?
But wouldn't it be nice if there was a flag that could tell to create it with the default value provided if it doesn't exist ?

The idea would be that if your program just reads configuration parameters and never writes them back, then as of now you have to remember the exact name and format of all the options (which implies having the readme nearby); but with this switch, you could easily edit the configuration manually or, even better, you could use an (external) generic interface to edit it graphically... The drawback being that even if you don't need to customize the program, you'll end up with a config file filled with the default values What do you think?

But wouldn't it be nice if there was a flag that could tell to create it with the default value provided if it doesn't exist ?

A new function is planned
I can't implement it since I haven't found its name #mac#

Why not 'conflib__set_flag_that_can_tell_to_create_it_with_the_default_value_provided_if_it_does_not_exist() ' ?

Yes, I was thinking about a new function too I think it should be the "default" one (i.e. the one with the shortest name), and the other one could be something like conflib__get_string_key_nowrite...

e.g. typical code would look like

  window_width = conflib__get_num_key("bgammon2","window","width",80,NULL);
  window_height = conflib__get_num_key("bgammon2","window","height",80,NULL);
  int old_difficulty = conflib__get_num_key_nowrite("bgammon2","gameplay","difficulty",-1,NULL);
  if (old_difficulty>=0)
    difficulty = old_difficulty*42;
  else
    difficulty = conflib__get_num_key("bgammon2","gameplay","difficulty2",-1,NULL);

Flanker
:

Even when reading? Why?

size optimization

But it sure isn't required for it to work. An if (!f) goto notfound; instead of the return FAIL; in my routine would be mostly indistingushible from yours for the caller.

* There is not much point in using INI files over binary config files on the calculator.

If you don't want to lose space or time to code a nice interface which will bloat your program. If my program is only 200bytes long, I don't want to add an interface and a file-managing system which will take 4 or 5 kB

That's one reason why I dislike your library so much: it encourages laziness: "I don't feel like writing a GUI for configuration, let's just have the user poke around in an INI file instead." Programs should never require hand-editing a configuration file. Red Hat is finally managing to bring Linux away from this, and now you are importing this mentality to the calculators.

* It is very easy to implement.

of course, but how heavy will be your lib ?

My function isn't a lib, it's sample code.

All this can be done with properly-designed binary configuration files.

wrong.

No, right. It's just a matter of proper, backwards-compatible design. In almost all cases, just adding to the end of a structure should be enough for new extensions. In the others, you need to think a bit more about the design, but it is not impossible. Give a counterexample if you think I'm wrong.

- such a format is perfect for sharing config files between applications. The lib is common to all applications which want to use the config file, so we can easily share the config file. If 2 applications A and B uses the same config file for one key, and if a new version of A must use differents keys, the config file remain unchanged, and B needn't to be changed. Consider the "system" folder of PreOS. Its place is in a config file, by example, like the default shell (launched by shift-on).

This can be done with a properly-specified binary file as well! Unless of course some standard-disrespecting programmer comes around and starts adding incompatible extensions to the specification...

Well, IMHO, if they don't know about each other, they shouldn't be poking around in the same config file.

They can share some keys, even they have some "private" keys. Sections exist for this purpose

IMHO, the private stuff should be in a separate file.
But even private sections can be done with binary config files without any requirement for parsing.

Oh, and Pollux, I'll never use INI files for Backgammon.

>That's one reason why I dislike your library so much: it encourages laziness: "I don't feel like writing a GUI for configuration,
>let's just have the user poke around in an INI file instead." Programs should never require hand-editing a configuration file.
> Red Hat is finally managing to bring Linux away from this,
Another reason not to choose Fedora. You NEVER get all the options with a GUI.

Another reason for conflib is that, for example, all TSR can share the same config file, with a commun section explaining some commun stuff, and with one section per TSR for their private settings. A nigthmare to do in binary.

No, right. It's just a matter of proper, backwards-compatible design. In almost all cases, just adding to the end of a structure should be enough for new extensions. In the others, you need to think a bit more about the design, but it is not impossible. Give a counterexample if you think I'm wrong.

2 versions of the same program, with different extensions, and developped by different people ?

That's one reason why I dislike your library so much: it encourages laziness: "I don't feel like writing a GUI for configuration, let's just have the user poke around in an INI file instead." Programs should never require hand-editing a configuration file. Red Hat is finally managing to bring Linux away from this, and now you are importing this mentality to the calculators.

do you prefer to bloat your program and multiply its size by 10 ? Why don't you want to use the standard text editor to edit a text ?

IMHO, the private stuff should be in a separate file.
But even private sections can be done with binary config files without any requirement for parsing.

if you reimplement the same system without the text _tag at the end ....

Kevin Kofler
: That's one reason why I dislike your library so much: it encourages laziness

When I started to program on TI-68k, I wanted to do all the stuff by myself, but my projects where too long to write. Libraries are very useful to reduce time coding.

PpHd :
>That's one reason why I dislike your library so much: it encourages laziness: "I don't feel like writing a GUI for configuration,
>let's just have the user poke around in an INI file instead." Programs should never require hand-editing a configuration file.
> Red Hat is finally managing to bring Linux away from this,
Another reason not to choose Fedora. You NEVER get all the options with a GUI.

You're not forced to use their GUI tools, but they are there.
And if some options are hidden, it is a problem of the specific config tools, not of the idea of GUI config tools.

Another reason for conflib is that, for example, all TSR can share the same config file, with a commun section explaining some commun stuff, and with one section per TSR for their private settings. A nigthmare to do in binary.

But why do would you want that? What's the problem with having separate private settings in separate config files?

Flanker
:

No, right. It's just a matter of proper, backwards-compatible design. In almost all cases, just adding to the end of a structure should be enough for new extensions. In the others, you need to think a bit more about the design, but it is not impossible. Give a counterexample if you think I'm wrong.

2 versions of the same program, with different extensions, and developped by different people ?

Well, it's entirely their fault if they don't agree on a common format. (And yes, I know you aren't good at agreeing on formats, I already saw that... )

do you prefer to bloat your program and multiply its size by 10 ? Why don't you want to use the standard text editor to edit a text ?

Because it's a crappy interface for configuration. That's what the dialog ROM_CALLs are for. You design a static dialog and just call a single ROM_CALL to display it.

IMHO, the private stuff should be in a separate file.
But even private sections can be done with binary config files without any requirement for parsing.

if you reimplement the same system without the text _tag at the end ....

No, not at all!
I'm thinking of something like:

struct configfile {
 struct common {
  int foo;
  unsigned offsettostringbar;
  ...
  char reserved[12];
 };
 char private[NUM_PROGS][24];
 char stringdata[];
}

And in each program, you have something like:

#define PROGID 10
struct privatedata {
 int privatefoo, privatebar;
 ...
}
#define getprivate(cf) ((privatedata*)((cf)->private[PROGID]))
#define getstring(cf,offset) ((char*)(cf)+(offset))

As I said, no parsing!

Sasume
:

Kevin Kofler
: That's one reason why I dislike your library so much: it encourages laziness

When I started to program on TI-68k, I wanted to do all the stuff by myself, but my projects where too long to write. Libraries are very useful to reduce time coding.

That's not the point! It doesn't encourage laziness because it is a library, it encourages laziness because it encourages relying on hand-edited config files instead of providing a GUI for configuration.

But why do would you want that? What's the problem with having separate private settings in separate config files?

Because I want a single config file.

Well, it's entirely their fault if they don't agree on a common format.

If programmers don't have enough access to the web to communicate with other programmers ? If programs are indepedant, I don't want to create a dependence between programmers

(And yes, I know you aren't good at agreeing on formats, I already saw that... )

I don't like your allusion. It's a beginning of troll ....

Because it's a crappy interface for configuration. That's what the dialog ROM_CALLs are for. You design a static dialog and just call a single ROM_CALL to display it.

But you can't reduce it to 0 bytes ...

Flanker
: If programmers don't have enough access to the web to communicate with other programmers ?

In 2004? You must be kidding me...

Because it's a crappy interface for configuration. That's what the dialog ROM_CALLs are for. You design a static dialog and just call a single ROM_CALL to display it.

But you can't reduce it to 0 bytes ...

You can't reduce your INI parsing to 0 bytes either. The strings you'll use for your INI parsing will be mostly the same you'd use in a configuration dialog, so I don't think there's actually any size difference. And besides, saving size at the expense of functionality is not the way to go.

Kevin Kofler
:

Flanker
: If programmers don't have enough access to the web to communicate with other programmers ?

In 2004? You must be kidding me...

No a lot of student have limited access to the internet at scool and no access at home

Because it's a crappy interface for configuration. That's what the dialog ROM_CALLs are for. You design a static dialog and just call a single ROM_CALL to display it.

But you can't reduce it to 0 bytes ...

You can't reduce your INI parsing to 0 bytes either. The strings you'll use for your INI parsing will be mostly the same you'd use in a configuration dialog, so I don't think there's actually any size difference. And besides, saving size at the expense of functionality is not the way to go.

INI files can be used for a lot of things, internationalisation for exemple, just change the ini file and the program is localized (this is just another example) using a binary file for this is just a borring, and buggy way

Godzil
:

Kevin Kofler
:

Flanker
: If programmers don't have enough access to the web to communicate with other programmers ?

In 2004? You must be kidding me...

No a lot of student have limited access to the internet at scool and no access at home

Even "limited access" is enough to post a few messages. And cybercafes exist, too.

INI files can be used for a lot of things, internationalisation for exemple, just change the ini file and the program is localized (this is just another example) using a binary file for this is just a borring, and buggy way

Internationalization on a calculator? Don't you all whine about AMS internationalization?
But anyway, using a binary file is just fine for internationalization. Even GNU gettext uses binary files: the .pot text files are compiled into .mo binaries which are the files actually used at runtime.

Internationalization on a calculator? Don't you all whine about AMS internationalization?

That's a completely different: AMS localisation cause problems. A well done localisation should not.