Linas, thanks for the affirmation. I'll add some code to handle this
case, in which case we don't really need to worry about the order
anymore (at least for book_end().
We may still need to worry about it for book_begin(), but I'm not sure
how to handle that in the current QOF Object code. The order seems
somewhat dependent on the order-of-registration of the object modules,
no?
-derek
[EMAIL PROTECTED] (Linas Vepstas) writes:
> On Tue, May 25, 2004 at 11:52:08AM -0400, Derek Atkins was heard to remark:
>> I'm not 100% convinced it's the order that matters... I'm thinking
>> that during book_end() the various objects should just free() themselves
>> of memory and not worry about keeping themselves balanced. In other
>
> Yes. I agree.
>
>> >> As you can see from the following trace this causes a memory access
>> >> failure because transactions are kept in balance even when we're
>> >> destroying the book, so it's trying to scrub against an
>> >> already-destroyed commodity.
>
> That's a bug
>
>> > Why do we need to scrub things we're just trying to get rid of?
>
> Don't need to that's a bug.
>
> It would be nice to do them in order too. The order should be:
>
>> > * Business objects / SX templates
>> > * Lots
>> > * Splits / Transactions
>> > * Accounts / Price-DB
>> > * Commodities
>> > * Book
>> > * Session state
>
> --linas
>
> --
> pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
>
>
--
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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
