Re: [PATCH] Python bindings (with much of the core api)
I hope it's fine for you to send patches based on what is now in gnucash SVN. We'll make it happen. Thanks a lot for this work! Thank you for the commit, I'm excited. Now that I'm exposed to a larger number of users and developers, I can look forward to a higher volume of emails with bug reports, requests for documentation, and kudos. There goes my summer! Would it make sense to add a python bindings section in Bugzilla here:? http://bugzilla.gnome.org/describecomponents.cgi?product=GnuCash I would also like to give credit to Assiniboine Credit Union (http://www.assiniboine.mb.ca Winnipeg, Canada), which has funded a good chunk of our work on this through a grant they gave us in 2007. Additional python binding work since between June 17 and December 31, 2008 is being funded by a second grant they gave us this year. I've attached three patches, and would appreciate it if one and only one of the three were applied. All three of them change Jeff's email address from his gmail account to his parit account. He was working on this on ParIT's time, ParIT's dime, so this also acknowledges our contribution as an organization. This change and only this change can be found in jeff_is_parit_in_AUTHORS.patch To acknowledge Assiniboine Credit Union, I've attached acu_credit_with_paritistas.patch, it adds to the Mark and Jeff lines in AUTHORS: Python bindings, with grant funding from Assiniboine Credit Union (http://assiniboine.mb.ca/) . I realize that this deviates from the style of the other entries in AUTHORS, and will understand if it isn't an acceptable change. As an alternative, acu_credit_separate.patch leaves the Mark and Jeff lines untouched (except for the @parit.ca change), and gives ACU their own line: Assiniboine Credit Union http://assiniboine.mb.ca Provided grant funding for Python bindings This is probably a bad idea, as ACU isn't an author, so giving them a line is semantically incompatible with a file named AUTHORS. Would work if it were called CREDITS. -- This is off topic, but you're probably wondering how on earth we convinced a credit union to help pay for this. It helps that we have more than python bindings on the brain, but ways to actually use them: http://www.parit.ca/software/pscproject.2008-04-22.9244157838 http://www.parit.ca/software/pscproject.2008-04-22.6725154212 http://www.parit.ca/software/pscproject.2008-04-16.4762043942 http://www.parit.ca/software/pscproject.2008-04-21.9636009485 Expect more announcements on the above as we gear up.. We also pencilled in 30 hours this year for Jeff to inch the register rewrite forward, send him you ideas.. The credit union wanted to know how our work could contribute to at least one of the guiding principals of Social Inclusion, Economic Self Reliance, Ecological Responsibility, or Community Building. We claimed in our grant application that free software meets all four Social Inclusion Non-free software marginalizes everyone and disproportionately excludes people with low incomes. Free software is inclusive and participatory; all can use, all can share, all can change. Anyone can access free software through disc sharing and if available, the Internet. Economic Self Reliance Free software users are not dependent on the original developer for changes, nor likely to experience getting locked out of their own data or be unable to incorporate changes in law. Improvements, as well as software error fixes, can be made by local programmers getting direct feedback from SME users. Ecological Responsibility Computer hardware turnover, and the problem of e-waste, is mostly due to increasing resource demands from software. Free software is typically developed to reduce hardware demands. ParIT develops and tests its work on five year old computers, which encourages sensible resource usage. Community Building Free software is community infrastructure. Community minded individuals are not forced to choose between respect for copyright and goodwill; sharing of free software is permitted and encouraged. ParIT expects its work to be widely copied, leading to the establishment of other local support providers and community support networks. These situations encourage further community co-operation for development. Mark Index: AUTHORS === --- AUTHORS (.../trunk) (revision 9) +++ AUTHORS (.../branches/jeff_is_parit_in_AUTHORS) (revision 15) @@ -150,7 +150,7 @@ Dave Freese [EMAIL PROTECTED] for leap-year fix Todd T. Fries [EMAIL PROTECTED] OpenBSD fix John Goerzen [EMAIL PROTECTED] file i/o fix for 64-bit architectures -Jeff Green [EMAIL PROTECTED] Python bindings +Jeff Green [EMAIL PROTECTED] Python bindings Hans de Graaff [EMAIL PROTECTED] XML patches Daniel Hagerty [EMAIL PROTECTED] patch to balance sheet report Mitsuo Hamada [EMAIL PROTECTED] messages Japanese translations Index: AUTHORS === ---
Re: 2.2.5 Released
Hi Jean-Louis, Jean-Louis Henrion schrieb: I am very surprised to note that the version 2.2.5 Released is not yet available in the Ubuntu distribution. You know when that is done. Usually Ubuntu syncs automatically from Debian unstable. Unfortunately the Debian Maintainer for Gnucash (Thomas Bushnell) has been a little bit busy the last weeks. Hence he didn't update the package in Debian yet (http://bugs.debian.org/481290). If you want to know when he will update the package, please drop a note in the bug report mentioned above (by CCing [EMAIL PROTECTED]). Regards Micha ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.2.5 Released
Micha Lenk wrote: Usually Ubuntu syncs automatically from Debian unstable. Unfortunately the Debian Maintainer for Gnucash (Thomas Bushnell) has been a little bit busy the last weeks. Hence he didn't update the package in Debian yet (http://bugs.debian.org/481290). There is also some work being done in https://launchpad.net/~gnucash/+archive While there is no 2.2.5 version in the archive yet, we are working on providing a package from trunk. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.2.5 Released
Hi, Rolf Leggewie [EMAIL PROTECTED] wrote: Micha Lenk wrote: Usually Ubuntu syncs automatically from Debian unstable. Unfortunately the Debian Maintainer for Gnucash (Thomas Bushnell) has been a little bit busy the last weeks. Hence he didn't update the package in Debian yet (http://bugs.debian.org/481290). There is also some work being done in https://launchpad.net/~gnucash/+archive While there is no 2.2.5 version in the archive yet, we are working on providing a package from trunk. I am not sure who you are talking about. I just want to make sure that everyone knows that trunk is the *unstable* branch and is not recommended for inclusion in distributions. Of course, you are free to build whatever you like :-) Ciao, -- andi5 -- Pt! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
bzr branch of trunk
Hi, I thought that maybe one or the other among you might be interested to learn about the newly created bazaar branch from svn trunk at https://code.launchpad.net/~vcs-imports/gnucash/trunk which is automatically being kept up to date. bzr has better support for local, uncommitted changes and branches. The merge algorithm is also more powerful. If you don't like bzr for whatever reason, then don't use it, but if you like choice, feel free to check it out. Regards Rolf PS: My apologies to the german list, I am too lazy to rewrite everything in German. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting: weighted average price source
Charles Day wrote: On Mon, Jul 7, 2008 at 8:53 AM, Derek Atkins [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: David G. Hamblen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: A few years back (v1.8x), I had problems with these absolute values, and I patched report-utilities.scm,and commodity-utilites.scm so that the balance sheet would balance. In addition to completely removing all the numeric:abs, I also had to do something about the division by zero in commodity-utilities when there was a zero share balance. I'm using the Nearest in Time and the problem went away in the 2.x updates. If anyone's interested, I can dig up my old postings. Anyway, I vote for getting rid of absolute values in bookkeeping. It's not a question of book keeping. It's a question of computing the share price. GnuCash stores buys as a positive and sells as a negative. As Christian pointed out before, if you buy x shares for $y and then later SELL x shares for $y then a non-abs weighted average gives you a price of 0/share! Obviously this is wrong. The weighted average should be $(y/x) per share. But without the ABS you get: y * x + (-y)*xxy -xy 0 -- ==-- == --- = 0 x + x2x 2x When you use abs() here you get the right answer. The fundamental issue here is that I don't think that the average price should include shares I no longer own. My tests (all using the Balance Sheet) indicate that share prices (the y's) are all positive and are calculated from each transaction (Total Buy/Total Shares). The Total Buy (the x*y product) and the Total shares (the x's) are both positive or both negative. What seemed to be happening back in 1.8x, and is still happening in 2.4) was that when you have zero shares, the answer for the weighted average is irrevelant, but I have a situation where I sold all my shares (as in your example), but subsequently purchased a few more shares of the same stock. The weighted average (without all the abs()'s) looks like this: (I can't wait to see what Thunderbird does with my ascii equations :-) ) y * x + y * (-x) + z * w z * w ---==- == w x + (-x) + z z With the abs(), I get a nonsensical average price for my holdings in this asset. In my specific test case, with the initial purchase/sell of 100 shares at $5 (as in your example), and a subsequent purchase of 10 shares at $20, I get a weighted average price of $5.714, and an asset worth $57.14. Using the Nearest in Time or the Most Recent price source, I get an average share price of $20, and an asset value of $200. Without the abs(), you get 0/0 for the weighted average in your example, so that needs to be trapped. The good news is that in 2.4, the Balance Sheet balances in all cases (not true in 1.8x). Of course, then you need to make sure you re-apply the negative for sales. So it's not a question of absolute values in bookkeeping. It's a question of absolute values in computing share prices. Not the same thing. I agree with Derek. That is, the weighted average price source is not intended to compute the cost of your holdings, but rather to compute the volume-weighted average price of all buys AND sells. So it needs to keep using the absolute value. However, it does need to be changed: it should ignore exchanges with a zero amount in the split. So I think we need to add a new price source of Cost which computes without absolute value and does include zero amount splits. That's where taking a look at David's code might come in handy (though implementing this seems like a pretty simple job: copy existing weighted average function, get rid of absolute value, add report option). Whether to even keep the weighted average price source is a question worth asking; I don't think it is a useful way to revalue current holdings. Historical volumes don't seem relevant. Even if the volume weighting was removed, the formula also weights quotes that are clustered within a small period of time more heavily than quotes that are spread apart. In other words, if I have 30 quotes from this month and one quote from last year, the recent quotes practically drown out the quote from last year. If we want to aim for a historical price average then using something like linear regression seems like a better way to go. Could even add some time factors, like getting the midpoint of the portion of the line covering the last 30, 60, 90 days, whatever. But now I am brainstorming new price sources. I do think a volume-weighted average price can be useful; it's just more appropriate for measuring your personal trading performance. Maybe
Re: Reporting: weighted average price source
Charles Day [EMAIL PROTECTED] writes: I've added the new price source which I have called Average Cost (for now, at least). Committed as r17266. For now I have not removed the Weighted Average price source from any reports. I will have a look at that later on. When you do you might consider making Nearest in Time the default Maybe.. -Charles Christian -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting: weighted average price source
On Tue, Jul 8, 2008 at 6:54 AM, Derek Atkins [EMAIL PROTECTED] wrote: Charles Day [EMAIL PROTECTED] writes: I've added the new price source which I have called Average Cost (for now, at least). Committed as r17266. For now I have not removed the Weighted Average price source from any reports. I will have a look at that later on. When you do you might consider making Nearest in Time the default Maybe.. I thought about that, but the problem with nearest in time is that, as I recall, it requires pricedb entries to exist. Perhaps I could make it default to nearest in time whenever entries are detected. I will at least change the default to average cost. If you know an easy way to detect whether there are pricedb entries, let me know. That stuff is completely new to me. -Charles -Charles Christian -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting: weighted average price source
On Tue, Jul 8, 2008 at 5:59 AM, David G. Hamblen [EMAIL PROTECTED] wrote: Charles Day wrote: On Mon, Jul 7, 2008 at 8:53 AM, Derek Atkins [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: David G. Hamblen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: A few years back (v1.8x), I had problems with these absolute values, and I patched report-utilities.scm,and commodity-utilites.scm so that the balance sheet would balance. In addition to completely removing all the numeric:abs, I also had to do something about the division by zero in commodity-utilities when there was a zero share balance. I'm using the Nearest in Time and the problem went away in the 2.x updates. If anyone's interested, I can dig up my old postings. Anyway, I vote for getting rid of absolute values in bookkeeping. It's not a question of book keeping. It's a question of computing the share price. GnuCash stores buys as a positive and sells as a negative. As Christian pointed out before, if you buy x shares for $y and then later SELL x shares for $y then a non-abs weighted average gives you a price of 0/share! Obviously this is wrong. The weighted average should be $(y/x) per share. But without the ABS you get: y * x + (-y)*xxy -xy 0 -- ==-- == --- = 0 x + x2x 2x When you use abs() here you get the right answer. The fundamental issue here is that I don't think that the average price should include shares I no longer own. My tests (all using the Balance Sheet) indicate that share prices (the y's) are all positive and are calculated from each transaction (Total Buy/Total Shares). The Total Buy (the x*y product) and the Total shares (the x's) are both positive or both negative. What seemed to be happening back in 1.8x, and is still happening in 2.4) was that when you have zero shares, the answer for the weighted average is irrevelant, but I have a situation where I sold all my shares (as in your example), but subsequently purchased a few more shares of the same stock. The weighted average (without all the abs()'s) looks like this: (I can't wait to see what Thunderbird does with my ascii equations :-) ) y * x + y * (-x) + z * w z * w ---==- == w x + (-x) + z z With the abs(), I get a nonsensical average price for my holdings in this asset. In my specific test case, with the initial purchase/sell of 100 shares at $5 (as in your example), and a subsequent purchase of 10 shares at $20, I get a weighted average price of $5.714, and an asset worth $57.14. Using the Nearest in Time or the Most Recent price source, I get an average share price of $20, and an asset value of $200. Without the abs(), you get 0/0 for the weighted average in your example, so that needs to be trapped. So far as I can tell, this formula is the same as the new price source named Average Cost that I added yesterday (r17266). The good news is that in 2.4, the Balance Sheet balances in all cases (not true in 1.8x). Unless you have unrealized gains or losses on liabilities. I'm working on that... -Charles for sales. So it's not a question of absolute values in bookkeeping. It's a question of absolute values in computing share prices. Not the same thing. I agree with Derek. That is, the weighted average price source is not intended to compute the cost of your holdings, but rather to compute the volume-weighted average price of all buys AND sells. So it needs to keep using the absolute value. However, it does need to be changed: it should ignore exchanges with a zero amount in the split. So I think we need to add a new price source of Cost which computes without absolute value and does include zero amount splits. That's where taking a look at David's code might come in handy (though implementing this seems like a pretty simple job: copy existing weighted average function, get rid of absolute value, add report option). Whether to even keep the weighted average price source is a question worth asking; I don't think it is a useful way to revalue current holdings. Historical volumes don't seem relevant. Even if the volume weighting was removed, the formula also weights quotes that are clustered within a small period of time more heavily than quotes that are spread apart. In other words, if I have 30 quotes from this month and one quote from last year, the recent quotes practically drown out the quote from last year. If we want to aim for a historical price average then using something like linear regression seems like a better way to go. Could even add some time factors, like getting the midpoint of the portion of the line covering the last 30, 60, 90 days, whatever. But now I am
Small correction to pt_BR.po
Hello, just a correction I noticed using the program and was still in svn version. Thanks. -- Marco Túlio Gontijo e Silva Página: http://marcotmarcot.googlepages.com/ Blog: http://marcotmarcot.blogspot.com/ Correio: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil --- pt_BR.po.orig 2008-07-08 11:20:08.0 -0300 +++ pt_BR.po 2008-07-08 11:20:13.0 -0300 @@ -5377,7 +5377,7 @@ msgstr Se você pressionar o botão iSim/i, o diálogo iBem-vindo ao GnuCash/i será mostrado novamente quando você iniciar o GnuCash. Se você pressionar o -botão iNão/i, ele não será postrado novamente. +botão iNão/i, ele não será mostrado novamente. #: ../src/gnome/glade/newuser.glade.h:5 msgid ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting: weighted average price source
On Tue, Jul 8, 2008 at 8:50 AM, Charles Day [EMAIL PROTECTED] wrote: On Tue, Jul 8, 2008 at 5:59 AM, David G. Hamblen [EMAIL PROTECTED] wrote: Charles Day wrote: On Mon, Jul 7, 2008 at 8:53 AM, Derek Atkins [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: David G. Hamblen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: A few years back (v1.8x), I had problems with these absolute values, and I patched report-utilities.scm,and commodity-utilites.scm so that the balance sheet would balance. In addition to completely removing all the numeric:abs, I also had to do something about the division by zero in commodity-utilities when there was a zero share balance. I'm using the Nearest in Time and the problem went away in the 2.x updates. If anyone's interested, I can dig up my old postings. Anyway, I vote for getting rid of absolute values in bookkeeping. It's not a question of book keeping. It's a question of computing the share price. GnuCash stores buys as a positive and sells as a negative. As Christian pointed out before, if you buy x shares for $y and then later SELL x shares for $y then a non-abs weighted average gives you a price of 0/share! Obviously this is wrong. The weighted average should be $(y/x) per share. But without the ABS you get: y * x + (-y)*xxy -xy 0 -- ==-- == --- = 0 x + x2x 2x When you use abs() here you get the right answer. The fundamental issue here is that I don't think that the average price should include shares I no longer own. My tests (all using the Balance Sheet) indicate that share prices (the y's) are all positive and are calculated from each transaction (Total Buy/Total Shares). The Total Buy (the x*y product) and the Total shares (the x's) are both positive or both negative. What seemed to be happening back in 1.8x, and is still happening in 2.4) was that when you have zero shares, the answer for the weighted average is irrevelant, but I have a situation where I sold all my shares (as in your example), but subsequently purchased a few more shares of the same stock. The weighted average (without all the abs()'s) looks like this: (I can't wait to see what Thunderbird does with my ascii equations :-) ) y * x + y * (-x) + z * w z * w ---==- == w x + (-x) + z z With the abs(), I get a nonsensical average price for my holdings in this asset. In my specific test case, with the initial purchase/sell of 100 shares at $5 (as in your example), and a subsequent purchase of 10 shares at $20, I get a weighted average price of $5.714, and an asset worth $57.14. Using the Nearest in Time or the Most Recent price source, I get an average share price of $20, and an asset value of $200. Without the abs(), you get 0/0 for the weighted average in your example, so that needs to be trapped. So far as I can tell, this formula is the same as the new price source named Average Cost that I added yesterday (r17266). The good news is that in 2.4, the Balance Sheet balances in all cases (not true in 1.8x). Unless you have unrealized gains or losses on liabilities. I'm working on that... ...done. As of r17287, the balance sheet report now supports calculation of unrealized gains and losses on liabilities. -Charles for sales. So it's not a question of absolute values in bookkeeping. It's a question of absolute values in computing share prices. Not the same thing. I agree with Derek. That is, the weighted average price source is not intended to compute the cost of your holdings, but rather to compute the volume-weighted average price of all buys AND sells. So it needs to keep using the absolute value. However, it does need to be changed: it should ignore exchanges with a zero amount in the split. So I think we need to add a new price source of Cost which computes without absolute value and does include zero amount splits. That's where taking a look at David's code might come in handy (though implementing this seems like a pretty simple job: copy existing weighted average function, get rid of absolute value, add report option). Whether to even keep the weighted average price source is a question worth asking; I don't think it is a useful way to revalue current holdings. Historical volumes don't seem relevant. Even if the volume weighting was removed, the formula also weights quotes that are clustered within a small period of time more heavily than quotes that are spread apart. In other words, if I have 30 quotes from this month and one quote from last year, the recent quotes practically drown out the quote from last year. If we want to aim for a historical price average then using something like
Re: r17241 - gnucash/trunk/po - de.po: improve German translations for a few entries under File - New. Closes 538900.
Am Sonntag, 6. Juli 2008 18:31:35 schrieb Christian Stimming: You're very welcome to commit your translation change now on the stable branch in de.po. Shouldn't patchs on de.po also be applied on de_CH.po as long as they don't touch special swiss expressions? Regards, Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r17241 - gnucash/trunk/po - de.po: improve German translations for a few entries under File - New. Closes 538900.
Quoting Frank H. Ellenberger [EMAIL PROTECTED]: Am Sonntag, 6. Juli 2008 18:31:35 schrieb Christian Stimming: You're very welcome to commit your translation change now on the stable branch in de.po. Shouldn't patchs on de.po also be applied on de_CH.po as long as they don't touch special swiss expressions? Well, it should, but only on the 2.2 branch. ;) Regards, Frank -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r17241 - gnucash/trunk/po - de.po: improve German translations for a few entries under File - New. Closes 538900.
Frank H. Ellenberger wrote: Am Sonntag, 6. Juli 2008 18:31:35 schrieb Christian Stimming: You're very welcome to commit your translation change now on the stable branch in de.po. Shouldn't patchs on de.po also be applied on de_CH.po as long as they don't touch special swiss expressions? It sort of starts to feel like Pandora's box. And I don't think that is a feeling you want to induce in contributors. Can't all this be streamlined? Launchpad maybe? It's a breeze and real fun to translate stuff there. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: weird SWIG syntax error with inline keyword
Am Mittwoch, 9. Juli 2008 00:09 schrieb Mark Jenkins: Christian Stimming wrote: By the way, one very weird error that I get with SWIG-1.3.31 and your python/swig bindings is this: ... Turns out swig doesn't like the inline keyword at all of the places in the gnc-numeric.h header. If I add the option -Dinline= to the swig call (i.e. defining inline as an empty macro), swig runs without error and the build continues just fine. That bug was reported here: http://sourceforge.net/tracker/index.php?func=detailaid=1477756group_id=1 645atid=101645 and the fix made it into the 1.3.31 release here http://swig.cvs.sourceforge.net/swig/SWIG/Source/CParse/cscanner.c?r1=1.29; r2=1.30pathrev=rel-1-3-31 Are you sure you have 1.3.31? Oops, you are right - Derek has 1.3.31, but I have 1.3.29, which means I still experience this bug unless I upgrade to some newer versions (where newer means newer than May 2006...) Gnucash currently requires only swig 1.3.28. We either need to upgrade this (on trunk) to 1.3.31 or we need to add a workaround for versions lower than 1.3.31, which would mean adding -Dinline= to SWIG_PYTHON_OPT. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r17241 - gnucash/trunk/po - de.po: improve German translations for a few entries under File - New. Closes 538900.
(I'm unsure whether this answer made it to gnucash-devel, hence CC: to there) Am Dienstag, 8. Juli 2008 21:26 schrieb Rolf Leggewie: Frank H. Ellenberger wrote: Am Sonntag, 6. Juli 2008 18:31:35 schrieb Christian Stimming: You're very welcome to commit your translation change now on the stable branch in de.po. Shouldn't patchs on de.po also be applied on de_CH.po as long as they don't touch special swiss expressions? It sort of starts to feel like Pandora's box. And I don't think that is a feeling you want to induce in contributors. No, but this particular case is precisely why I was hesitating to add a de_CH.po translation into gnucash. Yes, the recently added de_CH.po translation should be patched accordingly as well. No, this shouldn't be Rolf's business but instead the business of the de_CH.po maintainer, whom I specifically asked whether he is willing to do this job and he accepted this job. I think he will provide a de_CH.po patch pretty soon, but it's fine if this takes 1-2 weeks. (If no de_CH.po patch were supplied by a de_CH maintainer, we would have to discuss again the point of a separate de_CH translation, but for now I'd give him a bit of time.) Can't all this be streamlined? Launchpad maybe? It's a breeze and real fun to translate stuff there. So far no external translation tool was able to set up gnucash translations correctly because of our importing of the translation message from C source code, Scheme source code, and GConf schema files. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] Python bindings (with much of the core api)
Am Dienstag, 8. Juli 2008 09:01 schrieb Mark Jenkins: Thanks a lot for this work! Thank you for the commit, I'm excited. Now that I'm exposed to a larger number of users and developers, I can look forward to a higher volume of emails with bug reports, requests for documentation, and kudos. There goes my summer! Heh. Would it make sense to add a python bindings section in Bugzilla here:? http://bugzilla.gnome.org/describecomponents.cgi?product=GnuCash Yes. I've added a component Python Bindings and added [EMAIL PROTECTED] as both default asignee and QA contact. If you prefer another address as either contact (like, Jeff), please give me the email address that is registered with bugzilla. To acknowledge Assiniboine Credit Union, I've attached acu_credit_with_paritistas.patch, it adds to the Mark and Jeff lines in AUTHORS: Python bindings, with grant funding from Assiniboine Credit Union (http://assiniboine.mb.ca/) . I realize that this deviates from the style of the other entries in AUTHORS, and will understand if it isn't an acceptable change. I think this change is very acceptable. I've applied this already. This is an interesting story. Thanks a lot. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting: weighted average price source
Date: Tue, 8 Jul 2008 08:41:21 -0700 From: Charles Day [EMAIL PROTECTED] Subject: Re: Reporting: weighted average price source To: Derek Atkins [EMAIL PROTECTED] Cc: gnucash-devel@gnucash.org, Christian Stimming [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 snip When you do you might consider making Nearest in Time the default Maybe.. I thought about that, but the problem with nearest in time is that, as I recall, it requires pricedb entries to exist. Perhaps I could make it default to nearest in time whenever entries are detected. I will at least change the default to average cost. If you know an easy way to detect whether there are pricedb entries, let me know. That stuff is completely new to me. -Charles (gnc-pricedb-has-prices (gnc-pricedb-get-db (gnc-get-current-book)) account-commodity report-currency) Alex ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r17241 - gnucash/trunk/po - de.po: improve German translations for a few entries under File - New. Closes 538900.
Am Mittwoch, 9. Juli 2008 00:42:00 schrieb Christian Stimming: Yes, the recently added de_CH.po translation should be patched accordingly as well. No, this shouldn't be Rolf's business but instead the business of the de_CH.po maintainer, whom I specifically asked whether he is willing to do this job and he accepted this job. I think he will provide a de_CH.po patch pretty soon, but it's fine if this takes 1-2 weeks. Though I would suggest, we should publish all changes to de.po first as patch on the german mailing list, because not everybody watches everytime trac. (If no de_CH.po patch were supplied by a de_CH maintainer, we would have to discuss again the point of a separate de_CH translation, but for now I'd give him a bit of time.) Assuming, the differences between de.po and de_CH.po are not too much, one could think about keeping de_CH.po as diff to de.po and create a make rule, patch de.po CH.diff po_CH.po for po/ and glossary/. Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
ofxdirectconnect in aqbanking3 branch
The handoff from aqbanking to gnucash is not working. There is still a problem with connecting to my broker's site, but even for the credit card sites, gnucash always returns WARN gnc.import.aqbanking gnc_ab_gettrans: No accountinfo result for this account I did have a problem earlier with errors regarding nonmatching UIDs. I copied my old aqbanking setup into the location that aqbanking3 uses, and I no longer get complaints from gnucash about UIDs. I get the accountinfo error for both accounts that I have updated in the aqbanking3 wizard, and accounts that are straight carryovers from aqbanking2. For the case of the credit cards, gnucash/aqbanking3 successfully connects to the ofx server and downloads the ofx data stream (I can get to it in /tmp/ofx.log), but gnucash isn't importing the transactions. The next to last dialog in the Online Banking Setup wizard has all the right aqbanking - gnucash account pairs matched correctly. Dave -- David Reiser [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
