That is let the percentage increase gradually. The current granularity is still
very rough, but at least it gives an indication of getting closer to fully
loading the data. The previous configuration on the other hand only suggested
something was happening but with no indication where in the load process
gnucash was.
This prevents calling xaccAccountRecomputeBalanceInCurrency on each split that gets added,
which was exponentially increasing load times. On a huge test book the
load time dropped from 53 minutes to 1m20s.
The core issue was that the delete visitor was never called because its parameter
type (char *) didn't match the boost::variant type (const char *).
Fixing the visitor's parameter type also require a const_cast
back to char * because that's what g_free takes as argument.
The rest of this commit is merely fixing KvpValue instantiations that
tried to create a char* KvpValue from a stack based const string instead
of a heap allocated one. That would bomb out on calling the
delete visitor.
Splits were not marked for deletion if the transaction is read-only
and the account is not marked for deletion yet. The net result is
that split will not be freed later on.
However xaccSplitDestroy is also called from a Transaction's do_destroy.
At that point accounts are not necessarily marked for deletion yet (like
is the case when a datafile is closed). This turned out to be a problem
for invoice post transactions (which are also read only) and hence
would cause memory to leak.
1. LC_ALL should set default-report-currency to USD
2. change test monetary output from list-of-strings '("$25.00") to
monetary pairs '(("USD" . 25)) which should be locale independent.
Always use absolute paths for configured directories (BINDIR etc.)
Abstract out the guts of gnc_gbr_find_foo_dir for foo in lib, bin, and data.
etc requires special handling because of the way it's treated if prefix
begins with /opt.
Always fall back on the configured directory if binreloc is disabled and
no default is passed in.
The table storing cell dimensions was never freed. The size of this table is
directly proportional to the number of cells in the register. So the more
transactions/splits in a register, the more memory was leaked - each time
a register was opened and closed. With my huge test book I saw leaks of
4Mb-10Mb per page that was opened/closed.
These functions are not actually exported in report-system.scm so they
are not generally available to external reports. It should mean
they're safe to remove.
collectors are accumulator-type objects, being mutated with each call,
rather than functional objects. (map) is meant for functional
constructs, returning a list to current continuation. We're not using
the (map) output, so, change it to (for-each) to emphasise this.
