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 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
