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/Linux
Congratulations! > I hope this is really my last release in an unsigned long long time[1]. I've already found a typo. 😅 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. > 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'. :P I 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. > - 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. > - 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 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. 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 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 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 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.
signature.asc
Description: PGP signature
