The Python API incorectly had GncCommodityTable.get_namespaces() defined
as a list of GncCommodityNamespace over the correct list of String. This
fixes the issue and adds a test for GncCommodityTable.get_namespaces()
and GncCommodityTable.get_namespaces_list().
Note: This is not a direct fix as I could not get SWIG to detect/convert
"GList *" to a "gchar *" to a Python str list.
Note the operands are const GncDate& because the GncDate has no copy
constructor/assigment operator (any other definition would fail
when used with variables of type boost::optional<GncDate>)
This required a couple of tweaks to the tests because:
- the invalid date returned for impossible conversions is different between the old implementation and the cpp edition
- unhandled glib warnings caused the tests to abort
This double free happened after the introduction of a class variable (static member variable
to GndDate and the test compiling in gnc-datetime.cpp *and* at the same time linking to
gnc-qof. This apparently threw off internal memory management. Removing either of linking to
gnc-qof or compiling in the source file solved it.
Credits go to John Ralls for debugging this.
For some reason gnc-vcs-info.h isn't found properly any more although
the relevant parts of the Makefiles haven't changed compared to the
maint branch. Perhaps a compiler option has changed ? Anyway simply
adding its path explicitly does fix it.
As a GncDate doesn't have any time information, this has to be made up.
GnuCash uses 3 times-of-day quite a lot:
- start-of-day (00:00 local time)
- end-of-day (23:59 local time)
- neutral time (10:59 utc, chosen to minimize
day offsetting when converting to/from localtime)
A second parameter to the new constructor will tell it to use one of these presets.
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.
