Re: Investment Sale Commission question
> On Dec 2, 2016, at 10:26 PM, Chris Good wrote: > > Hi, > > > > I'd like to update the guide investment selling shares section with some > better information about how to handle commission. > > See attachment 1 for the section I wish to update. > > > > The guide example says: > > > > and finally PROFIT is $1525 (GROSS_SALE-TOTALBUY-COMMISSION). > > > > but shows profit and capital gain as $1600. > > If you do the sale transaction as per the example, the Trial Balance is OK, > but the capital gain is overstated. > > > > I've tried to alter the splits to get capital gain of $1525 but either I end > up with an Imbalance split of $75 (commission value) or the Trial Balance is > out by $75 (Dr > Cr). > > Please see attachment 2 for the balanced transaction as I think it should > be, but which causes the Trial Balance problem. > > > > Could some-one please advise how to arrive at a capital gain of $1525 and a > balancing Trial Balance or explain why this is not possible? > Chris, You *either* expense the commission *or* reduce the capital gain, depending on your tax laws. Allowing both would be a very generous tax regime indeed, but regardless also produces an imbalance in the book because you're counting the commission twice. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: > > On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > >> On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> wrote: > >> > >> Just built master from > >> https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf10fee > >> c364c8127 and I still do not see the errors Geert is having. Added a > >> Customer and a Vendor and still only have one of each. > > > > Bob, > > > > Yes, I'm also not yet able to reproduce the duplicate vendor issue. Geert > > mentioned on IRC that he's using Fedora-25 so I'm building a new VM with > > that to test. > I can't reproduce it on Fedora-25 either. > > The save problems and crashes on master I *can* reproduce, so I'm working on > that. > > Regards, > John Ralls John, I can confirm your commits fix the save problems and crashes. Thanks. As I appear to be the only one experiencing the other part of duplicate objects, I am digging further locally. Using gdb, I found that all non-core objects are registered twice. Once they are registered as part of loading the app-utils module, which in turn loads the engine module which then loads the business modules. The second time they are loaded because the python bindings load the engine module, triggering loading of the business modules again apparently. I have no idea (yet) why this didn't happen before the backend rewrite was merged back in. I suppose none of you have the python bindings enabled, which would explain why only I'm seeing this. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: > Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: > > > On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > > >> On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> wrote: > > >> > > >> Just built master from > > >> https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf10f > > >> ee > > >> c364c8127 and I still do not see the errors Geert is having. Added a > > >> Customer and a Vendor and still only have one of each. > > > > > > Bob, > > > > > > Yes, I'm also not yet able to reproduce the duplicate vendor issue. > > > Geert > > > mentioned on IRC that he's using Fedora-25 so I'm building a new VM with > > > that to test. > > > > I can't reproduce it on Fedora-25 either. > > > > The save problems and crashes on master I *can* reproduce, so I'm working > > on that. > > > > Regards, > > John Ralls > > John, > > I can confirm your commits fix the save problems and crashes. Thanks. > > As I appear to be the only one experiencing the other part of duplicate > objects, I am digging further locally. > > Using gdb, I found that all non-core objects are registered twice. > Once they are registered as part of loading the app-utils module, which in > turn loads the engine module which then loads the business modules. > > The second time they are loaded because the python bindings load the engine > module, triggering loading of the business modules again apparently. > > I have no idea (yet) why this didn't happen before the backend rewrite was > merged back in. > > I suppose none of you have the python bindings enabled, which would explain > why only I'm seeing this. > > Geert The easy one-line fix would be to test for engine_is_initialized == 1 in gnc_engine_init_part2 just like in gnc_engine_init_part1. I wonder though whether we'd want to move this up to gnc_engine_init in general though. Do we want the init hooks to be run each time some code calls gnc_engine_init or should they be called only once also ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
> On Dec 3, 2016, at 7:46 AM, Geert Janssens wrote: > > Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: >> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> wrote: > > Just built master from > https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf10f > ee > c364c8127 and I still do not see the errors Geert is having. Added a > Customer and a Vendor and still only have one of each. Bob, Yes, I'm also not yet able to reproduce the duplicate vendor issue. Geert mentioned on IRC that he's using Fedora-25 so I'm building a new VM with that to test. >>> >>> I can't reproduce it on Fedora-25 either. >>> >>> The save problems and crashes on master I *can* reproduce, so I'm working >>> on that. >>> >>> Regards, >>> John Ralls >> >> John, >> >> I can confirm your commits fix the save problems and crashes. Thanks. >> >> As I appear to be the only one experiencing the other part of duplicate >> objects, I am digging further locally. >> >> Using gdb, I found that all non-core objects are registered twice. >> Once they are registered as part of loading the app-utils module, which in >> turn loads the engine module which then loads the business modules. >> >> The second time they are loaded because the python bindings load the engine >> module, triggering loading of the business modules again apparently. >> >> I have no idea (yet) why this didn't happen before the backend rewrite was >> merged back in. >> >> I suppose none of you have the python bindings enabled, which would explain >> why only I'm seeing this. >> >> Geert > > The easy one-line fix would be to test for engine_is_initialized == 1 in > gnc_engine_init_part2 just like in gnc_engine_init_part1. > > I wonder though whether we'd want to move this up to gnc_engine_init in > general though. Do we want the init hooks to be run each time some code calls > gnc_engine_init or should they be called only once also ? IMO we want to get rid of all of the dlopening and just link the convenience libraries like a normal program. That's a lot of work, though, so for now we should be loading only once. Is the problem really the python bindings (src/optional/python-bindings) or the python console (src/python) that loads the python bindings? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
On 03/12/2016 00:37, John Ralls wrote: > >> On Dec 2, 2016, at 3:02 PM, John Ralls wrote: >> >>> >>> On Dec 2, 2016, at 2:53 PM, Wm via gnucash-devel >>> wrote: >>> >>> On 02/12/2016 20:53, John Ralls wrote: > On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> wrote: > > Just built master from > https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf10feec364c8127 > and I still do not see the errors Geert is having. Added a Customer and a > Vendor and still only have one of each. Bob, Yes, I'm also not yet able to reproduce the duplicate vendor issue. Geert mentioned on IRC that he's using Fedora-25 so I'm building a new VM with that to test. >>> >>> Tagging on the end I've just built master and I get >>> === >>> The file /home/wm/Finance/simple2016-12-02.gnucash already exists. Are >>> you sure you want to overwrite it? >>> === >>> when simple2016-12-02.gnucash is brand new and doesn't exist when saving >>> as xml >>> >>> doing similar but saving as sqlite3 works as expected. >> >> I just pushed a fix for that part, now I'm chasing down why it's gone back >> to saving all of the standard currencies instead of just the ones actually >> assigned to accounts. > > So it looks like restricting the saved currencies just never got ported over > to master rather than being a regression. Anyone remember where the change is? Should have said, I'm testing on a rather unexciting Lubuntu VM === Linux Lubuntu64 4.4.0-51-generic #72-Ubuntu SMP Thu Nov 24 18:29:54 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux === At the risk of saying something everyone knows the save-as-XML creates all the commodities in my tests and they appear and disappear with that format. Recipe new file and save as XML => loads of commodities open same file save as sql3 => expected commodity (just GBP in my case) save as XML again => loads of currencies So, although the fix above works as expected (no errors on save), the commodity enthusiasm is, as far as I can see, directly connected to the format chosen at save time. I also think the file format is separate to the business issue. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
Op zaterdag 3 december 2016 08:05:39 CET schreef John Ralls: > > On Dec 3, 2016, at 7:46 AM, Geert Janssens > > wrote:> > > Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: > >> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: > On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > > On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> wrote: > > > > Just built master from > > https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf10 > > f > > ee > > c364c8127 and I still do not see the errors Geert is having. Added a > > Customer and a Vendor and still only have one of each. > > Bob, > > Yes, I'm also not yet able to reproduce the duplicate vendor issue. > Geert > mentioned on IRC that he's using Fedora-25 so I'm building a new VM > with > that to test. > >>> > >>> I can't reproduce it on Fedora-25 either. > >>> > >>> The save problems and crashes on master I *can* reproduce, so I'm > >>> working > >>> on that. > >>> > >>> Regards, > >>> John Ralls > >> > >> John, > >> > >> I can confirm your commits fix the save problems and crashes. Thanks. > >> > >> As I appear to be the only one experiencing the other part of duplicate > >> objects, I am digging further locally. > >> > >> Using gdb, I found that all non-core objects are registered twice. > >> Once they are registered as part of loading the app-utils module, which > >> in > >> turn loads the engine module which then loads the business modules. > >> > >> The second time they are loaded because the python bindings load the > >> engine > >> module, triggering loading of the business modules again apparently. > >> > >> I have no idea (yet) why this didn't happen before the backend rewrite > >> was > >> merged back in. > >> > >> I suppose none of you have the python bindings enabled, which would > >> explain > >> why only I'm seeing this. > >> > >> Geert > > > > The easy one-line fix would be to test for engine_is_initialized == 1 in > > gnc_engine_init_part2 just like in gnc_engine_init_part1. > > > > I wonder though whether we'd want to move this up to gnc_engine_init in > > general though. Do we want the init hooks to be run each time some code > > calls gnc_engine_init or should they be called only once also ? > > IMO we want to get rid of all of the dlopening and just link the convenience > libraries like a normal program. That's a lot of work, though, so for now > we should be loading only once. > > Is the problem really the python bindings (src/optional/python-bindings) or > the python console (src/python) that loads the python bindings? > It's the console in src/python that triggers this. I agree the dlopening should go and also this is for later. During the introduction of c++ in the backend something changed which causes the engine initialization to be allowed to run twice. I don't immediately find this and frankly I don't really care what it would be. In any case the engine should only be initialized once. I'll add the guard in the init entry point, being gnc_engine_init. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
On 03/12/2016 16:05, John Ralls wrote: > >> On Dec 3, 2016, at 7:46 AM, Geert Janssens >> wrote: >> >> Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: >>> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: > On Dec 2, 2016, at 12:53 PM, John Ralls wrote: >> On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> wrote: >> >> Just built master from >> https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf10f >> ee >> c364c8127 and I still do not see the errors Geert is having. Added a >> Customer and a Vendor and still only have one of each. > > Bob, > > Yes, I'm also not yet able to reproduce the duplicate vendor issue. > Geert > mentioned on IRC that he's using Fedora-25 so I'm building a new VM with > that to test. I can't reproduce it on Fedora-25 either. The save problems and crashes on master I *can* reproduce, so I'm working on that. Regards, John Ralls >>> >>> John, >>> >>> I can confirm your commits fix the save problems and crashes. Thanks. >>> >>> As I appear to be the only one experiencing the other part of duplicate >>> objects, I am digging further locally. >>> >>> Using gdb, I found that all non-core objects are registered twice. >>> Once they are registered as part of loading the app-utils module, which in >>> turn loads the engine module which then loads the business modules. >>> >>> The second time they are loaded because the python bindings load the engine >>> module, triggering loading of the business modules again apparently. >>> >>> I have no idea (yet) why this didn't happen before the backend rewrite was >>> merged back in. >>> >>> I suppose none of you have the python bindings enabled, which would explain >>> why only I'm seeing this. >>> >>> Geert >> >> The easy one-line fix would be to test for engine_is_initialized == 1 in >> gnc_engine_init_part2 just like in gnc_engine_init_part1. >> >> I wonder though whether we'd want to move this up to gnc_engine_init in >> general though. Do we want the init hooks to be run each time some code >> calls >> gnc_engine_init or should they be called only once also ? > > IMO we want to get rid of all of the dlopening and just link the convenience > libraries like a normal program. That's a lot of work, though, so for now we > should be loading only once. > > Is the problem really the python bindings (src/optional/python-bindings) or > the python console (src/python) that loads the python bindings? Open Q: has anyone tried this on Win where the python stuff is known not to work? I think python is red herring in this for me and agree there are (at least) two issues -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
Op zaterdag 3 december 2016 17:24:27 CET schreef Wm via gnucash-devel: > On 03/12/2016 16:05, John Ralls wrote: > >> On Dec 3, 2016, at 7:46 AM, Geert Janssens > >> wrote:>> > >> Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: > >>> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: > > On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > >> On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> > >> wrote: > >> > >> Just built master from > >> https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf1 > >> 0f > >> ee > >> c364c8127 and I still do not see the errors Geert is having. Added a > >> Customer and a Vendor and still only have one of each. > > > > Bob, > > > > Yes, I'm also not yet able to reproduce the duplicate vendor issue. > > Geert > > mentioned on IRC that he's using Fedora-25 so I'm building a new VM > > with > > that to test. > > I can't reproduce it on Fedora-25 either. > > The save problems and crashes on master I *can* reproduce, so I'm > working > on that. > > Regards, > John Ralls > >>> > >>> John, > >>> > >>> I can confirm your commits fix the save problems and crashes. Thanks. > >>> > >>> As I appear to be the only one experiencing the other part of duplicate > >>> objects, I am digging further locally. > >>> > >>> Using gdb, I found that all non-core objects are registered twice. > >>> Once they are registered as part of loading the app-utils module, which > >>> in > >>> turn loads the engine module which then loads the business modules. > >>> > >>> The second time they are loaded because the python bindings load the > >>> engine > >>> module, triggering loading of the business modules again apparently. > >>> > >>> I have no idea (yet) why this didn't happen before the backend rewrite > >>> was > >>> merged back in. > >>> > >>> I suppose none of you have the python bindings enabled, which would > >>> explain > >>> why only I'm seeing this. > >>> > >>> Geert > >> > >> The easy one-line fix would be to test for engine_is_initialized == 1 in > >> gnc_engine_init_part2 just like in gnc_engine_init_part1. > >> > >> I wonder though whether we'd want to move this up to gnc_engine_init in > >> general though. Do we want the init hooks to be run each time some code > >> calls gnc_engine_init or should they be called only once also ? > > > > IMO we want to get rid of all of the dlopening and just link the > > convenience libraries like a normal program. That's a lot of work, > > though, so for now we should be loading only once. > > > > Is the problem really the python bindings (src/optional/python-bindings) > > or the python console (src/python) that loads the python bindings? > Open Q: has anyone tried this on Win where the python stuff is known not > to work? > > I think python is red herring in this for me and agree there are (at > least) two issues No, python is not a red herring here. This thread is becoming increasingly confusing because I report many different issues at once. There were the save failure and crash which John fixed yesterday. There is still the issue of all commodities being saved instead of only those that are actually in use. And there's the one I alone was seeing (business ojbects being saved twice resulting in a corrupt xml file). This last one only appeared when gnucash is built with python bindings and I have just pushed a fix for a a couple of minutes ago. So the only thing left is the abundance of commodities being saved by xml. John, to answer your question: no, I don't know anymore either when this was implemented. It's weird this would not be in master though as all commits in maint are eventually merged into master. So if we're missing it on master one such merge must have had conflicts which weren't resolved properly. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
Op zaterdag 3 december 2016 18:32:44 CET schreef Geert Janssens: > Op zaterdag 3 december 2016 17:24:27 CET schreef Wm via gnucash-devel: > > On 03/12/2016 16:05, John Ralls wrote: > > >> On Dec 3, 2016, at 7:46 AM, Geert Janssens > > >> wrote:>> > > >> > > >> Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: > > >>> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: > > > On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > > >> On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> > > >> wrote: > > >> > > >> Just built master from > > >> https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8b > > >> f1 > > >> 0f > > >> ee > > >> c364c8127 and I still do not see the errors Geert is having. Added > > >> a > > >> Customer and a Vendor and still only have one of each. > > > > > > Bob, > > > > > > Yes, I'm also not yet able to reproduce the duplicate vendor issue. > > > Geert > > > mentioned on IRC that he's using Fedora-25 so I'm building a new VM > > > with > > > that to test. > > > > I can't reproduce it on Fedora-25 either. > > > > The save problems and crashes on master I *can* reproduce, so I'm > > working > > on that. > > > > Regards, > > John Ralls > > >>> > > >>> John, > > >>> > > >>> I can confirm your commits fix the save problems and crashes. Thanks. > > >>> > > >>> As I appear to be the only one experiencing the other part of > > >>> duplicate > > >>> objects, I am digging further locally. > > >>> > > >>> Using gdb, I found that all non-core objects are registered twice. > > >>> Once they are registered as part of loading the app-utils module, > > >>> which > > >>> in > > >>> turn loads the engine module which then loads the business modules. > > >>> > > >>> The second time they are loaded because the python bindings load the > > >>> engine > > >>> module, triggering loading of the business modules again apparently. > > >>> > > >>> I have no idea (yet) why this didn't happen before the backend rewrite > > >>> was > > >>> merged back in. > > >>> > > >>> I suppose none of you have the python bindings enabled, which would > > >>> explain > > >>> why only I'm seeing this. > > >>> > > >>> Geert > > >> > > >> The easy one-line fix would be to test for engine_is_initialized == 1 > > >> in > > >> gnc_engine_init_part2 just like in gnc_engine_init_part1. > > >> > > >> I wonder though whether we'd want to move this up to gnc_engine_init in > > >> general though. Do we want the init hooks to be run each time some code > > >> calls gnc_engine_init or should they be called only once also ? > > > > > > IMO we want to get rid of all of the dlopening and just link the > > > convenience libraries like a normal program. That's a lot of work, > > > though, so for now we should be loading only once. > > > > > > Is the problem really the python bindings (src/optional/python-bindings) > > > or the python console (src/python) that loads the python bindings? > > > > Open Q: has anyone tried this on Win where the python stuff is known not > > to work? > > > > I think python is red herring in this for me and agree there are (at > > least) two issues > > No, python is not a red herring here. This thread is becoming increasingly > confusing because I report many different issues at once. > > There were the save failure and crash which John fixed yesterday. > There is still the issue of all commodities being saved instead of only > those that are actually in use. > And there's the one I alone was seeing (business ojbects being saved twice > resulting in a corrupt xml file). This last one only appeared when gnucash > is built with python bindings and I have just pushed a fix for a a couple > of minutes ago. > > So the only thing left is the abundance of commodities being saved by xml. > And I should have added that this indeed probably doesn't have anything to do with the python bindings. So we can ignore those again from now on :) Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
> On Dec 3, 2016, at 9:38 AM, Geert Janssens wrote: > > Op zaterdag 3 december 2016 18:32:44 CET schreef Geert Janssens: >> Op zaterdag 3 december 2016 17:24:27 CET schreef Wm via gnucash-devel: >>> On 03/12/2016 16:05, John Ralls wrote: > On Dec 3, 2016, at 7:46 AM, Geert Janssens > wrote:>> > > Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: >> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> > wrote: > > Just built master from > https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8b > f1 > 0f > ee > c364c8127 and I still do not see the errors Geert is having. Added > a > Customer and a Vendor and still only have one of each. Bob, Yes, I'm also not yet able to reproduce the duplicate vendor issue. Geert mentioned on IRC that he's using Fedora-25 so I'm building a new VM with that to test. >>> >>> I can't reproduce it on Fedora-25 either. >>> >>> The save problems and crashes on master I *can* reproduce, so I'm >>> working >>> on that. >>> >>> Regards, >>> John Ralls >> >> John, >> >> I can confirm your commits fix the save problems and crashes. Thanks. >> >> As I appear to be the only one experiencing the other part of >> duplicate >> objects, I am digging further locally. >> >> Using gdb, I found that all non-core objects are registered twice. >> Once they are registered as part of loading the app-utils module, >> which >> in >> turn loads the engine module which then loads the business modules. >> >> The second time they are loaded because the python bindings load the >> engine >> module, triggering loading of the business modules again apparently. >> >> I have no idea (yet) why this didn't happen before the backend rewrite >> was >> merged back in. >> >> I suppose none of you have the python bindings enabled, which would >> explain >> why only I'm seeing this. >> >> Geert > > The easy one-line fix would be to test for engine_is_initialized == 1 > in > gnc_engine_init_part2 just like in gnc_engine_init_part1. > > I wonder though whether we'd want to move this up to gnc_engine_init in > general though. Do we want the init hooks to be run each time some code > calls gnc_engine_init or should they be called only once also ? IMO we want to get rid of all of the dlopening and just link the convenience libraries like a normal program. That's a lot of work, though, so for now we should be loading only once. Is the problem really the python bindings (src/optional/python-bindings) or the python console (src/python) that loads the python bindings? >>> >>> Open Q: has anyone tried this on Win where the python stuff is known not >>> to work? >>> >>> I think python is red herring in this for me and agree there are (at >>> least) two issues >> >> No, python is not a red herring here. This thread is becoming increasingly >> confusing because I report many different issues at once. >> >> There were the save failure and crash which John fixed yesterday. >> There is still the issue of all commodities being saved instead of only >> those that are actually in use. >> And there's the one I alone was seeing (business ojbects being saved twice >> resulting in a corrupt xml file). This last one only appeared when gnucash >> is built with python bindings and I have just pushed a fix for a a couple >> of minutes ago. >> >> So the only thing left is the abundance of commodities being saved by xml. >> > And I should have added that this indeed probably doesn't have anything to do > with the python bindings. So we can ignore those again from now on :) I found it. When I abstracted KVP to make it private-ish to QofInstance I removed some tests in the course of changing kvp_frame_to_dom_tree() into qof_instance_slots_to_dom_tree() with the result that it returns an empty element instead of nullptr on the currencies so that the commodity gets saved when it shouldn't. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Master - saving to xml broken
Op zaterdag 3 december 2016 12:52:25 CET schreef John Ralls: > > On Dec 3, 2016, at 9:38 AM, Geert Janssens > > wrote:> > > Op zaterdag 3 december 2016 18:32:44 CET schreef Geert Janssens: > >> Op zaterdag 3 december 2016 17:24:27 CET schreef Wm via gnucash-devel: > >>> On 03/12/2016 16:05, John Ralls wrote: > > On Dec 3, 2016, at 7:46 AM, Geert Janssens > > > > wrote:>> > > > > Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens: > >> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls: > On Dec 2, 2016, at 12:53 PM, John Ralls wrote: > > On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubo...@gmail.com> > > wrote: > > > > Just built master from > > https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8 > > b > > f1 > > 0f > > ee > > c364c8127 and I still do not see the errors Geert is having. Added > > a > > Customer and a Vendor and still only have one of each. > > Bob, > > Yes, I'm also not yet able to reproduce the duplicate vendor issue. > Geert > mentioned on IRC that he's using Fedora-25 so I'm building a new VM > with > that to test. > >>> > >>> I can't reproduce it on Fedora-25 either. > >>> > >>> The save problems and crashes on master I *can* reproduce, so I'm > >>> working > >>> on that. > >>> > >>> Regards, > >>> John Ralls > >> > >> John, > >> > >> I can confirm your commits fix the save problems and crashes. > >> Thanks. > >> > >> As I appear to be the only one experiencing the other part of > >> duplicate > >> objects, I am digging further locally. > >> > >> Using gdb, I found that all non-core objects are registered twice. > >> Once they are registered as part of loading the app-utils module, > >> which > >> in > >> turn loads the engine module which then loads the business modules. > >> > >> The second time they are loaded because the python bindings load the > >> engine > >> module, triggering loading of the business modules again apparently. > >> > >> I have no idea (yet) why this didn't happen before the backend > >> rewrite > >> was > >> merged back in. > >> > >> I suppose none of you have the python bindings enabled, which would > >> explain > >> why only I'm seeing this. > >> > >> Geert > > > > The easy one-line fix would be to test for engine_is_initialized == 1 > > in > > gnc_engine_init_part2 just like in gnc_engine_init_part1. > > > > I wonder though whether we'd want to move this up to gnc_engine_init > > in > > general though. Do we want the init hooks to be run each time some > > code > > calls gnc_engine_init or should they be called only once also ? > > IMO we want to get rid of all of the dlopening and just link the > convenience libraries like a normal program. That's a lot of work, > though, so for now we should be loading only once. > > Is the problem really the python bindings > (src/optional/python-bindings) > or the python console (src/python) that loads the python bindings? > >>> > >>> Open Q: has anyone tried this on Win where the python stuff is known not > >>> to work? > >>> > >>> I think python is red herring in this for me and agree there are (at > >>> least) two issues > >> > >> No, python is not a red herring here. This thread is becoming > >> increasingly > >> confusing because I report many different issues at once. > >> > >> There were the save failure and crash which John fixed yesterday. > >> There is still the issue of all commodities being saved instead of only > >> those that are actually in use. > >> And there's the one I alone was seeing (business ojbects being saved > >> twice > >> resulting in a corrupt xml file). This last one only appeared when > >> gnucash > >> is built with python bindings and I have just pushed a fix for a a couple > >> of minutes ago. > >> > >> So the only thing left is the abundance of commodities being saved by > >> xml. > > > > And I should have added that this indeed probably doesn't have anything to > > do with the python bindings. So we can ignore those again from now on :) > I found it. When I abstracted KVP to make it private-ish to QofInstance I > removed some tests in the course of changing kvp_frame_to_dom_tree() into > qof_instance_slots_to_dom_tree() with the result that it returns an empty > element instead of nullptr on the currencies so that the commodity gets > saved when it shouldn't. > > Regards, > John Ralls Great! Now we can all continue where we left off before this interrupt :D Thanks John! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.
HACKING file in gnucash-docs
Hello, I took a look today at the HACKING file included with the GnuCash docs, and I believe that it is out of date, at least because it references subversion. There may be other outdated bits included, but I am not informed enough to know what this document should say instead. I wanted to raise the issue here so that this file can get updated to current practice and procedure. TIA, David T. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
