[Tutor] a program which list ALL the errors

[Oscar Benjamin]

On Sun, 25 Oct 2020 at 02:15, Mats Wichmann <mats at wichmann.us> wrote:
>
> On 10/24/20 5:15 PM, Alan Gauld via Tutor wrote:
> > On 24/10/2020 23:08, Cameron Simpson wrote:
> >> On 18Oct2020 12:34, Alan Gauld <alan.gauld at yahoo.co.uk> wrote:
> >>> But it must be said that its an unusual strategy.
> >>> Most programs detect the first error and stop.
> >>
> >> And those programmes are user experience disasters. I hate them with a
> >> passion.
> >
> >> When that logic is buried deep in a subsidiary script, the user is
> >> massively annoyed. I submitted a small patch to probe for _all_ the
> >> software, complain about each missing comonepnt, and _then_ quit. Really
> >> easy and avoids much anger in the end user.
> >
> > Interesting. I absolutely hate that behaviour. Some compilers
> > do it and its a massive pain finding the first error and fixing
> > it then trying to find another, and another,  and then discovering
> > that fixing the first actually changed the second! It's much,
> > much easier IMHO to fix one thing at a time.
>
> It really depends on the context.
>
> I've often run into this with the GNU autoconf stuff... try to configure
> a program, and it fails. Install missing package, retry, fails. Repeat
> several times.  Why?  In the case of an autoconf setup, the problems are
> likely to be missing distribution packages, and it's nice to get those
> all at once, rather than iterating, because you could just gang all the
> needed installs into one command.  But I freely admit there are also
> times where it's bad to spew all the errors, like with compilers - often
> one problem will cascade through and potentially give you dozens to
> hundreds of fails, and there's no value to spewing those, it's better to
> just emit one, fix it, retry - and probably the fail list got massively
> smaller.

I think an important factor in this is whether or not you can give
accurate error messages for independent failures. Having experienced
teaching new programmers in both C and Python I find Python's "stop at
the first error" behaviour much better than the C compiler. It shows
you one error at a time along with a (relatively) helpful explanation
of the error.

A typical C compiler might give hundreds of mostly distracting error
messages because of e.g. a single missed semicolon. More importantly
only the first error message about the missing semicolon (often not
said in so many words) is meaningful and all of the subsequent error
messages just result from the compiler itself being confused after
failing to parse that one line correctly.

Another factor though is the time taken to run the whole process and
see the failures. A complicated C build might take many minutes to run
so being able to see all the error messages in one go could save some
time in the process.

Over the past week I've been trying to fix up the sympy release script
so that I can release version 1.7. The release script runs in a docker
container that always pulls from the current HEAD of the release
branch on github. That means that if something goes wrong then to fix
it you need to issue a pull request, wait for CI to complete, merge
that and then rerun the script and wait for all the tests to run again
in the docker container. Altogether that means that a single
edit-and-retry takes 5 hours before you see the next error message. In
this context it would be very helpful if I could see all of the error
messages at once!

On the other hand during this process one of the problems I was trying
to debug was made more difficult by excessively verbose output.
Building the latex docs failed in the release script. The latex output
log from the failed build was 31000 lines long with the summary
"missing characters". Searching the log I find sections like this:

  Missing character: There is no è in font cmex10!
  [1
  ]

I spent a bunch of time fiddling around trying to specify the encoding
or find a version of the font containing this character. After some
fiddling I realise that the actual error message that I should have
been extracting from the log is this:

  LaTeX Warning: Command \LaTeX invalid in math mode on input line 88.

  LaTeX Warning: Command \TeX invalid in math mode on input line 88.

  ! You can't use `\spacefactor' in math mode.
  \@->\spacefactor
                   \@m {}
  l.88 \(\mathrm{\LaTeX}
                        \) printing by running
\sphinxcode{\sphinxupquote{init...
  Sorry, but I'm not programmed to handle this case;
  I'll just pretend that you didn't ask for it.
  If you're in the wrong mode, you might be able to
  return to the right one by typing `I}' or `I$' or `I\par'.

  Missing character: There is no è in font cmex10!
  [1

  ]

So what has happened here is that the latex compiler realised \LaTeX
was invalid and then replaced it with \TeX and then realised that that
was also invalid. Then the compiler *apologised* and decided to
"pretend" I didn't ask for "it" and inserted some gibberish including
è (most likely in latin1 rather than utf8) and then it failed because
the font didn't have a character for è. The fix is redefining the
\LaTeX macro and has nothing to do with è or the fonts or anything
else. The whole process could have been a lot quicker if the last line
of the log output was simply:

  LaTeX Error: Command \LaTeX invalid in math mode on input line 88.


--
Oscar