Re: ofx import problems
On 24 Jun 2007, at 5:14:17 AM, Christian Stimming wrote: > Am Sonntag, 24. Juni 2007 06:48 schrieb David Reiser: >> ofx imports of files from ameritrade are giving me serious heartburn >> at the moment. > > Sorry to hear that :-/ > >> does the following gdb info suggest something specific to anyone? > > Try the attached patch on libofx. That should at least fix this > particular > crash. If it indeed fixes the crash, please report this to Benoit > and ask him > to have another libofx release. It worked for me. I'll get a message off to ofx-devel later Monday. Thanks. > > As for your other crash the discussion is continuing on > http://bugzilla.gnome.org/show_bug.cgi?id=450276 . And as I said > there: The > transactions will most probably not be imported correctly yet, but > at least > this won't lead to a crash anymore. > > Christian > Dave -- David Reiser [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Ubuntu Feisty GnuCash Backport
"Eric Ladner" <[EMAIL PROTECTED]> schrieb am Fri, 15 Jun 2007 07:08:54 -0500: > On 6/14/07, Derek Atkins <[EMAIL PROTECTED]> wrote: > > > > > > Some of my clients run Ubuntu Feisty, which is why I rolled > > my own version of 2.0.5 when Ubuntu was stuck on 2.0.2. > > However, today's Ubuntu updates show a "Backport" from > > Gutsy to Feisty. > > > > These work well, and have HBCI support, OFX and aqbanking. The repo > has feisty and edgy support, too. > > http://www.geole.info/Repository-for-deb-packages-deb.9.0.html?&l=1 They work great but it looks like DTAUS support is missing. Could this be added? Thanks, Manfred -- Manfred Usselmann[EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Generic importer:QIF
Am Sonntag, 24. Juni 2007 20:22 schrieb Chintan Agarwal: > Thanks for that information. I could not find the declaration of > Transaction structure(or its un-typedefed form) per say but from the > functions in the file, could gather the variable types present. That is intentional. We don't use direct access to the structure anywhere in gnucash, and you shouldn't use that, too. Instead, all access is done solely by the accessor functions in Transaction.h -- that's the whole point of that file. Do you have doxygen installed? Run "make doc" and a HTML documentation will be created in src/doc/html/index.html; in that documentation, browse to "Files" and go to "Transaction.h". This should give a usable overview of what can be done with a Transaction*. Having said that, there is also the header file src/engine/TransactionP.h where you can observe the actual data fields of the Transaction structure. But as I already mentioned, the structure must not be accessed directly from anywhere else in gnucash. > I think that for QIF importer, we could have a simpler structure, akin OFX > importer wherein the function void gnc_file_ofx_import (void) (in > /src/import-export/ofx/gnc-ofx-import.c)is the top-level function. Sounds okay. > In such > a top-level function there are basically three steps:- > 1) Creating a context for the input data(done by QIF context) > 2) Parsing the data(done by QIF parser written in /src/import-export/qif) > 3) Integrating the parsed data into the Gnucash accounts, actions like > matching, mapping etc.(as pointed out earlier, this is done simply by using > functions in import-main-matcher.h, specifically the function > gnc_gen_trans_list_add_trans(...)). > As for the frontend, it would be there only in step 1 as after that the > parsing process( in the backend) starts and completes. As a high-level description this is fine. However, I think problems will arise in the details, especially for the QIF format. But I would suggest you should commit the first code parts to your branch so that Josh and others can comment on that directly. > Some questions:- > 1) Do the above three steps miss out something vital for QIF import? Yes - the QIF file format has a whole bunch of nasty ambiguities. For that reason, there are multiple places throughout the importing process where the user might have to be asked to resolve some ambiguities (e.g. date format Year/month/day vs. Month/day/Year vs. whatever). The existing OFX importer is an example for you to start with, but QIF needs much more interaction with the user due to these ambiguities compared to the more modern OFX format. Your proposal above might still be sufficient, but please keep in mind you will have to add more user interaction along the way. > 2) The top-level function that would be made should be by what name? In > other words, which function call results in the QIF import process being > trigerred? If you're adding your code in the qif-import directory, just start by modifying the content of the gnc_plugin_qif_import_cmd_new_qif_import() function and have it create your new dialogs instead. > 3) Does GNUCash use the standard GNU indentation format? Currently probably yes, but it's up to the individual developer. There are efforts to unify the indentation. Once these are put in place, clear guidelines about the indentation will be given. As long as you haven't been told anything more specifically, just pick your favorite indentation and stick to it. GNU format is just fine. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Generic importer:QIF
Huh, sorry, I didn't see Derek's answer before writing my own. @Chintan: If I've said anything different from Derek, please ignore my remarks. Derek's answers are (as usual :) more correct than mine. Christian Am Sonntag, 24. Juni 2007 21:21 schrieb [EMAIL PROTECTED]: > Another thing to keep in mind is that the code in src/import-export/qif > was never complete, so you might to consider rewriting the parsing > functions, too, instead of using that code. It's unclear that that > code is correct; it's certainly true that when you merge files together > it doesn't do a good job of keeping them separate enough to be able > to "unload". > > > 2) The top-level function that would be made should be by what name? In > > other words, which function call results in the QIF import process being > > trigerred? > > Choose something. It really doesn't matter what you name the "start qif > import" API. > > > 3) Does GNUCash use the standard GNU indentation format? > > Not exactly. We TRY to use 4-space indentation with no tabs, braces > on the following line. No space between functions and parens, but spaces > between if/while/for and the parens. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Generic importer:QIF
Hi¸ Quoting Chintan Agarwal <[EMAIL PROTECTED]>: > Thanks for that information. I could not find the declaration of Transaction > structure(or its un-typedefed form) per say but from the functions in the > file, could gather the variable types present. > > I think that for QIF importer, we could have a simpler structure, akin OFX > importer wherein the function void gnc_file_ofx_import (void) (in > /src/import-export/ofx/gnc-ofx-import.c)is the top-level function. In such a > top-level function there are basically three steps:- > 1) Creating a context for the input data(done by QIF context) > 2) Parsing the data(done by QIF parser written in /src/import-export/qif) > 3) Integrating the parsed data into the Gnucash accounts, actions like > matching, mapping etc.(as pointed out earlier, this is done simply by using > functions in import-main-matcher.h, specifically the function > gnc_gen_trans_list_add_trans(...)). > As for the frontend, it would be there only in step 1 as after that the > parsing process( in the backend) starts and completes. > > Some questions:- > 1) Do the above three steps miss out something vital for QIF import? No, you also need: 1) the ability to load in multiple files 2) user input for data disambiguation (number/date formats) 3) QIF Category/Account mapping (this isn't in the generic importer; it's pretty QIF specific) Another thing to keep in mind is that the code in src/import-export/qif was never complete, so you might to consider rewriting the parsing functions, too, instead of using that code. It's unclear that that code is correct; it's certainly true that when you merge files together it doesn't do a good job of keeping them separate enough to be able to "unload". > 2) The top-level function that would be made should be by what name? In > other words, which function call results in the QIF import process being > trigerred? Choose something. It really doesn't matter what you name the "start qif import" API. > 3) Does GNUCash use the standard GNU indentation format? Not exactly. We TRY to use 4-space indentation with no tabs, braces on the following line. No space between functions and parens, but spaces between if/while/for and the parens. > -Chintan -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Generic importer:QIF
Thanks for that information. I could not find the declaration of Transaction structure(or its un-typedefed form) per say but from the functions in the file, could gather the variable types present. I think that for QIF importer, we could have a simpler structure, akin OFX importer wherein the function void gnc_file_ofx_import (void) (in /src/import-export/ofx/gnc-ofx-import.c)is the top-level function. In such a top-level function there are basically three steps:- 1) Creating a context for the input data(done by QIF context) 2) Parsing the data(done by QIF parser written in /src/import-export/qif) 3) Integrating the parsed data into the Gnucash accounts, actions like matching, mapping etc.(as pointed out earlier, this is done simply by using functions in import-main-matcher.h, specifically the function gnc_gen_trans_list_add_trans(...)). As for the frontend, it would be there only in step 1 as after that the parsing process( in the backend) starts and completes. Some questions:- 1) Do the above three steps miss out something vital for QIF import? 2) The top-level function that would be made should be by what name? In other words, which function call results in the QIF import process being trigerred? 3) Does GNUCash use the standard GNU indentation format? Thanks. -Chintan On 6/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > src/engine/Transaction.* > > -derek > > Quoting Chintan Agarwal <[EMAIL PROTECTED]>: > > > The OFX importer is proving very useful in understanding how to write a > qif > > importer with the given requirements. There was another question I had. > > This pertains to the variable type Transaction which is required by the > > gnc_gen_trans_list_add_trans function in import-main-matcher.h. Due to > the > > frequent occurrence of the word Transaction, I could not successfully > find > > the definition of the data-type(=>Transaction data-type). If you could > point > > me to the file that contains the same, I would figure out exactly what > > values in the datatype are relevant to QIF. > > Thanks. > > -Chintan > > > > On 6/22/07, Christian Stimming <[EMAIL PROTECTED]> wrote: > >> > >> Hi Chintan, > >> > >> please remember to CC gnucash-devel on all replies. > >> > >> Quoting Chintan Agarwal <[EMAIL PROTECTED]>: > >> > Thanks for the prompt reply. So importing from any format now > >> essentially > >> > involves parsing it and passing on the parsed object to the generic > >> > importer. > >> > >> Yes, exactly. > >> > >> > The front-end, of course has to be taken care of separately. I > >> > actually got confused when I saw import-parse.c in > /src/import-export. > >> Does > >> > this actually parse all the formats(as it has to be generic)? I > >> understand > >> > the post parsing part, as all the formats are then on a common > footing > >> and > >> > the same code can be used for mapping etc. However, I could not > >> understand > >> > the generic parser part. > >> > >> I don't think the functions of import-parse.h are used anywhere at > >> all. Basically you can ignore that file. The mainly interesting parts > >> of the "generic importer" is in import-main-matcher.h; you probably > >> don't need much else than that. > >> > >> > Also, if we have all the code generic( i.e. deals > >> > with all the various formats), what would be the difference between > >> various > >> > branches(OFX, HBCI, QIF etc.)? > >> > >> Again, import-parse.h is currently unused. The different > >> sub-directories all create a Transaction* and pass it to the functions > >> in import-main-matcher.h. > >> > >> > PS: I just hope I code enough to have bugs in them ;) > >> > >> Heheh. > >> > >> Christian > >> > >> > > >> > On 6/22/07, Christian Stimming < [EMAIL PROTECTED]> wrote: > >> >> > >> >> Quoting Chintan Agarwal < [EMAIL PROTECTED]>: > >> >> > >> >>> Can the code in /src/import-export/import-backend.c and other files > in > >> >> the > >> >>> same folder be used for mapping a parsed qif file? As far as I > >> >> understand, > >> >>> this is the generic framework that we want to use for all imports. > Is > >> my > >> >>> understanding right? > >> >> > >> >> Yes, this is completely right. > >> >> > >> >> Also not that there are still a few bugs in the "generic importer" > >> >> (import-backend.c code) > >> >> > http://lists.gnucash.org/pipermail/gnucash-devel/2007-June/020669.html > >> >> , but I'm quite confident those will get fixed over the next months. > >> > >> > > ___ > > 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: Release date 2.2.0? Another release candidate before that?
Christian Stimming <[EMAIL PROTECTED]> writes: > * Should we have another "release candidate" version (2.1.5) next weekend? > That would result in the final 2.2.0 around July 15th. I think (at least) a 2.1.5 is advisable. > SVN and uploaded on Saturday, June 30th. Binary package is created and > uploaded by Monday, July 2nd (and needs to be copied to gnucash.org as well). > Announcement is sent out on Tuesday, July 3rd. Does that sound fine? July 3rd is the day before a major USian holiday (Independence Day), which this year happens to be on a Wednesday. I'm not sure quite what impact that will have on "press", but it might be better to schedule the release for the following week. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp8hYBccLQ9h.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Release date 2.2.0? Another release candidate before that?
Our 2.1.4 release candidate is receiving improved bugreports of things that don't work. On the upside this means the package already works in the majority of cases and with most features. I think we're progressing nicely towards a 2.2.0 release that will work for enough Windows users so that we can call it a stable release. Open question from my side: * Should we have another "release candidate" version (2.1.5) next weekend? That would result in the final 2.2.0 around July 15th. * Or should we just go ahead and prepare 2.2.0 next weekend? As for the actual release and announcement date: As discussed on http://wiki.gnucash.org/wiki/Release_Schedule , we need to set a date for preparation of the source tarball, then allow some 2-3 extra days for the preparation and upload of the Windows binary, and send out the announcement after that. Nathan said he would prefer to have the announcement on a Tuesday. If we aim for next weekend, this means: Source package is tagged in SVN and uploaded on Saturday, June 30th. Binary package is created and uploaded by Monday, July 2nd (and needs to be copied to gnucash.org as well). Announcement is sent out on Tuesday, July 3rd. Does that sound fine? If we decide on another release candidate 2.1.5 (which should be released as usual with the immediate announcement), the above dates would be shifted by two weeks. Also, I've added some proposed announcements on http://wiki.gnucash.org/wiki/Announcement_2.2.0 where one text was my first try for a more story-like announcement, geared towards "popular press", and the other text is our usual announcement for the more technically oriented users. Everyone is invited to edit these heavily and improve by whatever you can come up with. Regards Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: ofx import problems
Am Sonntag, 24. Juni 2007 06:48 schrieb David Reiser: > ofx imports of files from ameritrade are giving me serious heartburn > at the moment. Sorry to hear that :-/ > does the following gdb info suggest something specific to anyone? Try the attached patch on libofx. That should at least fix this particular crash. If it indeed fixes the crash, please report this to Benoit and ask him to have another libofx release. As for your other crash the discussion is continuing on http://bugzilla.gnome.org/show_bug.cgi?id=450276 . And as I said there: The transactions will most probably not be imported correctly yet, but at least this won't lead to a crash anymore. Christian ? libofx-0.8.1.tar.gz Index: lib/ofx_preproc.cpp === RCS file: /cvsroot/libofx/libofx/lib/ofx_preproc.cpp,v retrieving revision 1.18 diff -u -r1.18 ofx_preproc.cpp --- lib/ofx_preproc.cpp 24 Jan 2007 08:53:54 - 1.18 +++ lib/ofx_preproc.cpp 24 Jun 2007 09:13:50 - @@ -470,7 +470,7 @@ tagname_idx++; } //cerr <___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
