[GNC-dev] [GNC] Fwd: Failed - import of QIF files from Quicken

[Adrien Monteleone]

I seem to recall a development goal being to eliminate Scheme code except for reports.

This might be a good candidate for just re-writing this in C/C++ with proper tests and verbose error output and/or logging.

If someone with the skillset is interested of course.

Regards,
Adrien

> On Feb 18, 2020 w8d49, at 6:35 PM, James Peterson <lyle at austin.rr.com> wrote:
> 
> Well, with no hint of what the problem is, even smaller
> test sets won't necessarily find anything, so it could be 
> a lot of work for no benefit.  For example, I could export
> each account separately (although there are about 80 of them
> so that's a lot of work), and each account could load 
> okay separately, because maybe the problem is an interaction 
> between two different accounts. So then I have to do 80*79
> possible pairs of accounts, and so on.
> 
> My poking around in the 
> source code to try to find the problem suggests that the
> problem is in the Scheme part that seems to be working with
> all the accounts at the same time:
> 
> ;; Build a local account tree to hold converted transactions.
> 
> ;; Sort the account list on the depth of the account path.
> 
> ;; Make all the accounts.
> 
> ;; Run through the markable transactions marking any
>      ;; duplicates.  marked transactions/splits won't get imported.
> 
>               ;; Convert into a GnuCash transaction.
>               ;; rebalance and commit everything
> 
> So this looks like multiple runs thru the data, and even printing
> the line number won't narrow it down -- you have to know what
> step of the process we are doing, and where we are in the data
> at that point.
> 
> As things stand, we don't even know what the immediate problem
> is -- a divide by zero?  Looking for an account that should exist,
> but doesn't?, an account type that it doesn't know about? 
> 
> The code is not written to allow it to even explain what it is
> doing. If we are going to use this code base, someone who actually
> understands, and is comfortable with the code will need to add
> a "verbose input processing" level or something that will create
> a log file explaining what it is going to try to do, then do it,
> then explain what it got and how it interprets that. I've done 
> that with code before, but only C code, where, if need be, there is
> the equivalent of a printf to a log file between every major step,
> or each iteration of a loop, explaining what it thinks it is doing
> and with what input and with what result.  I just don't know how to
> add that to scheme.
> 
> jim