annoying simple Guile question

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

>> Well, it shouldn't depend on the XML backend even if it's embedded in
>> the GnuCash tree.
>
> Sorry, I wasn't clear. XML as data interchange, not as a backend. If it's 
> going to receive QofBook data from external sources, including pilot-link or 
> via STDIN, it'll need the current XML parser, no matter what the backend 
> becomes. As part of QOF, qof_book_merge has no need to know about specific 
> GnuCash backends, only intermediary data formats. As we discussed originally, 
> XML is ideally suited to this data interchange mode.

AHHH..  Yes, indeed, XML is definitely suited to this.  However your
code still shouldn't assume XML, because a user may want to merge two
PG databases together, or a PG and XML dataset, or an XML and SQLite
(once that's implemented)...

You should be able to use any Gnucash-supported backend to load data
for merging.

But yes, XML is still a great interchange format.

>> Although having a real "test" in place would be a good thing.
>
> Agreed. The current test-book-merge.c is (to quote another test program) only 
> 'lightly testing' the framework.

That's ok -- it will still tell you if the framework is broken (if it's
a good test).

>> Question: do you still want me to apply that patch of yours from a few
>> weeks ago?  Or should I wait and apply the next one you plan to send?
>> > I've got all day tomorrow to sort it out - if it doesn't work I'll submit
>> > the patch tomorrow evening (BST) without it.
>
> I should have a patch ready later today - although some of the errors below 
> won't get fixed by then. The patch is almost ready because I've still got GUI 
> work to complete on the merge druid - I've got to complete the code to 
> present the user intervention information and handle the input ready for the 
> commit. Using radio buttons doesn't work, I need to replace them with 
> ordinary buttons.

That didn't answer my question, tho.  Should I apply your outstanding
patch or should I wait for the new one?

>> > Known problems with the merge druid so far:
>> >
>> > 1. First time crashes: For some reason, the first time you select a
>> > category, the code can cause a seg fault (in the hierarchy druid) - maybe
>> > 10% of the time. Next time you choose the same category, it works
>> > perfectly.
>>
>> How does it "recover" from a seg fault?
>
> (when you restart GnuCash). My point is that the crash is not easily 
> reproducible. It appears to be the first run after a build has a risk of 
> crashing. Subsequent runs seem OK - until the next make install.

Oh, that's VERY weird.  Unless it's a data-dependent file I can't
think of ANY reason why it would do this.  Unless you're writing
self-modifying code.  ;)

Unless.....  you may have a race condition.  The first time you run
after an install the runtime loader needs to read everything from
disk, which takes time.  The second time you run everything is cached
in memory so it runs much faster.  Perhaps the load-delay due to the
disk read is causing your failure because you're got a timing issue?
Perhaps you're expecting something to get initialized but it's not
being initialized fast enough when you're loading from disk?

>> > from the druid. I'm going to have to investigate delete_merge_group
>> > because it doesn't seem to be cleaning up properly (or else it's relying
>> > on a secondary process to do the clean up that is not called in the merge
>> > druid code).
>>
>> I'd guess the latter.  It sounds like you're using the wrong data to
>> merge into the existing book.
>
> I run the hierarchy druid to completion inside a second session then take the 
> QofBook exactly as it is left by the druid. There must be a secondary step 
> normally used by gnc_file_new() that I'm missing. 
>
> The only changes I've made to druid-hierarchy.c are to allow the hierarchy 
> druid to hand control back to the merge druid - because the second session is 
> started by the merge druid. The hierarchy druid is now aware of the merge 
> druid and behaves appropriately depending on whether the hierarchy druid was 
> started directly (by File->New, without a second session) or indirectly (by 
> File -> New Account Hierarchy, which starts merge druid, the second session 
> and then the hierarchy druid).

Hmm, I'll have to look at the code.  But not this week.

>> > 4. I've got some work to do with memory and g_free - the druid currently
>> > crashes if you run it twice within one GnuCash instance.
>>
>> Not good.  :(
>
> I know. Almost certainly related to the confused data received from the druid 
> - if I run the merge druid with dummy data and don't call the hierarchy 
> druid, it can be run repeatedly (but then it's not doing a lot!).

Not necessarily.  It could be that the druid, once loaded, doesn't get
"destroyed" but rather just hides itself to "go away".  If this is the
case (I don't know, I haven't checked, and I don't plan to explore
this myself -- I'm just suggesting avenues for you to explore) then if
YOU are destroying the hierarchy druid yourself then the next time you
try to run it it wont be there.  *crash*

> This is where I need the most help - when my code works fine alone but doesn't 
> work alongside existing code. Even if the GUI isn't trouble-free I'd like to 
> be able to submit it and get specific feedback on exactly where the problems 
> lie. It's hard to discuss these errors when the full code isn't available to 
> everyone.

*nods*

Bugs happen.  Never expect your code to be perfect the first time through.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available