| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
is in doc/, etc.
|
| | |
|
| |
|
|
| |
commented out, but now it's nearer the right place for conversion.
|
| | |
|
| |
|
|
| |
are now possible.
|
| |
|
|
| |
acprep.
|
| |
|
|
|
|
|
|
|
|
| |
compare compare_items<T>
handler item_handler<T>
iterators used to iterators sets of journal objects
filters derived from item_handler, they morph the result set
output derived from item_handler, these do the printing
Also, created a new 'help' files which contains just Ledger's help text.
|
| | |
|
| |
|
|
| |
within the new scheme.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What this means is that the utility code, basic math, value expressions,
string formatting and option handling are now entirely decoupled from the rest
of the code. This decoupling not only greatly simplifies the more basic parts
of Ledger, but makes it much easier to test and verify its completeness.
For example, when the formatting code %X is seen by the format parser, it
turns into a call to the expression function fmt_X, which must be defined when
the format string is first compiled against an object. If that object is a
transaction, the transaction's scope will be the first to have a chance at
providing a definition. If an account is being reported, it will. If neither
does, the next scope in sequence -- soon to be the current report -- will, and
then the session object that "owns" the current Ledger session.
In 2.6, the formatting code new everything about transaction and accounts, and
relied on flags to communicate special details between them. Now the
transaction will offer the details for its own reporting, while the formatter
worries only about strings and how to output them.
|
| |
|
|
|
|
|
|
|
| |
There are now three commands one can use to interact with value expressions
directly:
ledger parse EXPR # shows the parse tree resulting from EXPR
ledger compile EXPR # shows what the compiled tree looks like
ledger eval EXPR # print the resulting value, useful in scripts
|
| |
|
|
| |
about journal objects. This is all done through value expressions now.
|
| |
|
|
| |
the way that value expressions extract information from journal objects.
|
| | |
|
| |
|
|
|
|
|
| |
old system (for example, the meaning of 'a') has yet to be restored. In the
new scheme, this will be done by definition a function outside of the value
expression logic, rather than the tight coupling between journal innards and
value expressions that occurred in 2.x.
|
| |
|
|
| |
getting everything back up to what it was (plus the new code written for 3.0).
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
fails due to the fact that 2.x value expression syntax is not restored.
|
| | | |
|
| | |
| |
| |
| | |
report, session, parts of xpath, main, journal, option.
|
| |/ |
|
| | |
|
| |
|
