Re: Provide \hide and \no functions for transparent and void glyphs (issue 6575048)
On 2012/10/02 00:23:55, Graham Percival wrote: https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly#newcode649 ly/music-functions-init.ly:649: no = why not use "omit" instead of "no" ? I think that "omit" is more specific; "no" is a quite general word and I don't think it makes sense here. That has been discussed in comment #1 to comment #8 of this Rietveld review. Could you be a bit more specific about why you consider the conclusion of this discussion invalid? https://codereview.appspot.com/6575048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various clean-ups in stems and beams. (issue 6584045)
On 2012/10/01 23:34:39, MikeSol wrote:
I think a user should be able to use Kievan notation and normal
stems/flags/beams if she so chooses. I'll define something like
[snip]
and then use it in the documentation.
I still see some issues with this. As written now in stem.cc, when the
style property of NoteHead is set to kievan, the stems are not "normal".
In this case, it is not clear what Kievan notation with "normal
stems/flags/beams" would look like. At best, there would be no stems and
beams flat across the center of the staff. Or, something like
\relative c' {
\override NoteHead #'style = #'kievan
a'8[ bes]
}
gives the warning "weird stem size, check for narrow beams".
Also, because the calculation of the duration log moves to
note-head::calc-kievan-duration-log, something like
\relative c' {
\override NoteHead #'style = #'kievan
a'8
}
produces the wrong NoteHead stencil (a quarter note instead of an eighth
note).
If we implement the patch as written, Kievan note heads outside of the
KievanVoice context wouldn't make sense. I'm not altogether opposed to
that (I see no real reason to not use KievanVoice), but it seems like a
"policy" issue, as it would make Kievan notation different from how
other ancient notations are handled.
https://codereview.appspot.com/6584045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: extend description of glissandi (2844) (issue 6567059)
LGTM https://codereview.appspot.com/6567059/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \no functions for transparent and void glyphs (issue 6575048)
https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly#newcode649 ly/music-functions-init.ly:649: no = why not use "omit" instead of "no" ? I think that "omit" is more specific; "no" is a quite general word and I don't think it makes sense here. https://codereview.appspot.com/6575048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Added \clef "treble_8" for guitar harmonics (issue 6588049)
LGTM https://codereview.appspot.com/6588049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various clean-ups in stems and beams. (issue 6584045)
Reviewers: aleksandr.andreev,
Message:
I think a user should be able to use Kievan notation and normal
stems/flags/beams if she so chooses. I'll define something like
startKievanNotation = {
%% Set glyph styles.
\override NoteHead #'style = #'kievan
\override Rest #'style = #'mensural
\override Accidental #'glyph-name-alist =
#alteration-kievan-glyph-name-alist
\override Dots #'style = #'kievan
\override Slur #'stencil = ##f
%% There are beams in Kievan notation, but they are invoked manually
\set autoBeaming = ##f
}
stopKievanNotation = {
\revert NoteHead #'style
\revert Rest #'style
\revert Accidental #'glyph-name-alist
\revert Dots #'style
\revert Slur #'stencil
\unset autoBeaming
}
and then use it in the documentation.
Description:
Various clean-ups in stems and beams.
*) Eliminates code dups for Kievan work.
*) Transfers functions that are called a lot to C++ to speed things up.
*) Eliminates unused variables.
No regtest changes.
Please review this at https://codereview.appspot.com/6584045/
Affected files:
A input/regression/kievan-notation.ly
M lily/include/beam.hh
M lily/include/stem.hh
M lily/stem.cc
M ly/engraver-init.ly
M scm/define-grobs.scm
M scm/output-lib.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide define-session and define-session-public commands (issue 6588056)
On 2012/10/01 18:24:20, dak wrote:
15.6 `@tie{}': Inserting an Unbreakable Space
=
The `@tie{}' command produces a normal interword space at which a line
break may not occur. Always write it with following (empty) braces,
as
usual for commands used within a paragraph. Here's an example:
@TeX{} was written by Donald E.@tie{}Knuth.
produces:
TeX was written by Donald E. Knuth.
Thanks for the clarification.
http://codereview.appspot.com/6588056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch-testing-problem
2012/9/30 James : > Hello, > > On 30 September 2012 16:06, Thomas Morley > wrote: [...] >> I couldn't comprehend your own work. > > The problem is that not all errors are the same - I am no expert but > after testing patches for the last year or so, you get a feel for this > I guess. Phil's work (et al) has helped simplify the log, but if you > see > > http://code.google.com/p/lilypond/issues/detail?id=2790#c16 > > for instance, this was a differnet kind of failure and was easy to > spot simply because the log file references did point to a .ly file. > > This instance here is different and so it was trickier to follow the > chain, in fact I couldn't. Phil's suggestion of looking at the latest > file generated is a good one, but I simply use basic grep commands > > grep -r -C 10 "Error" > > for instance, in the top level of the build dir. > > I get a ton of hits, but the -C makes it easy to see if the return is > just a comment of the string 'Error' or a function call, rather than a > log file. > > The trick here is to know the error message being generated in the log > file, "fatal" is one, or you can just do "Processing files" and the -C > gives you a few lines above and below so you can see a completed file > or an error. > >> But after typing 'make check' the first two lines the terminal returns are: > >> >> For tracking crashes: use >> >> grep sourcefilename `grep -L systems.texi >> out/lybook-testdb/*/*log|sed s/log/ly/g` > > I can't comment on that but it seems awfully complicated. > >> >> Trying to enter this (in the build-directory) returns: >> \sourcefilename >> "/home/harm/lilypond-git/input/regression/instrument-name-volta.ly" >> >> This is exactly the file Marc mentioned here: >> http://codereview.appspot.com/6498052/#msg13 > > OK but that ly file will also occur in a snippet*.log file. So you can > cross reference I guess but that would need another grep search. > > I guess I am just used to looking at lines and lines of output to use > a simpler grep command, but not all crashes/compilation failures are > the same and don't generate the same error messages even if the > initial crash message looks the same. > > At least from my experience. > > However the offending log file *will* contain the error message (as if > you had run lilypond-book on the individual snippet) > > Hence my comment > > --snip-- > lily-7dccbf09.log:programming error: number of pages is out of bounds > lily-7dccbf09.log:programming error: tried to space systems on a bad > number of pages > lily-7dccbf09.log:programming error: number of pages is out of bounds > lily-7dccbf09.log:programming error: tried to space systems on a bad > number of pages > --snip-- > > The file 'lily-7dccbf09.log' contained the error message (from the > grep command) and also in that log was the name of the snippet. > > James > > James Hi James, many thanks for your explanations! I'll think about them. Continuing testing and trying. -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Outdated help2man; avoiding needing to "build" help2man.pl
On Mon, 01 Oct 2012, Pavel Roskin wrote: > On Thu, 13 Sep 2012 14:51:53 -0700 > Don Armstrong wrote: > > While it's correct, you can trivially work around this problem by > > changing > > > > #!@PERL@ -w > > > > to > > > > #!@PERL@ -w > > #! perl -w > > Considering the subsequent discussion, it's probably irrelevant to > LilyPond. However, it's a bad idea to use an executable name without > full path. #! perl -w isn't the executable name; it's just used to get around having to shove in the value of $(PERL) into @PERL@ before calling help2man.pl. See perldoc perlrun's documentation of -x. Don Armstrong -- To steal ideas from one person is plagiarism; to steal from many is research. -- Steven Wright http://www.donarmstrong.com http://rzlab.ucr.edu ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Various clean-ups in stems and beams. (issue 6584045)
http://codereview.appspot.com/6584045/diff/2001/ly/engraver-init.ly
File ly/engraver-init.ly (right):
http://codereview.appspot.com/6584045/diff/2001/ly/engraver-init.ly#newcode1150
ly/engraver-init.ly:1150: \override Beam #'positions =
#beam::get-kievan-positions
The only issue with putting this here is that if the user enters Kievan
notes without using the default KievanVoice context, the properties
don't get initialized. For example, this no longer works:
\relative c' {
\override NoteHead #'style = #'kievan
e8 [ g]
a[ bes]
}
Either we have to initialize these properties when the style property of
the NoteHead is set to kievan or we have to change the documentation to
indicate that Kievan notation can only be used with the default
contexts. The latter option would require changing the snippets in the
documentation, among other things.
http://codereview.appspot.com/6584045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Outdated help2man; avoiding needing to "build" help2man.pl
On Thu, 13 Sep 2012 14:51:53 -0700 Don Armstrong wrote: > In stepmake/stepmake/help2man-rules.make, I ran across the following: > > # We must invoke the generated $(outdir)/help2man script instead of > # the help2man.pl source, which means that the scripts/build directory > # must be built first. > # > # From the perlrun man-page: > # > # If the #! line does not contain the word "perl", the > # program named after the #! is executed instead of the Perl > # interpreter. This is slightly bizarre, but it helps > # > # Indeed it is. Perl sucks. > # > # Two screenfulls explaining that the otherwise standard #! is broken > # for perl, and arguing that this broken magic is better in some > # cases. Four more explaining what a line comment is, and that it may > # be parsed, same here. > > While it's correct, you can trivially work around this problem by > changing > > #!@PERL@ -w > > to > > #!@PERL@ -w > #! perl -w Considering the subsequent discussion, it's probably irrelevant to LilyPond. However, it's a bad idea to use an executable name without full path. See http://www.cyberciti.biz/tips/finding-bash-perl-python-portably-using-env.html So it should be #!/usr/bin/env perl -w -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide define-session and define-session-public commands (issue 6588056)
Reviewers: Ian Hulin (gmail),
Message:
On 2012/10/01 18:02:16, Ian Hulin (gmail) wrote:
Just a question about the doc-string.
http://codereview.appspot.com/6588056/diff/1/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/6588056/diff/1/scm/lily.scm#newcode51
scm/lily.scm:51: A@tie{}session basically corresponds to one LilyPond
file on
the
Is a space needed somewhere in "A@tie{}session"? I.e. will it look the
way you
intended when the docs are compiled?
15.6 `@tie{}': Inserting an Unbreakable Space
=
The `@tie{}' command produces a normal interword space at which a line
break may not occur. Always write it with following (empty) braces, as
usual for commands used within a paragraph. Here's an example:
@TeX{} was written by Donald E.@tie{}Knuth.
produces:
TeX was written by Donald E. Knuth.
So in a nutshell: if this runs through Texinfo, we will get a
non-breakable space in there. At the current point of time, only the
doc strings of music functions and of functions written in C++ are
listed in the NR and Extending manual, respectively. Does this mean
that we should not use Texinfo markup in *.scm files? No idea.
Description:
Provide define-session and define-session-public commands
Also moves the session logic into lily.scm instead of init.ly
Please review this at http://codereview.appspot.com/6588056/
Affected files:
M ly/init.ly
M scm/lily.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Provide define-session and define-session-public commands (issue 6588056)
Just a question about the doc-string.
http://codereview.appspot.com/6588056/diff/1/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/6588056/diff/1/scm/lily.scm#newcode51
scm/lily.scm:51: A@tie{}session basically corresponds to one LilyPond
file on the
Is a space needed somewhere in "A@tie{}session"? I.e. will it look the
way you intended when the docs are compiled?
http://codereview.appspot.com/6588056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Thomas Morley writes: > 2012/9/30 : >> On 2012/09/30 19:44:49, marc wrote: >>> >>> Am 30.09.2012 11:02, schrieb d...@gnu.org: >>> > [...] >>> > First, the define-public is asking for trouble. You are exposing an >>> > internal Scheme data structure to users and make it overwritable by >> >> the >>> >>> > user. If the user follows this invitation, the effects will bleed >> >> over >>> >>> > from session to session. Never do that. >>> Ok. >> >> >> No, it's not ok. Hold your horses, this is another case too stupid for >> documenting and walking people through. Give me two days, and then you >> replace your define-public for the alists with define-session, and >> that's it. The rest of the code stays as it is. >> >> I'll make define-session do everything that is needed. >> > > That would be very nice. > I can think of several functions/definitions currently destructively > changing internal Scheme data structures. > Perhaps they would work as expected then. See http://code.google.com/p/lilypond/issues/detail?id=2872>. The session management does not do any structure copying, so any _modification_ of structures is not going to be restored. The value of the variables defined with (define-session ...) itself, however, will get restored, so as long as you "modify" your alists only by prepending elements, or do a copy-and-modify yourself (leaving the original structure intact), this should work out. It would be feasible to do copying, but then one needs to use a different copying method for a variety of types, and copy for creating the initial session values, and copy for replacing them. I wanted to avoid that overhead. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
On 2012/10/01 08:46:09, marc wrote: Am 30.09.2012 22:03, schrieb d...@gnu.org: > On 2012/09/30 19:44:49, marc wrote: >> Am 30.09.2012 11:02, schrieb d...@gnu.org: >> > [...] >> > First, the define-public is asking for trouble. You are exposing an >> > internal Scheme data structure to users and make it overwritable by > the >> > user. If the user follows this invitation, the effects will bleed > over >> > from session to session. Never do that. >> Ok. > > No, it's not ok. Hold your horses, this is another case too stupid for > documenting and walking people through. Give me two days, and then you > replace your define-public for the alists with define-session, and > that's it. The rest of the code stays as it is. That's good news! I think I owe you something, thanks in advance! Or define-session-public. define-session will be for data that is reset per session, but not publicly accessible. Which is probably what you want if all the accessor functions are already in your .scm file. http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Marc Hohl writes: > Am 01.10.2012 11:00, schrieb d...@gnu.org: >> >> Or define-session-public. define-session will be for data that is reset >> per session, but not publicly accessible. Which is probably what you >> want if all the accessor functions are already in your .scm file. > I think that -public is needed for data to be accessible for a user? > Or is it sufficient that the function accessing the data is -public? "public" just publishes the variable binding. The binding does not need to get published to be accessible to functions in the same source file: the binding is only needed when the functions referring to it are _defined_, not when they are being used. Of course, you can't do session management on a variable you can't even access, but publishing the variable for everybody else to tamper with is not going to make our problem smaller. So we need to be able to do session-management on the variable _without_ publishing it, and that means in the module where it is being defined. And the easiest way is to have separate defining commands for that purpose. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Am 01.10.2012 11:00, schrieb d...@gnu.org: On 2012/10/01 08:46:09, marc wrote: Am 30.09.2012 22:03, schrieb d...@gnu.org: > On 2012/09/30 19:44:49, marc wrote: >> Am 30.09.2012 11:02, schrieb d...@gnu.org: >> > [...] >> > First, the define-public is asking for trouble. You are exposing an >> > internal Scheme data structure to users and make it overwritable by > the >> > user. If the user follows this invitation, the effects will bleed > over >> > from session to session. Never do that. >> Ok. > > No, it's not ok. Hold your horses, this is another case too stupid for > documenting and walking people through. Give me two days, and then you > replace your define-public for the alists with define-session, and > that's it. The rest of the code stays as it is. That's good news! I think I owe you something, thanks in advance! Or define-session-public. define-session will be for data that is reset per session, but not publicly accessible. Which is probably what you want if all the accessor functions are already in your .scm file. I think that -public is needed for data to be accessible for a user? Or is it sufficient that the function accessing the data is -public? http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Am 30.09.2012 22:03, schrieb d...@gnu.org: On 2012/09/30 19:44:49, marc wrote: Am 30.09.2012 11:02, schrieb d...@gnu.org: > [...] > First, the define-public is asking for trouble. You are exposing an > internal Scheme data structure to users and make it overwritable by the > user. If the user follows this invitation, the effects will bleed over > from session to session. Never do that. Ok. No, it's not ok. Hold your horses, this is another case too stupid for documenting and walking people through. Give me two days, and then you replace your define-public for the alists with define-session, and that's it. The rest of the code stays as it is. That's good news! I think I owe you something, thanks in advance! Marc I'll make define-session do everything that is needed. Just that it is possible to learn all the internals of LilyPond session does not mean that it makes sense that you are required to do so just in order to accomplish a simple task. http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
