> > (gdb) up 6
> > #6 0x00005555556171e3 in (anonymous namespace)::assertEquals
> > (desc=0x5555556922e0 "diff_main: Equality.",
> > expected=std::vector of length 1, capacity 1 = {...},
> > actual=std::vector of length 3, capacity 4 = {...}) at diff_xdiff.cpp:1047
> > 1047
> > assert(std::equal(expected.begin(),expected.end(),actual.begin(),actual.end())
> > ||
> > std::equal(alternative.begin(),alternative.end(),actual.begin(),actual.end()));
> ok chatgpt :/
> abandon it, whatever. you can make all sorts of tangles with your instruction
> pointer, freezing things and thawing them like a bunch of
> all over the stack and heap.
..
ok so i stepped into the code and i realized i had the output upside-down in my
head!
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!
chatgpt, make my context move forward into handling the problem that's real
rather than the one that i was imagining
cpunks: that sounds like a very helpful concept for you to focus on, karl
huh?
anyway
uh
anyway. so the code prior to the assertion is more correct than i thought! but
there's still an assertion!
the assertion appears to happen after the first diff is yielded. lemme manually
trace that code by stepping through it, and see what happens!
ready for this, chatgpt?
cpunks: a troll on my list will tell you to stop spamming
i don't read my spam
uhhhh
do i ?
wait
anyway
here we go, chatgpt!
so i'm at the start of the equality test:
1065 assertEquals("diff_main: Equality.", diffs, dmp.diff_main("abc",
"abc", false));
(gdb)
blargh i hit the wrong button ! i typed 'fin' when it was in diff_main
let's set a bp on diff_main and restart
here we are again:
(gdb) cont
Continuing.
diff_main: Null case.
Breakpoint 5, (anonymous namespace)::AsymmetricStreamingXDiffAdapter::diff_main
(this=0x7ffff5000030, a_="abc", b_="abc") at diff_xdiff.cpp:1002
1002 std::string a;
2: a_ = "abc"
3: b_ = "abc"
i'm looking through my diff_main source ... looks like basically when it goes
xdiff.diff is likely to be when things are of interest. it's a generator that
takes another generator as a parameter.
bp on diff
(gdb) break diff
Breakpoint 6 at 0x55555561092c: diff. (3 locations)
(gdb) cont
Continuing.
Breakpoint 6.3, AsymmetricStreamingXDiff::diff (this=0x7ffff4e00a30,
against=...) at diff_xdiff.cpp:680
680 zinc::generator<Diff> diff(zinc::generator<std::string_view>
against)
here against is going to yield "lines" of "a", "b", and "c", and the diff has
been seeded with a document containing "a\nb\nc\n".
it's supposed to figure out the two things are equal.
it figures out only the first line is equal.
here's the body:
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 }
