Re: [GNC-dev] [Bug 113772] Add categories for more reporting flexibility
I did get VSCode to work as a development environment with developing on windows. I hadn't worked out all the kinks out of it, but it was showing great promise. I could build pretty well on it and then run gdb under it to do debugging. There is a bit of info I added to the wiki for that component. https://wiki.gnucash.org/wiki/Building_on_Windows Thanks, Matt On Thursday, May 14, 2020, 09:19:31 AM CDT, Geert Janssens wrote: Op donderdag 14 mei 2020 13:58:37 CEST schreef flywire: > Geert, thanks for that I appreciate it. > > I have looked through the docs. Does anyone know what the chances are of > getting a Win10 environment up under Visual Studio are? I don't think anyone has tried before so I have no idea. IIRC Visual Studio does have support for cmake and clang so you may be able to tweak the current build system enough to pull it off. On the other hand the current build system is highly dependent on Mingw64. I have no idea whether you can make that Visual Studio cooperate with that environment. If you manage to do so, by all means document how. I'm sure others would be interested. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] gnucash maint: Restrict gnucash.pot comment collection to ones beginning with Translators.
John, It looks like the new comment for translators you added in gnucash/import-export/log-replay/gnc-log-replay.c is misspelled, so it might not have the effect you are looking for. Thanks,Matt Sent from Yahoo Mail on Android On Sat, Jan 4, 2020 at 6:00 PM, John Ralls wrote: Updated via https://github.com/Gnucash/gnucash/commit/df92200c (commit) from https://github.com/Gnucash/gnucash/commit/c9998a8a (commit) commit df92200c8ebb45ab03e363aa3892a3f5d12ed475 Author: John Ralls Date: Tue Dec 31 08:40:46 2019 -0800 Restrict gnucash.pot comment collection to ones beginning with Translators. On recommendation of the Translation Project's Benno Schulenberg. Required re-annotating some comments. Also removed several comments about leaving a line break to prevent inserting it into gnucash.pot. That didn't actually work: they were inserted anyway. Summary of changes: gnucash/gnome-search/dialog-search.c | 1 - gnucash/gnome/gnc-plugin-page-register.c | 2 +- gnucash/gnome/gnucash.desktop.in.in | 2 +- gnucash/import-export/import-main-matcher.c | 3 +-- gnucash/import-export/log-replay/gnc-log-replay.c | 7 +++--- gnucash/import-export/ofx/gnc-ofx-import.c | 16 +++--- libgnucash/engine/Recurrence.c | 26 +++ po/gnucash-pot.cmake | 2 +- 8 files changed, 27 insertions(+), 32 deletions(-) ___ gnucash-patches mailing list gnucash-patc...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-patches ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Bug 330930
Thanks Geert for the response and insightful help. With your response, I will see what I can do about maybe fixing some of the simpler aspects of this dialog first as it seems to be pretty straight forward. I'll stay away from the more radical discussion of removing the option entirely for now until I have a better understanding of how difficult it might be to extend it first. Thanks for the help from all the developers as I try to take on a new hobby. Matt On Thursday, November 28, 2019, 2:51:10 AM CST, Geert Janssens wrote: Hi Matthew, Thanks for looking into this. The bug has been around for too long already... Here's my view on it: In theory we could indeed use a different widget for cases where we are asking for a simple number. The big benefit of the GNCAmountEdit widget on the other hand is that it allows the user to do in-place calculations. Like in the loan calculator example I could enter the number of payment periods as 7*12 rather than 84 when I know the loan will be for 7 years. Or I could enter the outstanding periods as (7*12 - 3*12+9), not a calculation I could quickly do in my head. So the GNCAmountEdit offers the convenience of not needing to get an external calculator and I think that has value. The real issue is - as you have discovered - the decimal point adjustment happens unconditionally where it should be more tightly controlled. Personally I think users would expect it to be applied to currency amounts only. So with auto-decimal point set to two and you enter 1000, you really mean $10.00 For integer values like number of payment periods this clearly doesn't make sense. This is also what the implementation of xaccParseAmount suggests: it will only apply auto decimal point corrections when the string to be parsed is marked as a monetary type. This function is called by the expression parser to evaluate the amount, but the expression parser doesn't differentiate and will always assume monetary values. So of the two suggestions you make I think extending GNCAmountEntry and the expression parser to take the amount type into account is the best. However a more radical approach may be to first evaluate whether we want to keep the auto decimal point functionality at all. So before you spend the effort it may be worthwhile to check with our user base who is really using this function and how much of a loss it would be if we simply removed it. Personally I don't benefit from this feature. It requires more typing and mental overhead in most of my data entries as I have plenty of values that are integer. Others may have different experiences. As a side note while testing I found several minor usability bugs with this: in many cases I can enter values or calculations, but they won't be evaluated until I leave the window. For example the loan calculator. I can enter a value like 10 in the amount field. When leaving the field I'd expect it to change to 1000.00 when auto decimal point is set to 2. It doesn't change however until after I click on the calculate button. That's pretty confusing. The same goes for the period field in the loan assistant. Only when switching to the next page and back, the field will be interpreted. Just to say there's plenty of room for improvement here. Regards, Geert Op zondag 24 november 2019 20:45:55 CET schreef Matthew Forbis via gnucash- devel: > Hi developers, > > As a foray into fixing bugs, this one looked simple to tackle. Here is the > link for easy access: https://bugs.gnucash.org/show_bug.cgi?id=330930 > > As a summary, when having auto decimal point enabled, certain fields are > treated as still having the auto decimal point enabled, such as number of > payment periods on the loan assistant. As I looked into this, these > dialogs and a few others use a GNCAmountEntry which goes through the > expression parser and there is no way to turn off the auto decimal point > when setting up the form, so anytime there is a GNCAmountEntry, it forces > decimal places into the number. I guess I see a few possible ways to go > about fixing it, but I'm not sure which would be considered correct. 1) > Pass parameters back up so you can have the GNCAmountEntry tell the > expression parser to not do auto decimal point, or 2) Change it to a > different type of entry field (such as GTKEntry) that would not parse > expressions, but would also not enter in decimal points, or 3) I missed > some option somewhere to tell a GNCAmountEntry to ignore the decimal > points, but I certianly can't figure it out. > > Is there a preference from the core devs as to which would be considered the > "correct" way. I also see when researching this, it probably also applies > to other places too that use GNCAmountEntry. For instance, the tax table > editor has a Percent entry for rat
[GNC-dev] Bug 330930
Hi developers, As a foray into fixing bugs, this one looked simple to tackle. Here is the link for easy access: https://bugs.gnucash.org/show_bug.cgi?id=330930 As a summary, when having auto decimal point enabled, certain fields are treated as still having the auto decimal point enabled, such as number of payment periods on the loan assistant. As I looked into this, these dialogs and a few others use a GNCAmountEntry which goes through the expression parser and there is no way to turn off the auto decimal point when setting up the form, so anytime there is a GNCAmountEntry, it forces decimal places into the number. I guess I see a few possible ways to go about fixing it, but I'm not sure which would be considered correct. 1) Pass parameters back up so you can have the GNCAmountEntry tell the expression parser to not do auto decimal point, or 2) Change it to a different type of entry field (such as GTKEntry) that would not parse expressions, but would also not enter in decimal points, or 3) I missed some option somewhere to tell a GNCAmountEntry to ignore the decimal points, but I certianly can't figure it out. Is there a preference from the core devs as to which would be considered the "correct" way. I also see when researching this, it probably also applies to other places too that use GNCAmountEntry. For instance, the tax table editor has a Percent entry for rate that I wouldn't think makes sense to necessarily add auto decimal places when you are already entering in as a percent and not a decimal. If someone can provide direction, I'll make an attempt at fix and submit a pull request for review. Thanks, Matt ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Windows Build problem
I might have fixed it myself. Does the following change make sense? CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 0654dfb5a..b054f9cc2 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -217,9 +217,9 @@ if (WITH_GNUCASH) pkg_check_modules (WEBKIT REQUIRED IMPORTED_TARGET webkitgtk-3.0) else() pkg_check_modules (WEBKIT REQUIRED webkitgtk-3.0) + _pkg_create_imp_target(WEBKIT) endif() set(WEBKIT1 1 CACHE INTERNAL "WebKitGtk") - _pkg_create_imp_target(WEBKIT) else (WIN32 OR APPLE) If (NOT CMAKE_VERSION VERSION_LESS 3.6) pkg_check_modules (WEBKIT IMPORTED_TARGET webkit2gtk-4.0) Thanks, Matt On Friday, September 13, 2019, 12:26:22 PM CDT, Matthew Forbis via gnucash-devel wrote: Hi, I'm attempting to build on windows to try to still solve the report bug I'm interested in and it seems that the patch below might have broken the windows build (or I don't know what I'm doing is also a possibilty). With the commit John pushed yesterday, I get the following error message when cmake is running: CMake Error at CMakeLists.txt:222 (_pkg_create_imp_target): _pkg_create_imp_target Function invoked with incorrect arguments for function named: _pkg_create_imp_target Can anyone help? Thanks,Matt On Thursday, September 12, 2019, 11:22:42 PM CDT, John Ralls wrote: Updated via https://github.com/Gnucash/gnucash/commit/41c58ec0 (commit) via https://github.com/Gnucash/gnucash/commit/c23f3f05 (commit) from https://github.com/Gnucash/gnucash/commit/70eb7172 (commit) commit 41c58ec00ab2276ca9b326570d07689fc47bc7e9 Author: John Ralls Date: Thu Sep 12 14:45:23 2019 -0700 Convert Gtk3 and Webkit to imported targets. This causes CMake to include their headers with -isystem instead of -I, so the compiler doesn't generate warnings on them. ArchLinux was failing to build because of such warnings. Includes a function from cmake 3.6 to allow this to work on systems like Ubuntu 14.04 that still provide only cmake 3.5. commit c23f3f05e311d81ce0fbb7bbc6b850e5acd5776d Author: John Ralls Date: Tue Sep 10 16:33:33 2019 -0700 Fix deprecated G_TYPE_INSTANCE_GET_PRIVATE and G_INLINE_FUNC with the function/declaration that they substituted. Note that this doesn't use the recommended new GObject creation macros because the class names in libgnucash/engine don't follow the gnome naming convention. Summary of changes: CMakeLists.txt | 61 ++ common/cmake_modules/GncPkgConfig.cmake | 52 ++ gnucash/CMakeLists.txt | 6 +-- gnucash/gnome-search/CMakeLists.txt | 2 +- gnucash/gnome-search/gnc-general-search.c | 2 +- gnucash/gnome-search/search-account.c | 2 +- gnucash/gnome-search/search-boolean.c | 2 +- gnucash/gnome-search/search-core-type.c | 2 +- gnucash/gnome-search/search-date.c | 2 +- gnucash/gnome-search/search-double.c | 2 +- gnucash/gnome-search/search-int64.c | 2 +- gnucash/gnome-search/search-numeric.c | 2 +- gnucash/gnome-search/search-reconciled.c | 2 +- gnucash/gnome-search/search-string.c | 2 +- gnucash/gnome-utils/CMakeLists.txt | 4 +- gnucash/gnome-utils/gnc-combott.c | 3 +- gnucash/gnome-utils/gnc-currency-edit.c | 2 +- gnucash/gnome-utils/gnc-date-format.c | 2 +- gnucash/gnome-utils/gnc-embedded-window.c | 2 +- gnucash/gnome-utils/gnc-main-window.c | 2 +- gnucash/gnome-utils/gnc-period-select.c | 2 +- gnucash/gnome-utils/gnc-plugin-file-history.c | 2 +- gnucash/gnome-utils/gnc-plugin-manager.c | 2 +- gnucash/gnome-utils/gnc-plugin-menu-additions.c | 2 +- gnucash/gnome-utils/gnc-plugin-page.c | 2 +- gnucash/gnome-utils/gnc-plugin.c | 2 +- gnucash/gnome-utils/gnc-query-view.c | 2 +- gnucash/gnome-utils/gnc-tree-model-account-types.c | 3 +- gnucash/gnome-utils/gnc-tree-model-account.c | 2 +- gnucash/gnome-utils/gnc-tree-model-commodity.c | 2 +- gnucash/gnome-utils/gnc-tree-model-owner.c | 2 +- gnucash/gnome-utils/gnc-tree-model-price.c | 2 +- gnucash/gnome-utils/gnc-tree-model-selection.c | 2 +- gnucash/gnome-utils/gnc-tree-model-split-reg.c | 2 +- gnucash/gnome-utils/gnc-tree-model.c | 2 +- gnucash/gnome-utils/gnc-tree-view-account.c | 2 +- gnucash/gnome-utils/gnc-tree-view-commodity.c | 2 +- gnucash/gnome-utils/gnc-tree-view-owner.c | 2 +- gnucash/gnome-utils/gnc-tree-view-price.c | 2 +- gnucash/gnome-utils/gnc-tree-view-split-reg.c | 2 +- gnucash/gn
[GNC-dev] Windows Build problem
Hi, I'm attempting to build on windows to try to still solve the report bug I'm interested in and it seems that the patch below might have broken the windows build (or I don't know what I'm doing is also a possibilty). With the commit John pushed yesterday, I get the following error message when cmake is running: CMake Error at CMakeLists.txt:222 (_pkg_create_imp_target): _pkg_create_imp_target Function invoked with incorrect arguments for function named: _pkg_create_imp_target Can anyone help? Thanks,Matt On Thursday, September 12, 2019, 11:22:42 PM CDT, John Ralls wrote: Updated via https://github.com/Gnucash/gnucash/commit/41c58ec0 (commit) via https://github.com/Gnucash/gnucash/commit/c23f3f05 (commit) from https://github.com/Gnucash/gnucash/commit/70eb7172 (commit) commit 41c58ec00ab2276ca9b326570d07689fc47bc7e9 Author: John Ralls Date: Thu Sep 12 14:45:23 2019 -0700 Convert Gtk3 and Webkit to imported targets. This causes CMake to include their headers with -isystem instead of -I, so the compiler doesn't generate warnings on them. ArchLinux was failing to build because of such warnings. Includes a function from cmake 3.6 to allow this to work on systems like Ubuntu 14.04 that still provide only cmake 3.5. commit c23f3f05e311d81ce0fbb7bbc6b850e5acd5776d Author: John Ralls Date: Tue Sep 10 16:33:33 2019 -0700 Fix deprecated G_TYPE_INSTANCE_GET_PRIVATE and G_INLINE_FUNC with the function/declaration that they substituted. Note that this doesn't use the recommended new GObject creation macros because the class names in libgnucash/engine don't follow the gnome naming convention. Summary of changes: CMakeLists.txt | 61 ++ common/cmake_modules/GncPkgConfig.cmake | 52 ++ gnucash/CMakeLists.txt | 6 +-- gnucash/gnome-search/CMakeLists.txt | 2 +- gnucash/gnome-search/gnc-general-search.c | 2 +- gnucash/gnome-search/search-account.c | 2 +- gnucash/gnome-search/search-boolean.c | 2 +- gnucash/gnome-search/search-core-type.c | 2 +- gnucash/gnome-search/search-date.c | 2 +- gnucash/gnome-search/search-double.c | 2 +- gnucash/gnome-search/search-int64.c | 2 +- gnucash/gnome-search/search-numeric.c | 2 +- gnucash/gnome-search/search-reconciled.c | 2 +- gnucash/gnome-search/search-string.c | 2 +- gnucash/gnome-utils/CMakeLists.txt | 4 +- gnucash/gnome-utils/gnc-combott.c | 3 +- gnucash/gnome-utils/gnc-currency-edit.c | 2 +- gnucash/gnome-utils/gnc-date-format.c | 2 +- gnucash/gnome-utils/gnc-embedded-window.c | 2 +- gnucash/gnome-utils/gnc-main-window.c | 2 +- gnucash/gnome-utils/gnc-period-select.c | 2 +- gnucash/gnome-utils/gnc-plugin-file-history.c | 2 +- gnucash/gnome-utils/gnc-plugin-manager.c | 2 +- gnucash/gnome-utils/gnc-plugin-menu-additions.c | 2 +- gnucash/gnome-utils/gnc-plugin-page.c | 2 +- gnucash/gnome-utils/gnc-plugin.c | 2 +- gnucash/gnome-utils/gnc-query-view.c | 2 +- gnucash/gnome-utils/gnc-tree-model-account-types.c | 3 +- gnucash/gnome-utils/gnc-tree-model-account.c | 2 +- gnucash/gnome-utils/gnc-tree-model-commodity.c | 2 +- gnucash/gnome-utils/gnc-tree-model-owner.c | 2 +- gnucash/gnome-utils/gnc-tree-model-price.c | 2 +- gnucash/gnome-utils/gnc-tree-model-selection.c | 2 +- gnucash/gnome-utils/gnc-tree-model-split-reg.c | 2 +- gnucash/gnome-utils/gnc-tree-model.c | 2 +- gnucash/gnome-utils/gnc-tree-view-account.c | 2 +- gnucash/gnome-utils/gnc-tree-view-commodity.c | 2 +- gnucash/gnome-utils/gnc-tree-view-owner.c | 2 +- gnucash/gnome-utils/gnc-tree-view-price.c | 2 +- gnucash/gnome-utils/gnc-tree-view-split-reg.c | 2 +- gnucash/gnome-utils/gnc-tree-view-sx-list.c | 2 +- gnucash/gnome-utils/gnc-tree-view.c | 2 +- gnucash/gnome-utils/search-param.c | 6 +-- gnucash/gnome-utils/test/CMakeLists.txt | 2 +- gnucash/gnome/CMakeLists.txt | 2 +- gnucash/gnome/gnc-budget-view.c | 2 +- gnucash/gnome/gnc-plugin-account-tree.c | 2 +- gnucash/gnome/gnc-plugin-basic-commands.c | 2 +- gnucash/gnome/gnc-plugin-budget.c | 2 +- gnucash/gnome/gnc-plugin-business.c | 2 +- gnucash/gnome/gnc-plugin-page-account-tree.c | 2 +- gnucash/gnome/gnc-plugin-page-budget.c | 2 +- gnucash/gnome/gnc-plugin-page-invoice.c | 2 +- gnucash/gnome/gnc-plugin-page-owner-tree.c | 2 +- gnucas
Re: [GNC-dev] Building on Windows
I was running gnucash directly from the inst directory and not creating an installer first. This explanation makes sense. Thanks,Matt On Saturday, August 24, 2019, 11:22:48 AM CDT, John Ralls wrote: > On Aug 23, 2019, at 11:28 PM, Geert Janssens > wrote: > > Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via gnucash- > devel: >> I have finally had time to sit down and try again. When libxml development >> was installed via pacman, it installed icu64 in addition to the icu61 that >> was already installed by the gnucash script. I was able to remove icu64 >> and clear out the entire build and inst directories and try again. It >> built without errors at that point and then the first time I ran, it >> crashed. I had to do a glib-compile-schemas in order for it to run at that >> point. (I'm just documenting manual interactions in case the scripts >> should be updated some for others). >> >> Thanks all for your help so far. Now onto trying to debug the chart hang >> problem. >> > Thanks for the feedback. > > How exactly did you run gnucash ? > > I think the whole windows build system is set up to create a Windows > installer > for the gnucash package and run gnucash after this installer has run. > > On the other hand, if simply running the glib-compile-schemas on the end > result of the build script helps you run it without invoking the Windows > installer, that's a worthwile bonus. > > I *thought* we did run this while building, but a quick scan of the build > scripts suggest it's only run while bundling gnucash. I wonder why that is. > Perhaps John remembers. Because everything else that uses GSettings is built by MinGW, because there's no need for GSettings during the build process and glib-compile-schemas is comprehensive so running it once at the end does the job. IIRC we disabled compiling the schemas at build time because it set up the paths for the build directory and so the compiled schemas failed after the install step. As for the build system set up, build_package.ps1 does indeed build a setup.exe for distribution and even uploads it to the distribution server if provided with an upload URI. For other purposes the build system does require a bit of manual intervention. That's equally true on Unix including MacOS. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
I have finally had time to sit down and try again. When libxml development was installed via pacman, it installed icu64 in addition to the icu61 that was already installed by the gnucash script. I was able to remove icu64 and clear out the entire build and inst directories and try again. It built without errors at that point and then the first time I ran, it crashed. I had to do a glib-compile-schemas in order for it to run at that point. (I'm just documenting manual interactions in case the scripts should be updated some for others). Thanks all for your help so far. Now onto trying to debug the chart hang problem. Thanks, Matt On Friday, August 16, 2019, 7:53:09 AM CDT, Matthew Forbis wrote: Yes I have that commit on my system and had a clean build directory for gnucash prior to starting the compile. Thanks, Matt On Thursday, August 15, 2019, 10:21:50 PM CDT, John Ralls wrote: I had a similar build failure on MacOS a few hours ago and pushed https://github.com/Gnucash/gnucash/commit/24d4576617995980c147bb49cacafe6f16978573 to fix it. Did your build have that commit? Regards, John Ralls > On Aug 15, 2019, at 7:21 PM, Matthew Forbis via gnucash-devel > wrote: > > Hi responding to myself: > > First, forgot plain text in the first email, so I fixed the formatting in the > original below to make it easier to read. > Second, my system has both icu 61 which is the one explicitly required for > webkit as well as has icu 64 which was installed as part of the libxml2 > library. When I do a pkg-config, it finds the version 61 one. I suspect > this might be related to my problem, but I'm not experienced enough as a > programmer to figure out how to solve it. > > Thanks, > Matt > > > > On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via > gnucash-devel wrote: > > > Hi All, > I have recently worked on building GNUCash on windows to try to debug a > problem I've been having with my reports. I found a few things that look > like the script might need to be updated for (or I had something wrong in my > procedure). > > 1. I had to install some packages through pacman manually: > openssl-devel - this seemed to keep python's hashlib from working correctly > and not able to go very in the build process (I didn't start keeping notes > right at the beginning). > mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I > had to install it to continue. (I think I had to use this format as well to > install) > glib2-devel - Required for gnucash. > libxml2-devel - Required for gnucash > libxslt-devel - Required for gnucash > > 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup > powershell script. This failed due to a missing angleproject package. This > was not available in pacman anymore, so I ended up modifying > setup-mingw64.ps1 to add this to the install and re-ran it and it appears to > have installed correctly. > > But, that brings me to now where I'm stuck. I am getting the following error > when building: > [ 42%] Linking CXX shared library > ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function > `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: > undefined reference to > `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: > undefined reference to > `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: > undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) > const'collect2.exe: error: ld returned 1 exit status > > Any hints as to how to debug this one? > > Thanks, > Matt > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
Yes I have that commit on my system and had a clean build directory for gnucash prior to starting the compile. Thanks,Matt On Thursday, August 15, 2019, 10:21:50 PM CDT, John Ralls wrote: I had a similar build failure on MacOS a few hours ago and pushed https://github.com/Gnucash/gnucash/commit/24d4576617995980c147bb49cacafe6f16978573 to fix it. Did your build have that commit? Regards, John Ralls > On Aug 15, 2019, at 7:21 PM, Matthew Forbis via gnucash-devel > wrote: > > Hi responding to myself: > > First, forgot plain text in the first email, so I fixed the formatting in the > original below to make it easier to read. > Second, my system has both icu 61 which is the one explicitly required for > webkit as well as has icu 64 which was installed as part of the libxml2 > library. When I do a pkg-config, it finds the version 61 one. I suspect > this might be related to my problem, but I'm not experienced enough as a > programmer to figure out how to solve it. > > Thanks, > Matt > > > > On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via > gnucash-devel wrote: > > > Hi All, > I have recently worked on building GNUCash on windows to try to debug a > problem I've been having with my reports. I found a few things that look > like the script might need to be updated for (or I had something wrong in my > procedure). > > 1. I had to install some packages through pacman manually: > openssl-devel - this seemed to keep python's hashlib from working correctly > and not able to go very in the build process (I didn't start keeping notes > right at the beginning). > mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I > had to install it to continue. (I think I had to use this format as well to > install) > glib2-devel - Required for gnucash. > libxml2-devel - Required for gnucash > libxslt-devel - Required for gnucash > > 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup > powershell script. This failed due to a missing angleproject package. This > was not available in pacman anymore, so I ended up modifying > setup-mingw64.ps1 to add this to the install and re-ran it and it appears to > have installed correctly. > > But, that brings me to now where I'm stuck. I am getting the following error > when building: > [ 42%] Linking CXX shared library > ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function > `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: > undefined reference to > `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: > undefined reference to > `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: > undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) > const'collect2.exe: error: ld returned 1 exit status > > Any hints as to how to debug this one? > > Thanks, > Matt > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
Hi responding to myself: First, forgot plain text in the first email, so I fixed the formatting in the original below to make it easier to read. Second, my system has both icu 61 which is the one explicitly required for webkit as well as has icu 64 which was installed as part of the libxml2 library. When I do a pkg-config, it finds the version 61 one. I suspect this might be related to my problem, but I'm not experienced enough as a programmer to figure out how to solve it. Thanks, Matt On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via gnucash-devel wrote: Hi All, I have recently worked on building GNUCash on windows to try to debug a problem I've been having with my reports. I found a few things that look like the script might need to be updated for (or I had something wrong in my procedure). 1. I had to install some packages through pacman manually: openssl-devel - this seemed to keep python's hashlib from working correctly and not able to go very in the build process (I didn't start keeping notes right at the beginning). mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I had to install it to continue. (I think I had to use this format as well to install) glib2-devel - Required for gnucash. libxml2-devel - Required for gnucash libxslt-devel - Required for gnucash 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup powershell script. This failed due to a missing angleproject package. This was not available in pacman anymore, so I ended up modifying setup-mingw64.ps1 to add this to the install and re-ran it and it appears to have installed correctly. But, that brings me to now where I'm stuck. I am getting the following error when building: [ 42%] Linking CXX shared library ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: undefined reference to `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: undefined reference to `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) const'collect2.exe: error: ld returned 1 exit status Any hints as to how to debug this one? Thanks, Matt ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Building on Windows
Hi All, I have recently worked on building GNUCash on windows to try to debug a problem I've been having with my reports. I found a few things that look like the script might need to be updated for (or I had something wrong in my procedure). 1. I had to install some packages through pacman manually:openssl-devel - this seemed to keep python's hashlib from working correctly and not able to go very in the build process (I didn't start keeping notes right at the beginning).mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I had to install it to continue. (I think I had to use this format as well to install)glib2-devel - Required for gnucash.libxml2-devel - Required for gnucashlibxslt-devel - Required for gnucash 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup powershell script. This failed due to a missing angleproject package. This was not available in pacman anymore, so I ended up modifying setup-mingw64.ps1 to add this to the install and re-ran it and it appears to have installed correctly. But, that brings me to now where I'm stuck. I am getting the following error when building:[ 42%] Linking CXX shared library ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: undefined reference to `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: undefined reference to `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) const'collect2.exe: error: ld returned 1 exit status Any hints as to how to debug this one? Thanks, Matt ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Bugzilla cleanup
Hi All, I saw a note on the irc channel the other day about trying to do some triage on the open bugs and clean them up. Before I start testing and changing statuses without anyone knowing who I am, I figured I would send an email first. I have been a user of gnucash for about 5 or 6 years now and been attempting to learn some of the code base by reading every commit as they are applied. I will admit most of my programming background is in vba and vb.net, so the c/c++ is understandable to me, but I get lost when I see the scheme code. I hope to get more involved as time moves on maybe trying to fix some of the simpler bugs, but for now, I feel like I can test some of them and do some general cleanup without too much objection. To make sure I'm on the right track, one of the first bugs I came across was https://bugs.gnucash.org/show_bug.cgi?id=797151. If I look at this, I believe it should be marked as applying to Gnucash, not bugzilla. Given the comment has the original reporter indicated that he has solved the problem, I might also be tempted to change it to Resolved > Incomplete or Resolved > Notabug, but I could see where there is still a bug but I don't know if there is enough interest to keep it open for that. My goal is to just help the project out, so if there is any other guidelines someone wants me to follow, I'd be quite grateful. Thanks,Matt ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Segfault when loading file on master
I have compiled master and came across a segfault when loading my normal file that works fine on 2.6.15. It happens during the loading of the file. It looks like possibly the code no longer handles a / in certain places in the file. I traced it to this section in my gnucash file (I cut it down to just show the tree in questions, out I can send more if needed). If I removed the slot in section, the file loads just find. The stack trace from the crash is at the end of the email. If this makes more sense to create a bug report out of, please let me know and I will do that. Thanks, Matt Capital One cb2525c09fbe0f791e01b4caa0fff869 CREDIT ISO4217 USD 100 color Not Set import-map-bayes / Expenses:Vacation 2 Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. 0x712f32ab in std::__cxx11::basic_string, std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator > const&) () from /lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) st Ambiguous command "st": stack, start, status, step, stepi, stepping, stop, strace. (gdb) bt #0 0x712f32ab in std::__cxx11::basic_string, std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator > const&) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x7670380c in KvpFrameImpl::set (this=0x58236820, path=std::vector of length 0, capacity 0, value=0x57be9190) at kvp_frame.cpp:128 #2 0x76703579 in KvpFrameImpl::set (this=0x58236820, key=0x57be90d0 "/", value=0x57be9190) at kvp_frame.cpp:91 #3 0x721200ba in dom_tree_to_kvp_frame_given (node=0x57e467a0, frame=0x58236820) at sixtp-dom-parsers.cpp:443 #4 0x72120161 in dom_tree_to_kvp_frame (node=0x57e467a0) at sixtp-dom-parsers.cpp:465 #5 0x7211fe67 in dom_tree_to_frame_kvp_value (node=0x57e467a0) at sixtp-dom-parsers.cpp:339 #6 0x7211ff43 in dom_tree_to_kvp_value (node=0x57e467a0) at sixtp-dom-parsers.cpp:391 #7 0x72120083 in dom_tree_to_kvp_frame_given (node=0x57f822c0, frame=0x57f1f840) at sixtp-dom-parsers.cpp:429 #8 0x721201cd in dom_tree_create_instance_slots (node=0x57f822c0, inst=0x58012900) at sixtp-dom-parsers.cpp:476 #9 0x720f594a in account_slots_handler (node=0x57f822c0, act_pdata=0x7fffb020) at gnc-account-xml-v2.cpp:365 #10 0x72120ca1 in gnc_xml_set_data (tag=0x57f85c90 "act:slots", node=0x57f822c0, item=0x7fffb020, handlers=0x72342de0 ) at sixtp-dom-parsers.cpp:858 #11 0x72120d97 in dom_tree_generic_parse (node=0x57f83cb0, handlers=0x72342d20 , data=0x7fffb020) at sixtp-dom-parsers.cpp:889 #12 0x720f5d2c in dom_tree_to_account (node=0x57f83cb0, book=0x57c61880) at gnc-account-xml-v2.cpp:540 #13 0x720f5c23 in gnc_account_end_handler ( data_for_children=0x57f83cb0, data_from_children=0x0, sibling_data=0x57c8fc30, parent_data=0x0, global_data=0x7fffb420, result=0x57c95fc0, tag=0x57f9cf20 "gnc:account") at gnc-account-xml-v2.cpp:491 #14 0x72123b44 in sixtp_sax_end_handler (user_data=0x57c01c40, name=0x57c68e03 "gnc:account") at sixtp.cpp:539 #15 0x71d43df5 in ?? () from /lib/x86_64-linux-gnu/libxml2.so.2 #16 0x71d4ce3b in xmlParseElement () from /lib/x86_64-linux-gnu/libxml2.so.2 #17 0x71d4c0e2 in xmlParseContent () from /lib/x86_64-linux-gnu/libxml2.so.2 #18 0x71d4ca33 in xmlParseElement () from /lib/x86_64-linux-gnu/libxml2.so.2 ---Type to continue, or q to quit--- #19 0x71d4c0e2 in xmlParseContent () from /lib/x86_64-linux-gnu/libxml2.so.2 #20 0x71d4ca33 in xmlParseElement () from /lib/x86_64-linux-gnu/libxml2.so.2 #21 0x71d4d3bb in xmlParseDocument () from /lib/x86_64-linux-gnu/libxml2.so.2 #22 0x72124009 in sixtp_parse_file_common (sixtp=0x57bf5430, xml_context=0x57ce8a60, data_for_top_level=0x0, global_data=0x7fffb420, parse_result=0x7fffb438) at sixtp.cpp:717 #23 0x721241c3 in sixtp_parse_fd (sixtp=0x57bf5430, fd=0x57c01800, data_for_top_level=0x0, global_data=0x7fffb420, parse_result=0x7fffb438) at sixtp.cpp:793 #24 0x7210a820 in gnc_xml_parse_fd (top_parser=0x57bf5430, fd=0x57c01800, callback=0x72110dad , parsedata=0x57c0c320, bookdata=0x57c61880) at io-gncxml-gen.cpp:60 #25 0x721115d1 in qof_session_load_from_xml_file_v2_full (xml_be= 0x57c7e800, book=0x57c61880, push_handler=0x0, push_user_data=0x0, type=GNC_BOOK_XML2_FILE) at io-gncxml-v2.cpp:809 #26 0x72111840 in qof_session_load_from_xml_file_v2 ( xml_be=0x
Re: gnc-numeric
On a similiar but slightly unrelated note, on commit https://github.com/Gnucash/gnucash/commit/e322457e , under functioninline GncRational operator+(GncInt128 a, GncRational b), I think it possibly should be | - return b + GncRational(a, 1); | | + return GncRational(a, 1) + b; instead of | - return b + GncRational(a, 1); | | + return GncRational(a, 1) + a; Matt From: Robert Fewell <14ubo...@gmail.com> To: "gnucash-devel@gnucash.org" Sent: Tuesday, February 21, 2017 5:18 AM Subject: gnc-numeric Hi, Just built from master with all the new changes but had to change gnc-numeric.cpp line 86 from isnan(d) to std::isnan(d), gcc version 4.9.4 After change all built successfully. Bob ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Commit 10b006fdc1fe67c6caff7efca163406c89e78187
Hi,
I've been lurking on the list for a while and looking at all the code changes
to try to better understand c++ programming, but I saw this one that was merged
today and it didn't look right, but I might be missing something.
In src/backend/sql/gnc-transaction-sql.cpp, at line 964, I think a : is missing
in the date string between %M and %S. The line in question is:
auto datebuf = time.format_zulu ("%Y-%m-%d %H:%M%S");
If it is correct, could someone explain it to me why?
Thanks,Matt
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
