Re: score as footnote/footer

[Stephen MacNeil]

You could also do something like this


\version "2.18.2"

\header {

title = "FootNote"

tagline = "FootNote"

}

%%%


footOne = \markup {

%% space

\vspace #2

%

\hspace #1

\dir-column {

%%

\vspace #0

\concat {

"*" \hspace #1.5

\score {

\relative c { c'8 d e f g a b c}

\layout {

indent = 0

}

}

}

%%

}

\hspace #2

\dir-column {

%%

% move it over

\halign #-3.4

%%

\concat {

"**" \hspace #1

\score {

\relative c { c''8 b a g f e d c }

\layout {

indent = 0

}

}

}

%%

}

}

%%

one = \markup{P}

\relative c' {

\override Score.FootnoteItem.annotation-line = ##f

\footnote "*" #'(0 . 3) \footOne c'8 c a g f e d c c2 c c'8^"**" b a g f e
d c}



HTH

STephen
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Thomas Morley]

2016-04-17 21:01 GMT+02:00 Noeck :

> IMHO, it would make sense to [...] have 3 categories:
> - warning: user, please look at this
> - error: this is severe, there is something definitely wrong, but
>   Lilypond did its very best to keep running
> - fatal error: this is severe and Lilypond could not rescue the
>   situation, nothing was produced

We do this already, (but see below for multi-file-compilation).

Actually, we have even more fine-grained errors/warnings/messages.
But if any problem causes an _error_  of any kind (not a warning),
even a non_fatal_error, LilyPond throws a fatal error _after_ having
tried to create a pdf.

In short:
If error detected?
1. print to terminal the kind of the error, with location
2. create pdf, if non_fatal_error
3. throw a fatal error

As far as I know, the third point was introduced, because the first
was ignored far too often.



> nothing was produced

Doesn't work for multi-file-compilation.
To illustrate:
Imagine three files
file-I.ly
file-II.ly
file-III.ly

file-II.ly contains nothing else than
#(ly:error "~a" (*location*))
The other files will not cause any error/warning

Now do
lilypond file-I.ly file-II.ly file-III.ly
You'll notice:
LilyPond will compile file-I.ly with pdf
file-II.ly causes a fatal error, Lilypond exits immediately
file-III.ly will not be compiled at all.

I'm aware Andrew intended to disregard multi-file-compilation, though
we need to care about the entire functionality.


So, how to do it reasonable different?


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Tim McNamara]

> On Apr 17, 2016, at 3:16 PM, David Kastrup  wrote:
> 
> Noeck  writes:
> 
>> These two are often similar but not always.
>> IMHO, it would make sense to consider both and have 3 categories:
>> - warning: user, please look at this
>> - error: this is severe, there is something definitely wrong, but
>>  Lilypond did its very best to keep running
>> - fatal error: this is severe and Lilypond could not rescue the
>>  situation, nothing was produced
> 
> We are not talking about "nothing was produced" since LilyPond can't
> change the past.  The demand rather boils down to "if LilyPond has
> already successfully produced anything, that should not be left
> available and the PDF should not be completed properly."

Having read this thread from the perspective of a musician who uses LilyPond 
rather than a programmer who is also a musician, I don't don't understand the 
controversy.  It seems to me that LilyPond should produce whatever output it 
can from the syntax such as it is- whether that is a garbled PDF file or MIDI 
file- because that helps point the user to the syntax error in a very concrete 
way.  "Oh, my forced breaks failed there and I see the note with the wrong 
duration that caused it."  For me it is helpful to have the output; having 
LilyPond say essentially "you effed up, son, and you can't have a PDF to check 
it out" is less helpful to me.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[David Kastrup]

Sharon Rosner  writes:

>> Except that the premise of this thread was that users refuse to look
>> _at_ _all_ at _any_ messages or error status and instead want to be able
>> to deduce the presence of errors from the existence of output files.
>
>> So it pretty much doesn't matter what we write on the console: it's not
>> acceptable for LilyPond to produce any file in case of a syntax error.
>
> Actually the premise of this thread was something altogether different, and
> I'd rather believe it's a simple case of misunderstanding than you trying
> deliberately to make any sort of healthy debate futile:
>
> Andrew started with:
>
>> Wouldn’t a complete syntax error stop processing?
>
> Then Simon wrote:
>
>> To me, the oddity would be in that Lily speaks of a ‘fatal error’ here.
>
> That's the whole premise for you right there. The existence or absence of
> output files is just a corollary.
>
> If we can further pinpoint the discussion, given the current way lilypond
> handles parsing (or other) errors, what *is* the meaning of 'fatal error'?

An error leading to a fatal error message and a non-zero exit status
because LilyPond does not see fit to deal with the input properly.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score as footnote/footer

