Casting a char* to a struct containing a uint32_t is not universally safe
due to alignment constraints on reads on some platforms. Copy our possibly
unaligned source data into an aligned area of memory to avoid SIGBUS on
armhf.
Reported by vorlonofportland in PR#403. This commit the John's optimized
version of Vorlon's proposed fix.
- add -Wno-deprecated-declarations to CXX_FLAGS as well. This was
reported by vorlonofportland in PR#401 to become necessary for glib 2.58
as that has deprecated g_type_class_add_private which appears in our
c++ code.
- change -Wno-deprecated-register into -Wregister. The former appeared to
be a clang dialect and alias for the latter (see
https://github.com/Barro/compiler-warnings for an overview of clang
and gcc warnings). It was moved to global CXX_FLAGS as it can only be
added for g++.
The KVP value for the qof_book_get_num_days_autoreadonly was being
called many times so it makes sense to cache it in the book to avoid
the KVP lookup.
test_suite_gncInvoice sets up the test suite. It's not part of the test
runtime, so stack variables in it have gone out of scope by the time the
tests are actually run. Making invoiceData static makes it permanent so
it exists at runtime.
First, save isn't necessary if the book is dirty, so don't... but that
means that the book has to be marked dirty after a session swap. No more
laziness.
Second, regardless of the outcome of inner_main_add_price_quotes the
session must be destroyed to remove the lock.
A couple of cleanups in QofSessionImpl::save as well: Rewrote the
descriptive comment to reflect how it really works when the backend has
gotten disconnected and removed the superfluous qof_book_set_backend
with the backend that we'd *just gotten from the book*.
Change all instances of bugzilla.gnome.org to bugs.gnucash.org, reflecting
our migration to a self-hosted bug tracker.
Inform the Translation Project Coordinator at release that this affects
translatable strings and that all message catalogs have been updated.
I think this crash is triggered because the 'account' variable
defaults to the first available AR account. If there's no AR account
it becomes null, and querying null's default book leads to segfault.
I guess I can fix segfault too by fixing gnc_account_get_book.
Change some plain string literals to std::string constants, which helps
avoiding typos and also saves some string constructors/destructors
in the KVP lookup. Nevertheless the functions in Account.cpp do not
contribute that much to the overall UI speed, but whatever.
The function qof_book_use_split_action_for_num_field gets called quite a
lot in each register display refresh (due to sorting all splits from
Split.x's xaccSplitOrder function), but it always used to use a KVP
lookup, which is rather expensive compared to accessing a gboolean member
variable.
To get rid of this cost, I had to remove the KVP lookup in this
simple-looking function. The pattern is this: A gboolean cache variable is
introduced, along with an isvalid flag. The lookup makes the expensive
KVP lookup once, then caches the value. The GObject property mechanism
offers a callback for when the setter was called, which is used to mark
the cached value as invalid. A parallel setter method (here:
qof_book_set_option) also just marks the cache as invalid. This covers
all setters, and the getters will use the cached value except for their
first invocation.
The NUM_FIELD_SOURCE feature was introduced in 2012 by the very large
commit 7cdd7372 and apparently its costs never were a problem
until the KVP lookup became more costly due to the std::vector
construction and destruction.
Turns out that the on-the-fly conversion from const char* (the KVP_OPTION_PATH
constants) to std::string with their immediate deletion afterwards is
a quite costly operation. Avoiding this is surprisingly easy: Just keep
local std::string objects at hand, and they don't have to be created
and deleted anymore.
The more optimized solution might be to turn the std::vector<std::string>
into a std::vector<GQuark>, but this commit at least improves the picture for now.
First change is to ensure gncEntry rounding is consistent. Internally
calculated values in the entry are never rounded. Consumers of
gncEntry's calculated values can request them either rounded or not.
Next use a pragmatical approach for calculating values on invoices based on
the entry values: do the rounding such that we never
create an unbalanced transaction while posting
That means
- round each entry's net value before summing them in net total
- accumulate all tax totals on invoice level per tax account before rounding
and round before before summing them in a global tax total
Hopefully this will catch a few more rounding issues in this area.
A complete solution can only offered if we allow users to manually correct
tax entries. This requires changes to user interface and data format
so that's not going to happen in gnucash 3.x.
strptime/strftime supports various modifiers to their parameters.
'E' and 'O': alternate locale-specific formats
(used in default format for Persian, Oriya, Azerbaijani)
'-': padding
(used in default format for Czech)
GnuCash passes dates as integer y/m/d without using locale-specific
formats, so we need to strip out 'E' and 'O' from the format when
scanning dates or determining separators in gnc-date.
None of '-', 'E', or 'O' are supported by boost (and '-' causes
errors), so strip them out from formatters in gnc-datetime as well.
See https://bugzilla.gnome.org/show_bug.cgi?id=795247.
This will probably need more refinement because the multiplications
are still missing rounding methods, but the changes in this commit
will already allow guile code to correctly create entries.
This commit contains another round of cleanups in the
timespec to time64 conversion. There were a number of
false assumptions that time64 = 0 would be a bad date
in the xml parser. This commit corrects enough of them to
eliminate the bug. Further cleanup is probably advised but
can be done at a later stage.
Also Bug 791825 - Accounting Period dates off by 1.
The DST start/end dates were reversed *and* the DST offset had the wrong
sign in Windows, resulting in the effective timezone always being one to
the west off (i.e. PDT was -9 and PST was -8).
Bills and invoices that are posted and subsequently unposted again still store their
posted account internally as a convenience to the user (upon reposting the old
account will be offered by default) so it's not a reliable test for the posted state.
The posted transaction on the other hand is guaranteed to only exist when the invoice is
posted. This should fix a slew of small and perhaps larger side effects, such as
a posted bill still appearing as editable, critical warnings when creating new bills/invoices
and so on.
An odd corner case: BST apparently came off of DST at 23:00 26 Oct 2014,
so midnight that day was ambiguous about being DST or not; that causes
the local_date_time constructor to throw in spite of the tm.is_dst element
being 0 (meaning pick standard time).
Instead of just failing in that case, try constructing a local_date_time
three hours later then adjust it back three hours. If *that* doesn't work
then throw a std::invalid argument.
After much thrashing this turned out to be caused by a date string
with a 3-digit year and that caused an unexpected boost::bad_cast
exception from boost::posix_time::time_from_string().
To prevent that and anything like it, pre-parse the string with
regular expressions to classify them and split out the timezone
if there is one. If neither (perhaps eventually none) of the
regexes match throw std::invalid_argument. The C function will
catch this and return 0.
91f4b19 changed the test for gncInvoiceDateExists from date != 0
to date != INT64_MAX, which isn't backwards compatible, so test
for both. But the submitted file had a posted date of -1 so
gncInvoiceIsPosted returned true anyway. That's not consistent with
the logic in dialog-invoice.c, which checked gncInvoicePostedAcc != NULL,
a better test. The result was that the "Post" button lit up but
gncInvoicePost returned immediately, doing nothing, so change
gncInvoiceIsPosted to use gncInvoicePostedAcc instead.
There were several problems that broke the Imap Editor that have been
fixed due to kvp changes. The import-map-bayes entries were being added
to the tree view based on the number token entries squared. Retrieving
import-map entries resulted in an empty list and also deleting entries
from the tree view failed.
Found with -Wimplicit-fallthrough, but older versions of GCC don't support it. So it will take some effort to add it to the build config.
I think it did not result in a reproducible bug.
Turns out the stream facet parser is really slow. Since we have a
well-constrained universe of input formats we don't really need that
overhead. This got a 33% improvement in loading a large SQLite database.
This commit fixes business reports caused by 91f4b19039
whereby the posted-date for unposted invoice was changed
from 0 to MAXINT. Now we need to use (gncInvoiceIsPosted)
or (gncInvoiceDateExists) instead.
When building from git it will add targets to generate the swig files.
When building from tarball it will just point at the generated source
files from the tarball.
Several were only there because they used to be generated via autogen.sh
and hence had to be included because autogen.sh was not supposed to be run
in a tarball based build.
A few others aren't clear so I have left them in for now:
- gnucash.1 (man page)
- gnucash-design.info (because it's unclear what we want to do with that one)
These files should clearly be in the tarball:
- gnucash.pot -> for our translators
- ChangeLog -> can't be generated outside of a git repo
- gnc-vcs-info.h -> can't be generated outside of a git repo
- guile/python bindings -> to avoid a swig dependency when building from tarball
- the two dist_add_... macros now both take a list of file names
as argument so more files can be added at once to the dist tarball.
- dist_add_generated now creates the right target by itself. There's
no need to pass one any more
- make the swig generated *.py module files explicit output files
- change a couple of custom_targets into custom_commands. The only
reason they were defined as targets was to ensure they got built
before the dist tarball. This is now properly handled by the
dist_add_... macros.
- correctly handle dependency on swig-runtime.h (using OBJECT_DEPENDS
was not the way to do it according to that property's help page)
cmake with unix makefiles fails to resolve dist dependencies
added from COPY_FROM_BUILD if these dependencies aren't built yet.
This commit replaces the COPY_FROM_BUILD based logic with two new functions
'dist_add_configured' and 'dist_add_generated' to indicate which files should
be included in the dist tarball. The latter also adds a target level dependency
to the dist tarball custom command. Hence the former should
be used for files that get generated during a cmake run while the latter
should be used for files generated as the result of a 'make/ninja-build' run
(like files for which an add_custom_command rule exists).
Note: this commit also temporarily disables the dist target when building
from a tarball (and hence it won't be tested in distcheck either). This
will be handled in a future commit.
Conflicts:
- gnucash/gnome-utils/gnc-main-window.c
I have chosen to ignore the changes pulled in from maint. The same change will
be reimplemented in a followup commit.
- po/ru.po
Same here. The translation conflicted too much and there's a
translation update available for unstable I will pull in soon.
Resolved conflicts:
gnucash/gnome-search/dialog-search.c
gnucash/gnome-utils/gnc-splash.c
gnucash/import-export/aqb/gnc-plugin-aqbanking.c
gnucash/import-export/import-account-matcher.c
po/de.po
src/report/standard-reports/budget-barchart.scm
src/report/standard-reports/budget.scm
Note the de.po conflict was resolved by dropping all changes
and merging the file again with gnucash.pot (generated after
the merge but before committing).
GLib's scribbling of freed memory is enabled on Arch so attempting to
read the deleted members of inst and book crash instead of reaturning
invalid results. These weren't really useful tests anyway.
The first attempt to fix this, a17bc85a, doesn't work because the
boost::date_time constructor gets enough information in most cases to
generate a date, just not the one we expect. This change looks for '-' in
the fourth position and if it's there assumes iso-extended format, otherwise
it assumes delimiter-less ISO without the 'T', i.e. %Y%m%d%H%M%S.
Set a feature to prevent versions older that 2.6.20 from loading a
database from which they cannot read the dates. Ideally we would do this
only if the database is written to, but the current persistence design
includes committing back to the database during the load so the net
effect is that the flag would be set anyway.
This allows direct conversion between Scheme numbers and gnc_numeric
without the performance or accuracy penalties arising from using doubles
as an intermediary.
This commit introduces a new feature flag:
GNC_FEATURE_GUID_FLAT_BAYESIAN. It signifies that the bayes import map
data are stored flat and by guid. Any time bayes import map data are
accessed, they are converted if necessary.
