Re: [GNC-dev] Scripting Gnucash actions without UI
I've seen several questions on the user list with respect to that very use case as an SX variable. Regards, Adrien On 10/12/23 9:26 PM, Christopher Lam wrote: Other ideas are possible: determine the balance of an account at a particular date ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Scripting Gnucash actions without UI
Thanks Liz... With the full power of scheme (or python) it will be relatively straightforward to customise these calculations. There's an example script in the GitHub pull request, and it does interact via command line to input some transaction details, summarises the transaction and asks confirmation before committing the change. It does require some knowledge of programming and learning the gnucash API, but won't require building the full gnucash code. Other ideas are possible: determine the balance of an account at a particular date, download transactional, business or pricing data from an external source or any format (json,TSV), submit anything to an external recipient, etc. Implementing such a change effectively raises the scheme code from being a report-only mechanism to unlocking full scripting, and also unlock python scripting to more users. On Fri, 13 Oct 2023, 5:52 am Liz, wrote: > On Sun, 8 Oct 2023 17:51:40 +0800 > Christopher Lam wrote: > > > It would thus be useful to know the types of tasks that users wish to > > automate. I'll start: > > > > Every quarter, I personally tally up the GST account balances, which > > allows me to submit to the tax office. I currently use the "Income > > and GST Statement" report for tallying. I will also create some > > transactions which will offset the GST accounts back to zero. This > > could easily be automated. > > My GST is more complex > with two different vehicles, company tax and the income tax to be > reckoned as well. > Vehicles only have a proportion of the GST to be put in the > calculations. > > I attach my Scheduled transaction just for the amounts to be given to > the tax office. > There are also a series of scheduled transactions for the splits in the > GST for vehicle expenses. > > Liz > ___ > 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: [GNC-dev] Scripting Gnucash actions without UI
On Sun, 8 Oct 2023 17:51:40 +0800 Christopher Lam wrote: > It would thus be useful to know the types of tasks that users wish to > automate. I'll start: > > Every quarter, I personally tally up the GST account balances, which > allows me to submit to the tax office. I currently use the "Income > and GST Statement" report for tallying. I will also create some > transactions which will offset the GST accounts back to zero. This > could easily be automated. My GST is more complex with two different vehicles, company tax and the income tax to be reckoned as well. Vehicles only have a proportion of the GST to be put in the calculations. I attach my Scheduled transaction just for the amounts to be given to the tax office. There are also a series of scheduled transactions for the splits in the GST for vehicle expenses. Liz ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Scripting Gnucash actions without UI
Christopher, Did you mean to post this to the gnucash-users list so the "Dear Users" can comment ? Cheers David H. On Sun, 8 Oct 2023 at 19:52, Christopher Lam wrote: > Dear Users > > I'm aware there's demand for automated scripting Gnucash activity such as > entering transactions with custom formulas more complex than the SX > facility will allow, determining end-of-quarter calculations etc. > > There's a pending PR at https://github.com/Gnucash/gnucash/pull/1794 which > will unlock it (with a scheme script... or a python script if someone > proficient can code it), and *will* allow the above, and* can* offer some > interactivity (e.g. "please enter the transaction description" -- see the > PR for such an example),* and also* potentially unlock other UI toolkits. > From my understanding this is a facility that the original GnuCash code > from 1997 or so offered. > > We are not willing to provide custom-built solutions for users (not even > with money offers); and I do not think it's a good idea to add custom > scripts into the code. Users could share the scripts among themselves at > their own maintenance risk. However, if users are needing help for such > tasks, we can consider augmenting the software with api calls which can > assist. > > It would thus be useful to know the types of tasks that users wish to > automate. I'll start: > > Every quarter, I personally tally up the GST account balances, which allows > me to submit to the tax office. I currently use the "Income and GST > Statement" report for tallying. I will also create some transactions which > will offset the GST accounts back to zero. This could easily be automated. > ___ > 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
[GNC-dev] Scripting Gnucash actions without UI
Dear Users I'm aware there's demand for automated scripting Gnucash activity such as entering transactions with custom formulas more complex than the SX facility will allow, determining end-of-quarter calculations etc. There's a pending PR at https://github.com/Gnucash/gnucash/pull/1794 which will unlock it (with a scheme script... or a python script if someone proficient can code it), and *will* allow the above, and* can* offer some interactivity (e.g. "please enter the transaction description" -- see the PR for such an example),* and also* potentially unlock other UI toolkits. >From my understanding this is a facility that the original GnuCash code from 1997 or so offered. We are not willing to provide custom-built solutions for users (not even with money offers); and I do not think it's a good idea to add custom scripts into the code. Users could share the scripts among themselves at their own maintenance risk. However, if users are needing help for such tasks, we can consider augmenting the software with api calls which can assist. It would thus be useful to know the types of tasks that users wish to automate. I'll start: Every quarter, I personally tally up the GST account balances, which allows me to submit to the tax office. I currently use the "Income and GST Statement" report for tallying. I will also create some transactions which will offset the GST accounts back to zero. This could easily be automated. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
Derek Atkins wrote Hendrik Boom lt;hendrik@.pooqgt; writes: I hadn't known about the python bindings. First, it would make sense for me to try to use the python bindings to see if I can do what I need, writing a kind of a diary of what I discover I need to know and producing bits of preliminary documentation as I go. How does collaboration work with documentation? Is it a wiki? or svn access? or something else? It depends. There may be some docs in the wiki, but the primary docs are probably in the pythondoc sources, which means they are in SVN. For now the best way would be to work with the active devs and supply documentation patches against svn trunk (or git's trunk, if that's how you roll). -- hendrik -derek So according to the wiki[1] should we follow directions for Non-Committers or Committers? I would think the best option would be to clone and then submit pull requests but I'm not sure if things are setup to work that way. [1] http://wiki.gnucash.org/wiki/Git -- View this message in context: http://gnucash.1415818.n4.nabble.com/Scripting-tp4032648p4656113.html Sent from the GnuCash - Dev mailing list archive at Nabble.com. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
On Aug 10, 2012, at 5:22 AM, reubano reub...@gmail.com wrote: So according to the wiki[1] should we follow directions for Non-Committers or Committers? I would think the best option would be to clone and then submit pull requests but I'm not sure if things are setup to work that way. [1] http://wiki.gnucash.org/wiki/Git Committers are devs with commit privs in the subversion repo, so you should use the non-committers instructions. Even though the Author tag gets stripped by subversion, please use git format-patch to create your patches so that we get your commit messages. It's better to open bugs and attach your patches to them rather than to post them here. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
On 10-08-12 15:54, John Ralls wrote: On Aug 10, 2012, at 5:22 AM, reubano reub...@gmail.com wrote: So according to the wiki[1] should we follow directions for Non-Committers or Committers? I would think the best option would be to clone and then submit pull requests but I'm not sure if things are setup to work that way. [1] http://wiki.gnucash.org/wiki/Git ... Even though the Author tag gets stripped by subversion, please use git format-patch to create your patches so that we get your commit messages. ... And particularly because the Author tag gets stripped by subversion, I'd recommend adding a line Patch by xyz directly in the comment. That way, we still know the original author even in svn. I try to add this line every time I apply a patch by someone else, though I sometimes forget. If it's in the comment already, there's no risk of forgetting it. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
On Aug 10, 2012, at 8:34 AM, Geert Janssens janssens-ge...@telenet.be wrote: On 10-08-12 15:54, John Ralls wrote: On Aug 10, 2012, at 5:22 AM, reubano reub...@gmail.com wrote: So according to the wiki[1] should we follow directions for Non-Committers or Committers? I would think the best option would be to clone and then submit pull requests but I'm not sure if things are setup to work that way. [1] http://wiki.gnucash.org/wiki/Git ... Even though the Author tag gets stripped by subversion, please use git format-patch to create your patches so that we get your commit messages. ... And particularly because the Author tag gets stripped by subversion, I'd recommend adding a line Patch by xyz directly in the comment. That way, we still know the original author even in svn. I try to add this line every time I apply a patch by someone else, though I sometimes forget. If it's in the comment already, there's no risk of forgetting it. Good point. I've added a section to the Git wiki page with some guidance for preparing and submitting patches. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
Hendrik Boom hend...@topoi.pooq.com writes: On Thu, 01 Dec 2011 11:22:34 -0500, Derek Atkins wrote: This would imply you do not have doxygen installed. I didn't. I do now. It still doesn't work, failing in the same way. No time to investigate now. I'll look into it further tonight. Maybe there's a configure parameter I forgot. No, you will need to re-run configure after installing doxygen. -- hendrik -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Wed, 30 Nov 2011 15:12:31 -0500, Derek Atkins wrote: Hi, The API docs are generated via doxygen. You can generate them yourself using make docs. The sourcesof the API docs are spread out through the source tree. But when I'm in the top directory of the source tree (the same placs I originally executed ./configure and the general make commands), when I execute make docs it tells me make: *** No rule to make target `docs'. Stop. Until further notice, I'll look through the source tree for Makefiles that do have a docs target. AH! There's a doc target. Would that be the one you mean? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Thu, 01 Dec 2011 15:16:53 +, Hendrik Boom wrote: On Wed, 30 Nov 2011 21:13:58 +, Yawar Amin wrote: Hi Hendrik, The user documentation is in the gnucash-docs repository ( http://svn.gnucash.org/trac/browser/gnucash-docs). Evidently there's still something I don't know, Sorry to waste your time. I found it: svn checkout http://code.gnucash.org/repo/gnucash-docs/trunk gnucash-docs -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Dec 1, 2011, at 7:16 AM, Hendrik Boom wrote: Ah! I see. This is where it's all been processed and presented as nice, neat web pages. What's the verbiage I need to get the user-documentation source tree? Or is that in some corner of gnucash source tree I haven't looked yet? The correct URI for checkout is on http://www.gnucash.org/docs.phtml about 2/3 of the way down. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Thu, 01 Dec 2011 15:16:05 +, Hendrik Boom wrote: On Wed, 30 Nov 2011 15:12:31 -0500, Derek Atkins wrote: Hi, The API docs are generated via doxygen. You can generate them yourself using make docs. The sourcesof the API docs are spread out through the source tree. But when I'm in the top directory of the source tree (the same placs I originally executed ./configure and the general make commands), when I execute make docs it tells me make: *** No rule to make target `docs'. Stop. Until further notice, I'll look through the source tree for Makefiles that do have a docs target. AH! There's a doc target. Would that be the one you mean? Possibly not, because make doc tells me that doxygen.cfg is not found. hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ make doc make -C src/doc doc make[1]: Entering directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' rm -f doxygen.cfg.tmp sed doxygen.cfg.in doxygen.cfg.tmp \ -e 's:@-top_srcdir-@:../..:g; s:@-VERSION-@:2.4.99:g' mv doxygen.cfg.tmp doxygen.cfg doc: /home/hendrik/dv/gnucash/workspace/gnucash/src/doc distdir: rm -rf html refman.pdf doxygen.cfg /bin/bash: doxygen.cfg: command not found make[1]: *** [doc] Error 127 make[1]: Leaving directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' make: *** [doc] Error 2 hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
Hendrik Boom hend...@topoi.pooq.com writes: On Thu, 01 Dec 2011 15:16:05 +, Hendrik Boom wrote: On Wed, 30 Nov 2011 15:12:31 -0500, Derek Atkins wrote: Hi, The API docs are generated via doxygen. You can generate them yourself using make docs. The sourcesof the API docs are spread out through the source tree. But when I'm in the top directory of the source tree (the same placs I originally executed ./configure and the general make commands), when I execute make docs it tells me make: *** No rule to make target `docs'. Stop. Until further notice, I'll look through the source tree for Makefiles that do have a docs target. AH! There's a doc target. Would that be the one you mean? Yes.. Possibly not, because make doc tells me that doxygen.cfg is not found. Do you have doxygen installed? hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ make doc make -C src/doc doc make[1]: Entering directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' rm -f doxygen.cfg.tmp sed doxygen.cfg.in doxygen.cfg.tmp \ -e 's:@-top_srcdir-@:../..:g; s:@-VERSION-@:2.4.99:g' mv doxygen.cfg.tmp doxygen.cfg doc: /home/hendrik/dv/gnucash/workspace/gnucash/src/doc distdir: rm -rf html refman.pdf doxygen.cfg /bin/bash: doxygen.cfg: command not found This would imply you do not have doxygen installed. make[1]: *** [doc] Error 127 make[1]: Leaving directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' make: *** [doc] Error 2 hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ -- hendrik -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Thu, 01 Dec 2011 11:22:34 -0500, Derek Atkins wrote: This would imply you do not have doxygen installed. I didn't. I do now. It still doesn't work, failing in the same way. No time to investigate now. I'll look into it further tonight. Maybe there's a configure parameter I forgot. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On donderdag 1 december 2011, Hendrik Boom wrote: On Thu, 01 Dec 2011 15:16:05 +, Hendrik Boom wrote: On Wed, 30 Nov 2011 15:12:31 -0500, Derek Atkins wrote: Hi, The API docs are generated via doxygen. You can generate them yourself using make docs. The sourcesof the API docs are spread out through the source tree. But when I'm in the top directory of the source tree (the same placs I originally executed ./configure and the general make commands), when I execute make docs it tells me make: *** No rule to make target `docs'. Stop. Until further notice, I'll look through the source tree for Makefiles that do have a docs target. AH! There's a doc target. Would that be the one you mean? Possibly not, because make doc tells me that doxygen.cfg is not found. hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ make doc make -C src/doc doc make[1]: Entering directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' rm -f doxygen.cfg.tmp sed doxygen.cfg.in doxygen.cfg.tmp \ -e 's:@-top_srcdir-@:../..:g; s:@-VERSION-@:2.4.99:g' mv doxygen.cfg.tmp doxygen.cfg doc: /home/hendrik/dv/gnucash/workspace/gnucash/src/doc distdir: rm -rf html refman.pdf doxygen.cfg /bin/bash: doxygen.cfg: command not found make[1]: *** [doc] Error 127 make[1]: Leaving directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' make: *** [doc] Error 2 hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ -- hendrik Have you got doxigen installed on your system ? And what happens if you add --enable-doxygen to your configure command ? It's been a while since I built these docs myself, so I'm not exactly sure what the proper incantation is. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Scripting documentation
OK. I've managed to compile gnucash and get it to pass its checks (except for the database back end, which I had excluded. Now I'm ready to start prowling around looking for scripting API to document. Could someone tell me: Is there any existing API documentation, either in the source tree (which now has lots of automatically generated files) or on the wiki (please let me know where -- it's a huge source tree). Where are the source codes for the scripting API -- both the X side and the Python/Scheme side(s). So far I haven't found the rather extensive user documentation I'm used to seeing as a longtime gnucash user. Is it in the source tree too? Or somewhere else. Do I have to use a different make target to gennerate it? Anything else that might be useful? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
Hi, On Wed, November 30, 2011 3:06 pm, Hendrik Boom wrote: OK. I've managed to compile gnucash and get it to pass its checks (except for the database back end, which I had excluded. Now I'm ready to start prowling around looking for scripting API to document. Could someone tell me: Is there any existing API documentation, either in the source tree (which now has lots of automatically generated files) or on the wiki (please let me know where -- it's a huge source tree). Where are the source codes for the scripting API -- both the X side and the Python/Scheme side(s). So far I haven't found the rather extensive user documentation I'm used to seeing as a longtime gnucash user. Is it in the source tree too? Or somewhere else. Do I have to use a different make target to gennerate it? Anything else that might be useful? The API docs are generated via doxygen. You can generate them yourself using make docs. The sourcesof the API docs are spread out through the source tree. -- hendrik -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: Scripting documentation
Hi Hendrik, On Wed, Nov 30, 2011 at 8:06 PM, Hendrik Boom hend...@topoi.pooq.comwrote: [...] So far I haven't found the rather extensive user documentation I'm used to seeing as a longtime gnucash user. Is it in the source tree too? Or somewhere else. Do I have to use a different make target to gennerate it? The user documentation is in the gnucash-docs repository ( http://svn.gnucash.org/trac/browser/gnucash-docs). Regards, Yawar ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
Christian Stimming christ...@cstimming.de writes: Is there still a way, other than as a report, to run a scheme script that uses gnucash's API? Sorry, I don't know. For python it has been described a little bit more (in the optional/python directory), and that's also what I would suggest to use. Yes:gnucash-env guile -l file.scm Best Regards, Christian Stimming -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
On Sat, 12 Nov 2011 12:55:08 -0500, Derek Atkins wrote: Hi, Hendrik Boom hend...@topoi.pooq.com writes: [snip] (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. This is already the case.. However it's not a single Shared Library. It's a ton of shared libraries. Good. (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. This is also the case. The Scheme and Python bindings are based on the C APIs by wrapping using SWIG. Good. By the Scheme bindings do you mean the hooks for the report- generating guile code? [snip] But now I'm getting far in advance of myself. I'm currently arguing only for a clear, conprehensive, documented API that others could use to build their own edifices on top of gnucash. That would open the gates to all kinds of unexpected collaborations. I agree wholeheartedly. Are you willing to help document the APIs that exist? Yes, in principle. I hadn't known about the python bindings. First, it would make sense for me to try to use the python bindings to see if I can do what I need, writing a kind of a diary of what I discover I need to know and producing bits of preliminary documentation as I go. How does collaboration work with documentation? Is it a wiki? or svn access? or something else? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
Hi Hendrik, I think the wiki is the best place to start. For example I've been compiling a Scheme API reference on my user page: http://wiki.gnucash.org/wiki/User:Yawaramin You can also easily create a dedicated page once you sign up for a wiki account there. Btw, the Scheme bindings do more than generate reports. My impression is you can use them to make GnuCash do pretty much anything. Regards, Yawar Hendrik Boom hend...@topoi.pooq.com wrote: On Sat, 12 Nov 2011 12:55:08 -0500, Derek Atkins wrote: Hi, Hendrik Boom hend...@topoi.pooq.com writes: [snip] (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. This is already the case.. However it's not a single Shared Library. It's a ton of shared libraries. Good. (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. This is also the case. The Scheme and Python bindings are based on the C APIs by wrapping using SWIG. Good. By the Scheme bindings do you mean the hooks for the report- generating guile code? [snip] But now I'm getting far in advance of myself. I'm currently arguing only for a clear, conprehensive, documented API that others could use to build their own edifices on top of gnucash. That would open the gates to all kinds of unexpected collaborations. I agree wholeheartedly. Are you willing to help document the APIs that exist? Yes, in principle. I hadn't known about the python bindings. First, it would make sense for me to try to use the python bindings to see if I can do what I need, writing a kind of a diary of what I discover I need to know and producing bits of preliminary documentation as I go. How does collaboration work with documentation? Is it a wiki? or svn access? or something else? -- hendrik ___ 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: Scripting
Hendrik Boom hend...@topoi.pooq.com writes: (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. This is also the case. The Scheme and Python bindings are based on the C APIs by wrapping using SWIG. Good. By the Scheme bindings do you mean the hooks for the report- generating guile code? Amongst others, yes. The reports use the scheme bindings, but there are more APIs wrapped than just those used by the reports. For a while back in the 1.x days the gnucash application was actually a guile script. [snip] But now I'm getting far in advance of myself. I'm currently arguing only for a clear, conprehensive, documented API that others could use to build their own edifices on top of gnucash. That would open the gates to all kinds of unexpected collaborations. I agree wholeheartedly. Are you willing to help document the APIs that exist? Yes, in principle. I hadn't known about the python bindings. First, it would make sense for me to try to use the python bindings to see if I can do what I need, writing a kind of a diary of what I discover I need to know and producing bits of preliminary documentation as I go. How does collaboration work with documentation? Is it a wiki? or svn access? or something else? It depends. There may be some docs in the wiki, but the primary docs are probably in the pythondoc sources, which means they are in SVN. For now the best way would be to work with the active devs and supply documentation patches against svn trunk (or git's trunk, if that's how you roll). -- hendrik -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ 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
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 be useful. But now I'm getting far in advance of myself. I'm currently arguing only for a clear, conprehensive, documented API that others could use to build their own edifices on top of gnucash. That would open the gates to all kinds of unexpected collaborations. -- hendrik ___ 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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
Scripting
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 be useful. But now I'm getting far in advance of myself. I'm currently arguing only for a clear, conprehensive, documented API that others could use to build their own edifices on top of gnucash. That would open the gates to all kinds of unexpected collaborations. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GSoC Proposal] Python scripting and reporting project
Hi, I have made modifications, added some new features, edited the code migration part. Below is not the whole proposal, only the goals and their detailed description. Goals: 1] Develop python scripts in gnucash to provide a python framework. To achieve the above goal, my aim is to focus on and enhance the current reporting system 2] Develop python scripts for importing/exporting customer information 3] Develop python scripts to enhance the budgeting system by adding graphical features 4] Develop python scripts to enhance the future scheduled transaction reporting 5] Export the report system, which defines modules that provide functionalities for report generation, to python 6] Develop more ideas to utilise the powerful python scripting to enhance the reporting system. Detailed description: -:- The aim of this project is to develop a python framework for gnucash which currently uses uncommon scheme scripting. A python scripting framework will enable a large set of developers, well versed with python than with scheme to enhance or to alter the system as per their requirements. Also migrating to python will provide a large set of capable functionalities for gnucash. Major part of the scripting work is in the reporting section. My goal is to add python features to the current prototype and to create a strong framework for further development. -:- The initial goals are to add new user visible features, scripted in python. To start off, aim will be to provide options for importing/exporting the business contacts of the user. This will involve using the python library modules for import/export of data to/from csv format. -:- The next goal is to enhance the current budget system. Aim is to add more graphical features to display budget reports. The current budget summary displays simple data, budget values and actual values, here the idea is to add horizontal bar-graphs to display them. I.e. display bar-graphs of budgets of individual accounts along with the bar-graphs of actual values. This will graphically give the user an idea of where and by how much margin the budget and actual values vary. -:- The next goal is to add the feature of forecasting of the accounts. User will be provided with and option to see the forecasts of the account balances based on his scheduled transactions list. My aim is to provide him with a graphs of forecast values of his account balances of his chosen account according to his chosen timeline. These will involve using the python graph plotting libraries. Currently gnucash just has the feature of a simple summary over a period. The graphical forecasting will enable the user to actually get an understanding of his future ups and downs in finances. -:- Once these features are implemented, a small framework of user features using python scripts is ready. The next goal will be to migrate the report-system to python. This will define modules that will provide interface for all the report generation scripts. This will involve writing python scripts for report tables, bar-graphs, pie-charts, style-sheets and other related formats. The vast python module library will enable the reporting to include wide range of features. These scripts will provide functions that will be used by the report generating scripts to display report data as desired. Once this goal is achieved, a python framework for writing any python report scripts will be ready. All the reporting scripts can use the functionalities provided by this framework to create data and graphical reports. * Once this report system is ported to python, test it thoroughly for proper loading and working of modules. Deliverables: 1] A functionality of importing/exporting customer data in the business report system. 2] A enhanced budget reporting system. 3] A proper tested and working account forecasting system. 4] A proper tested and working report system which will facilitate python framework for report generation. *Need some suggestions for improvements* Thank you for reading. Regards, Rohan Kulkarni IM, GTalk: kulkarni.roha...@gmail.com IRC Nick: ahknor/rohan_k ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GSoC Proposal] Python scripting and reporting project
Hello, I have drafted a proposal for the above mentioned project. I have come up with this proposal based on what I could research and infer. There may be shortcomings in the content, its my humble request to comment on this for further improvement. Initially, I have listed down the goals of the project which involve steps needed to integrate python scripting and some functionalities that I want to add to the current prototype. Below that, I have described in detail about each point, what exactly I aim to achieve. Goals: 1] Develop python scripts in gnucash to provide a python framework. To achieve the above goal, my aim is to focus on and enhance the current reporting system 2] Export the report-system, which defines modules that provide functionalities for report generation, to python 3] Take up the business reports section, enable all the reports in this section to be generated by python scripts 4] Enable the customer information in this section to be imported/exported 5] Take up the standard reports section, export them to python 6] Enhance the budget generating system, add more graphical reports 7] Develop more ideas to utilise the powerful python scripting to enhance the reporting system. Detailed description: -:- The aim of this project is to develop a python framework for gnucash which currently uses uncommon scheme scripting. A python scripting framework will enable a large set of developers, well versed with python than with scheme to enhance or to alter the system as per their requirements. Also migrating to python will provide a large set of capable functionalities for gnucash. Major part of the scripting work is in the reporting section. My goal is to provide a python framework by exporting major parts of it to python. This framework will be useful for development of the whole report generating system to gradually integrate with python. -:- The initial goal is migrate the report-system to python. This will define modules that will provide interface for all the report generation scripts. This will involve writing python scripts for report tables, bar-graphs, pie-charts, style-sheets and other related formats. The vast python module library will enable the reporting to include wide range of features. These scripts will provide functions that will be used by the report generating scripts to display report data as desired. Once this goal is achieved a python framework for writing report scripts in will be ready. All the reporting scripts can use the functionalities provided by this framework to create data and graphical reports. * Once this report-system is ported to python, test it thoroughly for proper loading and working of modules. -:- The next goal will be to export the business scripts. It will involve writing python scripts, using the python defined functions in report-system to generate reports. It will enable business reports, customer, tax-invoices and related reports to work with the python modules. Here a sub goal is to enable the feature of importing/exporting customer information. I.e. to provide a functionality to import/export customer information in csv format. It will enable users to migrate their customer data from other sources(thunderbird/google contacts etc.) to gnucash and vice-versa. * Test this section for proper functioning. -:- The next goal will be to take up the standard scripts. Though the aim is to migrate all of it to python, initial focus will be on the budget part. Here a sub goal is to enhance the budget reporting. Aim is to add more graphical features to display budget reports. The current budget summary displays simple data, budget values and actual values, here the idea is to add horizontal bar-graphs to display them. I.e. display bar-graphs of budgets of individual accounts along with the bar-graphs of actual values. This will graphically give the user an idea of where and by how much margin the budget and actual values vary. After this, depending on the amount of time available, rest of the reports will be migrated. * Test this section for proper functioning. -:- During the development of python scripting, always, aim will be to make use of the vast python library for enhancing gnucash functionalities with the python framework. Deliverables: 1] A proper tested and working report-system which will facilitate python framework for report generation. 2] A proper tested and working business report generation system. 3] A functionality of importing/exporting customer data in the business report system. 4] A proper tested and working standard report generation system, which will have an enhanced budget reporting. Timeline: -:- The initial phase will be to get familiar with the report-system. Understand the module definition/initialisation for the report infrastructure. Discuss about how to get started with development of code
Re: [GSoC Proposal] Python scripting and reporting project
Dear Rohan, thanks for your detailed proposal about python scripting code. In general, your research is well-thought and goes into plenty of detail about how to migrate scheme code to python code. However, my statement from my previous email http://lists.gnucash.org/pipermail/gnucash-devel/2011-April/031642.html is still valid: Your goal is still rather vague in terms of user-visible new features, at least in the first half of your plan. As I said before, we recommend not to plan to migrate all of the current Scheme reporting code into another language, Python in this case. Not even all of business reports, because even that will easily get you lost in the whole collection of various reports there are. Instead, you should still modify and rearrange your application so that your python scripting code will enable new user-visible features *early* in your project. For example, the import/export customer data could be one such user-visible new feature. The improved budgeting reports could just as well be such an early user-visible new feature. My point is that you should first try to implement something new and user-visible very early in your project, and only as a next step work on migrating existing features from language x to language y. This will immediately lead to a better user-focused design of the framework parts that are still missing, and ultimately to a better deliverable and application. Regards, Christian Am Mittwoch, 6. April 2011 schrieb Rohan Kulkarni: Hello, I have drafted a proposal for the above mentioned project. I have come up with this proposal based on what I could research and infer. There may be shortcomings in the content, its my humble request to comment on this for further improvement. Initially, I have listed down the goals of the project which involve steps needed to integrate python scripting and some functionalities that I want to add to the current prototype. Below that, I have described in detail about each point, what exactly I aim to achieve. Goals: 1] Develop python scripts in gnucash to provide a python framework. To achieve the above goal, my aim is to focus on and enhance the current reporting system 2] Export the report-system, which defines modules that provide functionalities for report generation, to python 3] Take up the business reports section, enable all the reports in this section to be generated by python scripts 4] Enable the customer information in this section to be imported/exported 5] Take up the standard reports section, export them to python 6] Enhance the budget generating system, add more graphical reports 7] Develop more ideas to utilise the powerful python scripting to enhance the reporting system. Detailed description: -:- The aim of this project is to develop a python framework for gnucash which currently uses uncommon scheme scripting. A python scripting framework will enable a large set of developers, well versed with python than with scheme to enhance or to alter the system as per their requirements. Also migrating to python will provide a large set of capable functionalities for gnucash. Major part of the scripting work is in the reporting section. My goal is to provide a python framework by exporting major parts of it to python. This framework will be useful for development of the whole report generating system to gradually integrate with python. -:- The initial goal is migrate the report-system to python. This will define modules that will provide interface for all the report generation scripts. This will involve writing python scripts for report tables, bar-graphs, pie-charts, style-sheets and other related formats. The vast python module library will enable the reporting to include wide range of features. These scripts will provide functions that will be used by the report generating scripts to display report data as desired. Once this goal is achieved a python framework for writing report scripts in will be ready. All the reporting scripts can use the functionalities provided by this framework to create data and graphical reports. * Once this report-system is ported to python, test it thoroughly for proper loading and working of modules. -:- The next goal will be to export the business scripts. It will involve writing python scripts, using the python defined functions in report-system to generate reports. It will enable business reports, customer, tax-invoices and related reports to work with the python modules. Here a sub goal is to enable the feature of importing/exporting customer information. I.e. to provide a functionality to import/export customer information in csv format. It will enable users to migrate their customer data from other sources(thunderbird/google contacts etc.) to gnucash and vice-versa. * Test this section for proper functioning. -:- The next goal will be to take up
Re: Initial Draft application for Python Scripting Engine
Dear Rahul, Zitat von Rahul Gaur rahul@gmail.com: I've made some corrections to my application.Is it better now ?what more should I add ..? thanks for the additions. However, the basic problem in your application has not received much of an improvement: The main parts of your text are just some generic programming project description, but not at all specific to gnucash. Hence, from your applications it is not yet obvious whether you already have spent time and thinking on how your goals can be implement *specifically* in the gnucash project. I mean, from our point of view you can start working with gnucash nevertheless, but the GSoC staff that takes the final decision on your application might want to see further evidence that you've already got to know the gnucash project specifically. Also, the sentence reporting engine,which primarily involves migrating all of the current reporting scripts to python is grossly underestimating the time of migrating all reports and hence is rather unrealistic. Instead, you should *now* decide on one or two specific things that you will want to migrate to python or implement in python. User-visible things. Apart from this I've thinking of introducing a feature so that generated reports can directly be exported to some cloud service so that user have the access to reports even on a report system.If any thing similar to this is in the loop please let me know. Currently nobody is working on anything similar. Your idea is good. Maybe you should focus your application more on this particular idea and feature. I believe this will result in a better application than discussing the abstract notion of working on python engine in gnucash. Incidentally, your upload feature (either for the data file, or for generated reports, or both) might be implemented in python as well, once you've added some minor missing parts to the python module in gnucash. Hence, probably your application should emphasize your feature idea as the main goal, and mention the python engine only as a way to implement your main goal. I think this will make your application better. Best Regards, Christian *Basic Information* Student name:Rahul Gaur Location: Meerut City , UP ,India, Home Town :New Delhi ,India Email:rahul@gmail.com Instant messaging contact details (Skype or similar):iamaregee/iamaregee2 on IRC (irc.ubuntu.com) Phone : +91-8755426793 *Background/Programming Information:* I've experience of building GNU cash from source via SVN on a linux system.A few years ago,I learned C++ and Java as a part of my School curriculum.While this is my first year in college ,Now I am pursuing Bachelors in Engineering and my Major is in Computer Science.So I am learning C and Python here in College.By the time GsoC 2011 starts ,I will be done with my end semester exams and equiped with skills to work full time on coding,so I wan't to do some good project in order to strengthen my foundations in understanding of Sofware Systems. *What project in GnuCash would you like to work on?* I would Like to work on Python reporting and Scripting engine for Gnu cash over my summer vacations. *What will be the result of your project :* Upon the successful development of the scripting engine ,primarily all the current reporting scripts will be migrated to python plus it will open the possibilites of implementing various new financial reports as python has a vast accounting library support.For instance libraries like matplotlib, PyCompta can be used to genrate graphs and reports in xml,html and pdf formats.While in the long run,python being a more common scripting language,it will be easier for developers to contribute to the code and improve the efficiency. *How do you propose to solve the problem(s) posed in the project you'd like to work on?* *Project Schedule :* While I plan to follow the description given in the idea of the proposal.I've already familiarised my self with the working of GNU cash (v 2.4.4 SVNr20419).I took a brief idea of sample python scripts.As I've already stated , I've my University exams from 8th to 30thof May ,so during this period I will be in touch with the GNUCash community through emails.During the time before exams ,I hope to : - Get to know the mentor and other community members. - Going through Devloper Docs. - Understand working of the reporting engine. - Brainstorm plans with the community. After I am Done with my exams , I plan to Procede as follows : *Program time-line :* - To create a more accurate programing timetable. - Initial step would be to work on already included python patch in order build the scripting engine which interacts with gnu cash and do the functions like accessing the entries in the Database.This will be followed by working on the reporting engine,which primarily involves migrating all of the current reporting scripts
Re: Initial Draft application for Python Scripting Engine
Dear Christian, I've made some corrections to my application.Is it better now ?what more should I add ..? Apart from this I've thinking of introducing a feature so that generated reports can directly be exported to some cloud service so that user have the access to reports even on a report system.If any thing similar to this is in the loop please let me know. *Basic Information* Student name:Rahul Gaur Location: Meerut City , UP ,India, Home Town :New Delhi ,India Email:rahul@gmail.com Instant messaging contact details (Skype or similar):iamaregee/iamaregee2 on IRC (irc.ubuntu.com) Phone : +91-8755426793 *Background/Programming Information:* I've experience of building GNU cash from source via SVN on a linux system.A few years ago,I learned C++ and Java as a part of my School curriculum.While this is my first year in college ,Now I am pursuing Bachelors in Engineering and my Major is in Computer Science.So I am learning C and Python here in College.By the time GsoC 2011 starts ,I will be done with my end semester exams and equiped with skills to work full time on coding,so I wan't to do some good project in order to strengthen my foundations in understanding of Sofware Systems. *What project in GnuCash would you like to work on?* I would Like to work on Python reporting and Scripting engine for Gnu cash over my summer vacations. *What will be the result of your project :* Upon the successful development of the scripting engine ,primarily all the current reporting scripts will be migrated to python plus it will open the possibilites of implementing various new financial reports as python has a vast accounting library support.For instance libraries like matplotlib, PyCompta can be used to genrate graphs and reports in xml,html and pdf formats.While in the long run,python being a more common scripting language,it will be easier for developers to contribute to the code and improve the efficiency. *How do you propose to solve the problem(s) posed in the project you'd like to work on?* *Project Schedule :* While I plan to follow the description given in the idea of the proposal.I've already familiarised my self with the working of GNU cash (v 2.4.4 SVNr20419).I took a brief idea of sample python scripts.As I've already stated , I've my University exams from 8th to 30thof May ,so during this period I will be in touch with the GNUCash community through emails.During the time before exams ,I hope to : - Get to know the mentor and other community members. - Going through Devloper Docs. - Understand working of the reporting engine. - Brainstorm plans with the community. After I am Done with my exams , I plan to Procede as follows : *Program time-line :* - To create a more accurate programing timetable. - Initial step would be to work on already included python patch in order build the scripting engine which interacts with gnu cash and do the functions like accessing the entries in the Database.This will be followed by working on the reporting engine,which primarily involves migrating all of the current reporting scripts to python.This milestone will be done with implementing various python libraries like quantalib,matplotlib and other similar libraries for various reports. - Then I will work on extending python programs with C which involves modifying current C programs to support new python engine . - Updating community of my progress weekly via blog updates. - Will spend some time tweaking the User interface, in order to make it more appealing and convenient. - Start with testing and improving throughput of the code before midterm evaluations (ie: july 15th ). - Start pulling together the documentation and coding. - While in testing phase , I will also finish writing documentations as well. 2011/3/30 Christian Stimming stimm...@tuhh.de Dear Rahul, the application is fine for the start, but the actual goal of your project is still not completely clear. You say you want to enable developers to write scripts for various financial reports - but this is a very blurry requirement wording. Can you instead think of some goals which are more user-visible? Something along the lines of Currently, a user cannot do xy, but with my brand new shiny python engine I can and will implement xy so that the user feature xy is available after the project? Preferrably, this should be some feature that you would like to use for yourself as well, because in that case there is a high probability that it works out nicely. Also, your sentence Initial step would be to add the code to read and process the control file is unclear, because currently there is no control file in gnucash. Also, you say you want to write scripts for various financial reports, but can you be more specific here? Otherwise the project suffers from not having a clear goal. Regards, Christian Am Dienstag
Initial Draft application for Python Scripting Engine
Dear Christian, I've added my initial draft application for GSoC project hereby. Please take a look and advice for corrections. *Basic Information* Student name:Rahul Gaur Location: Meerut City , UP ,India, Home Town :New Delhi ,India Email:rahul@gmail.com Instant messaging contact details (Skype or similar):iamaregee/iamaregee2 on IRC (irc.ubuntu.com) *Background/Programming Information:* I've experience of building GNU cash from source via SVN on a linux system.A few years ago,I learned C++ and Java as a part of my School curriculum.While this is my first year in college ,Now I am pursuing Bachelors in Engineering and my Major is in Computer Science.So I am learning C and Python here in College.By the time GsoC 2011 starts ,I will be done with my end semester exams and equiped with skills to work full time on coding,so I wan't to do some good project in order to strengthen my foundations in understanding of Sofware Systems. *What project in GnuCash would you like to work on?* I would Like to work on Python reporting and Scripting engine for Gnu cash over my summer vacations. *What will be the result of your project :* Upon the successful development of the scripting engine ,it will enable developers to write scripts for various financial reports plus will be bringing in wider contributions to the development as python being a more popular language and highly customizable one too. *How do you propose to solve the problem(s) posed in the project you'd like to work on?* *Project Schedule : * While I plan to follow the description given in the idea of the proposal.I've already familiarised my self with the working of GNU cash (v 2.4.4 SVNr20419).I took a brief idea of sample python scripts.As I've already stated , I've my University exams from 8th to 30th of May ,so during this period I will be in touch with the GNUCash community through emails.During the time before exams ,I hope to : - Get to know the mentor and other community members. - Going through Devloper Docs. - Understand working of the reporting engine. - Brainstorm plans with the community. After I am Done with my exams , I plan to Procede as follows : *Program time-line :* - To create a more accurate programing timetable - Initial step would be to add the code to read and process the control file.Then I will adapt the current codes written in C to work with python engine.Working on API for C and python. - Writing scripts for various financial reports. - Updating community of my progress weekly via blog updates. - Start with testing and improving throughput of the code before midterm evaluations (ie: july 15th ). - Start pulling together the documentation and coding. - While in testing phase , I will also finish writing documentations aswell. -- --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Initial Draft application for Python Scripting Engine
Dear Rahul, the application is fine for the start, but the actual goal of your project is still not completely clear. You say you want to enable developers to write scripts for various financial reports - but this is a very blurry requirement wording. Can you instead think of some goals which are more user-visible? Something along the lines of Currently, a user cannot do xy, but with my brand new shiny python engine I can and will implement xy so that the user feature xy is available after the project? Preferrably, this should be some feature that you would like to use for yourself as well, because in that case there is a high probability that it works out nicely. Also, your sentence Initial step would be to add the code to read and process the control file is unclear, because currently there is no control file in gnucash. Also, you say you want to write scripts for various financial reports, but can you be more specific here? Otherwise the project suffers from not having a clear goal. Regards, Christian Am Dienstag, 29. März 2011 schrieb Rahul Gaur: Dear Christian, I've added my initial draft application for GSoC project hereby. Please take a look and advice for corrections. *Basic Information* Student name:Rahul Gaur Location: Meerut City , UP ,India, Home Town :New Delhi ,India Email:rahul@gmail.com Instant messaging contact details (Skype or similar):iamaregee/iamaregee2 on IRC (irc.ubuntu.com) *Background/Programming Information:* I've experience of building GNU cash from source via SVN on a linux system.A few years ago,I learned C++ and Java as a part of my School curriculum.While this is my first year in college ,Now I am pursuing Bachelors in Engineering and my Major is in Computer Science.So I am learning C and Python here in College.By the time GsoC 2011 starts ,I will be done with my end semester exams and equiped with skills to work full time on coding,so I wan't to do some good project in order to strengthen my foundations in understanding of Sofware Systems. *What project in GnuCash would you like to work on?* I would Like to work on Python reporting and Scripting engine for Gnu cash over my summer vacations. *What will be the result of your project :* Upon the successful development of the scripting engine ,it will enable developers to write scripts for various financial reports plus will be bringing in wider contributions to the development as python being a more popular language and highly customizable one too. *How do you propose to solve the problem(s) posed in the project you'd like to work on?* *Project Schedule : * While I plan to follow the description given in the idea of the proposal.I've already familiarised my self with the working of GNU cash (v 2.4.4 SVNr20419).I took a brief idea of sample python scripts.As I've already stated , I've my University exams from 8th to 30th of May ,so during this period I will be in touch with the GNUCash community through emails.During the time before exams ,I hope to : - Get to know the mentor and other community members. - Going through Devloper Docs. - Understand working of the reporting engine. - Brainstorm plans with the community. After I am Done with my exams , I plan to Procede as follows : *Program time-line :* - To create a more accurate programing timetable - Initial step would be to add the code to read and process the control file.Then I will adapt the current codes written in C to work with python engine.Working on API for C and python. - Writing scripts for various financial reports. - Updating community of my progress weekly via blog updates. - Start with testing and improving throughput of the code before midterm evaluations (ie: july 15th ). - Start pulling together the documentation and coding. - While in testing phase , I will also finish writing documentations aswell. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GSoC] Project: Python reporting and scripting engine
Dear Rohan, thank you for your interest in working with gnucash in the GSoC 2011 program. It is good to hear you've been able to build it from source. If you're interested in python scripting, I would suggest two things: * First, you should read through the example scripts in src/optional/python- bindings/example_scripts and run those as, well, examples. * Secondly, you can check out the brand new SVN (r20472 or higher), then modify the file src/python/init.py in the end to say if True:, then play around with the python console that opens upon next gnucash start (if your python path includes $prefix/lib/python). From my understanding, every action that you can invoke from that console should also be easy to add as a menu item anywhere inside gnucash. Feel free to come up with interesting ideas that can easily be added through python, but might have been very difficult in non- python before. Examples that come to mind are: Import from or export to various file formats, e.g. http://gnucash.uservoice.com/forums/101223-feature- request/suggestions/1470567-import-export-client-supplier-details?ref=title or https://bugzilla.gnome.org/show_bug.cgi?id=637004 Also, all the ideas from the uservoice page are useful suggestions for a project. Best Regards, Christian Am Dienstag, 22. März 2011 schrieb Rohan Kulkarni: Hello, I am interested to work on above mentioned project this summer as a part of GSoC. I have programming experience with Python, C and Scheme. I have built the source code and am getting familiar with the code. Currently going through the python scripts present in the code. Wanted to get some suggestions about the project from the mentors. Regards, Rohan Kulkarni ___ 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 reporting and scripting engine
Dear Andre, thank you for your interest in working with gnucash in the GSoC 2011 program. As a first step, we suggest you should checkout the gnucash sources from SVN and build it yourself (on some Linux/Unix computer), see http://wiki.gnucash.org/wiki/Building If you're interested in python scripting, I would suggest two things: * First, you should read through the example scripts in src/optional/python- bindings/example_scripts and run those as, well, examples. * Secondly, you can check out the brand new SVN (r20472 or higher), then modify the file src/python/init.py in the end to say if True:, then play around with the python console that opens upon next gnucash start (if your python path includes $prefix/lib/python). From my understanding, every action that you can invoke from that console should also be easy to add as a menu item anywhere inside gnucash. Feel free to come up with interesting ideas that can easily be added through python, but might have been very difficult in non- python before. Examples that come to mind are: Import from or export to various file formats, e.g. http://gnucash.uservoice.com/forums/101223-feature- request/suggestions/1470567-import-export-client-supplier-details?ref=title or https://bugzilla.gnome.org/show_bug.cgi?id=637004 Also, all the ideas from the uservoice page are useful suggestions for a project. Best Regards, Christian Am Mittwoch, 23. März 2011 schrieb Andre Murbach Maidl: Hi, I'm a student and was taking a look at Google SoC proposed projects for gnucash and got very interested to work on python reporting and scripting engine. Besides python I would like to include lua as well, if there is time to do it during SoC. If not I would consider it as a future project. The reason why I'm interested to include lua also is that I'm currently working with lua at the university I'm studying. If there is a possibility of working on this project I would be glad to get in touch with its mentor. Many thanks, Andre ___ 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 reporting and scripting engine
Dear Zuhao, Am Mittwoch, 23. März 2011 schrieb Zuhao Wan: I'm also interested in this idea! :) that is good to hear. Again, as a first step, we suggest you should checkout the gnucash sources from SVN and build it yourself (on some Linux/Unix computer), see http://wiki.gnucash.org/wiki/Building Just like to clarify, is the task to rewrite the scheme scripts in src/report/ using python/c, or are there new scripts/functionalities to be implemented? That is up to you. If you're interested in python scripting, I would suggest two things: * First, you should read through the example scripts in src/optional/python- bindings/example_scripts and run those as, well, examples. * Secondly, you can check out the brand new SVN (r20472 or higher), then modify the file src/python/init.py in the end to say if True:, then play around with the python console that opens upon next gnucash start (if your python path includes $prefix/lib/python). From my understanding, every action that you can invoke from that console should also be easy to add as a menu item anywhere inside gnucash. Feel free to come up with interesting ideas that can easily be added through python, but might have been very difficult in non- python before. Examples that come to mind are: Import from or export to various file formats, e.g. http://gnucash.uservoice.com/forums/101223-feature- request/suggestions/1470567-import-export-client-supplier-details?ref=title or https://bugzilla.gnome.org/show_bug.cgi?id=637004 Also, all the ideas from the uservoice page are useful suggestions for a project. Best Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Python reporting and scripting engine
Hi, I'm a student and was taking a look at Google SoC proposed projects for gnucash and got very interested to work on python reporting and scripting engine. Besides python I would like to include lua as well, if there is time to do it during SoC. If not I would consider it as a future project. The reason why I'm interested to include lua also is that I'm currently working with lua at the university I'm studying. If there is a possibility of working on this project I would be glad to get in touch with its mentor. Many thanks, Andre ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python reporting and scripting engine
I'm also interested in this idea! :) Just like to clarify, is the task to rewrite the scheme scripts in src/report/ using python/c, or are there new scripts/functionalities to be implemented? Thanks. Zuhao On Thu, Mar 24, 2011 at 2:49 AM, Andre Murbach Maidl andr...@gmail.comwrote: Hi, I'm a student and was taking a look at Google SoC proposed projects for gnucash and got very interested to work on python reporting and scripting engine. Besides python I would like to include lua as well, if there is time to do it during SoC. If not I would consider it as a future project. The reason why I'm interested to include lua also is that I'm currently working with lua at the university I'm studying. If there is a possibility of working on this project I would be glad to get in touch with its mentor. Many thanks, Andre ___ 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: Work on Python reporting and Scripting engine for GNU cash
On Thu, Mar 17, 2011 at 2:34 AM, Andy Clayton q3a...@gmail.com wrote: Rahul, On Wed, Mar 16, 2011 at 2:27 PM, Rahul Gaur rahul@gmail.com wrote: I've been successfully able to run configure with enabling python bindings, but however there have been some glitches when I tried running those scripts as per the instructions given in the comments but the following error shows up : [snip] Is this just because of lack of any actual account database on my system ?? or I am doing something wrong ?? In both cases the scripts expect arguments. I am sure a patch to make their behavior more helpful when the arguments are missing would be welcomed, but if you read the comments at the top it should make it reasonably clear what they expect. Andy Dear Christian, I would like to congratulate you and everyone at GnuCash Devel for getting selected in Gsoc 2011,hoping to work/contribute with GnuCash-Devleopers over the summer. In your last mail you have stated that a python patch has been received over the mailing list ,so is the Python reporting and scripting engine project is still on the cards for Gsoc ?If there are any other alternative projects based on C and/or python please let me know.. Primarily I would like to work on non-GUI python coding, something like python reporting engine and,As I have already started to familiarize my self with GnuCash 2.4.4 and I've been able to run the scripts plus I am going through the reports written in scheme lang...though it's not of much help,but I've got a gist of how reports are generated... Awaiting your reply.. --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Dear Christian, I've been successfully able to run configure with enabling python bindings, but however there have been some glitches when I tried running those scripts as per the instructions given in the comments but the following error shows up : aregee@aregee-laptop:~/unstable/cashgnu/lib/python2.6/site-packages$ gnucash-env python account_analysis.py Traceback (most recent call last): File account_analysis.py, line 259, in module if __name__ == __main__: main() File account_analysis.py, line 153, in main debits_show, credits_show) = argv[1:8] ValueError: need more than 0 values to unpack aregee@aregee-laptop:~/unstable/cashgnu/lib/python2.6/site-packages$ gnucash-env python simple_invoice_insert.py Traceback (most recent call last): File simple_invoice_insert.py, line 88, in module s = Session(argv[1], is_new=False) IndexError: list index out of range aregee@aregee-laptop:~/unstable/cashgnu/lib/python2.6/site-packages$ Is this just because of lack of any actual account database on my system ?? or I am doing something wrong ?? Now regarding pygtk ,well yes I 've been thinking to give it a try but as of I am spending some more time learning core python as I wan't to strengthen my foundation in the language,but I hope that I'll learn to use pygtk libraries by gsoc. BTW its good to hear that python module will be added to core gnucash soon..:) I've been preparing a rough proposal for GSoC , and I would like to get some inputs from the community so I 'm thinking of sending the proposal on the mailing list.. :) 2011/3/16 Christian Stimming stimm...@tuhh.de Dear Rahul, good to hear you can build from source now. Can you make sure to run configure with --enable-python, then check the examples in the directory src/optional/python-bindings/example_scripts whether you can run them as described in the files, respectively? This should give you a first feeling on how python programming of gnucash will look like. On another note, you can try the pygtk http://www.pygtk.org library to see how creating gtk GUI elements will look like in python. In your GSoC project, you can either try to add new GUI elements into gnucash using python and pygtk, such as a new interface to certain tasks that you need to do yourself but where you don't like the GUI right now. Or you can rather do some non-GUI coding with python, such as preparing and writing a text report for some numbers throughout gnucash. On the mailing list we've already received a patch that will add a python module into gnucash itself. The current optional/python-bindings is only a temporary solution in case one wants to write external python scripts, but again, it's a good first step for you to see what it will look like. Best Regards, Christian Am Montag, 14. März 2011 schrieb Rahul Gaur: thanks for yr help..gnu cash is running properly now..compilation frm svn `ve been sucessful. Now for python project ideas...can you brief me about it..? Thanks Rahul -- --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Rahul, On Wed, Mar 16, 2011 at 2:27 PM, Rahul Gaur rahul@gmail.com wrote: I've been successfully able to run configure with enabling python bindings, but however there have been some glitches when I tried running those scripts as per the instructions given in the comments but the following error shows up : [snip] Is this just because of lack of any actual account database on my system ?? or I am doing something wrong ?? In both cases the scripts expect arguments. I am sure a patch to make their behavior more helpful when the arguments are missing would be welcomed, but if you read the comments at the top it should make it reasonably clear what they expect. Andy ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Dear Rahul, good to hear you can build from source now. Can you make sure to run configure with --enable-python, then check the examples in the directory src/optional/python-bindings/example_scripts whether you can run them as described in the files, respectively? This should give you a first feeling on how python programming of gnucash will look like. On another note, you can try the pygtk http://www.pygtk.org library to see how creating gtk GUI elements will look like in python. In your GSoC project, you can either try to add new GUI elements into gnucash using python and pygtk, such as a new interface to certain tasks that you need to do yourself but where you don't like the GUI right now. Or you can rather do some non-GUI coding with python, such as preparing and writing a text report for some numbers throughout gnucash. On the mailing list we've already received a patch that will add a python module into gnucash itself. The current optional/python-bindings is only a temporary solution in case one wants to write external python scripts, but again, it's a good first step for you to see what it will look like. Best Regards, Christian Am Montag, 14. März 2011 schrieb Rahul Gaur: thanks for yr help..gnu cash is running properly now..compilation frm svn `ve been sucessful. Now for python project ideas...can you brief me about it..? Thanks Rahul ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Hi all, I've been trying to compile GNUcash source ver 2.4.3 downloaded frm gnucash.org ... while running ./configure, i get error ,here is a spinet of last few lines : configure: External QOF Disabled. Using Internal QOF Code. checking dbi/dbi.h usability... no checking dbi/dbi.h presence... no checking for dbi/dbi.h... no configure: error: Unable to find dbi/dbi.h and one more thing the source code Gnu cash on gnucash.org is different from that available on SVN?? because the size on gnucash.org is something less than 9MB but that on SVN greater in size last time I tried downloading it did something about 19.8MB and then net got disconnected...I don't 've very good internet connection here right now... 2011/3/13 Christian Stimming stimm...@tuhh.de Dear Rahul, Welcome to the project! We are very interested to hear about your plans with the GSoC project in gnucash. The Python topic is indeed one of the interesting ideas around here, and I'm confident you will find your way into the gnucash project easily so that you can soon get some exciting new features done. Have you been able to compile GnuCash on your own from SVN? Please try to do so. The following wiki pages should give some guidelines: http://wiki.gnucash.org/wiki/Building http://wiki.gnucash.org/wiki/SVN http://wiki.gnucash.org/wiki/Eclipse If there are specific problems that keep you from checking out gnucash, do not hesitate to ask directly here on the gnucash-devel mailing list. Also, out of curiosity: How did you hear about gnucash's GSoC participation (well, organization application so far)? Best Regards, Christian Am Samstag, 12. März 2011 schrieb Rahul Gaur: Hi, I am a Computer Science engineering student (1st year) from India.I am planning to apply for GSOC 2011 would really love to work on gnu Cash. I've been using open source operating system since last 1-2 years and then there was no turning back. I've learned C++ and java @ school .Now here in college i'm studying C and Python(linux platform),getting a good grip of it and I'm really fascinated by the python language. Familiar with building softwares from the source code, I'm seeking some guidance so that I can enter in Real world software development. This project here which I believe is based on Python C API , which is one of the most intriguing topics which I came across while studying python.I would like to get some more details about this project and want to start working on it. Thanks Regards Rahul Gaur irc : iamaregee2 gtalk : rahul.nbg -- --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Hi Rahul, Zitat von Rahul Gaur rahul@gmail.com: I've been trying to compile GNUcash source ver 2.4.3 downloaded frm gnucash.org ... while running ./configure, i get error ,here is a spinet of last few lines : configure: External QOF Disabled. Using Internal QOF Code. checking dbi/dbi.h usability... no checking dbi/dbi.h presence... no checking for dbi/dbi.h... no configure: error: Unable to find dbi/dbi.h this sounds already quite good. You're almost there :-) With this error, you either need to install the development package of libdbi, which is called libdbi0-dev on ubuntu, or switch off gnucash's usage of dbi with the configure argument --disable-dbi, i.e. ./configure --disable-dbi ... and one more thing the source code Gnu cash on gnucash.org is different from that available on SVN?? because the size on gnucash.org is something less than 9MB but that on SVN greater in size last time I tried downloading it did something about 19.8MB and then net got disconnected...I don't 've very good internet connection here right now... Yes, the SVN checkout contains some more files than what is included in the distributed .tar.gz file (the tarball). Notably some of the artwork source files are also in SVN but not in the tarball. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Work on Python reporting and Scripting engine for GNU cash
Thanks for your valuable inputs .. but i think i've again struck with something here.. checking what language compliance flags to pass to the C compiler... checking for gtk+-2.0 = 2.10... no Package gtk+-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gtk+-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gtk+-2.0' found configure: error: Library requirements (gtk+-2.0 = 2.10) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. I'am using svn source now and installed that libdbi0-dev too and my gtk+-2.0 pkg is located in usr/lib ,i tried export PKG_CONFIG_PATH=/usr/lib/pkgconfig ... am i missing any thing ?? On Mon, Mar 14, 2011 at 1:41 PM, Christian Stimming stimm...@tuhh.dewrote: Hi Rahul, Zitat von Rahul Gaur rahul@gmail.com: I've been trying to compile GNUcash source ver 2.4.3 downloaded frm gnucash.org ... while running ./configure, i get error ,here is a spinet of last few lines : configure: External QOF Disabled. Using Internal QOF Code. checking dbi/dbi.h usability... no checking dbi/dbi.h presence... no checking for dbi/dbi.h... no configure: error: Unable to find dbi/dbi.h this sounds already quite good. You're almost there :-) With this error, you either need to install the development package of libdbi, which is called libdbi0-dev on ubuntu, or switch off gnucash's usage of dbi with the configure argument --disable-dbi, i.e. ./configure --disable-dbi ... and one more thing the source code Gnu cash on gnucash.org is different from that available on SVN?? because the size on gnucash.org is something less than 9MB but that on SVN greater in size last time I tried downloading it did something about 19.8MB and then net got disconnected...I don't 've very good internet connection here right now... Yes, the SVN checkout contains some more files than what is included in the distributed .tar.gz file (the tarball). Notably some of the artwork source files are also in SVN but not in the tarball. Regards, Christian -- --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee -- --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Zitat von Rahul Gaur rahul@gmail.com:
checking for gtk+-2.0 = 2.10... no
Package gtk+-2.0 was not found in the pkg-config search path. Perhaps you
should add the directory containing `gtk+-2.0.pc' to the PKG_CONFIG_PATH
environment variable No package 'gtk+-2.0' found
configure: error: Library requirements (gtk+-2.0 = 2.10) not met;
consider adjusting the PKG_CONFIG_PATH environment variable if your
libraries are in a nonstandard prefix so pkg-config can find them.
I'am using svn source now and installed that libdbi0-dev too
and my gtk+-2.0 pkg is located in usr/lib ,i tried export
PKG_CONFIG_PATH=/usr/lib/pkgconfig ... am i missing any thing ??
Can you show us the directory content of /usr/lib/pkgconfig ? Usually,
this No package gtk+-2.0 error is caused by the missing development
package of gtk. Which distribution do you use? For Ubuntu, all of the
required development packages are automatically installed with the
following command:
sudo aptitude build-dep gnucash
and according to http://wiki.gnucash.org/wiki/Building only the
following should be installed manually in addition:
sudo aptitude install texinfo libdbi0-dev
libdbd-{sqlite3,pgsql,mysql} guile-1.8 guile-1.8-dev doxygen
Regards,
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Since build-dep didn't worked for me , i guess some more libs are missing
so i am installing them one by one manually and now searching for
libgnomeui-2.0 ...well actually i've learned quite a lot of new tweaks too
today :)
Regards
Rahul
On Mon, Mar 14, 2011 at 4:19 PM, Rahul Gaur rahul@gmail.com wrote:
Well i am using ubuntu lucid ,actually i don't have this libgtk2.0-dev pkg
installed pls see the attached screenshots build dep havent downloaded all
the necessary pkgs some are left and they are showing some error .. :(
W: Failed to fetch
http://in.archive.ubuntu.com/ubuntu/pool/main/p/pango1.0/libpango1.0-common_1.28.0-0ubuntu2.1_all.deb
404 Not Found
W: Failed to fetch
http://in.archive.ubuntu.com/ubuntu/pool/main/p/pango1.0/libpango1.0-0_1.28.0-0ubuntu2.1_i386.deb
404 Not Found
W: Failed to fetch
http://in.archive.ubuntu.com/ubuntu/pool/main/p/pango1.0/libpango1.0-dev_1.28.0-0ubuntu2.1_i386.deb
404 Not Found
I do 've libgtk2.0-dev pkg on my hdd let me try to install it manually..
On Mon, Mar 14, 2011 at 3:33 PM, Christian Stimming stimm...@tuhh.dewrote:
Zitat von Rahul Gaur rahul@gmail.com:
checking for gtk+-2.0 = 2.10... no
Package gtk+-2.0 was not found in the pkg-config search path. Perhaps
you
should add the directory containing `gtk+-2.0.pc' to the
PKG_CONFIG_PATH
environment variable No package 'gtk+-2.0' found
configure: error: Library requirements (gtk+-2.0 = 2.10) not met;
consider adjusting the PKG_CONFIG_PATH environment variable if your
libraries are in a nonstandard prefix so pkg-config can find them.
I'am using svn source now and installed that libdbi0-dev too
and my gtk+-2.0 pkg is located in usr/lib ,i tried export
PKG_CONFIG_PATH=/usr/lib/pkgconfig ... am i missing any thing ??
Can you show us the directory content of /usr/lib/pkgconfig ? Usually,
this No package gtk+-2.0 error is caused by the missing development
package of gtk. Which distribution do you use? For Ubuntu, all of the
required development packages are automatically installed with the following
command:
sudo aptitude build-dep gnucash
and according to http://wiki.gnucash.org/wiki/Building only the following
should be installed manually in addition:
sudo aptitude install texinfo libdbi0-dev libdbd-{sqlite3,pgsql,mysql}
guile-1.8 guile-1.8-dev doxygen
Regards,
Christian
--
---
*Regards*
*Rahul Gaur*
irc : iamaregee2
blog : aregee.wordpress.com
fb: http://facebook.com/iamaregee
--
---
*Regards*
*Rahul Gaur*
irc : iamaregee2
blog : aregee.wordpress.com
fb: http://facebook.com/iamaregee
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Finally did it...source is being compiled right now ...
so what next from here...??
btw all the best to gnucash for its application to GSoC 2011 .. :)
Regards
Rahul
On Mon, Mar 14, 2011 at 5:09 PM, Rahul Gaur rahul@gmail.com wrote:
Since build-dep didn't worked for me , i guess some more libs are missing
so i am installing them one by one manually and now searching for
libgnomeui-2.0 ...well actually i've learned quite a lot of new tweaks too
today :)
Regards
Rahul
On Mon, Mar 14, 2011 at 4:19 PM, Rahul Gaur rahul@gmail.com wrote:
Well i am using ubuntu lucid ,actually i don't have this libgtk2.0-dev pkg
installed pls see the attached screenshots build dep havent downloaded all
the necessary pkgs some are left and they are showing some error .. :(
W: Failed to fetch
http://in.archive.ubuntu.com/ubuntu/pool/main/p/pango1.0/libpango1.0-common_1.28.0-0ubuntu2.1_all.deb
404 Not Found
W: Failed to fetch
http://in.archive.ubuntu.com/ubuntu/pool/main/p/pango1.0/libpango1.0-0_1.28.0-0ubuntu2.1_i386.deb
404 Not Found
W: Failed to fetch
http://in.archive.ubuntu.com/ubuntu/pool/main/p/pango1.0/libpango1.0-dev_1.28.0-0ubuntu2.1_i386.deb
404 Not Found
I do 've libgtk2.0-dev pkg on my hdd let me try to install it manually..
On Mon, Mar 14, 2011 at 3:33 PM, Christian Stimming stimm...@tuhh.dewrote:
Zitat von Rahul Gaur rahul@gmail.com:
checking for gtk+-2.0 = 2.10... no
Package gtk+-2.0 was not found in the pkg-config search path. Perhaps
you
should add the directory containing `gtk+-2.0.pc' to the
PKG_CONFIG_PATH
environment variable No package 'gtk+-2.0' found
configure: error: Library requirements (gtk+-2.0 = 2.10) not met;
consider adjusting the PKG_CONFIG_PATH environment variable if your
libraries are in a nonstandard prefix so pkg-config can find them.
I'am using svn source now and installed that libdbi0-dev too
and my gtk+-2.0 pkg is located in usr/lib ,i tried export
PKG_CONFIG_PATH=/usr/lib/pkgconfig ... am i missing any thing ??
Can you show us the directory content of /usr/lib/pkgconfig ? Usually,
this No package gtk+-2.0 error is caused by the missing development
package of gtk. Which distribution do you use? For Ubuntu, all of the
required development packages are automatically installed with the following
command:
sudo aptitude build-dep gnucash
and according to http://wiki.gnucash.org/wiki/Building only the
following should be installed manually in addition:
sudo aptitude install texinfo libdbi0-dev libdbd-{sqlite3,pgsql,mysql}
guile-1.8 guile-1.8-dev doxygen
Regards,
Christian
--
---
*Regards*
*Rahul Gaur*
irc : iamaregee2
blog : aregee.wordpress.com
fb: http://facebook.com/iamaregee
--
---
*Regards*
*Rahul Gaur*
irc : iamaregee2
blog : aregee.wordpress.com
fb: http://facebook.com/iamaregee
--
---
*Regards*
*Rahul Gaur*
irc : iamaregee2
blog : aregee.wordpress.com
fb: http://facebook.com/iamaregee
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
thanks for yr help..gnu cash is running properly now..compilation frm svn `ve been sucessful. Now for python project ideas...can you brief me about it..? Thanks Rahul -- --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Work on Python reporting and Scripting engine for GNU cash
Hi, I am a Computer Science engineering student (1st year) from India.I am planning to apply for GSOC 2011 would really love to work on gnu Cash. I've been using open source operating system since last 1-2 years and then there was no turning back. I've learned C++ and java @ school .Now here in college i'm studying C and Python(linux platform),getting a good grip of it and I'm really fascinated by the python language. Familiar with building softwares from the source code, I'm seeking some guidance so that I can enter in Real world software development. This project here which I believe is based on Python C API , which is one of the most intriguing topics which I came across while studying python.I would like to get some more details about this project and want to start working on it. Thanks Regards Rahul Gaur irc : iamaregee2 gtalk : rahul.nbg ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Work on Python reporting and Scripting engine for GNU cash
Dear Rahul, Welcome to the project! We are very interested to hear about your plans with the GSoC project in gnucash. The Python topic is indeed one of the interesting ideas around here, and I'm confident you will find your way into the gnucash project easily so that you can soon get some exciting new features done. Have you been able to compile GnuCash on your own from SVN? Please try to do so. The following wiki pages should give some guidelines: http://wiki.gnucash.org/wiki/Building http://wiki.gnucash.org/wiki/SVN http://wiki.gnucash.org/wiki/Eclipse If there are specific problems that keep you from checking out gnucash, do not hesitate to ask directly here on the gnucash-devel mailing list. Also, out of curiosity: How did you hear about gnucash's GSoC participation (well, organization application so far)? Best Regards, Christian Am Samstag, 12. März 2011 schrieb Rahul Gaur: Hi, I am a Computer Science engineering student (1st year) from India.I am planning to apply for GSOC 2011 would really love to work on gnu Cash. I've been using open source operating system since last 1-2 years and then there was no turning back. I've learned C++ and java @ school .Now here in college i'm studying C and Python(linux platform),getting a good grip of it and I'm really fascinated by the python language. Familiar with building softwares from the source code, I'm seeking some guidance so that I can enter in Real world software development. This project here which I believe is based on Python C API , which is one of the most intriguing topics which I came across while studying python.I would like to get some more details about this project and want to start working on it. Thanks Regards Rahul Gaur irc : iamaregee2 gtalk : rahul.nbg ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Work on Python reporting and Scripting engine for GNU cash
Dear Christian, Thanks for your affirmative reply.I will try to compile GNUCash from source today itself.. will ping you if I hit a major roadblock in doing so. Well ever since I started using GNU/Linux I wanted to work with Gnu org and while surfing the web I struck upon GNU cash gsoc 2011 project ideas page and found this topic intriguing so I expressed my interest to work on it. Thanks Regards Rahul On 3/13/11, Christian Stimming stimm...@tuhh.de wrote: Dear Rahul, Welcome to the project! We are very interested to hear about your plans with the GSoC project in gnucash. The Python topic is indeed one of the interesting ideas around here, and I'm confident you will find your way into the gnucash project easily so that you can soon get some exciting new features done. Have you been able to compile GnuCash on your own from SVN? Please try to do so. The following wiki pages should give some guidelines: http://wiki.gnucash.org/wiki/Building http://wiki.gnucash.org/wiki/SVN http://wiki.gnucash.org/wiki/Eclipse If there are specific problems that keep you from checking out gnucash, do not hesitate to ask directly here on the gnucash-devel mailing list. Also, out of curiosity: How did you hear about gnucash's GSoC participation (well, organization application so far)? Best Regards, Christian Am Samstag, 12. März 2011 schrieb Rahul Gaur: Hi, I am a Computer Science engineering student (1st year) from India.I am planning to apply for GSOC 2011 would really love to work on gnu Cash. I've been using open source operating system since last 1-2 years and then there was no turning back. I've learned C++ and java @ school .Now here in college i'm studying C and Python(linux platform),getting a good grip of it and I'm really fascinated by the python language. Familiar with building softwares from the source code, I'm seeking some guidance so that I can enter in Real world software development. This project here which I believe is based on Python C API , which is one of the most intriguing topics which I came across while studying python.I would like to get some more details about this project and want to start working on it. Thanks Regards Rahul Gaur irc : iamaregee2 gtalk : rahul.nbg -- --- *Regards* *Rahul Gaur* irc : iamaregee2 blog : aregee.wordpress.com fb: http://facebook.com/iamaregee ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
scripting
Hi all, I recall seeing a couple things on this list about using the GnuCash API to read and write to the account file. I've been using a custom XML parser to read my account file directly and run reports on it, but I'm now thinking about adding write functionality so I thought it'd be wise to revisit how I'm interfacing with the accounts. I've been googling and searching the wiki for documentation, but haven't found much, particularly for write access. Are best practices for reading/writing the account file outside of the GnuCash GUI documented anywhere? Is the API documented anywhere (besides RTFS)? I've seen references to a Python-SWIG binding, what other options are there besides C? Would Scheme work, or is it only prepared for writing reports that integrate with the GnuCash GUI? I'd greatly appreciate *any* pointers that would help in learning how to read and write the accounts file without the GUI. Thanks, Ian p.s. apologies if -devel isn't the right place for this, I'm not sure if this is technically userland or devland. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: scripting
Hi Ian, Am Sonntag, 19. Oktober 2008 20:52 schrieb Ian Smith-Heisters: p.s. apologies if -devel isn't the right place for this, I'm not sure if this is technically userland or devland. -devel is the absoutely right place for this. I've been googling and searching the wiki for documentation, but haven't found much, particularly for write access. Are best practices for reading/writing the account file outside of the GnuCash GUI documented anywhere? Is the API documented anywhere (besides RTFS)? No, the API is documented nowhere else besides the source, but the source documentation is prepared for doxygen processing whose result is online here http://cvs.gnucash.org/docs/HEAD/ I've seen references to a Python-SWIG binding, what other options are there besides C? Would Scheme work, or is it only prepared for writing reports that integrate with the GnuCash GUI? Python is what has been integrated most recently, see http://wiki.gnucash.org/wiki/Python_Bindings and http://article.gmane.org/gmane.comp.gnome.apps.gnucash.devel/23800 Theoretically Scheme should work as well for such scripted jobs with opening a file, changing something, and saving again. However I don't know how to do that :-) Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: scripting
On Sun, Oct 19, 2008 at 12:41 PM, Christian Stimming [EMAIL PROTECTED] wrote: Hi Ian, Am Sonntag, 19. Oktober 2008 20:52 schrieb Ian Smith-Heisters: p.s. apologies if -devel isn't the right place for this, I'm not sure if this is technically userland or devland. -devel is the absoutely right place for this. I've been googling and searching the wiki for documentation, but haven't found much, particularly for write access. Are best practices for reading/writing the account file outside of the GnuCash GUI documented anywhere? Is the API documented anywhere (besides RTFS)? No, the API is documented nowhere else besides the source, but the source documentation is prepared for doxygen processing whose result is online here http://cvs.gnucash.org/docs/HEAD/ I've seen references to a Python-SWIG binding, what other options are there besides C? Would Scheme work, or is it only prepared for writing reports that integrate with the GnuCash GUI? Python is what has been integrated most recently, see http://wiki.gnucash.org/wiki/Python_Bindings and http://article.gmane.org/gmane.comp.gnome.apps.gnucash.devel/23800 Theoretically Scheme should work as well for such scripted jobs with opening a file, changing something, and saving again. However I don't know how to do that :-) Regards, Christian Thanks much, Christian. When diving blindly into something, it's at least good to know there isn't a better option ;) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheme scripting with gnucash.
On the Macintosh, many (most?) applications have a script api where they can be controlled by AppleScript. There is a Required Suite (open, print, quit, run), a Standard Suite (close, count, exists, ...) and then specialised suites for each application. The key is that the Required and Standard suites are the same over many different applications. Cuts down on learning time. Also once you have a control script working, it is easier to move it over to another application. Seems like this might be an interesting proposal for Gnome - an GnuCash could be one of a group of applications moving toward a common implementation. The script language does not have to be guile. It could be perl, ruby, whatever - as long as the api is accessible in those languages. BobG Well, the C re-write is only for the QIF importer. I do think that exporting a non-GUI open file API to scheme would be a Good Thing. -derek David Bottomley [EMAIL PROTECTED] writes: Thanks, anyhow. Such a great tool -- I just want a little more from it. Maybe Derek's c-re-write is a good option. Hi, Writing a script like this _should_ be possible. The only major problem that I can think of is the lack of an open file api without the associated GUI code, meaning I don't think you can write a script that opens a file without also initializing the GUI code. The perl bindings fell into disrepair years ago and nobody has been willing to maintain them. Unfortunately I don't know of any example scripts that would do what you want. Sorry. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.809 / Virus Database: 551 - Release Date: 12/9/2004 -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheme scripting with gnucash.
Well, the C re-write is only for the QIF importer. I do think that exporting a non-GUI open file API to scheme would be a Good Thing. -derek David Bottomley [EMAIL PROTECTED] writes: Thanks, anyhow. Such a great tool -- I just want a little more from it. Maybe Derek's c-re-write is a good option. Hi, Writing a script like this _should_ be possible. The only major problem that I can think of is the lack of an open file api without the associated GUI code, meaning I don't think you can write a script that opens a file without also initializing the GUI code. The perl bindings fell into disrepair years ago and nobody has been willing to maintain them. Unfortunately I don't know of any example scripts that would do what you want. Sorry. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.809 / Virus Database: 551 - Release Date: 12/9/2004 -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheme scripting with gnucash.
Hi, Writing a script like this _should_ be possible. The only major problem that I can think of is the lack of an open file api without the associated GUI code, meaning I don't think you can write a script that opens a file without also initializing the GUI code. The perl bindings fell into disrepair years ago and nobody has been willing to maintain them. Unfortunately I don't know of any example scripts that would do what you want. Sorry. -derek Carl N.Baldwin [EMAIL PROTECTED] writes: Greetings, i have been looking around for the last day or two for information about doing different things in gnucash from a scheme script. Here's what I would like to do. i would like to write a scheme script that will open my gnucash data file, get a list of accounts, get information about transactions in an account such as date, amount, splits, description and possibly even creating transactions. i'm a fairly accomplished script writer but I don't know much scheme. Four years ago or so I actually used the perl wrapper for gnucash rather successfully but I can't seem to find information about that anymore. Scheme seems to be the preferred way to script in gnucash so I would like to try that. Would anyone be able to point me to example scripts that do simple things like what I mentioned above? Are there any docs? I found a reference in the report section of the gnucash online manual that mentioned a file called gnc.html. I can't find this in CVS at all. Is this API still supported? Thank you for your help. Carl Baldwin ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Scheme scripting with gnucash.
Greetings, i have been looking around for the last day or two for information about doing different things in gnucash from a scheme script. Here's what I would like to do. i would like to write a scheme script that will open my gnucash data file, get a list of accounts, get information about transactions in an account such as date, amount, splits, description and possibly even creating transactions. i'm a fairly accomplished script writer but I don't know much scheme. Four years ago or so I actually used the perl wrapper for gnucash rather successfully but I can't seem to find information about that anymore. Scheme seems to be the preferred way to script in gnucash so I would like to try that. Would anyone be able to point me to example scripts that do simple things like what I mentioned above? Are there any docs? I found a reference in the report section of the gnucash online manual that mentioned a file called gnc.html. I can't find this in CVS at all. Is this API still supported? Thank you for your help. Carl Baldwin ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
[EMAIL PROTECTED] wrote: A view of the history and consideration of some practical matters may shed some light. It did, thanks. -- Even if all the gnucash scheme coders died tommorrow, there's so much scheme code that it would be a massive undertaking to re-write it. -- Form time to time, interfaces do change, and it doubles the work if a set of maintainers have to support multiple API's in the face of change. For perl to be practical in gnucash, we'd need a full-time perl guy promising to keep the interfaces whipped into shape. And we don't have that. -- the inter-module problem: say, for example, gnucash wants to use the Finance::Quote perl module for stock quotes. Then we need a way of having scheme call perl code ... debugging gets harder. Many bugs would require the scheme programmer to dive into perl code occasionally, or worse, the scheme-to-perl wrappers ... Meanwhile, the hot-shot perl rogrammer who has the whizband perl module, and wants to integrate it with gnucash... will need to use scheme to accomplish that integration ... And so the needed IQ ratchets up a bit more anyway Sigh. Yeah, interlanguage integration is a bear. What's the consensus on http://www.gnu.org/software/kawa/ ? According to http://www.gnu.org/software/kawa/kawa_11.html it provides pretty good Scheme - Java integration. It's vaguely tempting (assuming unlimited CPU power) to consider porting the core of GnuCash to Java. Then high-level development could be done in either Java or Scheme or both; no special demands would be placed on the IQ of the programmer wishing to call Scheme from Java or vice versa. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Hi Dan,
A view of the history and consideration of some practical matters may
shed some light.
Historically (about 3 years ago), the idea of scripting for gnucash was
discussed at length. I personally was advocating perl, not because
it was better, or that I liked it more, but because I knew there were
zillions of perl hacks out there. The gnucash reporting system was
at that point a html-based cgi-bin-like thingy, and I felt that perl
was a natural for attracting all of that talent.
The talent that was attracted was a number of schemeres (well, mostly
one, Rob Browning, and various supporting voices). And so with some
concern, hand-wringing, etc. said 'ok, scheme too'. There was already
a lot of perl code ('gnc-prices', and the reports in gnucash 1.2.x).
But in fact, no perl hacks ever did show up (excpet for Paul Fenwick, who
took the core of gnc-prices and turned it into the Finance::Quote perl
module on sourceforge).
I expected the perl/scheme code to be mostly 'superficial', with only
gadgets and do-dads using it. Instead, it become inside-out: scheme is now
at the core, and everything else is a do-dad that it coordinates.
There are several practical impediments to perl at this point:
-- Even if all the gnucash scheme coders died tommorrow, there's
so much scheme code that it would be a massive undertaking to
re-write it.
-- Form time to time, interfaces do change, and it doubles the work
if a set of maintainers have to support multiple API's in the face of
change. For perl to be practical in gnucash, we'd need a full-time
perl guy promising to keep the interfaces whipped into shape.
And we don't have that.
-- the inter-module problem: say, for example, gnucash wants to use
the Finance::Quote perl module for stock quotes. Then we need
a way of having scheme call perl code ... debugging gets harder.
Many bugs would require the scheme programmer to dive into perl code
occasionally, or worse, the scheme-to-perl wrappers ...
Meanwhile, the hot-shot perl rogrammer who has the whizband perl
module, and wants to integrate it with gnucash... will need to
use scheme to accomplish that integration ... And so the needed
IQ ratchets up a bit more anyway Sigh.
Linas.
It's been rumoured that Dan Kegel said:
Christopher Browne wrote:
Frankly, it's utterly unimportant if there are thousands of people out
there in "Internet-Land" that think Scheme is a ludicrous choice if, in
contrast, the core developers of GnuCash _all_ happen to like Scheme.
If the latter fact is true [and if not directly true, it's at least not
_vastly distant_ from the truth], then it's likely that Scheme will be
the Most Supported Scripting Language for GnuCash.
True. However, if you find it hard to attract qualified developers
to the project because only a few programmers are willing to learn
Scheme, GnuCash might develop more slowly than you like.
But hey, maybe you guys have plenty of people who regularly contribute code,
and aren't hurting for programmers. So, how many people *are* currently
contributing good Scheme code to GnuCash?
- Dan
p.s. I hope to use GnuCash soon myself, and am quite happy that the
latest RPM's install without trouble on Red Hat 6.2. And
I'm trying to learn Scheme, so if I run into a feature I've
gotta have, I can add it...
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
I'll say this only once, very quietly, since I don't want a flame war; but personally I've never been a fan of Java. Its slowww, buggy, crashes a lot, and has trouble playing nice with others. I've always been intrigued by the fact that the (vast?) majority of the open source community have stayed away from java, even as large chunks of the rest of the programming world flocked to it. --linas It's been rumoured that Dan Kegel said: What's the consensus on http://www.gnu.org/software/kawa/ ? According to http://www.gnu.org/software/kawa/kawa_11.html it provides pretty good Scheme - Java integration. It's vaguely tempting (assuming unlimited CPU power) to consider porting the core of GnuCash to Java. Then high-level development could be done in either Java or Scheme or both; no special demands would be placed on the IQ of the programmer wishing to call Scheme from Java or vice versa. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
We hear and respect your opinion. Java is definitely too slow still to be used for most client-side work, it's piggy with RAM, and the JITs are still buggy. Where speed is not the primary concern, Java has a lot going for it, IMHO. Turn off the JIT and it's pretty stable these days. One of GnuCash's competitors, Moneydance, is written in Java. I just did a web search and found that people complained about its speed somewhat; I suspect it's 2x or 3x slower than the GnuCash engine. Haven't seen any complaints about it being buggy, though. ObDisclosure: I'm a volunteer member of JSR-51, "bringing poll() and saturated 100baseT cards to a jvm near you". - Dan [EMAIL PROTECTED] wrote: I'll say this only once, very quietly, since I don't want a flame war; but personally I've never been a fan of Java. Its slowww, buggy, crashes a lot, and has trouble playing nice with others. I've always been intrigued by the fact that the (vast?) majority of the open source community have stayed away from java, even as large chunks of the rest of the programming world flocked to it. --linas It's been rumoured that Dan Kegel said: What's the consensus on http://www.gnu.org/software/kawa/ ? According to http://www.gnu.org/software/kawa/kawa_11.html it provides pretty good Scheme - Java integration. It's vaguely tempting (assuming unlimited CPU power) to consider porting the core of GnuCash to Java. Then high-level development could be done in either Java or Scheme or both; no special demands would be placed on the IQ of the programmer wishing to call Scheme from Java or vice versa. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Tue, Jan 16, 2001 at 10:44:02PM -0600, Christopher Browne wrote: On Tue, 16 Jan 2001 10:00:05 CST, the world broke into rejoicing as The world "could use" something akin to Graham's "On Lisp" that was, instead, "On Scheme." Kent Dybvig's book on ANSI Scheme, which also happens to be available on the web, seems to me to be about the best text on the language. Maybe we should post a link to that resource on the developer page? -- Dr. David C. Merrill http://www.lupercalia.net Linux Documentation Project[EMAIL PROTECTED] Collection Editor Coordinatorhttp://www.linuxdoc.org Finger me for my public key Under the full moon light we dance Spirits dance, we dance Joining hands, we dance Joining souls rejoice! -- Karen Beth ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Wed, 17 Jan 2001 22:48:53 EST, the world broke into rejoicing as David Merrill [EMAIL PROTECTED] said: On Tue, Jan 16, 2001 at 10:44:02PM -0600, Christopher Browne wrote: On Tue, 16 Jan 2001 10:00:05 CST, the world broke into rejoicing as The world "could use" something akin to Graham's "On Lisp" that was, instead, "On Scheme." Kent Dybvig's book on ANSI Scheme, which also happens to be available on the web, seems to me to be about the best text on the language. Maybe we should post a link to that resource on the developer page? Ready for cutting/pasting, in HTML or DocBook, whichever be preferred: li a href= "http://www.scheme.com/tspl2d/index.html" The Scheme Programming Language, 2nd Edition (Online copy of Kent Dybvig's book) /a listitempara ulink url= "http://www.scheme.com/tspl2d/index.html" The Scheme Programming Language, 2nd Edition (Online copy of Kent Dybvig's book) /ulink /para /listitem -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www.ntlug.org/~cbbrowne/lsf.html Signs of a Klingon Programmer #2: "You question the worthiness of my code? I should kill you where you stand!" ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Mon, Jan 15, 2001 at 07:05:40PM -0500, Eugene Tyurin wrote: Many years ago (circa 1988) I remember briefly trying out some package called Texas Instruments' Scheme. Back then I thought it looked like a dialect of Lisp with some additional system and GUI toolkits. Is that "The Scheme" we're talking about? Scheme is an old language. It predates Common LISP significantly and was one of the early "family" of LISP languages. One of the most beautiful things about Scheme (in my book) is the fact that the definitive reference to the language, "Revised^5 Report on the Algorithmic Language Scheme" (R5RS), is shorter than the *index* to the definitive reference to Common LISP, "Common LISP: The Language (2nd ed)" (CLTL2). Also, one of the best computer science textbooks ever written, "Structure and Interpretation of Computer Programs" by Abelson and Sussman, is written around Scheme. b.g. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Fwd: Re: scripting language vs. developer community size
I are stoopid. James, my apologies for the duplicate email. rob - Forwarded message from [EMAIL PROTECTED] - Date: Tue, 16 Jan 2001 18:27:21 -0700 (MST) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Re: scripting language vs. developer community size To: James LewisMoss [EMAIL PROTECTED] Quoting James LewisMoss [EMAIL PROTECTED]: 1) No on is willing to maintain an interface but the scheme one. You want a perl interface. Go ahead. 2) Many (most? all?) of the core programmers on gnucash know and like scheme. So whatever "You should do this" arguments you might have are pretty useless unless you or someone else is willing to maintain another scripting interface to gnucash. I don't think anyone has argued against one. It's just that no one is willing/able/have time/etc. Jim, I agree with what you are saying. I will explicitly say that I agree with the following points: 1. the core programmers know and like scheme 2. because of this (?), the core programmers don't believe that there is a need to maintain another scripting interface to gnucash. I wonder if the core programmers have ever realized that the choice to stick with scheme effectively limits their programmer base to other scheme users, a smaller base than they could have otherwise. (Actually, since I think that the core programmers are very smart people, I also think that they do know this.) I personally think that a wise question to ask is, "Even though we (the core programmers) are all familiar with scheme, and we all think that it is the best solution that exists for us to do this work in, is the amount of work we spend working in scheme better spent on maintaining a different interface, since we can accept the work of many others if we do a different interface." I guess it comes down to efficiencies. Imagine I am a big business man, and I have an administrative assistant. I can type at 80 wpm, and he can only type at 30. Should I type my own docs? Probably not, if I am getting paid 4 times what he is getting paid. That wasn't such a good analogy. Let me try this again. I am saying that these core guys are so good at what they do that they should work at making it so us not as good people can contribute by using their time to make it easier for more people to contribute to the project. Maybe leverage is what I am talking about, I am not sure. I know that I will never touch it as long as the language is scheme. The fact that the language is in scheme relegates me completely to the position of bug-filer and user. I will not even try to use M-x perldb RET on it, since I don't think I could. :-) Rob (I used to post here as [EMAIL PROTECTED], by way of introduction) - This mail sent through IMP: http://webapps.myinternetplace.net ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Tue, Jan 16, 2001 at 09:09:51AM -0700, Clark Jones wrote:
Just in case anyone's not aware of it, the "CAR" and "CDR" in Lisp (I'm
not familiar with Scheme) are register names for a computer designed in
the late 1950's. (Please don't ask me what the acronyms stand for, or
what the computer was -- I haven't dealt with that in about 15 or 20
years.)
The basic data structure in Scheme (and all LISP-like languages... in
fact LISP is an acronym for LIst PRocessing) is the singly-linked
list. The backbone of the list is a chain of cells ("cons cells")
that have a pointer to the cell data and a "next" pointer to the
remainder of the list.
In the IBM 704 both parts could be stored in one register, which had
two parts, the "address" part and the "decrement" part. The "data"
pointer was stored in the "address" part and the "next" pointer was
stored in the "decrement" part.
There were special instructions for getting out the two parts of a
register, "Contents of the Address part of Register" (CAR) and
"Contents of the Decrement part of Register" (CDR).
So CAR gets you the first element of a list and CDR gets you all the
other elements.
Yes, it's crufty and apocryphal. If it's THAT upsetting to see 'car'
and 'cdr' and friends, try this:
(define first car)
(define rest cdr)
b.g.
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Tyson Dowd wrote: On 15-Jan-2001, Dan Kegel [EMAIL PROTECTED] wrote: [...] Now I'm reading about car, cdr, caar, cddr, cadr, cdar, and the like. How nice that all the keywords of the language are so intuitive and high-level, uninfluenced by the hardware the language originally ran on. Hmm... C++ has a PDP-11 instruction in its *name*... ;-) Just in case anyone's not aware of it, the "CAR" and "CDR" in Lisp (I'm not familiar with Scheme) are register names for a computer designed in the late 1950's. (Please don't ask me what the acronyms stand for, or what the computer was -- I haven't dealt with that in about 15 or 20 years.) I rather suspect that "CAR" and "CDR" will still be used even when only crusty old curmudgeons like me remember what a "Pentium III" was... Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
[EMAIL PROTECTED] (Bill Gribble) writes:
The basic data structure in Scheme (and all LISP-like languages... in
fact LISP is an acronym for LIst PRocessing) is the singly-linked
list. The backbone of the list is a chain of cells ("cons cells")
that have a pointer to the cell data and a "next" pointer to the
remainder of the list.
And anyone who's familiar with glib, LISP lists are somewhat similar
to GSLists. GLists are actually doubly linked...
--
Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Dan Kegel [EMAIL PROTECTED] writes: By the way, I went and bought a Scheme book today at my favorite technical bookstore (Op-Amp Books in Los Angeles). I asked the clerk where the Scheme books were and he sniggered... there was an entire wall of C++ books, and just four books about Scheme (three, if you don't count duplicates). Now I'm reading about car, cdr, caar, cddr, cadr, cdar, and the like. Two things: (1) For scheme to be more successful, it will help a great deal if the SRFI's become widely available. Scheme is a very nice, small, well-defined language, but it lacks a lot of the convenience functions you might want. For example SRFI-1 is very helpful in this respect (for more info see the SRFI section at www.schemers.org). (2) If you haven't seen it, I give my highest recommendation to the the book people usually refer to as SICP. It's the "Structure and Interpretation of Computer Programs" by Abelson and Sussman. Aside from being an excellent way to learn scheme, it will probably broaden the way you think about computer programming. FWIW -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Dan Kegel [EMAIL PROTECTED] writes: p.s. I hope to use GnuCash soon myself, and am quite happy that the latest RPM's install without trouble on Red Hat 6.2. And I'm trying to learn Scheme, so if I run into a feature I've gotta have, I can add it... If you need any help with scheme, feel free to ask. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Ariel Rios wrote: Because there are very few people who know how to program in Scheme compared to the number of people who know how to program in C, C++, Java, or Perl. Basically your argument is: "Scheme is bad for there are not many programmers". Nope, not saying Scheme is bad. It may be great. All I'm saying is that the available developer pool is small. However you forget that Scheme is easier than C, C++, Java, Perl Not for people who know C++, Java, or Perl already and don't know Scheme; writing Scheme takes quite an adjustment. and the idea of a scripting language is to give the user an easy way of creating scripts and extending your application. Scheme has proved to be an excellent if not the best option as a scripting language. The power of lisp has already been showed by emacs an elisp... Only issue I have with that is users not familiar with Scheme (and that's nearly everyone) will have to spend the few weeks needed to learn Scheme. I admire you folks for trying to change the world for the better by spreading the gospel of Scheme, but pragmatically speaking, there's a cost: fewer people are available to work on Gnucash because of it. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
James LewisMoss wrote: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Dan Because there are very few people who know how to program in Dan Scheme compared to the number of people who know how to program Dan in C, C++, Java, or Perl. Learning new things is a goodness. People should be willing, might I say excited, to do that. Should be != are. Wishing it's so doesn't make it so. On the other hand, perhaps you folks are using "ability to program Scheme" in the same way Linus is using "ability to debug kernel problems without a kernel debugger", i.e. as an IQ filter to keep dumb people from contributing code. I respect that strategy, actually, in the case of Linux. Is that partly the way you folks think about it? Dan Fair enough. Would it be more convincing to estimate the number Dan of programmers using various languages by counting job listings Dan for each language? OK. I don't think anyone will argue that there are anywhere near the same number of people who know scheme as there are that know perl (or C or Java or C++ or whatever), but here's the simple facts: 1) No on is willing to maintain an interface but the scheme one. You want a perl interface. Go ahead. Would it be sufficient to write a Perl interface to the engine code, or would the Perl programmers need to be abel to call existing Scheme code? (Seems like that latter, offhand.) 2) Many (most? all?) of the core programmers on gnucash know and like scheme. That's abundantly clear :-)It's a self-selected group. So whatever "You should do this" arguments you might have are pretty useless unless you or someone else is willing to maintain another scripting interface to gnucash. I don't think anyone has argued against one. It's just that no one is willing/able/have time/etc. I don't think I'm saying "you should do this". I'm simply noting that you folks are perhaps needlessly stunting the growth of your project by not allowing coding in more mainstream languages. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Mon, 15 Jan 2001, Dan Kegel wrote: On the other hand, perhaps you folks are using "ability to program Scheme" in the same way Linus is using "ability to debug kernel problems without a kernel debugger", i.e. as an IQ filter to keep dumb people from contributing code. I respect that strategy, actually, in the case of Linux. Is that partly the way you folks think about it? Note that GnuCash isn't really making the decision. Scheme is the scripting language of the GNU project. It integrates with all the GNU stuff. I don't think I'm saying "you should do this". I'm simply noting that you folks are perhaps needlessly stunting the growth of your project by not allowing coding in more mainstream languages. It's GNU that are doing that, not GnuCash! Argue this RMS, who likes Lisp type languages! - Dan ABS -- Alaric B. Snell http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ Any sufficiently advanced technology can be emulated in software ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Al Snell wrote: On Mon, 15 Jan 2001, Dan Kegel wrote: On the other hand, perhaps you folks are using "ability to program Scheme" in the same way Linus is using "ability to debug kernel problems without a kernel debugger", i.e. as an IQ filter to keep dumb people from contributing code. I respect that strategy, actually, in the case of Linux. Is that partly the way you folks think about it? Note that GnuCash isn't really making the decision. Scheme is the scripting language of the GNU project. It integrates with all the GNU stuff. I don't think I'm saying "you should do this". I'm simply noting that you folks are perhaps needlessly stunting the growth of your project by not allowing coding in more mainstream languages. It's GNU that are doing that, not GnuCash! Argue this RMS, who likes Lisp type languages! Yes, he does. But he doesn't dictate what individual projects do. I'm sure he wouldn't object if some non-Scheme scripting language was supported by GnuCash. Sorry, you can't blame this on RMS - you folks have free will! - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Mon, Jan 15, 2001 at 06:37:59PM +, Al Snell wrote: On the other hand, perhaps you folks are using "ability to program Scheme" in the same way Linus is using "ability to debug kernel problems without a kernel debugger", i.e. as an IQ filter to keep dumb people from contributing code. I respect that strategy, actually, in the case of Linux. Is that partly the way you folks think about it? Note that GnuCash isn't really making the decision. Scheme is the scripting language of the GNU project. It integrates with all the GNU stuff. I think this is a little bit disingenuous. Nobody outside the gnucash-devel list is requiring gnucash to use Scheme, least of all RMS; in point of fact, hardly any GNU projects actually use Scheme anyway, despite several years of drum-beating to get it to happen. I'm not trying to say that the FSF support of Guile is not a factor in the decision to use Guile. However, it's not a primary reason (IMO) and frankly if "the FSF says we should" was the most important reason to use Guile as the scripting language I don't think I would support it. I'll shout it from a mountaintop: Scheme is a great programming language, and Guile (while it has its flaws) is a particularly nice implementation for those who wish to code part or all of their application in Scheme while remaining free to use any other libraries you can get your hands on. I've written big programs in C, C++, Common LISP, and Scheme, and small programs in lots and lots of languages. For working on big programs, right at this time I can't think of any way I'd rather do it than as a combination of Scheme and C. Scheme is the kind of language that brings joy to programming (for me) and C is the universal binding language, so if you can put them together there's nothing you can't do more-or-less in style. Bill Gribble ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Tue Jan 16, 2001 at 05:51:31PM +1100, Robert Graham Merkel wrote: Ariel Rios writes: On Sun, 14 Jan 2001, Dan Kegel wrote: I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): I don't see why quoting some web posts can be a good reason. OK, here's the canonical reply to "why do we use scheme". snip Ok, GNUCash uses Scheme as their scripting language; now what if I wanted to contribute C-code? Would it be rejected? --Dirk-Jan. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
"Dirk-Jan C . Binnema" writes: On Tue Jan 16, 2001 at 05:51:31PM +1100, Robert Graham Merkel wrote: Ariel Rios writes: On Sun, 14 Jan 2001, Dan Kegel wrote: I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): I don't see why quoting some web posts can be a good reason. OK, here's the canonical reply to "why do we use scheme". snip Ok, GNUCash uses Scheme as their scripting language; now what if I wanted to contribute C-code? Would it be rejected? C code is not rejected automatically. Of course, like scheme submissions, C code is not automatically accepted either. It's always a good idea to discuss your plans on the list before you start, to make sure they will fit into the general framework. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
[EMAIL PROTECTED] (Bill Gribble) writes: I've written big programs in C, C++, Common LISP, and Scheme, and small programs in lots and lots of languages. For working on big programs, right at this time I can't think of any way I'd rather do it than as a combination of Scheme and C. Scheme is the kind of language that brings joy to programming (for me) and C is the universal binding language, so if you can put them together there's nothing you can't do more-or-less in style. I don't think I need to elaborate much on this, but I will say that really learning Scheme (many thanks to Dr. Paul Wilson for that one), and then using it, has, over time, substantially widened my concept of how things can and *ought* to be when trying to mechanically convert ideas into implementations. Many of the popular languages are painfully weak by comparison. I had similar experiences with haskell, prolog, etc., but scheme is the only one that had enough of a foot in the three worlds of power, elegance, and practicality, to keep me committed to it for large projects. FWIW -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Many years ago (circa 1988) I remember briefly trying out some package called Texas Instruments' Scheme. Back then I thought it looked like a dialect of Lisp with some additional system and GUI toolkits. Is that "The Scheme" we're talking about? -- Nothing here - come back later! ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Eugene Tyurin wrote: Many years ago (circa 1988) I remember briefly trying out some package called Texas Instruments' Scheme. Back then I thought it looked like a dialect of Lisp with some additional system and GUI toolkits. Is that "The Scheme" we're talking about? Scheme is indeed a dialect of Lisp. I think the TI dialect of Scheme is slightly different from what Gnucash uses, but can't say how. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
I think this is a little bit disingenuous. Nobody outside the gnucash-devel list is requiring gnucash to use Scheme, least of all RMS; in point of fact, hardly any GNU projects actually use Scheme anyway, despite several years of drum-beating to get it to happen. False. Many GNOME applications use Scheme via guile or even using SIOD (as the GIMP) ariel ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Ariel Rios wrote: I think this is a little bit disingenuous. Nobody outside the gnucash-devel list is requiring gnucash to use Scheme, least of all RMS; in point of fact, hardly any GNU projects actually use Scheme anyway, despite several years of drum-beating to get it to happen. False. Many GNOME applications use Scheme via guile or even using SIOD (as the GIMP) The Gimp's not the greatest example for your purposes, since they just defected from the pure-scheme camp; they now allow people to write scripts in perl. Anyone want to take bets on the ratio between the number of plugins written in the next year for Gimp in the two languages? By the way, I went and bought a Scheme book today at my favorite technical bookstore (Op-Amp Books in Los Angeles). I asked the clerk where the Scheme books were and he sniggered... there was an entire wall of C++ books, and just four books about Scheme (three, if you don't count duplicates). Now I'm reading about car, cdr, caar, cddr, cadr, cdar, and the like. How nice that all the keywords of the language are so intuitive and high-level, uninfluenced by the hardware the language originally ran on. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Dan Kegel wrote: Now I'm reading about car, cdr, caar, cddr, cadr, cdar, and the like. How nice that all the keywords of the language are so intuitive and high-level, uninfluenced by the hardware the language originally ran on. Forgot the URL for the origin story of those keywords. It's http://home.wxs.nl/~faase009/HaCAR_CDR.html The guy who picked them tried to change them to something more sensible, but it was too late by then. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On 15-Jan-2001, Dan Kegel [EMAIL PROTECTED] wrote: By the way, I went and bought a Scheme book today at my favorite technical bookstore (Op-Amp Books in Los Angeles). I asked the clerk where the Scheme books were and he sniggered... there was an entire wall of C++ books, and just four books about Scheme (three, if you don't count duplicates). Now I'm reading about car, cdr, caar, cddr, cadr, cdar, and the like. How nice that all the keywords of the language are so intuitive and high-level, uninfluenced by the hardware the language originally ran on. Hmm... C++ has a PDP-11 instruction in its *name*... ;-) -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. [EMAIL PROTECTED]# http://www.cs.mu.oz.au/~trd # ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Mon, 15 Jan 2001 20:09:10 EST, the world broke into rejoicing as Ariel Rios [EMAIL PROTECTED] said: I think this is a little bit disingenuous. Nobody outside the gnucash-devel list is requiring gnucash to use Scheme, least of all RMS; in point of fact, hardly any GNU projects actually use Scheme anyway, despite several years of drum-beating to get it to happen. False. Many GNOME applications use Scheme via guile or even using SIOD (as the GIMP) The GNOME apps that use Scheme seem to be a minority; hopefully they will increasingly become script-controllable, but it's not vastly clear that this is yet or soon will be the case. But the more pertinent question is really of whether or not GnuCash uses Scheme _because of the authority of RMS_. The answer to that is _NO_. GnuCash does not use Scheme "because RMS thought that would be a good idea," but rather because various of the developers _of GnuCash_ consider it a good idea. Frankly, it's utterly unimportant if there are thousands of people out there in "Internet-Land" that think Scheme is a ludicrous choice if, in contrast, the core developers of GnuCash _all_ happen to like Scheme. If the latter fact is true [and if not directly true, it's at least not _vastly distant_ from the truth], then it's likely that Scheme will be the Most Supported Scripting Language for GnuCash. -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://www.hex.net/~cbbrowne/lsf.html "It seems certain that much of the success of Unix follows from the readability, modifiability, and portability of its software." -- Dennis M. Ritchie, September, 1979 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Christopher Browne wrote: Frankly, it's utterly unimportant if there are thousands of people out there in "Internet-Land" that think Scheme is a ludicrous choice if, in contrast, the core developers of GnuCash _all_ happen to like Scheme. If the latter fact is true [and if not directly true, it's at least not _vastly distant_ from the truth], then it's likely that Scheme will be the Most Supported Scripting Language for GnuCash. True. However, if you find it hard to attract qualified developers to the project because only a few programmers are willing to learn Scheme, GnuCash might develop more slowly than you like. But hey, maybe you guys have plenty of people who regularly contribute code, and aren't hurting for programmers. So, how many people *are* currently contributing good Scheme code to GnuCash? - Dan p.s. I hope to use GnuCash soon myself, and am quite happy that the latest RPM's install without trouble on Red Hat 6.2. And I'm trying to learn Scheme, so if I run into a feature I've gotta have, I can add it... ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
scripting language vs. developer community size
I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): http://www.cs.utah.edu/plt/mailarch/plt-scheme-2000/msg00667.html "Scheme is so much different from your other everyday languages that people simply ignore it." http://www.cs.utah.edu/plt/mailarch/plt-scheme-2000/msg00668.html "If I didn't have to learn it for a CS class here at Georgia Tech, I probably would have taken one look at Scheme and run screaming." http://www.red-bean.com/guile/guile/new/msg00423.html "I'm just getting to the "solving everyday programming tasks" myself. The learning curve on scheme has been steeper for me than on any previous language (although it just barely beats learning the OO paradigm for C++). I'd previously been in the habit of reaching the skill level needed to solve most basic problems in well under a week, but Scheme seems to want more of my time than that. Stepping back a bit though, I wonder if the difficulty isn't more in the fact that Scheme assumes some much different programming thought processes than those used in C,C++,Perl,Java,etc." Also, http://brainbench.com specializes in proficiency tests, and offers them for C, C++, and Java, but not for Scheme. (Probably means size of job market for Scheme skills is far smaller than that for C, C++, or Java skills.) Given the above, allowing people to contribute plugins written in some procedural language like Perl might expand the potential pool of plugin-writers by about a factor of ten. The new stable Gimp allows plugins to be written in Perl for just that reason. If the Gimp can do it, how about you folks? Scheme for the literati who think in terms of side-effect free functions, and Perl for the rest of us? And while I wait for this new scripting interface :-), how long does it take in your experience for the average C/C++/Java programmer to learn Scheme well enough to really understand Gnucash and contribute to it? - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Sun, 14 Jan 2001, Dan Kegel wrote: I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): I don't see why quoting some web posts can be a good reason. ariel ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Ariel Rios wrote: On Sun, 14 Jan 2001, Dan Kegel wrote: I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Because there are very few people who know how to program in Scheme compared to the number of people who know how to program in C, C++, Java, or Perl. Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): I don't see why quoting some web posts can be a good reason. Fair enough. Would it be more convincing to estimate the number of programmers using various languages by counting job listings for each language? Searching on 'monster.com' ( a jobs database ) for 'scheme' in category "computers: software" yields 46 hits, but these all seemed to be false hits; none I looked at were related to the programming language Scheme. Searching there in the same category for "java" yields over 1000 hits, all of which appear to be valid. The same goes for C and for Perl - Monster shows more than 1000 hits for each. There appear to be far more jobs available for Java, C++, and Perl programmers than for Scheme programmers, and it seems reasonable to conclude that Scheme programmers are a tiny minority among the programming community. QED. - Dan ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Because there are very few people who know how to program in Scheme compared to the number of people who know how to program in C, C++, Java, or Perl. Basically your argument is: "Scheme is bad for there are not many programmers". However you forget that Scheme is easier than C, C++, Java, Perl and the idea of a scripting language is to give the user an easy way of creating scripts and extending your application. Scheme has proved to be an excellent if not the best option as a scripting language. The power of lisp has already been showed by emacs an elisp... ariel ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
On Sun, 14 Jan 2001 22:06:08 -0800, Dan Kegel [EMAIL PROTECTED] said: Dan Ariel Rios wrote: On Sun, 14 Jan 2001, Dan Kegel wrote: I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Dan Because there are very few people who know how to program in Dan Scheme compared to the number of people who know how to program Dan in C, C++, Java, or Perl. Learning new things is a goodness. People should be willing, might I say excited, to do that. Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): I don't see why quoting some web posts can be a good reason. Dan Fair enough. Would it be more convincing to estimate the number Dan of programmers using various languages by counting job listings Dan for each language? OK. I don't think anyone will argue that there are anywhere near the same number of people who know scheme as there are that know perl (or C or Java or C++ or whatever), but here's the simple facts: 1) No on is willing to maintain an interface but the scheme one. You want a perl interface. Go ahead. 2) Many (most? all?) of the core programmers on gnucash know and like scheme. So whatever "You should do this" arguments you might have are pretty useless unless you or someone else is willing to maintain another scripting interface to gnucash. I don't think anyone has argued against one. It's just that no one is willing/able/have time/etc. Jim -- @James LewisMoss [EMAIL PROTECTED] | Blessed Be! @http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scripting language vs. developer community size
Ariel Rios writes: On Sun, 14 Jan 2001, Dan Kegel wrote: I'm sure this has been discussed a zillion times but I'd like to bring it up again: Requiring that all high-level Gnucash code be in Scheme might be restricting the number of developers able to contribute to it. Why? Here's a few quotes from the web in support of that theory (found by searching for "scheme learning curve"): I don't see why quoting some web posts can be a good reason. OK, here's the canonical reply to "why do we use scheme". The "core" developers (dave_p, rlb, grib etc.) all either love, or are at least comfortable with scheme. It works very nicely for our purposes. We've written a whole lot of code in it, and it's not going to go away. I personally dislike Perl, and while I'm not the arbiter of such things, I would be extremely wary of any new Perl code going into the main gnucash tree. In fact, it's pretty unlikely that code in languages other than C and Scheme will be added to the main tree in the forseeable future. As far as providing a perl interface for user scripts, maintaining one scripting language binding is hard enough. Maintaining a bunch of them is too difficult (and if anyone mentions SWIG's guile support we'll scream) and we have other priorities. There are two main alternatives, I suppose, if you want perl support. One is to work on getting/keeping the SWIG perl bindings up to date - there have been others who have shown interest in doing so, a quick check of the archives should reveal their email address. The second is to get g-wrap to support perl. Of course, g-wrap is written in scheme, and people who know scheme aren't really all that fussed about writing their scripts in scheme :-) Look, we realize that a lot of people are put off by scheme, but it really is a nice language once you get over the parentheses hurdle (and a good editor works wonders for that). Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Scheme as the scripting language (was Re:...)
Rob Browning wrote: "Jesse D. Sightler" [EMAIL PROTECTED] writes: Gnumeric, Gimp, Microsoft Office g, and I'm sure quite a few others. Really, IMO, Gnucash should have a plugin architecture and should support alternative extension languages. Hmm... Not that it matters, but I didn't realize that the GIMP supported more than SIOD (i.e. scheme) right now, and AFAIK Gnumeric's other language support comes through CORBA, something we're probably not about to jump in the middle of right now. GIMP supports perl via a plugin, and Gnumeric's plugin architecture has support for Scheme, Perl, and Python. Neither use CORBA to achieve this. -- --- Jesse D. Sightler http://www3.pair.com/jsight/ - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
Re: Scheme as the scripting language (was Re:...)
On Thu, 3 Jun 1999, Jesse D. Sightler wrote: Rob Browning wrote: "Jesse D. Sightler" [EMAIL PROTECTED] writes: Gnumeric, Gimp, Microsoft Office g, and I'm sure quite a few others. Really, IMO, Gnucash should have a plugin architecture and should support alternative extension languages. "Plugin Arhitecture" is a cool espression, you can please anyone with it. But the question is do we need it? Not every program needs a "plugin arhitecture" (an extreme example would be the unix 'ls' command :). Im still using 'xv' instead of Electric Eyes. xv does not have a plugin arhitecture, it does not have extension languages, yet it fulfills my needs. Let's first make a personal finance manager that *works*, OK? Later we can augument it with CORBA, OLE, Java, DCOM, Python, Perl, Tcl,(your favourite language here) and we can even use INTERCAL as an extension language :) Hmm... Not that it matters, but I didn't realize that the GIMP supported more than SIOD (i.e. scheme) right now, and AFAIK Gnumeric's other language support comes through CORBA, something we're probably not about to jump in the middle of right now. GIMP supports perl via a plugin, and Gnumeric's plugin architecture has support for Scheme, Perl, and Python. Neither use CORBA to achieve this. Maybe I wasn't that clear (and maybe I'm not informed well) but do the packeges above actually *rely* on more than one languages (i.e is perl indispensable for GIMP?) or they are there just to be able say "Hey! This program suports more than one extension language!" Was perl there for GIMP from the beginning or it was just added to an already stable program? Had MS Office extension languages (actually extension interfaces, like OLE) from the very first release? I know nothing about Gnumeric except that it has a version number below 0, but they may be well in our situation :) regards, alex. - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
Re: Scheme as the scripting language (was Re:...)
Alexandru Harsanyi wrote: On Thu, 3 Jun 1999, Jesse D. Sightler wrote: Rob Browning wrote: "Jesse D. Sightler" [EMAIL PROTECTED] writes: Gnumeric, Gimp, Microsoft Office g, and I'm sure quite a few others. Really, IMO, Gnucash should have a plugin architecture and should support alternative extension languages. "Plugin Arhitecture" is a cool espression, you can please anyone with it. But the question is do we need it? Not every program needs a "plugin arhitecture" (an extreme example would be the unix 'ls' command :). Im still using 'xv' instead of Electric Eyes. xv does not have a plugin arhitecture, it does not have extension languages, yet it fulfills my needs. Of course, every application doesn't need a plugin architecture. :) But, the I think that a Financial Management application does. Just like I think an image manipulation app does. BTW, I didn't even know that EE supported plugins. Guess I haven't used it in a while. Seems like overkill, though. :) Let's first make a personal finance manager that *works*, OK? Later we can augument it with CORBA, OLE, Java, DCOM, Python, Perl, Tcl,(your favourite language here) and we can even use INTERCAL as an extension language :) Hmm... Not that it matters, but I didn't realize that the GIMP supported more than SIOD (i.e. scheme) right now, and AFAIK Gnumeric's other language support comes through CORBA, something we're probably not about to jump in the middle of right now. GIMP supports perl via a plugin, and Gnumeric's plugin architecture has support for Scheme, Perl, and Python. Neither use CORBA to achieve this. Maybe I wasn't that clear (and maybe I'm not informed well) but do the packeges above actually *rely* on more than one languages (i.e is perl indispensable for GIMP?) or they are there just to be able say "Hey! This program suports more than one extension language!" Was perl there for GIMP from the beginning or it was just added to an already stable program? No, Perl wasn't there from the beginning. Actually, I believe that it wasn't even put into the primary Gimp dist until at least the 1.1 development series started. Had MS Office extension languages (actually extension interfaces, like OLE) from the very first release? Er, the MS Office part was sort of a joke. We'll get MS Office like scripting when the Gnome version of Gnumeric implements CORBA. Probably still a couple of months off, though. I know nothing about Gnumeric except that it has a version number below 0, but they may be well in our situation :) Yes, I haven't yet studied the source code in depth, but Gnumeric is definately a model to emulate when it comes to the plugin architecture. Everything that I have seen and heard indicates that it was relatively little source to implement and remarkably good. At the very least, I can say that the MS Excel import functions seem to work very well. :) -- --- Jesse D. Sightler http://www3.pair.com/jsight/ "Do not use a hatchet to remove a fly from your friend's forehead." - Chinese Proverb - % % -- The GnuCash / X-Accountant Mailing List To unsubscribe, send mail to [EMAIL PROTECTED] and put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
