Closed ExecutorElassus closed 9 years ago
Your MWE is actually faulty (you have to enclose the music in a context), but that shouldn't be an issue.
However, I couldn't verify the error message, neither on a binary 2.19.22, on a custom build somewhere in 2.19.23 nor in a custom build from latest master (2.19.25).
Could you please make sure that you don't have another issue (not the latest openLilyLib, wrong branch checked out ...)? If you "insist" on the error I'll download more binaries and do more testing.
PS:
You can wrap code in backticks. Then it will be formatted as code (making it more <readable>)
and special characters will be kept. Multiline code snippets can be enclosed in "fenced code blocks" by surrounding it with lines with three backticks, and then there is even the LilyPond code highlighting available, such as
```lilypond \version "2.19.24" \include "openlilylib" \score { a b c d } ```
which will result in
\version "2.19.24"
\include "openlilylib"
\score {
a b c d
}
Thank you for correcting the MWE. As for the bug: I found that deleting my OLL subdirectory and cloning it again made the issue go away, so chalk it up to my poor use of Git (is there some other command than 'clone' to update a local branch to the latest version?)
Cheers,
A
On Mon, Aug 3, 2015 at 4:45 PM, Urs Liska notifications@github.com wrote:
Your MWE is actually faulty (you have to enclose the music in a context), but that shouldn't be an issue.
However, I couldn't verify the error message, neither on a binary 2.19.22, on a custom build somewhere in 2.19.23 nor in a custom build from latest master (2.19.25).
Could you please make sure that you don't have another issue (not the latest openLilyLib, wrong branch checked out ...)? If you "insist" on the error I'll download more binaries and do more testing.
PS: You can wrap code in backticks. Then it will be formatted as code (making it more
) and special characters will be kept. Multiline code snippets can be enclosed in "fenced code blocks" by surrounding it with lines with three backticks, and then there is even the LilyPond code highlighting available, such as \version "2.19.24" \include "openlilylib" \score { a b c d }
which will result in
\version "2.19.24"\include "openlilylib"\score { a b c d }
— Reply to this email directly or view it on GitHub https://github.com/openlilylib/openlilylib/issues/129#issuecomment-127165584 .
(is there some other command than 'clone' to update a local branch to the latest version?)
Of course. If you don't do anything else with a repository than use it - as seems the case with you and OLL - all you have to do is regularly do git pull
to update it to the latest version. You can make a habit of doing that before starting to work or only if you know there's something new you might want.
Ah, one more hint: git clone
will create the repository in a subdirectory of the working directory, while you will have to be inside your repository for git pull
new version, similar issue to the one I previously posted:
Starting lilypond 2.19.24 [transkription kayser psalmi in vesperas.ly]... Processing `[$HOME]/transkription kayser psalmi in vesperas.ly' Parsing...[$HOME]/.lilypond/openlilylib/ly/openlilylib:28:9: In procedure ly:parser-include-string in expression (ly:parser-include-string parser "\include \"_internal/init-openlilylib.ily\""): [$HOME]/.lilypond/openlilylib/ly/openlilylib:28:9: Wrong number of arguments to #[primitive-procedure ly:parser-include-string] Exited with return code 1.
Happens even with a MWE:
\version "2.19.24" \include "openlilylib" \score { a b c d }
PS: the primitive-procedure… argument is actually enclosed in "<" symbols, but GitHub's stupid markdown feature then makes it invisible, so I had to change them :(