Re: Generic importer:QIF
Chintan Agarwal [EMAIL PROTECTED] writes: 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. Like I said, src/engine/Transaction* -- the structure definition is in TransactionP.h, but you shouldn't be using the structure members directly; you should use the functions defined in Transaction.h. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 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: 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
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
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
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. For you this means you don't have to care about bugs that are in the generic importer for now, only about bugs in your own code :-) Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Generic importer:QIF
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
Re: Generic importer:QIF
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
Re: Generic importer:QIF
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: Generic importer:QIF
Chintan Agarwal [EMAIL PROTECTED] writes: frequent occurrence of the word Transaction, I could not successfully find the definition of the data-type(=Transaction data-type). If you could point src/engine/Transaction.[ch] You will generally want to familiarize yourself with the Engine, as it's the core datatypes of the system. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgp8nAN7Ta1u9.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Generic importer:QIF
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? Thanks. -Chintan ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
