Re: 16690 breaks `make check` [WAS Re: AUDIT: r16690 - gnucash/trunk/src/engine - Daniel Harding's update to Afghani currency. closes #504257]
On Sun, Dec 23, 2007 at 11:19:42PM -0800, Andrew Sackville-West wrote: Well 16690 breaks make check. meanwhile I discovered that src/engine/iso-currencies-to-c isn't getting run. At least it looks that way because its supposed to update iso-4217-currencies.c and it doesn't. That doesn't seem to be the source of the failure but is something to note anyway. I did manually run iso-currencies-to-c, saw that it appeared to update iso-4217-currencies.c properly and make check still failed. :( okay, ignore that. sorry, it does run properly. But interestingly, Derek reverted 16619 and that causes make check to succeed. Seems odd to me that adjusting a currency would cause 16619 to cause a test to break. So maybe there is more going on here than meets the eye. Somehow, the two lines in 16690 cause make check to fails. If you delete either line (or jsut comment the out), it passes. Leave them both in, it fails. I can't see what the heck would cause it. And I still believe that it should be two currencies for reasons stated below. I am baffled, so someone please advise. Should I revert 16690 altogether? just delete the line for the old currency so `make check` passes or is something else going on here that this changeset is somehow exposing. The fact that rolling back 16619 makes me think so. Also `make check` fails later in sx, but I don't have a clue about that. A On Sun, Dec 23, 2007 at 07:09:04PM -0800, Andrew Sackville-West wrote: On Sun, Dec 23, 2007 at 08:33:10PM -0500, Derek Atkins wrote: Quoting Andrew Sackville-West [EMAIL PROTECTED]: Well, I honestly don't know. Based on the political situation, I'd say it's highly likely that the old ones are still in circulation, but how many of those are being tracked in financial software? How does conversion handle historic data in a file? IOW, if I have txn's in the old currency predating the new currnecy and gnucash converts what happens to those old txns? It does an internal conversion. EVERYTHING gets migrated over. This is used when the currency is renamed or reissued. Hence the question of whether it really is a different currency or just a reissue of the older one. It's a reissue but its properties have changed (no longer subdivided into puls at 100 per afghani) so prior transactions could have had fractional amounts which don't exist for the new currency. Further the old afghani was converted into new afghanis at two distinct rates depending upon whose authority issued the currency (wacky!). Some were traded at 1000 old to 1 new while some were traded at 2000 old to 1 new. Combining those two facts makes me think it should remain as two distict currencies, but I'm only learning here, so please feel free to tell me I'm wrong. ;) Thanks A ___ 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 -- signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Status of GDA backend
On Sun, Dec 23, 2007 at 08:00:48PM -0500, Phil Longstaff wrote: I've just checked in the last of the code for the gda backend business objects. The status is: Phil, I don't really have a clue what you're doing (other than implmenting a database backend) but I see you putting up all these commits, and I know it's a big job and I know you're all alone... I just wanted to say I'm rooting for you! Go Phil Go! ;-) A signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
xgettext deficiency?
To: Translation Project list, GnuCash devel. list Origin: my report on msgid errors in the gnucash-2.2.1 PO file. I think it's worth following this up. On 24/12/2007, at 8:44 AM, Christian Stimming wrote: 9. #.Translators: This string should not have shown up in #.gnucash.pot as it is looked up in the gtk20 translation #.domain. You can safely ignore this string and leave it #.untranslated. #: ../src/gnome-utils/gnc-dense-cal.c:443 msgid calendar:week_start:0 If this is obsolete, please remove it. Otherwise, it will confuse translators. Well, as Derek said: The string is looked up in gtk20's translation domain. If you look into the source file, you'll notice the dgettext() call around it. In a way, the fact that it shows up in gnucash.pot is a technical deficiency of the xgettext program. We can't do anything about that. Bruno, is this something that persists in the current gettext? If so, do we need to report it specifically to get it fixed? I don't know what type of deficiency is involved: what extra information do you need? Thankyou for any help you can offer with this. :) from Clytie Vietnamese Free Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: PO file typos, the more difficult ones
Christian Stimming schrieb: 26. #.src/report/standard-reports/cash-flow.scm #: ../intl-scm/guile-strings.c:1352 #, c-format msgid %s - %s to %s for Please include a msgctxt string or comment explaining what the placeholders stand for. In other languages, to and for aren't necessarily translated the same in different circumstances. We need to know the meaning of the string, in order to translate it correctly. I've just looked up for myself in the source: This is the title string of the report page. The first %s is the report name (usually Cash Flow). The second and third %s is the starting and ending date of the period covered by this report. I have no idea why this string ends with for and what is supposed to show up after this. Anyone who has used this report? After for some account names are supposed to show up. The cash flow report title shows up like this: Cash Flow - start-date to end-date for account(s) Herbert. Again, unfortunately we cannot add a translator's comment here in the Scheme source that will show up in the pot file. We might change that string into something more obvious, though. Probably having the %s to %s as a separate translation and then building the rest from this. -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: A book-close dialog to help auto-zeroize all Inc/Exp accounts
The other issue is the fact not really how traditional accounting would do this. More usual is a temporary equity account (receiving total income and total expenses) which is then closed to retained equity with a single entry, either gain or loss for the year (thus making it clear which the case was). I was planning to close all the accounts in a single transaction. Actually, two, one transaction for income and one for expense. I understood what you were doing. Now let me try to explain why that MIGHT be an issue. The result you have is two transactions, one representing total income and one representing total expenses. But the absolute magnitude of these two amounts is of little interest while the difference between them and especially the sense of that difference is considered of paramount importance (oh the famous lines from Dickens's David Copperfield say that so much better). So yes, your users can see whether the total income amount or the total expenses amount is the greater and perhaps even do a rough subtraction in their head BUT they probably would prefer a single amount clearly labeled as a gain or loss for the year. Which is why the traditional method was as it was (and from that temporary account the profit and loss report easily produced). Now equity accounts are standing accounts. Not entirely crazy for the close the books function to require the existence of a named equity account to be used for the closing process. The closing function would then generate THREE (instead of two) transactions (total income, total expenses, and gain (or loss) for the year). Michael PS: We (MA Chestnut Foundation) will probably agree to adopt GnuCash at the January board meeting after I present my recommendation. After which I presumably will become available to work on some of the things desired. But also likely to at first be working on the special report formats generally used by non-profits (we have so few accounts/transactions that no big deal to close the books manually so an autoclose not my highest priority). If I get involved, would have to be considered a serious resource (retired senior analyst with a few decades experience designing/writing/debugging financial business software). ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: PO file typos, the more difficult ones
My two cents... On Sun, Dec 23, 2007 at 11:14:59PM +0100, Christian Stimming wrote: Am Mittwoch, 19. Dezember 2007 07:23 schrieb Clytie Siddall: 21. #.src/report/standard-reports/trial-balance.scm #: ../intl-scm/guile-strings.c:524 msgid Do not net, but show gross debit/credit adjustments to these accounts. Merchandising businesses will normally select their inventory accounts here. net is not a verb. I suggest: ah the beauty if English. net can most assuredly be used as a verb. In this case it means something like combine amounts or provide a final result. Another use would be The previous values provided don't net out to the final total. where net out is equivalent to equal. Another example: OUr combined sales growth and cost reductions nets an increase in profits of... where nets would mean results in. + Do not calculate net value: show... That said, I think this nets a fine translation... ;) A signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 16690 breaks `make check` [WAS Re: AUDIT: r16690 - gnucash/trunk/src/engine - Daniel Harding's update to Afghani currency. closes #504257]
On Mon, Dec 24, 2007 at 03:04:00PM +0430, Daniel Harding wrote: Andrew Sackville-West wrote: On Sun, Dec 23, 2007 at 11:19:42PM -0800, Andrew Sackville-West wrote: Well 16690 breaks make check. meanwhile I discovered that src/engine/iso-currencies-to-c isn't getting run. At least it looks that way because its supposed to update iso-4217-currencies.c and it doesn't. That doesn't seem to be the source of the failure but is something to note anyway. I did manually run iso-currencies-to-c, saw that it appeared to update iso-4217-currencies.c properly and make check still failed. :( okay, ignore that. sorry, it does run properly. I'm on Windows, and when I was working on that patch, it appeared that at least some times iso-4217-currencies.c was not getting regenerated properly. I ended up just deleting iso-4217-currencies.c before rebuilding any time I changed iso-4217-currencies.scm. So there may still be something going on here. fair enough. But interestingly, Derek reverted 16619 and that causes make check to succeed. Seems odd to me that adjusting a currency would cause 16619 to cause a test to break. So maybe there is more going on here than meets the eye. Somehow, the two lines in 16690 cause make check to fails. If you delete either line (or jsut comment the out), it passes. Leave them both in, it fails. I can't see what the heck would cause it. Can you give more details about which test(s) are failing? Lots. part of the engine tests. Being on Windows, make check fails for me all over the place (I'm willing to help improve this, but won't be able to tackle it right away). However, I have been able to successfully run some individual tests, so if I know where to look, I might be able to help investigate. Does the tests also fail if you remove/comment out both currencies? it works fine in any combination other than two Afghani currencies. I even tried tweaking some of the values in the two lines to no avail, though I only tried a little. I didn't try moving one of the Afghani lines farther into the file in case it is somehow a problem with having two of the same currencies first. shrug. I think it's a case of this change exposing problems elsewhere, maybe even in the tests themselves. Oh, and can you comment at all on the discussion about whether there should be two Afghani currencies or just one? A signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: A book-close dialog to help auto-zeroize all Inc/Exp accounts
Quoting Mike or Penny Novack [EMAIL PROTECTED]: The result you have is two transactions, one representing total income and one representing total expenses. But the absolute magnitude of these two amounts is of little interest while the difference between them and especially the sense of that difference is considered of paramount importance (oh the famous lines from Dickens's David Copperfield say that so much better). That's not necessarily true. The difference between them is certainly ONE piece of data that's of interest to users, but I certainly want to be able to see the total income and total expense for a year. The CoA will perform that subtraction for you if the Income Total and Expense Total accounts are either a) the same, or b) siblings. I completely disagree that you need a third transaction. Also, I should add that the implementation I committed last night to trunk actually creates one transaction per currency, so if you have multiple income/expense currencies it will make sure that it doesn't mix them. So yes, your users can see whether the total income amount or the total expenses amount is the greater and perhaps even do a rough subtraction in their head BUT they probably would prefer a single amount clearly labeled as a gain or loss for the year. Which is why the traditional method was as it was (and from that temporary account the profit and loss report easily produced). I disagree. That single amount can still be labeled as such on the reports but by combining them in a single transaction in the registers you effectively lose data, and it's data that I dont want to throw away. Now equity accounts are standing accounts. Not entirely crazy for the close the books function to require the existence of a named equity account to be used for the closing process. The closing function would then generate THREE (instead of two) transactions (total income, total expenses, and gain (or loss) for the year). As said above, no, it's only two transactions. I don't understand what you mean by standing accounts. Also, the function, as implemented, doesn't require the account to exist a priori -- you can create it as part of the closing process itself. The alternative is to have the process auto-create an Equity account on your behalf, but I consider that kind of thing generally rude to the users. I'll note, however, that it does auto-create sub-accounts if you use multiple currencies. Michael PS: We (MA Chestnut Foundation) will probably agree to adopt GnuCash at the January board meeting after I present my recommendation. After which I presumably will become available to work on some of the things desired. But also likely to at first be working on the special report formats generally used by non-profits (we have so few accounts/transactions that no big deal to close the books manually so an autoclose not my highest priority). Not a big deal -- I've already implemented it. :-D If I get involved, would have to be considered a serious resource (retired senior analyst with a few decades experience designing/writing/debugging financial business software). Everyone is considered serious. Supply good patches that follow the standards and listen to the advice and suggestions given by the existing developers and your patches will be given the same attention as all the others. On the other hand, if you come in with a chip on your shoulder, hey, I'm a retired senior analyst; I've been doing this forever. I don't have to listen to you young whippersnappers then expect to get a very different response from us ;) This is a meritocracy, but it's a closed meritocracy. Prove your merit by submitting good, clean, simple, straightforward patches that fit into the existing framework and architectures. Extend what's there already instead of starting over. Stuff like that. I look forward to seeing your reports and other changes. -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: Timespecs GDates
Christian Stimming [EMAIL PROTECTED] writes: Am Sonntag, 23. Dezember 2007 18:49 schrieb Derek Atkins: Quoting Andreas Köhler [EMAIL PROTECTED]: Hi Phil, Am Freitag, den 21.12.2007, 20:10 -0500 schrieb Phil Longstaff: 2) Now that GDates are used, is there any reason that Timespec couldn't be replaced by GDate everywhere? GDates only support dates, but no times. So is the question is whether we we want to support only whole days. Ahh, there is that.. It would mean you could never support fixing http://bugzilla.gnome.org/show_bug.cgi?id=89439 OTOH it would mean http://bugzilla.gnome.org/show_bug.cgi?id=137017 (issues induced by time zone change) gets fixed, eventually. It has Severity: major Priority: High for almost two year by now :-) Does gdate have the concept of less-than-or-equal? With a Timespec (or time_t) it's easy to just add 12 hours to the day and use that as the comparison to make sure I get everything on the right day. However, I dont have a strong opinion about whether we should migrate to GDate or stay with Timespec. I don't think that timezone issues are necessarily any better or easier to handle with GDates. 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: Tax tables
Derek Atkins wrote: Quoting Phil Longstaff [EMAIL PROTECTED]: With the gda backend, if I open the tax table editor and create a tax table, the tax table is not committed. Is this expected? I assume with the xml backend, it would have been included in the save. Umm, no, that's not expected. Yes, with the XML backend it would have been included in the save. This is a bug. My bug. I fixed it. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 16690 breaks `make check` [WAS Re: AUDIT: r16690 - gnucash/trunk/src/engine - Daniel Harding's update to Afghani currency. closes #504257]
Andrew Sackville-West [EMAIL PROTECTED] writes: But interestingly, Derek reverted 16619 and that causes make check to succeed. Seems odd to me that adjusting a currency would cause 16619 to cause a test to break. So maybe there is more going on here than meets the eye. Somehow, the two lines in 16690 cause make check to fails. If you delete either line (or jsut comment the out), it passes. Leave them both in, it fails. I can't see what the heck would cause it. And I still believe that it should be two currencies for reasons stated below. I am baffled, so someone please advise. Should I revert 16690 altogether? just delete the line for the old currency so `make check` passes or is something else going on here that this changeset is somehow exposing. The fact that rolling back 16619 makes me think so. Also `make check` fails later in sx, but I don't have a clue about that. It's a bug in the tests.. The tests use an RNG with a fixed seed to generate random transactions, and the additional currency changed the results of the quazi-random selection. That coupled with the fixed lot code was causing an overflow situation. I've fixed this in trunk.. But if we're going to backport the afghani change then we'll need to also backport my test harness changes from r16716. Thank you for helping me test this last night, Andrew. Tracking it down to that one changeset helped me figure out what was going on. -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: PO file typos, the more difficult ones
Christian Stimming [EMAIL PROTECTED] writes: 29. #.src/business/business-reports/fancy-invoice.scm #.src/business/business-reports/easy-invoice.scm #.src/business/business-reports/invoice.scm #: ../intl-scm/guile-strings.c:3256 #: ../intl-scm/guile-strings.c:3462 #: ../intl-scm/guile-strings.c:3660 msgid Display each entry's total total tax Do we need total total ? Derek needs to comment on this. I need to research this... -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
Guile 1.8 error
Is Gnucash (as of r16711) supposed to work with Guile 1.8.3? Macports changed things around so it's hard to use Guile 1.6 so I tried to build Gnucash (from SVN, not Macports) with 1.8.3. When I run it I get this error loading saved reports (any saved reports): * 02:11:44 MESSG gnc.bin loading saved reports * 02:11:44 WARN gnc.app-utils Function: memoization, syntax-error /Users/mta/.gnucash/saved-reports-2.0:3:1: In procedure memoization in expression (let* () (define # #) ...): /Users/mta/.gnucash/saved-reports-2.0:3:1: In file /Users/mta/.gnucash/saved-reports-2.0, line 3: Mixed definitions and expressions in (define (options-gen) (let ((options (gnc:report-template-new-options/name Advanced Portfolio))) (let ((option (gnc:lookup-option options Display Share decimal places))) ((lambda (option) (if option (# 4.0))) option)) (let ((option (gnc:lookup-option options Display Show listings))) ((lambda (option) (if option (# #f))) option)) (let ((option (gnc:lookup-option options General Report name))) ((lambda (option) (if option (# Alexander Portfolio))) option)) (let ((option (gnc:lookup-option options General Set preference for price list data))) ((lambda (option) (if option (# #f))) option)) (let ((option (gnc:lookup-option options General Basis calculation method))) ((lambda (option) (if option (# #))) option)) (let ((option (gnc:lookup-option options General Include gains and losses))) ((lambda (option) (if option (# #t))) option)) options)). Looking at the code in eval.c in Guile 1.8.3 where this error comes from, it looks impossible. That error should only occur if there is a malformed (begin ...) form and there isn't a begin anywhere in the saved report file unless something there is a macro that expands to begin, which seems unlikely. Does anyone have any idea what's going on? Most other things seem to work and make check works so things aren't completely broken. For now I'm going to undo the changes to Macports that screwed up Guile 1.6, but I'm curious what's going on here. -- Mike Alexander [EMAIL PROTECTED] Ann Arbor, MIPGP key ID: BEA343A6 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
