<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 18, 2022 at 4:55 PM enh <<a href="mailto:enh@google.com">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 18, 2022 at 9:02 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/15/22 21:19, enh wrote:<br>
> On Fri, Jul 15, 2022 at 9:34 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
> On 7/14/22 18:53, enh wrote:<br>
> > On Wed, Jul 13, 2022 at 11:58 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>><br>
> > <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>>> wrote:<br>
> ><br>
> > On 7/12/22 19:13, enh via Toybox wrote:<br>
> > > so.. --transform works (though it confused people that it's not in<br>
> the --help<br>
...<br>
> Yeah but August 6 is 3 months from the previous release and I'd like to do that<br>
> on a more regular schedule (modulo maybe slipping a bit to sync up with kernel<br>
> releases for mkroot), meaning I want to finish this properly soonish. :)<br>
> <br>
> I have a half dozen open cans of worms right now... dd, sh, mkroot walkthrough,<br>
> diff, tar --transform, a redo of lib/passwd.c and everything depending on it,<br>
> and in file.c:<br>
> <br>
> + * TODO: XZ, JPEG size, dpkg.deb, rpm, mp3, odt, mp4, iso<br>
> + * MBR boot sector (partition X: startsector %d, %d sectors;)<br>
> + * word (.docx: Word 2007+), excel<br>
> <br>
> you shouldn't do those yourself --- you should make each of those a separate bug<br>
> on github with a "help wanted" or "starter project" label, and then next time<br>
> you have someone asking "hey, is there something i can look at?", you have stuff<br>
> ready and waiting...<br>
<br>
Good suggestion, but I'm never sure what actually _is_ easy. I shelved this<br>
after doing about half of mp3 identification, which turns out to be a<br>
surprisingly large rathole due to funky container formats. (And I don't trust<br>
anything microsoft's ever touched not to be turing-complete to solve...)<br></blockquote><div><br></div><div>heh, i know exactly what you mean because (a) i have this problem all the time at work, where people don't finish their "starter project" for years and (b) your specific jpeg size example was one _i_ punted when i originally submitted jpeg support because it turned out to be non-obvious.</div><div><br></div><div>i still think this is the "least worst" option though, and that's actually one reason why i suggested a separate bug for each: it lets people thrash about a bit until they find one that _is_ easy (for them).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> (not that you can 100% trust me not to do some of those when i've had a week<br>
> when i didn't get to write even a line of code and i'm looking for something to<br>
> do. but i'm trying to _stop_ doing all the easy little pieces myself at work for<br>
> similar reasons!)<br>
> <br>
> Trying to close tabs for a release. :)<br>
<br>
And of course I symmetrically added -a to nsenter and unshare before noticing<br>
that debian only has -a in nsenter and not unshare. I also don't know why<br>
nsenter has -S and -G but unshare doesn't? It seems like "create new container"<br>
and "insert process into existing container" are almost the same problem space...?<br></blockquote><div><br></div><div>(that seems reasonable to me unless proven otherwise.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Stream forward until you hit a diff, and then accumulate lines from each file<br>
> one at a time scanning BACKWARDS in the other file to find matching lines (where<br>
> does new last line of file 2 match in the list-since-difference of file1), and<br>
> when you find -U *2 lines of match you've ended the hunk. Flush what you've seen<br>
> (keeping the usual three lines of starting context) and move forward again as<br>
> matched. This usually leaves unconsumed lines in the other file (sometimes ALL<br>
> of what we've loaded from one file is unconsumed, that happens when you add or<br>
> remove a single line in isolation for example) but you just need to feed those<br>
> back in as "new" lines to the search algorithm...<br>
> <br>
> Yeah it's an N^2 search algorithm but what's the biggest hunk you've ever seen,<br>
> 200 lines? 1000? Modern hardware doing N^2 search over 1000 lines isn't going to<br>
> break stride. The INPUT FILE size doesn't matter, except as a theoretical bound<br>
> on the upper size of the hunk if you diff two completely unrelated files, but<br>
> optimizing for that case seems silly?<br>
> <br>
> aye, though -- like you -- i assume that's the kind of pathological case they<br>
> were thinking of.<br>
<br>
A) so where's the test case?<br></blockquote><div><br></div><div>tests?! did you ever look at any of the bell labs boys' stuff? :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
B) McIlroy's paper was published in 1976. which is theoretically 30 iterations<br>
of Moore's Law ago, implying we can literally handle a billion times as much<br>
corner case processing as they could.<br>
<br>
> (because although it never happens "for real", it happens<br>
> interactively, and that's probably when people are most sensitive to speed.) i<br>
> don't remember seeing a single hunk more than tens of lines (except the other<br>
> pathological case of "new file"). <br>
<br>
If people can send me a test case, I'm happy to fix it?<br>
<br>
In theory the improved search the paper described is just a subset of the N^2<br>
search that abandons attempts faster to find a non-optimal solution quickly.<br>
They're just doing it over the whole file instead of a current potential hunk...<br>
<br>
> > > but in the meantime<br>
> > > the kernel build script now uses --null with<br>
> > ><br>
> > <br>
> -T: <a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a><br>
> <<a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a>><br>
> > <br>
> <<a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a><br>
> <<a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a>>><br>
> > ><br>
> > <br>
> <<a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a><br>
> <<a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a>><br>
> > <br>
> <<a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a><br>
> <<a href="https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964" rel="noreferrer" target="_blank">https://cs.android.com/android/kernel/superproject/+/common-android-mainline:build/kernel/build.sh;l=964</a>>>><br>
<br>
I have no idea why your email system does this.<br></blockquote><div><br></div><div>and sadly, it's not clever enough for me to say "plain text for mailing lists, html for everything else". (or even just "plain text for any thread i _start_, but respect whatever's already in use for any thread i _reply_ to".)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But now that I've gone "well here's the 80/20 solution to handling mode shifts",<br>
> I'm tempted to code that up instead. Lemme see if I get to it this weekend, if<br>
> not I owe you this applied before monday.<br>
> <br>
> sgtm. i've been trying to stop committing things on fridays, so monday's the<br>
> earliest i'd be giving the kernel folks a new prebuilt anyway :-)<br>
<br>
Didn't get it done over the weekend. Reeducating myself on args plumbing corner<br>
cases instead...<br></blockquote><div><br></div><div>ack. i tried to take an update but hit another -Werror=format-security issue with one of your diff.c changes. i've sent a patch (and a separate patch to add that -Werror= to the default toybox configure, since that's one we always have to fix in the end anyway; may as well catch them fresh?).</div><div><br></div><div>i'll try again tomorrow... (i want to try to use `timeout -i` too!)</div></div></div></blockquote><div><br></div><div>heh, this doesn't seem intentional (especially because it happens without `-i`), but it wasn't obvious to me what the fix is?</div><div><br></div><div>~/toybox$ time ./toybox timeout -s SEGV 10 ./foo<br>timeout: exec ./foo: No such file or directory<br><br>real 0m10.035s<br>user 0m0.009s<br>sys 0m0.013s<br>~/toybox$ <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>
</blockquote></div></div>