annoying simple Guile question

[Derek Atkins]

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.

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

Sure...

> Should it go in a new /examples or perhaps in /accounts?

Neither.  I'd suggest /bin, /experimental, or /optional.

> Should it be outside GnuCash entirely, perhaps a mini project or absorbed 
> completely into pilot-link?

I'm not sure pilot-link is the right place for it.  But standalone is
certainly another option.

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

> I find it quite a useful debugging tool (quicker to recompile and test than 
> the full GUI).

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 do have a more 'standardised' test routine that has none of these problems, 
> mainly because it isn't interactive and therefore doesn't abort nor load 
> external files.

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.

> Console interactivity is probably to blame.

Could be.  I don't know.

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

Although having a real "test" in place would be a good thing.

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.

Ok.

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

> 2. My GUI skills aren't the best so the druid behaviour is not ideal.

:(

> 3. It's getting confused with the hierarchy druid output. Say you have a 
> simple book open in GnuCash and select Childcare Expenses from the hierarchy 
> druid to merge into your file. That's two accounts, Expenses (which will 
> match an existing account) and Childcare. In the GUI, I get 63 collision 
> reports.
> ???
> Running the same files through the console application (I said it was handy!) 
> generates the expected: 1 duplicate account, 1 possibly new account.
> Some of the collision reports list parameter data for Account objects that is 
> clearly inherited from UNSELECTED accounts from the example list - they 
> neither exist in the original book nor the selection 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.

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

-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