[David Kastrup]

bart deruyter  writes:

> hey,
>
> maybe a bit late, but I've done this in footnotes in the past. There was
> one issue though, footnotes are placed on top of each other like:
>
> 1. one score here
> 2. second score here.
> 3. third score here.
>
> What I needed back then was footnotes next to each other like:
>
> 1. one score here. 2. second score here 3. third score here.
>
> The reason is that these scores are short parts, but can take a lot of
> vertical space.
>
> Back then it was not possible to get the scores horizontally next to each
> other. Just informing, is it possible now?
>
> The advantage of footnotes is that in a muliple page document, they would
> be rendered on the right page automatically.

Page layout is still hardwired in C++, including footnotes.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[David Kastrup]

Noeck  writes:

> These two are often similar but not always.
> IMHO, it would make sense to consider both and have 3 categories:
> - warning: user, please look at this
> - error: this is severe, there is something definitely wrong, but
>   Lilypond did its very best to keep running
> - fatal error: this is severe and Lilypond could not rescue the
>   situation, nothing was produced

We are not talking about "nothing was produced" since LilyPond can't
change the past.  The demand rather boils down to "if LilyPond has
already successfully produced anything, that should not be left
available and the PDF should not be completed properly."

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Sharon Rosner]

> Except that the premise of this thread was that users refuse to look
> _at_ _all_ at _any_ messages or error status and instead want to be able
> to deduce the presence of errors from the existence of output files.

> So it pretty much doesn't matter what we write on the console: it's not
> acceptable for LilyPond to produce any file in case of a syntax error.

Actually the premise of this thread was something altogether different, and
I'd rather believe it's a simple case of misunderstanding than you trying
deliberately to make any sort of healthy debate futile:

Andrew started with:

> Wouldn’t a complete syntax error stop processing?

Then Simon wrote:

> To me, the oddity would be in that Lily speaks of a ‘fatal error’ here.

That's the whole premise for you right there. The existence or absence of
output files is just a corollary.

If we can further pinpoint the discussion, given the current way lilypond
handles parsing (or other) errors, what *is* the meaning of 'fatal error'?

Sharon



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lilypond-error-behaviour-tp189622p189688.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Turn moving of objects into code

[Noeck]

Hi,

there was a discussion some time ago about graphical adjustments that
are translated into ly code; e.g. to move or shape slurs in svg and get
the numbers in your ly file as a Frescobaldi feature.

Something similar seems to be achieved for css:
https://bugzilla.mozilla.org/show_bug.cgi?id=1139187
I am afraid, I only know a source in German for it:
https://www.soeren-hentzschel.at/firefox/firefox-48-entwickler-werkzeuge-leichteres-bewegen-von-positionierten-elementen/
perhaps you can read a translated version.

The idea is: You move an html object in your browser and you are told
the css that would put it there for absolute and similar positioning.

It is probably quite far from the Lilypond context, but I wanted to
mention it here in case someone is interested.

Cheers,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Noeck]

Am 17.04.2016 um 16:49 schrieb Kieren MacMillan:
>> Except that the premise of this thread was that users […]
>> > want to be able to deduce the presence of errors from the existence of 
>> > output files.
> Ah… sorry, I didn’t get that that was the premise.

I don't think so. To me it seems quite the contrary, the users wanted to
deduce from the error code whether Lilypond could do something with the
input to produce the output and *not* have to figure that out from the
presence of the output file. But that's just what I read.


From my point of view, the discussion boils down to:

- Lilypond has two categories of 'problems': warnings and errors and the
developers categorize the situation according to the associated severity.
-> metric: severe or not?

- Another criterion implied in this thread would be:
Can Lilypond go on after this situation and try to finish whatever it
can or is there no chance and it just stops here before it reaches the
end of the task.
-> metric: finishable (with some output) or exit here?


These two are often similar but not always.
IMHO, it would make sense to consider both and have 3 categories:
- warning: user, please look at this
- error: this is severe, there is something definitely wrong, but
  Lilypond did its very best to keep running
- fatal error: this is severe and Lilypond could not rescue the
  situation, nothing was produced

Probably, some similar situations (similar input syntax error) appear
inconsistent, because it depends on what is called later on whether this
is fatal or not. But still but the severity would be consistent (warning
or error) and the pdf would be there if there is no fatal error.

Cheers,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score as footnote/footer

[bart deruyter]

hey,

maybe a bit late, but I've done this in footnotes in the past. There was
one issue though, footnotes are placed on top of each other like:

1. one score here
2. second score here.
3. third score here.

What I needed back then was footnotes next to each other like:

1. one score here. 2. second score here 3. third score here.

The reason is that these scores are short parts, but can take a lot of
vertical space.

