Re: r23044 - gnucash/trunk/src/engine - Introduce transaction setter xaccTransSetDatePostedSecsNormalized() that ignores the time-of-day part.
Am Montag, 10. Juni 2013, 18:02:46 schrieb Derek Atkins: Christian Stimming cs...@code.gnucash.org writes: Author: cstim Date: 2013-06-09 17:32:06 -0400 (Sun, 09 Jun 2013) New Revision: 23044 Trac: http://svn.gnucash.org/trac/changeset/23044 Modified: gnucash/trunk/src/engine/Transaction.c gnucash/trunk/src/engine/Transaction.h Log: Introduce transaction setter xaccTransSetDatePostedSecsNormalized() that ignores the time-of-day part. We've struggled with the time-of-day part of the PostedDate for long enough. The PostedDate field is just not meaningful with anything else but a plain date, and no time-of-day at all. Hence, the correct setter function for this particular field must ignore the time-of-day. Consequently, a GDate should be used here anyway, but in many places the time64 is more convenient. The new function will now redirect that time64 to the GDate setter function to make sure we will now map everything to one single date. I'll note that the Close Book transactions depend on being able to say +1second to the canonical date/time.. Right, I didn't know about that. I've switched back the book-closing date to the original setter just a minute ago. From src/gnome-utils/dialog-book- close.c:294, it's not +1 second but +12 hours, but yes, you are right. However, this is a perfect example to demonstrate that this usage of PostedDate time-of-day part is not so good. Up until now, some of the importers already set the time-of-day part, so their sorting might already be totally off, compared to the book-closing txn. Effectively, the +12hours offset in the PostedDate is being abused to signal the flag This txn is a book-closing txn. Instead of abusing the PostedDate for this, the flag should rather be made explicit, which of course means that the sorting functions must check for this explicitly as well. Oh well. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: make check fails
Am Montag, 10. Juni 2013, 18:35:11 schrieb Alex Aycinena: Hi, Christian - I believe you did something recently in this area and make check doesn't complete; perhaps related? Unfortunately yes (due to the PWARN - PINFO change). Thanks for pointing this out. I've explained it in the commit message. Christian Message is as follows: TEST: test-engine... (pid=14932) /engine/Account/gnc set account separator: OK /engine/Account/gnc account name violations errmsg: OK /engine/Account/gnc account list name violations:OK /engine/Account/account create and destroy: OK /engine/Account/book set/get root account: OK /engine/Account/xaccMallocAccount: OK /engine/Account/gnc account create root: OK /engine/Account/xaccCloneAccount:OK /engine/Account/xaccFreeAccountChildren: OK /engine/Account/xaccFreeAccount: OK /engine/Account/xaccAccountCommitEdit: OK /engine/Account/gnc account insert remove split: OK /engine/Account/xaccAccount Insert and Remove Lot: OK /engine/Account/xaccAccountRecomputeBalance: OK /engine/Account/xaccAccountOrder:OK /engine/Account/qofAccountSetParent: OK /engine/Account/gnc account append/remove child: OK /engine/Account/gnc account n descendants: OK /engine/Account/gnc account get current depth: OK /engine/Account/gnc account get tree depth: OK /engine/Account/gnc account get descendants: OK /engine/Account/gnc account get descendants sorted: OK /engine/Account/gnc account lookup by name: OK /engine/Account/gnc account lookup by code: OK /engine/Account/gnc account lookup by full name helper: OK /engine/Account/gnc account lookup by full name: OK /engine/Account/gnc account foreach child: OK /engine/Account/gnc account foreach descendant: OK /engine/Account/gnc account foreach descendant until:OK /engine/Account/gnc account get full name: OK /engine/Account/xaccAccountGetProjectedMinimumBalance: OK /engine/Account/xaccAccountGetBalanceAsOfDate: OK /engine/Account/xaccAccountGetPresentBalance:OK /engine/Account/xaccAccountFindOpenLots: OK /engine/Account/xaccAccountForEachLot: OK /engine/Account/xaccAccountHasAncestor: OK /engine/Account/AccountType Stuff: OK /engine/Account/AccountType Compatibility: OK /engine/Account/xaccAccountFindSplitByDesc: OK /engine/Account/xaccAccountFindTransByDesc: OK /engine/Account/gnc account join children: OK /engine/Account/gnc account merge children: OK /engine/Account/xaccAccountForEachTransaction: OK /engine/Account/xaccAccountTreeForEachTransaction: OK /engine/Budget/gnc_budget_set_name():OK /engine/Budget/gnc_budget_set_description(): OK /engine/Budget/gnc_budget_set_num_periods(): OK /engine/Budget/gnc_budget_set_recurrence(): OK /engine/gncInvoice/post: OK /engine/Split/gnc split init:OK /engine/Split/gnc split dispose: OK /engine/Split/gnc split set get property: OK /engine/Split/xaccMallocSplit: OK /engine/Split/xaccDupeSplit: OK /engine/Split/xaccSplitClone:OK /engine/Split/mark split:OK /engine/Split/xaccSplitEqualCheckBal:OK /engine/Split/xaccSplitEqual:** ERROR:/home/gnucash-dev/svncheckouts/gnucash-clean/src/engine/test/utest-Spl it.c:459:test_xaccSplitEqual: assertion failed (checkC.hits == 2): (0 == 2) FAIL GTester: last random seed: R02Scdca4bb39f0f4afb061f96e24026bbb6 /bin/sh: line 1: 14931 Terminated
Re: New Register style
Am Mittwoch, 12. Juni 2013, 18:54:39 schrieb David Carlson: On 6/12/2013 1:45 PM, Kevin Oberlies wrote: I have discovered that I don't like using the New Register style in the 2.5.2 version of Gnucash. Is there a way to change the default behavior when opening an account to always use the Old Style Register Account? Unless of course someone can tell me how to get the behavior from the old style into the new style. Tab advancement seems to be broken for me. -- Kevin Oberlies Kevin, What is it that you do not like about the new register style? It is almost identical to the old style in every way except that it has more features and fewer bugs (at least it will have fewer bugs when it goes to stable release) What is tab advancement? Hi David, I tend to agree with Kevin here, unfortunately. The keyboard behaviour *is* currently different at several places. - The account selection doesn't select the account on the current level if the account separation character; this used to do an auto-complete of the account name on the current level, jumping to the first account in the list of the next level - After tabbing to the amount field, entering an amount, and pressing Return (the main enter key, not the one at the keypad), the cursor currently still stays in the same line, only completing the amount field. This used to do both: Completing the amount field and jumping to the next new transaction. I strongly prefer the old behaviour. And these are just the most obvious ones from the top of my head. Who and how can we add this keyboard behaviour back in? @Kevin: The old register window should be replaced by the new one completely in the long run because it relies on old libraries that will be no longer available at some point. Our intention should rather be to get the new register behave sufficiently the same as the old one. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Python Binding for Windows Version 2.5
The python bindings were never enabled for the windows binaries previously. Will the python bindings be enabled for the windows binaries in ver 2.5 ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python Binding for Windows Version 2.5
Am Mittwoch, 12. Juni 2013, 17:27:38 schrieb Rand Batchelder: The python bindings were never enabled for the windows binaries previously. Will the python bindings be enabled for the windows binaries in ver 2.5 ? No, they will not. The previous answer by David T. says it all: My understanding about why the Windows and Mac builds skip installing Python is that these OSes do not consistently provide Python to users. Including it by default in GnuCash for these platforms would require GnuCash to include Python in the distribution, with concomitant file size problems and requiring GnuCash to keep an updated Python. in other words, the gnucash windows binary with its current 70MB would have to grow even more to contain one complete python binary (and not only its gnucash bindings) with the correct version that fits the version that is used by the build server to build the python gnucash bindings. Current python installers come at 20MB size. We won't do that. But feel free to provide a build script and/or a separate binary package that adds the bindings to an existing gnucash package... Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python Binding for Windows Version 2.5
On Jun 13, 2013, at 6:18 AM, Christian Stimming christ...@cstimming.de wrote: Am Mittwoch, 12. Juni 2013, 17:27:38 schrieb Rand Batchelder: The python bindings were never enabled for the windows binaries previously. Will the python bindings be enabled for the windows binaries in ver 2.5 ? No, they will not. The previous answer by David T. says it all: My understanding about why the Windows and Mac builds skip installing Python is that these OSes do not consistently provide Python to users. Including it by default in GnuCash for these platforms would require GnuCash to include Python in the distribution, with concomitant file size problems and requiring GnuCash to keep an updated Python. in other words, the gnucash windows binary with its current 70MB would have to grow even more to contain one complete python binary (and not only its gnucash bindings) with the correct version that fits the version that is used by the build server to build the python gnucash bindings. Current python installers come at 20MB size. We won't do that. But feel free to provide a build script and/or a separate binary package that adds the bindings to an existing gnucash package... There's got to be a way around that. Pybsddb [1] makes a module that connects multiple versions of Berkeley DB with any version of Python after 2.3. What are they doing differently from us? Regards, John Ralls [1] http://www.jcea.es/programacion/pybsddb.htm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: make check fails
On Jun 13, 2013, at 3:59 AM, Christian Stimming christ...@cstimming.de wrote: Am Montag, 10. Juni 2013, 18:35:11 schrieb Alex Aycinena: Hi, Christian - I believe you did something recently in this area and make check doesn't complete; perhaps related? Unfortunately yes (due to the PWARN - PINFO change). Thanks for pointing this out. I've explained it in the commit message. Christian, You wrote in the commit message: Sigh. It turns out the utest-Split.c relies on the warning log level in order to check for specific code paths. This sucks. The log level warning should please be reserved for things that are actual warnings, not for code path checks that are used in the unittests. That's not correct. utest-Split may rely on the presence of the message to check the code path, and in order to do so needs to match the loglevel, logdomain, and message string. If you change one of those in the tested function, you just change it to match in the test and it should work. In this case you want to change the foo differ warnings to infos. No big deal, just change the loglevel in the tests to match. Now, ideally unit tests would only be checking the message to make sure that it's emitted: That's a side-effect of the function, and a unit test should test all of the function's effects. Unfortunately most of the engine consists of over-long functions with multiple code paths whose behavior is difficult to test correctly coupled with excessive class interdependencies . In order to be able to refactor them for better testability I have to first get them tested somehow so that I'll know when I break something in the refactor. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: make check fails
Am Donnerstag, 13. Juni 2013, 10:05:49 schrieb John Ralls: You wrote in the commit message: Sigh. It turns out the utest-Split.c relies on the warning log level in order to check for specific code paths. This sucks. The log level warning should please be reserved for things that are actual warnings, not for code path checks that are used in the unittests. That's not correct. utest-Split may rely on the presence of the message to check the code path, and in order to do so needs to match the loglevel, logdomain, and message string. If you change one of those in the tested function, you just change it to match in the test and it should work. In this case you want to change the foo differ warnings to infos. No big deal, just change the loglevel in the tests to match. Hi John, the problem is that it's not sufficient to just change it to match the test. I saw in utest-Split.c lines 424-428 how a set of loglevels was selected for various check counters. However, adding the G_LOG_LEVEL_INFO to the set of loglevels in line 424 doesn't work because other tests rely on exactly the chosen set of loglevels that are in use now. Changing the set of log levels solely for the checkC counter doesn't work either, because even this one relies on exactly only this set log level in some other code path tests. That's when I gave up and summarized this experienced in the quoted commit message. Now, ideally unit tests would only be checking the message to make sure that it's emitted: That's a side-effect of the function, and a unit test should test all of the function's effects. Unfortunately most of the engine consists of over-long functions with multiple code paths whose behavior is difficult to test correctly coupled with excessive class interdependencies . In order to be able to refactor them for better testability I have to first get them tested somehow so that I'll know when I break something in the refactor. I certainly agree the overly-long functions make unittesting even harder. Maybe I'm just not understanding the unittesting that includes checking for log output. In that case I'd appreciate if you change the PWARN into PINFO and correctly adapt the unittest. Thanks! Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Multi-column Reports
Hi Lauren, Lauren Murphy lau...@digital-spin.com writes: Hi there I have been using GnuCash for my start-up (and I am loving it). Can someone please help me set up a multi-column report? I want a column for the actual monthly spend compared to budget and same for year-to-date. Basically just a standard variance report. Looking forward to hearing from you. This is more of a user question and should have been asked on gnucash-user. (The gnucash-devel list is more about gnucash development, unless you're implying that you're trying to *write* the report?) GnuCash does have a multi-column report, but what it does is let you run multiple individual reports side-by-side, which might not be exactly what you want because the rows wont necessarily line up. If you want a try multi-column report with lined-up rows I'm afraid GnuCash has no such thing at this time. Even though it's an often-requested feature, nobody has donated such a work and none of the active devs have had the time to explore it. Sorry to be the bearer of bad news. Good Luck, -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
