isCallable fails

[tsbockman]

On Thursday, 21 January 2021 at 05:20:27 UTC, frame wrote:
> I was not asking here to re-produce my code or debug since it 
> cannot provide a snippet if I do not know what could cause the 
> error.

Generally, I don't need to know what causes an error in order to 
produce an MCVE. I have successfully done so on many occasions. 
It's annoying and slow, but usually very possible.

If it seems like it's going to be really difficult for a 
particular bug, it's fine to try asking others without an MCVE 
first. But, you should think of MCVE discovery as a valuable 
skill, not an impossibility.

My technique works like this:

0) Make note of the symptoms/message for the specific failure 
that I am trying to isolate.
1) Make a separate copy of the program's source code which I can 
freely destroy.
2) Remove, simplify, or mock up/stub out (like for unit tests) 
some large chunk of the remaining code in the program, from a 
part of the program that I *think* is unrelated to the error.
3) Re-test the program.
     a) If the failure goes away, goto (2) and try again by 
removing a different part of the program.
     b) If the failure is still present and I think there is more 
that could be removed or simplified, goto (2).
     c) If the failure is still present, and I don't see anything 
else to remove or simplify, then I'm done. Whatever is left of 
the source code (hopefully something short and non-proprietary) 
is my MCVE.

It's sort of a guess-and-check binary search for the minimum code 
that triggers the error. This process can be quite tedious, but 
it often does not require already knowing the cause of the error. 
(dustmite is a tool that partially automates this.)

Sometimes it's worth going through, because having an MCVE is 
*really* useful, especially for other people who don't know the 
rest of your project's mostly-unrelated code base and 
dependencies well.