| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The app objects both makes the whole program sort of behave like one
class in some object oriented languages, with an implicitly (actually
hiddenly explicitly) passed 'app' argument to all methods. Multiple
concurrent apps should be supported, but is of now untested.
The app is also configured to lazily bind all its fields, which means
that almost all loading is now lazy!
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Old init setup had the fancy idea to parse all files before anything
could be done with them. This however led to problems when a part of the
program which didn't care for the calendar files (such as text
formatting).
It also made testing performance almost impossible since to much code
was run before I had a chance to init statprof.
|
