Re: More Cruft for deletion
Dear John, thanks for looking up those unused functions. In general, I agree those should be removed. Have you also checked whether any of those are called from the Scheme files (with underscores replaces by dashes)? This should be checked as well. Looking at the details, there are a few functions that I would consider useful even though they are unused, such as the equality predicates: src/engine/gncEntry.c: gncEntryEqual src/engine/gncOrder.c: gncOrderEqual src/engine/gnc-commodity.c: gnc_commodity_table_equal Those: src/engine/SX-ttinfo.c: gnc_ttsplitinfo_set_credit_formula_numeric src/engine/SX-ttinfo.c: gnc_ttsplitinfo_set_debit_formula_numeric are from me and are needed to fix the still-existing bug about the SX formula which is locale dependent (meaning if you entered an amount "1.23" in a locale with decimal point as the decimal separator, it won't work if you switch to a locale with a comma as the decimal separator). Those functions are the first of several steps to fix that. However, to be honest I'm not at all working on this anymore. The app-utils ones should be checked for usage from Scheme (such as the gnc_is_euro_currency_code), but if they are unused in *our* Scheme code, all of them can be removed in trunk. The gnome-utils ones can be removed. However, the file src/gnome-utils/gnc-tree-view-owner.c is probably still being worked on by Geert, but he will speak up for himself shortly I guess. Regards, Christian Zitat von John Ralls : With a generous dose of grep and some perl, I've compiled some lists of unused functions. I've commented them out in the code and gotten a successful "make check". The one thing I can't do is know what's part of somebody's work-in-progress. I don't think any of these functions are new, but please look through the lists and let me know if I shouldn't remove any of them. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
Hendrik Boom 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: developer account created
Hendrik Boom writes: > On Tue, 01 Nov 2011 15:41:47 -0400, GnuCash Admin wrote: > > Are you still using CVS? Or does this message need to be changed? Or is > this completely out of your control? The message just needs to be changed. > -- hendrik > >> >> Welcome to the team. -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: More Cruft for deletion
On Nov 13, 2011, at 5:04 PM, John Ralls wrote: > With a generous dose of grep and some perl, I've compiled some lists of > unused functions. I've commented them out in the code and gotten a successful > "make check". The one thing I can't do is know what's part of somebody's > work-in-progress. I don't think any of these functions are new, but please > look through the lists and let me know if I shouldn't remove any of them. > > (In case you're wondering about the motivation: If it isn't there, it doesn't > need to be tested. There's quite enough to test without testing things that > aren't used.) > Dang it, forgot the attachments. Here they are. Regards, John Ralls gnome-utils-not-used-a Description: Binary data app-utils-not-used-a Description: Binary data engine-not-used-a Description: Binary data ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
More Cruft for deletion
With a generous dose of grep and some perl, I've compiled some lists of unused functions. I've commented them out in the code and gotten a successful "make check". The one thing I can't do is know what's part of somebody's work-in-progress. I don't think any of these functions are new, but please look through the lists and let me know if I shouldn't remove any of them. (In case you're wondering about the motivation: If it isn't there, it doesn't need to be tested. There's quite enough to test without testing things that aren't used.) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: developer account created
On Nov 13, 2011, at 6:39 AM, Hendrik Boom wrote: > On Tue, 01 Nov 2011 15:41:47 -0400, GnuCash Admin wrote: > >> This is an automated e-mail via the add-new-developer script ($Revision: >> 1.7 $). >> >> Developer account Muslim Chochlov has been created: >> . >> >> Admins (root) should update CVS access for this user. > > Are you still using CVS? Or does this message need to be changed? Or is > this completely out of your control? > > -- hendrik No, the message is obsolete. We're using Subversion with a git mirror on Github, and have been discussing shutting down the SVN part and just using the git repo. Regards, John Ralls ___ 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 wrote: >On Sat, 12 Nov 2011 12:55:08 -0500, Derek Atkins wrote: > >> Hi, >> >> Hendrik Boom 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: developer account created
On Tue, 01 Nov 2011 15:41:47 -0400, GnuCash Admin wrote: > This is an automated e-mail via the add-new-developer script ($Revision: > 1.7 $). > > Developer account Muslim Chochlov has been created: > . > > Admins (root) should update CVS access for this user. Are you still using CVS? Or does this message need to be changed? Or is this completely out of your control? -- hendrik > > Welcome to the team. ___ 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 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
