After a lot of playing around, I finally got the guile side working in a way that makes me happy. We've even got really nice automatic C header generation from the independent specification file. Now I don't know if everyone's going to be completely comfortable with that, but it definitely has advantages (no potential prototype skew, automatically get new functions on the scripting side, and automatic developer html docs and comments). Basically, you specify functions like this: (new-function 'gnc:account-occurences-in-list 'int "xaccIsAccountInList" '((Account* a) (Account** l)) "Return the number of times that account a appears in account list l.") and from that g-wrap generates guile wrapper functions, html docs including argument types and the description, and the main C side header file (i.e Account.h) with full comments and the #ifndef stuff. No memory leaks either. The GnuCash types show up at the guile level as opaque objects (just like they did with swig), but I've also special cased list types like Account** so that these are a separate kind of object that supports pointer-array-ref and pointer-array-length so you can get at their contents. The pointer-array is just a shallow wrapper around the underlying void**, so it's *very* time/space efficient. Whenever you do a pointer-array-ref, it creates the guile side object to represent that item in the array on the fly. Also, since we presume (for now) that you're not going to be modifying the void** from the guile level [1], we can store the length with the object when it's created, making that computation constant. [1] is this true? Say you GetSplits and get the Split** pointer. What happens when you call a function to add some splits? If realloc doesn't work, you may get a new pointer. I'll have to check and see if this causes any problems... Having pointer-arrays like this makes implementing conveniences on top of them like pointer-array-for-each and pointer-array-map or (the less efficient) pointer-array->pointer-token-list trivial. Any other features we need in g-wrap will be trivial to add since I've got a good working relationship with the author, and his code is surprisingly easy to augment. I've put the whole thing into gnucash/lib and integrated it into our build process so no one should feel a thing. Now that I've gotten this settled, I've already started making good progress on some of the things that have been waylaid[2] by this for a while. Just so you know what's going on. Expect a large patch soon... [2] memorized transactions, textual file format, options dialog (I'll need some help from Jeremy on this one), user hooks, etc. -- 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