Back then it was not possible to get the scores horizontally next to each
other. Just informing, is it possible now?

The advantage of footnotes is that in a muliple page document, they would
be rendered on the right page automatically.

grtz,
Bart

http://www.bartart3d.be/
On Twitter 
On Identi.ca 
On Google+ 

2016-04-17 13:34 GMT+02:00 bobr...@centrum.is :

> Thanks for the responses.  The score-in-copyright idea does precisely what
> I want; it's centered at the bottom of the first and only the first page of
> a score.
>
> 
> \version "2.18.0"
>
> models =  \relative c' {
>   c4-( d-) e-( f-)
>   \bar "||"
>   c4. d8 e4. f8
> }
>   \layout {}
>
>
> tune = \relative c' {\repeat unfold 25 { c4 d e f }}
>
> \score {
>   \tune
> }
>
>
> \header {
>   tagline = ""
>   copyright = \markup \score {
> \models
> \layout { }
>   }
> }
> 
>
> - Original Message -
> > From: "Urs Liska" 
> > To: bobr...@centrum.is, "Lilypond-User Mailing List" <
> lilypond-user@gnu.org>
> > Sent: Sunday, April 17, 2016 9:35:16 AM
> > Subject: Re: score as footnote/footer
> >
> >
> >
> > Am 17. April 2016 11:28:23 MESZ, schrieb "bobr...@centrum.is"
> > :
> > >It is sometimes the case in an etude book that a model of the etude
> > >showing a different general rhythm or articulation pattern will be
> > >given at the bottom of a page.  Typically, the model will be only one
> > >or a very few measures in a smaller size, centered at the bottom of the
> > >page.  Is this possible in straight LilyPond or is it necessary to use
> > >LilyPond-book?  I would prefer a straight LilyPond solution.
> > >
> > >-David
> > >
> >
> > I think this should be possible by inserting a score in a markup in the
> > copyright field.
> >
> > HTH
> > Urs
> >
> > --
> > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
> >
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re:Lilypond error behaviour

[Peter Gentry]

The errors that I frequently make show up as an additional empty stave or a 
ridiculously over long bar that runs off the page. This
alerts me to an error but I have to search for it and they can be be very 
simple typos. Error messages in the log may also be a
later result of the error rather than pin pointing its location so some digging 
is usually required.
 
This seems fine to me as all you have to do is work through the input step by 
step to loacte the error. It would be difficult
(impossible) to pick out all input errors in programs like Lilypond compared to 
familar number crunching codes, how the heck does
the code know what your intentions are and what is an "error" in your source.
 
Lets not ask the impossible of hard pressed developers.
 
regards 
Peter Gentry 
 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Kieren MacMillan]

Hi David,

> Except that the premise of this thread was that users […]
> want to be able to deduce the presence of errors from the existence of output 
> files.

Ah… sorry, I didn’t get that that was the premise.

> So it pretty much doesn't matter what we write on the console: it's not
> acceptable for LilyPond to produce any file in case of a syntax error.

Agreed, if that’s actually what’s on the table.

I personally read all errors AND check the output (AND up the log level, if I 
can’t find the problem that way)… but I know that isn’t true of all users. I 
did find it a bit disconcerting when I first noticed version number problems 
outputting fatal errors… but I quickly got over it without ultimately caring 
too much either way.

Maybe this thread is just a sign that Lilypond is becoming a victim of its own 
“success" (however limited that may be, relatively speaking).

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[David Kastrup]

Kieren MacMillan  writes:

> That being said, if (as in David K’s example) one or more
> sub-compilations fails “fatally” — in other words, it would have
> resulted in no meaningful/useful/concrete/verifiable output if it were
> the sole compilation task — then the log should reflect that in some
> way: it should indicate that *some*
> meaningful/useful/concrete/verifiable output had been achieved, but
> possibly not *all* of it as expected by the user.

Except that the premise of this thread was that users refuse to look
_at_ _all_ at _any_ messages or error status and instead want to be able
to deduce the presence of errors from the existence of output files.

So it pretty much doesn't matter what we write on the console: it's not
acceptable for LilyPond to produce any file in case of a syntax error.

> Nobody ever said good error handling and reporting was easy.  =)

To me this does not sound as much as "not easy" rather than "rigged".

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Kieren MacMillan]

Hi all,

On Apr 17, 2016, at 8:15 AM, David Kastrup  wrote:
> why can one now consider LilyPond as having succeeded in compiling the file?

