(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 }