[bug #24048] [mm] infinite loop with certain page lengths

[G. Branden Robinson]

Follow-up Comment #8, bug #24048 (project groff):

I don't find comment #7 helpful to this discussion.

[comment #7 comment #7:]
>   I find these page length tests unnecessary

The above is the most useful part of the response.

> 1) The page length is a constant.

Not necessarily.  Some real-world documents change the media size _in medias
res_, if you will.  Probably the most common example is a change of
orientation (portrait<->landscape); while one can argue whether this changes
the "size" of the output medium, it certainly changes the page length to a
*roff formatter.

> 2) The error of a wrong page length is immediately visible.

But it may not be immediately _comprehensible_.  Our users are sometimes
impatient folk.

> 3) The test deprives the users of an experience.

This is one of the worst counterarguments.

Only an immortal being can crave all possible experiences.
 
> 4) The test sabotages experimentation.

Any experimenter worth their salt should be able to disable the check in the
macro package source, or they can come to the groff@ mailing list or other
forum and ask for expert help doing it.

> 5) The test sabotages evolution from a typewriter situation to a high
> resolution output devices.

How so?  The page length is not forced to a coarse, discretized value (not
more coarse than the output device can support, anyway).  All that is
happening is a comparison of magnitudes.  Your page length can be 0 basic
units larger than the minimum required size, or 1, or 14,596.

> 6) The test is executed every time the macro is run, although errors
> have been corrected.

This is worth consideration if the test proves expensive relative to the rest
of processing.  Have you profiled it?

Do you have an argument from complexity analysis?  The check runs once per
page header, so once per page, and contains no loop.  It is therefore O(n) in
the number of pages.

Linear contributors to time or space consumption are not often the wisest
place to start attacking performance problems.

> 7) Not economical.

What does this mean?  Does it say anything you're not already communicating in
point 6?

> 8) It cements status quo.

How?  Here's the implementation from groff me(7), in Git HEAD.


.de @h                  \" --- header
.if \n@>1 .tm >> @h %=\\n% ?a=\\n(?a ?b=\\n(?b ?w=\\n(?w
.do if (u;\\n(tm+\\n(bm+\\n(.V>\\n(.p) \{\
.       do @err insufficient page length; aborting
.       pl \\n(nlu
.       ab
.\}


You can see that the page length (register `.p`) is being compared not to a
fixed value, but to the current vertical spacing `.V` (roughly, "line
height"), and to the user-configurable top and bottom margins (`tm` and `bm`
respectively).

_All_ of these parameters are configurable in various ways.  The only numeric
literal we see is used for emitting debugging output.

In summary, what are on earth are you talking about?

> 9) Is not based on cost analysis.

What cost do you claim to be measuring?  Are you responsible for paying it? 
This is a volunteer project.

> 10) Is not based on examination of all consequences.

Outside of solved games[1], what decision is?

This sort of argumentation is not persuasive.  Try a different tack.

Regards,
Branden

[1] https://en.wikipedia.org/wiki/Solved_game

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?24048>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/