The biggest problem was that a pointer to an out of scope struct tm was
passed to the wrapped function. With opt level 2, clang doesn't bother
setting the contents of the struct since it goes out of scope without being
used. This caused the transaction report to never report anything since
the start and end times it got were ridiculous.
Also most functions that take a struct tm pointer can change the contents
of the struct (if only to normalize it) so pass the new values back to Scheme.
Finally all calls to gnc_localtime and gnc_gmtime from Scheme leaked a struct tm
and calling gnc_tm_free from Scheme is a really bad idea so don't wrap it.
Mike Alexander brought this up with a test case that failed to round down
sufficiently; he found that reducing the rounding denominator by 2 sufficed
to make his test case pass.
In fact the sizing of the replacement denominator by shifting the larger of
the numerator or denominator by an arbitrary 62 bits was not correct most
of the time, so instead we begin with a shift of the full lower leg worth,
try to do the conversion, and if the conversion is still “big” shift the
larger value one more and try the operation again, repeating until the
result will fit in a GncNumeric.
In order to allow to revert the newly introduced behaviour of putting
transaction text in front of the extracted purpose, the feature can now
be disabled through the preferences dialog.
Some banks include additional purpose information for a transaction in
non-swift-section 17 (aka transaction text). If available, this
transaction text is put in front of the other purpose texts to provide
full transaction information.
While the final solution is still under discussion. This change is a
first low-impact implementation backported and distilled from the work
discussed in gnucash/gnucash#139.
Fixing Bug 779217 increased the maximum denominator by 10, and that led
to overflows when converting large numbers' denominators from 100 to the
new max.
Correct the cell save routine so that the "numeric" kvp is correctly
overwritten in all instances when an edit changes its value for both
credit and debit splits. The both part is accomplished by extracting the
overwrite function.
Also provide a scrub to correct all of the incorrect files.
Unfortunately the necessary calculation function is in app-utils so
running the scrub from the backend as usual isn't possible, so we run it
from gnc_post_file_open in gnome-utils/gnc-file.c instead.
This patch simplifies the previous patch so it does not care where the
file is opened from. If it is in the history list and does not exist,
the dialog advises of this and asks if it should be removed from the
list other wise the dialog displays file not found.
- cleanup whitespace
- add import-pending-matches.c to POTFILES.in
- convert asserts into g_return(_val)_if_fail
- handle the case where no matches are found (which can happen at least in the csv importer and I suspect in the OFX importer as well)
Track pending matches from the current import and display this information in
the match picker.
Conflicts:
src/import-export/gschemas/org.gnucash.dialogs.import.generic.gschema.xml.in.in
src/import-export/import-match-picker.c
https://bugzilla.gnome.org/show_bug.cgi?id=739571
Total Debits Issue re $0 Commodity Accounts and Price Source Mode Set to
"Nearest in Time" or "Most Recent"
There was a silent error from gnc-numeric-sub-fixed in
collect-unrealized-gains because a 0 value wasn't getting its
denominator set in the gnc-numeric-mul call in
gnc:exchange-by-pricedb-helper. While this is ultimately a flaw in
gnc-numeric, this commit works around it by forcing the value to the
correct denom in gnc:make-commodity-collector.
