Re: My QIF file crashes GnuCash. How can I find out what line(s) it doesn't like?
On Sat, Dec 19, 2009 at 2:50 PM, Pat McGee j...@xorandor.com wrote: I tried to import a QIF file from the Mac version of Quicken 2000 into GnuCash 2.2.9 (Mac Intel version). The druid goes through several screens, the last one being Payees and Memos, saying that the next screen will show me the payee and memo fields for certain transactions. As soon as I click on the Forward button, the program crashes. In the Console log, I see the message I've appended below. The qif file is about 1.4 MB. So, I'm reluctant to start making changes without more clues as to which parts I should work on. How can I figure out what line(s) the QIF importer doesn't like? I'm pretty certain that this is bug 575778: https://bugzilla.gnome.org/show_bug.cgi?id=575778 It has already been fixed, but the fix has not been released into a stable version of GnuCash yet. So you can look at the bug report to see how to patch GnuCash yourself. Or, leave GnuCash alone and hand edit your QIF file to make sure every security definition contains a T line. -Charles (If it helps, I have programmed some in LISP, but I'm not really good at it. I'm pretty good at C and Objective-C, amongst others.) Thanks, Pat -- Console log: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] Backtrace: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] In unknown file: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867]?: 0* [qif-import:update-security-hash # # # ...] 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] In /Apps-Local/Gnucash.app/Contents/Resources/share/gnucash/scm/qif-import/qif-dialog-utils.scm: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 745: 1* (let ((names #)) (hash-fold (lambda # #) #f ...) ...) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 746: 2* [hash-fold #procedure #f (qif-name map-entry p) #f ...] 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] In unknown file: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867]?: 3* [#procedure #f # Schwab:R-Cash # #f] 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] In /Apps-Local/Gnucash.app/Contents/Resources/share/gnucash/scm/qif-import/qif-dialog-utils.scm: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 748: 4* (let ((security-name #)) (if (and security-name # # ...) (let # #)) #f) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 751: 5* (if (and security-name # # ...) (let # #)) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 759: 6 (let ((existing-gnc-acct #) (book #)) (if (and # #) (let # #) ...)) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] ... 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 777: 7 (let* (# # #) (if # #) (hash-set! security-hash security-name #) ...) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 781: 8* [qif-ticker-map:lookup-type #qif-ticker-map stocks: (# # # ...) R-Cash] 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] In /Apps-Local/Gnucash.app/Contents/Resources/share/gnucash/scm/qif-import/qif-objects.scm: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 679: 9 (let (#) (for-each # #) retval) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 680: 10* [for-each #procedure #f (symbol) (# # # # ...)] 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] In unknown file: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867]?: 11 (if (null? rest) (letrec ((lp #)) (lp list1)) ...) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] ... 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867]?: 12 (begin (f (car l)) (lp (cdr l))) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867]?: 13* [#procedure #f # #] 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] In /Apps-Local/Gnucash.app/Contents/Resources/share/gnucash/scm/qif-import/qif-objects.scm: 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 682: 14 (if (string=? name #) (begin # #)) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] ... 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 685: 15 (if (string=? retval ) (set! retval #f)) 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] 685: 16* [string=? #f ] 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] /Apps-Local/Gnucash.app/Contents/Resources/share/gnucash/scm/qif-import/qif-objects.scm:685:18: In procedure string=? in expression (string=? retval ): 12/19/09 5:37:44 PM [0x0-0x17c17c].org.gnucash.Gnucash[4867] /Apps-Local/Gnucash.app/Contents/Resources/share/gnucash/scm/qif-import/qif-objects.scm:685:18: Wrong type argument in position 1 (expecting STRINGP): #f 12/19/09 5:37:44 PM com.apple.launchd[72] ([0x0-0x17c17c].org.gnucash.Gnucash[4867]) Exited with exit code: 2 12/19/09 5:37:44 PM
Re: OS X dmg File Size
On Wed, Sep 2, 2009 at 7:45 AM, John Ralls jra...@ceridwen.fremont.ca.uswrote: On Sep 1, 2009, at 9:35 PM, David T. wrote: Why has the OS X dmg file gone from 135MB to 215MB? That's getting to be a pretty BIG download... Mostly the addition of the Qt frameworks for the aqbanking wizard. I'll separate the intel and ppc into separate dmgs to get the size back down. Perhaps at some point a .dmg that also doesn't include aqbanking could be offered. At this point frankly I'm quite grateful to have any .dmg at all. I upgraded to Snow Leopard and now MacPorts can't guild gtk for quartz, so I'm dead in the water for building GnuCash myself. Might be time for me to switch over to John's build system. Regards, John Ralls -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Unstable version 2.3.4 and dates
On Tue, Aug 25, 2009 at 7:12 AM, Phil Longstaff plongst...@rogers.comwrote: Unstable version 2.3.4 has a major problem with storing/loading date or date/time values into postgresql or mysql databases, so the bug reports are coming in. A fix is already available, so I'm going to create 2.3.5 as soon as I can (today or tomorrow). This will push the string freeze to 2.3.6 which will be near the end of the first week of September. If that date causes anyone problems (if you want to finish something and get it in before the string freeze), let me know. Do you mean the first week that ends in September, or the first full week of September? Phil -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash OSX
2009/8/23 Christian Stimming stimm...@tuhh.de Dear John, Am Sonntag, 23. August 2009 04:39 schrieb John Ralls: On Aug 22, 2009, at 2:44 PM, Charles Day wrote: I believe aqbanking is written for Qt3, so it would have to be patched to compile against Qt4. I did notice instructions in the aqbanking README for building it with QT4, but I haven't tried that yet. I'm the one who has built this qt3-to-qt4 conversion code into the aqbanking package. It should work exactly as described in the README, as it is also used in each and every windows build (MS windows only has qt4). So please give it a try, and if there are any unexpected issues, don't hesitate to contact me. I haven't looked at what would be involved with a Gtk druid/wizard, either, but I still think it would be a better solution. Should be a fairly straightforward (if tedious) matter of replacing the Qt ui calls with Gtk ones in the existing Qt wizard. I'm sorry, but no, this is not the case. The Wizard for the online banking setup is way way too complex to be coded in yet another GUI toolkit quickly. I'd estimate the GUI wizard contains approx. 18 person-months of work by now, of which 9 pm would still be needed when porting it to another toolkit. I'm not saying it were impossible, just it won't be effective or doable with the current pm resources available around here. Again, please give the qt4 instructions a try and contact me on any issues; I think those should work relatively out-of-the-box. Thanks Christian, I might try again too. It has been a few months since I tried last. Perhaps what compiles for Qt4 doesn't necessarily compile for Qt4 for mac quartz. At least, I couldn't get it to compile, but I wasn't willing to play too much with it. Regards, Christian Stimming Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: aqbanking Qt on OSX (was: GnuCash OSX)
On Sun, Aug 23, 2009 at 4:12 PM, John Ralls jra...@ceridwen.us wrote: On Aug 23, 2009, at 1:12 PM, Christian Stimming wrote: Dear John, Am Sonntag, 23. August 2009 04:39 schrieb John Ralls: On Aug 22, 2009, at 2:44 PM, Charles Day wrote: I believe aqbanking is written for Qt3, so it would have to be patched to compile against Qt4. I did notice instructions in the aqbanking README for building it with QT4, but I haven't tried that yet. I'm the one who has built this qt3-to-qt4 conversion code into the aqbanking package. It should work exactly as described in the README, as it is also used in each and every windows build (MS windows only has qt4). So please give it a try, and if there are any unexpected issues, don't hesitate to contact me. Alas, no. I'll work with you privately on the particulars. (This is to save others, Charles in particular, the effort of trying.) Thanks for that, John. There are a few changes I'd hopefully like to get in before the string freeze, if I can find the time. Regards, John Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash OSX
I believe aqbanking is written for Qt3, so it would have to be patched to compile against Qt4. -Charles On Sat, Aug 22, 2009 at 2:15 PM, David Reiser dbrei...@earthlink.netwrote: Except that the bigger problem here is that aqbanking doesn't work with Qt Mac. Although I haven't tried it lately, the aqbanking setup wizard hasn't changed enough for me to expect that it would build successfully with QtMac. Dave On Aug 22, 2009, at 3:33 PM, Bryce Poole wrote: The simplest way to get Qt building on the Mac is to download the Qt SDK. The main page: http://qt.nokia.com/products/qt/downloads The specific Mac page: http://qt.nokia.com/downloads/sdk-mac-os-cpp Regards, Bryce On Fri, Aug 21, 2009 at 10:16 AM, John Rallsjra...@ceridwen.us wrote: On Aug 21, 2009, at 8:32 AM, Charles Day wrote: On Thu, Aug 20, 2009 at 7:44 PM, John Ralls jra...@ceridwen.us wrote: On Aug 20, 2009, at 4:40 PM, Charles Day wrote: Sweet! Since it is built for quartz, does it include aqbanking, and if so, which version of Qt was used? It does include aqbanking, but I haven't yet been able to get aqbanking to compile with Qt, so the wizard isn't available. I think it might work OK with an existing account setup, though. Yes, I believe it should still work fine without a front end if the setup is already there. Sucks if you aren't already set up though. (I haven't been able to get Qt3 or Qt4 for Mac going either.) It occurs to me that since aqbanking has a Gtk+ frontend it should be possible to just write a regular Gnucash druid to set up an aqbanking account. That would be a great benefit for the whole project, not just OSX, because it would get rid of a particularly onerous dependency. Or is my massive ignorance showing? Regards, John Ralls ___ 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 -- David Reiser dbrei...@earthlink.net ___ 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: GnuCash OSX
On Sat, Aug 22, 2009 at 7:39 PM, John Ralls jra...@ceridwen.us wrote: On Aug 22, 2009, at 2:44 PM, Charles Day wrote: I believe aqbanking is written for Qt3, so it would have to be patched to compile against Qt4. I did notice instructions in the aqbanking README for building it with QT4, but I haven't tried that yet. I haven't looked at what would be involved with a Gtk druid/wizard, either, but I still think it would be a better solution. Should be a fairly straightforward (if tedious) matter of replacing the Qt ui calls with Gtk ones in the existing Qt wizard. On a more positive note, the dbi stuff builds more-or-less out as-is, and sqlite3 is shipped with OSX (both Leopard and Tiger). Haven't had time to try running it yet... Now working on Webkit. I'm trying to use the built-in version, as it seems pretty stupid to build another library. Sounds good. The 2.2.9 .dmg worked perfectly for me, by the way. Regards, John Ralls Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash OSX
On Thu, Aug 20, 2009 at 7:44 PM, John Ralls jra...@ceridwen.us wrote: On Aug 20, 2009, at 4:40 PM, Charles Day wrote: On Thu, Aug 20, 2009 at 4:20 PM, John Ralls jra...@ceridwen.us wrote: On Aug 19, 2009, at 5:36 AM, Derek Atkins wrote: Hopefully you can upload the 2.2.9 DMG in the next few days. It's done, with an announcement on the MacOSX/Quartz Wiki page. Perhaps one of the admins could add a link to the main web page as well, and generate some publicity. Sweet! Since it is built for quartz, does it include aqbanking, and if so, which version of Qt was used? It does include aqbanking, but I haven't yet been able to get aqbanking to compile with Qt, so the wizard isn't available. I think it might work OK with an existing account setup, though. Yes, I believe it should still work fine without a front end if the setup is already there. Sucks if you aren't already set up though. (I haven't been able to get Qt3 or Qt4 for Mac going either.) Regards, John Ralls Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash OSX
On Thu, Aug 20, 2009 at 4:20 PM, John Ralls jra...@ceridwen.us wrote: On Aug 19, 2009, at 5:36 AM, Derek Atkins wrote: Hopefully you can upload the 2.2.9 DMG in the next few days. It's done, with an announcement on the MacOSX/Quartz Wiki page. Perhaps one of the admins could add a link to the main web page as well, and generate some publicity. Sweet! Since it is built for quartz, does it include aqbanking, and if so, which version of Qt was used? I'll get 2.3.4 builds going now and get the binaries for that up over the weekend. Regards, John Ralls Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Windows compile errors due to changeset 18237
Derek, this is the localtime_r change. What needs to be done? -Charles On Tue, Aug 4, 2009 at 11:17 PM, James Raehl jimra...@raehls.us wrote: Changeset 18327 causes the following error sequence when compiling under Windows XP. Copied from the nightly Windows build log for 04 Aug 2009: make[5]: Entering directory `/c/soft/gnucash/build/src/gnome-utils' ../../../repos/src/gnome-utils/gnc-date-edit.c: In function `fill_time_popup': ../../../repos/src/gnome-utils/gnc-date-edit.c:467: warning: implicit declaration of function `localtime_r' ../../../repos/src/gnome-utils/gnc-date-edit.c:467: warning: assignment makes pointer from integer without a cast ../../../repos/src/gnome-utils/gnc-date-edit.c: In function `gnc_date_edit_set_time': ../../../repos/src/gnome-utils/gnc-date-edit.c:698: warning: assignment makes pointer from integer without a cast make[5]: *** [gnc-date-edit.lo] Error 1 make[5]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils' make[3]: *** [all] Error 2 make[3]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/soft/gnucash/build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/soft/gnucash/build' make: *** [all] Error 2 I don't think this should be happening. Jim Raehl ___ 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: Windows compile errors due to changeset 18237
On Wed, Aug 5, 2009 at 11:48 AM, Derek Atkins warl...@mit.edu wrote: Charles, #ifndef HAVE_LOCALTIME_R # include localtime_r.h #endif At least this is what's used elsehwere. OK no problem. I've added that in r18238. Jim, try building it again. Sorry, -derek -Charles Quoting Charles Day ceda...@gmail.com: Derek, this is the localtime_r change. What needs to be done? -Charles On Tue, Aug 4, 2009 at 11:17 PM, James Raehl jimra...@raehls.us wrote: Changeset 18327 causes the following error sequence when compiling under Windows XP. Copied from the nightly Windows build log for 04 Aug 2009: make[5]: Entering directory `/c/soft/gnucash/build/src/gnome-utils' ../../../repos/src/gnome-utils/gnc-date-edit.c: In function `fill_time_popup': ../../../repos/src/gnome-utils/gnc-date-edit.c:467: warning: implicit declaration of function `localtime_r' ../../../repos/src/gnome-utils/gnc-date-edit.c:467: warning: assignment makes pointer from integer without a cast ../../../repos/src/gnome-utils/gnc-date-edit.c: In function `gnc_date_edit_set_time': ../../../repos/src/gnome-utils/gnc-date-edit.c:698: warning: assignment makes pointer from integer without a cast make[5]: *** [gnc-date-edit.lo] Error 1 make[5]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils' make[3]: *** [all] Error 2 make[3]: Leaving directory `/c/soft/gnucash/build/src/gnome-utils' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/soft/gnucash/build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/soft/gnucash/build' make: *** [all] Error 2 I don't think this should be happening. Jim Raehl ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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: [MacOSX]Cut, Copy, and Paste in the registers
On Mon, Aug 3, 2009 at 11:51 AM, John Ralls jra...@ceridwen.us wrote: On Aug 3, 2009, at 7:55 AM, Derek Atkins wrote: Hi, John Ralls jra...@ceridwen.us writes: I've figured out why this doesn't work: The register module (and perhaps a couple of others, I haven't looked) implements Cut, Copy, and Paste via gtkselections.c, which in turn depends upon gdkselection(-quartz).c. Unfortunately, gdkselection is an ICCCM (i.e., X-Windows) specific protocol. It might be possible to implement in Cocoa, but it would be a lot of work. It seems to me to be completely unnecessary for registers, where all of the data are strings. Is there any good reason not to rewrite the cut, copy, and paste functions to simply work the same as the main window ones? (If they go away along with the menu-stuffing and callbacks, will the gnc-main-window versions just magically take over?) IIRC (I may be mistaken) the register cut/copy/paste does full transaction copying... But I might be misremembering. Derek, No, it doesn't seem to. One can't even select a whole transaction that way, which I guess is why the Transaction menu has its own cut/copy/paste functions (which work fine under Quartz, by the way). I think John is correct about split and transaction cut/copy/paste. As I recall, the menu item for copying a transaction calls a function in ledger-core/split-register.c that does its copy via a Scheme routine. The clipboard if you will is a Scheme object that is tracked in a static variable defined in the same C file. Same thing for splits. I don't think gtk is involved. Gtk_selection_* is used only in src/register/register-gnome/gnucash-item-edit.c, and appears to be used only for operating on a single element in a transaction or split. Regards, John Ralls -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17459 - gnucash/trunk/src/gnome-utils - Bug #545722: Get the GNCDateEdit control working on Win32 again. Don't assume that the content returned by localtime() will not be changed out fro
Sure, why the heck not? Why didn't I think of that? So this instead, right?
tm_returned = localtime_r(current_time, mtm);
g_return_if_fail(tm_returned != NULL);
And get rid of the next line: mtm = *tm_returned;
On Fri, Jul 31, 2009 at 2:37 PM, Derek Atkins warl...@mit.edu wrote:
Hi,
As I said in my last message, I'm catching up on lots of changesets.
Is there any reason not to use localtime_r() here? We already make
sure it exists by using AC_REPLACE_FUNCS().
-derek
Charles Day ceda...@cvs.gnucash.org writes:
Author: cedayiv
Date: 2008-08-08 19:38:45 -0400 (Fri, 08 Aug 2008)
New Revision: 17459
Trac: http://svn.gnucash.org/trac/changeset/17459
Modified:
gnucash/trunk/src/gnome-utils/gnc-date-edit.c
Log:
Bug #545722: Get the GNCDateEdit control working on Win32 again. Don't
assume that the content returned by localtime() will not be changed out from
under you.
BP
Modified: gnucash/trunk/src/gnome-utils/gnc-date-edit.c
===
--- gnucash/trunk/src/gnome-utils/gnc-date-edit.c 2008-08-08 21:36:48
UTC (rev 17458)
+++ gnucash/trunk/src/gnome-utils/gnc-date-edit.c 2008-08-08 23:38:45
UTC (rev 17459)
@@ -307,7 +307,8 @@
fill_time_popup (GtkWidget *widget, GNCDateEdit *gde)
{
GtkWidget *menu;
- struct tm *mtm;
+ struct tm *tm_returned;
+ struct tm mtm;
time_t current_time;
int i, j;
@@ -318,21 +319,25 @@
gtk_option_menu_set_menu (GTK_OPTION_MENU (gde-time_popup), menu);
time (current_time);
- mtm = localtime (current_time);
+ tm_returned = localtime (current_time);
+ g_return_if_fail(tm_returned != NULL);
+/* The return value points to statically allocated, shared
memory.
+ * Copy the contents so we don't risk unexpected changes. */
+mtm = *tm_returned;
for (i = gde-lower_hour; i = gde-upper_hour; i++){
GtkWidget *item, *submenu;
hour_info_t *hit;
char buffer [40];
- mtm-tm_hour = i;
- mtm-tm_min = 0;
+ mtm.tm_hour = i;
+ mtm.tm_min = 0;
hit = g_new (hour_info_t, 1);
if (gde-flags GNC_DATE_EDIT_24_HR)
- qof_strftime (buffer, sizeof (buffer), %H:00,
mtm);
+ qof_strftime (buffer, sizeof (buffer), %H:00,
mtm);
else
- qof_strftime (buffer, sizeof (buffer), %I:00 %p ,
mtm);
+ qof_strftime (buffer, sizeof (buffer), %I:00 %p ,
mtm);
hit-hour = g_strdup (buffer);
hit-gde = gde;
@@ -351,14 +356,14 @@
for (j = 0; j 60; j += 15){
GtkWidget *mins;
- mtm-tm_min = j;
+ mtm.tm_min = j;
hit = g_new (hour_info_t, 1);
if (gde-flags GNC_DATE_EDIT_24_HR)
qof_strftime (buffer, sizeof (buffer),
- %H:%M, mtm);
+ %H:%M, mtm);
else
qof_strftime (buffer, sizeof (buffer),
- %I:%M %p, mtm);
+ %I:%M %p, mtm);
hit-hour = g_strdup (buffer);
hit-gde = gde;
@@ -529,7 +534,8 @@
void
gnc_date_edit_set_time (GNCDateEdit *gde, time_t the_time)
{
- struct tm *mytm;
+ struct tm *tm_returned;
+ struct tm tm_to_set;
g_return_if_fail (gde != NULL);
g_return_if_fail (GNC_IS_DATE_EDIT (gde));
@@ -545,8 +551,14 @@
else
gde-initial_time = the_time;
- mytm = localtime (the_time);
- gnc_date_edit_set_time_tm(gde, mytm);
+/* Convert time_t to tm. */
+ tm_returned = localtime (the_time);
+ g_return_if_fail(tm_returned != NULL);
+/* The return value points to statically allocated, shared
memory.
+ * Copy the contents so we don't risk unexpected changes. */
+tm_to_set = *tm_returned;
+
+ gnc_date_edit_set_time_tm(gde, tm_to_set);
}
void
___
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: GnuCash OSX
On Sun, Jul 12, 2009 at 5:10 PM, John Ralls jra...@ceridwen.us wrote: On Jul 11, 2009, at 10:57 AM, John Ralls wrote: On Jul 11, 2009, at 10:49 AM, Derek Atkins wrote: Hi, I'm not a fan of /usr/local -- I'd recommend something like /opt/gnucash. How about this: We use something like /opt/gnucash-version and just make that a symlink into wherever GnuCash.App gets put? So when we run GnuCash.App the first thing it does is determine its location and then creates the /opt/gnucash-version symlink? Or maybe we can do this as part of the Install process? Then all the files can still live under GnuCash.App, and the user can still put GnuCash.App wherever they want.. They can even have multiple versions sitting side-by-side.. And all we need is a magic symlink to make it work? What a delightfully sneaky idea! Easy to test out, too. I'll report back. (In my exploration I found some more things that need to get moved into the bundle, so there's a bit more work than just to create the softlink and try it out, and I've got a bunch of real-life stuff to do today.) It works, too! I need to rebuild everything in /opt/gnucash-foo, but if I build app dmgs (one each for intel and ppc, since I'm still having trouble with getting gtk+ to build universal) for 2.2.9, will you guys put them up in your downloads area on sourceforge? I think it makes more sense there than in gtk-osx. Derek, Charles Day either has or is about to commit the patches. Do you need any help setting up your build mac for the daily snapshots? I committed the patches yesterday. Were there any problems with the overnight builds for Linux or Windows? I was able to build GnuCash here with the mac integration features, like menus at the top of the screen instead of inside the GnuCash window. Looks pretty good, just a couple of oddities which John I have been discussing off-list. Now if I could just build aqbanking for quartz instead of X11... I'll have to find some time to try to build qt3-mac or even qt4-mac. I haven't been able to build them in the past. Oh, there is one other thing that I need to go bang on. For some reason in the last month or so Price Editor stopped working, both on 2.2.9 and on svn. Regards John Ralls Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 587843 – Macintosh OSX Quartz Build Inte gration Patches
On Wed, Jul 8, 2009 at 9:10 PM, John Ralls jra...@ceridwen.us wrote: On Jul 8, 2009, at 10:02 AM, Charles Day wrote: On Wed, Jul 8, 2009 at 8:15 AM, Phil Longstaff plongst...@rogers.com wrote: I don't know or use Mac OSX. Can someone who does look over the attachments and tell me whether they are OK to apply to trunk for 2.3.3? I guess you are talking about bug 587843: http://bugzilla.gnome.org/show_bug.cgi?id=587843 I build GnuCash with configure/make/make install at the command line, and against libraries built with MacPorts. So I could apply the patches here and make sure that it at least doesn't break my build. To really test the patches I assume I would have to switch from MacPorts to jhbuild so I can build GTK-OSX. I might try that if I can figure out how to keep my MacPorts build environment at the same time, at least until I can fully switch to jhbuild at a more convenient time. I would like, for the moment, to be able to continue working on register bugs without worrying about a learning curve for a different build tool. I don't use fink but maybe Dave or someone else can test that, even if only to make sure the build doesn't break. Testing to make sure it doesn't break MacPorts Fink is a good idea. I did check them on a Linux VM to make sure I hadn't broken anything (I had, but I fixed it before making the patches.) I applied the patch to configure.in and got an error in the configure step. The details have been added to bug 578843: http://bugzilla.gnome.org/show_bug.cgi?id=587843 If you (or anyone) who has one or the other installed wants to try a gtk-osx build, I think making a new user account with a clean environment (i.e., no trace of MacPorts or Fink in any path) is probably the safest, though I'll admit I haven't tried it. I do get support questions from users pretty often who've had trouble because they didn't completely purge MacPorts or Fink from their systems and jhbuild found the wrong macros or pkg-config or something and went astray. Regards, John Ralls Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 587843 – Macintosh OSX Quartz Build Inte gration Patches
On Wed, Jul 8, 2009 at 8:15 AM, Phil Longstaff plongst...@rogers.comwrote: I don't know or use Mac OSX. Can someone who does look over the attachments and tell me whether they are OK to apply to trunk for 2.3.3? I guess you are talking about bug 587843: http://bugzilla.gnome.org/show_bug.cgi?id=587843 I build GnuCash with configure/make/make install at the command line, and against libraries built with MacPorts. So I could apply the patches here and make sure that it at least doesn't break my build. To really test the patches I assume I would have to switch from MacPorts to jhbuild so I can build GTK-OSX. I might try that if I can figure out how to keep my MacPorts build environment at the same time, at least until I can fully switch to jhbuild at a more convenient time. I would like, for the moment, to be able to continue working on register bugs without worrying about a learning curve for a different build tool. I don't use fink but maybe Dave or someone else can test that, even if only to make sure the build doesn't break. Phil -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Exporting GnuCash to QSF cause program to crash
Yeah, I don't know. It seems weird that the bug would be reported on gtk+ 2.13.x, and patched in 2.13.5, but I still get the crash with 2.14.5. Perhaps it is a slightly different bug, and the gdb backtrace fit the description just well enough to lead me there. Are you using a newer version of gtk+? Were you getting the crash? Or possibly it's a glade bug? As far as the workaround, I didn't really like the way that the information that futures dates aren't supported was semi-hidden in a tooltip. So to me it is a slight improvement anyway. It would be better if the future dates were blocked out on the calendar or something, but I didn't want to spend any more time on it. -Charles On Tue, Jul 7, 2009 at 7:02 AM, Derek Atkins warl...@mit.edu wrote: It looks like this was fixed a year ago (2008-07-06, so a year ago yesterday)! So why are we still having to work around the problem? (Not that I object to having to work around the problem, but I'm curious) -derek Charles Day ceda...@gmail.com writes: I found that the crash no longer occurs if you edit the chart-export.glade file and delete the calendar's tooltip (just delete the entire line containing the words Future dates are not supported). So I think it is this bug: http://bugzilla.gnome.org/show_bug.cgi?id=539248 I'll be making a patch for trunk. -Charles On Mon, Jun 15, 2009 at 4:54 PM, Charles Day ceda...@gmail.com wrote: QSF export seems to work fine if you use the keyboard to pick the calendar day. The mouse can actually be used to switch the month or year, but it can't get anywhere near the numbers. Possibly it is this bug? http://bugzilla.gnome.org/show_bug.cgi?id=539248 -Charles On Mon, Jun 15, 2009 at 8:02 AM, Derek Atkins warl...@mit.edu wrote: I agree it should be disabled for 2.4.0. I think it should remain on for 2.3.x in case people still want to test it. -derek Quoting Phil Longstaff plongst...@rogers.com: I suggest that this be disabled for 2.3.X/2.4.0 until it can either be fixed or else replaced with something that works. The various QSF export bugs can be resolved, and a new enhancement request for an information export mechanism can be created. Phil From: Derek Atkins warl...@mit.edu To: John Wilson Diane Martin jwilsondmar...@gmail.com Cc: gnucash-u...@gnucash.org Sent: Monday, June 15, 2009 10:39:09 AM Subject: Re: Exporting GnuCash to QSF cause program to crash Hi, John Wilson Diane Martin jwilsondmar...@gmail.com writes: I am in the process of preparing figures for my accountant and would like to export a set of books to QSF so she can read them. When I go FileExportExport Chart of Accounts to QSF Gnucash crashes. Regards, John Wilson I'm not at all surprised. The QSF really isn't useful, there are known bugs in it, and it's really not supported. You'll notice that there's no QSF Import either, and pretty much nothing in the world supports QSF. So... it's not surprising this fails.. You have a few options to send your data to your accountant, but I would recommend you use GnuCash2QIF. Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. -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-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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.edu
Re: Exporting GnuCash to QSF cause program to crash
I found that the crash no longer occurs if you edit the chart-export.glade file and delete the calendar's tooltip (just delete the entire line containing the words Future dates are not supported). So I think it is this bug:http://bugzilla.gnome.org/show_bug.cgi?id=539248 I'll be making a patch for trunk. -Charles On Mon, Jun 15, 2009 at 4:54 PM, Charles Day ceda...@gmail.com wrote: QSF export seems to work fine if you use the keyboard to pick the calendar day. The mouse can actually be used to switch the month or year, but it can't get anywhere near the numbers. Possibly it is this bug? http://bugzilla.gnome.org/show_bug.cgi?id=539248 -Charles On Mon, Jun 15, 2009 at 8:02 AM, Derek Atkins warl...@mit.edu wrote: I agree it should be disabled for 2.4.0. I think it should remain on for 2.3.x in case people still want to test it. -derek Quoting Phil Longstaff plongst...@rogers.com: I suggest that this be disabled for 2.3.X/2.4.0 until it can either be fixed or else replaced with something that works. The various QSF export bugs can be resolved, and a new enhancement request for an information export mechanism can be created. Phil From: Derek Atkins warl...@mit.edu To: John Wilson Diane Martin jwilsondmar...@gmail.com Cc: gnucash-u...@gnucash.org Sent: Monday, June 15, 2009 10:39:09 AM Subject: Re: Exporting GnuCash to QSF cause program to crash Hi, John Wilson Diane Martin jwilsondmar...@gmail.com writes: I am in the process of preparing figures for my accountant and would like to export a set of books to QSF so she can read them. When I go FileExportExport Chart of Accounts to QSF Gnucash crashes. Regards, John Wilson I'm not at all surprised. The QSF really isn't useful, there are known bugs in it, and it's really not supported. You'll notice that there's no QSF Import either, and pretty much nothing in the world supports QSF. So... it's not surprising this fails.. You have a few options to send your data to your accountant, but I would recommend you use GnuCash2QIF. Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. -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-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Old bug still exists...
Does the bug are you referring to exist in bugzilla? What is the message that pops up? It sounds like one of the bugs that I fixed a while ago, but I believe the fix is only available in trunk and in versions 2.3.x. -Charles On Fri, Jul 3, 2009 at 7:04 AM, C. Andrews Lavarre alava...@lavarre.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, thank you for your mailing list. I have this problem and googling shows only this thread addressing it, so it must be rather anomalous... :-( I am on SuSE 11.1 (the latest) Linux with all the relevant repositories I can find. I've also downloaded and installed GnuCash manually, so am now on GnuCash 2.2.7, build from R17597M on 2008-12-03, well past the revisions cited below. But the bug is still there. I can see no precise pattern for its occurrence, nor can I deliberately replicate it. But it occurs frequently, if randomly. What happens is that I am entering a number of transactions. After a varying number of entries (one the first time today, eight the next time) and a varying amount of time suddenly the automatic recall of a common entry (e.g., Grocery Store Living:Food... does not pop up the account. If I try to leave the transaction (arrow up) I get the message. Similarly, trying to save the transaction renders the same message. It does not crash and I can then save the account, but I have to close the account and reopen the account. Then it goes on and works for a while, until they cycle repeats. Am I missing something? Thanks in advance, Andy Lavarre === Re: eek, disaster bug! Thomas Bushnell BSG Sun, 15 Oct 2006 00:17:58 -0700 Chris Shoemaker [EMAIL PROTECTED] writes: Thanks for the error reports. This bug has been #1 on my hit-list for a while, but I hadn't been able to reproduce it. It turns out that the unable to delete split behavior was a big clue, and something I could finally reproduce. I'm hoping that these bug(s) have been fixed by r15002 and r15004. I'm glad to report that this solves the bug, as far as what I had encountered. Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpOD/MACgkQQtZ89rjmrG19pwCgprUlvqaCoc/BD0g7FeHL56Hy nRoAnR0/StsXhFlReWsZfaxil/1m7m1Q =vpda -END PGP SIGNATURE- ___ 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: Old bug still exists...
Perhaps you mean bug 426111?http://bugzilla.gnome.org/show_bug.cgi?id=426111 On Fri, Jul 3, 2009 at 9:32 AM, Charles Day ceda...@gmail.com wrote: Does the bug are you referring to exist in bugzilla? What is the message that pops up? It sounds like one of the bugs that I fixed a while ago, but I believe the fix is only available in trunk and in versions 2.3.x. -Charles On Fri, Jul 3, 2009 at 7:04 AM, C. Andrews Lavarre alava...@lavarre.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, thank you for your mailing list. I have this problem and googling shows only this thread addressing it, so it must be rather anomalous... :-( I am on SuSE 11.1 (the latest) Linux with all the relevant repositories I can find. I've also downloaded and installed GnuCash manually, so am now on GnuCash 2.2.7, build from R17597M on 2008-12-03, well past the revisions cited below. But the bug is still there. I can see no precise pattern for its occurrence, nor can I deliberately replicate it. But it occurs frequently, if randomly. What happens is that I am entering a number of transactions. After a varying number of entries (one the first time today, eight the next time) and a varying amount of time suddenly the automatic recall of a common entry (e.g., Grocery Store Living:Food... does not pop up the account. If I try to leave the transaction (arrow up) I get the message. Similarly, trying to save the transaction renders the same message. It does not crash and I can then save the account, but I have to close the account and reopen the account. Then it goes on and works for a while, until they cycle repeats. Am I missing something? Thanks in advance, Andy Lavarre === Re: eek, disaster bug! Thomas Bushnell BSG Sun, 15 Oct 2006 00:17:58 -0700 Chris Shoemaker [EMAIL PROTECTED] writes: Thanks for the error reports. This bug has been #1 on my hit-list for a while, but I hadn't been able to reproduce it. It turns out that the unable to delete split behavior was a big clue, and something I could finally reproduce. I'm hoping that these bug(s) have been fixed by r15002 and r15004. I'm glad to report that this solves the bug, as far as what I had encountered. Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpOD/MACgkQQtZ89rjmrG19pwCgprUlvqaCoc/BD0g7FeHL56Hy nRoAnR0/StsXhFlReWsZfaxil/1m7m1Q =vpda -END PGP SIGNATURE- ___ 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
Register design question
I have a question about the register design. I've looked through the .h files are this doesn't seem to be addressed. Background: The register has a whole bunch of different cells. For example there is a cell for a posting date, one for a check number, one for an account, and so on. Depending which type of row you are currently on, only some of these cells are contained in the current cursor. For example, in transaction journal mode if you are on a split row then the account cell is in the current cursor but the posting date is not (instead it is part of a separate cursor for the transaction row). At any time it is possible to look up the value of the posting date cell, but if you are currently sitting on a split row, then the posting date cell contains the posting date of the last transaction row visited, which *might* not have been the same transaction that your current split belongs to. Have I lost you yet? Because I'm wondering if this is the way it is supposed to be. There would seem to be two possibilities: 1. You are not supposed to assume that cells outside the current cursor are valid. So when you are on a split row, all cells that are not in the split cursor, such as transaction-level cells like the posting date, should not be trusted. 2. All cells are supposed to be up-to-date, even if they are not part of the current cursor. This would mean that when the user tries to move from a split row in transaction A to a split row in transaction B, you'd have to first visit (programmatically) the cursor of transaction B to make sure all the transaction-related cells are up-to-date, then move on to the split the user wanted. Does anyone know which is correct? Most of the code that looks up cell values seems to either observe #1 or works either way, but there is one spot involved in bug 567709 that definitely assumes #2. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register bugs in bugzilla
I fine with that change if it suits David. However I have been almost completely saturated with other work in the past few months and so unable to contribute as actively as before. GnuCash bugs that I would have turned around in 24 hours in the past are taking weeks now. So I just want to make sure the expectations are not too high, since there are lots of outstanding register bugs. This crunch will pass, though. My other concern is that although I may have been the most active developer in the register area over the past year, I really only know the bits I have worked on, which is the stuff in register/ledger-core. I am fairly clueless with register/register-core and register/register-gnome, though I have dipped my toes for a couple of the display/redraw bugs. Cheers, Charles On Wed, Jun 24, 2009 at 7:01 AM, Phil Longstaff plongst...@rogers.comwrote: Charles, you seem to be the person who has done the most work on the gnucash register code lately. Do you want to be set as the default assignee or QA contact for the Register component? David, do you want to be removed? Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Exporting GnuCash to QSF cause program to crash
QSF export appears to work fine for me if I just avoid moving the mouse pointer into the calendar control. For some reason, if I put the mouse into the calendar then it crashes inside some internal calendar function (gtk_calendar_get_detail). I don't see how this would be a GnuCash problem, as there are not even any callbacks or properties set on the GtkCalendar widget. I can only guess that something is wrong with either glade or gtk+. -Charles On Mon, Jun 15, 2009 at 8:02 AM, Derek Atkins warl...@mit.edu wrote: I agree it should be disabled for 2.4.0. I think it should remain on for 2.3.x in case people still want to test it. -derek Quoting Phil Longstaff plongst...@rogers.com: I suggest that this be disabled for 2.3.X/2.4.0 until it can either be fixed or else replaced with something that works. The various QSF export bugs can be resolved, and a new enhancement request for an information export mechanism can be created. Phil From: Derek Atkins warl...@mit.edu To: John Wilson Diane Martin jwilsondmar...@gmail.com Cc: gnucash-u...@gnucash.org Sent: Monday, June 15, 2009 10:39:09 AM Subject: Re: Exporting GnuCash to QSF cause program to crash Hi, John Wilson Diane Martin jwilsondmar...@gmail.com writes: I am in the process of preparing figures for my accountant and would like to export a set of books to QSF so she can read them. When I go FileExportExport Chart of Accounts to QSF Gnucash crashes. Regards, John Wilson I'm not at all surprised. The QSF really isn't useful, there are known bugs in it, and it's really not supported. You'll notice that there's no QSF Import either, and pretty much nothing in the world supports QSF. So... it's not surprising this fails.. You have a few options to send your data to your accountant, but I would recommend you use GnuCash2QIF. Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. -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-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Exporting GnuCash to QSF cause program to crash
QSF export seems to work fine if you use the keyboard to pick the calendar day. The mouse can actually be used to switch the month or year, but it can't get anywhere near the numbers. Possibly it is this bug? http://bugzilla.gnome.org/show_bug.cgi?id=539248 -Charles On Mon, Jun 15, 2009 at 8:02 AM, Derek Atkins warl...@mit.edu wrote: I agree it should be disabled for 2.4.0. I think it should remain on for 2.3.x in case people still want to test it. -derek Quoting Phil Longstaff plongst...@rogers.com: I suggest that this be disabled for 2.3.X/2.4.0 until it can either be fixed or else replaced with something that works. The various QSF export bugs can be resolved, and a new enhancement request for an information export mechanism can be created. Phil From: Derek Atkins warl...@mit.edu To: John Wilson Diane Martin jwilsondmar...@gmail.com Cc: gnucash-u...@gnucash.org Sent: Monday, June 15, 2009 10:39:09 AM Subject: Re: Exporting GnuCash to QSF cause program to crash Hi, John Wilson Diane Martin jwilsondmar...@gmail.com writes: I am in the process of preparing figures for my accountant and would like to export a set of books to QSF so she can read them. When I go FileExportExport Chart of Accounts to QSF Gnucash crashes. Regards, John Wilson I'm not at all surprised. The QSF really isn't useful, there are known bugs in it, and it's really not supported. You'll notice that there's no QSF Import either, and pretty much nothing in the world supports QSF. So... it's not surprising this fails.. You have a few options to send your data to your accountant, but I would recommend you use GnuCash2QIF. Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. -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-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash OSX
On Thu, Jun 11, 2009 at 12:56 PM, John Ralls jra...@ceridwen.us wrote: On Jun 11, 2009, at 11:26 AM, Derek Atkins wrote: Hi, I noticed that you've done a lot of work on a semi-standalone GnuCash application for OSX. Could you perhaps come over to gnucash-devel or the #gnucash irc channel so we can talk about setting up an OSX Build Server? I'd like to work with you to integrate your osx work into the GnuCash source tree and then we can start to produce daily builds! Of course, we'd need to try to solve the gconf/glade/guile hardcoded-path issue somehow.. Are you interested?? Thanks, -derek Hello. I'm flattered, and interested. It didn't even occur to me that you guys would be interested in making GnuCash portable to OSX. (For those who don't know, I've been publishing at http://wiki.gnucash.org/wiki/MacOSX/Quartz instructions for building GnuCash as a native app on OSX, using Richard Hult's gtk-osx-build project. I've recently taken that over, too, along with some related stuff and consolidated it at gtk-osx.sourceforge.net -- which is down at the moment, but you can get to the project page at http://sourceforge.net/projects/gtk-osx/) I'm presently have 3 patches to gnucash itself: - Remove AC_CHECK_HEADERS of X11/Xlib.h - Modify the gnucash.in batch file template to set up the environment correctly and start Dbus - Incorporate the gnucash menus into the Mac menubar. Only one of them (the last) is ready to go, but the other two only need to be guarded so that they work only when building against gtk-quartz. I have written but not yet tested a patch to binreloc.c which should allow binreloc to work correctly with a mac application bundle. I've looked at dbus, and I see that its hardcoded path (to the machine-id file) can be easily fixed up to look in the bundle as well. Are there more hard-coded paths that I don't yet know about? Derek, you mention daily builds. Do you have a mac available in your build farm? Hmm, the other thing that you should be aware of is that the gtk-osx-build setup doesn't at present do universal binaries. Dunno if that matters. One other outstanding issue is that, to my knowledge, AqBanking isn't available when compiling for quartz since the AqBanking GUI requires qt3, which requires X11. I don't know how hard it would be to build AqBanking using quartz versions of Qt instead (qt3-mac or qt4-mac on MacPorts). Regards, John Ralls -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash OSX
On Sat, Jun 13, 2009 at 5:22 PM, John Ralls jra...@ceridwen.us wrote: On Jun 13, 2009, at 11:10 AM, Charles Day wrote: One other outstanding issue is that, to my knowledge, AqBanking isn't available when compiling for quartz since the AqBanking GUI requires qt3, which requires X11. I don't know how hard it would be to build AqBanking using quartz versions of Qt instead (qt3-mac or qt4-mac on MacPorts). -Charles Well, Gnucash builds just fine with aqbanking support turned on, and aqbanking builds with the following options: --enable-ofx=yes --disable-qt3 --disable-kde --disable-chipcard-client --with-backends=aqhbci aqdtaus aqofxconnect --with-frontends=cbanking g2banking. Gnucash's Actions menu has the online actions menu, but the Tools menu lacks the HBCI setup item. Right, sorry I should have been clearer. You can build with aqbanking for quartz but you get no frontend for it. So you can only use it if you have previously configured it somehow. If I recall correctly, the cbanking and g2banking frontends no longer exist in AqBanking. Aqbanking builds commandline tools aqbanking-tool and aqhbci-tool, which I expect allow you to configure your banks, though I will admit that I haven't tried yet. No, me either. If that works, it could be a workaround. But obviously it would much nicer to use the GUI. I suppose that it's worth trying to get it working with QT, but I don't really have time right now to do it. FWIW, QT3 doesn't seem to happily build against Leopard, and generally speaking QT4 and QT3 aren't compatible. Me either... and as I recall, I couldn't build qt3-mac or qt4-mac with MacPorts, so I don't even have a chance of trying to patch and compile AqBanking against one of them. :( Regards, John Ralls -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Common code indentation (follow-up to 2007 discussion)
On Mon, Jun 8, 2009 at 8:14 AM, Christian Stimming stimm...@tuhh.de wrote:
Zitat von Derek Atkins warl...@mit.edu:
Charles Day ceda...@gmail.com writes:
I strongly prefer -bl to -br.
Me too. I prefer:
if ()
{
}
else
{
...
}
Agreed by me. I already wrote the same thing in 2007 [1]: I prefer -bl
-bli0 over the proposed options. If this is a somewhat majority opinion
here, we should surely use those options instead.
Cool! And if we use -bl, then definitely -bli0 or I will be hopelessly
confused!
However I do like:
do
{
...
} while (...);
This is already included by -ce -cdw.
This is my preference as well.
-Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Common code indentation (follow-up to 2007 discussion)
2009/6/5 Christian Stimming stimm...@tuhh.de
Now that we've come back to working on one single branch (trunk), we should
reconsider the idea from back in 2007: We should re-indent the whole code
into one single indentation scheme. See
http://lists.gnucash.org/pipermail/gnucash-devel/2007-March/020099.html
Quote from there: I'd like to propose the following indent options.
Indentation
-nutNo tabs. Indentation is done with spaces.
-i4 Add four spaces for each indent level
-ci4Continuation lines are indented by four spaces
-cli4 Case labels are indented by four spaces
-ppi4 Nested pre-processor defines are indented by four spaces
-nbcDo not force newlines after commas in declarations (default)
-nbfda Don´t put each argument in a function declaration
on a separate line (default)
-lp Line up continued lines at parentheses (default)
-pslPut the type of a procedure on the line before its name.
-bboPrefer to break long lines before boolean operators.
Blank Lines
-nsob Do not swallow optional blank lines (default)
-badForce a blank line after a declaration.
-bbbForce a blank line before a block comment.
-bapForce blank lines after procedure bodies.
Comments
-fcaReformat all comments except those starting in column 1
-fc1Reformat comments starting in column 1
-sc Continuation lines in a comments start with a '*'
[Added from discussion:]
-lc80 Comment line width of 80
Statements
-npcs Do not put space after the function in function calls.
-nprs Do not put a space after every ´(´ and before every ´)´.
-ncsDo not put a space after cast operators.
-safPut a space after each for.
-saiPut a space after each if.
-sawPut a space after each while.
[Added from discussion:]
-ss On one-line for and while statments, force a blank before the
semicolon.
-brsPut braces on struct declaration line.
-br Put braces on line with if, etc.
-ce Cuddle else and preceeding `}´.
-cdwCuddle while of do {} while; and preceeding `}´.
Other
-l80Line width of 80.
[Discussion ended unclear on this one. Maybe -l95 instead.]
If this is agreed upon, someone needs to actually apply this patch. (I'm
rather short on time to do this, but would do it if nobody else steps up.)
I strongly prefer -bl to -br. Easier to visually match parens makes it
easier to read, harder to make mistakes. It adds lines, but is worth it in
my opinion. I like the rest, though personally I prefer two spaces for
indents rather than four. It helps reduce line breaks and I still find it
quite readable.
Just my 0.02,
Charles
In any case, right now is a good time to do this, so we should do it.
Regards,
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Win32 Daily Builds available
On Mon, Jun 1, 2009 at 7:04 PM, Phil Longstaff plongst...@rogers.comwrote: On June 1, 2009 12:02:20 pm Jonathan wrote: On 6/1/2009 12:41 AM, Derek Atkins wrote: Hey all, I've got Win32 daily builds available now. The build log and the setup.exe are available at: http://code.gnucash.org/builds/ Please be kind to my bandwidth; these are for testing only and NOT meant for public consumption. Use of these setup files may cause your computer to spontaneously combust or turn your brain into goo for the Hulu(R) aliens. I just installed today's build on Vista x64 and got this This application has failed to start because libwebkit-1.0-2.dll was not found. Re-installing the application may fix this problem. I just committed r18100 which should fix this. Assuming this change went into last night's build, can anyone verify that the problem is fixed for them? Phil -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Win32 Daily Builds available
On Tue, Jun 2, 2009 at 8:19 AM, Derek Atkins warl...@mit.edu wrote: Quoting Charles Day ceda...@gmail.com: I just committed r18100 which should fix this. Assuming this change went into last night's build, can anyone verify that the problem is fixed for them? Looks like Christian kicked off a second build, there are two from last night: gnucash-2.3.0-svn-r18100-setup.exe and gnucash-2.3.0-svn-r18101-setup.exe Cool. If someone can verify that it installs fires up on Windows, I want to ask a few users to verify bug fixes for display issues. By the way, in r18101 it looks like Christian not only removed the aqbanking patch, but removed the option to even have one (see changes to packaging/win32/install.sh). Any idea why? -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Make problem on trunk
I can't make trunk. This must be something small. Any ideas? Cheers, Charles Making all in pixmaps make[3]: *** No rule to make target `16x16/gnucash-icon.png', needed by `all-am'. Stop. make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: sorting of transactions within day
2009/4/29 Christian Stimming stimm...@tuhh.de Am Dienstag, 28. April 2009 13:54 schrieb marcus.wolsc...@googlemail.com: Hello, what sorting is used for the transactions within a single day? I would like to make sure the transactions get the same sorting-order they have on the bank-account to make comparing both easier for the user. Could this be done my modifying the time in the postedDate or should I look somewhere else? I think the intra-day sorting is indeed the time-of-day of the posted-date. Well, I don't really know, but I vaguely recall something along these lines :-) Are we talking about the order they display in the register? Because there is View-Sort By. The standard sort is first by transaction (according to posting date, followed by number, entry date/time, description), and then by split memo, split action, split reconcile status, split amount, split value, and finally split reconcile date. -Charles Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla
On Fri, Apr 24, 2009 at 6:10 AM, Phil Longstaff plongst...@rogers.comwrote: I'm starting to go through bugzilla and see what's there. Any bug marked RESOLVED from before 2008, I will mark VERIFIED, just to get them out of our way. There are bugs from pre 2.0 with requests to see if they can be reproduced with 2.X. I think they should just be closed, and reopened if they happen again. How should bugs be handled if they are fixed in trunk with the fix to be released in the upcoming 2.3.x? There are a number of bugs that Charles Day has commented on re a fix in trunk that should handle it. That's what I wondered too. I was told to mark them resolved with a target release of 2.3.x. I'm not sure what is supposed to happen to them once 2.3.x is out, but at least they disappear from my bug searches now. ;) Phil -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.2.6 - problems with qif import
One final question before I add support for Oth S to the QIF importer. Were you seeing this on a !Type line, like !Type:Oth S? Or was it a T line, like TOth S? Thanks, Charles On Tue, Apr 21, 2009 at 7:05 AM, Charles Day ceda...@gmail.com wrote: OK, so I'll make the QIF importer treat Oth S (German Quicken) the same as Oth A (English Quicken). Thanks, Charles On Tue, Apr 21, 2009 at 6:52 AM, Herbert Thoma herbert.th...@iis.fraunhofer.de wrote: Charles Day schrieb: I see this also discussed here: http://www.wiso-software.de/forum/index.php?page=ThreadpostID=91169 What does Vermögenskonten mean? I am just trying figure out which GnuCash account type is the closest/best match. The generic asset type? Or bank? Vermögenskonten literally translates to asset accounts Herbert. Cheers, Charles On Mon, Apr 20, 2009 at 10:57 PM, and78...@gmx.de and78...@gmx.de wrote: Quicken 2009 German. Don't know what Oth S means, both were bank accounts, so i don't know why the qif export of Quicken interpreted them as Oth S. Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Which version of Quicken are you using? German? Does Oth S mean asset? Or is it liability? I can add support for this to the QIF importer. Cheers, Charles On Mon, Apr 20, 2009 at 5:00 PM, and78...@gmx.de and78...@gmx.de wrote: Just looked in my qif file again and it's Oth S that makes problems when importing into gnucash 2.2.6! Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Do you really mean Oth S? Or do you mean Oth A? We know that Oth A isn't working right in 2.2.9 and it has been fixed (but not released.) -Charles On Mon, Apr 20, 2009 at 3:32 PM, and78...@gmx.de and78...@gmx.de wrote: I solved my problem in 2.2.6 now. After importing the Quicken 2009 qif file the properties of one bank account was wrong, and therefore the deposit and withdrawal values were interchanged. Correcting it to bank and this problem was solved. Other problems in 2.2.6 with qif import: - account property Oth S has to be corrected manually to Bank in qif file before import - deletion of double bookings manually after import Now all balances are exactly the same in gnucash like they were in Quicken, so everything ok. Thanks for such a great piece of software and for the good support!!! Cheers, Andreas 2009/4/20 Charles Day ceda...@gmail.com I wonder if there is not something wrong other than the version. I think very little changed in the QIF import after 2.2.6. Certainly nothing I can think of that would have this kind of result. Andreas, did you import multiple QIF files? If so, did you import them together or separately? Could you pick a specific transaction that was imported into GnuCash incorrectly, and show the actual QIF data that it came from? Cheers, Charles On Mon, Apr 20, 2009 at 7:45 AM, Derek Atkins warl...@mit.edu wrote: Safer than trying to continue to use the broken 2.2.6-3 package. -derek and78...@gmx.de and78...@gmx.de writes: Ok, but how safe and stable are such packages from foreign repositories? Could they harm my system? 2009/4/18 Cristian Marchi cr...@libero.it Hi Derek, Ubuntu 8.10 is only available with gnucash 2.2.6. How do i update gnucash to 2.2.9 on Ubuntu 8.10? I don't use Ubuntu. Either find a repository that has it, or build from source. But 2.2.6 is old and there have been many QIF fixes. You can find a GnuCash 2.2.9 deb package for intrepid on http://www.getdeb.net; I tested it and on my system works well. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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: gnucash 2.2.6 - problems with qif import
On Thu, Apr 23, 2009 at 12:33 PM, and78...@gmx.de and78...@gmx.de wrote: Both and the Oth S was shown at two different positions in the qif file: *^ !Account NExtra-Konto TOth S ^ !Type:Oth S* and *^ NExtra-Konto TOth S* Hope this helps! Perfect, thanks. I've added support for this to the QIF importer in trunk (in r18055). Cheers, Charles Cheers, Andreas 2009/4/23 Charles Day ceda...@gmail.com One final question before I add support for Oth S to the QIF importer. Were you seeing this on a !Type line, like !Type:Oth S? Or was it a T line, like TOth S? Thanks, Charles On Tue, Apr 21, 2009 at 7:05 AM, Charles Day ceda...@gmail.com wrote: OK, so I'll make the QIF importer treat Oth S (German Quicken) the same as Oth A (English Quicken). Thanks, Charles On Tue, Apr 21, 2009 at 6:52 AM, Herbert Thoma herbert.th...@iis.fraunhofer.de wrote: Charles Day schrieb: I see this also discussed here: http://www.wiso-software.de/forum/index.php?page=ThreadpostID=91169 What does Vermögenskonten mean? I am just trying figure out which GnuCash account type is the closest/best match. The generic asset type? Or bank? Vermögenskonten literally translates to asset accounts Herbert. Cheers, Charles On Mon, Apr 20, 2009 at 10:57 PM, and78...@gmx.de and78...@gmx.de wrote: Quicken 2009 German. Don't know what Oth S means, both were bank accounts, so i don't know why the qif export of Quicken interpreted them as Oth S. Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Which version of Quicken are you using? German? Does Oth S mean asset? Or is it liability? I can add support for this to the QIF importer. Cheers, Charles On Mon, Apr 20, 2009 at 5:00 PM, and78...@gmx.de and78...@gmx.de wrote: Just looked in my qif file again and it's Oth S that makes problems when importing into gnucash 2.2.6! Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Do you really mean Oth S? Or do you mean Oth A? We know that Oth A isn't working right in 2.2.9 and it has been fixed (but not released.) -Charles On Mon, Apr 20, 2009 at 3:32 PM, and78...@gmx.de and78...@gmx.de wrote: I solved my problem in 2.2.6 now. After importing the Quicken 2009 qif file the properties of one bank account was wrong, and therefore the deposit and withdrawal values were interchanged. Correcting it to bank and this problem was solved. Other problems in 2.2.6 with qif import: - account property Oth S has to be corrected manually to Bank in qif file before import - deletion of double bookings manually after import Now all balances are exactly the same in gnucash like they were in Quicken, so everything ok. Thanks for such a great piece of software and for the good support!!! Cheers, Andreas 2009/4/20 Charles Day ceda...@gmail.com I wonder if there is not something wrong other than the version. I think very little changed in the QIF import after 2.2.6. Certainly nothing I can think of that would have this kind of result. Andreas, did you import multiple QIF files? If so, did you import them together or separately? Could you pick a specific transaction that was imported into GnuCash incorrectly, and show the actual QIF data that it came from? Cheers, Charles On Mon, Apr 20, 2009 at 7:45 AM, Derek Atkins warl...@mit.edu wrote: Safer than trying to continue to use the broken 2.2.6-3 package. -derek and78...@gmx.de and78...@gmx.de writes: Ok, but how safe and stable are such packages from foreign repositories? Could they harm my system? 2009/4/18 Cristian Marchi cr...@libero.it Hi Derek, Ubuntu 8.10 is only available with gnucash 2.2.6. How do i update gnucash to 2.2.9 on Ubuntu 8.10? I don't use Ubuntu. Either find a repository that has it, or build from source. But 2.2.6 is old and there have been many QIF fixes. You can find a GnuCash 2.2.9 deb package for intrepid on http://www.getdeb.net; I tested it and on my system works well. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Herbert Thoma Dipl.-Ing., MBA Head of Video Group Multimedia Realtime
Re: gwenhywfar-3.6.0.tar.gz not found
The way the script checks to see if the file has already been downloaded is to do`basename $URL` and see if that exists in the download directory. But that doesn't work with the gwen URL since it ends in =gwenhywfar-3.6.0.tar.gz rather than the expected /gwenhywfar-3.6.0.tar.gz. So that check will always fail and the script will always try to download. -Charles On Thu, Apr 23, 2009 at 8:24 PM, Andrew Sackville-West and...@swclan.homelinux.org wrote: On Fri, Apr 24, 2009 at 08:45:08AM +1000, Stephen Grant Brown wrote: Hi Martin All [...] ++ wget --passive-ftp -c ' http://www.aquamaniac.de/sites/download/download.php?package=01release=17file=01dummy=gwenhywfar-3.6.0.tar.gz ' -P /Z/soft/tmp --08:32:12-- http://www.aquamaniac.de/sites/download/download.php?package=01release=17file=01dummy=gwenhywfar-3.6.0.tar.gz = `z:/soft/tmp/download@package =01release=17file=01dummy=gwenhywfar-3.6.0.tar.gz' Resolving www.aquamaniac.de... 81.169.145.75 Connecting to www.aquamaniac.de[81.169.145.75]:80... connected. HTTP request sent, awaiting response... 404 08:32:13 ERROR 404: (no description). gnuc...@elshadai ~/Packaging $ ls /z/GNUCash_Downloads/gwen* /z/GNUCash_Downloads/gwenhywfar-2.6.2.tar.gz /z/GNUCash_Downloads/gwenhywfar-3.6.0.tar.gz /z/GNUCash_Downloads/gwenhywfar-3.4.1.tar.gz /z/GNUCash_Downloads/gwenhywfar-3.7.2.tar.gz $ -- If I have /z/GNUCash_Downloads/gwenhywfar-3.6.0.tar.gz already downloaded, does install.sh need to go to internet to get it? I really know nothing about this stuff on windows, but is it a case issue? The above stuff is looking for 'Z', but the downloads are in 'z'... hth, but probably won't. A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknxMQsACgkQaIeIEqwil4Z8EQCgknW1CjjXtjamgu4FFlP534zN 6jgAoOR+8tt6mDU/h+hbTJYAKEVfrvM1 =nQA7 -END PGP SIGNATURE- ___ 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: gwenhywfar-3.6.0.tar.gz not found
That version of the gwenhywfar package doesn't exist any more, at least not at that URL. You'll need to edit the defaults.sh script (I think) and provide a revised URL, probably for a newer version. Have a look here and see which version you want to try. Maybe 3.8.0? I have no idea. http://www2.aquamaniac.de/sites/download/packages.php -Charles On Tue, Apr 21, 2009 at 2:11 PM, Stephen Grant Brown sg_br...@mcmedia.com.au wrote: Hi All, In msys on a Windows XP machine I downloaded gwenhywfar-3.6.0.tar.gz but still get --- ### Gwenhywfar --06:55:58-- http://www.aquamaniac.de/sites/download/download.php?package=01release=17file=01dummy=gwenhywfar-3.6.0.tar.gz = `z:/soft/tmp/download@package =01release=17file=01dummy=gwenhywfar-3.6.0.tar.gz' Resolving www.aquamaniac.de... 81.169.145.75 Connecting to www.aquamaniac.de[81.169.145.75]:80... connected. HTTP request sent, awaiting response... 404 06:55:59 ERROR 404: (no description). gnuc...@elshadai ~/Packaging --- In Windows Internet Explorer, the http://www.aquamaniac.de/sites/download/download.php?package=01release=17file=01dummy=gwenhywfar-3.6.0.tar.gzpage is not found. Yours Sincerely Stephen Grant Brown ___ 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: gwenhywfar-3.6.0.tar.gz not found
On Wed, Apr 22, 2009 at 9:54 AM, Martin Preuss aquaman...@gmx.de wrote: Hi, On Mittwoch, 22. April 2009, Charles Day wrote: That version of the gwenhywfar package doesn't exist any more, at least not at that URL. You'll need to edit the defaults.sh script (I think) and provide a revised URL, probably for a newer version. Have a look here and see which version you want to try. Maybe 3.8.0? I have no idea. http://www2.aquamaniac.de/sites/download/packages.php [...] 3.8.0 should be fine. This version is source- and binary-compatible to 3.6.0. Thanks, Martin. Adjust your defaults.sh file and let us know it goes. The updated URL should be: http://www2.aquamaniac.de/sites/download/download.php?package=01release=21file=01dummy=gwenhywfar-3.8.0.tar.gz -Charles Regards Martin -- Things are only impossible until they're not Martin Preuss - http://www2.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ___ 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: gwenhywfar-3.6.0.tar.gz not found
It is in your defaults.sh, at or near line 261. Just change the URL, like: if [ $AQBANKING3 != yes ]; then set_default GWENHYWFAR_URL $SF_MIRROR/gwenhywfar/gwenhywfar-2.6.2.tar.gz else set_default GWENHYWFAR_URL http://www.aquamaniac.de/sites/download/download.php?package=01release=21file=01dummy=gwenhywfar-3.8.0.tar.gz set_default GWENHYWFAR_PATCH `pwd`/gwenhywfar-3.6.0-patch.diff fi However, I now see that there is patch needed for version 3.6.0. Since no one has contributed a patch for 3.8.0, you can try it unpatched or maybe duplicate the same changes in 3.6.0. I'm not really familiar -- you'll have to try it and see. Such are the pleasures of compiling on Windows. ;) -Charles On Wed, Apr 22, 2009 at 3:29 PM, Stephen Grant Brown sg_br...@mcmedia.com.au wrote: Hi All Adjust your defaults.sh file and let us know it goes. The updated URL should be: http://www2.aquamaniac.de/sites/download/download.php?package=01release=21file=01dummy=gwenhywfar-3.8.0.tar.gz I hate it when a thought becomes a fact. Some ome thought it was defaults.sh, but it is not. I have searched through install,sh but cannot find gwen*.tar.gz, Yours Sincerely Stephen Grant Brown ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.2.6 - problems with qif import
I see this also discussed here: http://www.wiso-software.de/forum/index.php?page=ThreadpostID=91169 What does Vermögenskonten mean? I am just trying figure out which GnuCash account type is the closest/best match. The generic asset type? Or bank? Cheers, Charles On Mon, Apr 20, 2009 at 10:57 PM, and78...@gmx.de and78...@gmx.de wrote: Quicken 2009 German. Don't know what Oth S means, both were bank accounts, so i don't know why the qif export of Quicken interpreted them as Oth S. Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Which version of Quicken are you using? German? Does Oth S mean asset? Or is it liability? I can add support for this to the QIF importer. Cheers, Charles On Mon, Apr 20, 2009 at 5:00 PM, and78...@gmx.de and78...@gmx.de wrote: Just looked in my qif file again and it's Oth S that makes problems when importing into gnucash 2.2.6! Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Do you really mean Oth S? Or do you mean Oth A? We know that Oth A isn't working right in 2.2.9 and it has been fixed (but not released.) -Charles On Mon, Apr 20, 2009 at 3:32 PM, and78...@gmx.de and78...@gmx.dewrote: I solved my problem in 2.2.6 now. After importing the Quicken 2009 qif file the properties of one bank account was wrong, and therefore the deposit and withdrawal values were interchanged. Correcting it to bank and this problem was solved. Other problems in 2.2.6 with qif import: - account property Oth S has to be corrected manually to Bank in qif file before import - deletion of double bookings manually after import Now all balances are exactly the same in gnucash like they were in Quicken, so everything ok. Thanks for such a great piece of software and for the good support!!! Cheers, Andreas 2009/4/20 Charles Day ceda...@gmail.com I wonder if there is not something wrong other than the version. I think very little changed in the QIF import after 2.2.6. Certainly nothing I can think of that would have this kind of result. Andreas, did you import multiple QIF files? If so, did you import them together or separately? Could you pick a specific transaction that was imported into GnuCash incorrectly, and show the actual QIF data that it came from? Cheers, Charles On Mon, Apr 20, 2009 at 7:45 AM, Derek Atkins warl...@mit.eduwrote: Safer than trying to continue to use the broken 2.2.6-3 package. -derek and78...@gmx.de and78...@gmx.de writes: Ok, but how safe and stable are such packages from foreign repositories? Could they harm my system? 2009/4/18 Cristian Marchi cr...@libero.it Hi Derek, Ubuntu 8.10 is only available with gnucash 2.2.6. How do i update gnucash to 2.2.9 on Ubuntu 8.10? I don't use Ubuntu. Either find a repository that has it, or build from source. But 2.2.6 is old and there have been many QIF fixes. You can find a GnuCash 2.2.9 deb package for intrepid on http://www.getdeb.net; I tested it and on my system works well. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.2.6 - problems with qif import
OK, so I'll make the QIF importer treat Oth S (German Quicken) the same as Oth A (English Quicken). Thanks, Charles On Tue, Apr 21, 2009 at 6:52 AM, Herbert Thoma herbert.th...@iis.fraunhofer.de wrote: Charles Day schrieb: I see this also discussed here: http://www.wiso-software.de/forum/index.php?page=ThreadpostID=91169 What does Vermögenskonten mean? I am just trying figure out which GnuCash account type is the closest/best match. The generic asset type? Or bank? Vermögenskonten literally translates to asset accounts Herbert. Cheers, Charles On Mon, Apr 20, 2009 at 10:57 PM, and78...@gmx.de and78...@gmx.de wrote: Quicken 2009 German. Don't know what Oth S means, both were bank accounts, so i don't know why the qif export of Quicken interpreted them as Oth S. Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Which version of Quicken are you using? German? Does Oth S mean asset? Or is it liability? I can add support for this to the QIF importer. Cheers, Charles On Mon, Apr 20, 2009 at 5:00 PM, and78...@gmx.de and78...@gmx.de wrote: Just looked in my qif file again and it's Oth S that makes problems when importing into gnucash 2.2.6! Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Do you really mean Oth S? Or do you mean Oth A? We know that Oth A isn't working right in 2.2.9 and it has been fixed (but not released.) -Charles On Mon, Apr 20, 2009 at 3:32 PM, and78...@gmx.de and78...@gmx.de wrote: I solved my problem in 2.2.6 now. After importing the Quicken 2009 qif file the properties of one bank account was wrong, and therefore the deposit and withdrawal values were interchanged. Correcting it to bank and this problem was solved. Other problems in 2.2.6 with qif import: - account property Oth S has to be corrected manually to Bank in qif file before import - deletion of double bookings manually after import Now all balances are exactly the same in gnucash like they were in Quicken, so everything ok. Thanks for such a great piece of software and for the good support!!! Cheers, Andreas 2009/4/20 Charles Day ceda...@gmail.com I wonder if there is not something wrong other than the version. I think very little changed in the QIF import after 2.2.6. Certainly nothing I can think of that would have this kind of result. Andreas, did you import multiple QIF files? If so, did you import them together or separately? Could you pick a specific transaction that was imported into GnuCash incorrectly, and show the actual QIF data that it came from? Cheers, Charles On Mon, Apr 20, 2009 at 7:45 AM, Derek Atkins warl...@mit.edu wrote: Safer than trying to continue to use the broken 2.2.6-3 package. -derek and78...@gmx.de and78...@gmx.de writes: Ok, but how safe and stable are such packages from foreign repositories? Could they harm my system? 2009/4/18 Cristian Marchi cr...@libero.it Hi Derek, Ubuntu 8.10 is only available with gnucash 2.2.6. How do i update gnucash to 2.2.9 on Ubuntu 8.10? I don't use Ubuntu. Either find a repository that has it, or build from source. But 2.2.6 is old and there have been many QIF fixes. You can find a GnuCash 2.2.9 deb package for intrepid on http://www.getdeb.net; I tested it and on my system works well. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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: gnucash 2.2.6 - problems with qif import
I wonder if there is not something wrong other than the version. I think very little changed in the QIF import after 2.2.6. Certainly nothing I can think of that would have this kind of result. Andreas, did you import multiple QIF files? If so, did you import them together or separately? Could you pick a specific transaction that was imported into GnuCash incorrectly, and show the actual QIF data that it came from? Cheers, Charles On Mon, Apr 20, 2009 at 7:45 AM, Derek Atkins warl...@mit.edu wrote: Safer than trying to continue to use the broken 2.2.6-3 package. -derek and78...@gmx.de and78...@gmx.de writes: Ok, but how safe and stable are such packages from foreign repositories? Could they harm my system? 2009/4/18 Cristian Marchi cr...@libero.it Hi Derek, Ubuntu 8.10 is only available with gnucash 2.2.6. How do i update gnucash to 2.2.9 on Ubuntu 8.10? I don't use Ubuntu. Either find a repository that has it, or build from source. But 2.2.6 is old and there have been many QIF fixes. You can find a GnuCash 2.2.9 deb package for intrepid on http://www.getdeb.net; I tested it and on my system works well. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF Record and field layouts
On Mon, Apr 20, 2009 at 8:31 AM, Tax Assistance Program - ( taptax ) tap...@nd.edu wrote: Hi everyone, Still trying to get started. I am moving my data from QuickBooks (much different than Quicken) to Gnucash. I can easily export from QB to a tab or csv delimited file. But moving that data into the QIF format will by my challenge. So I am studying what is involved and find that the information re QIF format I found using google is pretty general. I have some sense of what it will look like but nothing specific. For general QIF information, have a look at the information at wikipedia. GnuCash also has a writeup on the QIF format here: http://svn.gnucash.org/trac/browser/gnucash/trunk/src/import-export/qif-import/file-format.txt Where there are differences, I'd tend think the GnuCash document is more accurate. ;) Here are my questions: a)How many record types does QIF support? b)Where do I find the field-by-field layouts for each supported QIF record type? c)What techniques did prior QB users invoke to make the data conversion to QIF? Once I have those answers I am assuming I should be able to transfer my data from QB format to QIF. Has anyone ever converted QB records to Gnucash? Interested in all replies! :) Thanks. Tom Bullock ___ 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: gnucash 2.2.6 - problems with qif import
Do you really mean Oth S? Or do you mean Oth A? We know that Oth A isn't working right in 2.2.9 and it has been fixed (but not released.) -Charles On Mon, Apr 20, 2009 at 3:32 PM, and78...@gmx.de and78...@gmx.de wrote: I solved my problem in 2.2.6 now. After importing the Quicken 2009 qif file the properties of one bank account was wrong, and therefore the deposit and withdrawal values were interchanged. Correcting it to bank and this problem was solved. Other problems in 2.2.6 with qif import: - account property Oth S has to be corrected manually to Bank in qif file before import - deletion of double bookings manually after import Now all balances are exactly the same in gnucash like they were in Quicken, so everything ok. Thanks for such a great piece of software and for the good support!!! Cheers, Andreas 2009/4/20 Charles Day ceda...@gmail.com I wonder if there is not something wrong other than the version. I think very little changed in the QIF import after 2.2.6. Certainly nothing I can think of that would have this kind of result. Andreas, did you import multiple QIF files? If so, did you import them together or separately? Could you pick a specific transaction that was imported into GnuCash incorrectly, and show the actual QIF data that it came from? Cheers, Charles On Mon, Apr 20, 2009 at 7:45 AM, Derek Atkins warl...@mit.edu wrote: Safer than trying to continue to use the broken 2.2.6-3 package. -derek and78...@gmx.de and78...@gmx.de writes: Ok, but how safe and stable are such packages from foreign repositories? Could they harm my system? 2009/4/18 Cristian Marchi cr...@libero.it Hi Derek, Ubuntu 8.10 is only available with gnucash 2.2.6. How do i update gnucash to 2.2.9 on Ubuntu 8.10? I don't use Ubuntu. Either find a repository that has it, or build from source. But 2.2.6 is old and there have been many QIF fixes. You can find a GnuCash 2.2.9 deb package for intrepid on http://www.getdeb.net; I tested it and on my system works well. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.2.6 - problems with qif import
Which version of Quicken are you using? German? Does Oth S mean asset? Or is it liability? I can add support for this to the QIF importer. Cheers, Charles On Mon, Apr 20, 2009 at 5:00 PM, and78...@gmx.de and78...@gmx.de wrote: Just looked in my qif file again and it's Oth S that makes problems when importing into gnucash 2.2.6! Cheers, Andreas 2009/4/21 Charles Day ceda...@gmail.com Do you really mean Oth S? Or do you mean Oth A? We know that Oth A isn't working right in 2.2.9 and it has been fixed (but not released.) -Charles On Mon, Apr 20, 2009 at 3:32 PM, and78...@gmx.de and78...@gmx.de wrote: I solved my problem in 2.2.6 now. After importing the Quicken 2009 qif file the properties of one bank account was wrong, and therefore the deposit and withdrawal values were interchanged. Correcting it to bank and this problem was solved. Other problems in 2.2.6 with qif import: - account property Oth S has to be corrected manually to Bank in qif file before import - deletion of double bookings manually after import Now all balances are exactly the same in gnucash like they were in Quicken, so everything ok. Thanks for such a great piece of software and for the good support!!! Cheers, Andreas 2009/4/20 Charles Day ceda...@gmail.com I wonder if there is not something wrong other than the version. I think very little changed in the QIF import after 2.2.6. Certainly nothing I can think of that would have this kind of result. Andreas, did you import multiple QIF files? If so, did you import them together or separately? Could you pick a specific transaction that was imported into GnuCash incorrectly, and show the actual QIF data that it came from? Cheers, Charles On Mon, Apr 20, 2009 at 7:45 AM, Derek Atkins warl...@mit.edu wrote: Safer than trying to continue to use the broken 2.2.6-3 package. -derek and78...@gmx.de and78...@gmx.de writes: Ok, but how safe and stable are such packages from foreign repositories? Could they harm my system? 2009/4/18 Cristian Marchi cr...@libero.it Hi Derek, Ubuntu 8.10 is only available with gnucash 2.2.6. How do i update gnucash to 2.2.9 on Ubuntu 8.10? I don't use Ubuntu. Either find a repository that has it, or build from source. But 2.2.6 is old and there have been many QIF fixes. You can find a GnuCash 2.2.9 deb package for intrepid on http://www.getdeb.net; I tested it and on my system works well. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Doxygen update?
On Tue, Mar 31, 2009 at 6:37 AM, Derek Atkins warl...@mit.edu wrote: Hi all, On the new server I'm seeing the following message from the nightly doxygen build: Warning: Tag `DETAILS_AT_TOP' at line 154 of file doxygen.cfg has become obsolete. To avoid this warning please update your configuration file using doxygen -u I think this means we need a cfg upgrade? I see the same warning here when building the doxygen docs. As I recall, doxygen -u fixes it (as it indicates). That's all I know though. -Charles -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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GNOME 2: MDI or SDI?
On Mon, Mar 30, 2009 at 8:05 AM, Derek Atkins warl...@mit.edu wrote: Simon Eilting si...@cupcake.is-a-geek.net writes: MDI is way confusing. I always find myself closing the 'main' window when I really want to close a report tab. It should really be all tabs or all windows. The only situation where one would probably want tabs is when they have multiple different views of the accounts tree, or multiple different accounts trees open. Personally I'd like to see the [x] to close on each tab instead of on the toolbar... Sort of like how Firefox does it. At the risk of replying to a 5-year-old reply (in which case, ignore), isn't this already covered with Preferences-Windows-Show close button? Simon. -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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Roadmap / GNC 2.4
On Sat, Mar 21, 2009 at 12:46 PM, Phil Longstaff plongst...@rogers.comwrote: As far as I can tell, there are a number of things that are in trunk or are being developed: 1) libdbi backend - in trunk. I've been using it for a while now. 2) replace gtkhtml with webkit - I've just started on a branch 3) register rewrite - Charles Day has done a lot of work fixing up the register, but the rewrite is stalled (?) 4) change reports from being scm-generated html to html templates with embedded scm - a prototype invoice is in trunk 5) changes to saved reports - Andrew Sackville-West working on it? I propose we start towards a release 2.4 with #1. I think I have enough time to act as release manager, so I volunteer if required. For 2.6 (date TBD), #2 and #4 (replacing all reports) would be a good advance. I don't know enough about #3 or #5 to say anything, but perhaps #2/#4/#5 could go into 2.6 as a (partial) re-architecture of the whole reporting system. Regarding the register, I haven't done any work at all on the register-rewrite branch. Just cleaned up a bunch of crashers and other bugs in the current register. I don't foresee working on register-rewrite until more time has been spent on investments and (possibly) Mac packaging. So I would definitely say 2.4 wouldn't include any register-rewrite stuff, though I may make a few more tweaks to the existing register in the coming days. Thoughts? Phil -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New Splash Screen Graphic
On Sat, Mar 14, 2009 at 9:57 AM, Andrew Sackville-West and...@swclan.homelinux.org wrote: On Sat, Mar 14, 2009 at 12:02:43PM -0400, Andrew Duggan wrote: On Sat, 2009-03-14 at 16:43 +0100, Geert Janssens wrote: On Saturday 14 March 2009, Tynan wrote: Hello, I don't really know anything about open source, but I've been enjoying using GnuCash, and I thought I'd try to help out by making a new splash screen graphic. I have attached it for your consideration. The software is very professional, but the graphic looked cobbled together to me. Tynan I like it ! Geert Clean, crisp and simple. +1 +1 ^ 2 Is it OK to have the names of well-known companies in the graphics? Any issue with the artist putting a credit in the text? (At least it is quite subtle.) -Charles A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm74foACgkQaIeIEqwil4ajZwCfX4ZDzKbQUxkst48NL10SMJTE 3dcAn0+ofZLRA/m7ImIztq8/kr3xOHre =Dcd5 -END PGP SIGNATURE- ___ 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: New Splash Screen Graphic
On Sat, Mar 14, 2009 at 4:27 PM, Andrew Sackville-West and...@swclan.homelinux.org wrote: On Sat, Mar 14, 2009 at 11:48:59AM -0700, Charles Day wrote: On Sat, Mar 14, 2009 at 9:57 AM, Andrew Sackville-West +1 ^ 2 Is it OK to have the names of well-known companies in the graphics? Any issue with the artist putting a credit in the text? (At least it is quite subtle.) Charles, good eye. I withdraw my +1^2 pending the removal of recognizable proprietary trademarks. I personally have no problem with the artists name in the text. It is no different than the copyright notices in the preambles to source code, IM(very uneducated)O. The artist's name is fine with me too, but I figured it was something to ask about. That said, and based on his other post in this thread, I suspect the artist doesn't realize what it means to release his art to the project. Tynan, perhaps you should read up on these licenses. I was wondering, even with the artist's GPL, if it was possible to use copyrighted or trademarked names or whatever in the artwork. I don't pretend to understand the fair use stuff. Is there any issue with the several images of which this collage is composed? Are they licensed clip art? Or from a free source? I do like the clean look of it. On the old one, the Gnu bucks were kind of humorous though. A -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Behavior of Enter in register
On Thu, Mar 12, 2009 at 10:08 AM, Andy Den Tandt adtlist_...@adtsoft.euwrote: Charles wrote: How about changing the current checkbox preference into three radio buttons? 1. Enter moves to the next line (default) 2. Enter moves to the next transaction 3. Enter moves to a new transaction For changing the behavior/add the preference, but for always creating a new transaction. I'd rather have Enter commit the current transaction and move to the next one. Only if the transaction being edited was the last one, it will create a new one. I often import transactions from my bank and then edit them (eg to create splits). So when I press Enter, I declare that I am done with that transaction and am moving on to the next one. It would be very weird that I would suddenly jump to the end of the screen. The checkbox option that you already in Edit-Preferences-Register is #3 when checked and #1 when unchecked. The only thing new here is #2. Ulrike Fischer wrote I would like keys for 2 _and_ 3. e.g.enter - next transaction shift + enter - new transaction So I agree with Ulrike ;-) In this proposal shift+enter equal Enter followed by shift-pagedown right? I.e. we are never creating new empty transactions in the middle of the ledger. Empty transactions are always at the bottom, so if you pick #3 then you jump to the end every time you hit Enter. I'd use #2, personally. Andy Den Tandt -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Behavior of Enter in register
Unless you have Enter moves to blank transaction check in your preferences, the Enter key only advances to the next row. The next row might be the next transaction (typical in basic ledger style) or the next split (typical in transaction journal style). Personally, I would expect Enter to save the transaction I am on and move to the next transaction, regardless of register style. Is there a good reason that it isn't that way? If I just wanted to move to the next split, I could use Tab or the down cursor. It is just a one-line code change. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Behavior of Enter in register
On Wed, Mar 11, 2009 at 2:41 PM, Dennis Muhlestein djmuhlest...@gmail.comwrote: Charles Day wrote: Unless you have Enter moves to blank transaction check in your preferences, the Enter key only advances to the next row. The next row might be the next transaction (typical in basic ledger style) or the next split (typical in transaction journal style). Personally, I would expect Enter to save the transaction I am on and move to the next transaction, regardless of register style. Is there a good reason that it isn't that way? If I just wanted to move to the next split, I could use Tab or the down cursor. It is just a one-line code change. I might expect that too, but my wife, who also enters transactions, constantly gets messed up when enter brings her away from the current transaction she is entering. Some people are not used to edittabedittab and use editentereditenter. How about changing the current checkbox preference into three radio buttons? 1. Enter moves to the next line (default) 2. Enter moves to the next transaction 3. Enter moves to a new transaction -Charles -Dennis ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Speeding up reports
On Mon, Mar 9, 2009 at 9:46 AM, Andrew Sackville-West and...@swclan.homelinux.org wrote: On Sun, Mar 08, 2009 at 02:03:57PM -0800, Charles Day wrote: On Sat, Mar 7, 2009 at 3:43 PM, Mike Alexander m...@umich.edu wrote: Has anyone looked at http://bugzilla.gnome.org/show_bug.cgi?id=573229 to see if my patch makes any sense? It speeds up some reports (e.g. Income Statement) by a factor of 50 or so with largish files. ... Cool!! I'm certainly not any sort of authority on report infrastructure (I've dabbled), but I've read your code changes and the concept looks right to me. Perhaps Christian could comment? ... This really should get exercised more. I'm going to go ahead and at least commit this to trunk. This may be experimental, but I guess that's what trunk is for, and it seems fine to me so far. Thanks Charles, I've been sitting on that in my inbox for a long time not having the time to work on it.. No problem. I've committed it as r17988. If you get any time and could try a bit of testing with it, that would be great. Cheers, Charles A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1R/wACgkQaIeIEqwil4YseQCfeia3ZZ6W9TgwiispgzO7WIrC 3EQAnjK47h9Mk1HmTGcxKkYk5G/svVeF =ve8I -END PGP SIGNATURE- ___ 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: Speeding up reports
On Sat, Mar 7, 2009 at 3:43 PM, Mike Alexander m...@umich.edu wrote: Has anyone looked at http://bugzilla.gnome.org/show_bug.cgi?id=573229 to see if my patch makes any sense? It speeds up some reports (e.g. Income Statement) by a factor of 50 or so with largish files. It seems to work for me, but it affects the report infrastructure and I haven't tried to test all the reports. I'm going to be gone for a couple of weeks and may have intermittent EMail access. Cool!! I'm certainly not any sort of authority on report infrastructure (I've dabbled), but I've read your code changes and the concept looks right to me. Perhaps Christian could comment? Another small performance gain might be made by changing the two let* calls to let in gnc:account-get-trans-type-balance-interval, since the order of execution is unimportant in those declarations. In particular, the second let* runs inside the loop so it would be good to change it there. No idea whether the performance difference would be noticeable or not -- and perhaps there is no improvement at all if Guile is not running multi-threaded -- but might as well prefer let in situations where let* is not required. I did run a simple test using a sizable profit loss report. Before your changes, it took 40 seconds. With your changes, it was about 3-4 seconds. The numbers appear to match as well. This really should get exercised more. I'm going to go ahead and at least commit this to trunk. This may be experimental, but I guess that's what trunk is for, and it seems fine to me so far. -Charles Mike ___ 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: r17969 - gnucash/trunk/src/register/ledger-core - Bug #343217: Register: Don't leave the account cell if the user chooses not to create a new account when prompted. This allows any typo to be qu
On Wed, Mar 4, 2009 at 6:32 AM, Derek Atkins warl...@mit.edu wrote: Charles, Charles Day ceda...@cvs.gnucash.org writes: Modified: gnucash/trunk/src/register/ledger-core/split-register-control.c gnucash/trunk/src/register/ledger-core/split-register-p.h gnucash/trunk/src/register/ledger-core/split-register.c Log: Bug #343217: Register: Don't leave the account cell if the user chooses not to create a new account when prompted. This allows any typo to be quickly fixed. Previously the account cell text was blanked and focus moved to the next cell. Could you make the same change in src/business/business-ledger/gncEntryLedger* as well? I suspect the same bug exists over there. Committed as r17971. I don't really play with the business stuff much, so you should test it and see if it works as expected. It seemed OK to me. If only they were all this easy! -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 -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register rewrite
On Mon, Mar 2, 2009 at 5:50 AM, Chris Shoemaker c.shoema...@cox.net wrote: On Sun, Mar 01, 2009 at 01:35:30PM -0800, Charles Day wrote: Could someone enlighten me as to the state of the register rewrite, or point me to some kind of readme about it? I would like to know what the approach was, where things left off, etc. I had a quick look at the register-rewrite branch. My first impression is that the original register code has not been changed at all and that some kind of new stuff based on GtkTreeView was being worked on. Is it the intention to abandon a GUI-independent register design for a Gtk+ dependent version? Yes, exactly. At the time, it was somewhat of a feasibility study, as GtkTreeViews were still a little new and there weren't too many examples of good implementations that used 1000s+ of entries. These days, it's not really a question of the quality of the gtk+ bits. OK, I may take a look at some point. I did get pretty familiar GtkTreeView and its related widgets when fixing the Security Editor and Price Editor. Now that the known register crashes have been fixed, at the moment I probably give higher priority to lots, OFX investment importing, and Mac packaging. I haven't had the time to work on it (or any other part of GnuCash) for quite a while now. IIRC, last time I worked on it, I got copy and pasting of transactions working, which was pretty low on my priority list, so I think it's probably usable, though not polished. Cool, thanks for the update. I take it the old split register code is to be abandoned, so I don't have to worry about bring my trunk register fixes over to the register-rewrite branch. -chris Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Register rewrite
Could someone enlighten me as to the state of the register rewrite, or point me to some kind of readme about it? I would like to know what the approach was, where things left off, etc. I had a quick look at the register-rewrite branch. My first impression is that the original register code has not been changed at all and that some kind of new stuff based on GtkTreeView was being worked on. Is it the intention to abandon a GUI-independent register design for a Gtk+ dependent version? Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
How to programmatically select register cell text?
When typing an account name in the register, if you make a mistake and then hit tab, it will ask if you want to make a new account. If you say no, then what you have typed is lost and focus moves to the next field in the register. It seems better to me to keep the focus on the account field and give the user a chance to fix the typo or to delete the text entirely if they actually didn't intend to enter an account. I have prepared a fix for bug 343217 (which is exactly this issue) such that focus can remain on the account field, however I don't know how (or if it is even presently possible) to make the text automatically be selected. Does anyone know how to programmatically select text in a register cell? If no one responds, then I'll just commit the change as is, and the text just won't be selected after the user picks no. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fwd: GnuCash packaging
This is an off-list email that he gave me permission to forward to the list. Mac readers may be interested. -Charles -- Forwarded message -- From: Charles Day ceda...@gmail.com Date: Fri, Feb 27, 2009 at 11:27 AM Subject: Re: GnuCash packaging To: Rick Stahlhut rstahl...@rochester.rr.com On Fri, Feb 27, 2009 at 5:35 AM, Rick Stahlhut rstahl...@rochester.rr.comwrote: Hello Charles, i just was struggling to install GnuCash on my intel Macbook Pro 10.5.5 the last couple days. I saw the discussion you were in last month at macosforge titled GnuCash packaging. Thank you thank you thank you -- for considering a mac executable for GnuCash. Mac installs are a complete pain; I'd love to package it up into a single .app file. I'm a former oracle database designer. I've worked in unix and vms environments. But that was 20 years ago. Now I just want a financial package that works -- and what appears to be the best option for the mac. the GnuCash documentation is fantastic compared to MoneyDance, for instance, and I've heard great things about the features. I was astonished (ok, not that much) to hear some folks on the group suggesting to you that some of us are unwilling to install macports and fink. These folks must be smoking something interesting.I've *done* that. It doesn't work. And then I'm totally stuck, after a lot of time and disk wasted. MacPorts should work. That's what I use whenever I need to build a released version. (I usually work with the unreleased code.) If you are unable to build with MacPorts, ask on the gnucash-user list and I (or someone else) will respond to your specific issue. As you obviously realize, many users of reasonable skill do not have unix chops. And unix chops are the only thing that matters when these macport installs fail. Unless, of course, you have an entire week to devote to it, which I don't because I'm trying to do medical research instead. So again, thank you for thinking of us poor users. I do not want to buy my second choice when an open source product is better and better documented. But I don't have a week to install it. If you are seriously considering a build, would you please let me know and I'll wait for it. Else, I guess, I have to buy MoneyDance. I honestly don't care about the money. Time is my issue. I'm not actively working on packaging at the moment, but it's high on my priority list. It may be figured out fairly soon but I have no timeline for it. If you need something instantly and don't want to retry MacPorts or Fink by asking on the gnucash-user list, then I guess you'll have to pick something else. I suppose it's considered wrong to try to pay for such things, but i for one, would be happy to pay for a working executable for GnuCash (preferably with some free trial option). I wish I could offer technical help, but if I had those skills, i wouldn't be writing you. thanks for listening. No worries. Could I forward this exchange to the gnucash-devel list so other GnuCash developers can read it? - Rick in Rochester (NY) Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: make check failing on mac leopard
On Wed, Feb 25, 2009 at 7:22 AM, David Reiser dbrei...@earthlink.netwrote: On Feb 19, 2009, at 2:36 PM, Charles Day wrote: On Thu, Feb 19, 2009 at 11:10 AM, Charles Day ceda...@gmail.com wrote: I tried make check on my mac today, and it is failing (see below). I assume that this is related to the .so vs. .dylib thing, to which I hope that Dave can still recall the answer. See: http://www.mail-archive.com/fink-de...@lists.sourceforge.net/msg13057.html Any bright ideas on what I have to change to fix this? Sorry to reply to my own question, but it was solved by adjusting $DYLD_LIBRARY_PATH with: export DYLD_LIBRARY_PATH=/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources:/opt/local/lib (all on one line) This was for libraries built with MacPorts, so I guess it would be different with fink. [snip] A straightforward substitution of the fink libs '/sw/lib' for '/opt/local/lib' doesn't work for me. I have never managed to get make check to work on my mac. With yesterday's trunk, it fails in test-lots at OTHER gnc.lots [xaccSplitAssignToLot()] Failed to split into two! The lots failure is an open issue and it presently happens on every platform so far as I know. So your setup is probably fine. The resolution of the thread mentioned above was to remove the sed patch pogma mentioned late in the thread. The fink wizards are unanimous in warning that DYLD_LIBRARY_PATH should be avoided if at all possible. It doesn't do the same thing in OS X that it does in Linux, and frequently gets in the way on the Mac. DYLD_FALLBACK_LIBRARY_PATH is generally recommended as 'doing what you want'. While trunk builds for me without the substitution, for the fink I have to replace all of the DYLD_LIBRARY_PATH instances with DYLD_FALLBACK_LIBRARY_PATH or gnucash won't build. Fink almost wipes your environment before it builds, so something gets out of whack in that step. Doing that substitution in trunk does not solve my make check problem. Thanks, I'll keep an eye out for this if I see any problems. Previously I was getting GnuCash to run by adjusting DYLD_LIBRARY_PATH in the bin/gnucash script manually. Obviously that trick doesn't work for make check, so I just put in the environment before running. I have tried DYLD_FALLBACK_LIBRARY_PATH, and it didn't work for me. I get a make check failure in the dynamic linking tests. Dave -- David Reiser dbrei...@earthlink.net -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: make check failing on mac leopard
On Wed, Feb 25, 2009 at 4:04 PM, David Reiser dbrei...@earthlink.netwrote: On Feb 25, 2009, at 12:04 PM, Charles Day wrote: I have never managed to get make check to work on my mac. With yesterday's trunk, it fails in test-lots at OTHER gnc.lots [xaccSplitAssignToLot()] Failed to split into two! The lots failure is an open issue and it presently happens on every platform so far as I know. So your setup is probably fine. But how the heck am I failing make check with test-lots turned off? I was testing r17959 this morning. Test-lots was disabled in r17946 and re-enabled in r17964. But that was just in the 2.2 branch. Were you testing that or was it trunk? I only use trunk. Dave -- David Reiser dbrei...@earthlink.net -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Pasting transactions in register
On Tue, Feb 24, 2009 at 6:28 AM, Derek Atkins warl...@mit.edu wrote: Charles Day ceda...@gmail.com writes: In a register, what is the expected behavior of the Paste Transaction menu item when pasting to a non-new transaction? After asking for user confirmation, should it paste the data into the existing transaction, immediately commit the changes, and move down to the next transaction? Or should it paste the data without committing and leave the user on the same line? Or something else? I believe it should do the latter -- paste the data without committing and leave the user on the same line. That's what I thought too, but it seems that presently it immediately commits and remains on the same line. Not sure if there is a bug already for this. I didn't see one. Anyway, I'll see if I can fix it. Cheers, Charles -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
Pasting transactions in register
In a register, what is the expected behavior of the Paste Transaction menu item when pasting to a non-new transaction? After asking for user confirmation, should it paste the data into the existing transaction, immediately commit the changes, and move down to the next transaction? Or should it paste the data without committing and leave the user on the same line? Or something else? Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: meta-bug for 2.3/2.4
On Sat, Feb 21, 2009 at 8:01 PM, Derek Atkins warl...@mit.edu wrote: hi, Quoting Charles Day ceda...@gmail.com: Is there a meta-bug for 2.3/2.4 to block in Bugzilla to indicate that a particular bug (e.g. bug 426111) has been fixed in trunk, and can be marked as fixed once a 2.3 or 2.4 has been made? Or some other way to keep track of bugs I've fixed in trunk that will not be backported for 2.2? Cheers, Charles No, we dont have one.. Generally we don't do a catch-all until after we branch.It's not there to keep track of fixed bugs, it's there to keep track of bugs yet-to-be backported. You can already find bugs fixed for 2.3.x by a simple bugzilla query. So what's the proper thing to do for bugs like 426111, which was reported in version 2.0.5 but has just recently been fixed in trunk and is unlikely to be backported for 2.2? How do we remember to mark that bug fixed once we branch for 2.3 or 2.4? -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: make check failing on mac leopard
On Thu, Feb 19, 2009 at 11:10 AM, Charles Day ceda...@gmail.com wrote: I tried make check on my mac today, and it is failing (see below). I assume that this is related to the .so vs. .dylib thing, to which I hope that Dave can still recall the answer. See: http://www.mail-archive.com/fink-de...@lists.sourceforge.net/msg13057.html Any bright ideas on what I have to change to fix this? Sorry to reply to my own question, but it was solved by adjusting $DYLD_LIBRARY_PATH with: export DYLD_LIBRARY_PATH=/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources:/opt/local/lib (all on one line) This was for libraries built with MacPorts, so I guess it would be different with fink. Cheers, Charles make check-TESTS ERROR: In procedure dynamic-link: ERROR: file: libguile-srfi-srfi-13-14-v-1, message: dlopen(libguile-srfi-srfi-13-14-v-1.so, 9): image not found (process:55398): gnc.module-WARNING **: Could not locate module gnucash/foo interface v.0 test-load-c.c: testing module load/unload from C ... Failed to load foo FAIL: test-load-c ERROR: no code for module (gnucash gnc-module) FAIL: test-load-scm ERROR: no code for module (gnucash gnc-module) FAIL: test-gwrapped-c ERROR: no code for module (gnucash gnc-module) FAIL: test-scm-module ERROR: no code for module (gnucash gnc-module) FAIL: test-scm-multi ERROR: no code for module (gnucash gnc-module) FAIL: test-load-deps test-modsysver.c: checking for a module we shouldn't find ... (process:55445): gnc.module-WARNING **: Could not locate module gnucash/futuremodsys interface v.0 ok PASS: test-modsysver test-incompatdep.c: loading a module with bad deps ... (process:55463): gnc.module-WARNING **: Could not locate module gnucash/incompatdep interface v.0 ok PASS: test-incompatdep (process:55481): gnc.module-WARNING **: Could not locate module gnucash/agedver interface v.5 test-agedver.c: asking for an old but supported interface ... failed FAIL: test-agedver test-dynload.c: testing dynamic linking of libgnc-module ... OK PASS: test-dynload test-scm-dynload: testing dynamic-link of libgnc-module from Scheme. ERROR: In procedure dynamic-link: ERROR: file: libgnc-module, message: dlopen(libgnc-module.so, 9): image not found FAIL: test-scm-dynload test-scm-init: testing Scheme-only module system init. ERROR: no code for module (gnucash gnc-module) FAIL: test-scm-init == 9 of 12 tests failed Please report to gnucash-devel@gnucash.org == ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Swig type mapping for GUID's
On Wed, Feb 18, 2009 at 7:03 AM, Derek Atkins warl...@mit.edu wrote: Charles Day ceda...@gmail.com writes: I have a question about the current type mapping that swig does for GUID pointers. Currently, if a C function returns a GUID* that is a null pointer (== NULL), swig converts it to SCM_UNDEFINED and hands that to guile. From src/base-typemaps.i: %typemap(out) GUID * $result = ($1) ? gnc_guid2scm(*($1)): SCM_UNDEFINED; Unfortunately, returning SCM_UNDEFINED to guile causes the variable on the guile side to become unbound, leading to crashes (bug #530819, for example). There is apparently no way to test for this condition from guile, so it seems to me that swig should never return SCM_UNDEFINED to guile. Does anyone know why the type mapping has been defined this way? Shouldn't it be redefined to return SCM_BOOL_F instead? Either that or gnc_guid2scm(guidnull()) ?? I'm not sure why it is the way it is, nor am I sure what it SHOULD be. SCM_BOOL_F probably is correct. qof_instance_get_guid() can return a normal GUID, guid_null(), or NULL (upon failure). So it seems there ought to be a way for the caller (Scheme) to distinguish between the last two. Having #f returned to Scheme seems like a natural fit, as #f is returned by many Scheme procedures to indicate a bad result. A second issue is how GUID's are currently handled within Scheme. To represent, say, a C split in Scheme, a record is filled out with the values of each field (e.g. date, amount, account). The account is stored in Scheme by use of its GUID, which may not exist if the split has not yet been assigned to an account. How do we intend to represent this situation in Scheme? I don't see any code that handles this, and #f would seem to be appropriate. Cheers, Charles -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: Windows packaging: upgrade to gtk 2.14.7?
On Tue, Feb 10, 2009 at 2:46 PM, Charles Day ceda...@gmail.com wrote:
On Mon, Feb 9, 2009 at 9:58 PM, Andreas Köhler andi5...@gmx.net wrote:
Hi Charles,
sure, that is perfectly possible. Simply point the URLs in
packaging/win32/defaults.sh to the correct files {,-dev} in
ftp://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.14/.
Andreas, I went ahead and updated defaults.sh with the newer version in
r17897, but unfortunately I can't test it because I don't have a Windows
build environment for the moment. Just thought I should warn you.
-Charles
OTOH, we are talking about Bug #520165, right? The patch seems to be
part of Gtk+ 2.14.3.
Interesting... the bug definitely occurs on Windows, as I have experienced
myself and as reported in 2.2.8 in bug 570166. But I tried and it doesn't
occur with 2.14.7 on Mac. Can't say whether 2.14.7 fixes it on Windows, but
that's my theory. Unfortunately, I don't have a Windows machine that I can
build on at the moment.
Ciao,
-- andi5
Cheers,
Charles
Charles Day wrote:
Any chance of making the setup.exe for GnuCash 2.2.9 for Windows come
with gtk 2.14.7 rather than 2.14.6? There appears to be a fix for bug
570166 in there.
Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Transaction API question
On Tue, Feb 10, 2009 at 12:27 PM, Alan Jenkins alan-jenk...@tuffmail.co.ukwrote: Christian Stimming wrote: Am Dienstag, 10. Februar 2009 11:02 schrieb Alan Jenkins: I have a question about how to destroy a transaction properly. Interesting. The generic import layer does this: xaccTransDestroy(trans); xaccTransCommitEdit(trans); to destroy an open transaction in gnc_import_exists_online_id(). It seems to work :-). Maybe the register code is missing the commit. I really don't know now, and I also didn't really know at the time when I wrote (part of) the importing code. I vaguely recall this Destroy/Commit sequence had to be used there because otherwise the transactions didn't disappear as intended. However, even at that time I couldn't find out which one was the intended way, and it was sufficient for me to see this work. The comments actually say this is the right way /** The xaccTransDestroy() method will remove all of the splits from each of their accounts, free the memory associated with them. This routine must be followed by either an xaccTransCommitEdit(), in which case the transaction memory will be freed, or by xaccTransRollbackEdit(), in which case nothing at all is freed, and everything is put back into original order. */ I've committed r17896, which updates these comments to make it (hopefully) clear that no extra commit step is required of the caller if the transaction isn't already open. Also, I've committed r17895 to fix the way the register was trying to destroy blank transactions. Regards Alan Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Transaction API question
On Tue, Feb 10, 2009 at 12:27 PM, Alan Jenkins alan-jenk...@tuffmail.co.ukwrote: Christian Stimming wrote: Am Dienstag, 10. Februar 2009 11:02 schrieb Alan Jenkins: I have a question about how to destroy a transaction properly. Interesting. The generic import layer does this: xaccTransDestroy(trans); xaccTransCommitEdit(trans); to destroy an open transaction in gnc_import_exists_online_id(). It seems to work :-). Maybe the register code is missing the commit. I really don't know now, and I also didn't really know at the time when I wrote (part of) the importing code. I vaguely recall this Destroy/Commit sequence had to be used there because otherwise the transactions didn't disappear as intended. However, even at that time I couldn't find out which one was the intended way, and it was sufficient for me to see this work. The comments actually say this is the right way /** The xaccTransDestroy() method will remove all of the splits from each of their accounts, free the memory associated with them. This routine must be followed by either an xaccTransCommitEdit(), in which case the transaction memory will be freed, or by xaccTransRollbackEdit(), in which case nothing at all is freed, and everything is put back into original order. */ Interesting, as xaccTransDestroy() itself includes an open/commit pair (either itself or via functions it calls -- can't remember at the moment). Regards Alan ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Windows packaging: upgrade to gtk 2.14.7?
Any chance of making the setup.exe for GnuCash 2.2.9 for Windows come with gtk 2.14.7 rather than 2.14.6? There appears to be a fix for bug 570166 in there. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Transaction API question
I have a question about how to destroy a transaction properly. Suppose I do the following to create a new transaction with one split. new_trans = xaccMallocTransaction (gnc_get_current_book ()); xaccTransBeginEdit (new_trans); xaccTransSetCurrency (new_trans, currency ? currency : gnc_default_currency()); xaccTransSetDateSecs (new_trans, info-last_date_entered); blank_split = xaccMallocSplit (gnc_get_current_book ()); xaccSplitSetParent(blank_split, new_trans); I haven't committed yet. Now what if I decide that I don't want this transaction or split any more? Will xaccTransRollbackEdit() get that done? If not, what is the correct way? I ask because the register tries to do it with xaccTransDestroy(), but since the transaction is still open, that doesn't actually work. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Bug or compile issue?
I'm seeing some CRIT messages on my Mac, which is running the latest code
from SVN trunk. I've used gdb to try to figure out what's happening, and it
seems a bit weird, like a possible compile or other platform-specific issue.
The CRIT messages look like:
* 03:28:15 CRIT gnc.ledger [gnc_split_register_get_trans_split()]
bad row
* 03:28:15 CRIT gnc.register.gnome
gnucash_sheet_cursor_set_from_table: assertion `gnucash_sheet_cell_valid
(sheet, v_loc)' failed
The specific line that seems to fail is line 1471 of
src/register/register-core/table-allgui.c:
vloc = *virt_loc;
This statement is supposed to copy a struct:
(gdb) whatis vloc
type = VirtualLocation
(gdb) whatis *virt_loc
type = VirtualLocation
(gdb) ptype VirtualLocation
type = struct _VirtualLocation {
VirtualCellLocation vcell_loc;
int phys_row_offset;
int phys_col_offset;
}
(gdb) ptype VirtualCellLocation
type = struct _VirtualCellLocation {
int virt_row;
int virt_col;
}
However, the struct only seems to be copied properly *sometimes*. For
example:
(gdb) next
1471 vloc = *virt_loc;
(gdb) print *virt_loc
$82 = {
vcell_loc = {
virt_row = 2,
virt_col = 0
},
phys_row_offset = 0,
phys_col_offset = 0
}
(gdb) next
1473 vcell = gnc_table_get_virtual_cell (table, vloc.vcell_loc);
(gdb) print vloc
$90 = {
vcell_loc = {
virt_row = 2,
virt_col = 0
},
phys_row_offset = -1073749880,
phys_col_offset = 720727
}
So part of the struct copied OK (virt_row, virt_col) and the rest seems to
be garbage (phys_row_offset, phys_col_offset). Even stepping forward a few
more times doesn't change the result. Any ideas how this could be happening?
Some kind of optimization I should turn off perhaps?
I don't think it is a gdb problem, as I still get the CRIT messages without
gdb.
Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17840 - gnucash/trunk/src/register/ledger-core - Register: Add additional debugging output during register cleanup. Also rename a variable for clarity and to match typical usage in the re
On Fri, Jan 23, 2009 at 12:31 PM, Derek Atkins warl...@mit.edu wrote: Hi, Charles Day ceda...@gmail.com writes: On Thu, Jan 22, 2009 at 11:02 AM, Derek Atkins warl...@mit.edu wrote: Charles Day ceda...@cvs.gnucash.org writes: Register: Add additional debugging output during register cleanup. Also rename a variable for clarity and to match typical usage in the rest of the ledger code. BP Why is this something that should be back ported? Do you not want new debugging output backported? I had to add this to troubleshoot the register with a user (bug 426111), as he could randomly reproduce the problem himself but could not describe how to make it happen for others. It would be nice to have this change released so that users can produce this output on request with --log gnc.ledger=debug if/when we can't reproduce their problem. I think it depends where we are in the lifecycle of the stable release. Right now I'd consider 2.2 nearing its end, and really we should limit changes to true bug fixes, and even then we should be conservative about what it is that we're fixing. Simultaneously I think we should seriously think about the 2.3/2.4 lifecycle. Do we have a timeframe for 2.3/2.4? If these debugging messages might help me fix register problems then it could be worth adding them in 2.2, because then users will be better able to help me. That could help get some register bugs fixed in trunk before 2.3/2.4. Otherwise register bugs may just continue to sit around. I'm definitely not saying to backport the actual fixes for 2.2, but at least backporting the debugging messages may help keep fixes coming. I'm just sort of wary of getting into the situation where there's a new stable release and fixes will be quarantined in trunk again. So I'd like to get some register fixes done before the next stable release goes out, and these debugging messages may help. As for the variable name change, that's strictly optional, but the old name was confusing when read in context with all the other functions in that file. Incidentally, I just committed a bunch of changes related to doxygen. I guess those don't really have to be backported if documentation is never produced from branches, though it seems innocuous. Innocuously-seeming changes often come back to bite us. Just look at the one-line change put into 2.2.8 that causes close invoice to crash! Agreed, however this particular changeset (r17841) doesn't change any functionality - it is all edits to comments except in two spots where a function declaration in the .h file had a different parameter name from in the .c file. Simple typos -- I just made them match. Anyway that changeset is just for documentation, so no problem, no need to backport it. There will be another doxygen changeset committed soon. I won't mark that one for backport. I would recommend caution and restraint about backporting changes. If it's not a crasher, if it's not causing data loss or data corruption, then it probably doesn't need to get backported. In terms of adding debugging output That's definitely a tough call. If the problem is so subtle that we can't figure it out then it's probably minor enough that I would err on the side of wait for 2.3. I think the debugging code is a very safe change. The code doesn't even run unless the --log option is set. If you look at r17837 and r17838, all you'll see are new ENTER(), DEBUG() and LEAVE() statements. For r17839, if the variable name change worries you then don't backport it, that's fine. There's only one new debugging message added in r17839 anyway. And yes, documentation is built off trunk, not 2.2. -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 -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17840 - gnucash/trunk/src/register/ledger-core - Register: Add additional debugging output during register cleanup. Also rename a variable for clarity and to match typical usage in the re
On Thu, Jan 22, 2009 at 11:02 AM, Derek Atkins warl...@mit.edu wrote: Charles Day ceda...@cvs.gnucash.org writes: Register: Add additional debugging output during register cleanup. Also rename a variable for clarity and to match typical usage in the rest of the ledger code. BP Why is this something that should be back ported? Do you not want new debugging output backported? I had to add this to troubleshoot the register with a user (bug 426111), as he could randomly reproduce the problem himself but could not describe how to make it happen for others. It would be nice to have this change released so that users can produce this output on request with --log gnc.ledger=debug if/when we can't reproduce their problem. As for the variable name change, that's strictly optional, but the old name was confusing when read in context with all the other functions in that file. Incidentally, I just committed a bunch of changes related to doxygen. I guess those don't really have to be backported if documentation is never produced from branches, though it seems innocuous. -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 -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Income/Expenses report
On Thu, Jan 8, 2009 at 7:35 PM, Tim Vail jlye...@fastmail.us wrote: Andrew, Sorry for taking a long time getting back. I finally went deeper into the net worth barchart report (which is also used to create the income/expenses chart report), and found that changing the report-utilities.scm's gnc:get-comm-balance-at-date function to NOT use qof resulted in a tremendous increase in speed. Now, I'm not sure that is an acceptable solution -- particularly when we are trying to transition to be closer to SQL. Nevertheless, I've attached the patch (report-utilities.patch) for this part. However, for cash flow report, I got that to run in less than a second too (processing all of my transactions dating back to 2006 -- something like 5000 transactions). The problem there was that the line: (gnc:report-percent-done (* 85 (/ work-done splits-to-do Was being run thousands of times. That is a quite expensive call just to update the progress -- particularly if you have thousands of splits to do. What I did was change it to only update the progress every time it changes by 1%. The progress still seems to move quite smoothly (in the short time that it runs -- it runs really fast. Great find, Tim. Similar changes to the QIF importer improved speed by a factor of 10. Perhaps other reports have the same inefficiency and can be easily sped up too. So...there are two patches attached. Let me know if it works, and I'm curious what others have to say about the idea of swapping that report-utilities method to not use qof. It is also possible that I'm missing something since for different commodities, maybe the qof method is more accurate. I doubt that is the case, though. By the way, I've subscribed to the gnucash-devel digest. -Tim Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Can't find commodity using gnc_commodity_table_lookup()
On Tue, Nov 11, 2008 at 11:47 AM, Justin Mazzola Paluska [EMAIL PROTECTED]wrote: Hi Derek, On Tue, Nov 11, 2008 at 08:43:42AM -0500, Derek Atkins wrote: Well, for one thing I would either use NYCE or GNC_COMMODITY_NS_NYSE in both places. Yes, technically they should be the same, but you might as well test that theory. Changing both to NYSE or GNC_COMMODITY_NS_NYSE leads to the same results. I didn't look into the data file to verify that you configured GOOG under NYCE. I take it that you mean NYSE, right? Attached is a screenshot of the Price Editor for my example file, which looks like it should be configured correctly. —Justin You know that GOOG is supposed to be a NASDAQ stock, right? Just asking because I see in your screenshot that your price came from Finance::Quote. Wondering if it makes any difference. -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Development on Mac Leopard (10.5.5)
On Mon, Oct 27, 2008 at 9:04 AM, Dave Reiser [EMAIL PROTECTED] wrote: Charles Day wrote: Dare I ask: fink or macports? I don't quite understand the difference. I think you said that someone compiled gnucash for aqua using macports, which sounds promising. Fink for me. They're just two different packaging systems. Macports has a bit of help directly from Apple these days, but they have different strengths. Macports tends to jump on updates faster, but that can break already installed stuff unexpectedly. Fink is more cautious (but not error free), but that tends to make them slower in the gnome realm. Fink's kde maintainer is quicker to package new versions than macports. Both suffer from a shortage of active maintainers. Macports provides some additional flexibility in variants of packages, and I think they have a built-in option to build a .app. see the thread starting at: http://lists.macosforge.org/pipermail/macports-users/2008-October/012018.html for info on the aqua build. Once the problems with gnome 2.22 vs 2.24 get ironed out in fink, I'll see if the fink gnome guru is willing to look at the --without-x11 versions of various things to work with gtk-aqua. Dave, I don't know if you saw already from the macports user mailing list, but from following that link and asking a few questions I was eventually able to use macports to build GnuCash on 10.5.5 without x11. It seems to work OK, though I have not exercised it much. Supposedly it should now be possible to generate GnuCash as a .app but I don't think it has been done successfully yet. Dave -- David Reiser [EMAIL PROTECTED] -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Transfering stock between two accounts not supported?
On Thu, Nov 6, 2008 at 2:07 PM, Rainer Dorsch [EMAIL PROTECTED] wrote: Hello, I am wondering if transfering stock between two accounts is not supported. When I try that, I get You can't transfer from a non-currency account. Try reversing the from and to accounts and making the amount negative. Am I doing something wrong? If not, for an outsider that looks odd, since transfering stock looks like a simple feature to implement... I think there is a good reason to not allow this, because you need to somehow specify the cost basis of the shares you are transferring. This could happen automatically if lots functionality was involved, but we're not there yet. Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r17677 hangs on launch
On Sat, Nov 1, 2008 at 12:02 PM, David Reiser [EMAIL PROTECTED]wrote: The last non-aqbanking debug message in the terminal is: * 14:39:32 WARN Gtk Refusing to add non-unique action 'FilePageSetupAction' to action group 'MainWindowActions' gnucash.trace exists, but is empty. Dave Perhaps related to r17610? On Nov 1, 2008, at 1:47 PM, Derek Atkins wrote: Anything on the terminal or in gnucash.trace? -derek Quoting David Reiser [EMAIL PROTECTED]: r17677 hangs on launch for me with the splash screen progress bar saying gnucash/report/standard-reports It stays there for at least several minutes with no activity. Could someone check r17675 for potential scheme problems? Mac OS X 10.5.5, guile 1.8.3 , slib 3b-1 (with one more recent patch from slib svn for slib-guile) -- David Reiser [EMAIL PROTECTED] ___ 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: GnuCash win32 building...
On Sun, Oct 26, 2008 at 11:19 AM, Charles Day [EMAIL PROTECTED] wrote: On Sat, Oct 25, 2008 at 3:44 PM, Martin Preuss [EMAIL PROTECTED] wrote: Hi, On Samstag, 25. Oktober 2008, Andreas Köhler wrote: [...] Anyone know how to proceed? does adding -lz to the gcc command fix this error? Martin should know it :-) Yes, adding -lz worked for me. Thanks!! [...] Actually, I do ;-) It has already been fixed in SVN right after I received this mail ;-) So what if anything should be done with the GnuCash install.sh script? Commit the addition of -lz that made it work for me? Or leave it alone in anticipation of Martin's fix? Now I have run into the next problem, while building aqbanking: /bin/xmlmerge -v --compact -o accountjobs.xml ./jobgetbalance.xml ./jobgettransactions.xml ./jobgetstandingorders.xml ./jobsingletransfer.xml ./jobsingledebitnote.xml ./jobinternaltransfer.xml ./jobeutransfer.xml ./jobmultitransfer.xml ./jobforeignxferwh.xml ./jobcreatesto.xml ./jobmodifysto.xml ./jobdeletesto.xml ./jobgetdatedxfers.xml ./jobcreatedatedxfer.xml ./jobmodifydatedxfer.xml ./jobdeletedatedxfer.xml ./jobloadcellphone.xml /bin/sh: /bin/xmlmerge: No such file or directory I tried copying xmlmerge.exe into /bin just to see what would happen, but that just led to another error message: /bin/xmlmerge -v --compact -o accountjobs.xml ./jobgetbalance.xml ./jobgettransa ctions.xml ./jobgetstandingorders.xml ./jobsingletransfer.xml ./jobsingledebitno te.xml ./jobinternaltransfer.xml ./jobeutransfer.xml ./jobmultitransfer.xml ./jo bforeignxferwh.xml ./jobcreatesto.xml ./jobmodifysto.xml ./jobdeletesto.xml ./jo bgetdatedxfers.xml ./jobcreatedatedxfer.xml ./jobmodifydatedxfer.xml ./jobdelete datedxfer.xml ./jobloadcellphone.xml NOTE: you should run 'diskperf -y' to enable the disk statistics No input file given. make[8]: *** [accountjobs.xml] Error 1 Regards Martin Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Development on Mac Leopard (10.5.5)
On Sun, Oct 26, 2008 at 4:12 PM, David Reiser [EMAIL PROTECTED]wrote:
On Oct 26, 2008, at 6:44 PM, Charles Day wrote:
What is the current state as far as doing GnuCash development on Leopard?
I
now have a spiffy new MacBook Pro at my disposal, so I am trying to shift
away from developing on XP. I read the FAQ but the information sounded
enough out-of-date that I thought I should ask for a update to
double-check
before diving in.
1. Is it readily possible to do GnuCash development, compilation, and
testing work from within Leopard, via macports or fink or otherwise?
I always have one or more fink gnucash installs around plus gnucash trunk.
I found the best way to make sure I had all the dependencies was to install
the latest fink gnucash ('fink install gnucash2'), and then set up an /opt
install of trunk (/opt is not in my path) for testing/development:
guile18-build PERL_PATH=/usr/bin/perl PERL=/usr/bin/perl
LIBRARY_PATH=/sw/lib CPATH=/sw/include ./configure --enable-error-on-warning
--enable-compile-warnings --prefix=/opt/gnucash-svn --enable-debug
--enable-doxygen --enable-ofx --enable-hbci --with-dbi-dbd-dir=/sw/lib/dbd
the guile18-build is a fink-installed bit that just sets environment stuff
to find fink's guile. I force the system perl because there were some issues
switching back and forth between fink's and the system's. But I still use
fink to install finance-quote...
There's some grumbling about that the latest gtk+ has broken gtkhtml and
evince in fink (making it hard to install gnucash2). But others have
apparently succeeded.
There's also one report that finance-quote 1.14 was causing a problem
(didn't for me). I'll try to get f-q 1.15 committed tonight.
When I got started, it was easier for me to figure out fink than macports.
Fink will also keep old shared libraries around so as not to break already
compiled stuff. If you're careful about general port updating, that may not
be a problem for you.
Dare I ask: fink or macports? I don't quite understand the difference. I
think you said that someone compiled gnucash for aqua using macports, which
sounds promising.
2. Is it just easier to do the work in Linux or XP running in a virtual
machine, e.g. vmware fusion or parallels? (I would rather not have to dual
boot.)
Maybe Linux in a virtual machine, but I'd be really surprised if XP was
easier than native Mac -- OS X is a unix variant after all.
Cheers,
Charles
Dave
--
David Reiser
[EMAIL PROTECTED]
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash win32 building...
On Sat, Oct 25, 2008 at 3:44 PM, Martin Preuss [EMAIL PROTECTED] wrote: Hi, On Samstag, 25. Oktober 2008, Andreas Köhler wrote: [...] Anyone know how to proceed? does adding -lz to the gcc command fix this error? Martin should know it :-) Yes, adding -lz worked for me. Thanks!! [...] Actually, I do ;-) It has already been fixed in SVN right after I received this mail ;-) So what if anything should be done with the GnuCash install.sh script? Commit the addition of -lz that made it work for me? Or leave it alone in anticipation of Martin's fix? Regards Martin Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Development on Mac Leopard (10.5.5)
What is the current state as far as doing GnuCash development on Leopard? I now have a spiffy new MacBook Pro at my disposal, so I am trying to shift away from developing on XP. I read the FAQ but the information sounded enough out-of-date that I thought I should ask for a update to double-check before diving in. 1. Is it readily possible to do GnuCash development, compilation, and testing work from within Leopard, via macports or fink or otherwise? 2. Is it just easier to do the work in Linux or XP running in a virtual machine, e.g. vmware fusion or parallels? (I would rather not have to dual boot.) Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GnuCash win32 building...
...currently fails on gwenhywfar. First, the default download version for gwen (3.4.1) apparently doesn't exist any more: ### Gwenhywfar --17:31:50-- http://www.aquamaniac.de/sites/download/download.php?package=01re lease=13file=01dummy=gwenhywfar-3.4.1.tar.gz = `c:/soft/tmp/[EMAIL PROTECTED] =01release=13file=01dummy=gwenhywfar-3.4.1.tar.gz' Resolving www.aquamaniac.de... 81.169.145.75 Connecting to www.aquamaniac.de[81.169.145.75]:80... connected. HTTP request sent, awaiting response... 404 File 1/13/1does not exist 17:31:51 ERROR 404: File 1/13/1does not exist. Fine, so I updated defaults.sh with the latest version (3.5.1) and tried again and failed again: gcc -g -O2 -Wall -Wdeclaration-after-statement -Wall -Wdeclaration-after-statement -o .libs/gwentest.exe gwentest.o -L/c/soft/regex/lib -L/c/soft/gnome/lib -L/c/soft/gnutls/lib ../src/.libs/libgwenhywfar.dll.a -liconv -lgcrypt -lgnutls -lgpg-error -lregex -lwsock32 -lintl -L/c/soft/gwenhywfar/lib gwentest.o(.text+0x92e8): In function `testDES4': c:/soft/tmp/gwenhywfar-3.5.1/test/gwentest.c:205: undefined reference to `inflateInit_' gwentest.o(.text+0x9314):c:/soft/tmp/gwenhywfar-3.5.1/test/gwentest.c:213: undefined reference to `inflate' gwentest.o(.text+0x93fb):c:/soft/tmp/gwenhywfar-3.5.1/test/gwentest.c:243: undefined reference to `inflateEnd' gwentest.o(.text+0x94d2):c:/soft/tmp/gwenhywfar-3.5.1/test/gwentest.c:225: undefined reference to `deflateEnd' collect2: ld returned 1 exit status make[2]: *** [gwentest.exe] Error 1 make[2]: Leaving directory `/c/soft/tmp/gwenhywfar-3.5.1/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/soft/tmp/gwenhywfar-3.5.1' make: *** [all] Error 2 Anyone know how to proceed? Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Windows build of trunk
Adam Kessel has offered to test the register fixes for bugs 393383 426111 if we can come up with a Windows install .exe based on trunk. Apparently he is able to reproduce the problems repeatedly in 2.2.7 and it would be useful to have him give trunk a test drive to see if he can break it. I kind of recall that there may have been nightly Windows builds at some point, but not any more. Would it be possible to make one on an ad hoc basis (i.e. now)? Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: text not translated on the UI, while it is translated in the PO
On Thu, Oct 16, 2008 at 6:34 PM, Derek Atkins [EMAIL PROTECTED] wrote: Quoting [EMAIL PROTECTED]: Derek Atkins wrote: Hi, Quoting Zhang Weiwu [EMAIL PROTECTED]: sorry for having a new translator's question. This is my first trial to correct translation on gnome software. I found the word Total Credits, Total Debits and Net Change was not translated to Chinese when locale was zh_CN.UTF-8 (I compiled from 2.2.7 source myself). See the screenshot attached. First I thought someone overlooked the phrases, because all other parts are translated fine. Then I use gtranslator to work on zh_CN.po and found it is translated in the po, like in the screenshot. Then I don't know how to make it also Chinese on the UI. I wonder is there something wrong in the source code that makes these 3 particular phrases not translated? Because they are the only cases so far with missing translation on zh_CN. Which report is this? Account Report has this problem. Others probably also. Very odd. That string certainly looks translated in the scheme source. It could be a bug in the po file. But in the report (register.scm) the only place where the string Total Credits is used is in a translated string: ./src/report/standard-reports/register.scm: (add-subtotal-row (_ Total Credits) leader table used-columns So this string should be translated. Also, the About Box appears untranslated, too! Oh was it supposed to be translated? I thought it was intentionally:) I would have expected it to be, but I don't know. Just a shot in the dark... could this have anything to do with the #, fuzzy line in the po file? Probably not but I thought I would throw it out there. All four untranslated strings that I see here have that line in common. -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 -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register code question
On Thu, Oct 16, 2008 at 4:27 AM, Chris Shoemaker [EMAIL PROTECTED]wrote: On Wed, Oct 15, 2008 at 08:41:58PM -0700, Charles Day wrote: I am debugging the register code and trying to figure out why bogus message boxes can appear, and also why crashes occur in certain cases. I believe that I've figured it out the sources of these problems, but I have a background question to ask before proceeding with a fix. These problems seem to stem from the way that the pending_trans_guid is used when entering a brand new transaction. Can anyone explain the intended use of pending_trans_guid where new transactions are concerned? I came across some comments in split-register-load.c which appear to shed some light. When the bottom line of the register is created (where the user would start entering a new transaction), a new transaction with a single blank split is tied to it but not marked pending: /* We don't want to commit this transaction yet, because the split doesn't even belong to an account yet. But, we don't want to set this transaction as the pending transaction either, because we want to pretend that it hasn't been changed. We depend on some other code (somewhere) to commit this transaction if we really edit it, even though it's not marked as the pending transaction. */ [disclaimer: This is totally from my poor memory. Your best bet for getting a deep understanding the register code is thoroughly studying the code and history, and single stepping in gdb.] pending_trans_guid is how the register keeps track of an open, edited transaction. From the user's perspective, navigating to the blank transaction is not an editing operation (especially since it happens automatically when the register opens) and should therefore not dirty the book. So it seems the intention is to never mark a brand-new transaction as the pending transaction. Not exactly, the intention is to not mark a brand-new transaction as pending until it is actually edited. Yet a few routines DO set the brand-new transaction as pending, such as the autocompletion routine gnc_split_register_auto_completion() in split-register-control.c, and a couple of other routines that perform split deletion. That seems correct. So does anyone know why some forms of editing (autocompletion, deleting a split) cause the brand-new transaction to be marked as pending, while all others, including the typical practice of simply typing a transaction in, do not? What is the correct practice? At a higher level, the ideal behaviors are: a) Opening and navigating in a register doesn't dirty the book. b) Editing a transaction doesn't dirty the book until it is committed. c) Closing a register while on an edited, uncommitted transaction will raise the modal commit/rollback dialog. d) Autocompletion counts as editing the transaction. Hope that helps, Thank you, that certainly helps. I've just committed r17628 which prevents brand-new transactions from being mistaken for existing transactions that are being edited in another register. When combined with r17623, this fixes bugs 393383 and 426111. These two patches are pretty small. If you have a minute to give them a quick proofread, at least for a conceptual double-check, I'd be interested in any comments. To me this fixes some fairly obvious bugs (to a fresh pair of eyes, at least) although at this point perhaps I just know enough to be dangerous. :) -chris p.s. Please be especially careful with register code. You probably know this, but over the years, that code has seen a pattern of subtle regressions that have taken months or years to fix (if ever?), and those bugs have caused data corruption. It is _extremely_ easy to break in subtle ways. Thanks, I'm trying to be careful, ask questions, and make minimal changes. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions
On Wed, Oct 15, 2008 at 5:25 AM, Tom Browder [EMAIL PROTECTED] wrote: I would like to see the scheduled transactions (sx) capability enhanced (see enhancement bug # 521285) to be more like Quicken. I would like to see a split-pane in the account window showing due and buttons to push like 'enter', 'edit', and 'skip'. I would like to see the same buttons in the sx editor along with a choice of seeing sx for each account on separate tabs. And of course I will work on this myself (with helpful comments from developers). Thoughts? Feasible? Congratulations on taking this up! I don't know anything about the sx code, but judging by the bug reports this is an area ripe for attention. (I believe at least some of those bug reports are actually underlying register problems, which I am working on.) Anyway, I think Josh Sled is the scheduled transactions expert, so he may be able to help you. -Charles -Tom ___ 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
Register code question
I am debugging the register code and trying to figure out why bogus message boxes can appear, and also why crashes occur in certain cases. I believe that I've figured it out the sources of these problems, but I have a background question to ask before proceeding with a fix. These problems seem to stem from the way that the pending_trans_guid is used when entering a brand new transaction. Can anyone explain the intended use of pending_trans_guid where new transactions are concerned? I came across some comments in split-register-load.c which appear to shed some light. When the bottom line of the register is created (where the user would start entering a new transaction), a new transaction with a single blank split is tied to it but not marked pending: /* We don't want to commit this transaction yet, because the split doesn't even belong to an account yet. But, we don't want to set this transaction as the pending transaction either, because we want to pretend that it hasn't been changed. We depend on some other code (somewhere) to commit this transaction if we really edit it, even though it's not marked as the pending transaction. */ So it seems the intention is to never mark a brand-new transaction as the pending transaction. Yet a few routines DO set the brand-new transaction as pending, such as the autocompletion routine gnc_split_register_auto_completion() in split-register-control.c, and a couple of other routines that perform split deletion. So does anyone know why some forms of editing (autocompletion, deleting a split) cause the brand-new transaction to be marked as pending, while all others, including the typical practice of simply typing a transaction in, do not? What is the correct practice? Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: problem with qif-parse.scm in trunk
On Wed, Sep 24, 2008 at 7:31 AM, David Reiser [EMAIL PROTECTED]wrote: On Sep 24, 2008, at 9:29 AM, Derek Atkins wrote: David Reiser [EMAIL PROTECTED] writes: Turning off the setting of LC_MESSAGES and running: LANG=C /opt/gnucash-svn/bin/gnucash does allow gnucash to start. But I still get the error message in the qif dialog Some characters have been discarded when importing 141003a.qif What if you set LANG=en_US? Or en_US.UTF-8? The 'natural' state of my LANG setting is en_US.UTF-8. That's where I had the initial problem with gnucash trunk failing on launch with the .scm file containing the latin-1 version of the GBP symbol. I get the same illegal byte sequence error on launch with LANG=en_US. In case you haven't already noticed, in r17598 I have backed out the pound symbol changes for bug 141003. Since it involved the same lines as the fix for bug 141002, it prevented 141002 from getting backported into 2.2.7. I have an alternative solution for the pound symbol, but am not 100% happy with it so I have not committed it yet. At least the way is cleared now for the 141002 fix no matter where 141003 ends up. Stay tuned. Dave -- David Reiser [EMAIL PROTECTED] -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compatibility
On Thu, Sep 25, 2008 at 2:07 PM, Derek Atkins [EMAIL PROTECTED] wrote: Hi, Quoting Antonio González de la Llave Gállego [EMAIL PROTECTED]: Hi I want to know two things: 1.- Is the 2.2.6 version of gnucash compatible with Windows Vista Home Basic? Yes. However, due to some date entry problems on Vista I would upgrade to 2.2.7 (which is about to be released) as soon as possible. 2.- It already the spanish language in the downloadable file? Yes. Sorry if the subjects below are in the page (http://www.gnucash.org/es/), but I can´t find it. Thank you -derek PS: Please remember to CC the list on all replies. -- 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 -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: problem with qif-parse.scm in trunk
On Tue, Sep 23, 2008 at 7:07 PM, David Reiser [EMAIL PROTECTED]wrote: On Sep 23, 2008, at 9:50 AM, Charles Day wrote: On Mon, Sep 22, 2008 at 8:38 PM, David Reiser [EMAIL PROTECTED]wrote: On Sep 22, 2008, at 12:42 PM, Charles Day wrote: On Mon, Sep 22, 2008 at 9:41 AM, Charles Day [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 8:13 AM, Derek Atkins [EMAIL PROTECTED] wrote: Quoting David Reiser [EMAIL PROTECTED]: On Sep 22, 2008, at 10:17 AM, Derek Atkins wrote: David Reiser [EMAIL PROTECTED] writes: As it exists currently, qif-parse.scm does not work, even with the escaped version of a3. However, if I change \xa3 to \\xa3, gnucash will run. That looks like a escaping/quoting inconsistency among systems. Is that any easier to solve than the base encoding problem? If you change it to \\xa3 then does it properly deal with the £ in the QIF? -derek I don't know. Is there a sample qif file I can test? What will I be looking for? See http://bugzilla.gnome.org/show_bug.cgi?id=141003 Doubling up the backslashes should break the fix, as then the backslash loses its special regex expression meaning. Sorry, wrong attachment on the previous message. I've now attached the correct one. -Charles Please see the simple QIF file attached. It contains the British Pound symbol in ISO 8859-1 (0xA3). This is what the QIF importer needs to be able to handle. Here is the output of 'od': $ od -c 141003a.qif 000 ! A c c o u n t \n N M y C r e 020 d i t C a r d \n T C C a r d \n 040 ^ \n ! T y p e : C C a r d \n D 2 060 2 / 0 9 / 2 0 0 8 \n P T e s t 100 p a y e e \n T 243 3 8 . 4 6 \n ^ \n 120 -Charles Correct. Doubling the backslash breaks the fix.With LANG=en_US.UTF-8, my system even complains some characters have been discarded during the import when I make the .scm file UTF-8 while the qif is latin-1. (Though I haven't changed the other two files in the changeset...). I need that LANG setting because that's the only way to get gtkprint to use US-letter paper parameters while printing checks. (Unless someone wants to add a gnumeric-style default page setup to gnucash.) If you change that LANG setting, does it affect the QIF import behavior? Regarding page setup, have you tried out Mike Alexander's patch for bug 531871? Hmm. Turns out it was LC_MESSAGES that I was setting to force gtkprint to use US Letter as the default paper. Mike's patch does indeed solve that problem. I'd vote to move that patch to trunk sooner rather than later. Turning off the setting of LC_MESSAGES and running: LANG=C /opt/gnucash-svn/bin/gnucashdoes allow gnucash to start. But I still get the error message in the qif dialog Some characters have been discarded when importing 141003a.qif The Some characters have been discarded message means that the default attempt to convert the string to UTF-8 according to locale has failed and the pound symbol was just deleted instead. If you continue then the import should succeed. I have just tested with that test QIF file myself, and the pound symbols are getting converted to UTF-8 and actually failing the regex match. So it seems that there is a bug here and I am completely bewildered as to how I could have missed it, as I tested the code with a large file chock full of pound symbols. Or somehow fooled myself with a different file (must have). Anyway I will dive in and report back here. Since I'm not setting $LANG anywhere in .profile or .bashrc, I'd guess some setting in the Mac realm is doing it for me. Defeating that kind of setting is not something I think I should do in generic packaging, however. Dave -- David Reiser [EMAIL PROTECTED] -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: problem with qif-parse.scm in trunk
On Mon, Sep 22, 2008 at 8:38 PM, David Reiser [EMAIL PROTECTED]wrote: On Sep 22, 2008, at 12:42 PM, Charles Day wrote: On Mon, Sep 22, 2008 at 9:41 AM, Charles Day [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 8:13 AM, Derek Atkins [EMAIL PROTECTED] wrote: Quoting David Reiser [EMAIL PROTECTED]: On Sep 22, 2008, at 10:17 AM, Derek Atkins wrote: David Reiser [EMAIL PROTECTED] writes: As it exists currently, qif-parse.scm does not work, even with the escaped version of a3. However, if I change \xa3 to \\xa3, gnucash will run. That looks like a escaping/quoting inconsistency among systems. Is that any easier to solve than the base encoding problem? If you change it to \\xa3 then does it properly deal with the £ in the QIF? -derek I don't know. Is there a sample qif file I can test? What will I be looking for? See http://bugzilla.gnome.org/show_bug.cgi?id=141003 Doubling up the backslashes should break the fix, as then the backslash loses its special regex expression meaning. Sorry, wrong attachment on the previous message. I've now attached the correct one. -Charles Please see the simple QIF file attached. It contains the British Pound symbol in ISO 8859-1 (0xA3). This is what the QIF importer needs to be able to handle. Here is the output of 'od': $ od -c 141003a.qif 000 ! A c c o u n t \n N M y C r e 020 d i t C a r d \n T C C a r d \n 040 ^ \n ! T y p e : C C a r d \n D 2 060 2 / 0 9 / 2 0 0 8 \n P T e s t 100 p a y e e \n T 243 3 8 . 4 6 \n ^ \n 120 -Charles Correct. Doubling the backslash breaks the fix.With LANG=en_US.UTF-8, my system even complains some characters have been discarded during the import when I make the .scm file UTF-8 while the qif is latin-1. (Though I haven't changed the other two files in the changeset...). I need that LANG setting because that's the only way to get gtkprint to use US-letter paper parameters while printing checks. (Unless someone wants to add a gnumeric-style default page setup to gnucash.) If you change that LANG setting, does it affect the QIF import behavior? Regarding page setup, have you tried out Mike Alexander's patch for bug 531871? Dave -- David Reiser [EMAIL PROTECTED] Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: problem with qif-parse.scm in trunk
On Mon, Sep 22, 2008 at 8:13 AM, Derek Atkins [EMAIL PROTECTED] wrote: Quoting David Reiser [EMAIL PROTECTED]: On Sep 22, 2008, at 10:17 AM, Derek Atkins wrote: David Reiser [EMAIL PROTECTED] writes: As it exists currently, qif-parse.scm does not work, even with the escaped version of a3. However, if I change \xa3 to \\xa3, gnucash will run. That looks like a escaping/quoting inconsistency among systems. Is that any easier to solve than the base encoding problem? If you change it to \\xa3 then does it properly deal with the £ in the QIF? -derek I don't know. Is there a sample qif file I can test? What will I be looking for? See http://bugzilla.gnome.org/show_bug.cgi?id=141003 Doubling up the backslashes should break the fix, as then the backslash loses its special regex expression meaning. Please see the simple QIF file attached. It contains the British Pound symbol in ISO 8859-1 (0xA3). This is what the QIF importer needs to be able to handle. Here is the output of 'od': $ od -c 141003a.qif 000 ! A c c o u n t \n N M y C r e 020 d i t C a r d \n T C C a r d \n 040 ^ \n ! T y p e : C C a r d \n D 2 060 2 / 0 9 / 2 0 0 8 \n P T e s t 100 p a y e e \n T 243 3 8 . 4 6 \n ^ \n 120 -Charles Dave -- David Reiser [EMAIL PROTECTED] -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 141003.qif Description: Binary data ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FW: Source Code
On Wed, Sep 17, 2008 at 1:40 AM, Byamukama Robinhood [EMAIL PROTECTED]wrote: -- *From:* Byamukama Robinhood *Sent:* 17 September 2008 11:38 *To:* [EMAIL PROTECTED] *Subject:* Source Code Hi Guyz Thanx for the Nice work. I recently downloaded the GNUCASH accounting software it was good. I want to learn C, how do i get the source code. Just go to www.gnucash.org and click on one of the Download choices. You can download the source code from any version you like. For more information on how you can get all the newest source code and start making your own improvements, just send an email to gnucash-devel@gnucash.org and I'm sure there are plenty of people who can give better advice than me. Good day Byamukama Robinhood Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.
On Tue, Sep 16, 2008 at 2:40 PM, Charles Day [EMAIL PROTECTED] wrote:
On Tue, Sep 16, 2008 at 10:54 AM, Charles Day [EMAIL PROTECTED] wrote:
On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler [EMAIL PROTECTED] wrote:
Hi,
On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
Hi Charles,
On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
Trac: http://svn.gnucash.org/trac/changeset/17421
Log:
Add a new function to the gnc_numeric library that converts
denominators to exact powers of ten.
Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
===
--- gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27
15:11:19 UTC (rev 17420)
+++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27
15:33:23 UTC (rev 17421)
+ fraction = converted_val.denom;
+ if (fraction = 0)
+return FALSE;
out of curiosity, what is the reason for disallowing negative
denominators? I am not sure whether there is a gnc_numeric API
function
to switch signs of nom and denom safely, but I am sure that doing it is
possible :-) But maybe the current behavior is actually desired.
I just noticed that ignoring negative denominators means that 1/(-10) is
now printed as 1 * 10, where it was printed as 10.00 before. Is
that a regression we have to fix or not?
I can see how that would happen, because in previous versions, non-decimal
fractions were forced to print in decimal form in some places. So even
though the old routines considered 1/(-10) non-decimal, it would print it as
decimal anyway. I think this takes us back to the original discussion.
Should go ahead and add support for negative denominators to
gnc_numeric_to_decimal()? I must only take less than 5 lines of code.
Here's the first attempt at that change. How are you testing these numbers?
I went ahead and committed this change in r17554. Calling
gnc_numeric_to_decimal on 4/-3 now gets you 12. However, there is an
overflow danger because gnc_numeric_convert() doesn't check for that
(apparently this has been a problem for some time). Someone else should
probably look at that, as I am no expert on 64-bit/128-bit math.
-Charles
$ svn diff
Index: gnc-numeric.c
===
--- gnc-numeric.c (revision 17505)
+++ gnc-numeric.c (working copy)
@@ -1043,7 +1043,14 @@
converted_val = *a;
if (converted_val.denom = 0)
-return FALSE;
+ {
+converted_val = gnc_numeric_convert(converted_val, 1,
GNC_DENOM_EXACT);
+if (gnc_numeric_check(converted_val) != GNC_ERROR_OK)
+ return FALSE;
+*a = converted_val;
+*max_decimal_places = decimal_places;
+return TRUE;
+ }
/* Zero is easily converted. */
if (converted_val.num == 0)
Ciao,
-- andi5
Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.
On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler [EMAIL PROTECTED] wrote: Hi, On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote: Hi Charles, On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote: Trac: http://svn.gnucash.org/trac/changeset/17421 Log: Add a new function to the gnc_numeric library that converts denominators to exact powers of ten. Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c === --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27 15:11:19 UTC (rev 17420) +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27 15:33:23 UTC (rev 17421) + fraction = converted_val.denom; + if (fraction = 0) +return FALSE; out of curiosity, what is the reason for disallowing negative denominators? I am not sure whether there is a gnc_numeric API function to switch signs of nom and denom safely, but I am sure that doing it is possible :-) But maybe the current behavior is actually desired. I just noticed that ignoring negative denominators means that 1/(-10) is now printed as 1 * 10, where it was printed as 10.00 before. Is that a regression we have to fix or not? I can see how that would happen, because in previous versions, non-decimal fractions were forced to print in decimal form in some places. So even though the old routines considered 1/(-10) non-decimal, it would print it as decimal anyway. I think this takes us back to the original discussion. Should go ahead and add support for negative denominators to gnc_numeric_to_decimal()? I must only take less than 5 lines of code. Ciao, -- andi5 Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.
On Tue, Sep 16, 2008 at 10:54 AM, Charles Day [EMAIL PROTECTED] wrote:
On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler [EMAIL PROTECTED] wrote:
Hi,
On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
Hi Charles,
On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
Trac: http://svn.gnucash.org/trac/changeset/17421
Log:
Add a new function to the gnc_numeric library that converts
denominators to exact powers of ten.
Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
===
--- gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27
15:11:19 UTC (rev 17420)
+++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c 2008-07-27
15:33:23 UTC (rev 17421)
+ fraction = converted_val.denom;
+ if (fraction = 0)
+return FALSE;
out of curiosity, what is the reason for disallowing negative
denominators? I am not sure whether there is a gnc_numeric API function
to switch signs of nom and denom safely, but I am sure that doing it is
possible :-) But maybe the current behavior is actually desired.
I just noticed that ignoring negative denominators means that 1/(-10) is
now printed as 1 * 10, where it was printed as 10.00 before. Is
that a regression we have to fix or not?
I can see how that would happen, because in previous versions, non-decimal
fractions were forced to print in decimal form in some places. So even
though the old routines considered 1/(-10) non-decimal, it would print it as
decimal anyway. I think this takes us back to the original discussion.
Should go ahead and add support for negative denominators to
gnc_numeric_to_decimal()? I must only take less than 5 lines of code.
Here's the first attempt at that change. How are you testing these numbers?
$ svn diff
Index: gnc-numeric.c
===
--- gnc-numeric.c (revision 17505)
+++ gnc-numeric.c (working copy)
@@ -1043,7 +1043,14 @@
converted_val = *a;
if (converted_val.denom = 0)
-return FALSE;
+ {
+converted_val = gnc_numeric_convert(converted_val, 1, GNC_DENOM_EXACT);
+if (gnc_numeric_check(converted_val) != GNC_ERROR_OK)
+ return FALSE;
+*a = converted_val;
+*max_decimal_places = decimal_places;
+return TRUE;
+ }
/* Zero is easily converted. */
if (converted_val.num == 0)
Ciao,
-- andi5
Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r17535 - gnucash/trunk/src/gnome-utils - In price and commodity tree views, restore gconf settings after initialization.
On Tue, Sep 16, 2008 at 9:26 PM, Andreas Köhler [EMAIL PROTECTED] wrote: Hi Charles, On Wed, 2008-09-17 at 00:17 -0400, Andreas Köhler wrote: Author: andi5 New Revision: 17535 Trac: http://svn.gnucash.org/trac/changeset/17535 Log: In price and commodity tree views, restore gconf settings after initialization. Previously, gconf settings like sort column and order for price and commodity dialogs were read in while creating the main tree view objects themselves, i.e. before a model has been set. In this early stage of initialization, these properties cannot always be set and are ignored subsequently. Instead, apply the properties after the view has been built and set default sorting column only if no column has been found in gconf. BP I noticed this when looking at r17439 and r17468. If you agree with my findings and everything works for you, I would backport these three commits together. Either all or none of them ;-) Looks like a good idea to me. Unfortunately I may not be unable to do any testing or development for a few days because my graphics card has suddenly decided to begin dying. I have ordered a new one, but for now my system is very unstable (and frequently rather unreadable.) Ciao, -- andi5 PS: If you have not already done so, I would suggest you to build gconf-editor for Windows. It works perfectly (just as Glade-3, but that is a topic I will revive later) and can be quite helpful sometimes. At least for non-automated tasks it is easier to handle than gconftool-2 :-) Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
