Re: QOF-to-SQL Proof of Concept

[EMAIL PROTECTED] (Linas Vepstas) writes: >> latter, because some SQL engines that I'd like to use don't support >> notify events (e.g. SQLite). > > but SQLLite is single-user, right? No multi-user support. No, there is multi-user support in SQLite (at least according to their website). It lock

ANNOUNCE: [EMAIL PROTECTED]: ETRACK 0.90 available]

Below is announcement for a simple scheme/guile command-line/emacs based expense tracking package. --linas - Forwarded message from Thien-Thi Nguyen <[EMAIL PROTECTED]> - README excerpt: This directory contains etrack, a simple package to track expenses: query, add, delete, update

Re: QOF-to-SQL Proof of Concept

On Mon, May 24, 2004 at 11:10:49AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > FYI, > > > > I just finished coding a proof-of-concept for saving & restoring > > arbitrary QOF objects to SQL tables & back. I've now started on > > a prototype that will

Re: QOF_QUERY_PARAM_GUID -> QOF_PARAM_GUID

On Mon, May 24, 2004 at 10:56:04PM +0200, Herbert Thoma was heard to remark: > Hi! > > I think Linas missed some QOF_QUERY_PARAM_GUID -> QOF_PARAM_GUID Sorry. I am not sure how to justify the rush I swas in that I'd miss this. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <

Re: Book Closing in HEAD kills objects in a "bad" order, corrupts memory.

[EMAIL PROTECTED] (Linas Vepstas) writes: > Hey' didn't you write that code? I think its pulling from a hash table, > which is why its random order. I don't remember how things work during > startup. It should be easier during startup, where one can clearly > spec a dependency graph (this depend

Re: Book Closing in HEAD kills objects in a "bad" order, corrupts memory.

On Wed, May 26, 2004 at 09:34:24AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > On Tue, May 25, 2004 at 10:33:18AM -0400, Derek Atkins was heard to remark: > >> > >> DEBUG: Enter: qof_object_book_end > > > > OK. right, reordering would be non-trivial

Re: Book Closing in HEAD kills objects in a "bad" order, corrupts memory.

On Wed, May 26, 2004 at 09:26:16AM -0400, Derek Atkins was heard to remark: > 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 bo

Re: Book Closing in HEAD kills objects in a "bad" order, corrupts memory.

[EMAIL PROTECTED] (Linas Vepstas) writes: > On Tue, May 25, 2004 at 10:33:18AM -0400, Derek Atkins was heard to remark: >> >> DEBUG: Enter: qof_object_book_end > > OK. right, reordering would be non-trivial. > > The if (book_ending) flag sounds like a good idea. > > Are you fixing this, or do yo

Re: Book Closing in HEAD kills objects in a "bad" order, corrupts memory.

On Tue, May 25, 2004 at 10:33:18AM -0400, Derek Atkins was heard to remark: > > DEBUG: Enter: qof_object_book_end OK. right, reordering would be non-trivial. The if (book_ending) flag sounds like a good idea. Are you fixing this, or do you really want me to do it? --linas -- pub 1024D/010

Re: Book Closing in HEAD kills objects in a "bad" order, corrupts memory.

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 o

Re: Book Closing in HEAD kills objects in a "bad" order, corrupts memory.

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.