[Toybox] Github thingy #408.

[enh]

On Tue, Jan 31, 2023 at 9:11 PM Rob Landley <rob at landley.net> wrote:
>
> Replying to https://github.com/landley/toybox/issues/408#issuecomment-1410711619
> here instead of the list because design discussions in github issues comments
> tend to get lost (or at least I can't easily find 'em again 6 months later):
>
> Patch applied. Note I'm unlikely to catch regressions introduced into pending,
> at least not in patches from you to pending, or from the person who wrote a
> thing that's in pending. Those get applied without much (if any) review because
> I tend to get sucked into long tangents far too easily otherwise. (The point of
> pending is it all gets a properly thorough review later, and well-meaning
> patches from known actors are unlikely to make it measurably worse in the meantime.)

this is about vi? yeah, part of me regrets enabling that, but it is by
far the most requested toy. mksh is good enough as a shell (and, as
i've said, almost all the complaints there are about the interactive
side of things --- "can you improve the line editing?"), but cat is
not much of an editor. that's part of why i'd like to just have either
a simple gap buffer or a trivial block with the gap always at the end.
it's way easier to reason about/hack on, and thus much more amenable
to drive-by improvements (which i fear is all that vi's likely to get
any time soon).

it's particularly sad to me that toybox vi is the same number of lines
of code as fuzix's "vile", but has less functionality and more bugs.
but it seemed like you were also attached to the "but what if i need
to edit 16GiB files on systems with large address space but small
ram?!" that got us to this YAGNI implementation in the first place?

> Pretty much everything that's left in pending is its own nontrivial project to
> properly clean up and promote, or I'd have done it by now, and I don't want to
> mess with them much until I can set aside appropriate blocks of time/energy to
> FINISH them.
>
> Some aren't _big_ projects: telnet/tenetd I want to test interoperability with
> other server/clients. For tftp/tftpd I also one to test at least one real user
> like qemu's netboot, except the IBM mainframe "enterprise" clowns who hijacked
> the project and drove off Fabrice Bellard back when KVM became a thing replaced
> the simple "-bootp" command line option (http://etherboot.org/wiki/qemu) with
> some procedure involving feeding json into virtfs
> (https://www.kraxel.org/blog/2021/09/vm-network-boot/) and I need to build a
> sufficiently old qemu version that it's NOT CRAZY to test this.

(i think both telnet and tftp are sufficiently niche these days that
"implements the absolute basics" is enough. i haven't heard any
complaints from the [niche!] users i'm aware of since you last saw
patches.)

> Some are design issues: tcpsvd doesn't share code with netcat and isn't inetd,
> it's an otherwise obscure UI that Denys Vlasenko was fond of so added to
> busybox, which got copied from there.
>
> Some are just "I've never used bootchartd and need to figure out how to tell
> what success looks like."
>
> In the case of useradd and friends, the project is the lib/password.c rewrite
> and the _blocker_ is making test infrastructure to properly regression test it
> in a known environment it can trash, although I suppose I _could_ test it in a
> deboostrap chroot before mkroot's ready? Hmmm...
>
> Anyway, feel free to close this issue if it's working for you, lemme know what
> to fix next if not...

(closed anyway on the basis of "that was a feature request, feature
now implemented, anything else is bug reports, and i'll send those to
the list".)

> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net