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
