Also a big reason why the classic "git flow" is bad. There's no new merge base, ever.

I don't think there's a fundamental restriction.

A big one is that we don't really have a general model for what the correct answer is. That makes it hard to even throw ML at it. For a signal that is just some (slowly changing) tones or just a bunch of separate transients this is easy, but when it's a combination or neither of those...

Right, the facet / facet-core separation already makes this a possibility (and the same split could still be done for serde, I think)

Of course, but the macros could still be decoupled from the core traits and evolve separately. Everyone depends on "serde_traits" v1, but different versions of serde_derive can coexist. Something worth considering for facet? Maybe the macro paths would get too ugly...

Huh but this isn't even a case of "serde is stable", there could be a serde_derive 2.0 right? At the expense of compile times of course...

But yeah one is doing check and the other is doing whatever, and those are mutually exclusive too so this doesn't seem to be true

I always thought it was doing something that the manually invoked Cargo would otherwise have to do, taking just as long

def should have an attribution :/

Looks like it's from "A fast bit-vector algorithm for approximate string matching based on dynamic programming" (Myers, 1999) dl.acm.org/doi/10.1145/.... The variable names are close to the pseudocode. Each cell of the matrix is represented as 0,+1,+2 and it's done in 1x64 blocks.