Re: Python script: Gnucash
On Fri, 07 Oct 2011 14:38:37 +1300, Andrew Ruthven wrote: Also, I'm not sure if has been mentioned here already, but myself, Micha Lenk and mostly Philipp Kern packaged up the python bindings for Debian. They're in the python-gnucash package in Debian testing unstable. If that was recent, it explains an anomaly I noticed today. The package python-gnucash has arrived in Debian wheezy according to aptitude on one of my machines, but not on another, which uses different mirrors. In any case, thanks. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Thu, 07 Jul 2011 20:48:27 -0500, Tim M wrote: What I'm looking for is this: 1. Create the 'new' reporting system alongside the existing one so that the reports do not suffer until the existing functionality can be fully replaced by the new system. After all reports are replaced and working, the old scheme code could be pulled. 2. Create a set of libraries and/or use the existing gnucash libraries for querying information from the database. Based on the discussion, I presume C or Objective C would be best and just avoid Python/Scheme altogether (I am not sure how the scheme system actually performs the data queries right now). If all the necessary code is already in place, then this does not require any work. As far as I've been able to figure out so far, the python and scheme bindings use the existing gnucash libraries to access the data base. So if the current reports are what you need, why rewrite in C? But it does make sense to allow the Scheme reporting system to generate XML. And if it's essential for some reason to have them compiled, the Gambit C implementation of Scheme (as in Debian package gambc) is capable of compiling Scheme into (rather unreadable) C. Of course there are subtle differences between Gambit and guile, and including another tool into gnucash would be a big step. 3. Using these libraries, create the code for aggregating the data (also in C or Objective C) for each report. A single prototype report would be OK to start. Output the report data as structured XML. The XML data should adhere to an XML schema. All in favour of allowing reports to be in XML. It probably won't take too much effort to allow this. It's what I'm already doing with my personal reporting tool that reads the gnucash XML file. It's written in C++ and has to be changed every year or so to adapt to changes in teh gnucash file. All I needed for neat output was a .css file. It's quite effective. 4. For each report, create an XSLT file which will transform the data into HTML/XHTML for display. 5. A small amount of javascript would be needed to perform the actual XSLT transformation but it would be pretty small. 6. Style the page elements using CSS. Also, I think the jqplot patch that has been made could be migrated in to the new reporting system, as those graphs look really nice. If we're brainstorming about report-describing formalisms, has anyone looked at RPG, a commercial workhorse from back in the 1960's? It wouldn't be directly applicable unless it's changed drastically since then, but some of its ideas may be. I think there are several benefits to this approach: 1. Currently reports can only be exported as HTML. By making the reporting code export an XML data structure, reports could be easily exported from GnuCash as XML (pre-transformation) or as HTML (post-transformation). Much desired. But could probably be achieved with only minor changes in the present system. 6. No reliance on Scheme or Python. Minimal Javascript, but that should be handled easily by webkit. To achieve advantage 6 would require major changes, though. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Fri, 08 Jul 2011 23:33:16 -0400, John Ralls wrote: On Jul 8, 2011, at 8:15 PM, Yawar Amin wrote: If we stick with Scheme, we can take advantage of all the low-level functions that already exist for data extraction and report layout. But we can also move to a declarative model where we can have convention (re-use the report definitions as options) over configuration (build an options dialog box). Also, is it still true that we have to restart GnuCash every time we change a Scheme report, to see the changes? In any case, we need to make it dead easy for users to import and run and custom reports. Best, Yawar * I find that I’m saying ‘declarative’ a lot nowadays–I think it has to do with the fact that I’m learning Haskell :-) Fun. Two questions: Can that be easily converted into a string parser so that normal users aren't put off by the extra parentheses, and is there anything about that that works in Scheme but not in C? One of the hallmarks of Scheme is its metaprogrammability, for applications just like this. And its simple syntax promotes this. Not that it isn't possible to write string parsers and the like, and many Scheme systems come with packages for this. But once you go this route, coding tends to become inflexible, like in C. But as I've said elsewhere, the greatest barrier users encounter in trying to use the existing reporting tools isn't that they're written in Scheme. It's that the API they use is undocumented. That's something I hope to do something about. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Tue, 15 Nov 2011 13:30:37 + (UTC) Hendrik Boom hend...@topoi.pooq.com wrote: On Fri, 08 Jul 2011 23:33:16 -0400, John Ralls wrote: On Jul 8, 2011, at 8:15 PM, Yawar Amin wrote: If we stick with Scheme, we can take advantage of all the low-level functions that already exist for data extraction and report layout. But we can also move to a declarative model where we can have convention (re-use the report definitions as options) over configuration (build an options dialog box). Also, is it still true that we have to restart GnuCash every time we change a Scheme report, to see the changes? In any case, we need to make it dead easy for users to import and run and custom reports. Best, Yawar * I find that I’m saying ‘declarative’ a lot nowadays–I think it has to do with the fact that I’m learning Haskell :-) Fun. Two questions: Can that be easily converted into a string parser so that normal users aren't put off by the extra parentheses, and is there anything about that that works in Scheme but not in C? One of the hallmarks of Scheme is its metaprogrammability, for applications just like this. And its simple syntax promotes this. Not that it isn't possible to write string parsers and the like, and many Scheme systems come with packages for this. But once you go this route, coding tends to become inflexible, like in C. But as I've said elsewhere, the greatest barrier users encounter in trying to use the existing reporting tools isn't that they're written in Scheme. It's that the API they use is undocumented. That's something I hope to do something about. -- hendrik I believe Yawar has made a start on documenting the API at http://wiki.gnucash.org/wiki/User:Yawaramin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
Hi Hendrik, On Tue, Nov 15, 2011 at 8:30 AM, Hendrik Boom hend...@topoi.pooq.comwrote: [...] One of the hallmarks of Scheme is its metaprogrammability, for applications just like this. And its simple syntax promotes this. I've started writing a proof-of-concept declarative report ( https://github.com/yawaramin/gc-decl-reports/blob/master/hello-world.scm ). It doesn't really do anything other than populate a few options into the report options dialog box, and render a few lines of HTML. I'm trying to come up with a flexible format for pushing the accounting data around internally, so that it can filtered, sorted, and grouped, and then shown in either a tabular or graphical layout. If you want to try it out, just copy over hello-world.scm and replace your version of it (in your GnuCash install's shared reports directory) with my one. [...] But as I've said elsewhere, the greatest barrier users encounter in trying to use the existing reporting tools isn't that they're written in Scheme. It's that the API they use is undocumented. That's something I hope to do something about. Very true. Are you planning to start up a wiki page? Maybe we can pool efforts. Regards, Yawar ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
I note that Yawar's page (http://wiki.gnucash.org/wiki/User:Yawaramin) looks like a great start to documenting the reports. It is currently a ghost on the site, though; nothing apparently links to it. I believe it would be useful to link to it directly from the main wiki page (wiki.gnucash.org/wiki/GnuCash), either under Development or Documentation. What would be the preference? David - Original Message - From: Mike Evans mi...@saxicola.idps.co.uk To: Hendrik Boom hend...@topoi.pooq.com Cc: gnucash-de...@lists.gnucash.org Sent: Tuesday, November 15, 2011 5:56 AM Subject: Re: Reporting system and potentially Python On Tue, 15 Nov 2011 13:30:37 + (UTC) Hendrik Boom hend...@topoi.pooq.com wrote: On Fri, 08 Jul 2011 23:33:16 -0400, John Ralls wrote: On Jul 8, 2011, at 8:15 PM, Yawar Amin wrote: If we stick with Scheme, we can take advantage of all the low-level functions that already exist for data extraction and report layout. But we can also move to a declarative model where we can have convention (re-use the report definitions as options) over configuration (build an options dialog box). Also, is it still true that we have to restart GnuCash every time we change a Scheme report, to see the changes? In any case, we need to make it dead easy for users to import and run and custom reports. Best, Yawar * I find that I’m saying ‘declarative’ a lot nowadays–I think it has to do with the fact that I’m learning Haskell :-) Fun. Two questions: Can that be easily converted into a string parser so that normal users aren't put off by the extra parentheses, and is there anything about that that works in Scheme but not in C? One of the hallmarks of Scheme is its metaprogrammability, for applications just like this. And its simple syntax promotes this. Not that it isn't possible to write string parsers and the like, and many Scheme systems come with packages for this. But once you go this route, coding tends to become inflexible, like in C. But as I've said elsewhere, the greatest barrier users encounter in trying to use the existing reporting tools isn't that they're written in Scheme. It's that the API they use is undocumented. That's something I hope to do something about. -- hendrik I believe Yawar has made a start on documenting the API at http://wiki.gnucash.org/wiki/User:Yawaramin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python script: Gnucash
On Tue, 2011-11-15 at 12:39 +, Hendrik Boom wrote: On Fri, 07 Oct 2011 14:38:37 +1300, Andrew Ruthven wrote: Also, I'm not sure if has been mentioned here already, but myself, Micha Lenk and mostly Philipp Kern packaged up the python bindings for Debian. They're in the python-gnucash package in Debian testing unstable. If that was recent, it explains an anomaly I noticed today. The package python-gnucash has arrived in Debian wheezy according to aptitude on one of my machines, but not on another, which uses different mirrors. In any case, thanks. Early October, so possibly a broken Debian mirror? Cheers! -- Andrew Ruthven, Wellington, New Zealand At home: and...@etc.gen.nz | linux.conf.au 2012 | Come with us, Under the Stars | http://lcaunderthestars.org.au signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
Hi Derek, On 2011-11-15, at 20:43, Derek Atkins wrote: […] My preference would be to move it out of Yawar's user page onto a real page and then we could link from there. Or better yet, let's get the changes into the sources themselves so we could use sometihng like doxygen to generate the docs. I’d be happy to see my reference merged into the doxygen reference. What I was trying to do on my page was compile an API reference from the report developer’s point of view–maybe something of a broad target, but I felt that the doxygen reference kind of drops you in at the deep end and lets you figure everything out for yourself. Maybe I should see if I can point towards specific parts of the doxygen API docs for specific goals, like if you want to get an account balance, look at this, that and that function … . Another thing I’ve been wondering: do all the C APIs documented in doxygen have a one-to-one correspondence with Scheme functions, and if so what exactly is the mapping for the function names? Is it something like: xaccSomethingDoSomething ( C ) - xaccSomethingDoSomething ( Scheme ) gnc_account_find_split ( C ) - gnc-account-find-split ( Scheme ) Can I assume the Account structure ( http://svn.gnucash.org/docs/HEAD/structAccount.html ) is also transparently wrapped in Scheme? Appreciate any pointers/advice. Regards, Yawar PGP.sig Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
Hi, On Tue, November 15, 2011 10:16 pm, Yawar Amin wrote: Hi Derek, On 2011-11-15, at 20:43, Derek Atkins wrote: [ ] My preference would be to move it out of Yawar's user page onto a real page and then we could link from there. Or better yet, let's get the changes into the sources themselves so we could use sometihng like doxygen to generate the docs. Id be happy to see my reference merged into the doxygen reference. What I was trying to do on my page was compile an API reference from the report developers point of viewmaybe something of a broad target, but I felt that the doxygen reference kind of drops you in at the deep end and lets you figure everything out for yourself. Maybe I should see if I can point towards specific parts of the doxygen API docs for specific goals, like if you want to get an account balance, look at this, that and that function . Another thing Ive been wondering: do all the C APIs documented in doxygen have a one-to-one correspondence with Scheme functions, and if so what exactly is the mapping for the function names? Is it something like: xaccSomethingDoSomething ( C ) - xaccSomethingDoSomething ( Scheme ) gnc_account_find_split ( C ) - gnc-account-find-split ( Scheme ) With a few exceptions yes, this is the case. Can I assume the Account structure ( http://svn.gnucash.org/docs/HEAD/structAccount.html ) is also transparently wrapped in Scheme? This depends on your definition of 'wrapped.' In general, C structures are mapped to Scheme as opaque pointer objects, which requires using getters/setters from guile to manipulate the object. For example, you can't just do Account-desc in scheme, you need to use (xaccAccountGetDescription acc). Appreciate any pointers/advice. Regards, Yawar -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Nov 15, 2011, at 7:24 PM, Derek Atkins wrote: Hi, This depends on your definition of 'wrapped.' In general, C structures are mapped to Scheme as opaque pointer objects, which requires using getters/setters from guile to manipulate the object. For example, you can't just do Account-desc in scheme, you need to use (xaccAccountGetDescription acc). Has anyone ever tried using the gnome 2 Guile bindings and whatever is the g_object_get mechanism from Guile? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
Hi, On Tue, November 15, 2011 11:17 pm, John Ralls wrote: On Nov 15, 2011, at 7:24 PM, Derek Atkins wrote: Hi, This depends on your definition of 'wrapped.' In general, C structures are mapped to Scheme as opaque pointer objects, which requires using getters/setters from guile to manipulate the object. For example, you can't just do Account-desc in scheme, you need to use (xaccAccountGetDescription acc). Has anyone ever tried using the gnome 2 Guile bindings and whatever is the g_object_get mechanism from Guile? Probably not, because I don't think it existed in a sufficient maturity the last time we did a scheme generator migration (g-wrap - swig). What is the current maturity of these bindings? How supported are they? Are they being actively developed and maintained? What does it buy us that we don't already have? Regards, John Ralls -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Nov 15, 2011, at 9:16 PM, Derek Atkins wrote: Hi, On Tue, November 15, 2011 11:17 pm, John Ralls wrote: On Nov 15, 2011, at 7:24 PM, Derek Atkins wrote: Hi, This depends on your definition of 'wrapped.' In general, C structures are mapped to Scheme as opaque pointer objects, which requires using getters/setters from guile to manipulate the object. For example, you can't just do Account-desc in scheme, you need to use (xaccAccountGetDescription acc). Has anyone ever tried using the gnome 2 Guile bindings and whatever is the g_object_get mechanism from Guile? Probably not, because I don't think it existed in a sufficient maturity the last time we did a scheme generator migration (g-wrap - swig). What is the current maturity of these bindings? How supported are they? Are they being actively developed and maintained? What does it buy us that we don't already have? It's different from gwrap or swig (that would be gobject-introspection, which doesn't appear to be well supported, unfortunately). Rather, it is a guile library like slib or ice-9 that permits calling GObject functions without explicitly wrapping subclasses. It would let us simplify the API by e.g., not having to export explicit getters/setters, directly using GObject memory management, and so on. (FWIW, Python integration with both GObject and GObject-Introspection is both extensive and very actively developed. Were we starting now we'd have to be nuts to pick Guile over Python.) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Wed, November 16, 2011 12:40 am, John Ralls wrote: On Nov 15, 2011, at 9:16 PM, Derek Atkins wrote: Hi, On Tue, November 15, 2011 11:17 pm, John Ralls wrote: On Nov 15, 2011, at 7:24 PM, Derek Atkins wrote: Hi, This depends on your definition of 'wrapped.' In general, C structures are mapped to Scheme as opaque pointer objects, which requires using getters/setters from guile to manipulate the object. For example, you can't just do Account-desc in scheme, you need to use (xaccAccountGetDescription acc). Has anyone ever tried using the gnome 2 Guile bindings and whatever is the g_object_get mechanism from Guile? Probably not, because I don't think it existed in a sufficient maturity the last time we did a scheme generator migration (g-wrap - swig). What is the current maturity of these bindings? How supported are they? Are they being actively developed and maintained? What does it buy us that we don't already have? It's different from gwrap or swig (that would be gobject-introspection, which doesn't appear to be well supported, unfortunately). Rather, it is a guile library like slib or ice-9 that permits calling GObject functions without explicitly wrapping subclasses. It would let us simplify the API by e.g., not having to export explicit getters/setters, directly using GObject memory management, and so on. (FWIW, Python integration with both GObject and GObject-Introspection is both extensive and very actively developed. Were we starting now we'd have to be nuts to pick Guile over Python.) If we were starting now we'd probably not be using C at all (and I'd argue whether or not we should be using gnome/gtk/glib, either). But alas we have over a decade of legacy code that's had thousands of man-hours of work to get us where we are, and it would be a shame to give all that up. We can play the what if games or think about how we could have done things better if we could start over, but I feel it would be a better use of our time to look forward instead of looking back. Regards, John Ralls -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
