annoying simple Guile question
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
> 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.
> 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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