On Tue, Apr 4, 2017 at 4:42 PM, Rob Landley <r...@landley.net> wrote:
> On 04/04/2017 12:32 PM, enh wrote: > > On Mon, Apr 3, 2017 at 2:43 PM, Rob Landley <r...@landley.net > > <mailto:r...@landley.net>> wrote: > > > > 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.) > > > > 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. > > I have a local diff adding a second "testcmd" function (which differs > from testing in that it implies $C at the start of the command line, so > you don't have to repeat the command name. (See commit ee14fc396dff > adding that late last year: $CMDNAME is the name of the command being > tested, $C is an absolute path to that command to run so we bypass shell > builtins when we use it.) > > Then I'm going through and converting the commands one by one to use it, > and using "I converted that to the new function" (using it at least > once) as a proxy for having reviewed the tests. > 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 :-) > Unfortunately, actually reviewing the tests goes off on tangents very > easily. 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. > And the failure mode of having 15 minutes at a time to work on > toybox is I wind up with lots of partially finished things all over the > tree because I don't remember what I was working on last and keep trying > to grab a small todo item I might be able to finish in one sitting. (Or > at least get it to a point I can check in the next chunk before getting > pulled away. You never know...) > > Sigh. I should at least check in the ones I've already gotten converted. > (Both of them. The third one alphabetically was blkid and I went off on > a tangent fixing something...) > (for those watching in black and white, rob committed these this afternoon.) > The downside, of course, would be having yet more half-finished things > in the tree, and then new commands would start using cmdname _without_ > having been fully vetted. meh, that was never going to work anyway :-) you know what they say: Always Be Cleaning-up. or something like that. > 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). > > > > 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"). > > Which is a start. :) > > I need to fix the help output. 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. 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"). > Lemme fix ls -m first. (I checked in your > first text fixup! There's still a failing test. Legitimately, although > it's a whitespace issue.) > > > 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.) > > > > 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. > > > > the number of changes is starting to get hard to keep track of though, > > so if you could start merging some of them... > > Indeed. I'll try to carve out some time this evening. > > (When I hit a new issue like the ls -m thing I have the choice of > "follow the tangent and get distracted" or "throw it on the ever-growing > todo list containing items I haven't looked at in a year".) > 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. > My netbook finally crashed (failed to suspend properly, only power down > would fix it) so my 8 gazillion open windows/tabs with all the todo > items I hadn't properly written down on the todo lists got zapped. I > suppose that's a form of simplifying. Sigh. > > > (and if there's something you want done differently, tell me now so i > > can start doing the others that way.) > > > > > ...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. :) > > > > 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. > > And here I go "I should fix up and promote gzip decompression side, with > libz config option so you hae a model of what I want it to look like", > and that's ANOTHER tangent from ls -m and testcmd just from earlier this > email. > > (And if I follow said tangent, that would leave this email window open > and half-replied to, that's another thing I lost maybe 3 dozen of in > last week's reboot although possibly thunderbird has drafts of them > auto-saved. Haven't checked yet, it's on the todo list...) > > I need large blocks of time just to complete the giant pile of dangling > threads. Alas, I should be doing GPS code for $DAYJOB. (And I should be > checking in the rest of your patch list from yesterday, which > shortest-job-first says is probably the better scheduling decision...) > > > 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...) > > > > 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? > > I was doing that, it turned out to be hard, trying to remember why. (I > think there's some shared bit-buffer infrastructure that I probably > should move to lib/ but then that tangented into "gzip decompression is > so much slower than zlib because they're dealing with 2 bits at a time > in the initial decision and why was I not doing that...") > 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. 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. > Can of worms, going back to poke at ls -m now. (And then I need to get > back to the GPS code.) > > Rob > -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer.
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net