Re: sys-apps/groff-1.23.0: explicitly disable compatibility wrappers

[G. Branden Robinson]

Hi Fabian,

I saw the following in a commit[1] of yours.

"On Prefix systems, compatibility wrappers are generated because the
default action is "auto".  These wrappers, however, do not function
well on certain systems (Illumnos for instance), but from tests it
appears they are not necessary either, so just disable them
unconditionally."

Can you elaborate on this?  What is the failure mode?  When preparing
the groff 1.23.0, I don't recall that we had anyone testing its
portability to Illumos.

Perhaps we can get that working better for the next release.

Regards,
Branden

[1] 
https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/groff?id=552ad970da3fe2492239f88e84bedec2dc666478


signature.asc
Description: PGP signature

Proposed GNU troff behavior change: require end-of-input macros to exit

[Douglas McIlroy]

> For historical reasons (and for compatibility with AT&T 'troff'),
> the end macro exits as soon as it causes a page break and
> no remaining data is in the partially collected line.

This isn't the only anomalous behavior at the end of a
document. Since day one, troff has occasionally emitted
a blank page at the end. I believe this is because a
new page is triggered when the previous page is filled
rather than when some output needs somewhere to
go. A document that exactly fills the last page thus
gets an extra page.

Before jumping for a special fix for .em, you might like
to consider the more general question of how a page
gets initiated and/or when a trap gets sprung (upon
reaching it or upon passing it?). Then .em might not
need so much special pleading.

In regard to the narrow issue of .em, what alternate
fixes have you considered? For example, instead of
exiting, .em might be required to do .rm em. Or the
removal could be done automatically when .em is
invoked. Under either regime, a user could even
arrange for .em to be reinstated to accomplish a
second coming--er, ending.

Doug

Re: sys-apps/groff-1.23.0: explicitly disable compatibility wrappers

[Fabian Groffen]

Hi,

On Illumnos, with 1.23.0 default configure, if I do this:

% bzcat /gentoo/prefix64/usr/share/man/man3p/snprintf.3p.bz2 | ( cd 
/gentoo/prefix64/usr/share/man && /gentoo/prefix64/usr/libexec/man-db/zsoelim ) 
| ( cd /gentoo/prefix64/usr/share/man && preconv -e UTF-8 ) | ( cd 
/gentoo/prefix64/usr/share/man && tbl ) | ( cd /gentoo/prefix64/usr/share/man 
&& neqn -Tutf8 ) | ( cd /gentoo/prefix64/usr/share/man && nroff -mandoc -c 
-rLL=78n -rLT=78n -Tutf8 )
troff:/gentoo/prefix64/usr/lib/groff/site-tmac/an.tmac:1: fatal error: input 
stack limit exceeded (probable infinite loop)
grotty::():10: fatal error: 'V' command invalid 
before first 'p' command

(/gentoo/prefix64 is my "prefix", an offset everything is installed into)

If I add --without-compatibility-wrappers:

SNPRINTF(3P)   POSIX Programmer’s Manual  SNPRINTF(3P)

PROLOG
   This  manual  page is part of the POSIX Programmer’s Manual.  The Linux
   implementation of this interface may differ (consult the  corresponding
   Linux  manual page for details of Linux behavior), or the interface may
   not be implemented on Linux.

NAME
...

In this case /gentoo/prefix64/usr/lib/groff/site-tmac/an.tmac is not
present.  This makes everything work fine, including manpages from the
host.

The file, when it is created, contains:

.do mso an.tmac
.cp 1
.so /usr/share/lib/tmac/an

The file it points to comes from Illumnos.  I can send its contents
off-list if necessary.

Thanks,
Fabian

On 09-12-2023 02:08:29 -0600, G. Branden Robinson wrote:
> Hi Fabian,
> 
> I saw the following in a commit[1] of yours.
> 
> "On Prefix systems, compatibility wrappers are generated because the
> default action is "auto".  These wrappers, however, do not function
> well on certain systems (Illumnos for instance), but from tests it
> appears they are not necessary either, so just disable them
> unconditionally."
> 
> Can you elaborate on this?  What is the failure mode?  When preparing
> the groff 1.23.0, I don't recall that we had anyone testing its
> portability to Illumos.
> 
> Perhaps we can get that working better for the next release.
> 
> Regards,
> Branden
> 
> [1] 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/groff?id=552ad970da3fe2492239f88e84bedec2dc666478



-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: PGP signature

Re: sys-apps/groff-1.23.0: explicitly disable compatibility wrappers

[G. Branden Robinson]

Hi Fabian,

At 2023-12-09T19:25:19+0100, Fabian Groffen wrote:
> On Illumnos, with 1.23.0 default configure, if I do this:
> 
> % bzcat /gentoo/prefix64/usr/share/man/man3p/snprintf.3p.bz2 | ( cd 
> /gentoo/prefix64/usr/share/man && /gentoo/prefix64/usr/libexec/man-db/zsoelim 
> ) | ( cd /gentoo/prefix64/usr/share/man && preconv -e UTF-8 ) | ( cd 
> /gentoo/prefix64/usr/share/man && tbl ) | ( cd /gentoo/prefix64/usr/share/man 
> && neqn -Tutf8 ) | ( cd /gentoo/prefix64/usr/share/man && nroff -mandoc -c 
> -rLL=78n -rLT=78n -Tutf8 )
> troff:/gentoo/prefix64/usr/lib/groff/site-tmac/an.tmac:1: fatal error: input 
> stack limit exceeded (probable infinite loop)
> grotty::():10: fatal error: 'V' command 
> invalid before first 'p' command
> 
> (/gentoo/prefix64 is my "prefix", an offset everything is installed into)
[reorganized]
> The file, when it is created, contains:
> 
> .do mso an.tmac
> .cp 1
> .so /usr/share/lib/tmac/an
> 
> The file it points to comes from Illumnos.  I can send its contents
> off-list if necessary.

