On 12 Aug 1999 00:13:16 CDT, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
>
> (Aside: I've nearly got the gnc_choose_item_from_list_dialog function
> and guile side gnc:choose-item-from-list-dialog wrapper working. I
> finally got around to it. Also note that in the process I've changed
> the behavior of gnc:query-dialog, and created a generic interaction
> dialog function that lets you put whatever you like above the
> yes/no/cancel buttons. I'll have details later.)
Glad to hear it.
> [EMAIL PROTECTED] writes:
>
> > Note that this includes the "c-split" component, which would be
> > populated using the C address of the split. This way we maintain
> > the data from both sides of the Lisp<==>C "boundary." I suspect
> > that it may also be necessary to include a couple additional "C
> > pointer references" that allow referencing the C pointers to the
> > account and the transaction.
>
> Keeping C pointers on the scheme side long term seems like a bad idea.
> If you need to keep them short term, then that's fine, but in general,
> you should try hard to stick to using the C data structures (via the
> corresponding g-wrapped getter/setter routines) directly.
>
> There are some potentially ugly synchronization and skew problems that
> duplicating the data on the guile side creates --- you won't be
> notified when someone makes a change, and those changes are already
> asynchronous (via the GUI) and may become even less predictable if we
> start supporting incoming commands via a socket.
The plan is *not* to have this persist for any great period of time;
it is, rather to build the whole set of transactions on the Scheme side
and push them in at
once.
> Further, there's a related garbage collection/memory allocation issue
> here. Over the long term, the guile side has no way of knowing when
> the C side might free the C pointers you're holding within your
> guile-side split structure. We could fix that by adding some more
> conventions/infrastructure to the C side deallocation process, but if
> we don't have a compelling reason to do that now, we'd probably be
> better off postponing that work until we do.
>
> > Creating a new split might look like this:
> >
> > (define (initialize-split) ;;; Returns a gnc-split-structure
> > (let ((ptr (gnc:split-create))
> > (splitstruct (build-mystruct-instance gnc-split-structure)))
> > (splitstruct 'put 'gncpointer ptr)
> > splitstruct))
>
> What's the advantage to this over just using:
>
> (gnc:malloc-split)
>
> as provided by g-wrap as a wrapper for xaccMallocSplit and then using
> the normal (or some new ones if we need them) g-wrapped split
> manipulators? And if the current manipulators are just too scheme
> unfriendly, then we can add some friendlier wrappers to
> src/scm/convenience-wrappers.scm (or wherever) as I'm doing for the
> user interaction stuff..
The plan is to have that set up the split, and then I set up all
the other splits, and can populate them all in whatever order
is appropriate from the "turning-QIF-into-GnuCash" perspective.
> > Am I way off here? Or does this sound like the right direction?
>
> >From my semi-careful reading, I think you've mostly understand the
> structure. Note that AFAIK there's no global list of transactions
> anywhere. They're just pointed to by all the relvant splits they
> contain.
That's the impression I get from the way the data structure seems to
work, so I think we're reading this the same.
> Also, I can't recall if splits are unique. I thought they
> were, but I'm not sure. i.e. is there only one copy of a given split
> that each account (on both the sending and receiving end) point to, or
> is there one copy for each account...
That makes sense, and I hope there's only just the one copy of each
split.
> Also note that despite my criticisms, I'm sure there may very well be
> a good reason to do things more the way you're suggesting and I just
> haven't "gotten it" yet.
The thing to "get" is that I only intend for this stuff to persist on
the Scheme side for long enough to populate all the
splits/transactions/accounts. The data can then get dropped.
--
THAT COMMAND IS NOT KNOWN TO THIS PROGRAM.
MAYBE YOU SHOULD LOG IN? (TYPE HELP FOR DETAILS)
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
