lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: small reduction in output from make doc


From: David Kastrup
Subject: Re: Patch: small reduction in output from make doc
Date: Thu, 16 Jun 2011 22:40:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Thursday, June 16, 2011 3:48 PM
>
>> Carl Sorensen <address@hidden> writes:
>>
>>> David Kastrup feels pretty strongly that progress messages belong
>>> on
>>> stderr along with warning/error messages, since ther are not the
>>> output of the program.
>>
>> Actually, I feel progress messages belong on /dev/null.  Iff stderr
>> is
>> on a tty, there may be some justification to put out some progress
>> indicators to it, but they should not take useful space: one can
>> compress successive progress messages by using CR and/or BS when
>> going
>> on.
>
> Yes and no.  I agree progress messages are generally
> wasted space, but in a complicated build like LilyPond
> with all the documentation there should be enough
> context information available to see easily what
> went wrong when the build fails.  Not sure you could
> capture that on one line.

Then it needs to be on more than one line.  But outputting lots as
garbage in the hope that the location of the important messages within
the garbage will by chance make it possible to infer information that
should be in the error message itself: that's stupid.

There are situations where you are without a clue and sifting through
loads of garbage is the last way out.  In that case, you enable tracing
functionality and bite the bullet.

> Most error messages are too localised.

I don't get it.  Getting the exact error location is what I want.  If
you need context, you can output multiple error locators: C compilers,
upon duplicate definitions, tend to output the locations of both
definitions when encountering the second one.  That's definitely better
than outputting just the second one, and loads of garbage around it in
the hope that this makes finding the first definition easier.

I would not mind if Lilypond wrote, upon encountering an error, all
locators that are in the input tree concerning the error.  Let it be a
dozen.  Those are relevant to the error.  Easier to sift through them
than two thousand lines not relevant to the error.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]