Re: Happy new Sun (was: man-pages-6.02 released)

[Alejandro Colomar]

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