If no final output file (e.g., PDF) exists before compilation begins, a final 
output file does exist after compilation ends, most users would understand the 
aggregate error to be non-“fatal”. To me — and, I would offer, to most users 
I’ve ever worked with, programmed for, or watched in action — “fatal”, in this 
kind of context, means the application in question had to terminate before 
*any* [not *all*] meaningful/useful/concrete/verifiable output could be 
achieved. Surely, if a database made a successful SQL transaction, but the UI 
couldn’t return to the main menu because of some subsequent navigation error, 
it would be misleading (not to mention unnecessarily alarming) to say that a 
“fatal” error had occurred.

That being said, if (as in David K’s example) one or more sub-compilations 
fails “fatally” — in other words, it would have resulted in no 
meaningful/useful/concrete/verifiable output if it were the sole compilation 
task — then the log should reflect that in some way: it should indicate that 
*some* meaningful/useful/concrete/verifiable output had been achieved, but 
possibly not *all* of it as expected by the user.

Nobody ever said good error handling and reporting was easy.  =)

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Thomas Morley]

2016-04-17 13:59 GMT+02:00  :
> On Sun, 17 Apr 2016, Urs Liska wrote:
>> No, of course not. If LilyPond is able to "recover" (as Andrew put it) it
>> should of course do so. But it should not report a "fatal error" and a
>> "failed file" then.
>
> I think the whole thing comes down to something very simple which
> ought to go without saying, but evidently needs to be said after all:
>
> Lilypond should not lie.

Does she?

Look at the sippet below where I accumulated several errors:

 snippet start

\version "1.7.2"

(display "whatever")

\foo

{ c''1 }
{

#(format #t "~a\n"
  (assoc 'avoid-slur (assoc-get 'Accidental all-grob-descriptions)))

