Op zaterdag 3 december 2016 12:52:25 CET schreef John Ralls: > > On Dec 3, 2016, at 9:38 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> > > 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 > >>>>> <geert.gnuc...@kobaltwit.be> > >>>>> 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 <jra...@ceridwen.us> 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.gnucash.org/mailman/listinfo/gnucash-devel
