(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.)
[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.
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..
> 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. 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...
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.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
