> and now check out the variables in the failed assertion
>
> (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()));
> (gdb) p expected
> $1 = std::vector of length 1, capacity 1 = {{type = EQUAL, text = "abc"}}
> (gdb) p equal
> $2 = equal # oops here i output the wrong word
> (gdb) p actual
> $3 = std::vector of length 3, capacity 4 = {{type = EQUAL, text = "a"}, {type
> = DELETE, text = "bc"}, {type = INSERT, text = "bc"}}
>
> actual has the wrong content. expected is what it should have. after the
> first character, it started making weird diffs 💁 !
>
> maybe how things change after the first thing is related to the extra
> consumed pointers !ok chatgpt :/ so one of the things i got into pushing at this was c++20 generators. just a little bit. c++20 made coroutines in such a way that you can do all sorts of hijinx with them. it's kind of like a structure and pattern that lets you put one functions stack into a variable, mid-execution, anywhere in the stack, and shift execution to anywhere else in another function, and then return to this spot if you want, or abandon it, whatever. you can make all sorts of tangles with your instruction pointer, freezing things and thawing them like a bunch of mind controlled hackers or politicians or whatever handling switching and amnesia and flashbacks, with a big papertrail all over the stack and heap. yup ! so obv its very messy, as well as poorly documented, and you can see my implementation of a generator at https://raw.githubusercontent.com/karl3wm/zinc/refs/heads/main/include/zinc/__generator.hpp ohhh i'm in a client that can attach files now i'll attach it . it's the attached __generator.hpp file. This is actually not my work, I took a reference implementation (omg i should have taken one from a standard library they are so much simpler and more efficient) and tried to modify it to evaluate eagerly so i could use temporaries like braced init lists as parameters. compare that slog to this implementation from somebody who tried to know what they were doing: https://raw.githubusercontent.com/storm-ptr/step20/refs/heads/main/generator.hpp (attached as generator.hpp without the prefixed underbars). Look how short and simple and clear it is! !! step20 is licensed MIT. _anyway_ generators look like normal calls, but under the hood they are a bunch of function calls to things inside the compiler runtime, and the gdb i've been using isn't tuned for them; additionally when you use coroutines your real, actual stack trace turns into a mess, with all sorts of different stack frames hanging off each other and freaky stuff, gdb has a big challenge there when i step through the generators the execution pointer jumps between the prolog and epilog and only occasionally engages the actual next statement. there's a lot of hidden code without sourcelines that gets executed. in debugging __generator i had to infer what this hidden code was here and there to resolve issues }:! some of it is specified but other stuff actually matters that isn't specified ;s .... so additionally the stack trace isn't right, stuff can get left out that one would intuitively expect to be there, or things show in different spots ... and when you step through it it can be ineffective, it can work better to set a breakpoint on the next line than step to it
__generator.hpp
Description: Binary data
generator.hpp
Description: Binary data
