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 <l...@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

_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Reply via email to