| Commit message (Collapse) | Author |
|---|
|
This new setup stores all configurations are parameters. This forces
everything into modules, and ensures that we can't have a module use an
unloaded config. It (unfortunatelly) also causes users to have to
specify namespaces when defining values, but ini-files (and the like)
already does that. Also, there is nothing stopping a new `set-config!'
from being defined which allows un-namespaced operation.
The commit also removes the introspection procedures. They where a bit
weird to begin with, since they only showed loaded fields. And since the
program had no way of properly serializing or deserializing them we
remove them for the time being. They would however be good to
reintroduce together with a proper menu for editing simple
configuration (see Emacs' `custom-set-variables').
|
|
|
|
|
|
|
|
|
|
This is the first (major) step in splitting the generally useful items
into its own library.
|
|
|
|
|
|
|
|
|
|
|
|
Tried adding a ./configure script, which mostly is responsible for
downloading a default zoneinfo file, and setting up the environment for
the program.
I have for quite a while thought about having a configure system for
things like these, but also for setting up default paths. Let's see if
it works out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Placing all possible configuration items in a central (parameters)
module scales really badly. This idea that any module can register
configuration parameters is better. The current implementation however
has the drawback that it requires that the module exposing the parameter
is loaded before the value can be sat, but that scales even worse.
A probable solution would be to abandon binding everything to guile's
module system, and instead let (util config) provide a `conf-ref' and a
`conf-set!' procedures.
A `define-configuration' similar to emacs `defcustom' could be of use,
mainly for retroactively type checking parameters.
|
