Re: Improve error reporting in 027_stream_regress test

Hi,

On Tue, 22 Jul 2025 at 03:56, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Jul 21, 2025 at 11:53:00AM +0300, Nazir Bilal Yavuz wrote:
> > I realized that we actually don't trim the file, we do the opposite;
> > read the file from both ends. Sorry for not realizing earlier. I will
> > update the remaining patches according to that but I think trim_file()
> > is helpful, too. What do you think about adding both
>
> I did not review the contents of the patch yet, as I was rather unsure
> about the right semantics here.
>
> > ```
> > trim_file() -> trims $n lines from head or tail of the file and
> > returns the remaining lines.
> > read_file_ends() -> returns $n lines from head or tail of the file.
> > ```
> >
> > although trim_file() will not be used in these particular patches?
>
> And this made me wonder over the weekend if only showing the head
> and/or tail of a file is always the best set of properties.
> Then I came up that  this could be something close to what git-grep
> -A/-B is able to do.  For example, for a crash, it would be much
> cheaper to target a log entry that matches with what we see in the
> usual crash stacks, then print the surroundings.  The "trim" behavior
> you have proposed is a subset of that, where the matching patterns are
> the end and/or the beginning of the file to show.
>
> So the API could com down to a pattern matching, with "head" and
> "tail" being the optional number of lines we'd want to print around
> the pattern we are looking for.

That makes sense and could be really useful in more general cases but
I think that discussion might be better suited for a separate thread.

For this specific case, we are dealing with regression.diffs; which
already contains the relevant diff output. We don't need to search for
patterns here; we just want to include a small portion of the file in
the error message, to spare users from having to open the file
manually.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft