stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Black <>
Subject Re: bulletproofing exec output
Date Mon, 30 Jul 2007 20:38:33 GMT
Greetings Martin

It might be of use to note how the existing parsers currently work when
considering how the output could be improved for the purposes of parsing.

On the windows side, the output from running of each family of
executables (locales, tests, examples) is routed into it's own file.  We
then read the file line by line, looking for the starting row header and
the (old) footer to determine when to start and stop reading.

On the unix side, the output from making the 'runall' target is teed
into a file, which is then post-processed.  During that processing, the
file is read line by line, with the section controlled by the make enter
marker, the processing start controlled by the starting row header, and
the processing stop controlled by the make leave marker.

Looking at the output (as it stands now), I believe the parsers could be
more robust if they ignored all lines that started with whitespace or
where the first word was in all caps.  Alternately, they could start
processing after the first line in all caps, and stop processing before
the second line in all caps.  I suppose a third option would be to alter
the exec utility so it could produce the output desired, rather than
doing a post-processing step.  Thoughts?

--Andrew Black

Martin Sebor wrote:
> I did some work on the exec utility recently. One of the enhancements
> I added was a summary section at the end of the output. It seems that
> this had the unexpected consequence to the scripts that interpret the
> output of the utility, namely that the new summary is taken as
> additional tests, examples, or locales and included in the generated
> reports.
> It's clear that the scripts aren't robust enough to deal with these
> types of changes. I'd like to find a way to make them more robust so
> that we can safely enhance the exec utility's output in the future
> without causing this sort of adverse fallout. To make this possible
> I think we need to enhance the output of exec to help the scripts
> disambiguate ordinary output (such as the "PROGRAM SUMMARY" label
> I added) from the output relevant to the scripts (i.e., the examples,
> tests, and locales).
> What should this output format look like? Would adding the number
> of each program in front its name be sufficient? I.e., replacing
>             0    0      46      0   100%
>        0    0      16      0   100%
>        0    0      16      0   100%
>        0    0      16      0   100%
> with
>   ##  NAME                  STATUS WARN ASSERTS FAILED PERCNT ...
>    1.             0    0      46      0   100%
>    2.        0    0      16      0   100%
>    3.        0    0      16      0   100%
>    4.        0    0      16      0   100%
> That way scripts written to process this type of output would look
> for lines matching the RE pattern "^ *[1-9][0-9]*\. [^ ][^ ]*  *"
> to reliably distinguish find programs (examples, locales, tests)
> in the log files from other kinds of output. The big assumption
> here is that there would be no other lines matching that RE in
> the logs, or at least not in the immediate vicinity of the output
> from exec.
> I would also like to make an additional enhancement to help scripts
> to extract the relevant exec output from the rest of the contents
> of the log and differentiate between examples, locales, and tests.
> I'm thinking replacing the label "NAME" with "EXAMPLE NAME", "LOCALE
> NAME", and "TEST NAME" and ending the output with something like
> "END EXAMPLES" etc. should do it.
> Any other/better ideas?
> Martin

View raw message