<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 3, 2017 at 2:43 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/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>
</span>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>
<span class=""><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>
</span>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></blockquote><div><br></div><div>that's all the more reason why i want to go through them. at the moment i think we're not paying much attention to them because we know they're not great. i'd like to get to the point where "all tests passing" is the default.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>yeah, that's what i've tried to do with gzip/gunzip/zcat too (though the weaker version in the absence of a spec of "verify every claim in the --help output").</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.)</blockquote><div><br></div><div>that's one of the good things about at least polishing the existing tests: we'll need better tests eventually, but "something is better than nothing", and all the ones i've looked at so far were fittable into 15 minute gaps between meetings.</div><div><br></div><div>the number of changes is starting to get hard to keep track of though, so if you could start merging some of them...</div><div><br></div><div>(and if there's something you want done differently, tell me now so i can start doing the others that way.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><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>
</span>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></blockquote><div><br></div><div>yeah, it's all done and passing the tests. (including the toybox tar tests, since tar shells out to gzip.) i'll get it committed to toolbox this week and then start worrying about porting to toybox.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've had the decompress side of gzip implemented in the "compress"<br>
utility in pending for a while (works fine as far as I know), which<br>
needs to become gunzip.c. I have about the first 1/4 of the compression<br>
side but it writes everything out as "stored" gzip blocks (not actually<br>
compressed; my research went down a "when do you perform dictionary<br>
resets" rathole and I got distracted).<br>
<br>
I note that to implement git you need the libz style header (not the<br>
gzip or zip or raw header), because that's how git stores data. (There's<br>
a youtube video with somebody decompressing git objects from the command<br>
line using the perl zlib module; inside it's a text file with<br>
keyword:value headers followed by data, a bit like smtp or http. Doing a<br>
simple git reader (repo downloader) isn't actually _that_ big a deal,<br>
it's merges and such that get complciated. (I say that not having<br>
studied the network protocol yet. And implementing "bisect" might hurt,<br>
dunno yet.)<br>
<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></blockquote><div><br></div><div>yeah, that's how things are at the moment, which is one reason i decided to do this in toolbox first. i guess it will be easiest if my patch adds a new pending/gzip.c and just #if 0s out those parts of compress.c and then let you decide how you want to implement the non-libz variant?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Oh, and I have a folder with the references to implement zip.c. Maybe i<br>
can find a weekend to devote to that sometime.<br>
<span class=""><br>
> but i may as well commit<br>
> the tests to toybox right away. not least because some of the existing<br>
> tests (like the tar tests) implicitly test gzip/gunzip/zcat.<br>
<br>
</span>I'm happy to merge tests for commands that aren't implemented yet. I may<br>
tweak them when the command goes in, but good tests are always useful.<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>