[Toybox] [PATCH] Implement dmesg -T.

[Rob Landley]

On 04/03/2017 03:03 PM, enh wrote:
> since i have to maintain a parallel build system, promotion/demotion
> just mean extra work for me, so i'm always happier with the status quo :-)

Trying to converge the build systems is on my todo list. :)

(But today I'm playing with GPS signal tracking heuristics for $DAYJOB.
I'm finally seeing #%*(&%&# bit edges in the raw antenna data! Pretty
sure I have to correct code phase _before_ trying to track doppler
because it's just too noisy otherwise, but I might be able to use the
signal strength (vector length) as a weight for the phase angle deltas.
Dunno if that's helpful yet. This is _so_ much easier since I converted
everything to polar coordinates...)

> as for the more recent patches i've been sending... it's not that i hate
> awk -- i'd actually love to have the time to sit down and write toybox
> awk -- but i'm trying to get to where we pass all the toybox tests [for
> the toys we're using] on Android.

I note that some of the tests are broken and most are incomplete. (I
don't have a pending directory for test code, and large chunks of it
were contributed.)

I keep meaning to do a "finishing pass" where I find commands I think
are done, read through the relevant specs (posix, lsb, and/or man page)
line by line, write a test for every statement and corner case I can
think of in its command.test file, then read through the command
implementation and writte any additional tests _that_ brings up (and
making sure the "deltas from posix" section is filled out and has
tests), make sure the command passes all of the tests, and then mark
both command and test READY (for 1.0).

It's on the todo list. (It's part of the roadmap.html annotation.) Alas
I've been getting to spend about 4 hours on toybox in a _good_ week
recently. (Where "recently" is longer than I care to admit. And it tends
to be in 15 minute chunks, which are less useful than one 4 hour block
would be.)

> ...and one reason i'm [finally] paying that the attention it deserves is
> that i have a libz-based gzip that i'll add to _tool_box in the short
> term and then work out how to get that into toybox (since you'll
> presumably want your no-dependencies version too, but you presumably
> won't want to reimplement the libz interface).

I have a todo item to do libz wrapper versions of gzip/gunzip already,
but at this rate you may get to it before I do. :)

I've had the decompress side of gzip implemented in the "compress"
utility in pending for a while (works fine as far as I know), which
needs to become gunzip.c. I have about the first 1/4 of the compression
side but it writes everything out as "stored" gzip blocks (not actually
compressed; my research went down a "when do you perform dictionary
resets" rathole and I got distracted).

I note that to implement git you need the libz style header (not the
gzip or zip or raw header), because that's how git stores data. (There's
a youtube video with somebody decompressing git objects from the command
line using the perl zlib module; inside it's a text file with
keyword:value headers followed by data, a bit like smtp or http. Doing a
simple git reader (repo downloader) isn't actually _that_ big a deal,
it's merges and such that get complciated. (I say that not having
studied the network protocol yet. And implementing "bisect" might hurt,
dunno yet.)

I was thinking of having the name "compress" be a front-end to deal with
multiple compression types (hence the help text, and things like
handling gzip zlib format with command line options), but that was a bit
of a cul-de-sac and I need to back it out again. (If I did it that way
I'd either bundle gzip/bzip/xz into compress.c, or have horrible
cross-command dependencies, or have the engines of those under lib.
Doesn't seem worth it...)

Oh, and I have a folder with the references to implement zip.c. Maybe i
can find a weekend to devote to that sometime.

> but i may as well commit
> the tests to toybox right away. not least because some of the existing
> tests (like the tar tests) implicitly test gzip/gunzip/zcat.

I'm happy to merge tests for commands that aren't implemented yet. I may
tweak them when the command goes in, but good tests are always useful.

Rob