| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This means transactions can only have day-level granularity -- which has
always been the case from an data file point of view. The advantage to this
restriction is that reports will now be immune from daylight savings related
bugs, where a transaction falls to the wrong side of a --monthly report, for
example.
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
complicated string of pointers, it's now just a global block of text that gets
appended to as the error is being thrown up, and can be displayed at the catch
point if desired. There are almost no cases where a thrown exception will not
result in an error message being displayed to the user.
|
|
|
|
|
|
| |
except for several unused parameter warnings (because there is so much code
still #if 0'd out), and one implicit conversion from long long to long which
still has to be dealt with.
|
|
|
|
| |
functions for each of the journal objects has yet to be ported.
|
|
|
|
| |
the way that value expressions extract information from journal objects.
|
|
|
|
| |
value_t, rather than the rest of Ledger proper.
|
|
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.
|