Re: Lilypond error behaviour

[David Kastrup]

Thomas Morley  writes:

> Anyone, with an example for an _immediate_ abort?

toplevel-score-handler = "bad"

\score {
  {
c1
  }
  \layout { }
}

#(display "not reached")


-- 
David Kastrup

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

Re: Lilypond error behaviour

[Thomas Morley]

2016-04-19 23:28 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>>> just turn on
>>> warning-as-error and be done with it.
>>
>> As I wrote days ago ...
>
> We could implement an option for the maximum number of non-fatal errors
> before abort.  People who really do not want to have LilyPond continue
> after an error can then set it to zero.

Wouldn't setting to zero be the same as our current warning-as-error?


As a side-note, during this thread I continuosly tried to force
LilyPond to abort _immediately_.

Even for:

\version "1.2.3"

\book { \score { { c''1 } } }
\book { \score { { \set Score.fontSize = #(/ 4 0) dis''1 } } }
\book { \score { { c''1.2 } } }
\book { \score { { e''5 } } }
\book { \score { { cs''1 } } }
\book { \score { { dis''1 } } }

LilyPond continues, trying to compile each book after the other.

The only way I've found was to throw (ly:error ...) somewhere or using
warning-as-error.

Anyone, with an example for an _immediate_ abort?

Cheers,
  Harm

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

Re: Lilypond error behaviour

[Kieren MacMillan]

Hi Martin,

> Doesn't anyone think this is a ridiculously long thread for such a minor 
> problem?

1. Your post answers your own question, doesn’t it?  ;)

2. cf. David K’s mention of “bike-shedding” (which, I have to admit, I didn’t 
know about until I searched it on the web).

Best,
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]

Sharon Rosner  writes:

>> More exactly, LilyPond's task is to read a LilyPond input file and
>> process its contained expression according to the setting of hook
>> variables (those may do something other than typesetting, for example
>> converting to a MusicXML expression and writing it out again).  Some
>> processing may result in files being generated (including PDF files).
>> But the generation of PDF files is a side effect.  It does not have a
>> relation to the occurence of errors.
>
> OK, I think I finally get it. But then why are the errors classified
> as “fatal”?

Because LilyPond was unable to make sense of the input and just
attempted some kind of error recovery in order to carry on.  When you
have a file needing an hour of processing, you don't really want to have
LilyPond abort for trivial errors like misspelling gis as giss even
though LilyPond knows that it cannot offer a PDF file in complete
correspondence with the input.

> Is it only so that the exit code would be non-zero?

That is one consequence.

> Is this the difference between fatal and non-fatal errors? If so,
> maybe a better term could be used?

A non-fatal error is one where LilyPond continues processing.  At the
end of LilyPond's processing, a fatal error is raised summarily when any
non-fatal error occured.

One could change this to a normal message to shut people up, but the
message would still need to make very clear that LilyPond was not able
to successfully process the input, and of course there must be an exit
status signifying an error.

In short, nothing would change apart possibly from the output to the
terminal, and the output to the terminal should still at the very bottom
indicate an error that made it unable for LilyPond to consider the run
successful.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[Sharon Rosner]

> It would be a little less futile, if people would try harder to read
> and to understand what was written and think about it.
> Really no reason for a flame-war.

That was not my intention, and I tried really hard to think about this problem. 
Call me slow :-)

Sharon


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

Re: Lilypond error behaviour

[Sharon Rosner]

> More exactly, LilyPond's task is to read a LilyPond input file and
> process its contained expression according to the setting of hook
> variables (those may do something other than typesetting, for example
> converting to a MusicXML expression and writing it out again).  Some
> processing may result in files being generated (including PDF files).
> But the generation of PDF files is a side effect.  It does not have a
> relation to the occurence of errors.

OK, I think I finally get it. But then why are the errors classified as 
“fatal”? Is it only so that the exit code would be non-zero? Is this the 
difference between fatal and non-fatal errors? If so, maybe a better term could 
be used?

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

Re: Lilypond error behaviour

[David Kastrup]

Thomas Morley  writes:

>> just turn on
>> warning-as-error and be done with it.
>
> As I wrote days ago ...

We could implement an option for the maximum number of non-fatal errors
before abort.  People who really do not want to have LilyPond continue
after an error can then set it to zero.

The problem is that there are situations where LilyPond is called with
hundreds of files, and such a hard immediate abort does not leave the
lexer/parser/inputstack in a predictable state, so one would have to
abort processing all files on the command line.

Which may be particularly tricky in connection with the
-djob-count=... option since the control job would presumably have to
kill all other jobs asynchronously which _indeed_ leaves the output
files (including the log files) in undefined state.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[Martin Tarenskeen]

Doesn't anyone think this is a ridiculously long thread for such a minor 
problem?


--

MT


___
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:

>> What's wrong with the exit code?  I thought people rather complained
>> about the error message.
>
> For the given examples, the non-zero exit code signifies failure, when
> lilypond has actually completed its task - generating a PDF -
> successfully.

Uh, LilyPond was not tasked with generating "a PDF" but rather a PDF
_corresponding_ to the input (not just loosely inspired by it).  It did
not complete this task successfully.

The antithesis is the file

{ }

which is a valid LilyPond file processed successfully without generating
any PDF file.

More exactly, LilyPond's task is to read a LilyPond input file and
process its contained expression according to the setting of hook
variables (those may do something other than typesetting, for example
converting to a MusicXML expression and writing it out again).  Some
processing may result in files being generated (including PDF files).
But the generation of PDF files is a side effect.  It does not have a
relation to the occurence of errors.

> And this goes hand in hand with the misleading message “fatal error”,
> when in fact Lilypond has reported the syntax errors and merrily
> continued both parsing the input file and generating the output.

> So which was it, failure or success?

Failure.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[Thomas Morley]

2016-04-19 22:41 GMT+02:00 Sharon Rosner :
>> Now it appears that there are people who want to change that
>> because they want to add some sort of post-processing by machine
>> (embedding LP in Makefiles, or into a server), or even just the
>> imposition of some tidier design principle that has nothing
>> to do with printing music.
>
> Lilypond's handling of errors is fine. It's just the reporting of errors
> that's not.

