[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Happy new Sun (was: man-pages-6.02 released)
From: |
Alejandro Colomar |
Subject: |
Re: Happy new Sun (was: man-pages-6.02 released) |
Date: |
Fri, 23 Dec 2022 01:03:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 |
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/Linux
Congratulations!
:-}
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'. :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.
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
- 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, 2022/12/22
- 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
- Re: Viewing PDFs. (Was: Happy new Sun), Steffen Nurpmeso, 2022/12/27