This looks like Savannah #63924.


You might consider cherry-picking the commit mentioned there.

> In this case /gentoo/prefix64/usr/lib/groff/site-tmac/an.tmac is not
> present.  This makes everything work fine, including manpages from the
> host.

Does Illumos continue to use the AT&T troff descendant that Solaris
shipped with version 10 but (as I understand it) dropped in favor of
groff in Solaris 11?

If the latter, there is likely little or no reason to have groff install
compatibility wrappers around an older version of groff.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Updating eqn

[Dave Kemper]

On 12/7/23, Carl Milsted  wrote:
> I cloned your repo and found the bugs and fixed them on my machine. I'd
> like to know the proper procedure to send the fixes back your way. I
> have not contributed to a GNU project before.

Hi Carl,

You can open a bug report in the groff bug tracker
(https://savannah.gnu.org/bugs/?group=groff&func=additem), describing
the problem and attaching a patch.  You don't need to create an
account to submit a bug, but creating one lets the system email you
with updates or questions.

Alternately, you can post a patch to this email list.  But the bug
tracker is generally the better option, in case no developer has the
bandwidth to handle it right away: a mailing list post might get
forgotten, while a bug report will remain open until resolved in some
way.

Thanks for finding and fixing some eqn bugs!

Re: Proposed GNU troff behavior change: require end-of-input macros to exit

[G. Branden Robinson]

Hi Doug,

At 2023-12-09T09:26:16-0500, Douglas McIlroy wrote:
> > For historical reasons (and for compatibility with AT&T 'troff'),
> > the end macro exits as soon as it causes a page break and
> > no remaining data is in the partially collected line.
> 
> This isn't the only anomalous behavior at the end of a document. Since
> day one, troff has occasionally emitted a blank page at the end. I
> believe this is because a new page is triggered when the previous page
> is filled rather than when some output needs somewhere to go. A
> document that exactly fills the last page thus gets an extra page.

Right.  When a line of output is "finished" and sent to the device
(device-independent output is prepared for it), the vertical position
advances by one vee, and, (in groff, if vertical position traps are not
disabled,) any visible vertical position traps planted between the
previous text baseline and the new one are sprung.[1]  If one of these
traps is what I term "the implicit page trap"[2], then the page is
ejected and a new one started.

Here is how I try to present this information in our Texinfo manual and
roff(7).

 Vertical spacing has an impact on page‐breaking decisions.
 Generally, when a break occurs, the formatter moves the drawing
 position to the next text baseline automatically.  If the formatter
 were already writing to the last line that would fit on the page,
 advancing by one vee would place the next text baseline off the
 page.  Rather than let that happen, roff formatters instruct the
 output driver to eject the page, start a new one, and again set the
 drawing position to one vee below the page top; this is a page
 break.

 When the last line of input text corresponds to the last output
 line that fits on the page, the break caused by the end of input
 will also break the page, producing a useless blank one.  Macro
 packages keep users from having to confront this difficulty by
 setting “traps”; moreover, all but the simplest page layouts tend
 to have headers and footers, or at least bear vertical margins
 larger than one vee.

Of itself, I don't think this procedure is closely coupled with
end-of-input macro handling.

> Before jumping for a special fix for .em, you might like to consider
> the more general question of how a page gets initiated and/or when a
> trap gets sprung (upon reaching it or upon passing it?).

I've been trying to, and I haven't come up with any other ideas, hence
mooting it on the list.  :)

> Then .em
> might not need so much special pleading.
> 
> In regard to the narrow issue of .em, what alternate
> fixes have you considered? For example, instead of
> exiting, .em might be required to do .rm em.

You mean that we might require the macro called by the `em` request to
delete the `em` request itself (or whatever the user renamed it to)?

> Or the removal could be done automatically when .em is invoked. Under
> either regime, a user could even arrange for .em to be reinstated to
> accomplish a second coming--er, ending.

It seems like this would imply looping on "if end-of-input macro
defined" at the end of input.  That seems similar to my proposal; either
one could lead to groff "hanging" (blocking while trying to read from
stdin) if the user doesn't follow the rules.

One of the reasons my proposal has the shape it does is because it is so
hard to explain.

[groff.texi from Git HEAD]

--snip--
   (1) While processing an end-of-input macro, the formatter assumes
that the next page break must be the last; it goes into "sudden death
overtime".
--end snip--

Any time I have to resort to a sports metaphor (and possibly a
U.S.-centric one at that) to explain a technical point, I treat that as
an indicator either that I'm being too whimsical or that the system in
question is too baroque.

Regards,
Branden

[1] With mysterious exceptions that seem to be widely shared among
*roffs.  In a nutshell, implementations seem to assume that only one
vertical position between the current and next baselines will have
traps planted.  This is not the same thing as having one trap hide
others at the _same_ vertical position, nor the same thing as
vertical position traps not being able to be sprung while a
trap-called macro is being interpreted.

https://savannah.gnu.org/bugs/?56499

[2] 
https://www.gnu.org/software/groff/manual/groff.html.node/The-Implicit-Page-Trap.html


signature.asc
Description: PGP signature