Re: removing the .IX macro from the ms package in 1.23 breaks old documents

[G. Branden Robinson]

At 2024-10-02T13:29:28-0500, G. Branden Robinson wrote:
> [follow-ups set to groff@gnu, a discussion list]

One point I forgot to mention...

> At 2024-10-02T18:12:06+0200, joerg van den hoff wrote:
> > I was not aware of this change (not following groff development
> > closely) and it took me quite a bit of time today to find the root
> > course of why some newly compiled old documents of mine do not
> > contain an index any more.

I infer from this account that you built this document without the groff
options `-wall` or `-ww`.  I strongly urge you to do so, as does our
documentation.

troff(1):

     Two warning names group other warning categories for convenience.

     all    All warning categories except di, mac, and reg.  This
            shorthand is intended to produce all warnings that are
            useful with macro packages and documents written for AT&T
            troff and its descendants, which have less fastidious
            diagnostics than GNU troff.[1]

     w      All warning categories.  Authors of documents and macro
            packages targeting groff are encouraged to use this setting.

If you had either of these enabled, or even just `-wmac`, you would have
received a diagnostic during the build complaining of `IX` being
undefined, which should have alerted you to the root cause of the issue.

To the best of my knowledge, with one exception, all of the macro
packages groff ships are "`-ww`-clean", meaning that they are free of
warnings.

The exception is mom(7), which is "merely" -wall-clean.

I beseech all groff users to specify the `-ww` or `-wall` option to
groff for _any_ usage scenario except possibly the rendering of legacy
documents that expected AT&T troff as the formatter and can't be
changed.  (Fixing a warning never forces you to adopt a GNU extension to
troff.)  I can attest from extensive personal experience that these
warnings truly do help in tracking down problems.

You may also find the `-b` option useful--it generates backtraces upon
warnings or errors from the formatter.

Regards,
Branden

[1] Or almost none at all.  My suspicion is that, as with Ritchie's C
    compiler, input validation and other sanity checks were regarded as
    as a luxury, or as wasteful of core that should have been conceded
    to other user processes.  Ritchie and McIlroy have told the tales:

    "After the TMG version of B was working, Thompson rewrote B in
    itself (a bootstrapping step). During development, he continually
    struggled against memory limitations: each language addition
    inflated the compiler so it could barely fit, but each rewrite
    taking advantage of the feature reduced its size."[2]

    "Conversion to C made UNIX, already elegant and capable, into a
    system also intelligible, pliable, and ultimately portable. It
    elicited a flood of utilities and made it easier to refine the
    kernel. As the compiler evolved, the system benefited too: better
    object code meant speedups and space savings across the board.  More
    than once an overgrown kernel was squeezed back into place by
    attending to the compiler."[3]

    While I know of no testimonials on point regarding AT&T troff's
    size, it was comparable to that of compilers for other programming
    languages in Seventh Edition Unix.  The C compiler's 3 passes were
    24 KiB, 35 KiB, and 12 KiB, respectively; "f77pass1" was
    82 KiB(!)[4]; and troff was 42 KiB.

    Interestingly (to me), the BASIC compiler `bas` was a mere 7 KiB.
    The Bell Labs CSRC seemed to view that language with a neutrality or
    even acceptance that is surprising in the hindsight of younger
    generations, who innovated a prejudice of their own by
    characterizing BASIC as so horrible that it forever corrupted the
    mind and retarded the programming ability of the practitioner--in
    _any_ language.  Supposedly this was due to its unstructured nature;
    but Pascal was structured to a fault (down to the ordering of
    declarations), and they hated it, too.  Perhaps the most noteworthy
    feature of early Unix advocates was how much seething hatred they
    had, and for how many different things.  For further specimens of
    half-informed bias trumpeting itself as discerning judgment, peruse
    Eric S. Raymond's "New Hacker Dictionary", a.k.a. "Jargon File".
    (On further consideration, anything by Raymond suits this purpose.)

[2] Ritchie, D. M.; "The Development of the C Language"
    https://www.bell-labs.com/usr/dmr/www/chist.html

[3] McIlroy, M. D.; "A Research Unix Reader: Annotated Excerpts from the
    Programmer's Manual: 1971-1986"

[4] I exclaim because that's bigger than the original address space of
    the PDP-11.  'Some models, beginning with the PDP-11/45, can be set
    to use 32K words (64 KB) as the "instruction space" for program code
    and a separate 32K words of "data space". Some operating
    systems—notably Unix since edition V7, and RSX11-M+—rely on this
    feature.' (Wikipedia)

    If I knew how to dump a V7 object file (and/or interpret the dump)
    I'd see how much of that is "text" versus "data".

    Oh wait.  I do know.  It's a command no one runs anymore but that
    continues to occupy prime name space real estate.

    $ size /lib/f77pass1
    62592+19846+13542 = 95980b = 0273354b

    The output is not self-describing, so we turn to the man page.

    DESCRIPTION
         Size prints the (decimal) number of bytes required by the
         text, data, and bss portions, and their sum in octal and
         decimal, of each object-file argument.  If no file is speci-
         fied, a.out is used.

    Wow.  Talk about kissin' the limit.  No wonder there was such
    antipathy for Fortran in early Unix culture (and which lingered
    because we more diligently copy the prejudices of our fathers than
    their wisdom).  Any jerk building a Fortran project on the
    time-sharing host you were on was going to swap your ass OUT.  (My
    understanding is that the V7 kernel didn't support demand paging--
    that was a feature of the much-touted "vmunix" kernel developed by
    Berkeley.  When a process vacated core memory, it did so
    _completely_.)

signature.asc
Description: PGP signature