Date: Mon, 25 Aug 2025 21:37:03 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: "Isaac (.ike) Levy" <ike@blackskyresearch.net> Cc: Anthony Pankov <anthony.pankov@yahoo.com>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, Poul-Henning Kamp <phk@phk.freebsd.dk>, David Chisnall <theraven@FreeBSD.org>, hackers@freebsd.org Subject: CBOR (Was: My experiences with Rust) Message-ID: <20250825213703.0570107f@nuclight.lan> In-Reply-To: <EFD5963A-347F-4DCB-9EAB-34A43AD59764@blackskyresearch.net> References: <aKiWZ1I3pqZSOsfk@kib.kiev.ua> <202508221712.57MHCPDl008201@critter.freebsd.dk> <E04D6E14-8EA1-446B-8C9C-762C9956F6D5@FreeBSD.org> <20250822214848.25569826@nuclight.lan> <202508221937.57MJbBtK008806@critter.freebsd.dk> <20250823002942.305119b2@nuclight.lan> <202508222133.57MLXtAA009189@critter.freebsd.dk> <20250823073225.ecf498cc3e7a6dcb68ccc3c8@dec.sakura.ne.jp> <1614139543.20250823141311@yahoo.com> <A56F576C-6748-47E1-91AA-8A33D20DFD19@blackskyresearch.net> <277027377.20250825132929@yahoo.com> <EFD5963A-347F-4DCB-9EAB-34A43AD59764@blackskyresearch.net>
index | next in thread | previous in thread | raw e-mail
On Mon, 25 Aug 2025 09:03:51 -0400 "Isaac (.ike) Levy" <ike@blackskyresearch.net> wrote: > If your parser pipeline has an absolute need to not miss things like "fatal: > dropping all", one could simply look for the string "drop" not "dropped", > > Given this output, > > -- > foo dropped 1/2 foo > bar sortof double! dropped bar > baz dropped 2/2 baz > fatal: dropping all > bang sortof last bang > -- > > $ myprogram | grep drop > foo dropped 1/2 foo > bar sortof double! dropped bar > baz dropped 2/2 baz > fatal: dropping all > $ > > Caught it! > > > Now, if the original program doesn't give enough output, (messages like > "fatal: dropping all"), that could be worth investigating in the upstream > program. > > Next steps? > Putting on my sysadmin hat, as a user, I may investigate/replicate the > event, perhaps read the man page, read the source code, and try to > understand why this is happening. Perhaps the program doing something > performance constrained and can't possibly output more? Perhaps the program > simply being lazy in output, perhaps begging for improvement? Is this output > a wrapper shell/other buffer issue, not even the program at all? Is this > case something which happens so rarely, and is so expensive to improve- or > so difficult to maintain long-term, that it's cleaner to just anticipate the > output? > > If the output is not in my power to change, yet my need still exists to > catch it reliably, we all have an infinitude of tools and languages to solve > output structure problems to satisfaction. > > Again, in any sufficiently complex system, ideal coordination between > systems and subsystems is not possible. Good software starts with trusting > programs to do what they say they'll do, great software starts with a > healthy mistrust programs will fail, and anticipating common failures which > affect the important parts of your using them. > > -- > One last thought back to PHK's original point: > > If the output is in CBOR format, the entire problem above still exists, but > now *requires* specific programs to read and understand, before a user or > program can begin to understand it. It's not harder than adding "| bunzip2" to you pipeline, and then understanding structured output is much simpler than yours > bar sortof double! > dropped bar > baz dropped 2/2 baz ..which is yet something not understandable == still to be translated to JSON by you. -- WBR, @nuclighthelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250825213703.0570107f>