| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It is also optional, which is useful for generated items.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
commodity.h - code for commodity_t
annotate.h - commodity annotations
pool.h - commodity pool management
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
There was a if statement with an inverse boolean meaning, which caused
some automated transaction postings to have a null amount.
|
| |
|
|
|
| |
The last commit did not contain the majority of changes because of a
slight mishap. This contains the real changeset.
|
| | |
|
| |
|
|
|
|
|
| |
This is like -V, except it lets you specify the goal commodity to report
in terms of, for example:
reg -x CAD
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Since cost reports are now calculated by setting the amount_ expression,
there is no need to track a separate "total cost" entity.
|
| |
|
|
|
| |
xact_t::add_to_value, in cases where the xact had a "compound" total,
was adding transaction values to the running total twice.
|
| |
|
|
|
|
| |
This allows reports to access the "whicheth" index of the reported
transaction. It's used mainly by the --average report, which divides
the running total by this count to get the arithmetic mean.
|
| |
|
|
|
|
| |
That is, if a metadata tag cannot be found in a transaction, look in the
parent entry to see if it was set there. Transactions "inherit"
notational details from their entries.
|
| | |
|
| |
|
|
|
| |
That is, if the user didn't enter an amount for that transaction in
their ledger journal, don't print one out either.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
