annoying simple Guile question

Neil Williams linux at codehelp.co.uk
Wed Sep 22 10:17:49 EDT 2004


On Wednesday 22 September 2004 2:56 pm, Derek Atkins wrote:
> 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)...

The code will merge any valid QofBook, no matter how it is presented. The 
console application that I will work on will be targetted at XML simply 
because I see that as the easiest for communication via pilot-link. There's 
nothing to stop it being adapted to accept other sources. The merge code 
itself is a library that can be used by any QOF aware program.

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

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

The new one has just been sent and it completely replaces the one from the 
27th August - which can now be forgotten.

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

:-))

It's resolved now. I suspect it was just a messy build - in preparing the 
patch I tidy up what I've been coding and build in separate directories. This 
shows up all kinds of issues with things like the Makefile.am - it hasn't 
happened since.

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

I suspect there was a config error in an old file that got removed during 
further testing. (Unless it happens again, but I have tested the code in the 
patch with this in mind.)

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

Thanks. I won't be doing much on this code for a week now myself - got to 
catch up on other projects.

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

It crashes within the second run of the account hierarchy druid (at the point 
where it is processing the user selection of example account trees), not when 
the merge druid loads. I will continue investigations.

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

:-))

Thank you for all your help with this, Derek. I know it hasn't been easy with 
a self-taught newbie asking daft questions each week!


-- 

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/4979cf38/attachment-0001.bin


More information about the gnucash-devel mailing list