Re: [Toybox] hexdump tests.
On Wed, Mar 27, 2024 at 6:22 AM Rob Landley wrote: > > On 3/25/24 10:42, enh wrote: > > On Sun, Mar 24, 2024 at 1:40 AM Rob Landley wrote: > >> > >> On 3/22/24 15:02, enh wrote: > >> >> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves > >> >> > but no-one > >> >> > else? :-) > >> >> > >> >> I _don't_ trust myself, and I'm not special. (That's policy.) > >> > > >> > yeah, but that's why i suggested > >> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION --- that way we can say "we > >> > can't make hard assertions about the _host's_ whitespace, but we can > >> > still make hard assertions about _ours_". if we just canonicalize all > >> > the whitespace all the time, we can't (say) ensure that columns line > >> > up or whatever. > >> > >> Or we could just "NOSPACE=1 TEST_HOST=1 make tests" if that's the test we > >> want > >> to run...? > > > > it's not though. that's my point. there are several cases: > > > > 1. testing toybox --- we know what whitespace we're expecting to > > produce, and want tests to protect against regressions. > > > > 2. testing host tools --- we _don't_ have control over what whitespace > > the host produces. > > a) in some cases we manually mark individual tests to show "we don't > > care about host whitespace for this test case". > > b) sometimes this applies to _all_ the tests for a toy. > > > > we're talking about case 2b here, which is currently the > > least-well-supported variant. > > You can NOSPACE=1 in an individual tests/command.test and it should last until > the end of the file? That's why scripts/test.sh does: > > # Run command.test in a subshell > (. "$1"; cd "$TESTDIR"; echo "$FAILCOUNT" > continue) > > So the variables and functions and so on defined in one test don't leak into > others. I spent like 3 commits getting that to work properly, the last of > which > was commit 07bbc1f61280 and mentions the previous 2. > > > i think we're talking at cross purposes because _i'm_ talking about > > variables set _within the tests, by the tests themselves_ and you're > > talking about variables set on the command-line, which i don't think > > make any sense here, because we're talking about properties of the > > individual tests/commands. > > There are three scopes: > > 1) Variables exported into all tests > > POTATO=1 make tests > > 2) Variables set for a single test: > > POTATO=1 testcmd "thingy" "-x woo" "expected\n" "file" "stdin" > > 3) Variables set for the current test file. > > [ -n "$TEST_HOST" ] && NOSPACE=1 > > Which is just a normal assignment (or export) in a tests/file.test, they go > away > at the end of the current file (because of the above parenthetical subshell > calling it), and which was the new thing I added in 2022. > > I remember my first attempt at this years ago ctrl-c didn't work reliably, but > the fix to that was just a trap at the top of scripts/test.sh: > > # Kill child processes when we exit > trap 'kill $(jobs -p) 2>/dev/null; exit 1' INT > > > (unless you really do want to say "there's absolutely nothing we can > > do about host whitespace, so give up completely", which i think has > > yet to be proven that it's _that_ bad. but there are commands where > > having a test that says "this whitespace -- that toybox produces -- is > > reasonable [but as long as the non-whitespace matches, and there's > > _some_ whitespace everywhere we have whitespace, we'll accept any > > whitespace from the host tool]".) > > I think per-command [ -n "$TEST_HOST" ] && NOSPACE=1 might be reasonable. I'd > rather not blanket do it for all commands. +1. that's what we'd done so far, and i think it's been working pretty well. i thought you were saying you wanted something with file scope, but if not, i think we're in violent agreement to just keep doing what we've been doing :-) > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] hexdump tests.
On 3/25/24 10:42, enh wrote: > On Sun, Mar 24, 2024 at 1:40 AM Rob Landley wrote: >> >> On 3/22/24 15:02, enh wrote: >> >> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but >> >> > no-one >> >> > else? :-) >> >> >> >> I _don't_ trust myself, and I'm not special. (That's policy.) >> > >> > yeah, but that's why i suggested >> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION --- that way we can say "we >> > can't make hard assertions about the _host's_ whitespace, but we can >> > still make hard assertions about _ours_". if we just canonicalize all >> > the whitespace all the time, we can't (say) ensure that columns line >> > up or whatever. >> >> Or we could just "NOSPACE=1 TEST_HOST=1 make tests" if that's the test we >> want >> to run...? > > it's not though. that's my point. there are several cases: > > 1. testing toybox --- we know what whitespace we're expecting to > produce, and want tests to protect against regressions. > > 2. testing host tools --- we _don't_ have control over what whitespace > the host produces. > a) in some cases we manually mark individual tests to show "we don't > care about host whitespace for this test case". > b) sometimes this applies to _all_ the tests for a toy. > > we're talking about case 2b here, which is currently the > least-well-supported variant. You can NOSPACE=1 in an individual tests/command.test and it should last until the end of the file? That's why scripts/test.sh does: # Run command.test in a subshell (. "$1"; cd "$TESTDIR"; echo "$FAILCOUNT" > continue) So the variables and functions and so on defined in one test don't leak into others. I spent like 3 commits getting that to work properly, the last of which was commit 07bbc1f61280 and mentions the previous 2. > i think we're talking at cross purposes because _i'm_ talking about > variables set _within the tests, by the tests themselves_ and you're > talking about variables set on the command-line, which i don't think > make any sense here, because we're talking about properties of the > individual tests/commands. There are three scopes: 1) Variables exported into all tests POTATO=1 make tests 2) Variables set for a single test: POTATO=1 testcmd "thingy" "-x woo" "expected\n" "file" "stdin" 3) Variables set for the current test file. [ -n "$TEST_HOST" ] && NOSPACE=1 Which is just a normal assignment (or export) in a tests/file.test, they go away at the end of the current file (because of the above parenthetical subshell calling it), and which was the new thing I added in 2022. I remember my first attempt at this years ago ctrl-c didn't work reliably, but the fix to that was just a trap at the top of scripts/test.sh: # Kill child processes when we exit trap 'kill $(jobs -p) 2>/dev/null; exit 1' INT > (unless you really do want to say "there's absolutely nothing we can > do about host whitespace, so give up completely", which i think has > yet to be proven that it's _that_ bad. but there are commands where > having a test that says "this whitespace -- that toybox produces -- is > reasonable [but as long as the non-whitespace matches, and there's > _some_ whitespace everywhere we have whitespace, we'll accept any > whitespace from the host tool]".) I think per-command [ -n "$TEST_HOST" ] && NOSPACE=1 might be reasonable. I'd rather not blanket do it for all commands. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] hexdump tests.
On Sun, Mar 24, 2024 at 1:40 AM Rob Landley wrote: > > On 3/22/24 15:02, enh wrote: > >> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but > >> > no-one > >> > else? :-) > >> > >> I _don't_ trust myself, and I'm not special. (That's policy.) > > > > yeah, but that's why i suggested > > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION --- that way we can say "we > > can't make hard assertions about the _host's_ whitespace, but we can > > still make hard assertions about _ours_". if we just canonicalize all > > the whitespace all the time, we can't (say) ensure that columns line > > up or whatever. > > Or we could just "NOSPACE=1 TEST_HOST=1 make tests" if that's the test we want > to run...? it's not though. that's my point. there are several cases: 1. testing toybox --- we know what whitespace we're expecting to produce, and want tests to protect against regressions. 2. testing host tools --- we _don't_ have control over what whitespace the host produces. a) in some cases we manually mark individual tests to show "we don't care about host whitespace for this test case". b) sometimes this applies to _all_ the tests for a toy. we're talking about case 2b here, which is currently the least-well-supported variant. i think we're talking at cross purposes because _i'm_ talking about variables set _within the tests, by the tests themselves_ and you're talking about variables set on the command-line, which i don't think make any sense here, because we're talking about properties of the individual tests/commands. (unless you really do want to say "there's absolutely nothing we can do about host whitespace, so give up completely", which i think has yet to be proven that it's _that_ bad. but there are commands where having a test that says "this whitespace -- that toybox produces -- is reasonable [but as long as the non-whitespace matches, and there's _some_ whitespace everywhere we have whitespace, we'll accept any whitespace from the host tool]".) > >> Erik did lash (lame-ass shell) to be tiny, Ash was the bigass lump of > >> complexity > >> copied out of debian or some such and nailed to the side of the project by > >> that > >> insane Russian developer who never did learn english and communitcated > >> entirely > >> through a terrible translator program (so any conversation longer than 2 > >> sentences turned into TL;DR in EITHER direction, he was also hugely > >> territorial > >> about anybody else touching "his" code), and msh was the minix shell > >> mostly used > >> on nommu systems. > > > > did lash _stay_ tiny? > > Yes, but it was also borderline unusable. > > > i feel like the trouble with projects like that > > is usually that no-one can agree on what's necessary versus bloat, so > > you trend towards just being a bad implementation of whatever. iirc > > inferno had _two_ different "tiny" shells. > > Erik implemented something tiny for his own personal use, and ignored > everybody > else who tried to add stuff to it. > > When Erik moved on, I studied it. When I moved on, Bernhard removed it: > > https://git.busybox.net/busybox/commit/?id=96702ca945a8 > > >> > because, to be fair to the confused, in english > >> > "pending" _can_ legitimately mean "almost there". whereas your whole > >> > point with > >> > pending is "i actually have _no_ idea how close this is yet". > >> > >> Linux has drivers/staging but I didn't like that. > > > > yeah, "staging" also sounds very much like "nearly there!". > > The problem is motivated reasoning. We could call the directory > instant_death_do_not_touch and people would still enable stuff in it to see if > it worked for them. (And then ship it when it Worked For Them.) > > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] hexdump tests.
On 3/22/24 15:02, enh wrote: >> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but >> > no-one >> > else? :-) >> >> I _don't_ trust myself, and I'm not special. (That's policy.) > > yeah, but that's why i suggested > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION --- that way we can say "we > can't make hard assertions about the _host's_ whitespace, but we can > still make hard assertions about _ours_". if we just canonicalize all > the whitespace all the time, we can't (say) ensure that columns line > up or whatever. Or we could just "NOSPACE=1 TEST_HOST=1 make tests" if that's the test we want to run...? >> Erik did lash (lame-ass shell) to be tiny, Ash was the bigass lump of >> complexity >> copied out of debian or some such and nailed to the side of the project by >> that >> insane Russian developer who never did learn english and communitcated >> entirely >> through a terrible translator program (so any conversation longer than 2 >> sentences turned into TL;DR in EITHER direction, he was also hugely >> territorial >> about anybody else touching "his" code), and msh was the minix shell mostly >> used >> on nommu systems. > > did lash _stay_ tiny? Yes, but it was also borderline unusable. > i feel like the trouble with projects like that > is usually that no-one can agree on what's necessary versus bloat, so > you trend towards just being a bad implementation of whatever. iirc > inferno had _two_ different "tiny" shells. Erik implemented something tiny for his own personal use, and ignored everybody else who tried to add stuff to it. When Erik moved on, I studied it. When I moved on, Bernhard removed it: https://git.busybox.net/busybox/commit/?id=96702ca945a8 >> > because, to be fair to the confused, in english >> > "pending" _can_ legitimately mean "almost there". whereas your whole point >> > with >> > pending is "i actually have _no_ idea how close this is yet". >> >> Linux has drivers/staging but I didn't like that. > > yeah, "staging" also sounds very much like "nearly there!". The problem is motivated reasoning. We could call the directory instant_death_do_not_touch and people would still enable stuff in it to see if it worked for them. (And then ship it when it Worked For Them.) Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] hexdump tests.
On 23/3/24 07:02, toybox-requ...@lists.landley.net wrote: Date: Fri, 22 Mar 2024 13:02:18 -0700 From: enh To: Rob Landley Cc: toybox@lists.landley.net Subject: Re: [Toybox] hexdump tests. Message-ID: Content-Type: text/plain; charset="UTF-8" On Mon, Mar 18, 2024 at 6:04?AM Rob Landley wrote: On 3/15/24 16:24, enh wrote: Sure, but that said some tests _DO_ care about the exact amount of whitespace (are columns aligned), or tabs vs spaces. i know what you mean, but at the same time, i'm struggling to thing of a single case i've been involved with where the "upstream" tool hasn't screwed me over by doing something stupid sooner or later... Yup. And yet... I'm thinking maybe strip _trailing_ whitespace? It's not user-visible and I can't think of an instance where it's semantically relevant. (LEADING whitespace is semantically relevant all the time, interstitial a lot too. But trailing generally shouldn't BE there...) CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but no-one else? :-) I _don't_ trust myself, and I'm not special. (That's policy.) yeah, but that's why i suggested CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION --- that way we can say "we can't make hard assertions about the _host's_ whitespace, but we can still make hard assertions about _ours_". if we just canonicalize all the whitespace all the time, we can't (say) ensure that columns line up or whatever. The problem is "dump hex" isn't a big enough job that pulling it out into a library function that can be shared is really a win. It's another one of those "the fighting is so vicious because the stakes are so small" things. Maybe if I could genericize the "show hex in 4 digit groups, now do octal!" variants into some sort of engine... but I worry that the glue to call the engine would be bigger than any savings. od and hexdump are weird there in that the former lets you express quite a large variety of different dumps, and the latter (i think) pretty much anything. i have wondered whether the others can't mostly be written in terms of hexdump. (xxd still has all the reverse stuff, but as long as no-one else does, that's not duplication.) Yeah, it _seems_ like there's something I can do there, but I'm tired of being distracted by it. *shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in the meantime... yeah, like you say, these are some of the simplest commands anyway. i'd be a lot more worried if we had four seds or four shells :-) At the end of my tenure, busybox had FIVE shells, although that last one was my fault and two of them were the "xkcd standards" problem. Erik did lash (lame-ass shell) to be tiny, Ash was the bigass lump of complexity copied out of debian or some such and nailed to the side of the project by that insane Russian developer who never did learn english and communitcated entirely through a terrible translator program (so any conversation longer than 2 sentences turned into TL;DR in EITHER direction, he was also hugely territorial about anybody else touching "his" code), and msh was the minix shell mostly used on nommu systems. did lash _stay_ tiny? i feel like the trouble with projects like that is usually that no-one can agree on what's necessary versus bloat, so you trend towards just being a bad implementation of whatever. iirc inferno had _two_ different "tiny" shells. Somebody then started hush as the "one shell to rule them all" replacement but work on it petered out. Not sure whose baby that was because the entire busybox community collapsed at about the same time: Erik Andersen ran a startup and got so overworked his marriage nearly collapsed, Manuel Nova's girlfriend died, Glenn McGrath tried a GPL enforcement action down in australia/new zealand and it left such a bad taste in his mouth he quit open source development entirely, Mike Frysinger started maintaining seperate for-profit forks of every project he touched and never pushing anything upstream which eventually resulted in the blackfin architecture (his dayjob) being declared dead and yanked from linux/arch and never even making it into qemu... And that's ignoring the whole uclibc->buildroot saga... *shrug* Hush dying was pretty minor in context: the busybox community imploded and I stepped in to prop up what I could until Bruce went "you, volunteer who is mopping the floors, you're doing it wrong, do it MY WAY, I have _seniority_ and you've been doing everything in my name all along anyway whether you know it nor not"... Anyway, before all that happened I printed out the bash man page into a 3 ring binder to read on the bus and started my own "one shell to rule them all", bbsh.c, and work ended on that when bruce chased me off busybox. Denys removed it pretty early on in his tenure, but as far as
Re: [Toybox] hexdump tests.
On Mon, Mar 18, 2024 at 6:04 AM Rob Landley wrote: > > On 3/15/24 16:24, enh wrote: > > Sure, but that said some tests _DO_ care about the exact amount of > > whitespace > > (are columns aligned), or tabs vs spaces. > > > > i know what you mean, but at the same time, i'm struggling to thing of a > > single > > case i've been involved with where the "upstream" tool hasn't screwed me > > over by > > doing something stupid sooner or later... > > Yup. And yet... > > I'm thinking maybe strip _trailing_ whitespace? It's not user-visible and I > can't think of an instance where it's semantically relevant. (LEADING > whitespace > is semantically relevant all the time, interstitial a lot too. But trailing > generally shouldn't BE there...) > > > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but > > no-one > > else? :-) > > I _don't_ trust myself, and I'm not special. (That's policy.) yeah, but that's why i suggested CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION --- that way we can say "we can't make hard assertions about the _host's_ whitespace, but we can still make hard assertions about _ours_". if we just canonicalize all the whitespace all the time, we can't (say) ensure that columns line up or whatever. > > The problem is "dump hex" isn't a big enough job that pulling it out > > into a > > library function that can be shared is really a win. It's another one > > of those > > "the fighting is so vicious because the stakes are so small" things. > > Maybe if I > > could genericize the "show hex in 4 digit groups, now do octal!" > > variants into > > some sort of engine... but I worry that the glue to call the engine > > would be > > bigger than any savings. > > > > od and hexdump are weird there in that the former lets you express quite a > > large > > variety of different dumps, and the latter (i think) pretty much anything. i > > have wondered whether the others can't mostly be written in terms of > > hexdump. > > (xxd still has all the reverse stuff, but as long as no-one else does, > > that's > > not duplication.) > > Yeah, it _seems_ like there's something I can do there, but I'm tired of being > distracted by it. > > > *shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in > > the > > meantime... > > > > yeah, like you say, these are some of the simplest commands anyway. i'd be > > a lot > > more worried if we had four seds or four shells :-) > > At the end of my tenure, busybox had FIVE shells, although that last one was > my > fault and two of them were the "xkcd standards" problem. > > Erik did lash (lame-ass shell) to be tiny, Ash was the bigass lump of > complexity > copied out of debian or some such and nailed to the side of the project by > that > insane Russian developer who never did learn english and communitcated > entirely > through a terrible translator program (so any conversation longer than 2 > sentences turned into TL;DR in EITHER direction, he was also hugely > territorial > about anybody else touching "his" code), and msh was the minix shell mostly > used > on nommu systems. did lash _stay_ tiny? i feel like the trouble with projects like that is usually that no-one can agree on what's necessary versus bloat, so you trend towards just being a bad implementation of whatever. iirc inferno had _two_ different "tiny" shells. > Somebody then started hush as the "one shell to rule them all" replacement but > work on it petered out. Not sure whose baby that was because the entire > busybox > community collapsed at about the same time: Erik Andersen ran a startup and > got > so overworked his marriage nearly collapsed, Manuel Nova's girlfriend died, > Glenn McGrath tried a GPL enforcement action down in australia/new zealand and > it left such a bad taste in his mouth he quit open source development > entirely, > Mike Frysinger started maintaining seperate for-profit forks of every project > he > touched and never pushing anything upstream which eventually resulted in the > blackfin architecture (his dayjob) being declared dead and yanked from > linux/arch and never even making it into qemu... And that's ignoring the whole > uclibc->buildroot saga... > > *shrug* Hush dying was pretty minor in context: the busybox community imploded > and I stepped in to prop up what I could until Bruce went "you, volunteer who > is > mopping the floors, you're doing it wrong, do it MY WAY, I have _seniority_ > and > you've been doing everything in my name all along anyway whether you know it > nor > not"... > > Anyway, before all that happened I printed out the bash man page into a 3 ring > binder to read on the bus and started my own "one shell to rule them all", > bbsh.c, and work ended on that when bruce chased me off busybox. Denys removed > it pretty early on in his tenure, but as far as I'd gotten was what was > checked > in to pending until the current round of shell work started... > > > Yes
Re: [Toybox] hexdump tests.
On 3/15/24 16:24, enh wrote: > Sure, but that said some tests _DO_ care about the exact amount of > whitespace > (are columns aligned), or tabs vs spaces. > > i know what you mean, but at the same time, i'm struggling to thing of a > single > case i've been involved with where the "upstream" tool hasn't screwed me over > by > doing something stupid sooner or later... Yup. And yet... I'm thinking maybe strip _trailing_ whitespace? It's not user-visible and I can't think of an instance where it's semantically relevant. (LEADING whitespace is semantically relevant all the time, interstitial a lot too. But trailing generally shouldn't BE there...) > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but no-one > else? :-) I _don't_ trust myself, and I'm not special. (That's policy.) > The problem is "dump hex" isn't a big enough job that pulling it out into > a > library function that can be shared is really a win. It's another one of > those > "the fighting is so vicious because the stakes are so small" things. > Maybe if I > could genericize the "show hex in 4 digit groups, now do octal!" variants > into > some sort of engine... but I worry that the glue to call the engine would > be > bigger than any savings. > > od and hexdump are weird there in that the former lets you express quite a > large > variety of different dumps, and the latter (i think) pretty much anything. i > have wondered whether the others can't mostly be written in terms of hexdump. > (xxd still has all the reverse stuff, but as long as no-one else does, that's > not duplication.) Yeah, it _seems_ like there's something I can do there, but I'm tired of being distracted by it. > *shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in > the > meantime... > > yeah, like you say, these are some of the simplest commands anyway. i'd be a > lot > more worried if we had four seds or four shells :-) At the end of my tenure, busybox had FIVE shells, although that last one was my fault and two of them were the "xkcd standards" problem. Erik did lash (lame-ass shell) to be tiny, Ash was the bigass lump of complexity copied out of debian or some such and nailed to the side of the project by that insane Russian developer who never did learn english and communitcated entirely through a terrible translator program (so any conversation longer than 2 sentences turned into TL;DR in EITHER direction, he was also hugely territorial about anybody else touching "his" code), and msh was the minix shell mostly used on nommu systems. Somebody then started hush as the "one shell to rule them all" replacement but work on it petered out. Not sure whose baby that was because the entire busybox community collapsed at about the same time: Erik Andersen ran a startup and got so overworked his marriage nearly collapsed, Manuel Nova's girlfriend died, Glenn McGrath tried a GPL enforcement action down in australia/new zealand and it left such a bad taste in his mouth he quit open source development entirely, Mike Frysinger started maintaining seperate for-profit forks of every project he touched and never pushing anything upstream which eventually resulted in the blackfin architecture (his dayjob) being declared dead and yanked from linux/arch and never even making it into qemu... And that's ignoring the whole uclibc->buildroot saga... *shrug* Hush dying was pretty minor in context: the busybox community imploded and I stepped in to prop up what I could until Bruce went "you, volunteer who is mopping the floors, you're doing it wrong, do it MY WAY, I have _seniority_ and you've been doing everything in my name all along anyway whether you know it nor not"... Anyway, before all that happened I printed out the bash man page into a 3 ring binder to read on the bus and started my own "one shell to rule them all", bbsh.c, and work ended on that when bruce chased me off busybox. Denys removed it pretty early on in his tenure, but as far as I'd gotten was what was checked in to pending until the current round of shell work started... > Yes I saw your email in the other thread about pending not being granular > enough, but didn't really have anything coherent to say in response? I see > pending as an unfinished todo heap I need to drain, and I feel bad for not > cleaning it up fast enough. Doing non-cleaning work there is like > organizing > trash piles. Attempting to categorize the bulk wasn't an unambiguous win > even > for toys/ which is _intended_ to keep growing rather than shrink, so > adding it > to pending doesn't appeal. I don't really want spend architectural design > cycles > on scaffolding that gets torn down again. > > indeed. > > i think the only half-way practical idea i had was "keep pending but just > switch > to a much scarier name". I need to clean it all up. I just haven't quite gotten my groove back post-pandemic and people
Re: [Toybox] hexdump tests.
On Fri, Mar 15, 2024 at 2:06 PM Rob Landley wrote: > On 3/15/24 09:58, enh wrote: > > On Thu, Mar 14, 2024 at 9:25 PM Rob Landley wrote: > > > I could make ours do that, or I could export NOSPACE=1 at the start o > the test > > > (since each one runs as a child process now meaning environment > variable > > > assignments won't persist into other tests) > > > > or have a NOSPACE that _doesn't_ reset? > > NOSPACE already doesn't reset, I've been doing shell prefix assignment to > set it > for individual commands, ala: > > $ NOSPACE=1 bash -c 'env | grep NOSPACE' > NOSPACE=1 > $ echo -n $NOSPACE > $ > > If I just NOSPACE=1 on its own line it should apply to all the tests in the > current script, then clean up at the end because each test script runs as a > (child process) with its own environment. > > And that's probably correct here because diff -b ignores changes in the > AMOUNT > of space but not the EXISTENCE of space, so "a b c" and "abc" still > wouldn't > match, which is what I was worried about. (I thought -b yanks space, but > instead > it normalizes it.) > > > i feel like most of the tools that > > produce human-readable output have this problem otherwise: (a) upstream > often > > has a weird duplicative implementation that leads to bizarre behavior > and (b) > > they keep changing things (possibly without even noticing, since it's > whitespace). > > Sure, but that said some tests _DO_ care about the exact amount of > whitespace > (are columns aligned), or tabs vs spaces. > i know what you mean, but at the same time, i'm struggling to thing of a single case i've been involved with where the "upstream" tool hasn't screwed me over by doing something stupid sooner or later... CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but no-one else? :-) > > (xxd, which has the `-r` option, seems like the partial exception, but > even > > there as long as xxd can consume any [text] input it's likely to be > given, i > > don't think it matters exactly what the text output's whitespace looks > like?) > > > > > > but that weakens the test, or maybe > > I could add a "NOTRAIL=1" that runs the output through sed 's/[ > \t]*$//' or some > > such? > > > > Anyway, reviewing commands to promote them out of pending is a > thing, and I'm > > trying close tabs rather than open more just now. > > > > (i didn't even realize there was a hexdump in pending! missed that > somehow...) > > It mostly comes up when I complain we've got FOUR hex dumpers that share > no code > (it's the fourth, you added the third with xxd, posix od and my hexedit > were the > first two), but the recent revisit tipped me over into "alright, I'll > clean it > up..." > > The problem is "dump hex" isn't a big enough job that pulling it out into a > library function that can be shared is really a win. It's another one of > those > "the fighting is so vicious because the stakes are so small" things. Maybe > if I > could genericize the "show hex in 4 digit groups, now do octal!" variants > into > some sort of engine... but I worry that the glue to call the engine would > be > bigger than any savings. > od and hexdump are weird there in that the former lets you express quite a large variety of different dumps, and the latter (i think) pretty much anything. i have wondered whether the others can't mostly be written in terms of hexdump. (xxd still has all the reverse stuff, but as long as no-one else does, that's not duplication.) > *shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in the > meantime... > yeah, like you say, these are some of the simplest commands anyway. i'd be a lot more worried if we had four seds or four shells :-) > > Rob > > > > P.S. In THEORY the chmod +x bit on tests/*.test is the equivalent of > "pending", > > where "make tests" only runs the ones marked executable but you can > still run > > them individually/standalone with "make test_commandname". In > practice, the > > pending status of commands and the pending status of TESTS isn't a > 1-1 match up. > > Yes I saw your email in the other thread about pending not being granular > enough, but didn't really have anything coherent to say in response? I see > pending as an unfinished todo heap I need to drain, and I feel bad for not > cleaning it up fast enough. Doing non-cleaning work there is like > organizing > trash piles. Attempting to categorize the bulk wasn't an unambiguous win > even > for toys/ which is _intended_ to keep growing rather than shrink, so > adding it > to pending doesn't appeal. I don't really want spend architectural design > cycles > on scaffolding that gets torn down again. > indeed. i think the only half-way practical idea i had was "keep pending but just switch to a much scarier name". because, to be fair to the confused, in english "pending" _can_ legitimately mean "almost there". whereas your whole point with pending is "i actually have _no_ idea how close
Re: [Toybox] hexdump tests.
On 3/15/24 09:58, enh wrote: > On Thu, Mar 14, 2024 at 9:25 PM Rob Landley wrote: > > I could make ours do that, or I could export NOSPACE=1 at the start o the > > test > > (since each one runs as a child process now meaning environment variable > > assignments won't persist into other tests) > > or have a NOSPACE that _doesn't_ reset? NOSPACE already doesn't reset, I've been doing shell prefix assignment to set it for individual commands, ala: $ NOSPACE=1 bash -c 'env | grep NOSPACE' NOSPACE=1 $ echo -n $NOSPACE $ If I just NOSPACE=1 on its own line it should apply to all the tests in the current script, then clean up at the end because each test script runs as a (child process) with its own environment. And that's probably correct here because diff -b ignores changes in the AMOUNT of space but not the EXISTENCE of space, so "a b c" and "abc" still wouldn't match, which is what I was worried about. (I thought -b yanks space, but instead it normalizes it.) > i feel like most of the tools that > produce human-readable output have this problem otherwise: (a) upstream often > has a weird duplicative implementation that leads to bizarre behavior and (b) > they keep changing things (possibly without even noticing, since it's > whitespace). Sure, but that said some tests _DO_ care about the exact amount of whitespace (are columns aligned), or tabs vs spaces. > (xxd, which has the `-r` option, seems like the partial exception, but even > there as long as xxd can consume any [text] input it's likely to be given, i > don't think it matters exactly what the text output's whitespace looks like?) > > > but that weakens the test, or maybe > I could add a "NOTRAIL=1" that runs the output through sed 's/[ \t]*$//' > or some > such? > > Anyway, reviewing commands to promote them out of pending is a thing, and > I'm > trying close tabs rather than open more just now. > > (i didn't even realize there was a hexdump in pending! missed that somehow...) It mostly comes up when I complain we've got FOUR hex dumpers that share no code (it's the fourth, you added the third with xxd, posix od and my hexedit were the first two), but the recent revisit tipped me over into "alright, I'll clean it up..." The problem is "dump hex" isn't a big enough job that pulling it out into a library function that can be shared is really a win. It's another one of those "the fighting is so vicious because the stakes are so small" things. Maybe if I could genericize the "show hex in 4 digit groups, now do octal!" variants into some sort of engine... but I worry that the glue to call the engine would be bigger than any savings. *shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in the meantime... > Rob > > P.S. In THEORY the chmod +x bit on tests/*.test is the equivalent of > "pending", > where "make tests" only runs the ones marked executable but you can still > run > them individually/standalone with "make test_commandname". In practice, > the > pending status of commands and the pending status of TESTS isn't a 1-1 > match up. Yes I saw your email in the other thread about pending not being granular enough, but didn't really have anything coherent to say in response? I see pending as an unfinished todo heap I need to drain, and I feel bad for not cleaning it up fast enough. Doing non-cleaning work there is like organizing trash piles. Attempting to categorize the bulk wasn't an unambiguous win even for toys/ which is _intended_ to keep growing rather than shrink, so adding it to pending doesn't appeal. I don't really want spend architectural design cycles on scaffolding that gets torn down again. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] hexdump tests.
On Thu, Mar 14, 2024 at 9:25 PM Rob Landley wrote: > Following up on commit cab0b6653827, the hexdump test suite is weird. For > example, the first test has "simple\\n" when it means "simple\n" (which > nevertheless somehow works for reasons I am loathe to examine at the > moment, and > I have a todo item to convert the various test arguments needing escapes to > $'blah\n' arguments where the shell does it instead of washing it through > echo > inside the function, but that is a giant flag day change for some point > where > I'm facing a clean tree.) > > But the bigger problem is that TEST_HOST doesn't pass because debian's > hexdump > is doing something silly: > > $ echo -e 'simple\n' | hexdump | sed 's/$/./' > 000 6973 706d 656c 0a0a. > 008. > > I.E. padding short lines with trailing spaces, because of course. > > I could make ours do that, or I could export NOSPACE=1 at the start o the > test > (since each one runs as a child process now meaning environment variable > assignments won't persist into other tests) or have a NOSPACE that _doesn't_ reset? i feel like most of the tools that produce human-readable output have this problem otherwise: (a) upstream often has a weird duplicative implementation that leads to bizarre behavior and (b) they keep changing things (possibly without even noticing, since it's whitespace). (xxd, which has the `-r` option, seems like the partial exception, but even there as long as xxd can consume any [text] input it's likely to be given, i don't think it matters exactly what the text output's whitespace looks like?) > but that weakens the test, or maybe > I could add a "NOTRAIL=1" that runs the output through sed 's/[ \t]*$//' > or some > such? > > Anyway, reviewing commands to promote them out of pending is a thing, and > I'm > trying close tabs rather than open more just now. > (i didn't even realize there was a hexdump in pending! missed that somehow...) > Rob > > P.S. In THEORY the chmod +x bit on tests/*.test is the equivalent of > "pending", > where "make tests" only runs the ones marked executable but you can still > run > them individually/standalone with "make test_commandname". In practice, the > pending status of commands and the pending status of TESTS isn't a 1-1 > match up. > ___ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net > ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
