Error reporting and Lilypond Linting

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Error reporting and Lilypond Linting

Guy Stalnaker-2
All,

I ask this question knowing some of Lilypond's developers frequent this list -- is there anyway to get better error reporting/logging? I ask for several reasons.

One is that the current log output when -verbose is enabled is FULL of lines relating to font substitution. Over 80% of the output, in fact. When trouble-shooting output errors related to lilypond code, those font-related lines just obfuscate the meaningful output. Could we get something like "LOG: font substitution" "LOG: font substitution 100 more times"?

Two, we all know how the smallest error, in the case I have in mind a closing  brace } one line off, can cause an explosion of error output. In this same case every reported error referencing a lilypond source line was, of course, an error; but not one of them were related to the actual error, that misplaced brace, which was near m.20 and not m.86 which was the focus of all of the log output referencing a source file line number. There may be nothing that can be done about that, of course, but if there were some type of WARNING process that recognized (!) mal-formed, or simply bad code, our lives might be a bit easier (though lilypond developers lives might not be easier). Alternatively, do any of you know of any kind of well-formedness checking, linting, for lilypond code?

Third, some log output lines do not reference a line in the lilypond source file. Again, in this case, the eventual resolution related to multi-measure rests (that closing brace } "covered" the multi-measure rest because it was after and not before the multi-measure rest). But none of log lines which indicated a multi-measure rest error referenced a line in the lilypond source. So, though multi-measure rest errors were there, they were not of much practical use because the lilypond source is several thousand lines long and there are hundreds of multi-measure rests in the dozen-plus parts. I eventually had to resort to the binary method of breaking the source in two, commenting part B, compiling part A, etc. to slowly eliminate working source to find the failing source.

GuyS

Guy Stalnaker
[hidden email]

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
dak
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error reporting and Lilypond Linting

dak
Guy Stalnaker <[hidden email]> writes:

> Third, some log output lines do not reference a line in the lilypond source
> file. Again, in this case, the eventual resolution related to multi-measure
> rests (that closing brace } "covered" the multi-measure rest because it was
> after and not before the multi-measure rest). But none of log lines which
> indicated a multi-measure rest error referenced a line in the lilypond
> source. So, though multi-measure rest errors were there, they were not of
> much practical use because the lilypond source is several thousand lines
> long and there are hundreds of multi-measure rests in the dozen-plus parts.
> I eventually had to resort to the binary method of breaking the source in
> two, commenting part B, compiling part A, etc. to slowly eliminate working
> source to find the failing source.

If you are interested in getting something fixed, an example beats an
anecdote.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error reporting and Lilypond Linting

Flaming Hakama by Elaine
In reply to this post by Guy Stalnaker-2
> From: Guy Stalnaker <[hidden email]>
> Subject: Error reporting and Lilypond Linting

> I ask this question knowing some of Lilypond's developers frequent this list -- is there anyway to get better error reporting/logging?

Sorry, I can't speak to your main question.


> So, though multi-measure rest errors were there, they were
> not of much practical use because the lilypond source is
> several thousand lines long and there are hundreds of
> multi-measure rests in the dozen-plus parts. I eventually
> had to resort to the binary method of breaking the source
> in two, commenting part B, compiling part A, etc. to slowly
> eliminate working source to find the failing source.

To be clear, I don't disagree with any of your suggestions for improving lilypond's logging.

However, this particular issue can be mitigated by breaking your source up into more manageable sections.  Why should part B need to wrangle with anything from part A?  That's seems like a liability without much upside.

In any kind of coding, after a few hundred lines, you should probably consider refactoring.  Multiple thousands of lines of source per file is just way too much to manage in most contexts, and is rarely necessary.

Maybe the next time you have such an error, rather than doing a binary search, you could start by reorganizing your file structure in a way that allows you to build individual targets.

If that sounds interesting, feel free to send me your file and I could make some suggestions as to how to restructure it.

Again, sorry I can't help specifically with the logging output.


HTH,

David Elaine Alt
415 . 341 .4954                                           "Confusion is highly underrated"
[hidden email]
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On Tue, Aug 8, 2017 at 1:48 PM, <[hidden email]> wrote:
Send lilypond-user mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/lilypond-user
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lilypond-user digest..."

Today's Topics:

   1. Re:Remove all occurrencies of "0" fingerings (David Kastrup)
   2. Re:Alignment problem (Menu Jacques)
   3. Re:Vertical alignment of custom dynamics (Gregor Smith)
   4. Error reporting and Lilypond Linting (Guy Stalnaker)


---------- Forwarded message ----------
From: David Kastrup <[hidden email]>
To: Marc Hohl <[hidden email]>
Cc: Thomas Morley <[hidden email]>, Lilypond-User <[hidden email]>
Bcc: 
Date: Tue, 08 Aug 2017 18:44:01 +0200
Subject: Re: Remove all occurrencies of "0" fingerings
Marc Hohl <[hidden email]> writes:

> Am 08.08.2017 um 13:00 schrieb Thomas Morley:
>> 2017-08-08 12:47 GMT+02:00 David Kastrup <[hidden email]>:
>>
>>>
>>> You can do this by using
>> [...]
>>
>> Nice one. I always forget about 'grob-transformer'. Missing bracket, tho'
>
> I wasn't aware of grob-transformer at all. And I am still unsure about
> what it does. I have read the doc string, though.

It gives your function both the grob and the value (callbacks and
unpure/pure containers already resolved) that _would_ get calculated
without your override in place.

That can be handy when your function just wants to modify the default,
or if the default is only used sometimes.  To use it, you don't need to
know whether the default is a constant, a function, or an unpure/pure
container.

--
David Kastrup




