On 6/26/20 2:35 PM, enh via Toybox wrote: > toybox patch fails to apply the patch > https://android.googlesource.com/platform/external/snakeyaml/+/refs/heads/master/src/patches/android/Representer.patch
That's html, I clicked the ".txt" link at the bottom and it downloaded a block of "Zy95YW1sL3NuYWtleWFtbC9yZXByZXNlbnRlci9SZXByZXNlbnRlci5qYXZhCkBAIC0xNSw3" which I don't recognize the encoding of? $ file Representer.txt Representer.txt: ASCII text, with very long lines, with no line terminators The debian file command is editorializing, but not helpful. > to the file > https://android.googlesource.com/platform/external/snakeyaml/+/refs/heads/master/src/main/java/org/yaml/snakeyaml/representer/Representer.java. Could you send me the two files? > the worst part is that it _thinks_ it succeeds :-( > > the interesting bit happens when we come to apply this hunk: > > @@ -15,7 +15,6 @@ > */ > package org.yaml.snakeyaml.representer; > > -import java.beans.IntrospectionException; > import java.util.ArrayList; > import java.util.Arrays; > import java.util.Iterator; > > here: > > package org.yaml.snakeyaml.representer; > > import java.beans.IntrospectionException; > import java.util.ArrayList; > import java.util.Arrays; > import java.util.Collections; > import java.util.Iterator; > import java.util.List; > > the eagle-eyed human will notice that there's an extra "Collections" > in the actual file that isn't in the patch, because the patch was > actually against an older version of the source. Didn't commit 333a10f9ef59 fix this back in February? (It was supposed to...) > the bug is that toybox drops that new line in its output. > > it reads it: > > MAYBE: > IN: import java.beans.IntrospectionException; > MAYBE: -import java.beans.IntrospectionException; > IN: import java.util.ArrayList; > MAYBE: import java.util.ArrayList; > IN: import java.util.Arrays; > MAYBE: import java.util.Arrays; > IN: import java.util.Collections; > FUZZED: 21 import java.util.Iterator; > > but then it does a `goto fuzzed` and explicitly drops that line it > just read. which is clearly wrong here, but the code comment > explicitly calls out this behavior: > > // If match failed, flush first line of buffered data and > // recheck buffered data for a new match until we find one or run > // out of buffer. That's leading data. The idea was if you're matching @@ abc - def ghi And the data says: abc abc def ghi It shouldn't see the first abc, read in the second abc and go "nope, that's not def" and then discard _both_ before checking again. (It has to advance _one_ line and try again, thus checking at every possible offset, including rechecking the data it's already buffered because it thought it might be a later part of the hunk under consideration. The actual _start_ of the hunk might be in that mismatched later part it's already read in.) > so i'm not quite sure i understand the intended logic here. when would > you ever want to drop an input line that doesn't have a '-' or '+' > line in the hunk? Can you send me the test files? (I can try to put together a test from what you've sent me, but I'd rather have the real one.) Thanks, Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net