Re: gnucash c++
On Wednesday 06 August 2014 19:15:35 John Ralls wrote: On Aug 6, 2014, at 2:16 PM, Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote: I tried to follow the directions at http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't find a Bugzilla issue encapsulating the Great C++ Refactor. Should I create one so there is a place to put patches? I learned on IRC that it is generally a goal not to have C++ keywords in the Gnucash code base, and this patch is along those ends. I think I got all the C++11 keywords that would interfere with a C++11 compile. If this is an inappropriate patch to submit, please let me know. After my signature, you can find the patch prepared using `git format-patch` (as specified in http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed the advice of http://wiki.gnucash.org/wiki/Development_Process (All development should target the *master* branch.). Please let me know if anything looks amiss (the amount of context, using unified diff format, perhaps I should be attaching instead of in-line quotation, etc.). Thanks! In Christ, Hi Aaron, Thank you for your patch. I haven't tested it yet but IMO the intention is correct. As for bugzilla: you can create a new bugreport and attach your patch there. Attaching it to a mailing list message risks that it gets lost in the midst of the ongoing discussions. 'git format- patch' is perfectly fine as format. As for the All development should target the *master* branch, we should change this. That's advice from the svn era. In git bugfixes should target the *maint* branch. New features and enhancements should target *master*. I clarified http://wiki.gnucash.org/wiki/Development_Process#Developing_New_Featu res a bit and cleared out all of the old stuff about backports and audits. I'm not quite satisfied with it, so I'll let it percolate in my head for a day or two and have another go. If someone else has some thoughts, by all means dive in. I altered some more parts that still wrongly suggested all bugfix development should go on master. But I still welcome more improvements and clarifications. Let's not have a generic Convert GnuCash to C++ bug that will accumulate a zillion patches and a zillion comments. That will just become a headache. If you (Aaron) would rather attach the patch to a bug, make it Remove C++11/14 Keywordsor something, but I'm perfectly happy using Github pull requests for C++ if that's more convenient. I don't really see that patch as a bug-fix; it's not a problem with maint that it doesn't compile in C++. OTOH, *not* applying it to maint will make it harder to merge into master sooner than otherwise, so I'm not opposed to it either as long as it passes `make distcheck`. Fully agreed. It may be better to apply this one against maint in the hopes it will result in simple merges for a while longer. It has to pass make distcheck of course. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 734183
On Wed, 06 Aug 2014 18:01:52 +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 06 August 2014 16:00:21 Mike Evans wrote: HiGeert. n is set to 25 using gnc_exp_parser_parse (discount, n, NULL); just after it's set to gnc_numeric_zero (); Taking the zeroing line out doesn't change the behaviour though. Oh right. Probably this isn't working for me because my decimal separator is ,. Sorry for the false suggestion. Where discount is read from the file. When the invoice is opened after import the 25.00 is shown in the discount column but the price hasn't been discounted, the line total is still at original price. The gncEntryGetDocDiscountValue () function calls the gncEntry::gncEntryRecomputeValues() function which should set he discount to be applied. Yes, it does. As an aside This is a horribly backward way of doing things and source of various bugs. We should definitely fix this at some point. I fixed the import file for my locale and reran the debugger. The gncEntryRecomputeValues function effectively does nothing in this case because the entry has no Invoice tax table set. The recalculation only happens when there is either a bill or an invoice tax table. So that would explain why the discount is not substracted. Geert Ah found it by looking in the .gnucash xml file. The discount is saved as 25/1 and the price as 75/1. In gncEntryComputeValues() the denom is read from the currency, ie 100 so it divides 25 by the denom and gets the wrong answers which is effectively zero. Hence no discount. I need to run gnc_numeric_convert(...) to set the denom correctly. Thanks Geert, sometimes just asking the questions out loud is what's needed. :) Mike -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 734183
On Thursday 07 August 2014 15:27:32 Mike Evans wrote: Ah found it by looking in the .gnucash xml file. The discount is saved as 25/1 and the price as 75/1. In gncEntryComputeValues() the denom is read from the currency, ie 100 so it divides 25 by the denom and gets the wrong answers which is effectively zero. Hence no discount. I need to run gnc_numeric_convert(...) to set the denom correctly. Thanks Geert, sometimes just asking the questions out loud is what's needed. :) Mike Nice job :) And as usual still something totally different... Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
make-gnucash-potfiles
I have GREP_OPTIONS=--color=always -n --directories=skip, so when I run make distcheck, it fails. make-gnucash-potfiles is expecting grep to *not* put out line numbers nor colors. If the response to this is don't do that, then you can stop reading. However, if we're wanting this script to run reliably in the face of a customized environment, the following patch works: From 0a150b770f895df9420bd5133bc8ba3960580a28 Mon Sep 17 00:00:00 2001 From: lmat dartm...@gmail.com Date: Thu, 7 Aug 2014 13:35:17 -0400 Subject: [PATCH] make-gnucash-potfiles is now more reliable make-gnucash-potfiles relies on certain behaviour from grep. This patch helps ensure that grep behaves in the way we expect. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 35f4771..4a2e285 100644 --- a/Makefile.am +++ b/Makefile.am @@ -185,7 +185,7 @@ pot: Makefile po/POTFILES.in $(srcdir)/po/POTFILES.in: make-gnucash-potfiles .potfiles -if test -w $(srcdir)/po/POTFILES.in ; then ./make-gnucash-potfiles $(srcdir)/po/POTFILES.in ; fi +if test -w $(srcdir)/po/POTFILES.in ; then GREP_OPTIONS=-o --color=auto ./make-gnucash-potfiles $(srcdir)/po/POTFILES.in ; fi # Creation rules so that po/gnucash.pot can always be created for # make dist. -- 1.9.1 It's also possible to similarly patch make-gnucash-potfiles itself. If that's desired, I'll be happy to come up with a patch like that. In Christ, Aaron Laws ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: make-gnucash-potfiles
On Aug 7, 2014, at 10:37 AM, Aaron Laws dartm...@gmail.com wrote: I have GREP_OPTIONS=--color=always -n --directories=skip, so when I run make distcheck, it fails. make-gnucash-potfiles is expecting grep to *not* put out line numbers nor colors. If the response to this is don't do that, then you can stop reading. However, if we're wanting this script to run reliably in the face of a customized environment, the following patch works: From 0a150b770f895df9420bd5133bc8ba3960580a28 Mon Sep 17 00:00:00 2001 From: lmat dartm...@gmail.com Date: Thu, 7 Aug 2014 13:35:17 -0400 Subject: [PATCH] make-gnucash-potfiles is now more reliable make-gnucash-potfiles relies on certain behaviour from grep. This patch helps ensure that grep behaves in the way we expect. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 35f4771..4a2e285 100644 --- a/Makefile.am +++ b/Makefile.am @@ -185,7 +185,7 @@ pot: Makefile po/POTFILES.in $(srcdir)/po/POTFILES.in: make-gnucash-potfiles .potfiles -if test -w $(srcdir)/po/POTFILES.in ; then ./make-gnucash-potfiles $(srcdir)/po/POTFILES.in ; fi +if test -w $(srcdir)/po/POTFILES.in ; then GREP_OPTIONS=-o --color=auto ./make-gnucash-potfiles $(srcdir)/po/POTFILES.in ; fi # Creation rules so that po/gnucash.pot can always be created for # make dist. -- 1.9.1 It's also possible to similarly patch make-gnucash-potfiles itself. If that's desired, I'll be happy to come up with a patch like that. Please stop sending patches to the list. It seems silly to create a branch on your Github repo for something small like this, so use Bugzilla. You don’t even need to post anything here; all of the active devs get bug mail. Aside from that, what happens if instead of setting GREP_OPTIONS to “-o —color=auto you unset it entirely? I do think that it would be better to modify make-gnucash-potfiles.in directly to not use grep. Shelling out to run grep on a file from perl is pretty perverse. At the same time the script can be improved so that it doesn’t keep changing the order of files and so generating extraneous change sets. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
