annoying simple Guile question

Wed Sep 22 04:57:45 EDT 2004

On Wednesday 22 September 2004 4:23 am, you wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > I'll look into that. TBH, I'm not sure why it is calling OpenSP, except
> > that it is loading the current XML datasource files directly, without
> > user intervention and without using Guile/Scheme/GUI.
>
> XML doesn't use OpenSP.  The only thing I can think of that uses
> OpenSP is the OFX code.  But you shouldn't be loading that at all.

Erk. That is bad. I have no need or intention of calling OFX code - as it is 
obviously being called, this example will not make the next patch and I'll 
check future backtraces in other code for OpenSP - to be sure.

> > Is a console demo/program/merge suitable for the main GnuCash tree?
>
> Sure...

Great.

> > Should it go in a new /examples or perhaps in /accounts?
>
> Neither.  I'd suggest /bin, /experimental, or /optional.

/experimental
(It's certainly unfinished!)

> > (I don't mind which, except that if it is outside GnuCash completely, it
> > might make it harder to get it working when the XML backend is replaced -
> > it'd lose the automation and have to save the XML to the filesystem for a
> > later merge within GnuCash itself.)
>
> 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.

> Eh?  You don't need to recompile the full GUI; you generally only need
> to recompile the library you're working on...  Unless you're changing
> APIs.  But I find I can "make -C src/engine install" and it works
> quite nicely.

I'm learning all the time!
:-)
(I spent a lot of yesterday morning learning Glade - never used it before).

> Uh, Gnucash has plenty of test routines that load external files (as I
> said, check the tests in src/backend/file/test for examples.  They
> work just fine, and they exit just fine when they are done.

I suspect it's the early abort that is not cleaning up properly.

> > Pity, I've *almost* got the replacement patch ready that includes the
> > Glade and C code to wrap a QofBook* merge operation around an existing
> > file and the output of the hierarchy druid! It works (with a few
> > provisos) but now I'll have to either fix or remove the example before I
> > submit the patch.
>
> Well, removing the example is pretty easy (IMHO).  ;)

:-)
Not at 1am! I'll do it today.

> 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.

> 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.

> > 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.

> > 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).

> > 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!).

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.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20040922/1615368c/attachment.bin