This reduces parsing time in the optimized build by 25%, and was a safe,
easy patch. If the "quick predicate evaluator" fails, we disable it
from that point on go back to what the standard code does.
This allows for value expressions to be used which reference the
incoming posting, for example:
= Income:Clients:
(Liabilities:Taxes:VAT1) (floor(amount) * 1)
(Liabilities:Taxes:VAT2) 0.19
2009/07/27 * Invoice
Assets:Bank:Checking $1,190.45
Income:Clients:ACME_Inc
The automated posting for VAT1 will use the floored amount multiplied by
a factor, while the posting for VAT2 multiples the whole amount as
before.
The different namespaces are:
Function Value expression functions, which receive a "context"
Option Command-line options
Precommand Commands which are invoked before reading the journal
Command Commands which are invoked after reading the journal
Directive Directives that occur at column 0 in a data file
This greatly eases the ability for Python uses to add intercept hooks to
change how the basic Ledger module functions. An example of what should
be possible soon:
import ledger
def my_foo_handler(value):
print "--foo received:", value
ledger.add_handler(ledger.Option, "foo=", my_foo_handler)
id returns a unique SHA1 id of a transaction.
idstring is the string that the SHA1 is based on.
magnitude is the sum of the positive side of a transaction.
These strings are now collected automagically in the file po/ledger.pot.
If you'd like to produce a translation, just run this command after
building Ledger:
msginit -l LOCALE -o LANG.po -i po/ledger.pot
Where LOCALE is a string like de or en_GB, and LANG is a short
descriptive word for your language.
Then send me this .po file so I can commit it to the Ledger sources
(alternatively, you could maintain the file in a fork on GitHub), and
setup the build script to format and install your new message catalog
during a "make install".
The purpose of this class is much like Emacs' (interactive) form: it
allows a value expression function to declare exactly how many
arguments, and of what type, it intends to receive. It then offers
type-safe access to theese arguments in a consistent manner.
An example value expression function definition in C++:
value_t fn_foo(call_scope_t& scope) {
// We expect a string, an integer, and an optional date
interactive_t args(scope, "sl&d");
std::cout << "String = " << args.get<string>(0)
<< "Integer = " << args.get<long>(1) << std::endl;
if (args.has(2)) // was a date provided?
std::cout << "Date = " << args.get<date_t>(2) << std::endl;
return NULL_VALUE;
}
There is also an in_context_t<T> template, which finds the context type
T in the current scope hierarchy. The in_context_t then also acts as a
smart pointer to reference this context object, in addition to serving
the same duty as interactive_t. This combination of intent is solely
for the sake of brevity.
value_t fn_bar(call_scope_t& scope) {
in_context_t<account_t> env(scope, "sl&d");
std::cout << "Account name = " << env->fullname()
<< "String arg = " << env.get<string>(0)
<< std::endl;
return NULL_VALUE;
}
As you can see here, 'env' acts as a smart pointer to the required
context, and an object to extract the typed arguments.