Btw,
have a look into lily.scm
Near the end of
(define-public (lilypond-main files) ...
you'll find:
(if (pair? failed)
(begin (ly:error (_ "failed files: ~S") (string-join failed))
   (ly:exit 1 #f))
(begin
  (ly:exit 0 #f)

comment (ly:error ...
And the otherwise all present "Fatal error ..." message will disappear.
Instead you'll get:
"warning: Compilation completed with warnings or errors"

"Compilation completed" doesn't say anything about success or the kind
of errors, though.

Ofcourse other consquences may happen, you'll have to try it out.

>
>> I think I'll risk making you uncomfortable in order to argue
>> against arbitrary non-generation (or deletion) of PDF output.
>> Sorry.
>
> Again, it's rather the exit code, not the presence or absence of PDF's.
>
> On a more general note, I think it's a real shame that whenever someone
> wants to build any kind of tooling around lilypond, some "people" here get
> into bunker mode. Lilypond is great, yes, but it could be improved, you
> know...

I'm also irritated. Why should there a contrast while LilyPond is used
by programmers/developers and non-programmers?

If LilyPond syntax is obfuscated by more and more cryptic things, only
understandable for experienced programmers, yes, then we have a
problem - this probably is the reason for concerns mentioned by some
participiants here.
I don't think this is the case up to now, more correct is the opposite, imho

> Andrew, if you're still reading this futile exchange,

It would be a little less futile, if people would try harder to read
and to understand what was written and think about it.
Really no reason for a flame-war.

> just turn on
> warning-as-error and be done with it.

As I wrote days ago ...

>
> Sharon


Cheers,
  Harm

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

Re: Lilypond error behaviour

[Sharon Rosner]

> What's wrong with the exit code?  I thought people rather complained
> about the error message.

For the given examples, the non-zero exit code signifies failure, when lilypond 
has actually completed its task - generating a PDF - successfully. And this 
goes hand in hand with the misleading message “fatal error”, when in fact 
Lilypond has reported the syntax errors and merrily continued both parsing the 
input file and generating the output.

So which was it, failure or success?

Sharon
___
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:

>> Now it appears that there are people who want to change that
>> because they want to add some sort of post-processing by machine
>> (embedding LP in Makefiles, or into a server), or even just the
>> imposition of some tidier design principle that has nothing
>> to do with printing music.
>
> Lilypond's handling of errors is fine. It's just the reporting of errors
> that's not.
>
>> I think I'll risk making you uncomfortable in order to argue 
>> against arbitrary non-generation (or deletion) of PDF output. 
>> Sorry.
>
> Again, it's rather the exit code, not the presence or absence of
> PDF's.

What's wrong with the exit code?  I thought people rather complained
about the error message.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[Sharon Rosner]

> Now it appears that there are people who want to change that
> because they want to add some sort of post-processing by machine
> (embedding LP in Makefiles, or into a server), or even just the
> imposition of some tidier design principle that has nothing
> to do with printing music.

Lilypond's handling of errors is fine. It's just the reporting of errors
that's not.

> I think I'll risk making you uncomfortable in order to argue 
> against arbitrary non-generation (or deletion) of PDF output. 
> Sorry.

Again, it's rather the exit code, not the presence or absence of PDF's.

On a more general note, I think it's a real shame that whenever someone
wants to build any kind of tooling around lilypond, some "people" here get
into bunker mode. Lilypond is great, yes, but it could be improved, you
know...

Andrew, if you're still reading this futile exchange, just turn on
warning-as-error and be done with it.

Sharon



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lilypond-error-behaviour-tp189622p189776.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

Re: Lilypond error behaviour

[David Kastrup]

Stephan Neuhaus  writes:

> On 2016-04-19 17:54, Tim Reeves wrote:
>> Maybe they should be called "mortally-wounding" errors? :)
>
> This is an excellent suggestion. Perhaps we could implement that further
> output from Lilypond becomes more and more incoherent as the poison sets
> in? And finally, the pain is too much to bear and Lilypond gives up.

Except that in case of syntax errors, LilyPond "gives up" when it was
going to finish anyway.  If it has further files to process, it will
tackle them first.  Basically it just announces in this manner that it
will quit with non-zero exit code _now_ that it has nothing more to do.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[David Wright]

On Tue 19 Apr 2016 at 13:22:50 (+0200), Stephan Neuhaus wrote:
> On 2016-04-18 20:29, David Wright wrote:
> >That begs the question. How do you define "clearly malformed input."
> >If it is malformed, it can't be clear.
> >
> >Of course, if you mean "clearly-malformed", then I contest this
> >vehemently.
> 
> I think I was precise enough.

Yes, the fault was with me. I failed to guess whether you meant
"clearly-malformed input" or "clearly malformed-input" and so
I tried to cover both possibilities in turn. It's just a case of
"man eating tiger".

> But I must say that I don't feel comfortable with the tone of this
> discussion, so I will, with respect, bow out of it.

I've felt comfortable using LP for nine years and, until this thread,
hadn't given much thought to how errors are treated. I was more
concerned about "mistakes" in specifying what I wanted and got.
LP is great because you can work on mistakes even before all the
errors have been eliminated. That really helps when you're working
to tight deadlines.

Now it appears that there are people who want to change that
because they want to add some sort of post-processing by machine
(embedding LP in Makefiles, or into a server), or even just the
imposition of some tidier design principle that has nothing
to do with printing music.

I think I'll risk making you uncomfortable in order to argue
against arbitrary non-generation (or deletion) of PDF output.
Sorry.

Cheers,
David.

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

Re: Lilypond error behaviour

[Stephan Neuhaus]

On 2016-04-19 17:54, Tim Reeves wrote:
> Maybe they should be called "mortally-wounding" errors? :)

This is an excellent suggestion. Perhaps we could implement that further
output from Lilypond becomes more and more incoherent as the poison sets
in? And finally, the pain is too much to bear and Lilypond gives up.

Something like this:

$ lilypond playground/error.ly
GNU LilyPond 2.19.37
Processing `/tmp/lyp/wrappers/error.ly'
Happily parsing...
/Users/sharon/playground/error.ly:1:3: aargh! they got me, the bastards!
/Users/sharon/playground/error.ly:1:3 error: unrecognized string, not in
text script or \lyricmode
{
  bork }
/tmp/lyp/wrappers/error.ly:1: warning: no ... \version ... statement
found, please ... oh god, do I have to go through with this?
/tmp/lyp/wrappers/error.ly:1: dammit, add

\version "2.19.37"

for future compa... ti... bility
Interpreting ... music... though ... it's ... hard ...
Ah crap, I've had it. Tell George he can keep the horse.
Fly, you fools!
$

Fun,

Stephan
-- 
GPG key ID 4BDA81D3
fingerprint 5F88 399F 8811 72BE B36A  FC93 4D13 FCB2 4BDA 81D3

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

Re: Lilypond error behaviour

[Johannes Waldmann]

Peter Gentry wrote:

> ... how the heck does the code know what your intentions are
> and what is an "error" in your source.

(wearing my professional hat for a moment)

in the programing languages I use and teach, the answer is:

"from static type declarations".

I declare types of identifiers exactly
for the purpose of documenting my intentions.
Then the compiler *can* figure out
whether my source corresponds to these intentions.
This gives me machine-checked documentation.
What more could we hope for? ..

In lilypond, bar checks is one such way of documenting an intention,
and have it machine-checked (at run-time, but nevertheless).
I can easily imagine more here, e.g.,
specify the total length of a music expression,
or that music expressions (inside << .. >>) should have equal lengths.

- J.W.

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

Re: Lilypond error behaviour

[Tim Reeves]

> Message: 4
> Date: Tue, 19 Apr 2016 01:48:17 -0500 (CDT)
> From: msk...@ansuz.sooke.bc.ca
> To: Noeck 
> Cc: lilypond-user@gnu.org
> Subject: Re: Lilypond error behaviour
> Message-ID:
>
> Content-Type: text/plain; charset=US-ASCII
> 
> On Tue, 19 Apr 2016, Noeck wrote:
> > think that is what confuses most people here. The error was non-fatal
> > but still after everything is done, an additional fatal error is 
raised
> > to draw attention to previous non-fatal errors.
> 
> Those are fatal errors.  They kill the program.  They're just not
> instantly fatal.
> 
> -- 
> Matthew Skala
> msk...@ansuz.sooke.bc.ca People before principles.
> http://ansuz.sooke.bc.ca/
> 


Maybe they should be called "mortally-wounding" errors? :)

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

Re: Lilypond error behaviour

[Sharon Rosner]

> The non-fatal errors are re-raised as a fatal error after the pdf is
> produced just to alert the user in the end that there were errors. And I
> think that is what confuses most people here. The error was non-fatal
> but still after everything is done, an additional fatal error is raised
> to draw attention to previous non-fatal errors.

I understand, but to me this does not make sense. If the error was not
fatal, and lilypond has indeed continued processing the file and producing
the output, then what's the point of raising a fatal error? As I wrote
before, according to the docs a fatal error is defined as follows:
"Something is definitely wrong, and LilyPond cannot continue." Do you see
the contradiction here?

And I'd add that if Lilypond has indeed succeeded in rendering the bad input
file, and has clearly displayed syntax errors and their location on stderr,
why should it exit with an error code? Doesn't the user already have enough
diagnostics?

There's also the issue I demonstrated with the warning-as-error option,
which causes further confusion, since it makes the normal non-fatal syntax
errors into *real* fatal errors, which cause lilypond to exit immediately
upon a syntax error, even though its stated function is to convert warnings
into errors. However, looking at the docs I found this (
http://lilypond.org/doc/v2.19/Documentation/contributor/warnings-errors-progress-and-debug-output.html
<http://lilypond.org/doc/v2.19/Documentation/contributor/warnings-errors-progress-and-debug-output.html>
 
):

"The error functions come in three different flavors: fatal error messages,
programming error messages and normal error messages. Errors written by the
error () function will cause LilyPond to exit immediately, errors by
Input::error () will continue the compilation, but return a non-zero return
value of the LilyPond call (i.e. indicate an unsuccessful program
execution). All other errors will be printed on the console, but not exit
LilyPond or indicate an unsuccessful return code. Their only differences to
a warnings are the displayed text and that they will be shown with loglevel
ERROR.

"If the Scheme option warning-as-error is set, any warning will be treated
as if Input::error was called."

So it's clear why warning-as-error has the effect it does. I'm sorry but the
current behaviour to me seems incoherent - it mixes warnings with errors,
and success with failure.

Sharon



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lilypond-error-behaviour-tp189622p189748.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

Re: Lilypond error behaviour

[Stephan Neuhaus]

On 2016-04-18 20:29, David Wright wrote:

That begs the question. How do you define "clearly malformed input."
If it is malformed, it can't be clear.

Of course, if you mean "clearly-malformed", then I contest this
vehemently.


I think I was precise enough.

But I must say that I don't feel comfortable with the tone of this 
discussion, so I will, with respect, bow out of it.


Fun,

Stephan

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

Re: Lilypond error behaviour

[David Kastrup]

Thomas Morley  writes:

> 2016-04-19 8:48 GMT+02:00  :
>> On Tue, 19 Apr 2016, Noeck wrote:
>>> think that is what confuses most people here. The error was non-fatal
>>> but still after everything is done, an additional fatal error is raised
>>> to draw attention to previous non-fatal errors.
>>
>> Those are fatal errors.  They kill the program.  They're just not
>> instantly fatal.
>
>
>
> My thesis was that even a non_fatal_error will be turned into a fatal
> for alerting purpose finally.
> See:
> \version "1.2.3"
> { c''1 }
>
> According to the lexer it's a "non_fatal_error" (and correctly
> reported in the log), but turned into a fatal later.
>
> If I'm wrong here I'd love to be corrected.

I don't think that it's the non_fatal_error per se that is turned into a
fatal error, but rather syntax errors specifically (at least the lexer
has a flag for keeping track of syntax errors).  At least that's what I
seem to remember.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[mskala]

On Tue, 19 Apr 2016, Thomas Morley wrote:
> My thesis was that even a non_fatal_error will be turned into a fatal
> for alerting purpose finally.

Yes.  Mine was that such an error is fatal by definition, even if
misleadingly called "non-fatal."

-- 
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

[Thomas Morley]

2016-04-19 8:48 GMT+02:00  :
> On Tue, 19 Apr 2016, Noeck wrote:
>> think that is what confuses most people here. The error was non-fatal
>> but still after everything is done, an additional fatal error is raised
>> to draw attention to previous non-fatal errors.
>
> Those are fatal errors.  They kill the program.  They're just not
> instantly fatal.



My thesis was that even a non_fatal_error will be turned into a fatal
for alerting purpose finally.
See:
\version "1.2.3"
{ c''1 }

According to the lexer it's a "non_fatal_error" (and correctly
reported in the log), but turned into a fatal later.

If I'm wrong here I'd love to be corrected.

Cheers,
  Harm

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

Re: Lilypond error behaviour

[mskala]

On Tue, 19 Apr 2016, Noeck wrote:
> think that is what confuses most people here. The error was non-fatal
> but still after everything is done, an additional fatal error is raised
> to draw attention to previous non-fatal errors.

Those are fatal errors.  They kill the program.  They're just not
instantly fatal.

-- 
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

[Noeck]

Hi Sharon,

Thomas Morley explained it to me rather well in another branch of this
thread:
https://www.mail-archive.com/lilypond-user@gnu.org/msg111048.html

The non-fatal errors are re-raised as a fatal error after the pdf is
produced just to alert the user in the end that there were errors. And I
think that is what confuses most people here. The error was non-fatal
but still after everything is done, an additional fatal error is raised
to draw attention to previous non-fatal errors.

Cheers,
Joram

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

Re: Lilypond error behaviour

[Sharon Rosner]

> And how many *programmers* actually bother to check compilation logs and fix 
> problems that are thrown up? If you want strict error handling then add a 
> --werror option to lilypond that just says "crash on error and let make 
> handle it", then those people using make can deal with the lack of debug info 
> their way.

OK, if I use the -dwarning-as-error option with the example I gave previously, 
lilypond will abort and not create a PDF file. From the docs 
(http://lilypond.org/doc/v2.18/Documentation/usage/command_002dline-usage.en.html
 
):

"warning-as-error   #f  Change all warning and ‘programming error’ 
messages into errors."

So the warning-as-error option causes fatal errors to really behave like fatal 
errors. What does this have to do with warnings exactly?

Then there’s this page 
(http://lilypond.org/doc/v2.19/Documentation/usage/error-messages 
):

"Error: Something is definitely wrong. The current processing step (parsing, 
interpreting, or formatting) will be finished, but the next step will be 
skipped.”

In the case of a parsing error, the next step would presumably be the engraving?

"Fatal error: Something is definitely wrong, and LilyPond cannot continue. This 
happens rarely. The most usual cause is misinstalled fonts.”

Actually, as we’ve seen, the most usual cause would be a parsing error. And 
contrary to the docs, lilypond does continue, except when given the 
warning-as-error option. That’s pretty incoherent.

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

Re: Lilypond error behaviour

[Sharon Rosner]

> And secondly, to me it seems clear why the error is termed "fatal" - the 
> parser aborted. You don't want a compilation error to return a fatal error to 
> "make" and, because it receives a fatal error, make throws a fatal error and 
> crashes too, do you? The question is WHERE in the stack do we actually trap 
> and handle the error.

No. As I demonstrated, the parser in fact does not abort. It continues 
correctly parsing the rest of the input after encountering the error. So what 
is exactly “fatal” here?

> Lilypond, imho, makes the correct decision FOR THE USER, traps the error, and 
> then turns the incomplete output, from the *crashed* parser, into an 
> incomplete pdf.

Again, these are two separate things. The fact that Lilypond continues 
processing the input is fine. The error reporting to me seems misleading.

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

Re: Lilypond error behaviour

[Anthonys Lists]

On 18/04/2016 22:01, Sharon Rosner wrote:
Lilypond would expectedly complain about line 2, then proceed to put 
together the PDF file and finally exit with a “fatal error”. The PDF 
File would include 2 scores, so that means right after encountering 
the syntax error on line 2, it continued to correctly process line 3. 
So what was it that was fatal about this? Is this a matter of some 
internal implementation details we don’t understand or what? And 
again, how is this any different than a non-fatal error?


Firstly, as a programmer and a musician, I'd say that for lilypond to 
produce whatever output it can is IMPORTANT. A failed pdf is a perfectly 
usable debugging trace - I've used a computer system that, if the 
program failed, it erased any and all changes to open files - which is a 
recipe for frustration when debugging - wtf is the computer deleting my 
debug logs for!, and actually a data integrity nightmare too ... the 
more debugging info I have the better!


And secondly, to me it seems clear why the error is termed "fatal" - the 
parser aborted. You don't want a compilation error to return a fatal 
error to "make" and, because it receives a fatal error, make throws a 
fatal error and crashes too, do you? The question is WHERE in the stack 
do we actually trap and handle the error.


Lilypond, imho, makes the correct decision FOR THE USER, traps the 
error, and then turns the incomplete output, from the *crashed* parser, 
into an incomplete pdf. (Or, in this example, restarts the parser for 
the next score.) A *programmer* (which most lilypond users are *not*), 
wants to handle the problem at the next level up, in "make", but let's 
face it, how many of lilypond's users even know what make *is*?


And how many *programmers* actually bother to check compilation logs and 
fix problems that are thrown up? If you want strict error handling then 
add a --werror option to lilypond that just says "crash on error and let 
make handle it", then those people using make can deal with the lack of 
debug info their way.


But leave it the way it is for those users who never check the logs and 
just look to see if the output looks right. I must admit I fall into 
both camps - when running lily on Windows I only check the log if I have 
a problem. When running it on linux, I run it from konsole so I see all 
the errors and warnings anyway. And being the sort of person I am I tend 
to try to get rid of warnings because I know the result is a more robust 
system.


Cheers,
Wol

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

Re: Lilypond error behaviour

[Sharon Rosner]

>> If compiling the file has failed to such a degree that we are choosing
>> to call it a "fatal error," that means the PDF is *not* suitable for
>> further use.  Conversely, if you think the generated PDF is still
>> useful, then don't call what happened a "fatal error" - it must have
>> really been a warning.
> 
> With that definition, any error that does not terminally destroy the
> computer is not a fatal error since otherwise you can still debug the
> problem.

I for one happen to think that the way lilypond handles syntax errors is 
totally reasonable and actually beneficial to users, but I still don’t get the 
usage of the term “fatal”. Consider the following lilypond input file:

{ a }
b
{ c }

Lilypond would expectedly complain about line 2, then proceed to put together 
the PDF file and finally exit with a “fatal error”. The PDF File would include 
2 scores, so that means right after encountering the syntax error on line 2, it 
continued to correctly process line 3. So what was it that was fatal about 
this? Is this a matter of some internal implementation details we don’t 
understand or what? And again, how is this any different than a non-fatal error?

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

Re: Lilypond error behaviour

[David Wright]

On Mon 18 Apr 2016 at 09:06:47 (+0200), Stephan Neuhaus wrote:
> On 2016-04-17 13:51, Urs Liska wrote:
> >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."
> 
> Coming at this discussion rather late, and also from a totally
> different angle, I'd like to make the (slightly off-topic) point
> that I don't think that it's a good idea to make it a design
> principle that Lilypond should try to render even clearly malformed
> input.

That begs the question. How do you define "clearly malformed input."
If it is malformed, it can't be clear.

Of course, if you mean "clearly-malformed", then I contest this
vehemently. LP has a complicated syntax, and scores have complicated
structures. But often, one's next score has close similarities with
some previous one, so I often hack an old score into the new one.
I'll leave the old lyrics to start with (to spread the notes
realistically) while I type in new notes, and cut and paste any
useful lyrics I can find without bothering to hyphenate them at first.

So there'll be several LP runs of what's clearly rubbish while I check
my work so far for things like syntax, missing durations, correct
octavation, etc. I do not want to be deprived of this facility by
some misguided attempts to protect some users from their folly.

> (Note that I'm not saying that it is a happy coincidence that
> Lilypond does, in fact, do this.  It's great for debugging, as I can
> attest.  All I'm saying is that it would be a bad idea for users to
> rely on this behaviour, and for Lilypond developers to embrace it as
> a design principle.)
> 
> We have seen in HTML how malformed input quickly becomes the norm
> and how browser vendors are unable to back out of supporting it.

You're carrying the analogy too far. No one has suggested that LP
has to interpret its language differently, nor that PDF viewers
of MIDI players have to be made to support idiosyncratic output files
written by LP.

> (Just try to validate almost any web page that claims to be HTML
> 4.01 and you'll see what I mean.) The result is that render engines
> are much slower and much buggier than they need to be, because they
> have tons of exceptions for stuff that isn't really HTML but where
> the blame would ultimately fall on the browser if it didn't render
> properly.

On the contrary, LP having to take a rigorous approach to classifying
errors in its input could (possibly) slow it down, and it's also
possible to foresee bugs where an accidental misclassification makes
it censure and consequently censor some output unnecessarily.

> (I'm not saying that I advocate browsers refusing to render
> something that is almost, but not quite, entirely unlike HTML.  I'm
> just saying that once you go down that rabbit hole, you won't come
> back up in a hurry.)
> 
> Personally, I like the idea of Lilypond clearly saying to the user
> that there is something wrong with the input file.

It does. Not always clearly, as discussed above. It can't divine
the user's intent.

> If that "modal
> dialog" went away, users would simply look at the output file and
> conclude that their input must have been OK. Having a clear and
> unambiguous message (even if there is debate about the use of the
> word "fatal") that _there is something wrong with the input file_
> frees Lilypond developers to extend and otherwise develop Lilypond
> without the burden of having to support wrong but entrenched usage.

This would indicate that you're using a GUI of some sort to run LP.
If you have a GUI-oriented program, then a GUI interface is likely the
right approach. But LP is not a GUI program, it's a music processing
program (cf MS Word versus LaTeX), and benefits from having a console
for error messages.

I assume you *do* have a console for error and informational messages.
I would think that determining whether a modal dialog window has been
mapped, and what its contents are, is a harder proposition for make
users and server writers than parsing the output on the console.

However, parsing the console output is what they seem to be
complaining about, and a desire to 

Re: Lilypond error behaviour

[mskala]

On Mon, 18 Apr 2016, David Kastrup wrote:
> msk...@ansuz.sooke.bc.ca writes:
> > If compiling the file has failed to such a degree that we are choosing
> > to call it a "fatal error," that means the PDF is *not* suitable for
> > further use.  Conversely, if you think the generated PDF is still
> > useful, then don't call what happened a "fatal error" - it must have
> > really been a warning.
>
> With that definition, any error that does not terminally destroy the
> computer is not a fatal error since otherwise you can still debug the
> problem.

That is not true.

-- 
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

[David Kastrup]

msk...@ansuz.sooke.bc.ca writes:

> On Mon, 18 Apr 2016, David Wright wrote:
>> may be a decision that a machine can make, but whether a PDF is
>> suitable for further use (to debug the source code, give to a player,
>> or admire on the coffee table) is not.
>
> If compiling the file has failed to such a degree that we are choosing
> to call it a "fatal error," that means the PDF is *not* suitable for
> further use.  Conversely, if you think the generated PDF is still
> useful, then don't call what happened a "fatal error" - it must have
> really been a warning.

With that definition, any error that does not terminally destroy the
computer is not a fatal error since otherwise you can still debug the
problem.

While this definition has something going for it, its usefulness for
LilyPond may be limited.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[mskala]

On Mon, 18 Apr 2016, David Wright wrote:
> may be a decision that a machine can make, but whether a PDF is
> suitable for further use (to debug the source code, give to a player,
> or admire on the coffee table) is not.

If compiling the file has failed to such a degree that we are choosing to
call it a "fatal error," that means the PDF is *not* suitable for further
use.  Conversely, if you think the generated PDF is still useful, then don't
call what happened a "fatal error" - it must have really been a warning.

-- 
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

[David Wright]

On Mon 18 Apr 2016 at 03:23:31 (-0500), msk...@ansuz.sooke.bc.ca wrote:
> On Mon, 18 Apr 2016, Sharon Rosner wrote:
> > I’m not saying that lilypond’s behaviour is necessarily wrong. I’m just
> > trying to point out, like others have, that the term “fatal error” would
> > normally mean that the program was unable to continue processing.
> 
> I run Lilypond in Make, like a compiler, and I wish it would handle errors
> the way compilers do.  That means:  a fatal error is one that prevents it
> from *finishing* processing.  The program might not necessarily stop
> instantly upon detecting a fatal error - most compilers will attempt to
> press ahead in order to be able to provide more information about this or
> other errors - but once a fatal error has been detected, it's known that
> there will not be a successful completion.  Much like the meaning of the
> word "fatal" outside computing:  a fatal wound is one that will kill you
> eventually.  You might not be dead yet, when you have suffered a fatal wound.
> 
> Working like a compiler also means that if a fatal error occurs, the file
> that failed is not written.  If it had been partially written before
> then, it is *deleted*.  Not patched up to look sort of okay.  Deleting it
> is important so that Make, and other build tools, can correctly
> distinguish the bad file from a correct one.

So satisfyling your "make" is more important that my chance to eyeball
the (possibly a) mess that I have created?

> Returning an "error" exit
> code is important too, but does not serve the same purpose, because it
> only notifies the parent process, not future tools looking at the files
> left behind.
> 
> Fortunately, Make will unless configured otherwise delete the bad file
> itself anyway, instead of depending on a broken compiler to do so.  But
> the compiler that doesn't clean up its own mess, *is* broken.

Let's not lose sight of the fact that LP is a music notation program,
not a compiler. Whether an object file is in a fit state to be linked
may be a decision that a machine can make, but whether a PDF is
suitable for further use (to debug the source code, give to a player,
or admire on the coffee table) is not.

Cheers,
David.

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

Re: Lilypond error behaviour

[Johannes Waldmann]

> > ... since this is a regular source of confusion,

> You are the first to have complained.

This is similar, I think:

http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00282.html

- J.W.

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

Re: Lilypond error behaviour

[mskala]

On Mon, 18 Apr 2016, Sharon Rosner wrote:
> I’m not saying that lilypond’s behaviour is necessarily wrong. I’m just
> trying to point out, like others have, that the term “fatal error” would
> normally mean that the program was unable to continue processing.

I run Lilypond in Make, like a compiler, and I wish it would handle errors
the way compilers do.  That means:  a fatal error is one that prevents it
from *finishing* processing.  The program might not necessarily stop
instantly upon detecting a fatal error - most compilers will attempt to
press ahead in order to be able to provide more information about this or
other errors - but once a fatal error has been detected, it's known that
there will not be a successful completion.  Much like the meaning of the
word "fatal" outside computing:  a fatal wound is one that will kill you
eventually.  You might not be dead yet, when you have suffered a fatal wound.

Working like a compiler also means that if a fatal error occurs, the file
that failed is not written.  If it had been partially written before
then, it is *deleted*.  Not patched up to look sort of okay.  Deleting it
is important so that Make, and other build tools, can correctly
distinguish the bad file from a correct one.  Returning an "error" exit
code is important too, but does not serve the same purpose, because it
only notifies the parent process, not future tools looking at the files
left behind.

Fortunately, Make will unless configured otherwise delete the bad file
itself anyway, instead of depending on a broken compiler to do so.  But
the compiler that doesn't clean up its own mess, *is* broken.

-- 
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

[Noeck]

Thanks Thomas,

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

Ok, that's good.

> 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.

Ok, then why is this 3. called fatal? Wouldn't it make sense to tell the
user at the end: severe (a) error(s) occured and exit with a non-zero
exit code? But not call it a failed file or fatal?

>> nothing was produced
> 
> Doesn't work for multi-file-compilation.

My expectation would be that the worst error wins (and I realize that
this differs from what I wrote before). So, it is fatal if any output
could not be produced and it has a severe error if any severe error occured.
I don't know if that's possible but it seems likely to me.

> So, how to do it reasonable different?

As above: Call the rethrown 'fatal error' (3) 'severe error'.

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 22:16 schrieb David Kastrup:
> We are not talking about "nothing was produced" since LilyPond can't
> change the past.  

will be

> 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."

No.

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

Re: Lilypond error behaviour

[Sharon Rosner]

>> 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.

As previously shown, a sample file with the content:

{ bork }

Will lead to the following output:

$ lilypond playground/error.ly
GNU LilyPond 2.19.37
Processing `/tmp/lyp/wrappers/error.ly'
Parsing...
/Users/sharon/playground/error.ly:1:3: error: unrecognized string, not in text 
script or \lyricmode
{ 
  bork }
/tmp/lyp/wrappers/error.ly:1: warning: no \version statement found, please add

\version "2.19.37"

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

Note that the "fatal error" message appears only at the end after lilypond has 
finished processing, and has created a PDF file, so what’s exactly “fatal” 
here? Also, if I understand correctly, lilypond first creates a temporary .ps 
file, then runs gs in order to convert it to a PDF file. If a *fatal* error has 
indeed been encountered while parsing the input file, why does lilypond 
continue with the normal processing sequence? What is the difference then 
between a fatal error and a non-fatal error?

I’m not saying that lilypond’s behaviour is necessarily wrong. I’m just trying 
to point out, like others have, that the term “fatal error” would normally mean 
that the program was unable to continue processing.

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

Re: Lilypond error behaviour

[Stephan Neuhaus]

On 2016-04-17 13:51, Urs Liska wrote:



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."


Coming at this discussion rather late, and also from a totally different 
angle, I'd like to make the (slightly off-topic) point that I don't 
think that it's a good idea to make it a design principle that Lilypond 
should try to render even clearly malformed input.


(Note that I'm not saying that it is a happy coincidence that Lilypond 
does, in fact, do this.  It's great for debugging, as I can attest.  All 
I'm saying is that it would be a bad idea for users to rely on this 
behaviour, and for Lilypond developers to embrace it as a design principle.)


We have seen in HTML how malformed input quickly becomes the norm and 
how browser vendors are unable to back out of supporting it. (Just try 
to validate almost any web page that claims to be HTML 4.01 and you'll 
see what I mean.) The result is that render engines are much slower and 
much buggier than they need to be, because they have tons of exceptions 
for stuff that isn't really HTML but where the blame would ultimately 
fall on the browser if it didn't render properly.


(I'm not saying that I advocate browsers refusing to render something 
that is almost, but not quite, entirely unlike HTML.  I'm just saying 
that once you go down that rabbit hole, you won't come back up in a hurry.)


Personally, I like the idea of Lilypond clearly saying to the user that 
there is something wrong with the input file. If that "modal dialog" 
went away, users would simply look at the output file and conclude that 
their input must have been OK. Having a clear and unambiguous message 
(even if there is debate about the use of the word "fatal") that _there 
is something wrong with the input file_ frees Lilypond developers to 
extend and otherwise develop Lilypond without the burden of having to 
support wrong but entrenched usage.


Fun,

Stephan

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

Re: Lilypond error behaviour

[Thomas Morley]

2016-04-18 1:26 GMT+02:00 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.
>

An example for the same problem in _one_ file:


\version "2.18.2"

\book { \score { { c''1 } } }
\book { #(ly:error "msg") }
\book { \score { { cis''1 } } }

>
> So, how to do it reasonable different?
>
>
> Cheers,
>   Harm

Cheers,
  Harm

___
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: 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

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: 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: 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: 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: 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: 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

Re: Lilypond error behaviour

[Andrew Bernard]

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. 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’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.

Andrew


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

Re: Lilypond error behaviour

[Andrew Bernard]

Hi David,

Unaware of such issue. Can you let me know what mail client you are
using so I can test, so as to avoid this?

Andrew

On 17 April 2016 at 12:29, David Wright  wrote:
> Please can you quote in a way that's visible in text clients,
> not just HTML ones.

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

Re: Lilypond error behaviour

[David Wright]

Please can you quote in a way that's visible in text clients,
not just HTML ones.

On Sat 16 Apr 2016 at 20:42:45 (+1000), Andrew Bernard wrote:
> I have not used any language of complaint, merely observation and puzzlement. 
> It was also not I that mentioned it is a regular source of confusion. Others 
> do seem to think so. As to being the first, I may possibly be the first to 
> write a lilypond compile server where I need to understand clearly the error 
> conditions to get everything working nicely.
> 
> On 16/04/2016, 5:47 PM, "David Kastrup"  wrote:
> 
> Andrew Bernard  writes:
> 
> So gentlemen, since this is a regular source of confusion,
> 
> You are the first to have complained.
> 
> 
> 
> 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).

> But
> for my preference, a serious syntax error which is just outright
> garbage should in my opinion not produce any output. Other types of
> compilers would stop.

Some compilers might stop. For example, a heavily optimising compiler
would be wasting its time. OTOH a checkout compiler would apply a
fixup and carry on compiling to the end.

If a compiler was producing an executable program as its target, then
it would attempt to produce it, but it would be pointless trying to
run it. But you could examine its output (eg the symbol table); yet
for most people, the compiler listing would be sufficient. OTOH LP's
target is a PDF (ignoring other targets) and most people find as much
diagnostic information there as in the messages emitted on the
console. In order to examine a PDF, you need it to be consistent
enough for PDF readers to render it, and that means LP can't just give
up and stop.

LP can also produce multiple targets. Some may be usable in the
presence of errors elsewhere.

Other errors can be tolerated in the "final" output. For example, I
produce many scores with individual lines for singers, but pianists
prefer two staves which I give them. However, I don't bother to
eliminate all the errors that result, and they understand that.

> 
> As does LilyPond.
> 
> But it does not stop. After the syntax error it still produces the output 
> PDF, and states a 'fatal error' happened. Perhaps it could say that 'a syntax 
> occurred but I overall I was able to carry on regardless in this case’ or 
> something to that effect. I thought the common understanding of fatal error 
> means that the program cannot continue processing because of it. I am only 
> talking about the processing of one file here, as per the submitted MWE, not 
> the processing of more than one file on the command line.

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.

Cheers,
David.

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

Re: Lilypond error behaviour

[Noeck]

Hi,

Am 16.04.2016 um 12:52 schrieb Urs Liska:
> There should be *some* sort of order of severity, like "warning",
> "serious error", "fatal error".

Yes. And the wording not only concerns the error itself. But also the
rest of the message. If I compile:

\version "2.19.80"
{ a }

I get a perfectly fine output, but the message reads:
fatal error: failed files: "test.ly"
In this thread we already talked about the fatal (which is exaggerated
here), but also the 'failed' is misleading as the comilation of the file
did not fail, it just had (maybe severe, because unpredictable) errors.

So, I agree with Urs.

Cheers,
Joram

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

Re: Lilypond error behaviour

[Urs Liska]

Am 16.04.2016 um 12:42 schrieb Andrew Bernard:
> I have not used any language of complaint, merely observation and
> puzzlement. It was also not I that mentioned it is a regular source of
> confusion. Others do seem to think so.

It is probably the first time this *specific* issue has been reported.
What is regularly irritating is the terminology of "fatal errors".

> As to being the first, I may possibly be the first to write a lilypond
> compile server where I need to understand clearly the error conditions
> to get everything working nicely.
>
> On 16/04/2016, 5:47 PM, "David Kastrup"  > wrote:
>
> Andrew Bernard  > writes:
>
> So gentlemen, since this is a regular source of confusion,
>
>
> You are the first to have complained.
>
>
>
>
> 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. But
> for my preference, a serious syntax error which is just outright
> garbage should in my opinion not produce any output. Other
> types of
> compilers would stop.
>
>
> As does LilyPond.
>
>
> But it does not stop. After the syntax error it still produces the
> output PDF, and states a 'fatal error' happened. Perhaps it could say
> that 'a syntax occurred but I overall I was able to carry on
> regardless in this case’ or something to that effect. I thought the
> common understanding of fatal error means that the program cannot
> continue processing because of it. I am only talking about the
> processing of one file here, as per the submitted MWE, not the
> processing of more than one file on the command line.

I also find it good that LilyPond continues to work because having the
PDF often helps identifying errors.
But I also find it puzzling that LilyPond reports a "fatal error" and
exits with "failed files:". For example when I use the wrong LilyPond
version compared to the \version statement.
Basically what Andrew suggests above seems right to me. There should be
*some* sort of order of severity, like "warning", "serious error",
"fatal error".

Best
Urs

>
> Andrew
>
>
>
>
> ___
> 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

[Andrew Bernard]

I have not used any language of complaint, merely observation and puzzlement. 
It was also not I that mentioned it is a regular source of confusion. Others do 
seem to think so. As to being the first, I may possibly be the first to write a 
lilypond compile server where I need to understand clearly the error conditions 
to get everything working nicely.

On 16/04/2016, 5:47 PM, "David Kastrup"  wrote:

Andrew Bernard  writes:

So gentlemen, since this is a regular source of confusion,

You are the first to have complained.



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. But
for my preference, a serious syntax error which is just outright
garbage should in my opinion not produce any output. Other types of
compilers would stop.

As does LilyPond.

But it does not stop. After the syntax error it still produces the output PDF, 
and states a 'fatal error' happened. Perhaps it could say that 'a syntax 
occurred but I overall I was able to carry on regardless in this case’ or 
something to that effect. I thought the common understanding of fatal error 
means that the program cannot continue processing because of it. I am only 
talking about the processing of one file here, as per the submitted MWE, not 
the processing of more than one file on the command line.

Andrew



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

Re: Lilypond error behaviour

[Noeck]

The wording 'fatal error' is perhaps a bit strong if a pdf is still
produced. But I always liked it (especially as a beginner) that LilyPond
tries hard to keep on going and produces output if it can, despite
(partially) severe input errors on the user side.

>From my experience, the return code indicates correcty whether there
were errors or not.

Cheers,
Joram

___
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:

> So gentlemen, since this is a regular source of confusion,

You are the first to have complained.

> and it certainly has had me glued up for many days wondering what is
> wrong with my code, should this not be raised as a defect, or at the
> very least the adjetctive ‘fatal’ removed fromt he message, and
> replaced with ‘warning’ or something else?

It is a fatal error in that LilyPond has no idea what you want, and
exits with a fatal error message and an according error state, and
without processing further files on the command line.

I don't see the point in trying to leave a broken PDF file rather than
finishing it.  Some syntax errors are trivial and you want to have a
working PDF file in order to correct as many problems as possible when
every compilation takes half an hour.

> 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. But
> for my preference, a serious syntax error which is just outright
> garbage should in my opinion not produce any output. Other types of
> compilers would stop.

As does LilyPond.

> If there is such an error it neeeds attention, not PDF output I
> reckon.

If you ignore both error messages as well as error status and just go by
the presence of a PDF file and expect LilyPond to not open the PDF file
unless it can guarantee an error-less rest of the run, then you still
will get confused after editing a file badly by LilyPond leaving the old
PDF file around untouched.

-- 
David Kastrup

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

Re: Lilypond error behaviour

[Richard Shann]

On Sat, 2016-04-16 at 12:14 +1000, Andrew Bernard wrote:
> So gentlemen, since this is a regular source of confusion, and it
> certainly has had me glued up for many days wondering what is wrong
> with my code, should this not be raised as a defect, or at the very
> least the adjetctive ‘fatal’ removed fromt he message, and replaced
> with ‘warning’ or something else?
> 
> 
> 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. But
> for my preference, a serious syntax error which is just outright
> garbage should in my opinion not produce any output. Other types of
> compilers would stop. If there is such an error it neeeds attention,
> not PDF output I reckon.

However, the output PDF is often the fastest way of seeing the source
and nature of the trouble. Unlike compiling an executable program where
the output of a broken executable would be counter-productive, you can
often see where it starts to go wrong looking at a PDF. And, indeed,
I've seen many cases where the output PDF is just fine despite LilyPond
not expecting it; useful for those using a front end that don't really
understand the syntax generated.

Richard




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

Re: Lilypond error behaviour

[Andrew Bernard]

So gentlemen, since this is a regular source of confusion, and it certainly has 
had me glued up for many days wondering what is wrong with my code, should this 
not be raised as a defect, or at the very least the adjetctive ‘fatal’ removed 
fromt he message, and replaced with ‘warning’ or something else?

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. But for my preference, a 
serious syntax error which is just outright garbage should in my opinion not 
produce any output. Other types of compilers would stop. If there is such an 
error it neeeds attention, not PDF output I reckon. I think this is best moved 
to the bug list for discussion. I think aberrant behaviour that does not match 
ordinary expectations can fairly be classed as a bug.

Andrew


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

Re: Lilypond error behaviour

[Urs Liska]

Am 15. April 2016 18:50:48 MESZ, schrieb Simon Albrecht 
:
>On 15.04.2016 13:59, Andrew Bernard wrote:
>> Is this expected behaviour? Wouldn’t a complete syntax error stop 
>> processing? What am I missing here? Should I be addressing instead
>the 
>> bug list?
>
>To me, the oddity would be in that Lily speaks of a ‘fatal error’ here.
>
>It’s a policy that Lily should always try to finish processing and 
>return some output instead of just exiting.

This seems related to the regular source of confusion when a version mismatch 
cause a fatal error *and* a file.

Urs

>
>Best, Simon
>
>___
>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: Lilypond error behaviour

[Simon Albrecht]

On 15.04.2016 13:59, Andrew Bernard wrote:
Is this expected behaviour? Wouldn’t a complete syntax error stop 
processing? What am I missing here? Should I be addressing instead the 
bug list?


To me, the oddity would be in that Lily speaks of a ‘fatal error’ here. 
It’s a policy that Lily should always try to finish processing and 
return some output instead of just exiting.


Best, Simon

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

Lilypond error behaviour

[Andrew Bernard]

I am writing a lilypond server to process lilypond source files submitted by a 
client program to avoid the startup costs of lilypond. This is based on an idea 
by Sharon, I think pulled up from past archives, and is a small project Sharon 
and Urs and I are working on experimentally.

In relation to this, an oddity – to me, at least – came up, when dealing with 
errors in source files. If I have a lilypond source as shown in the example 
here, it’s deliberately incorrect, and I would expect lilypond to report a 
fatal error and stop. Instead, this file produces not only a fatal error 
message from lilypond, but also generates a PDF file. Why is the file 
generated? This has me rather confused – I thought my server code was not 
working. The syntax error is reported as fatal not as a warning.

Is this expected behaviour? Wouldn’t a complete syntax error stop processing? 
What am I missing here? Should I be addressing instead the bug list?

Andrew

— snip

file test.ly:
——

\version "2.19.39"

junk syntax error on purpose

{
  c''
}

lilypond output:
——

Processing `test.ly'
Parsing...
test.ly:3:6: error: syntax error, unexpected STRING, expecting '.' or '=' or ','
junk 
 syntax error on purpose
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-kUaRg5'...
Converting to `test.pdf'...
Deleting `/tmp/lilypond-kUaRg5'...
fatal error: failed files: "test.ly"

— snip


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

Re: Help with this lilypond error

[Alexander Kobel]

On 2010-09-17 10:17, Phil Holmes wrote:

- Original Message - From: "peterwinson1" 

JMarc, thank you for the suggestion. Here is the result:  [...]
There is still a problem. The second bar which is the refrain, I want to
move to the bottom of everything. [...]


Peter,

I'm struggling to understand what you mean.   [...]


Hi, Peter,

I do, too, but there's another idea:

\score {
  {   %% <-
\new Staff {
  \key ... \time ...
  \new Voice { ... }
  \addlyrics { ... }
}
\new Staff {
  ...
}
  }   %% <-
}

Note that a score can only contain a single music expression, otherwise 
the syntax is wrong by definition.  You can achieve this by putting 
braces around all the music which should be shown sequentially.
The double angle brackets, however, denote parallel music, with all 
sections starting at the same point in time, which seems not to be what 
you want.



If you want to get that to the end on a line on its
own, why don't you just use a single staff and place the refrain music
at the end? You can start it on a new line with \break.


+1. The most easiest way usually is using this approach and, 
additionally, variables (look in the Learning Manual for details, 
especially the section "Final touches > Organizing pieces with variables"):


stanzaMusic = { ... } %% only notes
stanzaLyrics = \lyricmode { ... }
refMusic = { ... }
refLyrics = \lyricmode { ... }

\score {
  { %% might be needed or not
\new Staff {
  \key ... \time ...
  \new Voice { \stanzaMusic \break \refMusic }
  \addlyrics { \stanzaLyrics \refLyrics }
}
  }
}

or something similar.


HTH,
Alexander

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

Re: Help with this lilypond error

[Phil Holmes]

- Original Message - 
From: "peterwinson1" 

To: 
Sent: Friday, September 17, 2010 6:31 AM
Subject: Re: Help with this lilypond error




JMarc, thank you for the suggestion.  Here is the result:

http://old.nabble.com/file/p29735309/Ye%2Bwho%2Bown%2Bver2.png

There is still a problem.  The second bar which is the refrain, I want to
move to the bottom of everything.  As I understand it, this is the result 
of

<< >>, which puts everything in parrallel.  So how do I do a bar of the
refrain at the bottom of a song?



Peter,

I'm struggling to understand what you mean.  You say "The second bar which 
is the refrain" - do you mean the second (lower) staff in the music you've 
shown?  If you want to get that to the end on a line on its own, why don't 
you just use a single staff and place the refrain music at the end?  You can 
start it on a new line with \break.


If this isn't what you're trying to do, a scan of the original would be 
helpful.


--
Phil Holmes



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

Re: Help with this lilypond error

[peterwinson1]

JMarc, thank you for the suggestion.  Here is the result:

http://old.nabble.com/file/p29735309/Ye%2Bwho%2Bown%2Bver2.png 

There is still a problem.  The second bar which is the refrain, I want to
move to the bottom of everything.  As I understand it, this is the result of
<< >>, which puts everything in parrallel.  So how do I do a bar of the
refrain at the bottom of a song?



Editions IN NOMINE wrote:
> 
>   Well, it seems that you missed the << ... >> stuff : you can't have a 
> staff AFTER lyrics, but you can in parallel...
> So you have to put << before the first \new Staff, and >> before the last
> }
> 
> May I suggest a clearer way to put your code (it is very insolent from 
> me, but that's the way I managed to see where the bug was), such as :
> 
> (...)
> musicI = {\key f \major \time 3/4
>   \partial 4 c'8. c'16 |
>   f'4 f'4 a'8. g'16 |
>   g'4 g'4 bes'8. d''16 |
>   c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
>   f'2 \bar "|"
> 
>   \partial 4 c'8. c'16 |
>   f'4 f'4 a'8. g'16 |
>   g'4 g'4 bes'8. d''16 |
>   c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
>   f'2 \bar "|"
> 
>   \partial 4 a'8. bes'16 |
>   c''4 a'4 c''8. c''16 |
>   bes'4 g'4 bes'8. bes'16  |
>   a'4 f'4 a'8. a'16 |
>   g'2 \bar "|"
>   }
> 
> musicII = {\key f \major \time 3/4
>   \partial 4 s4 |}
> 
> words = \lyricmode {
>  \set stanza = "1. "
>  Ye who own the faith of Je- sus sing the won- ders that were
> done,
>  When the love of God the Fath- er o'er our sin the vic- tory won,
>  When He made the Vir- gin Ma- ry Moth- er of His On- ly Son.
>  }
> 
> 
> 
> \score {
> <<
>   \new Staff {\new Voice = "upper" \musicI}
>   \new Lyrics \lyricsto "upper" \words
>   \new Staff = lower {\musicII}
>  >>
> }
> 
> So the \score{...} part is really clear and the <<...>> quite obvious.
> 
> Best regards !
> 
> JMarc
> 
> On 15/09/2010 17:38, peterwinson1 wrote:
>> \score {
>>  \new Staff {
>>  \key f \major \time 3/4
>>  \new Voice { \voiceOne
>>  \partial 4 c'8. c'16 |
>>  f'4 f'4 a'8. g'16 |
>>  g'4 g'4 bes'8. d''16 |
>>  c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
>>  f'2 \bar "|"
>>  
>>  \partial 4 c'8. c'16 |
>>  f'4 f'4 a'8. g'16 |
>>  g'4 g'4 bes'8. d''16 |
>>  c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
>>  f'2 \bar "|"
>>  
>>  \partial 4 a'8. bes'16 |
>>      c''4 a'4 c''8. c''16 |
>>  bes'4 g'4 bes'8. bes'16  |
>>  a'4 f'4 a'8. a'16 |
>>  g'2 \bar "|"
>>  }
>>  
>>  \addlyrics {
>>  \set stanza = "1. "
>>  Ye who own the faith of Je- sus sing the won- ders that 
>> were done,
>>  When the love of God the Fath- er o'er our sin the vic- 
>> tory won,
>>  When He made the Vir- gin Ma- ry Moth- er of His On- ly 
>> Son.
>>  }
>>  }
>>  
>>  
>>  \new Staff {
>>  }
>> }
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Help-with-this-lilypond-error-tp29719902p29735309.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.


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

Re: Help with this lilypond error

[Éditions IN NOMINE]

 Well, it seems that you missed the << ... >> stuff : you can't have a 
staff AFTER lyrics, but you can in parallel...

So you have to put << before the first \new Staff, and >> before the last }

May I suggest a clearer way to put your code (it is very insolent from 
me, but that's the way I managed to see where the bug was), such as :


(...)
musicI = {\key f \major \time 3/4
 \partial 4 c'8. c'16 |
 f'4 f'4 a'8. g'16 |
 g'4 g'4 bes'8. d''16 |
 c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
 f'2 \bar "|"

 \partial 4 c'8. c'16 |
 f'4 f'4 a'8. g'16 |
 g'4 g'4 bes'8. d''16 |
 c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
 f'2 \bar "|"

 \partial 4 a'8. bes'16 |
 c''4 a'4 c''8. c''16 |
 bes'4 g'4 bes'8. bes'16  |
 a'4 f'4 a'8. a'16 |
 g'2 \bar "|"
 }

musicII = {\key f \major \time 3/4
 \partial 4 s4 |}

words = \lyricmode {
\set stanza = "1. "
Ye who own the faith of Je- sus sing the won- ders that were done,
When the love of God the Fath- er o'er our sin the vic- tory won,
When He made the Vir- gin Ma- ry Moth- er of His On- ly Son.
}



\score {
<<
 \new Staff {\new Voice = "upper" \musicI}
 \new Lyrics \lyricsto "upper" \words
 \new Staff = lower {\musicII}
>>
}

So the \score{...} part is really clear and the <<...>> quite obvious.

Best regards !

JMarc

On 15/09/2010 17:38, peterwinson1 wrote:

\score {
\new Staff {
\key f \major \time 3/4
\new Voice { \voiceOne
\partial 4 c'8. c'16 |
f'4 f'4 a'8. g'16 |
g'4 g'4 bes'8. d''16 |
c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
f'2 \bar "|"

\partial 4 c'8. c'16 |
f'4 f'4 a'8. g'16 |
g'4 g'4 bes'8. d''16 |
c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
f'2 \bar "|"

\partial 4 a'8. bes'16 |
c''4 a'4 c''8. c''16 |
bes'4 g'4 bes'8. bes'16  |
a'4 f'4 a'8. a'16 |
g'2 \bar "|"  
}

\addlyrics {
\set stanza = "1. "
Ye who own the faith of Je- sus sing the won- ders that 
were done,
When the love of God the Fath- er o'er our sin the vic- 
tory won,
When He made the Vir- gin Ma- ry Moth- er of His On- ly 
Son.
}
}


\new Staff {
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Help with this lilypond error

[Phil Holmes]

- Original Message - 
From: "peterwinson1" 

To: 
Sent: Wednesday, September 15, 2010 4:38 PM
Subject: Help with this lilypond error




I am trying to typeset a hymn with a refrain at the bottom.  The music and
the lyrics for the hymn is part of one staff.  The music and lyrics for 
the
refrain is on another staff.  However, when I go to create the second 
staff

Lilypond complains that there is a syntax error at the second \new Staff
command.  Here is my Lilypond file.  Thank you for the help.


[snip code]

If you read the section of the Notation Reference entitled "1.6.1 Displaying 
staves" and then go to "Grouping staves" you will see the staves are 
surrounded with <<  >>.  Try that.


--
Phil Holmes



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

Help with this lilypond error

[peterwinson1]

I am trying to typeset a hymn with a refrain at the bottom.  The music and
the lyrics for the hymn is part of one staff.  The music and lyrics for the
refrain is on another staff.  However, when I go to create the second staff
Lilypond complains that there is a syntax error at the second \new Staff
command.  Here is my Lilypond file.  Thank you for the help.

\version "2.12.3"
#(ly:set-option 'point-and-click #t)

#(set-default-paper-size "statement")

#(set-global-staff-size 15.0)

stemOn = { \override Staff.Stem #'transparent = ##f }
stemOff = { \override Staff.Stem #'transparent = ##t }

\layout { 
indent = #0 
ragged-right = ##f
} 

\paper {
 #(define left-margin (* 0.3 cm))
  between-system-padding = #3.0
  between-system-space = #3.0
  ragged-bottom = ##t
  ragged-last-bottom = ##t
}

\score {
\new Staff { 
\key f \major \time 3/4
\new Voice { \voiceOne  
\partial 4 c'8. c'16 |
f'4 f'4 a'8. g'16 |
g'4 g'4 bes'8. d''16 | 
c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
f'2 \bar "|"

\partial 4 c'8. c'16 | 
f'4 f'4 a'8. g'16 |
g'4 g'4 bes'8. d''16 |
c''4. \autoBeamOff a'8 \autoBeamOn bes'8 g'8 |
f'2 \bar "|"

\partial 4 a'8. bes'16 |
c''4 a'4 c''8. c''16 |
bes'4 g'4 bes'8. bes'16  |
a'4 f'4 a'8. a'16 |
g'2 \bar "|"
}

\addlyrics { 
\set stanza = "1. "
Ye who own the faith of Je- sus sing the won- ders that 
were done, 
        When the love of God the Fath- er o'er our sin the vic- 
tory won,
When He made the Vir- gin Ma- ry Moth- er of His On- ly 
Son.
}
}


\new Staff { 
}
}

-- 
View this message in context: 
http://old.nabble.com/Help-with-this-lilypond-error-tp29719902p29719902.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.


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

Lilypond error on starting for the first time

[Munin]

I just downloaded Lilypond version 2.10.33-1 (upgrading from 2.10.2), and
when I try to typeset files I get an error:

(OSError: [Errno 8] Exec format error)

I'm running Mac OS 10.4.10; Lilypond is in the Applications folder. Any help
would be greatly appreciated.

Thanks,
Brenda GS (er, 'Munin')
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Lilypond error on starting for the first time

[Robert Blackstone]

Opened Lilypond.app 2.8.2-4 for the first time today. 
Saved the opening file, chose Compile > Typeset file , as instructed, 
but received "unexpected" error 
message: "(OSError: [Errno 8] Exec format error)"
What can I do?

Computer: Apple Powerbook G4,  OS 10.4.5 
Lilypond.app dragged to Application folder.
NB I don't know whether the following is of importance: 
Fink is on a separate Firewire harddisk because it 
could not be installed on my powerbook 
("Symlinks not supported on this volume" or something like that.) 



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

Re: Lilypond error for 3 eighth notes

[Graham Percival]

On 11-Feb-06, at 10:59 AM, Ben Fisher wrote:


Thanks for the quick response. Yeah, I was expecting c'4. c'8 d'[ e'].

I tend to agree Nahum, that this is not expected. I'm not an expert on 
these matters but generally expect to see 8th notes only grouped 
together when there is an even number.


You can easily change this behavior; see "Setting automatic beams" (or 
something like that).


- Graham



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

Re: Lilypond error for 3 eighth notes

[Ben Fisher]

Thanks for the quick response. Yeah, I was expecting c'4. c'8 d'[ e'].
I tend to agree Nahum, that this is not expected. I'm not an expert on these matters but generally expect to see 8th notes only grouped together when there is an even number.
I'm not sure what the psychological advantages are to grouping 3 8th notes, to me it looks like triplets at first glance. But if this is the traditional way to do it, then I guess Lilypond is right.
-Ben



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

Re: Lilypond error for 3 eighth notes

[Kris Shaffer]

The grouping which Lilypond chooses by default in this case (as in most  
others) is the standard way of grouping such a figure in common practice  
instrumental music.  In 2/4 and 3/4, any consecutive eighth-notes within a  
measure are typically beamed together (with a few exceptions).   
Incidentally, there are some psychological advantages to following the  
traditional notational practice in this case, as well.  That said, neither  
notation is confusing enough to hinder performance.  All in all, there is  
no right or wrong, but breaking with tradition will not win you anything  
here.  It may even be slightly disadvantageous.



--
Kris Shaffer
graduate student in music theory, Yale University
co-editor-in-chief for music theory, AmSteg.org
www.shaffermusic.com



On Fri, 10 Feb 2006 00:50:40 -0500, Ramana Kumar <[EMAIL PROTECTED]>  
wrote:



would c'4. c'8 d'[ e'] be what you expect? or what?

On 2/10/06, Ben Fisher <[EMAIL PROTECTED]> wrote:


It looks like Lilypond is giving the wrong output here:

{
\time 3/4
c'4. c'8 d' e'
}

The three eighth notes are grouped together. I have no idea why this  
should
happen, because they aren't triplets. If the time signature were 6/8  
then it

might make sense, but otherwise I can't imagine why.

I guess there isn't any "right" or "wrong" way to group 8th notes, but  
this

is a strange choice for the default. I'm using version 2.6.5.1.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user






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



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

Re: Lilypond error for 3 eighth notes

[Ramana Kumar]

would c'4. c'8 d'[ e'] be what you expect? or what?

On 2/10/06, Ben Fisher <[EMAIL PROTECTED]> wrote:
>
> It looks like Lilypond is giving the wrong output here:
>
> {
> \time 3/4
> c'4. c'8 d' e'
> }
>
> The three eighth notes are grouped together. I have no idea why this should
> happen, because they aren't triplets. If the time signature were 6/8 then it
> might make sense, but otherwise I can't imagine why.
>
> I guess there isn't any "right" or "wrong" way to group 8th notes, but this
> is a strange choice for the default. I'm using version 2.6.5.1.
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
>


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

Lilypond error for 3 eighth notes

[Ben Fisher]

It looks like Lilypond is giving the wrong output here:
 
{
\time 3/4
c'4. c'8 d' e'
}
 
The three eighth notes are grouped together. I have no idea why this should happen, because they aren't triplets. If the time signature were 6/8 then it might make sense, but otherwise I can't imagine why.
 
I guess there isn't any "right" or "wrong" way to group 8th notes, but this is a strange choice for the default. I'm using version 2.6.5.1.



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

lilypond error?

[amhso (sent by Nabble.com)]

I am wondering if this error i am getting is the program or me. 

# -*-compilation-*-
Changing working directory to `C:/Documents and Settings/Alex So/Desktop/hungarian rhapsody'
Processing `C:/Documents and Settings/Alex So/Desktop/hungarian rhapsody/hungarianrhapsody.txt'
Parsing...
C:/Program Files/LilyPond/usr/share/lilypond/2.7.27/ly/init.ly:28:0: error: syntax error, unexpected SCM_T

#(if (and (ly:get-option 'old-relative)


I have looked through all my syntax and everything seems correct. I don't understand what is wrong heresomeone explain or give me some help?

View this message in context: lilypond error?
Sent from the Gnu - Lilypond - User forum at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond error

[Han-Wen Nienhuys]

Steve Leyland wrote:
Sorry to be a nuisance guys, but I wonder if you can help?  I've recently set 
up a new desktop machine running Fedora Core 4 and loaded Lilypond version 
2.6.1.  When I try to run the...



it looks like a packaging error in GUILE. Which version/where did you 
get it from?




--
 Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen


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

Re: Lilypond error / Installing on FC4

[Graham Percival]

On 5-Aug-05, at 10:46 AM, Steve Leyland wrote:
GNU LilyPond 2.6.1 /usr/share/guile/1.6/srfi/srfi-13.scm:159:1: In 
procedure
dynamic-link in expression (load-extension 
"libguile-srfi-srfi-13-14-v-1"

"scm_init_srfi_13"):


Gee, FC4 is popular.  :)

Try 2.6.3.  I think the link is up now, but if not, look in the 
directory

http://lilypond.org/download/binaries/Fedora-4/


Cheers,
- Graham



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

Lilypond error

[Steve Leyland]

Sorry to be a nuisance guys, but I wonder if you can help?  I've recently set 
up a new desktop machine running Fedora Core 4 and loaded Lilypond version 
2.6.1.  When I try to run the...

lilypond test

...command to test the system I get the following error...

GNU LilyPond 2.6.1 /usr/share/guile/1.6/srfi/srfi-13.scm:159:1: In procedure 
dynamic-link in expression (load-extension "libguile-srfi-srfi-13-14-v-1" 
"scm_init_srfi_13"):
/usr/share/guile/1.6/srfi/srfi-13.scm:159:1: file: 
"libguile-srfi-srfi-13-14-v-1", message: "libguile-srfi-srfi-13-14-v-1.so: 
cannot open shared object file: No such file or directory"

There is a /usr/share/guile/1.6/srfi directory and I've tried adding this to 
my PATH variable, but it doesn't make a difference.  I've taken a look 
through what I can find on the internet, but I'm struggling now.  Can you 
guys point me in the right direction?

Thanks.
-- 
Best...

Steve


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

Re: LilyPond error

[Mats Bengtsson]

Apparently, you have installed version 2.2.5, but used a version
of the file test.ly that is written for a newer version, 2.4.3.
My best suggestion is to upgrade to version 2.4.x. The alternative
is to keep your current version and read the Tutorial which is
included in the documentation for your current version of the
program (available at www.lilypond.org).
   /Mats
Mardi Girard wrote:
Hello
I'm having trouble getting test.ly to work. My test.log file says
 
/lilypond (GNU LilyPond) 2.2.5
Running lilypond-bin...
Now processing `test.ly'
Parsing.../
// 
//cygdrive/c/Dokumente und Einstellungen/Besitzer/Eigene Dateien/My 
Music/test.ly:3:0: error: syntax error, unexpected '{':/
// 
/{/
// 
//cygdrive/c/Dokumente und Einstellungen/Besitzer/Eigene Dateien/My 
Music/test.ly:4:8: warning: Braces don't match:
  c4(  c
4)
Failed files: test.ly /
// 

/lilypond: error: LilyPond failed on input file test (exit status 1)
lilypond: warning: Running LilyPond failed. Rerun with --verbose for a 
trace.
/
Can you help me? Thank you
Mardi


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
Fax:   (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

LilyPond error

[Mardi Girard]

Hello
I'm having trouble getting test.ly to work. My 
test.log file says
 
lilypond (GNU LilyPond) 2.2.5Running 
lilypond-bin...Now processing `test.ly'Parsing...
 
/cygdrive/c/Dokumente und 
Einstellungen/Besitzer/Eigene Dateien/My Music/test.ly:3:0: error: syntax error, 
unexpected '{':
 
{
 
/cygdrive/c/Dokumente und 
Einstellungen/Besitzer/Eigene Dateien/My Music/test.ly:4:8: warning: Braces 
don't match:  c4(  c    
4)Failed files: test.ly 
 
lilypond: error: LilyPond failed on input file test (exit status 
1)lilypond: warning: Running LilyPond failed. Rerun with --verbose for a 
trace.
Can you help me? Thank you
Mardi
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Lilypond error when opening test.ly

[J Groombridge]

Operating system: W2K

When I click on test.ly to open it, E:\cygwin\bin\bash.exe opens a DOS
window. It says it is processing the file and then I get two "Error
(2): The system cannot find the file specified" errors. I know that you
told me not to change the default directory, but I don't have 204M
available on C: for cygwin.

The batch file creates the .dvi, .pdf, .ps and .log files. Acrobat
opens the .pdf without any problems. Should I just ignore the errors?

Thanks!
J Groombridge



__ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

test.log
Description: test.log
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond Error

[Jeffrey Philpott]

Mats Bengtsson schrieb:
According to some earlier email on the mailing list, it's since the
Debian package you use is built to work together with a newer version
of teTeX and apparently, it's not backward compatible.  Try Ferenc's
package instead of Pedro's (or maybe it's the other way around, I have to
confess I don't remember the names of the different Debian releases), see
the Downloads page at lilypond.org.
  /Mats
Jeffrey Philpott wrote:
All of a sudden I get the following errors with Lilypond:
lilypond: Symbol `kpse_format_info' has different size in shared 
object, consider re-linking
GNU LilyPond 2.4.2
Processing `pfingstchoral.ly'
Analysiere...

Warnung: lily-guile:
pfingstchoral.ly: old relative compatibility was not used.
Interpretation der Musik...Speicherzugriffsfehler
I'm using 2.4.2 on Debian, what do I do now?!
Greetings Jeffrey
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user



Many thanks to you and Roland, who answered so promptly. As a user of 
Debian "testing" (which is Sarge), it means for those users that one 
needs the packages from Pedro, and now it works again!

Greetings Jeffrey
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond Error

[Mats Bengtsson]

According to some earlier email on the mailing list, it's since the
Debian package you use is built to work together with a newer version
of teTeX and apparently, it's not backward compatible.  Try Ferenc's
package instead of Pedro's (or maybe it's the other way around, I have to
confess I don't remember the names of the different Debian releases), see
the Downloads page at lilypond.org.
  /Mats
Jeffrey Philpott wrote:
All of a sudden I get the following errors with Lilypond:
lilypond: Symbol `kpse_format_info' has different size in shared 
object, consider re-linking
GNU LilyPond 2.4.2
Processing `pfingstchoral.ly'
Analysiere...

Warnung: lily-guile:
pfingstchoral.ly: old relative compatibility was not used.
Interpretation der Musik...Speicherzugriffsfehler
I'm using 2.4.2 on Debian, what do I do now?!
Greetings Jeffrey
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user

Lilypond Error

[Jeffrey Philpott]

All of a sudden I get the following errors with Lilypond:
lilypond: Symbol `kpse_format_info' has different size in shared object, 
consider re-linking
GNU LilyPond 2.4.2
Processing `pfingstchoral.ly'
Analysiere...

Warnung: lily-guile:
pfingstchoral.ly: old relative compatibility was not used.
Interpretation der Musik...Speicherzugriffsfehler
I'm using 2.4.2 on Debian, what do I do now?!
Greetings Jeffrey
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypond: error: LaTeX failed on the output file - Windows 2000 with LaTeX

[Mats Bengtsson]

Bad suggestion, see my previous email. I think TeXLive has some
advantages compared to both TeXLive and MikTeX.
/Mats
Bertalan Fodor wrote:
I suggest uninstalling TeXLive. Install MikTex instead.
Lilypond has to use the TeX that is included in cygwin. Perhaps it is 
enough to just set some environment variables in cygwin.bat, to clear 
the environment variables set by TeXLive. Refer to the mailing list 
archive to find the correct environment settings.

Bert
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
Fax:   (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypond: error: LaTeX failed on the output file - Windows 2000 with LaTeX

[Bertalan Fodor]

I suggest uninstalling TeXLive. Install MikTex instead.
Lilypond has to use the TeX that is included in cygwin. Perhaps it is 
enough to just set some environment variables in cygwin.bat, to clear 
the environment variables set by TeXLive. Refer to the mailing list 
archive to find the correct environment settings.

Bert
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user