---------- Forwarded message ----------
From: Menu Jacques <[hidden email]>
To: "Manuela Gößnitzer" <[hidden email]>
Cc: Menu Jacques <[hidden email]>, Phil Holmes <[hidden email]>, Lilypond-User Mailing List <[hidden email]>
Bcc: 
Date: Tue, 8 Aug 2017 19:26:40 +0200
Subject: Re: Alignment problem
Hello Manuela,

+2, thanks, using two markups is both elegant and simple!

JM

Le 8 août 2017 à 12:18, Manuela Gößnitzer <[hidden email]> a écrit :

What about

\relative b, {
 \key g \major
 \clef "bass"
 \time 3/4

 \textLengthOn
 d4 _\markup{\italic "Fine"}
 \fermata
 g4- \markup { \dynamic "f" }
 b4
}


2017-08-07 15:18 GMT+02:00 Phil Holmes <[hidden email]>:
It does, but only if you attach the markup to the note.  As it turns out, it still _just_ collides with the forte, so adding a space to the end of "fine" solves this.  However, they still don't align since they are both avoiding note stems of different lengths.

\relative b, {
 \key g \major
 \clef "bass"
 \time 3/4

 \textLengthOn
 d4 _\markup{\italic "Fine "}
 \fermata
 g4 \f
 b4
}


--
Phil Holmes


----- Original Message ----- From: "Jacques Menu" <[hidden email]>
To: "Lilypond-User Mailing List" <[hidden email]>
Sent: Monday, August 07, 2017 1:30 PM
Subject: Re: Alignment problem



Hello Phil,

\textLengthOn doesn't solve the problem, thanks anyway!

JM

Jacques Menu, iPhone

Le 7 août 2017 à 08:19, Menu Jacques <[hidden email]> a écrit :

Hello folks,

Can the « Fine » and « f » be on the same horizontal line while remaining attached to two differents notes, without using any separate dynamics voice?

Thanks!

JM

\version "2.19.55"

\relative b, {
  \key g \major
  \clef "bass"
  \time 3/4

  d4
  \fermata _\markup{\italic "Fine"}
  g4 \f
  b4
}





--------------------------------------------------------------------------------







--------------------------------------------------------------------------------



_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user



_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user



---------- Forwarded message ----------
From: Gregor Smith <[hidden email]>
To: [hidden email]
Cc: 
Bcc: 
Date: Tue, 8 Aug 2017 19:57:20 +0100
Subject: Re: Vertical alignment of custom dynamics
Thanks, that worked. Had to change the horizontal alignment but now I have exactly what I was looking for.

On 6 August 2017 at 00:46, Martin Neubauer <[hidden email]> wrote:


On 06/08/2017 00:19, Gregor Smith wrote:
> \version "2.16.0"
>
> \include "common.ly"
>
> upper = \relative c'' {
>   \clef treble
>   \key c \major
>   \time 2/4
>   c2
>   \repeat volta 2 {
>     d | e
>   }
> }
>
>
> lower = \relative c' {
>   \clef bass
>   \key c \major
>   \time 2/4
>   c2
>   \repeat volta 2 {
>     d | e
>   }
> }
>
> mpf = \markup  { \dynamic { mp } "-" \dynamic { f } }
mpf = #(make-dynamic-script "mp - f")

or a little more elaborate:

mpf = #(make-dynamic-script
        (markup #:dynamic "mp"
          #:normal-text #:italic #:bold "-"
          #:dynamic "f"))
(The latter form isn't necessarily preferable in this instance, but
gives you an example how to achieve more fine-grained control over the
formatting if needed.)
>
> dynamics = {
>   s2\mp
>   \repeat volta 2 {
>     s2-\mpf | R2
>   }
> }
>
>
>
> \score {
>
>   \new PianoStaff <<
>     \new Staff = "upper" \upper
>     \new Dynamics = "dynamics" \dynamics
>     \new Staff = "lower" \lower
>   >>
> }
--
Ceci n'est pas une signature.


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user




---------- Forwarded message ----------
From: Guy Stalnaker <[hidden email]>
To: lilypond-user Mailinglist <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 8 Aug 2017 15:48:16 -0500
Subject: Error reporting and Lilypond Linting
All,

I ask this question knowing some of Lilypond's developers frequent this list -- is there anyway to get better error reporting/logging? I ask for several reasons.

One is that the current log output when -verbose is enabled is FULL of lines relating to font substitution. Over 80% of the output, in fact. When trouble-shooting output errors related to lilypond code, those font-related lines just obfuscate the meaningful output. Could we get something like "LOG: font substitution" "LOG: font substitution 100 more times"?

Two, we all know how the smallest error, in the case I have in mind a closing  brace } one line off, can cause an explosion of error output. In this same case every reported error referencing a lilypond source line was, of course, an error; but not one of them were related to the actual error, that misplaced brace, which was near m.20 and not m.86 which was the focus of all of the log output referencing a source file line number. There may be nothing that can be done about that, of course, but if there were some type of WARNING process that recognized (!) mal-formed, or simply bad code, our lives might be a bit easier (though lilypond developers lives might not be easier). Alternatively, do any of you know of any kind of well-formedness checking, linting, for lilypond code?

Third, some log output lines do not reference a line in the lilypond source file. Again, in this case, the eventual resolution related to multi-measure rests (that closing brace } "covered" the multi-measure rest because it was after and not before the multi-measure rest). But none of log lines which indicated a multi-measure rest error referenced a line in the lilypond source. So, though multi-measure rest errors were there, they were not of much practical use because the lilypond source is several thousand lines long and there are hundreds of multi-measure rests in the dozen-plus parts. I eventually had to resort to the binary method of breaking the source in two, commenting part B, compiling part A, etc. to slowly eliminate working source to find the failing source.

GuyS

Guy Stalnaker
[hidden email]

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user



_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Loading...