Re: not all doc clean-ups are good
Werner LEMBERG wrote Friday, August 19, 2011 6:38 AM In particular, many locations which I've fixed (at least in my opinion) were talking about, say, `#t' and `#foo' at the same time, which I consider *very* confusing. There are two possiblities to fix it: Either by saying `#t' and `foo', or by saying `##t' and `#foo'. I've decided to use the former, following the advice in the paragraph I've cited first in this email. If you think that it's better to do it the other way, I can change this, no problem. However, I would like to here some arguments (or maybe you can give me links to a previous discussion which I've missed apparently)... No, what you did is correct. This is the way it is introduced in the Learning Manual. See http://www.lilypond.org/doc/v2.15/Documentation/learning/modifying-context-properties Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3842 - Release Date: 08/18/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Has piano pedal brackets end on the right of a note column. (issue 4899050)
On Aug 19, 2011, at 5:01 AM, k-ohara5...@oco.net wrote: A swing and a miss, I'm afraid. See input/regression/pedal-bracket for what the original alignment goals were. (You could expand that reg-test to cover issue 723) I think the correct fix is merely to ignore suspended heads, which could be implemented as aligning to the stem for down-stems. I find good evidence to back that up I'll post on the bug tracker. If this is the fix, my recent work on 620 could be tweaked a bit to be used in this situation as well. Currently, bound-interfaces is a property that resides in the grobs being aligned to (note columns, paper columns). If instead bound interfaces resides in the grobs that are being aligned (hairpins, line spanners, piano pedals), then the same note column could be aligned to different ways for different grobs. The more I think about it, the more it makes sense. Let me know if you think this'd be a good option. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes boolean/SCM confusions, part 1. (issue 4875054)
Graham Percival gra...@percival-music.ca writes: On Thu, Aug 18, 2011 at 09:43:38PM +, carl.d.soren...@gmail.com wrote: I think we ought to have a comment somewhere that describes why we don't use scm_is_true. But I can't figure out where to put it -- I guess it should be in the documentation that we hope will arise as a result of all this effort. Yes, but let's not hope for this. Bertrand: you're her mentor, so this is your job. Add a section to the CG chapter on programming. Make a new @section right before LilyPond miscellany. Interfacing Lilypond with Guile As a policy, we try keeping to the documented interfaces of Guile. Lilypond has a certain amount of its own macros and trickery for making working with Guile convenient on the C side of Lilypond. Some noteworthy points are: Something like that? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Does better polynomial calculations for avoid objects. (issue 4860042)
Thanks Joe! New patchset uploaded. Cheers, MS http://codereview.appspot.com/4860042/diff/1/flower/polynomial.cc File flower/polynomial.cc (right): http://codereview.appspot.com/4860042/diff/1/flower/polynomial.cc#newcode65 flower/polynomial.cc:65: Polynomial::minmax (Real l, Real r, bool dir) const On 2011/08/18 21:36:45, joeneeman wrote: Perhaps bool max instead of bool dir? Done. http://codereview.appspot.com/4860042/diff/1/lily/bezier.cc File lily/bezier.cc (right): http://codereview.appspot.com/4860042/diff/1/lily/bezier.cc#newcode87 lily/bezier.cc:87: Axis other = Axis ((a + 1) % NO_AXES); On 2011/08/18 21:36:45, joeneeman wrote: Use the other_axis function. Done. http://codereview.appspot.com/4860042/diff/1/lily/bezier.cc#newcode217 lily/bezier.cc:217: Bezier::minmax (Axis ax, Real l, Real r, Direction d) const On 2011/08/18 21:36:45, joeneeman wrote: What is this function supposed to do? This is like other_coordinate insofar as it is a fancy wrapper around a polynomial function that. It finds the max or min along the bezier between l and r. http://codereview.appspot.com/4860042/diff/1/lily/bezier.cc#newcode239 lily/bezier.cc:239: return p.minmax (sol[LEFT][0], sol[RIGHT][0], d != LEFT); On 2011/08/18 21:36:45, joeneeman wrote: If there are multiple intersections with (say) r, then Polynomial::solve doesn't seem to return them in any useful order. So sol[RIGHT][0] is really just an arbitrary solution, isn't it? True, but this seems no worse than line 81 where ts[0] is returned. Not that this is a good excuse... I'll overload the function such that 0 is a default. http://codereview.appspot.com/4860042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes boolean/SCM confusions, part 1. (issue 4875054)
I think so. I'm already writing a section called C/Scheme interface where I explain that scm_integer_p (x) == SCM_BOOL_T isn't correct. I also start a list of functions like to_boolean explaining why and how to use them. As an expert of these issues, you will probably want to add some details after I push that :) Bertrand ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Has piano pedal brackets end on the right of a note column. (issue 4899050)
On Thu, 18 Aug 2011 23:25:40 -0700, Mike Solomon mike...@ufl.edu wrote: On Aug 19, 2011, at 5:01 AM, k-ohara5...@oco.net wrote: I think the correct fix is merely to ignore suspended heads, which could be implemented as aligning to the stem for down-stems. I find good evidence to back that up I'll post on the bug tracker. If this is the fix, I don't know until next time I look at Ted Ross' book in the library. I have lots of piano music, but pedaling is very rarely written explicitly. I would have thought piano pedal brackets would work just like hairpins, but input/regression/pedal-bracket.ly says they end a bit earlier, at the /left/ of the main note column. my recent work on 620 could be tweaked a bit to be used in this situation as well. Currently, bound-interfaces is a property that resides in the grobs being aligned to (note columns, paper columns). If instead bound interfaces resides in the grobs that are being aligned (hairpins, line spanners, piano pedals), then the same note column could be aligned to different ways for different grobs. The more I think about it, the more it makes sense. Let me know if you think this'd be a good option. You mean your new 'bound-alignment-interfaces. I didn't follow issue 620, but looking now I don't see how it helps. We would want to find the left extent of the note-heads in the main note column, excluding suspended note-heads. (Actually, I think that is the x-reference point for the NoteColumn) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: Request to mailing list lilypond-devel rejected
- Original Message - From: lilypond-devel-ow...@gnu.org To: philehol...@googlemail.com Sent: Thursday, August 18, 2011 11:09 PM Subject: Request to mailing list lilypond-devel rejected Your request to the lilypond-devel mailing list Posting of your message titled Corrects image size in web.pdf - issue 982 (issue 4916041) has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: Non-members are not allowed to post messages to this list. Since you are not subscribed to this list, please use the Gmane interface at http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.devel for posting messages. Thank you, The LilyPond mailing list administrators Any questions or comments should be directed to the list administrator at: lilypond-devel-ow...@gnu.org Don't think I've had this bounce before. I'm subscribed with a different email address. Anyway, patch is up for review at http://codereview.appspot.com/4916041/ -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Has piano pedal brackets end on the right of a note column. (issue 4899050)
On Aug 19, 2011, at 9:51 AM, Keith OHara wrote: You mean your new 'bound-alignment-interfaces. I didn't follow issue 620, but looking now I don't see how it helps. We would want to find the left extent of the note-heads in the main note column, excluding suspended note-heads. (Actually, I think that is the x-reference point for the NoteColumn) Imagine that bound interfaces were not a list but rather a lazy alist of interfaces and callbacks. For example: `((clef-interface . ,my-clef-interface-callback) (key-signature-interface . ,(ly:simple-closure ,my-key-signature-callback-that-needs-an-extra-argument 1)) bar-line-interface) Lazy alist because it can also contain non-pairs, in which case a default extent callback along a given axis is used as the callback. The axis group interface recurses through this list, applying the callback to grobs that contain interfaces in the alist to get the extent of that grob according to the callback. So, now, say that you want to align to a note column a particular way for piano-pedal-brackets. The bound-alignment-interfaces alist would look like: `((note-column-interface . ,my-note-column-callback-specific-to-piano-pedal-brackets)) And my-note-column-callback would be something to the effect of: #(define (my-note-column-callback-specific-to-piano-pedal-brackets grob) exclude-all-left-noteheads-from-extent) This seems swiss-army-knife tweakable: it generalizes the problem of finding different extents for the same grob depending on the grob that needs to be aligned by rolling all extent-finding callbacks into an alist (not unlike the concept of grob properties in the first place). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond's SVG output
Hello, I recently had an informal discussion with some collegues on the use of SVG, in general. They are in music research, I am a developer working on a completely unrelated topic - so please forgive me my ignorance w.r.t. music-related terminology. We discussed the possibilities to use music scores on web pages, and they immediately referred to Lilypond because of its quality output. While browsing this list's archives, and other on-line discussions for that matter, two questions came up: - In what version, exactly, did Lilypond drop the use of groups (svg:g) in its output? I read a debate on this issue, where the key argument against groups was the trouble people have in editing grouped SVG elements in Inkscape. I can, however, imagine all sorts of situations in which group elements could be very useful - from a developer's point of view at least. This leads to the second question: - For what purpose are people putting music up on the web; what's the typical use case? Just publishing it for others to read? Hyperlinking to it, from it? Annotations? Keeping bits and pieces of music for later reference? Learning? Studying? Comparing versions? I may, at some point, be in the position to do some work on this. But I'm hesitant to dive in at the deep end - meaning Lilypond tens of thousands of lines of code ... A bit of guidance might help though cheers, Sandor Spruit Information and Computing Sciences, Utrecht University ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's SVG output
On Aug 19, 2011, at 10:04 AM, Sandor Spruit wrote: Hello, I recently had an informal discussion with some collegues on the use of SVG, in general. They are in music research, I am a developer working on a completely unrelated topic - so please forgive me my ignorance w.r.t. music-related terminology. We discussed the possibilities to use music scores on web pages, and they immediately referred to Lilypond because of its quality output. While browsing this list's archives, and other on-line discussions for that matter, two questions came up: - In what version, exactly, did Lilypond drop the use of groups (svg:g) in its output? LilyPond still uses groups. grep g in scm/output-svg.scm. I read a debate on this issue, where the key argument against groups was the trouble people have in editing grouped SVG elements in Inkscape. I can, however, imagine all sorts of situations in which group elements could be very useful - from a developer's point of view at least. This leads to the second question: - For what purpose are people putting music up on the web; what's the typical use case? Check the list archives for an e-mail from Michael Geary. He's working on this. I do it too for my musical compositions (http://www.apollinemike.com/norman1). Just publishing it for others to read? Hyperlinking to it, from it? Annotations? Keeping bits and pieces of music for later reference? Learning? Studying? Comparing versions? There is no formal hub that groups these efforts together, but as the SVG standard becomes better supported by more and more browsers, I'm sure it'll get picked up by more and mor epeople. I may, at some point, be in the position to do some work on this. But I'm hesitant to dive in at the deep end - meaning Lilypond tens of thousands of lines of code ... You don't need to jump into tens and thousands of lines of LilyPond code - all of the svg backend is present in output-svg.scm. Michael Geary is likely to be sponsoring some work on this too - I'll keep you posted if/when this happens. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Has piano pedal brackets end on the right of a note column.(issue 4899050)
- Original Message - From: Keith OHara k-ohara5...@oco.net To: mts...@gmail.com; lilypond-devel@gnu.org; re...@codereview.appspotmail.com; Mike Solomon mike...@ufl.edu Sent: Friday, August 19, 2011 8:51 AM Subject: Re: Has piano pedal brackets end on the right of a note column.(issue 4899050) On Thu, 18 Aug 2011 23:25:40 -0700, Mike Solomon mike...@ufl.edu wrote: On Aug 19, 2011, at 5:01 AM, k-ohara5...@oco.net wrote: I think the correct fix is merely to ignore suspended heads, which could be implemented as aligning to the stem for down-stems. I find good evidence to back that up I'll post on the bug tracker. If this is the fix, I don't know until next time I look at Ted Ross' book in the library. I have lots of piano music, but pedaling is very rarely written explicitly. I've got a PDF of Ross - could let you have a copy of the bit on pedals, if you want. Not sure it's explicit enough, but you're welcome.Elaine Gould has 6 pages on pedalling, which could be scanned if required. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes boolean/SCM confusions, part 1. (issue 4875054)
Bertrand Bordage bordage.bertr...@gmail.com writes: I think so. I'm already writing a section called C/Scheme interface where I explain that scm_integer_p (x) == SCM_BOOL_T isn't correct. Well, it works as long as scm_is_eq works the same as ==. But that's an implementation detail of Guile and not part of the Guile API. Bypassing the Guile API here does not buy us anything regarding efficiency, and it is not helpful for debugging and newcomers who should not be required to know internals of Guile. I also start a list of functions like to_boolean explaining why and how to use them. As an expert of these issues, you will probably want to add some details after I push that :) Actually, I am far from being an expert. Most of my respective knowledge is less than two days old, gained mostly by cross-reading and consolidating Guile and Lilypond docs and C sources. The point is that for a newcomer, reading the respective docs should tell enough of the story to make them reasonably comfortable with reading Lilypond code instead of going WTF?!? right away. It is somewhat amusing, by the way, that Lilypond's to_boolean is required in order to let '() and #f be interpreted in the same manner. It would seem that Lisp's conflating them into `nil' is not the worst idea. But that may not be enough reason to let Lilypond use the Elisp mode of Guile. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes boolean/SCM confusions, part 1. (issue 4875054)
I'm already writing a section called C/Scheme interface where I explain that scm_integer_p (x) == SCM_BOOL_T isn't correct. Well, it works as long as scm_is_eq works the same as ==. But that's an implementation detail of Guile and not part of the Guile API. Bypassing the Guile API here does not buy us anything regarding efficiency, and it is not helpful for debugging and newcomers who should not be required to know internals of Guile. Of course, this is bizarre for newcomers... But there's something else that actually mislead me before we started working on this. In the Guile reference, it is written that scm_string_p returns #t or #f. And it is also written that scm_is_string returns 0 or 1. Because it isn't written SCM_BOOL_T and SCM_BOOL_F, I always thought 0 and 1 were Scheme values. This, of course, totally broke my understanding of these functions. I pointed out this logical error in the piece of doc I will push. It is somewhat amusing, by the way, that Lilypond's to_boolean is required in order to let '() and #f be interpreted in the same manner. It would seem that Lisp's conflating them into `nil' is not the worst idea. This also mislead me a long time ago. Bertrand ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrects image size in web.pdf - issue 982 (issue 4916041)
LGTM, but do we still use the -small images for anything else now? I mean, go ahead and push this, but then please investigate if we still need the -small images, and if we don't need them, then please remove them from the build system. http://codereview.appspot.com/4916041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrects image size in web.pdf - issue 982 (issue 4916041)
- Original Message - From: percival.music...@gmail.com To: philehol...@googlemail.com; perciv...@gmail.com Cc: lilypond-devel@gnu.org; re...@codereview.appspotmail.com Sent: Friday, August 19, 2011 11:40 AM Subject: Re: Corrects image size in web.pdf - issue 982 (issue 4916041) LGTM, but do we still use the -small images for anything else now? I mean, go ahead and push this, but then please investigate if we still need the -small images, and if we don't need them, then please remove them from the build system. http://codereview.appspot.com/4916041/ [Address list snipped] Yes - they're used in the web pages, with a link to the big ones that can be clicked to show more detail. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
\once \revert
Up to now, \once \revert is not really documented nor used. I have not yet dug through the existing code in order to figure out what it does if anything (most likely ignoring \once, but not sure). In order to not have the override/revert stack get into unexpected interactions, I want to change \once\override to be impervious to normal reverts. That would mean that \once\revert is an obvious candidate for reverting a \once\override before its time. However, I have no idea whether there is an actual sensible use for that functionality. \once\revert could also mean to let a current non-once override become inactive just for the current time step. That's likely harder to implement, I think. Again, I have no idea whether there is an actual sensible use for that either, and it looks rather ad-hoc. IF one wanted to get crazy, one could use \once\revert for one of the two things, and \revert\once for the other. Which one for which, and would anybody remember that? Since the parser permits \once\revert, I tend towards making it match the last \once\override. It likely does not make much sense, but then it is sort of easy to understand. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \once \revert
On 8/19/11 10:15 AM, David Kastrup d...@gnu.org wrote: Up to now, \once \revert is not really documented nor used. I have not yet dug through the existing code in order to figure out what it does if anything (most likely ignoring \once, but not sure). I would expect that \once \revert would revert an \override for the current time step only (meaning events whose start time is the current moment). For any events whose start time is other than the current moment, the \override would continue to apply. In order to not have the override/revert stack get into unexpected interactions, I want to change \once\override to be impervious to normal reverts. This seems to me to be a wise decision. \once \override is a statement that you are creating an override for everything happening at the current moment; reverts would not seem to apply. That would mean that \once\revert is an obvious candidate for reverting a \once\override before its time. However, I have no idea whether there is an actual sensible use for that functionality. I can see no sensible use for that functionality. You would have conflicting statements about what should happen at this time. \once\revert could also mean to let a current non-once override become inactive just for the current time step. As I mentioned above, I think this is the logically consistent meaning. That's likely harder to implement, I think. You have *clearly* studied this and thought about it much more than I (and I'm grateful for your tackling this issue). I would think that a \once command would not need a stack. \once means create a new setting from the current setting, and apply it at this moment, but don't carry it forward. But again, you have much more basis for your observations than I have for mine. Again, I have no idea whether there is an actual sensible use for that either, and it looks rather ad-hoc. I have no idea whether there is a sensible use, either, but it is logically consistent, IMO. IF one wanted to get crazy, one could use \once\revert for one of the two things, and \revert\once for the other. Which one for which, and would anybody remember that? I agree that this would be crazy. But if we were going to do it, \once \revert should revert an \override, but only for the current moment, and \revert \once should revert a \once \override, IMO. But I would not be in favor of this proposal. Since the parser permits \once\revert, I tend towards making it match the last \once\override. It likely does not make much sense, but then it is sort of easy to understand. I lean to the opposite use, as I have described. To me, \once \override x = #y \once \revert x should be an undefined state, since there are two conflicting commands. Why should the second one have preference over the first? Just because it comes later in the text stream? I'd be fine with having the documentation say something like When two \once commands conflict, the resulting state is indeterminate. You should never have two \once commands at the same musical moment that affect the same property setting. In fact, I think I would be in favor of removing \once \revert from the parser. The semantics of \once \revert can be confusing, and the same behavior could be achieved with a \once \override. But I would be open to arguments from those who see good uses of \once \revert. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
Reviewers: , Message: Hi, Graham asked me to document an small issue. (http://codereview.appspot.com/4875054/) And this became something bigger. He also told me to push it directly, but I made a few changes in the interface as I read the code and wrote the doc. So the review concerns only the C files of this patch, but feel free to tell me if I was totally wrong when writing it. Thanks, Bertrand Description: lily-guile updates and CG: Scheme-C interface section. Please review this at http://codereview.appspot.com/4917044/ Affected files: M Documentation/contributor/programming-work.itexi M lily/general-scheme.cc M lily/include/lily-guile.hh M lily/lily-guile.cc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
Doc part LGTM. I can't speak about the scm / C++ stuff. http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
THanks for doing this!
I have some comments about the docs. I think they're too tutorial, and
I think the exhaustive lists are unwieldy and should be eliminated. THe
source should be the reference.
I think the code changes should be separated from the doc changes. I
disagree with your changes on directions; they don't need to be
integers.
Thanks,
Carl
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi
File Documentation/contributor/programming-work.itexi (right):
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1811
Documentation/contributor/programming-work.itexi:1811: (see
@ref{LilyPond programming languages}).
I'd prefer to see a URL to the appropriate Guile page here.
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1830
Documentation/contributor/programming-work.itexi:1830: or warning when
compiling but must be avoided:
I think that you should reference the paragraph that David pointed out
in his email:
http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00646.html
The code in your example *will work*, but it is not following the API
guidelines. So we should be clear about why we're doing this. It's for
standards compliance, not because of lack of functionality.
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1833
Documentation/contributor/programming-work.itexi:1833: scm_string_p
([any_SCM_you_want]) == SCM_BOOL_T
I think it would be better to say:
if (scm_string_p (scm_value) == SCM_BOOL_T)
i.e. put in a real variable name, instead of a place holder)
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1840
Documentation/contributor/programming-work.itexi:1840: quicker in terms
of execution time.
Are you sure of the execution time argument? I'm not.
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1845
Documentation/contributor/programming-work.itexi:1845: a misnomer in the
reference: it says @code{scm_is_string} returns @code{#t}
Are you sure this is correct?
The current page of the API reference says:
— Scheme Procedure: string? obj
— C Function: scm_string_p (obj)
Return #t if obj is a string, else #f.
— C Function: int scm_is_string (SCM obj)
Returns 1 if obj is a string, 0 otherwise.
(see
http://www.gnu.org/software/guile/manual/html_node/String-Predicates.html#String-Predicates
)
Also, the Guile API says :
The type of the return value of a C function that corresponds to a
Scheme function is always SCM. In the descriptions below, types are
therefore often omitted but for the return value and for the arguments.
(see
http://www.gnu.org/software/guile/manual/html_node/API-Overview.html#API-Overview
)
So scm_is_string returns a C int, with a value of 0 or 1.
scm_string_p returns a C SCM, with a value of #t or #f (but we can't
access those values directly from C).
I think the key point that we should get across (which I didn't
understand until I started this review) is that we should use generally
use C functions and macros that have no corresponding Scheme procedures.
The C functions with corresponding Scheme procedures return SCM values,
and we can't use them for anything but assignment in C.
Or perhaps it's clearer to say that for anything but assignment in C, we
should use only C Functions and Macros with non-SCM return values.
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1876
Documentation/contributor/programming-work.itexi:1876: Here is a list of
these functions:
Rather than explaining these functions, I think we should only explain
cases where the usage is non-obvious (i.e. using to_boolean on property
returns, since unset properties often aren't boolean values.
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1878
Documentation/contributor/programming-work.itexi:1878: TODO: complete
this list.
See my comment below. I don't think we should have exhaustive lists,
unless they are automatically generated.
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1882
Documentation/contributor/programming-work.itexi:1882: Convert a Scheme
boolean @var{b} to a C boolean, else return false.
If b is a Scheme boolean value, return the corresponding C boolean
value, else return false.
Or
Return @code{true} if @var{b} is @code{SCM_BOOL_T}, otherwise return
@code{false}
http://codereview.appspot.com/4917044/diff/1/Documentation/contributor/programming-work.itexi#newcode1918
Documentation/contributor/programming-work.itexi:1918: TODO: complete
this list.
I'm not in favor of having a complete list here. Unless we can identify
a means of automatically creating the list from the source code, this
will invariably
Re: Has piano pedal brackets end on the right of a note column.(issue 4899050)
On Fri, 19 Aug 2011 01:33:56 -0700, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Keith OHara I don't know until next time I look at Ted Ross' book in the library. Mostly I was being rhetorical, calling to attention the vastly different time-scales that Mike and I live in. I've got a PDF of Ross ... I think I'll get me one of those. A distributor who carries it is only a few miles beyond the local university library; he says the book is out of print at the moment, but he has the CD version. Takes up less shelf space. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc File lily/general-scheme.cc (right): http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc#newcode110 lily/general-scheme.cc:110: if (scm_is_integer (s)) On 2011/08/19 18:04:38, Carl wrote: I think the old code here is correct, and the doc-string is wrong. Both are correct; the only difference is when Guile raises an error. In Bertrand's version, it's at the top of the code; in current master, it's in the block below when scm_to_int () is called. http://codereview.appspot.com/4917044/diff/1/lily/include/lily-guile.hh File lily/include/lily-guile.hh (right): http://codereview.appspot.com/4917044/diff/1/lily/include/lily-guile.hh#newcode96 lily/include/lily-guile.hh:96: // or scm_is_true (scm_exact_p (x)) ? Have you looked at the definition in the Guile repository (libguile/numbers.h)? It's a low-level function which returns true if the SCM object isn't an immediate (http://www.gnu.org/software/guile/manual/guile.html#Immediate-objects) and is tagged as a fraction (I think this only happens if scm_divide () creates a fraction) http://codereview.appspot.com/4917044/diff/1/lily/lily-guile.cc File lily/lily-guile.cc (right): http://codereview.appspot.com/4917044/diff/1/lily/lily-guile.cc#newcode229 lily/lily-guile.cc:229: return is_number_pair (p) ? ly_scm2interval is deliberately sloppy; it's assumed the caller has made sure the object is a number pair. If we're unsure, we use robust_scm2interval, which does the check then calls this function to perform the conversion. Adding this extra safety check will cause any robust_scm2interval call on a valid number-pair to get two checks. http://codereview.appspot.com/4917044/diff/1/lily/lily-guile.cc#newcode290 lily/lily-guile.cc:290: return is_number_pair (s) ? see comment for ly_scm2interval http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
On 2011/08/19 20:20:12, Neil Puttock wrote: http://codereview.appspot.com/4917044/diff/1/lily/include/lily-guile.hh File lily/include/lily-guile.hh (right): http://codereview.appspot.com/4917044/diff/1/lily/include/lily-guile.hh#newcode96 lily/include/lily-guile.hh:96: // or scm_is_true (scm_exact_p (x)) ? Have you looked at the definition in the Guile repository (libguile/numbers.h)? It's a low-level function I mean macro, of course. http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: oops! I've changed files in the `snippet' directory
On 18 August 2011 22:46, Reinhold Kainhofer reinh...@kainhofer.com wrote: BTW, I managed to get the LSR-copy running on my machine: http://lsr.kainhofer.at/LSR/ (the jail is set up but not yet used for compiling) HOWTO as usual at http://wiki.kainhofer.com/lilypond/lsr_setup Wow, that's awesome work, Reinhold. :) I've tried following the instructions, but can't get it to work properly. I think I've followed the instructions to the letter (apart from adding setcp.sh to the sh/ directory, since it's missing here: http://wiki.kainhofer.com/_media/lilypond/lsr/setcp.sh), but my jail refuses to mount when booting up and the LSR site isn't found when I type the URL into my browser. Any ideas? Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes boolean/SCM confusions, part 1. (issue 4875054)
On Fri, Aug 19, 2011 at 6:14 AM, Bertrand Bordage bordage.bertr...@gmail.com wrote: It is somewhat amusing, by the way, that Lilypond's to_boolean is required in order to let '() and #f be interpreted in the same manner. It would seem that Lisp's conflating them into `nil' is not the worst idea. This also mislead me a long time ago. It's a historical artefact of old lilypond code that would add objects to lists like set_property(foo, scm_cons(bla, get_property(foo)) for this to work, the default value of get_property() must be '(). For booleans, it's a reasonable default to be off, so we have to interpret '() as false. Scheme has a similar confusion in that all non-#f values are interpreted to be true. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \once \revert
Carl Sorensen wrote Friday, August 19, 2011 5:38 PM In fact, I think I would be in favor of removing \once \revert from the parser. The semantics of \once \revert can be confusing, and the same behavior could be achieved with a \once \override. I agree - it would be better to return a syntax error for \once \revert rather than invent or continue some obscure and unnecessary semantics. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3844 - Release Date: 08/19/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc File lily/general-scheme.cc (right): http://codereview.appspot.com/4917044/diff/1/lily/general-scheme.cc#newcode110 lily/general-scheme.cc:110: if (scm_is_integer (s)) On 2011/08/19 20:20:12, Neil Puttock wrote: On 2011/08/19 18:04:38, Carl wrote: I think the old code here is correct, and the doc-string is wrong. Both are correct; the only difference is when Guile raises an error. In Bertrand's version, it's at the top of the code; in current master, it's in the block below when scm_to_int () is called. OK, I see now. I withdraw my objection to these changes. As an aside, I think that we should change the definition of the property align-dir. It should no longer be called a direction, since it's not limited to the values -1, 0, and 1. But this is a discussion for another thread. Thanks! http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added \compoundMeter function to NR (issue 4837050)
LGTM. http://codereview.appspot.com/4837050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes boolean/SCM confusions, part 1. (issue 4875054)
Han-Wen Nienhuys hanw...@gmail.com writes: On Fri, Aug 19, 2011 at 6:14 AM, Bertrand Bordage bordage.bertr...@gmail.com wrote: It is somewhat amusing, by the way, that Lilypond's to_boolean is required in order to let '() and #f be interpreted in the same manner. It would seem that Lisp's conflating them into `nil' is not the worst idea. This also mislead me a long time ago. It's a historical artefact of old lilypond code that would add objects to lists like set_property(foo, scm_cons(bla, get_property(foo)) for this to work, the default value of get_property() must be '(). For booleans, it's a reasonable default to be off, so we have to interpret '() as false. It is not just an old artifact. If one wants to have a sensible interpretation for setting a nested property when the corresponding parent property has not been set yet, the parent property has to be assumed to default to an empty list, or you would not be able to inject a nested value. Since properties can be nested arbitrarily deep and we don't have a corresponding type system reaching below the top level, we can't infer different defaults for unset nested properties depending on the type (say #f for booleans, 0 for integers, '() for lists and alists). My implementation for nested properties deals with conflicts like (excuse the simplified syntax, I don't want to look this up all the time) \override Voice x.y #7 ; x.y is 7 \override Voice.x ##f; x.y is nonexistent \override Voice.x.y.z #3 ; x.y is '((z . 3)) by masking the Voice.x incompatible with nested properties and replacing it with '() effectively while a nested property is visible. So strictly speaking a default of '() is not necessary since a '() will introduce itself magically when it is mandatory. But it still makes things less strange. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents nested tuplets from colliding. (issue 4808082)
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-broken.ly
File input/regression/tuplet-nest-broken.ly (right):
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-broken.ly#newcode5
input/regression/tuplet-nest-broken.ly:5: texidoc = Broken nested
tuplets avoid each other correctly.
indent
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-broken.ly#newcode50
input/regression/tuplet-nest-broken.ly:50: \Voice \remove
Forbid_line_break_engraver
\Voice
\remove Forbid_line_break_engraver
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-force-shift-over-numbers.ly
File input/regression/tuplet-nest-force-shift-over-numbers.ly (right):
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-force-shift-over-numbers.ly#newcode17
input/regression/tuplet-nest-force-shift-over-numbers.ly:17: \times 2/3
{ a8 [a8 a8 ]}
a8[ a a] }
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-force-shift-over-numbers.ly#newcode29
input/regression/tuplet-nest-force-shift-over-numbers.ly:29: a a a a a
a4 a a a a
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-force-shift-over-numbers.ly#newcode31
input/regression/tuplet-nest-force-shift-over-numbers.ly:31: a
a4
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-force-shift-over-numbers.ly#newcode40
input/regression/tuplet-nest-force-shift-over-numbers.ly:40: a a a a a
a4 a a a a
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest-force-shift-over-numbers.ly#newcode42
input/regression/tuplet-nest-force-shift-over-numbers.ly:42: a
a4
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest.ly
File input/regression/tuplet-nest.ly (right):
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest.ly#newcode15
input/regression/tuplet-nest.ly:15: \times 2/3 { c8[ c8 c8] }
c8[ c c]
http://codereview.appspot.com/4808082/diff/13002/input/regression/tuplet-nest.ly#newcode21
input/regression/tuplet-nest.ly:21: \times 2/3 { a8[ a8 a8] }
a8[ a a]
http://codereview.appspot.com/4808082/diff/13002/lily/tuplet-bracket.cc
File lily/tuplet-bracket.cc (right):
http://codereview.appspot.com/4808082/diff/13002/lily/tuplet-bracket.cc#newcode283
lily/tuplet-bracket.cc:283: SCM scm_x_span = me-get_property
(X-positions);
I seem to recall we discussed the option of splitting control-points
into separate X/Y properties (can't remember exactly which grob it was
for :). My main concern was the naming since 'positions should be
changed to Y-positions, but this would be disruptive for other grobs.
http://codereview.appspot.com/4808082/diff/13002/lily/tuplet-bracket.cc#newcode669
lily/tuplet-bracket.cc:669: // have to re_run numbers to check for
number-on-number collisions
This is getting a bit complicated. Do you think it's feasible to have a
grob which would collect the colliding brackets and do the collision
avoidance as a separate positioning-done callback?
http://codereview.appspot.com/4808082/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
On Fri, Aug 19, 2011 at 06:04:38PM +, carl.d.soren...@gmail.com wrote: I have some comments about the docs. I think they're too tutorial, and I think the exhaustive lists are unwieldy and should be eliminated. THe source should be the reference. On the long term, I agree with Carl. In the short term, I think the docs should be pushed as-is. It's easy to make editorial fixes later; I want us (meaning Bertrand and the programmers commenting on this stuff) to get into the habit of archiving information first, and playing with formatting later. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates pure closures (issue 4894052)
http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly File input/regression/pure-closure.ly (right): http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly#newcode18 input/regression/pure-closure.ly:18: #(ly:make-pure-closure ly:stem::height '(-3 . 10)) I'm a bit worried this is too close to an extra-spacing-height override to make a good test example. http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc File lily/pure-closure.cc (right): http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode36 lily/pure-closure.cc:36: return (SCM) SCM_CELL_WORD_1 (smob); SCM_PACK (SCM_CELL_WORD_1 (smob)); (if you want to be strict :) http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode43 lily/pure-closure.cc:43: return (SCM) SCM_CELL_WORD_2 (smob); SCM_PACK (SCM_CELL_WORD_2 (smob)); http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode60 lily/pure-closure.cc:60: SCM_NEWSMOB2 (z, pure_closure_tag, unpure, pure); SCM_UNPACK (unpure), SCM_UNPACK (pure) http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode68 lily/pure-closure.cc:68: assert (is_pure_closure (pc)); optimized builds will segfault on invalid args, so you should use LY_ASSERT_TYPE () here http://codereview.appspot.com/4894052/diff/9001/lily/pure-closure.cc#newcode76 lily/pure-closure.cc:76: assert (is_pure_closure (pc)); LY_ASSERT_TYPE () http://codereview.appspot.com/4894052/diff/9001/scm/define-grobs.scm File scm/define-grobs.scm (left): http://codereview.appspot.com/4894052/diff/9001/scm/define-grobs.scm#oldcode2655 scm/define-grobs.scm:2655: (if (not (procedure? unpure)) I think you want this instead: (let ((pure (ly:pure-closure-pure-part unpure))) (if (not (procedure? pure)) pure (apply pure (append (list (car args) start end) (cdr args) http://codereview.appspot.com/4894052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates pure closures (issue 4894052)
On 18 August 2011 13:44, Mike Solomon mike...@ufl.edu wrote: What about pure-container ? It's all right, I suppose... but what about the unpure part? After all, the container's not just about the pure callback. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
On 2011/08/19 21:08:10, Carl wrote: As an aside, I think that we should change the definition of the property align-dir. It should no longer be called a direction, since it's not limited to the values -1, 0, and 1. It's unused. I think it's superseded by stacking-dir. Cheers, Neil http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
On 8/19/11 4:35 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Aug 19, 2011 at 06:04:38PM +, carl.d.soren...@gmail.com wrote: I have some comments about the docs. I think they're too tutorial, and I think the exhaustive lists are unwieldy and should be eliminated. THe source should be the reference. On the long term, I agree with Carl. In the short term, I think the docs should be pushed as-is. It's easy to make editorial fixes later; I want us (meaning Bertrand and the programmers commenting on this stuff) to get into the habit of archiving information first, and playing with formatting later. I totally agree. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
