It seems that std::locales created by boost::locale::generator are
not entirely compatible: If used to create a new locale with a facet
for boost::date_time one ends up with the C locale and the facet.
For the time being avoid the problem by using boost::locale to format
dates and times. std::chrono gets calendar functions in C++20 so we
can switch date-time backends once we can adopt it.
We can't use std::locale::global because all streams imbue it by
default and if it's not 'C' (aka std::locale::classic) then we
must imbue all the streams that we don't want localized, and that's
most of them.
Provides error checking for setting the C++ locale from the environment.
This is necessary both because the environment might have an invalid
locale, which would cause an unhandled exception crash.
On windows std::locale("") can't handle some Microsoft-style locale
strings (e.g. Spanish_Spain) so we use boost::locale's gen("") function
to set the locale--though even that can't handle a Microsoft-style
locale string with an appended charset (e.g. Spanish_Spain.1252) and
that's what glibc's setlocale(LC_ALL, NULL) emits.
Testing notes: Based on the averages of 3 runs, the net
user CPU to save the XML file I use is:
10.2 seconds without this change
7.6 seconds with this change
In my environment the first call to the format routine
in question, the call that sets the cache value, is at
the end of the XML load.
The refactoring provides roughly 10% reduction in user CPU
use for XML file load by moving an expensive function
to within an if-clause where the result is used. The diff looks
like a full re-write but only the if statements, indenting,
and commentary changed.
This value is queried on each comparison of split or txn sort function,
which means it is called quite a lot. Avoiding the KVP lookup of this
property gains a lot in terms of CPU cycles.
Because of https://sourceforge.net/p/libdbi-drivers/bugs/24.
This issue causes trouble in save_may_clobber_data() as well, so
work around it by using a SQL query instead of dbi_conn_get_table_list.
Until now GNC_CONFIG_HOME was more or less hard-coded.
Now it can be set via environment variable GNC_CONFIG_HOME.
In addition it will automatically be created to avoid potential
user confusion.
when moving entry between accounts
When using the cut transaction option the 'associated file' value was
not being pasted to the new transaction. Added scheme code to get this
value and save it to new transaction when using 'cut/copy' and then
'paste' operations. When using the duplicate option, a dialogue allows
you to keep the copied association or not. It does not get copied for
autocomplete.
This involves renaming 3 functions:
gnc_uri_get_protocol -> gnc_uri_get_scheme
gnc_uri_is_known_protocol -> gnc_uri_is_known_scheme
gnc_uri_is_file_protocol -> gnc_uri_is_file_scheme
The *_protocol variants are marked as deprecated.
Additionally a number of local variables have been renamed from
protocol to scheme to support this change.
- gnc_uri_get_components will now return NULL as protocol if the input is a normal
file system path instead of a uri (it used to return 'file')
- gnc_uri_get_protocol will now return NULL if the input is a normal
file system path instead of a uri (it used to return 'file')
- gnc_uri_is_file_protocol now returns FALSE if protocol is NULL (it used to return TRUE)
- gnc_uri_is_file_uri now returns FALSE if input is a normal file
system path instead of a uri (it used to return TRUE)
- a new function gnc_uri_targets_local_fs will return TRUE only if its input
is either a file uri or a normal file system path. This function is now mostly
used instead of gnc_uri_is_file_uri in the current code base
- a new function gnc_uri_is_uri is added to check whether its input
is a valid uri (has protocol, path and hostname for non-file uris)
Previously the account color slot has been populated with "Not Set"
when any field for the account has been edited and saved. This routine
should run once and remove all such entries.
There are a very few left that need deeper study, but this gets
rid of most of the noise. For the most part it's just getting rid of
extra variables or removing an assignment that is always
replaced later but before any reads of the variable. A few are
discarded result variables.
It can't, because if b is 0 the function would have
returned already; since b.m_hi is 0 b.m_lo can't be. The assert
reassures clang that this is the case.
We need to compare the magnitudes of the remainder and the denominator
in order to round negative numbers correctly. Note that while gnc_numeric
is constrained to a positive denominator the C++ rounding functions cannot
assume that constraint in all cases.
Combined with the previous commit, this fixes
Bug 796949 - Incorrect conversion of 0,01 USD to EUR
So that the returned price tuple has the two commodities of interest
converted to a common currency. Before the first pair that that shared
any random currency would be returned, perhaps creating an absurd result.
This function complements gnc_time64_get_day_begin/end. There was
time64CanonicalDayTime but this returned noon of the given day, where we
want 10:59am in most cases. I haven't changed time64CanonicalDayTime
directly as that may break assumptions in other parts of the code.
Instead I have created a new function that can be gradually introduced.
Use a variant of xaccParseAmount that allows to ignore the locale's positive_sign character
or the + sign if locale doesn't define a positive_sign character.
In a future redesign it would probably be better to replace use
of xaccParseAmount with some variant of the gnc-expression-parser
but that would require more that a few tweaks to get right.
John Ralls
Christian Stimming
Alex Aycinena
Thomas Klausner
Christopher D. Carson
Christopher Lam
Geert Janssens
Robert Fewell
YOSHINO Yoshihito
Christoph Holtermann