[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two further apparent regressions in 1.23 in s.tmac
|
From: |
joerg van den hoff |
|
Subject: |
Re: two further apparent regressions in 1.23 in s.tmac |
|
Date: |
Thu, 17 Oct 2024 02:00:21 +0200 |
|
User-agent: |
Mozilla Thunderbird |
On 16.10.24 23:12, G. Branden Robinson wrote:
[replying only to the lists, since you're not honoring the Reply-To
header anyway]
I wrote to groff-bug, I wanted (and want) to keep the response on that list. that's my decision, not
yours.
Hi Joerg,
At 2024-10-16T22:01:02+0200, joerg van den hoff wrote:
At 2024-10-16T13:30:23+0200, joerg van den hoff wrote:
I ran into this problem several months ago but did never suspect
it would be related to a preceding update to 1.23 (which happened
as part of general package update run so I did not even take note
until recently that groff on my machine is actually now at 1.23)
so this report comes a bit late.
Did you review the NEWS file or the release announcement to see if
this issue was covered there?
https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0
https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00001.html
no. I considered this an obvious bug.
I see. The views of the developers have no weight to you, even though
it is they who maintain the software.
untrue.
true: I considered it a bug (as I said): it is at least a fair hypothesis that I have encountered a
bug, if groff documents well-behaving for decades suddenly format massively wrong. this is by no
means disregard for the developers' views. I thought it a regression (still do)), I reported it. I
don't read any NEWS file at that point simply because that would be the last thing coming to my mind
in this situation: "20 years all good, suddenly formatting of same document breaks". this sure is
not a new feature proudly presented in the NEWS. or so one would think.
I had no incentive to read the NEWS in this context.
What _would_ incentivize you to read a software package's release notes?
not the encounter of a (even if only) perceived bug. I don't understand the
inner workings of groff.
I have never looked at the C++ code. I am *using* the product and I observe
changes in behaviour
that look a whole lot like "bugs", definitely are regressions as far as behaviour/formatting is
concerned. I report those findings here. and you object to that and refer me to the release notes?
well...
What is this `rt` doing without a preceding `mk`?
my understanding is that w/o mk the default is for rt to return to
page top. at least that is what it empirically has done for the last
25 years I believe.
I now double-checked: the manual seems to indicate that w/o preceding
mk, rt needs an argument (distance from page top).
Yes. I'd say "seems" is an understatement.
groff(7) [from groff Git][1]:
.rt Return (upward only) to vertical position marked by .mk
on the current page.
.rt N Return (upward only) to vertical position N (default
scaling unit v).
Here's our Texinfo manual (from 1.22.4) on the same subject:
5.22 Page Motions
=================
*Note Manipulating Spacing::, for a discussion of the main request for
vertical motion, 'sp'.
-- Request: .mk [reg]
-- Request: .rt [dist]
The request 'mk' can be used to mark a location on a page, for
movement to later. This request takes a register name as an
argument in which to store the current page location. With no
argument it stores the location in an internal register. The
results of this can be used later by the 'rt' or the 'sp' request
(or the '\v' escape).
The 'rt' request returns _upwards_ to the location marked with the
last 'mk' request. If used with an argument, return to a position
which distance from the top of the page is DIST (no previous call
to 'mk' is necessary in this case). Default scaling indicator is
'v'.
if it _really_ does the line would have to read `.rt 0'. but doing
this does not change behaviour neither for 1.22 nor for 1.23: AFAICS
the resulting pdfs are unaltered.
so apparently `.rt' w/o argument and preceding `mk' indeed is valid
and _does_ (and might prospectively be guaranteed to) return to page
top. if so, the groff manual regarding .rt/.mk should then mention
this circumstance.
groff's Texinfo manual goes on to say:
If a page break occurs between a 'mk' request and its matching 'rt'
request, the 'rt' is silently ignored.
if it _really_ does the line would have to read `.rt 0'. but doing
this does not change behaviour neither for 1.22 nor for 1.23: AFAICS
the resulting pdfs are unaltered.
so apparently `.rt' w/o argument and preceding `mk' indeed is valid
and _does_ (and might prospectively be guaranteed to) return to page
top. if so, the groff manual regarding .rt/.mk should then mention
this circumstance.
It's not "valid": it's undefined.[2] You relied on undefined behavior
but got an outcome you were happy with, and have proceeded to elevate
that behavior to the status of specification, apparently because it
satisfies your preference.
you are mistaken. read again what I actually wrote including all "ifs". I would ask you to not
insinuate motives and attitudes. this is annoying.
This is of a piece with your other observations, a point to which I
return below.
see above.
Would you please follow-up with a complete document as a reproducer?
It can still be "minimal" insofar as it reproduces the problem(s).
I do not understand. the snippet I sent can be considered "the
document". to make it compliant with currently documented behaviour
replace `.rt' by `.rt 0'.
Your snippet/document was exercising undefined behavior (or relying upon
`ms` internals to set the anonymous vertical position mark _for_ you),
so I suspected that you might have elided more from your snippet than
you intended.
read again what I wrote: I said "change the line to '.rt 0' to make it consistent
with manual".
I understand now that you are content to exercise any unspecified
formatter or macro package behavior you can identify, pour cement on it,
and decree any alteration of such unspecified behavior as a "bug".
your understanding seems decidedly limited but you are principally free to draw whatever wrong
conclusions you like about what I am content with. but I disapprove of you doing so.
On many machine architectures, in the C language, a pointer occupies the
same number of bits as an `int` variable. Clearly we can assume that
they're always equivalent; if our code works despite some tedious manual
warning us not to rely on this conclusion, we should do so anyway.
The release notes/NEWS file may be helpful here.
I do not understand. if you think the reported behaviour (the spacing
issue) and the difference to 1.22 is _not_ a bug, I would appreciate a
short hint where exactly _that_ is resolved in the 17 pages NEWS...
Okay. Here you go.
https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n426
thank you. I am a groff user, not an expert. I do not understand that paragraph. I do not see the
relevance to the encountered problem. sure my fault.
if the use of .rt from within DS/DE is "unspecified", I was not aware of it (what fraction of the
user base would have been?). it did (for decades...) the "expected", return to page top and the
absolute `.sp |xxx' moved from there. this was *deterministic and over time/releases invariant*
behaviour and intuitively "right". if it was so far unspecified/not guaranteed, then the correct
action in my view would have been to specify it as such in 1.23 to maintain backward compatibility
with real world usage rather than to "fix" it differently.
if your elaborations simply mean that the empirically observed behaviour was never guaranteed: might
be. but the implementation did it. always. if you have changed that then that is breaking backward
compatibility. which of course you can do. but ideally should not without very good reason,
considering the consequences: documents now break. for the first time in _decades_. this is _not_ a
minor issue.
if it _is_ a bug (I would definitely think it is since, again, it
breaks 25+ years of consistent groff behaviour),
How do you know? Have you run any tests with groff 1.12.1 lately?
I have formatted this special document (a letter template) with invariant relevant top section for
decades, yes. honestly, what is this about? it sure "always worked". it does not do that any longer,
let's face it.
I am not qualified to judge whether the changes causing this are justifiable (let alone desirable
for whatever reasons). my gut feeling is they are not, simply because: backward compatibility. etc
etc etc pp.
[...]I will not find it in the NEWS. I have reported it in the hope
that it is of interest to you.
I'm taking note of it as reinforcing my impression that Berkeley's
introduction of the `DD` register feature was under-specified.
I don't understand. I do just want to use groff like I have done for quite some (actually: a really
long) time. this seems to become increasingly difficult. the formatted output seems to become
incrementally a "moving target". this is highly unwelcome for all affected users.
if not so much because you think it is not a bug, too bad.
It's often difficult to please everyone simultaneously when
unspecified/undefined behavior is at issue. ISO/IEC JTC1/SC22/WG14 has
much experience in this respect.
I do not understand. regarding .rt append a zero argument (than it is "specified") but this does not
fix the broken formatting. otherwise, see above.
if you state that the introduced changes do _not_ have caused a proper regression, I take note of
that but do not agree.
the snippet I sent (replacing .rt by `.rt 0', if you prefer) seems valid troff/ms and now formats
no longer as it did (again: for decades) but the formatting is now broken. if this is not a
regression in your universe it can't be helped.
if the correct formatting for decades is "accidental" or due to relying on "unspecified" behaviour
(whatever that might be here), then it seems it would have been better to now enforce a specified
behaviour that is identical to the previously unspecified (but deterministic and invariant one)
instead of "fixing" and "specifying" it in a way that breaks backward compatibility.
thanks for looking into the issue. as said, I have reverted to 1.22
since I currently need to get some writing/formatting done and don't
have much time for further 1.23-related delays/distractions right now.
Okay.
but I trust you have tested your fix yourself...
It's possible.
surprise.
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=bc0103ddd08966578989d717f31cd1f273a9544f
Since my Carnac hat predicts that, if you follow the link, you'll read
the words "Test fails at this commit" and leap to a conclusion that I
haven't fixed the problem, here's another URL.
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7fbda04469c0581e7d6394291ca3d1c13483c3ed
No point release to groff 1.23 is anticipated. The next release is
expected to be 1.24. To get a preview of what user-visible changes
to ms are anticipated in the next release, you can consult the NEWS
file in our Git repository.
your decision. in my opinion the recently surfaced regression (the .XA
issue) alone would deserve that since otherwise it will take
substantially more time until it is officially fixed with releasing
1.24.
I hope to release 1.24 before the end of the calendar year. I have some
years of familiarity with the stable package update practices of the
Debian Project, and my inference is that the fix for the `XA` bug comes
nowhere near the threshold for such a backport. I also seem to recall
that the consensus of the groff mailing list, reached some years ago, is
that our team is not large enough to support multiple branches of
development. Our headcount has not increased substantially since then.
This isn't to say that you couldn't petition Debian, Red Hat, Arch, and
other Linux distributors to recalibrate their backport/stable update
policy to more closely conform to your perturbation threshold.
As it happens, Debian's groff package maintainer, Colin Watson, has been
a fixture of the groff list for years, and has made a couple of dozen
commits to the repository over time. He's well-placed to gainsay me.
[1] The lack of `br` meant that a document that started with a `DS`
macro call did not "sweep" the drawing position past vertical
position 0, which springs a trap that calls a macro called
`cov*first-page-init`,[2] which does much essential
initialization, including (indirectly) setup of the `PS`
register storing the type size. Consequently, the text of the
display would render at 1 point(!) instead of the formatter's
default of 10. The diagnostic about the `nf` environment might
warn the user that the formatting is likely to go awry, but we
can do better than that by simply restoring the break.
IIUC ("restoring the break"), this is the same sort of regression as
with the .XA macro?
That seems a fair assessment.
to quote you: `I'd say "seems" is an understatement.'
deleting a "superfluous" line of code as a "code tidyup"?
I winced when I saw it; it was mixed in with an improvement in argument
validation and diagnostic reporting.
wrong emphasis/priorities then, it seems.
if so, I would rate this as an indication that you should consider to
increase your personal "confidence threshold" which you require to be
reached before you proceed with such an action.
Next time I have a time machine to go back three years and exhort myself
to think twice, I'll surely take your advice.
if at all take it for the future. that's easier. and would be helpful.
as said previously, the working hypothesis "original author might be
smarter (at least not less smart) than me and had a reason to put that
line in" could help.
The use of manifest program source code as a proxy measure of
intelligence is noteworthy for how many problems it's caused among
software engineers over the decades.
One might observe that the "smart" developer writes automated tests[3]
to measure the behavior of a complex software system, so that the
multifarious interactions of its components remain within expected
bounds on a mechanically (and independently, externally) verifiable
basis instead of resting solely upon the intelligence or mastery level
of an authoring developer, who might retire, lose their mental
faculties or interest in the project, or otherwise become unavailable.
By _that_ metric, the intelligence level of groff releases through
1.22.3 was minimal (only the "gdiffmk" program had any tests). For the
ms package in particular, it was at zero for the entire lifespan of the
1.22 series.
wrong metric.
A system that depends solely upon the intelligence of its maintenance
personnel is a fragile one, not a robust one. Have you ever talked to
a pilot or an electrical lineworker about the nature of their job, and
the rules and safety measures that are part of it?
beside the point.
I appreciate your candor--your perspective enables me to conclusively
decide the matter of what sort of person I'm dealing with, a question
whose answer you had only suggestively hinted toward before.
that is a rather offensive and arrogant statement. you draw any satisfaction
from such behaviour?
that's my approach with other peoples code at least when I adjust it
to my needs.
I conjecture that you've had better luck with the code people have
developed than with the people themselves, if you so speedily and
reflexively resort to derogating and insulting their intelligence.
this statement also is obviously intentional offensive. but also makes no sense at all. my
suggestion simply was to always assume that the "other guy" is possibly the smarter one in order to
avoid the sort of unforced errors you are seeming to be prone to ("that line of code makes no sense
to me, so I delete it without further ado because if it makes no sense to me, that's reason enough
to do so."). whose intelligence I am insulting with this proposal remains your well kept secret.
maybe you just have a distinctly inflated perception of yours if you can't stomach my proposal to
always tentatively presume "the other one" is smarter. --
I have arrived at the conclusion that the state of 1.23 is unsatisfactory (at least as far as ms is
concerned) and that too many regressions have been introduced, partly intentional (.IX removal from
s.tmac), partly due to avoidable interventions (uncalled-for code removal: .XA, .DS), partly due to
"fixing" "unspecified" behaviour (or so I seem to understand the present problem triggering this
thread). I trust that much valuable work has been done internally, too, but at the receiving end I
only care for user-visible regressions and stuff breaking that used to work previously. so I will
avoid 1.23 from now on and use the last "reliable" version, 1.22.4, instead.
last not least: your reaction/response to this simple bug report was unpleasant, to say the least.
for the second time in the second instance. but I have no interest in triggering and reading any
more of your abrasive and complacent, meandering monologues, let alone to try to respond reasonably
to them as I have tried here. this is ultimately fruitless and time's to valuable for that. so I
will unsubscribe (also because I will not be able to report further bugs in 1.23 since I will not be
exposed to them after reverting to 1.22.4, of course).
bye,
joerg
Regards,
Branden
[1] groff(7) from 1.22.4 differs little:
.rt Return (upward only) to vertical position marked by .mk
on the current page.
.rt ±N Return (upward only) to specified distance from the top
of the page (default scaling indicator v).
[2] CSTR #54 has equivalent language, not specifying the behavior of an
argumentless `rt` request when `mk` has not been called while
formatting the same page, but I leave verification of this
equivalence to the reader.
[3] or machine-verifiable proofs in a formal verification system