<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 4, 2017 at 4:42 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/04/2017 12:32 PM, enh wrote:<br>
> On Mon, Apr 3, 2017 at 2:43 PM, Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a><br>
</span><span class="">> <mailto:<a href="mailto:rob@landley.net">rob@landley.net</a>>> wrote:<br>
><br>
> On 04/03/2017 03:03 PM, enh wrote:<br>
> > since i have to maintain a parallel build system, promotion/demotion<br>
> > just mean extra work for me, so i'm always happier with the status quo :-)<br>
><br>
> Trying to converge the build systems is on my todo list. :)<br>
><br>
> (But today I'm playing with GPS signal tracking heuristics for $DAYJOB.<br>
> I'm finally seeing #%*(&%&# bit edges in the raw antenna data! Pretty<br>
> sure I have to correct code phase _before_ trying to track doppler<br>
> because it's just too noisy otherwise, but I might be able to use the<br>
> signal strength (vector length) as a weight for the phase angle deltas.<br>
> Dunno if that's helpful yet. This is _so_ much easier since I converted<br>
> everything to polar coordinates...)<br>
><br>
> > as for the more recent patches i've been sending... it's not that i hate<br>
> > awk -- i'd actually love to have the time to sit down and write toybox<br>
> > awk -- but i'm trying to get to where we pass all the toybox tests [for<br>
> > the toys we're using] on Android.<br>
><br>
> I note that some of the tests are broken and most are incomplete. (I<br>
> don't have a pending directory for test code, and large chunks of it<br>
> were contributed.)<br>
><br>
> that's all the more reason why i want to go through them. at the moment<br>
> i think we're not paying much attention to them because we know they're<br>
> not great. i'd like to get to the point where "all tests passing" is the<br>
> default.<br>
<br>
</span>I have a local diff adding a second "testcmd" function (which differs<br>
from testing in that it implies $C at the start of the command line, so<br>
you don't have to repeat the command name. (See commit ee14fc396dff<br>
adding that late last year: $CMDNAME is the name of the command being<br>
tested, $C is an absolute path to that command to run so we bypass shell<br>
builtins when we use it.)<br>
<br>
Then I'm going through and converting the commands one by one to use it,<br>
and using "I converted that to the new function" (using it at least<br>
once) as a proxy for having reviewed the tests.<br></blockquote><div><br></div><div>ah, i remembered you talking about this, so didn't include "gzip" as prefixes to the test names in my new tests. one of the things on my to-do list was working out why it didn't seem to be working :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unfortunately, actually reviewing the tests goes off on tangents very<br>
easily.</blockquote><div><br></div><div>definitely. i saw the "ls -m" bug too, but deliberately _didn't_ look in to it because i didn't want to get distracted. i'm explicitly not looking at stuff like that on my first pass. for now i just want to enable (where possible) running the toybox tests on a toybox-only system.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> And the failure mode of having 15 minutes at a time to work on<br>
toybox is I wind up with lots of partially finished things all over the<br>
tree because I don't remember what I was working on last and keep trying<br>
to grab a small todo item I might be able to finish in one sitting. (Or<br>
at least get it to a point I can check in the next chunk before getting<br>
pulled away. You never know...)<br>
<br>
Sigh. I should at least check in the ones I've already gotten converted.<br>
(Both of them. The third one alphabetically was blkid and I went off on<br>
a tangent fixing something...)<br></blockquote><div><br></div><div>(for those watching in black and white, rob committed these this afternoon.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The downside, of course, would be having yet more half-finished things<br>
in the tree, and then new commands would start using cmdname _without_<br>
having been fully vetted.</blockquote><div><br></div><div>meh, that was never going to work anyway :-) you know what they say: Always Be Cleaning-up. or something like that. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I keep meaning to do a "finishing pass" where I find commands I think<br>
> are done, read through the relevant specs (posix, lsb, and/or man page)<br>
> line by line, write a test for every statement and corner case I can<br>
> think of in its command.test file, then read through the command<br>
> implementation and writte any additional tests _that_ brings up (and<br>
> making sure the "deltas from posix" section is filled out and has<br>
> tests), make sure the command passes all of the tests, and then mark<br>
> both command and test READY (for 1.0).<br>
><br>
> yeah, that's what i've tried to do with gzip/gunzip/zcat too (though the<br>
> weaker version in the absence of a spec of "verify every claim in the<br>
> --help output").<br>
<br>
</span>Which is a start. :)<br>
<br>
I need to fix the help output.</blockquote><div><br></div><div>don't worry: i meant my own help output based on playing with the GNU and busybox versions. yes, i am a cowboy who started writing the code before starting to write the tests.</div><div><br></div><div>there's all kinds of weird shit, from the harmless (such as "all three of gzip/gunzip/zcat accept the same arguments, even if most of them are meaningless for gunzip/zcat") to the WTF (such as the GNU-only "if the filename you give me doesn't exist, i'll try to find a file that does and use that instead").</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Lemme fix ls -m first. (I checked in your<br>
first text fixup! There's still a failing test. Legitimately, although<br>
it's a whitespace issue.)<br>
<span class=""><br>
> It's on the todo list. (It's part of the roadmap.html annotation.) Alas<br>
> I've been getting to spend about 4 hours on toybox in a _good_ week<br>
> recently. (Where "recently" is longer than I care to admit. And it tends<br>
> to be in 15 minute chunks, which are less useful than one 4 hour block<br>
> would be.)<br>
><br>
> that's one of the good things about at least polishing the existing<br>
> tests: we'll need better tests eventually, but "something is better than<br>
> nothing", and all the ones i've looked at so far were fittable into 15<br>
> minute gaps between meetings.<br>
><br>
> the number of changes is starting to get hard to keep track of though,<br>
> so if you could start merging some of them...<br>
<br>
</span>Indeed. I'll try to carve out some time this evening.<br>
<br>
(When I hit a new issue like the ls -m thing I have the choice of<br>
"follow the tangent and get distracted" or "throw it on the ever-growing<br>
todo list containing items I haven't looked at in a year".)<br></blockquote><div><br></div><div>funnily enough, i didn't even tell you i'd found that because i didn't want to distract you. for me the thing i'm most interested in right now (because i've ignored it for far too long) is getting to where i can run all the tests on a regular basis.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My netbook finally crashed (failed to suspend properly, only power down<br>
would fix it) so my 8 gazillion open windows/tabs with all the todo<br>
items I hadn't properly written down on the todo lists got zapped. I<br>
suppose that's a form of simplifying. Sigh.<br>
<span class=""><br>
> (and if there's something you want done differently, tell me now so i<br>
> can start doing the others that way.)<br>
><br>
> > ...and one reason i'm [finally] paying that the attention it deserves is<br>
> > that i have a libz-based gzip that i'll add to _tool_box in the short<br>
> > term and then work out how to get that into toybox (since you'll<br>
> > presumably want your no-dependencies version too, but you presumably<br>
> > won't want to reimplement the libz interface).<br>
><br>
> I have a todo item to do libz wrapper versions of gzip/gunzip already,<br>
> but at this rate you may get to it before I do. :)<br>
><br>
> yeah, it's all done and passing the tests. (including the toybox tar<br>
> tests, since tar shells out to gzip.) i'll get it committed to toolbox<br>
> this week and then start worrying about porting to toybox.<br>
<br>
</span>And here I go "I should fix up and promote gzip decompression side, with<br>
libz config option so you hae a model of what I want it to look like",<br>
and that's ANOTHER tangent from ls -m and testcmd just from earlier this<br>
email.<br>
<br>
(And if I follow said tangent, that would leave this email window open<br>
and half-replied to, that's another thing I lost maybe 3 dozen of in<br>
last week's reboot although possibly thunderbird has drafts of them<br>
auto-saved. Haven't checked yet, it's on the todo list...)<br>
<br>
I need large blocks of time just to complete the giant pile of dangling<br>
threads. Alas, I should be doing GPS code for $DAYJOB. (And I should be<br>
checking in the rest of your patch list from yesterday, which<br>
shortest-job-first says is probably the better scheduling decision...)<br>
<span class=""><br>
> I was thinking of having the name "compress" be a front-end to deal with<br>
> multiple compression types (hence the help text, and things like<br>
> handling gzip zlib format with command line options), but that was a bit<br>
> of a cul-de-sac and I need to back it out again. (If I did it that way<br>
> I'd either bundle gzip/bzip/xz into compress.c, or have horrible<br>
> cross-command dependencies, or have the engines of those under lib.<br>
> Doesn't seem worth it...)<br>
><br>
> yeah, that's how things are at the moment, which is one reason i decided<br>
> to do this in toolbox first. i guess it will be easiest if my patch adds<br>
> a new pending/gzip.c and just #if 0s out those parts of compress.c and<br>
> then let you decide how you want to implement the non-libz variant?<br>
<br>
</span>I was doing that, it turned out to be hard, trying to remember why. (I<br>
think there's some shared bit-buffer infrastructure that I probably<br>
should move to lib/ but then that tangented into "gzip decompression is<br>
so much slower than zlib because they're dealing with 2 bits at a time<br>
in the initial decision and why was I not doing that...")<br></blockquote><div><br></div><div>yeah, like i said, i'll ship this in toolbox first anyway. unfortunately i've been adding new tests. i'm down to just one TODO in the code now though.</div><div><br></div><div>speaking of which: i have TODOs in the tests about how to test "don't compress/uncompress from a tty without -f", because i can't think of a way to write that test.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can of worms, going back to poke at ls -m now. (And then I need to get<br>
back to the GPS code.)<br>
<span class="HOEnZb"><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Elliott Hughes - <a href="http://who/enh" target="_blank">http://who/enh</a> - <a href="http://jessies.org/~enh/" target="_blank">http://jessies.org/~enh/</a><br>Android native code/tools questions? Mail me/drop by/add me as a reviewer.</div>
</div></div>