Hi Branden, On 12/20/22 04:40, G. Branden Robinson wrote:
At 2022-12-19T20:10:25+0100, Alejandro Colomar wrote:On 12/19/22 17:59, G. Branden Robinson wrote:[dropping Deri and groff@] At 2022-12-19T17:39:37+0100, Alejandro Colomar wrote:Would you mind sending a patch that I can apply with git? I could manually edit the file you attached, but I'm feeling lazy for that :\Damn. Our lazinesses are duelling. :P:P I actually wonder how producing such a diff was simpler than just copying the output of git diff...I don't find "diff -u <tab-completion>{,.new}" very difficult. (I often do that in repos that I mostly read as opposed to contributing to; that way my half-baked ideas don't get in the way of a rebase pull. Branching doesn't solve that problem, and if I git-stash something in such a repo I'm likely to forget about it, or not think to check there.)
Hmmm, can make sense. (I branch for such occasions.) (stash && rebase-pull && stash-pop is also common, but that's for repos in which I work more often and don't have to pull tons of changes.) :)
BTW, I still plan releasing man-pages-6.02 in a two days, and feel confident enough about the string changes (modulo a few tweaks that I'll apply) to ship them in it. If you have any comments about them, please voice them :)I have weak preference for the name "string_copying(7)" over "string_copy(7)", but leaving the summary-description the same.
I prefer it too. string_copy was for when this page was going to substitute the other ones, so I wanted it to have a name resembling them. But now I like "copying" more. So, done, and pushed. A new page is born.
Apart from that I have no comments, apart from encouraging you in your effort to reform common practice to something less sloppy.
Thanks :)
I think you will get pushback from people who (1) don't appreciate how horrible the C string library is, in part because they have mazed themselves with the notion that the engineers at the Bell Labs CSRC were all infallible giants who deigned to walk among us mortals for a while; and (2) would rather wait until some total replacement solution comes along, which of course they would oppose with at least much passion. Nevertheless, once in a while they'll make good points. Take that opportunity to anneal the quality of your initiative. The standard I/O library is a disaster, too. Much more esteemed people than I have made this point, such as Korn and Vo, who presented their case at USENIX in 1991.[1] Of course, they did the smart thing back then and didn't FLOSS-license it, possibly under direction from AT&T management. Thanks to that shrewd advice, sfio.h stormed to success and ubiquity instead of being nearly forgotten.
That's why I went for public domain for the APIs and basic implementations, and BSD-3-Clause for the string_copying(7) page. I'd like it to be as widespread as possible.
However, my own library implementation is LGPL-3.0-or-later, as couldn't be otherwise.
But even a permissive license may well have not been enough. The average programmer will happily drink from a pool of dioxin as long as it is a familiar one. >was David Wheeler (no, the other one)Didn't know of the other David Wheeler.Well, David J. Wheeler (computer scientist) passed away in 2004, so possibly David A. Wheeler (computer scientist) gets mistaken for him less often now. I've been making this joke for years. It hasn't worked once. Like the average programmer, I learn nothing from this.According to wikipedia, pkg-config(1)'s initial release is also from 2000. So, yes, probably it wasn't widely known at the time.It was an innocent time, when packaging was still young and exciting,
I need to learn packaging some day. I should learn Debian packaging to package this new library...
and before JavaScript people getting paid a lot to work in e-commerce decided they could do it better than everyone else. Regards, Branden [1] https://www.cs.princeton.edu/courses/archive/fall97/cs595/sfio.ps
Cheers, Alex -- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
