Re: grob-property: if callback is independent of layout, call just once (issue 42190043)
On Dec 14, 2013, at 12:00 PM, d...@gnu.org wrote: > > https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc > File lily/unpure-pure-container.cc (right): > > https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc#newcode45 > lily/unpure-pure-container.cc:45: > On 2013/12/14 09:47:33, MikeSol wrote: >> Looking good. > >> The only thing is - how do we verify that this actually ignores start > and end? > > The function does not get passed start and end, so it has little choice > but to ignore them. > >> For example, let's say that there is a scheme function with optional > arguments >> for start and end that is used as the pure and unpure function. > > You are confused. If the second container element is _unbound_, which > is what is being checked here, the function in the first container will > _always_ be called without begin and end arguments. Ah, ok, didn’t know that. > >> It'll evaluate >> just fine for unpure cuz begin and end are optional. But begin and > end may be >> useful when it is pure. If this is the only function passed to the > constructor, >> it will return true for the function above and yet perhaps be an > operation that >> we don't want to cache. > >> Conversely, it is possible to do: > >> (ly:make-unpure-pure-container foo foo) > >> that should be cached but it would return false for this function. > > Well, but in this case the function foo will be called without begin/end > for the pure case and _with_ begin/end for the unpure case. Different > thing. > >> So, my proposal would be: > >> 1) if there is a single function, verify that it takes only one >> argument > > Doesn't matter. It will always get only one argument. Ok. > >> 2) if there are two functions, verify that the second takes only one > argument > >> All of this is of course predicated, like I said above, on being able > to check >> the number of arguments a scheme function takes, which may or may not > be >> possible... > > I would try to avoid this: the fine details here differ significantly > between GUILEv1 and GUILEv2, and it does not appear that you can rely on > this information being available at all or at least with the same > mechanism for functions defined in C in GUILEv2. So there is a large > danger that we would be painting us into a corner here. > > Once can, of course, call the function with three arguments and trap an > error (if one occurs). But error trapping is not likely efficient. > Sounds like more trouble than it’s worth. LGTM then. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grob-property: if callback is independent of layout, call just once (issue 42190043)
https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc File lily/unpure-pure-container.cc (right): https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc#newcode45 lily/unpure-pure-container.cc:45: On 2013/12/14 09:47:33, MikeSol wrote: Looking good. The only thing is - how do we verify that this actually ignores start and end? The function does not get passed start and end, so it has little choice but to ignore them. For example, let's say that there is a scheme function with optional arguments for start and end that is used as the pure and unpure function. You are confused. If the second container element is _unbound_, which is what is being checked here, the function in the first container will _always_ be called without begin and end arguments. It'll evaluate just fine for unpure cuz begin and end are optional. But begin and end may be useful when it is pure. If this is the only function passed to the constructor, it will return true for the function above and yet perhaps be an operation that we don't want to cache. Conversely, it is possible to do: (ly:make-unpure-pure-container foo foo) that should be cached but it would return false for this function. Well, but in this case the function foo will be called without begin/end for the pure case and _with_ begin/end for the unpure case. Different thing. So, my proposal would be: 1) if there is a single function, verify that it takes only one argument Doesn't matter. It will always get only one argument. 2) if there are two functions, verify that the second takes only one argument All of this is of course predicated, like I said above, on being able to check the number of arguments a scheme function takes, which may or may not be possible... I would try to avoid this: the fine details here differ significantly between GUILEv1 and GUILEv2, and it does not appear that you can rely on this information being available at all or at least with the same mechanism for functions defined in C in GUILEv2. So there is a large danger that we would be painting us into a corner here. Once can, of course, call the function with three arguments and trap an error (if one occurs). But error trapping is not likely efficient. Or create a new type predicate for a new class of functions instead of doing a boolean test (which seems like a pain...so I like the boolean approach above). https://codereview.appspot.com/42190043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
grob-property: if callback is independent of layout, call just once (issue 42190043)
https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc File lily/unpure-pure-container.cc (right): https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc#newcode45 lily/unpure-pure-container.cc:45: Looking good. The only thing is - how do we verify that this actually ignores start and end? For example, let's say that there is a scheme function with optional arguments for start and end that is used as the pure and unpure function. It'll evaluate just fine for unpure cuz begin and end are optional. But begin and end may be useful when it is pure. If this is the only function passed to the constructor, it will return true for the function above and yet perhaps be an operation that we don't want to cache. Conversely, it is possible to do: (ly:make-unpure-pure-container foo foo) that should be cached but it would return false for this function. So, my proposal would be: 1) if there is a single function, verify that it takes only one argument 2) if there are two functions, verify that the second takes only one argument All of this is of course predicated, like I said above, on being able to check the number of arguments a scheme function takes, which may or may not be possible... Or create a new type predicate for a new class of functions instead of doing a boolean test (which seems like a pain...so I like the boolean approach above). https://codereview.appspot.com/42190043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
