[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Happy new Sun (was: man-pages-6.02 released)
From: |
G. Branden Robinson |
Subject: |
Re: Happy new Sun (was: man-pages-6.02 released) |
Date: |
Thu, 22 Dec 2022 15:57:52 -0600 |
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
- man-pages-6.02 released, Alejandro Colomar, 2022/12/22
- Happy new Sun (was: man-pages-6.02 released), Alejandro Colomar, 2022/12/22
- Re: Happy new Sun (was: man-pages-6.02 released),
G. Branden Robinson <=
- Re: Happy new Sun (was: man-pages-6.02 released), Deri, 2022/12/23
- Re: Happy new Sun (was: man-pages-6.02 released), Alejandro Colomar, 2022/12/23
- Re: Happy new Sun (was: man-pages-6.02 released), Nate Bargmann, 2022/12/23
- Re: Happy new Sun (was: man-pages-6.02 released), Deri, 2022/12/23
- Re: Viewing PDFs. (Was: Happy new Sun), Ralph Corderoy, 2022/12/24
- Re: Viewing PDFs. (Was: Happy new Sun), Steffen Nurpmeso, 2022/12/24
- Re: Viewing PDFs. (Was: Happy new Sun), Deri, 2022/12/24
- Re: Viewing PDFs. (Was: Happy new Sun), G. Branden Robinson, 2022/12/27