Re: [PATCH] Re: GUILE error reporting has changed for worse in 2.15 (compared to 2.12), useless now

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> Am Mittwoch, 3. August 2011, 21:39:43 schrieb Reinhold Kainhofer:
>> However, in lilypond 2.15.9 (and probably also some earlier versions),
>> lilypond suddenly only prints out the error message, but not where the
>> error occurred (neither file nor expression is displayed):
> [...]
>> Is there any way to revert GUILE's error reporting back to the 2.12
>> "verbose" output?
>> I think this deserves a bug report with priority "High", according to the
>> latest GOP-8 ("anything which makes it difficult for serious contributors
>> to help out (e.g. difficult to find the relevant source tree(s), [...]).")
>
> After some git bisect'ing, the offending commit is 
> 52bea08ef73a55ee3091f3267ee7075c066d13c5, which removed all (debug-enabled 
> debug) calls with the reason that they caused deprecation warnings (but also 
> printed out vital path/backtrace information!).
>
> Here is a patch, which reverts those debug changes:
>    http://codereview.appspot.com/4815085/
>
> The reason for the initial removal was to suppress deprecation warnings with 
> guile 2.0, but that should be easier achieved with setting warn-deprecated to 
> #f.
>
> See guile's 1.8 documentation:
>     http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Debugger-
> options.html#Debugger-options
>
> And the 2.0 documentation:
>     http://www.gnu.org/software/guile/manual/html_node/Debug-Options.html

I don't think that throwing away source file error locations should ever
be a default.  It might be available as an optimization for, say,
multiple pass processing, in case that it really, really, provably is
quite expensive to maintain.  But it is not a debug option in as far as
it is part of debugging Lilypond, but rather of debugging user input.

-- 
David Kastrup