Hi Branden, On 12/22/22 22:57, G. Branden Robinson wrote:
Hi Alex,At 2022-12-22T21:12:39+0100, Alejandro Colomar wrote:On 12/22/22 20:39, Alejandro Colomar wrote:Gidday! I'm proud to announce: man-pages-6.02 - manual pages for GNU/LinuxCongratulations!
:-}
I hope this is really my last release in an unsigned long long time[1].I've already found a typo. 😅
Fixed. :D
I also think some further revisions to the string copying discussion and related pages are warranted. Nothing critical, but if you really want to start steering hordes of C programmers whose currency is the Dunning-Krugerrand down new cattle runs, I think you'll need additional material.
Yeah, that might be one of the main reasons to release again in the near future.
You can take it as a Christmas present :) Now, I'm officially waiting for groff-1.23 to be released to declare it as a dependency. Deri sent me a present for Christmas, and it would be a much smaller and better present if groff 1.23 was out... just sayin'. :PI hear you. I got a present myself this week--a case of coronavirus (my first). I will likely push before Christmas Day but I don't expect to squawk to Bertrand to roll the 1.23.0.rc2 archive by then, for the reasons related in my status report. Fortunately my case of COVID is mild and I have nearly recovered. It knocked me off my stride for macro programming but I kept on with corrections to documentation.
BTW, maybe it's me that I don't care too much about having a perfect groff_mdoc(7)... But if the remaining bugs you mentioned earlier this week are not regressions, and don't seem grave either, I'd consider declaring them non-RC, and releasing already. I'm fearing the freeze is too close already.
- Don't release for 2 years or so, until a few months before the freeze for Debian trixie.If it were me I could not see committing to this. The longer I spend in a long dev cycle the more I dislike it (even if I'm my own worst enemy on judging a code base ready for release). For groff I want to move to something like a 6-month cycle.
I have no preference. I wanted to try a slow pace for reducing load on packagers, but I know I'll get impatient on some changes being read by the public, as there will be important changes... So I probably won't wait that much. :p
But overall I liked the entire year that we didn't release, or even didn't update the official repo (except for having to repeatedly explain people why I couldn't release). It proved how FOSS development doesn't pertain to an organization, but to the developers themselves. And I'd like to be able to repeat it, even if there may be seasons where I release often, there may be others where I don't release at all, if I don't have anything important.
So, I think a reasonable thing to say is that I'll release at least once every two years, and also anytime I have something worthy of a release.
- Migrate to MR macros after groff-1.23 is in Debian.[2] - Provide a PDF book of the Linux man-pages (actually, Deri did this; I'll just help polish it).I think these will constitute significant improvements in the everyday user's man page experience. We'll see if I'm right.[2] We know that the plan of not releasing, so in case I have to release, having sufficient groff in Debian should be enough. Other releases either move faster, so they'll also have it, or they should read the list of dependencies and/or the release notes before upgrading. Something important like the string issue might make me release again with some completely rewritten pages for who-knows-what...I recently put an-ext.tmac on a diet,[1] so people/distributions can always grab the simplified `MR` definition from there[2] and stuff it into .../groff/man.local to avoid problems. I would counsel you to expect the unexpected.- Rewritten pages for string-copying functions. These now use consistent language. Also added a new string_copying(7) page that serves as an overview of all such functions, compares them, and details which is appropriate for which uses.One of the things I noticed is that the `TH` and the file name fell out of sync on this one.- Use _Nullable for documenting which functions accept NULL as a meaningful value in the function prototypes in the SYNOPSIS.At long last! :D
I hope this serves to incite Clang developers to actually use _Nullable for something good. It's almost ignored by the compiler.
https://www.adacore.com/gems/ada-gem-23 Two of the changes I'd make to Ada are: 1) Make variables read-only by default. This sounds crazy to old fogeys who haven't done multi-thread or multi-core programming. Rust has "let mut" for a reason. Any piece of storage may have many readers XOR one writer. 2) Make access types (pointers) refuse null assignments by default. So, require "nullable" much like what you've documented above for objects that contain null references rather than requiring "not null" to prohibit them as Ada currently does.
I'm discussing (with some Clang developers / WG14 members) on doing (2) for a future C standard, and trying to come up with a way that backwards compatibility doesn't get in the way.
But I know why they didn't go those ways. Backward compatibility. Jean Ichbiah make a huge number of correct calls--especially for the late 1970s when C was a mad dog of a language and not even considered for the high-integrity applications Ada was--but he didn't call them _all_ right.[3] Since you have reached a milestone and want some downtime anyway, I will recommend to you the Ada 83 Rationale document: http://archive.adaic.com/standards/83rat/html/Welcome.html
Uhhh, I don't remember having read an entire book about C or Unix (I still have only read <10% of mtk's TLPI; two years after he gave it to me as a present :p I'll finish it some day, hopefully). It's unlikely that I'll find the courage to read that about Ada. However, if you point me at things that you find interesting of Ada, I can have a look at them to illustrate myself.
I wonder how I can quote the C standard so well, if I only read small paragraphs when I need them. You'd probably be surprised of how little of the man-pages I've read so far... My brain gets bored pretty fast when reading technical stuff without a good reason. I can't help it.
Which reminds me that I didn't yet fully read groff_man{,_style}(7)... At this point, I'll assume it's good enough, and maybe come back to it after 1.23, to not nerd-snipe you :)
I urge you to look past the Pascal-flavored syntax you dislike and see what other aspects of the language's design and considerations might appeal to you. > Regards, Branden [1] https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an-ext.tmac?id=59efbfc364daee11af9207a3fc79675b6f5bfc25 [2] https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an-ext.tmac?id=59efbfc364daee11af9207a3fc79675b6f5bfc25#n131 [3] While I contrast Ada and C in many respects, they have a somewhat sad similarity in that their originators each felt that the language rapidly strayed from its principles after standardization. It wasn't Ritchie's death that prevented a 3rd edition of K&R, but his objection to the directions taken by C99. Likewise, Ichbiah, who dominated the Ada 83 development committee, famously resigned from the one for Ada 95, apparently due to disagreements with fellow member (and compiler writer) S. Tucker Taft over the expression of OO concepts in the language. Even having read some of the contemporary materials I don't judge myself competent to referee that debate. I get the feeling both sides overestimated the stakes. The DoD no longer had the stones to enforce the single-language mandate that birthed Ada in the first place; momentum had shifted (to less rigorously defined languages with many fewer integrity checks at compile- _or_ run-time), and use of the keyword "class" versus describing something as a "tagged type" was not going to make the difference. Sure, people were going to grab Java or C++ and use them to program the next-generation Grumman KillBots; the former group would produce machines that would never make it to deployment because the users in the field would still be waiting for widgets to render in AWT, and the latter would abandon their contract after upgrading a minor support library and being faced with a single 16KiB compiler error having something to do with templates. One of the thing groff did right, even if not by choice, was to largely avoid the STL.[4] Weirdly, I've seen Stepanov credited with bringing generics to Ada before selling Stroustroup on them for C++. But generics were already in Ada before Stepanov got to it. While a celebrated figure, every time I read Stepanov's stuff I feel the fog thickening, not clearing. Maybe I'm just too dumb to be one of the cool kids. [4] groff uses the preprocessor to abstract types for containers in a couple of places,[5] which I don't feel is any better than using the dangerously Turing-complete template approach.[6]
I'm a bit surprised that _Generic(3) is little known, compared to C++ templates. Probably C programmers learned from C++, and avoid it, even if only for keeping compilation times low. But _Generic(3) is very powerful too. I implemented some C++ casts in C using it.
I confess I've
felt tempted to reach for a vector<> a few times. But since groff
is not itself a library and its need for generic containers has
proven limited--only a handful of types are actually used--I
think it might be a maintainability win to just make ordinary
classes specialized for the existing cases.[7]
"In programming, everything we do is a special case of something
more general -- and often we know it too quickly." -- Alan J. Perlis
guilty :p Cheers, Alex
groff even uses its own string type instead of libstd++'s. I think
one might argue that it is one of the most successful exemplars of
the early concept of C++ as "C with classes" ever undertaken.
[5] https://git.savannah.gnu.org/cgit/groff.git/tree/src/include/itable.h
https://git.savannah.gnu.org/cgit/groff.git/tree/src/include/ptable.h
[6]
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=e48b38ba086b375f506651351c256fd12eba32fd
[7] Specifically, "ITABLE" is used for only _one_ type, charinfo.
src/libs/libgroff/nametoindex.cpp: ITABLE(charinfo) ntable; // Table
mapping number to glyph.
"PTABLE" is used for several.
src/devices/grotty/tty.cpp: PTABLE(schar) tty_colors;
src/libs/libgroff/glyphuni.cpp:PTABLE(glyph_to_unicode)
glyph_to_unicode_table;
src/libs/libgroff/make-uniuni:PTABLE(unicode_decompose)
unicode_decompose_table;
src/libs/libgroff/nametoindex.cpp: PTABLE(charinfo) table; // Table
mapping name to glyph.
src/libs/libgroff/uniglyph.cpp:PTABLE(unicode_to_glyph)
unicode_to_glyph_table;
src/libs/libgroff/uniuni.cpp:PTABLE(unicode_decompose)
unicode_decompose_table;
src/preproc/eqn/lex.cpp:PTABLE(definition) macro_table;
src/preproc/eqn/text.cpp:PTABLE(char_info) special_char_table;
src/preproc/pic/lex.cpp:PTABLE(char) macro_table;
src/preproc/pic/object.cpp: PTABLE(place) *tbl;
src/utils/hpftodit/hpuni.cpp:PTABLE(hp_msl_to_unicode)
hp_msl_to_unicode_table;
I assume the STL's map<C1, C2> could be used to replace all of
these. Iterators are required for at least some; I assume that is
also straightforward.
-- <http://www.alejandro-colomar.es/>
OpenPGP_signature
Description: OpenPGP digital signature
