Re: Git Migration: github with svn access
On zaterdag 12 november 2011, Yawar Amin wrote: Hi Geert, run: git push origin :master This pushes an empty branch name (the part before the colon) from your local repo to the master branch of the origin repo, effectively deleting it. Wow, not exactly the most intuitive command choice by our great Linus. Mathematically it does make sense of course... ;) Thanks for clarifying this. I did remove the master branch for now. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
Hi Hendrik, I've felt your pain. The reasonably new python bindings are pretty helpful. The documentation is still somewhat lacking, but there are some examples, and with a bit of digging through the doxygen output (and in some cases the .h and .c files) I've been able to work out how to do what want. Cheers! On Fri, 2011-11-11 at 20:40 +, Hendrik Boom wrote: A few years ago I wanted some printouts of gnucash data formatted in a form that my wife and I could use. It was frustrating to me that the easiest way to accomplish that was to reverse-engineer the gnucash file and hand-coding a C++ program that read in the XML file and further processed it. The initial, usable, form of this program was written in C+ + in about a day. Over the years, I've embellished it in various ways, sometimes to change functionality, sometimes to accomodate subtle changes in the gnucash file format. But it seems silly to duplicate stuff that's probably in gnucash itself, and is even maintained by the gnucash implementers. And it's obvious that with the shift to a database, I should consider reading the database instead of the (probably derivative and deprecated) XML file. I had looked at the gnucash source code, but I found it much harder to understand than the XML file itself. I had asked for information about an API for understanding the internal gnucash state and was referred to some (IIRC machine-generated) documentation. It didn't help much either. In particular, it didn't make it clear what I had to do to set up the internal gnucash state that it was reporting on. While a fine API for code that ws embedded within gnucash, it didn't really suffice for external code. And looking at the guile interface for reports didn't help much either, even though I was an experienced Lisp/Scheme programmer. At the time (is this still the case?) the only usable documentation to the reporting subsystem was the source code for the reports themselves. This definitely wasn't enough. The report code was full of functions with obscure names and equally obscure significance. This isn't a problem with Scheme being a difficult language to learn. It isn't difficult. It can be learned by a competent programmer in a day or two. It's a problem with obscurity of the API the reporting subsystem provides to the Scheme programmer. In subsequent years I've wanted to produce report output in forms other than HTML, which, as far as I know, is the only one supported by gnucash. I've also wanted to write some custom data-entry software for getting data into gnucash. Now presumably, given enough time, I'd have been able to overcome these obstacles to interfacing with gnucash code the way it obviously wants to be used. But, of course, at the moments I was faced with the need to produce, there wasn't enough time. *** Now I'm not really interested in just complaining. If you'll forgive a lurker, but long-time user, from speaking up, let me at least make a proposal. Yes, I know it will probably be a lot of work, and who will be found to do it, etc. What I'd like to hear is whether there are serious flaws here, and whether it's ever likely to gain the social support to make it worthwhile to try, etc. (1) The bulk of the code for gnucash should be a shared library, whose API (s) provide all the essential functionality of gnucash. This would include code for starting up gnucash, shutting it down, reading gnucash fies, opeining the usual gnucash window, and so forth. The current work of converting ad-hoc code to use Gobjects could go a long way to making this API consistent. (2) The gnucash main program itself should operate entirely by using this library's API. Maybe (1) and (2) is how gnucash is already structured; I don't know. (3) This library would be the basis for scripting interfaces to gnucash. The API would make the gnucash library itself indifferent to the scripting language being used. Of course, the API must still be clearly documented, or it will be practically useless. Documentation in the header files may suffice. It's worth noting here that some systems that can be used as scripting languages are capable of handling the C and C++ interfacing on their own, requiring no significant footprint in the gnucash library itself. (I'm thinking specifically about Gambit C here, which is an implementation of Scheme taht can compile to C. No doubt there are others.) Other languages that different users might want to use on top of gnucash? JavaScript, Python, Ruby and Erlang have been mentioned as languages that are in the Lisp camp as far as semantics goes. Several of them are interpreted. Google has recently put out a language that's designed for programs that partly run on a server and partly on a browser. Accessing gnucash from a browser, even only read-only, could
Re: Scripting
I am 100% on-board this score. Again, finding the boots on the ground to do this is another matter altogether. An accessible and well documented API is definitely a worth while venture in my opinion. API's have the effect of not only opening up other possibilities to the programs reach, but it generally has the effect of cleaning up other parts of the application that have not been so heavily developed or carefully attended to. Question, would this API change affect the portable nature of GnuCash or would it have absolutely no effect whatsoever? I'm used to working with languages and libraries that are provided everywhere I'm programming, so I'm not used to the portable aspect of programming. Most of my work is heavily based on server-side scripting (PHP, mainly) as well as local client scripting (JS, CSS, HTML, etc.). In regards to your comment on creating some sort of front-end web-based architecture ... I have some reservations about this feature set. While I completely agree that would enhance and extend the reach of GNC, I would recommend that by default such a feature set be DISABLED. I know we're talking about stuff way in the future here, ,but just thought I'd point that out. Hope to see more support for development of an API. As I am pursuing my Accounting degree at the moment ... I unfortunately cannot partake in a big way (at least I'll tlel the wife I can't!) right at this moment. But, if I can get a sense that this community is really behind this, I'll be more than happy to drop everything and contribute. It's crazy, I've been an IT professional for over 10 years, and I'm now pursuing my Accounting degree, what an awsome mix! ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
I have gotten around this by writing a set stored procedures for the mysql backend that more or less duplicate the data generated by the Scheme-based reports. Then I created Jasper iReport templates that use those stored procedures to fill their data sets. A small Java program automates the process of refreshing the reports and exports the results in PDF and HTML. I can run all my reports without ever having to open gnucash (except to add new transactions) and the end result is a single PDF document with all the combined reports including bookmarks to each individual report. It also creates an HTML version at the same time. You could easily also export Excel spreadsheets. It works very well now, but took at least a month of tinkering and is succeptible to breakage from changes in the underlying db structure though this hasn't occurred yet. The configuration of a Java development environment for even writing the small Java program using only the neccessary Jasper libraries was very tedious. JasperReports makes really beautiful looking reports, especially the charts and is highly customizable so for me it was worth the effort. You also have to make small changes to the structure of the accounts table in order to faciliate all the other SQL queries that calculate account balances, (store more hierarchial data) and some additional indexes need to be created to speed things up (price list, etc). I make a copy of the 'production' db into a 'reporting' db and then make the alterations there. A SQL script automates all of that, then the Java program runs refreshing the report file. On 11/12/11 05:33, Andrew Ruthven wrote: Hi Hendrik, I've felt your pain. The reasonably new python bindings are pretty helpful. The documentation is still somewhat lacking, but there are some examples, and with a bit of digging through the doxygen output (and in some cases the .h and .c files) I've been able to work out how to do what want. Cheers! On Fri, 2011-11-11 at 20:40 +, Hendrik Boom wrote: A few years ago I wanted some printouts of gnucash data formatted in a form that my wife and I could use. It was frustrating to me that the easiest way to accomplish that was to reverse-engineer the gnucash file and hand-coding a C++ program that read in the XML file and further processed it. The initial, usable, form of this program was written in C+ + in about a day. Over the years, I've embellished it in various ways, sometimes to change functionality, sometimes to accomodate subtle changes in the gnucash file format. But it seems silly to duplicate stuff that's probably in gnucash itself, and is even maintained by the gnucash implementers. And it's obvious that with the shift to a database, I should consider reading the database instead of the (probably derivative and deprecated) XML file. I had looked at the gnucash source code, but I found it much harder to understand than the XML file itself. I had asked for information about an API for understanding the internal gnucash state and was referred to some (IIRC machine-generated) documentation. It didn't help much either. In particular, it didn't make it clear what I had to do to set up the internal gnucash state that it was reporting on. While a fine API for code that ws embedded within gnucash, it didn't really suffice for external code. And looking at the guile interface for reports didn't help much either, even though I was an experienced Lisp/Scheme programmer. At the time (is this still the case?) the only usable documentation to the reporting subsystem was the source code for the reports themselves. This definitely wasn't enough. The report code was full of functions with obscure names and equally obscure significance. This isn't a problem with Scheme being a difficult language to learn. It isn't difficult. It can be learned by a competent programmer in a day or two. It's a problem with obscurity of the API the reporting subsystem provides to the Scheme programmer. In subsequent years I've wanted to produce report output in forms other than HTML, which, as far as I know, is the only one supported by gnucash. I've also wanted to write some custom data-entry software for getting data into gnucash. Now presumably, given enough time, I'd have been able to overcome these obstacles to interfacing with gnucash code the way it obviously wants to be used. But, of course, at the moments I was faced with the need to produce, there wasn't enough time. *** Now I'm not really interested in just complaining. If you'll forgive a lurker, but long-time user, from speaking up, let me at least make a proposal. Yes, I know it will probably be a lot of work, and who will be found to do it, etc. What I'd like to hear is whether there are serious flaws here, and whether it's ever likely to gain the social support to make it worthwhile to try, etc. (1) The bulk of the code for gnucash should be a shared library, whose API (s) provide
Re: Scripting API
On Sat, 12 Nov 2011 11:35:46 -0500, Nicolae Crisan wrote: I am 100% on-board this score. Again, finding the boots on the ground to do this is another matter altogether. The existing Python scripting API would be a good place to start. Maybe, all told, it's all we really need, except users who are obsessive about their language preferences. If I were to try using Python and still felt I needed something more, I'd be tempted to volunteer for this. Wasn't there an attempt to devise a common run-time system for dynamic languages some time ago? If so, could that provide some scripting- language independence? This is far-off stuff, not really a gnucash issue, though. An accessible and well documented API is definitely a worth while venture in my opinion. API's have the effect of not only opening up other possibilities to the programs reach, but it generally has the effect of cleaning up other parts of the application that have not been so heavily developed or carefully attended to. Yes. Any formal review of a large code body usually finds places where it can be improved. Question, would this API change affect the portable nature of GnuCash or would it have absolutely no effect whatsoever? I'm used to working with languages and libraries that are provided everywhere I'm programming, so I'm not used to the portable aspect of programming. Most of my work is heavily based on server-side scripting (PHP, mainly) as well as local client scripting (JS, CSS, HTML, etc.). Having the API by itself should have no effect on the portability of gnucash. It would be just more code written in the same language as the rest of gnucash.But *use* of the API as a shared library would be possible only on systems that have shared libraries. And the semantics of sharing may differ substantially between operating systems. I seem to remember that Windows shared libraries share writable data, whereas Linux ones don't. Can anyone confirm this? Where things could be really nonportable is in the scripting languages that might be implemented (by us or others) on top of the API. There are probably lots of nonportable scripting languages. In regards to your comment on creating some sort of front-end web-based architecture ... I have some reservations about this feature set. While I completely agree that would enhance and extend the reach of GNC, I would recommend that by default such a feature set be DISABLED. I know we're talking about stuff way in the future here, ,but just thought I'd point that out. I wouldn't want gnucash to provide a front-end web-based architecture at all. That's strictly for people who want to put financial information on the web. Let them do the web programming to suit their aesthetic, practical, and security needs as part of their website implementation. All that the API would do is give them the hooks they need. If I did anything like this at home, I'd restrict all access to my LAN, for a starter. Now I have been producing XML reports with CSS. But they're not connected to my web server at all. I leave them as files on the hard drive, accessible only to local users who can use file:/// URLs. Occasionally I produce updated ones. Hope to see more support for development of an API. As I am pursuing my Accounting degree at the moment ... I unfortunately cannot partake in a big way (at least I'll tlel the wife I can't!) right at this moment. But, if I can get a sense that this community is really behind this, I'll be more than happy to drop everything and contribute. It's crazy, I've been an IT professional for over 10 years, and I'm now pursuing my Accounting degree, what an awsome mix! IT and Accounting would indeed be good skills combination. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
