[m-rev.] for post-commit review: semantic help pieces for grade options

[Zoltan Somogyi]

On Thu, 17 Jul 2025 14:54:38 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> On Thu, 17 Jul 2025 at 01:21, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> > > I don't think memory rentention profiling is the main thing that memprof
> > > grades
> > > are used for, so I would either say:
> > >
> > >    Please see the "Using mprof for profiling memory allocation" and
> > >    "User mprof for profiling memory retention" sections in the Mercury
> > >    User's Guide for details.
> > >
> > > or, if you have to list one only section, point to the allocation one.

OK, I will follow this suggestion.

> > I don't have any objection to this, but I would like to understand the
> > situation before I make any changes. I don't usually use mprof (I use
> > the deep profiler instead),
> > and I don't usually even install the mprof-related
> > grades, so I am asking you guys: what happens if you invoke mprof -m
> > on a profile for a program that was compiled in a .prof (but not .memprof) grade?
> 
> In that specific case, you get a warning:
> 
>      Warning: error opening `Prof.Counts': can't open input file: No
> such file or directory
>     The generated profile will only include call counts.

That seems like a strange diagnostic. It says in effect "I can't get any counts,
so I will show you only the things I cannot get". At the very least, it should say
what kinds of counts (presumably not *call* counts) in Prof.Counts it cannot show.
And that is on top of "cannot open input file" nearly duplicating "error opening".
Text such as "cannot open `Prof.Counts' for reading: ..." or "cannot read `Prof.Counts': ..."
would be better.

Zoltan.