Compile error
Hi! gcc -DHAVE_CONFIG_H -I. -I../.. -DG_LOG_DOMAIN=\"gnc.app-utils\" -I../../lib/libc -I../../src -I../../src -I../../src/gnc-module -I../../src/calculation -I../../src/core-utils -I../../src/engine -I../../src/libqof/qof -pthread -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DORBIT2=1 -pthread -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -Werror -Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wno-unused -MT gnc-ui-util.lo -MD -MP -MF .deps/gnc-ui-util.Tpo -c gnc-ui-util.c -fPIC -DPIC -o .libs/gnc-ui-util.o cc1: warnings being treated as errors gnc-ui-util.c: In function ‘gnc_account_get_full_name’: gnc-ui-util.c:760: error: array subscript is above array bounds The following patch fixes this problem: Index: src/app-utils/gnc-ui-util.c === --- src/app-utils/gnc-ui-util.c (Revision 18298) +++ src/app-utils/gnc-ui-util.c (Arbeitskopie) @@ -756,8 +756,8 @@ if (!account) return NULL; name = xaccAccountGetFullName (account); - strncpy( result, name, sizeof(result)-1 ); - result[sizeof(result)] = '\0'; + strncpy( result, name, sizeof(result)-2 ); + result[sizeof(result)-1] = '\0'; return result; } Herbert -- Herbert Thoma Dipl.-Ing., MBA Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-6130 Fax: +49-9131-776-6099 email: t...@iis.fhg.de www: http://www.iis.fhg.de/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compile error
Hi, Quoting Herbert Thoma : Hi! [snip] cc1: warnings being treated as errors gnc-ui-util.c: In function ‘gnc_account_get_full_name’: gnc-ui-util.c:760: error: array subscript is above array bounds The following patch fixes this problem: Index: src/app-utils/gnc-ui-util.c === --- src/app-utils/gnc-ui-util.c (Revision 18298) +++ src/app-utils/gnc-ui-util.c (Arbeitskopie) @@ -756,8 +756,8 @@ if (!account) return NULL; name = xaccAccountGetFullName (account); - strncpy( result, name, sizeof(result)-1 ); - result[sizeof(result)] = '\0'; + strncpy( result, name, sizeof(result)-2 ); + result[sizeof(result)-1] = '\0'; Thank you for this patch. Yes, this is definitely a bug. However, there is no need to change the strncpy, only the NUL setting. return result; } Herbert -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: New database backend and multi-user
Thanks for the info. I have added some more comments inside your replies. >From what I understood by following the dev list, converting gnucash to a true db based application is at best a long-term goal. That would solve the multi- user aspects automatically, as the consistency in concurrent access would be guaranteed by the db engine. However, gnucash is far from there yet. So the alternative seems to be: make sure there's only one user accessing the db at any one time. With xml files this was handled with a lock file. Is something similar implemented in the db backends ? I mean, if one person is running gnucash a postgres backed book, and another person tries to start gnucash with the same postgres backed book, will he get the "This book seems to be open by another person" dialog box ? That would be sufficient for now. Regards, Geert On Sunday 6 September 2009, Phil Longstaff wrote: > > There are a couple of problems with the current db back-end with respect to > multi-user access. > > 1) locking/transactions - db transactions are used whenever an object is > written or updated. However, no locking is done, and there are certain > cases where related objects are not saved in the same db transaction, > because the back-end does not have enough information. For example, when a > transaction with multiple splits is saved, each of these is a separate > engine object and is saved separately. The back-end API would need to be > modified to add "start- transaction" and "end-transaction" calls so that > multiple objects could be saved/committed/rolled back together. > > 2) Update notification - Most objects are read when the db is opened and > not read again. Some databases (postgres? not mysql?) provide a callback > when an update is made, so that data can be refreshed. An alternative > would be a timer to refresh. > > 3) Mechanism to handle conflicts - How should the cases be handled when > different people make conflicting changes? > > Phil > ___ > 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: r18299 - gnucash/trunk/src/app-utils - Fix index-out-of-range compilation error
Phil, As I said on -devel, there is no need to change the strncpy length, only the length in the NUL setting.. In the worst case scenario you will over-write the last byte twice. -derek Quoting Phil Longstaff : Author: plongstaff Date: 2009-09-07 10:16:20 -0400 (Mon, 07 Sep 2009) New Revision: 18299 Trac: http://svn.gnucash.org/trac/changeset/18299 Modified: gnucash/trunk/src/app-utils/gnc-ui-util.c Log: Fix index-out-of-range compilation error Modified: gnucash/trunk/src/app-utils/gnc-ui-util.c === --- gnucash/trunk/src/app-utils/gnc-ui-util.c 2009-09-06 18:42:43 UTC (rev 18298) +++ gnucash/trunk/src/app-utils/gnc-ui-util.c 2009-09-07 14:16:20 UTC (rev 18299) @@ -756,8 +756,8 @@ if (!account) return NULL; name = xaccAccountGetFullName (account); - strncpy( result, name, sizeof(result)-1 ); - result[sizeof(result)] = '\0'; + strncpy( result, name, sizeof(result)-2 ); + result[sizeof(result)-1] = '\0'; return result; } ___ gnucash-changes mailing list gnucash-chan...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-changes -- 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: New database backend and multi-user
Phil Longstaff wrote: > 1) locking/transactions - db transactions are used whenever an object is > written or updated. However, no locking is done, and there are certain cases > where related objects are not saved in the same db transaction, because the > back-end does not have enough information. For example, when a transaction > with multiple splits is saved, each of these is a separate engine object and > is saved separately. The back-end API would need to be modified to add > "start- > transaction" and "end-transaction" calls so that multiple objects could be > saved/committed/rolled back together. I would say this is a prerequisite whether multi-user or not. We don't want an error to happen half way through the save, and the end up with a corrupt database. This didn't matter in the XML world so much, as if an error occurred that corrupted data you were unlikely to get the opportunity to save the corrupted xml file. > 2) Update notification - Most objects are read when the db is opened and not > read again. Some databases (postgres? not mysql?) provide a callback when an > update is made, so that data can be refreshed. An alternative would be a > timer to refresh. A far simpler approach is to just react to errors intelligently. For example, if you have chosen an option from a dialog box, and you attempt to commit a transaction depending on that option, and you discover the option you selected in the dialog box no longer exists (it's been changed, whatever), just tell the user "sorry, conflict, please make your change again, as the database changed out from beneath you". No need for sophisticated error handling, but we do need something more than the evil message "an error has occurred". > 3) Mechanism to handle conflicts - How should the cases be handled when > different people make conflicting changes? You simply pop up an error message to the end user, telling them that a conflict has occurred and they must abandon their changes and try again. In theory you won't store up a long list of changes, resulting in a big conflict, you would rather do one small changes at a time, resulting in small conflicts which are trivial to redo. Small conflicts are also extremely unlikely to happen, making the pain both small and seldom. Don't be tempted to offer the end user the option "use my changes and ignore the conflicted ones", as this is a recipe for pain and angst for the end user. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Budget
On September 4, 2009 03:41:42 pm Phil Longstaff wrote: > True. Also, I just went to sourceforge > (http://sourceforge.net/projects/gnucash/), and there is a big green > "Download Now! gnucash_2.3.5.setup.exe", since that was the last file > uploaded and sourceforge may not have an inherent stable/unstable > distinction. I found that Sourceforge has a way of manually assigning a version to the "Download Now" button, so I've set it back to 2.2.9. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Versions on sourceforge.net
I've been releasing unstable 2.3.X versions of gnucash, leading to a stable 2.4.0 in the (hopefully) near future. As part of the release process, I've been putting a win32 build onto sourceforge, as well as the source tarballs. It's recently come to my attention that sourceforge has a "Download Now" button which points to the most recently uploaded files. When I've uploaded an unstable win32 build, it has become the file that "Download Now" will download. If anyone has recently downloaded a win32 setup file from sourceforge.net hoping to try gnucash for their personal accounts, and that file is version 2.3.X, you should be aware that these files are being released to let people exercise the new functionality and report problems. If you are looking for a stable version to track your finances with, you should be using 2.2.9, and should wait for 2.4.0. It is possible to revert from 2.3.X back to 2.2.9. To do this: 1) Open your file with 2.3.X 2) Select File -> Save As. When the dialog box pops up, select XML from the drop-down list, then enter a new file name in the bottom section of the dialog. Press OK. 3) Exit 4) Remove 2.3.X 5) Download and install 2.2.9. 6) Start 2.2.9 and load the file you saved in step 2. If you run into any problems with this procedure, please post to this list. I have modified the "Download Now" button so that it refers to 2.2.9, and will ensure that this reference is kept until 2.4.0 is available. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash bug 584457 - Really F::Q problem
Erik, Bug 584457 (http://bugzilla.gnome.org/show_bug.cgi?id=584457) is really a Finance::Quote problem. What is the best way to log this with that project? Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash bug 584457 - Really F::Q problem
On Sep 7, 2009, at 9:14 AM, Phil Longstaff wrote: Erik, Bug 584457 (http://bugzilla.gnome.org/show_bug.cgi?id=584457) is really a Finance::Quote problem. What is the best way to log this with that project? http://rt.cpan.org/Public/Dist/Display.html?Status=Active&Name=Finance-Quote ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
System error getting price quotes
Fedora 10, gnucash 2.2.9 fc10-i386 distribution I was not able to get USD conversions so I casually ran gnc-fq-update to see if it had been patched. Now I get no price quotes at all. gnc-fq-update shows the following-- LWP is up to date (5.831). Date::Manip is up to date (5.54). HTML::Parser is up to date (3.62). HTML::TableExtract is up to date (2.10). Crypt::SSLeay is up to date (0.57). Finance::Quote is up to date (1.16). gnc-fq-dump works -- gnc-fq-dump yahoo ALVR Finance::Quote fields Gnucash uses: symbol: ALVR <=== required date: 09/04/2009 <=== required currency: USD <=== required last: 3.91 <=\ nav: <=== one of these price: 3.91 <=/ timezone: <=== optional So what did I break? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reg Run Balance for Subaccount view
OK, here is one more update... reg_run_balance_RC3.diff includes the following update(s): 1. Minor code cleanup 2. Fixed issue where 'negative' accounts such as the Equity accounts would show up with negative balances (negative balances would be positive and positive would be negative), but would have the correct color in "Open Subaccounts" view. They now have the correct color and balance. 3. Fixed "Open Subaccounts" view for Income/Expense accounts which would not display debit/credit totals for transactions. Only 'issue' left is clean-up for the overall Tools->General Ledger register. The General Ledger now displays a 'Balance' column because it is of the GENERAL_LEDGER type, but always has a $0.00 balance because transactions will always balance out. So, a new ledger type (SUBACCOUNTS_LEDGER) may be necessary to be used for the 'open subaccounts' view so that the general ledger can be left without a balance column, or the GENERAL_LEDGER type could sift out the balance column based on the ld->type property, although I'm uncertain of how to do this myself. The current behavior of the General Ledger register is not a bug, however, although ideally the Balance column would not be displayed in this register. I opted not to create a new ledger type for this patch, since it could perhaps more easily be done if it is possible to compare the ld->type and only display the balance column for the GENERAL_LEDGER if the ld->type == LD_SUBACCOUNTS. -Tim On Sun, Sep 6, 2009 at 6:58 PM, Tim M wrote: > Attached is an update to the RC1 patch > > This patch improves the original "RC1" patch in the following ways: > 1. reg_run_balance_RC2.diff adds the gnc_split_register_get_rbaln() function, > > whose code was originally duplicated in the > gnc_split_register_get_balance_fg_color() and > gnc_split_register_get_rbaln_entry() functions in the first patch. > > 2. Modified the gnc_split_register_get_tdebcred_entry() function to display > the > > debit/credit amount for the register's parent account and all subaccounts when > the GENERAL_LEDGER register is in use (used by Show Subaccounts feature). > > 3. Added the get_trans_total_amount_subaccounts() function which returns the > > total amount of a transaction for the register's parent account and all > subaccounts. > > > > On Fri, Sep 4, 2009 at 12:01 AM, Tim M wrote: > >> OK, IMO the updated patch attached to this mail is ready for testing. >> This patch does the following: >> >> 1. When opening an account register and it's subaccounts by right clicking >> it in the Accounts tab and selecting "Open Subaccounts," there is now a >> Balance column as there normally is in a single account register. >> >> 2. This new RBALN balance column tallies the balance of the splits for the >> account and all subaccounts at runtime. >> >> 3. Because the balance is calculated at runtime, this also means that the >> balance column always reflects an accurate running balance regardless of >> sort order. This is a big benefit and could certainly be modified to work >> for single account view as well. With the current single account register, >> when the sort order is changed the Balance displayed will only reflect the >> balance of the account associated with each split - not a running balance in >> relation to the sort order of the register, so that the 'Balance' displayed >> for each split when the sort order is not the default causes the 'Balance' >> column to be more or less unusable. >> >> I believe this should also resolve the following issue: >> http://bugzilla.gnome.org/show_bug.cgi?id=107929 >> >> I resolved issue #1 in my original mailing list post. Issue #2 remains a >> matter of testing by other users to ensure the patch doesn't have any >> unintended consequences. >> >> I've tested this patch locally by opening an account and it's subaccounts >> using the "Open Subaccounts" option. The newly added balance column tallies >> the balance properly at runtime, and sets the balance color properly as well >> (red for negative, black positive). I also tested different sort orders, >> and the running balance was spot on regardless. Since this affects only the >> "Open Subaccounts" register (and possibly other similar registers?), this >> does not affect single account registers so those still do not tally Balance >> properly when using a non-default sort order. >> >> This patch is against an older version of the SVN repository (I think a >> trunk snapshot of version 3.1), so it may or may not work OK with the latest >> trunk. Let me know if I need to make a new patch with the current trunk. >> >> >> As a side note and as matter of cleanup, it would be useful to >> functionalize the part of the new gnc_split_register_get_rbaln_entry() >> function which does the actual calculations to get the running balance of >> the register at a specific split, because the running balance also has to be >> calculated for the gnc_split_register_get_balance_fg_color() function to set >>
