> > the message shows after the debugging output from creating the answer to
> > the test. so it's not the null case that is showing the advancing pointers,
> > it's the next test where one of the docs is empty and the other has a
> > length of 3, so it's probably totally correct! OOPS!
>
> We want to formally apologize for earlier introducing what appeared like an
> advanced software engineering that was in fact deceptive due to me
> interpreting correct output as if it were indicative of a problem, and as if
> it were indicative of the cause of an unrelated problem.
onward ... ! ;p
here's the function again:
689 size_t l1 = 0, l2 = 0;
690 size_t tot2 = 0;
691 for (auto && new_line : against) {
692 extend_env(new_line);
693 if (dynxdfs[1].size() >= window_size) {
694 do_diff();
(gdb)
695 co_yield get_diff_for(l1, l2);
696 // if l1 or l2 overflows this likely means that file 1
was exhausted while there were still matching values in file 2 for some reason.
maybe they weren't passed through nreff?
697 while (l1) {
698 dynxdfs[0].consume();
699 -- l1;
700 }
701 tot2 += l2;
702 while (l2) {
703 dynxdfs[1].consume();
704 -- l2;
(gdb)
705 }
706 /*dbg: consume window*/
707 }
708 }
709 do_diff();
710
711 while (l1 < dynxdfs[0].size() || l2 < dynxdfs[1].size()) {
712 co_yield get_diff_for(l1, l2);
713 }
714 }
So, this is the first time I've run with a partial window and also data. I'm
thinking there's a reasonable chance that it could be because do_diff() is
being called more than once by exhausting the window partway through for the
first time. It could also be in the consume calls, which was my first thought
and is another likely candidate since I recently modified those and they may
not have ever even been called before. In fact, thinking on that, I'm leaning
back toward them being the culprits agai--
[but basically if i step through and take notes i can just see!