%{

 snippet end !!

In terminal I see:

(1) for the version:

error: file too old: 1.7.2 (oldest supported: 2.7.38)
error: consider updating the input with the convert-ly script

(2) for `(display "whatever")' without leading #-sign

atest-218.ly:3:1: error: syntax error, unexpected EVENT_IDENTIFIER

(display "whatever")

(3) for the call of undefined `foo'

atest-218.ly:5:1: error: unknown escaped string: `\foo'

\foo

(4) for the opening `{' followed by #(format ...)

(avoid-slur . inside)
atest-218.ly:10:1: warning: Ignoring non-music expression

#(format #t "~a\n"

(5) for the not finished block-comment

atest-218.ly:13:3: error: EOF found inside a comment
%{

atest-218.ly:13:3: error: syntax error, unexpected end of input
%{

All of them are "non_fatal_error" errors, correctly reported! LilyPond
continues outputting a pdf.
In the very end she throws a more or less summarizing _fatal_ error _and_ exits.
`Success: compilation successfully completed' is missing!
(Or look in flower/warn.cc and lily/lexer.ll)

It's LilyPonds most important goal to produce some printed output. And
she succeeds even by such a messy input.
The reason throwing the fatal error but not exiting before is
explained in the CG-link Simon already provided.

Is it a lie throwing such an summarizing fatal error in order to
protect our user-, bug- and devel-mailing-lists from users not paying
attention what they are told by non_fatal_errors (and warnings)?
I know several examples where people continued happily ignoring all
until the file contained several thousand lines and finally something
in that mess caused an _immidiate_ fatal error. Then they shine up on
mailing-lists and forums complaining and asking for help.

Otoh, I think I understand why Andrew needs to triage the differently
severe errors.
But the only thing I can think of is to treat _any_ error/warning as
fatal setting
#(ly:set-option 'warning-as-error)
or using the command-line version
-dwarning-as-error


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[David Kastrup]

Urs Liska  writes:

> Am 17.04.2016 um 12:33 schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> Am 17. April 2016 10:51:34 MESZ, schrieb David Kastrup :
 Urs Liska  writes:

> Am 17. April 2016 08:20:52 MESZ, schrieb David Kastrup :
>
>> A warning is appropriate for something which is not an error: namely
>> LilyPond has a well-specified task but the results will not likely
>> make sense.  LilyPond does not return an error code for a warning.
> Well, then let LilyPond report an error when it encounters one. But
> only then a "fatal" one when it actually forces LilyPond to stop.
 For any _correct_ input, LilyPond is eventually forced to stop.
>>> This is the point where I have to say you are talking bullshit,
>>> deliberately (?) and arbitrarily flipping around everyone's words and
>>> intentions. It doesn't make sense to continue with that thread.
>> So what does "force to stop" mean in your opinion?  
>
> \version "2.19.40"
>
> {
>   c'
>
> produces:
>
> /tmp/frescobaldi-hp7_ll/tmpoyBSnr/document.ly:4:4 <0>: error: syntax
> error, unexpected end of input
>
> c
>
> '

How is this substantially different from

{ c' }
{

here?

GNU LilyPond 2.19.32
Processing `dog.ly'
Parsing...
dog.ly:2:2: error: syntax error, unexpected end of input
{
 
dog.ly:1: warning: no \version statement found, please add

\version "2.19.32"

for future compatibility
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-EZC6cx'...
Converting to `dog.pdf'...
Deleting `/tmp/lilypond-EZC6cx'...
fatal error: failed files: "dog.ly"

> fatal error: failed files: "/tmp/frescobaldi-hp7_ll/tmpoyBSnr/document.ly"
>
> and it is obivous that LilyPond wasn't able to produce a file. This is
> the class of errors where I think the label "fatal" is appropriate.

So in my example it did produce a file.  The error was exactly the same
kind of error.  Now it is no longer fatal?  Because there was something
before the error that _did_ produce output?

> No, of course not. If LilyPond is able to "recover" (as Andrew put it)
> it should of course do so. But it should not report a "fatal error"
> and a "failed file" then.

So why is the above error no longer fatal, and why can one now consider
LilyPond as having succeeded in compiling the file?

> I would say if LilyPond is able to produce files for all targets that
> are requested by the input file then the compilation didn't "fail".

Ok, so now here magically there was no failure.  One problem with your
definition is that with syntax errors present you don't even _know_
whether or not the input file requested some target.

> If it produced "error" messages along the way then "compilation
> completed with errors" or something like that but compilation didn't
> fail.
>
>>
>> I don't get the obsession with "it is not an error if LilyPond does
>> not immediately crash and leaves bad output or none at all".
>
> Obviously you don't get it because you seem obsessed by the word
> "error" while gating out the word "fatal".

Is the error in the file I showed fatal or not?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[mskala]

On Sun, 17 Apr 2016, Urs Liska wrote:
> No, of course not. If LilyPond is able to "recover" (as Andrew put it) it
> should of course do so. But it should not report a "fatal error" and a
> "failed file" then.

I think the whole thing comes down to something very simple which
ought to go without saying, but evidently needs to be said after all:

Lilypond should not lie.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Urs Liska]

Am 17.04.2016 um 04:29 schrieb David Wright:
> I think a better analogy than compilers writing programs would be
> browsers rendering web pages. Can you imagine a WWW where malformed
> pages produced a few error messages on the screen and nothing else?
> No, we expect the browser to make its best attempt at a partial
> rendition. So please leave LP alone and write a better server.
> Yes, it might be nice if LP had an indication of severity level,
> but my preference would be for improvements in LP's primary goals.

I think the browser is indeed a good analogy.

If we have malformed HTML or even worse issues like e.g. a failed CSS
include, then yes, we expect the browser to render as much and as nice
as possible. But what LilyPond currently does is displaying a big modal
over the page saying "I'm sorry but I couldn't render the page due to a
fatal error. Please click here to close this message and view the page."

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Urs Liska]

Am 17.04.2016 um 12:33 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Am 17. April 2016 10:51:34 MESZ, schrieb David Kastrup :
>>> Urs Liska  writes:
>>>
 Am 17. April 2016 08:20:52 MESZ, schrieb David Kastrup :

> A warning is appropriate for something which is not an error: namely
> LilyPond has a well-specified task but the results will not likely
> make sense.  LilyPond does not return an error code for a warning.
 Well, then let LilyPond report an error when it encounters one. But
 only then a "fatal" one when it actually forces LilyPond to stop.
>>> For any _correct_ input, LilyPond is eventually forced to stop.
>> This is the point where I have to say you are talking bullshit,
>> deliberately (?) and arbitrarily flipping around everyone's words and
>> intentions. It doesn't make sense to continue with that thread.
> So what does "force to stop" mean in your opinion?  

\version "2.19.40"

{
  c'

produces:

/tmp/frescobaldi-hp7_ll/tmpoyBSnr/document.ly:4:4 <0>: error: syntax
error, unexpected end of input

c

'

fatal error: failed files: "/tmp/frescobaldi-hp7_ll/tmpoyBSnr/document.ly"

and it is obivous that LilyPond wasn't able to produce a file. This is
the class of errors where I think the label "fatal" is appropriate.


> That LilyPond should
> refrain from completing the current PDF it has open and make sure that
> it is invalid or deleted?  

No, of course not. If LilyPond is able to "recover" (as Andrew put it)
it should of course do so. But it should not report a "fatal error" and
a "failed file" then.

> What if the input file generated more than
> one PDF?  Should it delete or invalidate the PDF files it has written
> previously?  What if it had already written a PDF but fails during
> generation of a MIDI or vice versa?

I would say if LilyPond is able to produce files for all targets that
are requested by the input file then the compilation didn't "fail". If
it produced "error" messages along the way then "compilation completed
with errors" or something like that but compilation didn't fail.

>
> I don't get the obsession with "it is not an error if LilyPond does not
> immediately crash and leaves bad output or none at all".

Obviously you don't get it because you seem obsessed by the word "error"
while gating out the word "fatal".

>
> When is a stop forced?  Is LilyPond allowed to produce an error message
> before crashing?

Maybe "stop forced" isn't the perfect term either. Replace that with
when the error prevents LilyPond from producing output.
If LilyPond crashes then obviously any error handling has failed, so
that shouldn't be taken into account here.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score as footnote/footer

[bobr...@centrum.is]

Thanks for the responses.  The score-in-copyright idea does precisely what I 
want; it's centered at the bottom of the first and only the first page of a 
score.


\version "2.18.0"

models =  \relative c' {
  c4-( d-) e-( f-)
  \bar "||"
  c4. d8 e4. f8
}
  \layout {}


tune = \relative c' {\repeat unfold 25 { c4 d e f }}

\score {
  \tune 
}


\header {
  tagline = ""
  copyright = \markup \score {
\models
\layout { }
  }
}


- Original Message -
> From: "Urs Liska" 
> To: bobr...@centrum.is, "Lilypond-User Mailing List" 
> Sent: Sunday, April 17, 2016 9:35:16 AM
> Subject: Re: score as footnote/footer
> 
> 
> 
> Am 17. April 2016 11:28:23 MESZ, schrieb "bobr...@centrum.is"
> :
> >It is sometimes the case in an etude book that a model of the etude
> >showing a different general rhythm or articulation pattern will be
> >given at the bottom of a page.  Typically, the model will be only one
> >or a very few measures in a smaller size, centered at the bottom of the
> >page.  Is this possible in straight LilyPond or is it necessary to use
> >LilyPond-book?  I would prefer a straight LilyPond solution.
> >
> >-David
> >
> 
> I think this should be possible by inserting a score in a markup in the
> copyright field.
> 
> HTH
> Urs
> 
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
> 

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Andrew Bernard]

I now understand, which I had not previously, that lilypond will make its best 
effort to continue at all times, and this is a core value of the design 
philosophy – thanks Simon for pointing this out. But nobody has been able to 
explain to me how classing the error in question as fatal and then going on to 
produce good output is consistent with normal English usage. Since it is not 
consistent with normal English usage it is a source of confusion, as others 
have also pointed out. One is loth to pull out a dictionary in discussions. but 
the Oxford English Dictionary 2nd Edition gives the definition or denotation of 
fatal as:

fatal: 6. a. Producing or resulting in death, destruction, or irreversible 
ruin, material or immaterial; deadly, destructive, ruinous.

Apart from this common language usage, it is my praxis and experience in all 
spheres of programming that a ‘fatal error’ means the program cannot continue, 
even if it would like to.

Surely by any standard usage a recoverable error cannot be reported as fatal. 
There is no ruinous outcome. The file is produced. This is what I am referring 
to. It certainly confused me. I would say there is a class of errors that 
lilypond throws that are clearly recoverable, and should be reported in a more 
fine grained manner.

If certain people choose to think this topic is obsessive on my part, then 
apart from the fact that that is personally offensive, then why bother 
discussing subtleties of programming and usage at all? Semantics matters, as 
does also, for example, the semantics of fine engraving of musical notation. 
Clear semantics leads to clearer understanding. If lilypond had instead 
reported ‘recoverable error at or near line x’ this thread would never have 
arisen.

Andrew


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score as footnote/footer

[David Kastrup]

Urs Liska  writes:

> Am 17. April 2016 11:28:23 MESZ, schrieb "bobr...@centrum.is"
> :
>>It is sometimes the case in an etude book that a model of the etude
>>showing a different general rhythm or articulation pattern will be
>>given at the bottom of a page.  Typically, the model will be only one
>>or a very few measures in a smaller size, centered at the bottom of the
>>page.  Is this possible in straight LilyPond or is it necessary to use
>>LilyPond-book?  I would prefer a straight LilyPond solution.
>>
>>-David
>>
>
> I think this should be possible by inserting a score in a markup in
> the copyright field.

footnote maybe?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score as footnote/footer

[Pierre Perol-Schneider]

Hi David,

Try:

\version "2.19.39"

\header {
  title = "Scores as footnotes"
}

\markup {
  \null
  \footnote
  \null
  \concat {
"*" \hspace #1.5
\score {
  \relative { c'8 d e f g a b c}
  \layout {
indent = 0
  }
}
  }
  \null
  \footnote
  \null
\concat {
"**" \hspace #1
\score {
  \relative { c''16 b a g f e d c }
  \layout {
indent = 0
  }
}
  }
}

\score {
  \relative { c'4 d e f g a b c}
  \layout {
\context {
  \Staff
  instrumentName = "*"
}
  }
}

\score {
  \relative { c''4 b a g f e d c }
  \layout {
\context {
  \Staff
  instrumentName = "**"
}
  }
}

Cheers,
Pierre

2016-04-17 11:28 GMT+02:00 bobr...@centrum.is :

> It is sometimes the case in an etude book that a model of the etude
> showing a different general rhythm or articulation pattern will be given at
> the bottom of a page.  Typically, the model will be only one or a very few
> measures in a smaller size, centered at the bottom of the page.  Is this
> possible in straight LilyPond or is it necessary to use LilyPond-book?  I
> would prefer a straight LilyPond solution.
>
> -David
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Simon Albrecht]

On 17.04.2016 04:29, David Wright wrote:

As to lilypond making a best effort at producing output, I have never
seen this referred to in the NR. That ought to go in somewhere.

Um, the purpose of LP is to produce output (lilypond.org line 1).



I think this is in the right place there, instead of in the NR.

Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[David Kastrup]

Urs Liska  writes:

> Am 17. April 2016 10:51:34 MESZ, schrieb David Kastrup :
>>Urs Liska  writes:
>>
>>> Am 17. April 2016 08:20:52 MESZ, schrieb David Kastrup :
>>>
A warning is appropriate for something which is not an error: namely
LilyPond has a well-specified task but the results will not likely
make sense.  LilyPond does not return an error code for a warning.
>>>
>>> Well, then let LilyPond report an error when it encounters one. But
>>> only then a "fatal" one when it actually forces LilyPond to stop.
>>
>>For any _correct_ input, LilyPond is eventually forced to stop.
>
> This is the point where I have to say you are talking bullshit,
> deliberately (?) and arbitrarily flipping around everyone's words and
> intentions. It doesn't make sense to continue with that thread.

So what does "force to stop" mean in your opinion?  That LilyPond should
refrain from completing the current PDF it has open and make sure that
it is invalid or deleted?  What if the input file generated more than
one PDF?  Should it delete or invalidate the PDF files it has written
previously?  What if it had already written a PDF but fails during
generation of a MIDI or vice versa?

I don't get the obsession with "it is not an error if LilyPond does not
immediately crash and leaves bad output or none at all".

When is a stop forced?  Is LilyPond allowed to produce an error message
before crashing?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score as footnote/footer

[Urs Liska]

Am 17. April 2016 11:28:23 MESZ, schrieb "bobr...@centrum.is" 
:
>It is sometimes the case in an etude book that a model of the etude
>showing a different general rhythm or articulation pattern will be
>given at the bottom of a page.  Typically, the model will be only one
>or a very few measures in a smaller size, centered at the bottom of the
>page.  Is this possible in straight LilyPond or is it necessary to use
>LilyPond-book?  I would prefer a straight LilyPond solution.
>
>-David
>

I think this should be possible by inserting a score in a markup in the 
copyright field.

HTH
Urs

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

score as footnote/footer

[bobr...@centrum.is]

It is sometimes the case in an etude book that a model of the etude showing a 
different general rhythm or articulation pattern will be given at the bottom of 
a page.  Typically, the model will be only one or a very few measures in a 
smaller size, centered at the bottom of the page.  Is this possible in straight 
LilyPond or is it necessary to use LilyPond-book?  I would prefer a straight 
LilyPond solution.

-David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Urs Liska]

Am 17. April 2016 10:51:34 MESZ, schrieb David Kastrup :
>Urs Liska  writes:
>
>> Am 17. April 2016 08:20:52 MESZ, schrieb David Kastrup :
>>
>>>A warning is appropriate for something which is not an error: namely
>>>LilyPond has a well-specified task but the results will not likely
>>>make sense.  LilyPond does not return an error code for a warning.
>>
>> Well, then let LilyPond report an error when it encounters one. But
>> only then a "fatal" one when it actually forces LilyPond to stop.
>
>For any _correct_ input, LilyPond is eventually forced to stop.

This is the point where I have to say you are talking bullshit, deliberately 
(?) and arbitrarily flipping around everyone's words and intentions. It doesn't 
make sense to continue with that thread.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[David Kastrup]

Urs Liska  writes:

> Am 17. April 2016 08:20:52 MESZ, schrieb David Kastrup :
>
>>A warning is appropriate for something which is not an error: namely
>>LilyPond has a well-specified task but the results will not likely
>>make sense.  LilyPond does not return an error code for a warning.
>
> Well, then let LilyPond report an error when it encounters one. But
> only then a "fatal" one when it actually forces LilyPond to stop.

For any _correct_ input, LilyPond is eventually forced to stop.

> It is in no way a fatal error to have \version "2.19.39" in a file and
> compile it with 2.19.38. It just exposes a *certain* risk of problems.

It wasn't the topic whether or not a version mismatch should be a
warning or an error.

The choice to make it an error was _deliberate_ since we figured out the
hard way that people will ignore warnings and instead report every
change of syntax to the bug list.  Making a version mismatch an error
rather than a warning was not a decision dictated by logic but by
expediency.

However, Andrew basically tells us that he will also ignore errors
unless LilyPond searches for all files that the user could have expected
to be output from a run of LilyPond and deletes them.

I don't think it makes sense to go there.  If users are not willing to
accept an error message and error code, then I don't think we should try
to additionally sabotage LilyPond's attempts at salvaging something
useful in the output.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[Urs Liska]

Am 17. April 2016 08:20:52 MESZ, schrieb David Kastrup :
>Andrew Bernard  writes:
>
>> If you look at the MWE example I provided to illustrate what I
>believe
>> is misleading information about a ‘FATAL’ error, then it has plain
>> text which it ignores, claims a fatal error and proceeds to make a
>> perfectly good PDF.
>
>LilyPond wouldn't know that, and in any way it returns an ERROR message
>and an ERROR code.
>
>I don't know why you are obsessed about LilyPond not touching the PDF
>(in which case you still would not have an idea about whether LilyPond
>was successful unless you checked the PDF's modification date) or
>trying
>to leave behind an invalid PDF file (in which case you need to call a
>PDF verification program in order to figure out whether there was an
>error).
>
>Also, some runs of LilyPond may produce a PDF with a different name or
>indeed no PDF at all (you can run LilyPond for indexing purposes or
>information gathering and a number of other things).
>
>> Based on this it means one can have blocks of text as comments or
>> documentation with no syntax, happily ignore the error, and have a
>> nice new way of annotating lilypoind source code files. I hope people
>> can see that this is clearly absurd.
>
>It is not LilyPond's task to make it harder for people to ignore errors
>when they really try hard.
>
>> It’s the FATAL error message that I am questioning. That terminology
>> in my IT world means the program cannot go on. It’s a simply
>> confusing. adjective. One could say given the behaviour that it
>should
>> be a warning.
>
>A warning is appropriate for something which is not an error: namely
>LilyPond has a well-specified task but the results will not likely make
>sense.  LilyPond does not return an error code for a warning.

Well, then let LilyPond report an error when it encounters one. But only then a 
"fatal" one when it actually forces LilyPond to stop.

It is in no way a fatal error to have \version "2.19.39" in a file and compile 
it with 2.19.38. It just exposes a *certain* risk of problems.

>
>-- 
>David Kastrup
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Tuplet number direction

[David Kastrup]

David Wright  writes:

> On Fri 15 Apr 2016 at 10:23:55 (+0200), David Kastrup wrote:
>> 
>> Which would usually involve triplet brackets rather than hacking this
>> into partial note values at measure boundaries.  Which is how it was
>> done in the score I have been singing this from.
>
> Surely only two bars for each triplet, with three instances
> (naturally, because three was the whole point of the exercise).

It was 3 notes per 4 or even 8 bars.

> The triplets don't add any complications that aren't present
> already, ie if you want add barlines, you will get partial notes
> requiring ties all over.

Problem we were talking about were line breaks across tuplet markings
(brackets or slurs).

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error behaviour

[David Kastrup]

Andrew Bernard  writes:

> If you look at the MWE example I provided to illustrate what I believe
> is misleading information about a ‘FATAL’ error, then it has plain
> text which it ignores, claims a fatal error and proceeds to make a
> perfectly good PDF.

LilyPond wouldn't know that, and in any way it returns an ERROR message
and an ERROR code.

I don't know why you are obsessed about LilyPond not touching the PDF
(in which case you still would not have an idea about whether LilyPond
was successful unless you checked the PDF's modification date) or trying
to leave behind an invalid PDF file (in which case you need to call a
PDF verification program in order to figure out whether there was an
error).

Also, some runs of LilyPond may produce a PDF with a different name or
indeed no PDF at all (you can run LilyPond for indexing purposes or
information gathering and a number of other things).

> Based on this it means one can have blocks of text as comments or
> documentation with no syntax, happily ignore the error, and have a
> nice new way of annotating lilypoind source code files. I hope people
> can see that this is clearly absurd.

It is not LilyPond's task to make it harder for people to ignore errors
when they really try hard.

> It’s the FATAL error message that I am questioning. That terminology
> in my IT world means the program cannot go on. It’s a simply
> confusing. adjective. One could say given the behaviour that it should
> be a warning.

A warning is appropriate for something which is not an error: namely
LilyPond has a well-specified task but the results will not likely make
sense.  LilyPond does not return an error code for a warning.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user