Re: Branch off a 2.2-branch, then merge CSV importer into trunk?
Christian Stimming <[EMAIL PROTECTED]> writes: > Hence, I'd suggest to branch off the stable 2.2 branch now (or: within the > next few weeks), and merge the csv-importer branch into trunk directly after > that so that more people can have a look at the importer code. +1. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpGzBRYYTKdu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branch off a 2.2-branch, then merge CSV importer into trunk?
Quoting Andreas Köhler <[EMAIL PROTECTED]>: >> What do you think? > > +1, as it seems to help development. We/I could do the branching > whenever you like. BTW, are you doing the merge then? I think that if the CSV branch is ready to merge then we should make the 2.2 branch and then merge CSV into trunk. Although there are a few more patches I'd like to get in before the branch, but if I don't, I don't. > Also, what about the other branches? Especially, do you think we can > merge register-rewrite, force people to look at it and give them the > feeling that GnuCash is a nice project to hack on :-) I don't think the RR branch is ready to merge, and I don't think we should merge it until it is ready. > -- andi5 -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: Branch off a 2.2-branch, then merge CSV importer into trunk?
Hi Christian, Am Sonntag, den 07.10.2007, 23:04 +0200 schrieb Christian Stimming: > The subject says it all: The CSV importer in the csv-branch looks good enough > to be merged into our developement trunk. However, it still needs some work > here and there, which is why it shouldn't be merged into the trunk branch as > long as we are still releasing 2.2.x releases from it. > > Hence, I'd suggest to branch off the stable 2.2 branch now (or: within the > next few weeks), and merge the csv-importer branch into trunk directly after > that so that more people can have a look at the importer code. > > What do you think? +1, as it seems to help development. We/I could do the branching whenever you like. BTW, are you doing the merge then? Also, what about the other branches? Especially, do you think we can merge register-rewrite, force people to look at it and give them the feeling that GnuCash is a nice project to hack on :-) -- andi5 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branch off a 2.2-branch, then merge CSV importer into trunk?
Hi, Since I am not a core developer, you may ignore my opinion in this matter. I would like to ask though if someone could have a look at the patches I sent in last Wednesday via this list (the mail was titled "Two small gui improvements"). If they would get accepted and include before branching off 2.2.x, it would mean a lot for me, namely, that the next stable release is slightly easier to work with in my particular case. You can read the other mail to see why that is. Other than that, I have no opinion on this. Geert On Sunday 7 October 2007, Christian Stimming wrote: > The subject says it all: The CSV importer in the csv-branch looks good > enough to be merged into our developement trunk. However, it still needs > some work here and there, which is why it shouldn't be merged into the > trunk branch as long as we are still releasing 2.2.x releases from it. > > Hence, I'd suggest to branch off the stable 2.2 branch now (or: within the > next few weeks), and merge the csv-importer branch into trunk directly > after that so that more people can have a look at the importer code. > > What do you think? > > Christian > ___ > 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
Branch off a 2.2-branch, then merge CSV importer into trunk?
The subject says it all: The CSV importer in the csv-branch looks good enough to be merged into our developement trunk. However, it still needs some work here and there, which is why it shouldn't be merged into the trunk branch as long as we are still releasing 2.2.x releases from it. Hence, I'd suggest to branch off the stable 2.2 branch now (or: within the next few weeks), and merge the csv-importer branch into trunk directly after that so that more people can have a look at the importer code. What do you think? Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CSV Importer
"Benjamin Sperisen" <[EMAIL PROTECTED]> writes: > Anyway, most of what I've done has been to address the shortcomings > discussed earlier. Benjamin, congrats on a pretty successful Summer of Code project. The importer is looking (and working) pretty well. > First, I've reworked the internal error handling code so that, if > there are errors, a new column to the right is created listing the > errors on each particular row. For example, if a row has "abc" in its > "Deposit" column, it will put "Deposit column could not be understood" > in the "Errors" column for that row. I noticed that in my test file, the only regular line in error was a heading line. It'd be nice to have an option of the form "ignore file's header line". (Even better, it'd be good to do default column-type assignments based on the contents of that header line. ;) Secondarily, it'd be nice – in the error handling page – to be able to "ignore" a line in error, easily. It'd be nice to support both the transaction and post date in the importer, since the engine/model does support both, even if the register UI doesn't, right now. Also, I notice the first stage after the file parsing – perhaps part of the Generic Importer, though – is an account tree/selection dialog labeled: "Please select or create an apropriate GnuCash account for: " ... obviously, it'd be nice if the thought was finished about what account I'm supposed to be selecting for. > Second, fixed-width files are now supported. The interface is actually > virtually identical to Gnumeric's, as I merged their code into mine, > particularly for the context menu for column merging. I couldn't figure this out at all... I couldn't see how to mark the boundaries of columns for a fixed-width file. As well, the lines in my fixed-width file were pretty long, which made the dialog open way too wide... 1.5 screens wide, in fact. :( Were there some test data files that you were using? Are those checked in anywhere? I'll see if I can add mine, after I clean them up, as well. > During the fall, I would like to keep working on the importer, even > though I won't be able to work quite as much because of school. The > next feature I'd like to implement is actual editing within the dialog > of data (so that users don't have to go back and manually edit it in a > spreadsheet, save and reimport). Nifty. I hope you're able to find the time to continue to work on this... > I would also like to thank you, Josh and Christian, as well as the > rest of the GnuCash community, for all of your help and guidance over > the summer! This was definitely a great learning experience in many > practical aspects of open source and software development in general. > I have really enjoyed working with all of you and hope to continue in > the future. I'm glad you found it worthwhile. Thank you for sticking with it, and getting a nice new feature added to GnuCash! :) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpzwZFwyv0Od.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
CSV Importer
Hi everyone, Sorry for the long silence from my end! I just committed the work I've done over August in a big chunk. I should have committed it in smaller increments, but the main reason I refrained was that for much of the time it was in a not-so-functional state. :-( I guess this is a lesson in "release (or commit) early and often." Anyway, most of what I've done has been to address the shortcomings discussed earlier. First, I've reworked the internal error handling code so that, if there are errors, a new column to the right is created listing the errors on each particular row. For example, if a row has "abc" in its "Deposit" column, it will put "Deposit column could not be understood" in the "Errors" column for that row. Second, fixed-width files are now supported. The interface is actually virtually identical to Gnumeric's, as I merged their code into mine, particularly for the context menu for column merging. Third (and this took much more time than expected), I've implemented a real "Balance" column. I ended up having to rework a lot of my code a few times before I got this right, mainly because of edge cases I failed to consider at first. The idea is that if we get a file that has the following values in the Balance column: $10 $20 $40 $5 we will get transactions with amounts +$10, +$10, +$20, and -$35 -- if we're importing into an empty account (which is probably the most likely use case). However, if there are already transactions in the account, the importer uses that to change the amounts appropriately such that the balances are always correct. For example, if there was a deposit of $20 already in the account that took place between the dates for the first and second transactions in the file, the second transaction's amount will be changed to -$20 (because the balance would be $40 at that point). If there is a deposit or withdrawal column, I will always use that in preference to the balance column, since this is a much more unreliable way to calculate transaction amounts (as it depends entirely on the values for other transactions, both in the file and not). Never the less, it should work as expected for most people (importing into empty accounts). I've also added support for (ignoring) currency symbols in strings, month-day and month-day (i.e. (no year) dates, and the transaction number field. I put "ignoring" in parentheses because I'm not sure if I should be checking to see if the symbols match the commodity in the account (or if we should even be doing currency conversions), but under normal circumstances this should work. There has also been a significant amount restructuring of the code to ease the building of the features above (and future features as well). During the fall, I would like to keep working on the importer, even though I won't be able to work quite as much because of school. The next feature I'd like to implement is actual editing within the dialog of data (so that users don't have to go back and manually edit it in a spreadsheet, save and reimport). I would also like to thank you, Josh and Christian, as well as the rest of the GnuCash community, for all of your help and guidance over the summer! This was definitely a great learning experience in many practical aspects of open source and software development in general. I have really enjoyed working with all of you and hope to continue in the future. Kind regards, Benny ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
