Master - saving to xml broken

[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.gnucash at 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 <jralls at ceridwen.us> wrote:
> >>>>>> On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubobit at 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