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 <[email protected]> > > >> 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 <[email protected]> wrote: > > >>>>>> On Dec 2, 2016, at 12:47 PM, Robert Fewell <[email protected]> > > >>>>>> 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 [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
