Re: Issue 4419: Engraving ends too early (issue 252970043 by d...@gnu.org)
Reviewers: Dan Eble,
Message:
On 2015/07/10 02:56:43, Dan Eble wrote:
I haven't absorbed enough of the background knowledge on iteration to
say
credibly that this looks good, although the C++ looks fine.
Because this is a second try at fixing a problem, perhaps a regression
test
should be written or expanded to cover the case that the first try did
not.
Well, I'd like such a test to also cover issue 2608 which is not yet on
countdown. Making it part of _this_ issue would be a bad idea since
issue 2608 is a crash, and a regtest for a crash should not be committed
before the fix.
Description:
Issue 4419: Engraving ends too early
This is a followup on the solution for issue 2010 that was too eager
killing off unrelated iterators when an iterator in the vicinity of a
Lyric_combine_music_iterator died.
The salient point is to have Simultaneous_music_iterator::process_music
check for pending_moment () going from finite to infinite when
iterating, signifying the loss of an iterator defining an end point.
It happens to also fix issue 4339.
Also contains commit:
simplify Simultaneous_music_iterator::ok
Please review this at https://codereview.appspot.com/252970043/
Affected files (+12, -18 lines):
M lily/simultaneous-music-iterator.cc
Index: lily/simultaneous-music-iterator.cc
diff --git a/lily/simultaneous-music-iterator.cc
b/lily/simultaneous-music-iterator.cc
index
74f2d6dc9abbb2b14f182bbeeab5db6368f26a60..e892776b61a39e6f4814eb350500ab706a45c4ee
100644
--- a/lily/simultaneous-music-iterator.cc
+++ b/lily/simultaneous-music-iterator.cc
@@ -82,36 +82,33 @@ Simultaneous_music_iterator::construct_children ()
}
}
-// If there are non-run-always iterators and all of them die, take the
-// rest of them along.
+// If we have some iterators with definite next moment and no of them
+// remain after processing, we take the iterators with indefinite next
+// moment along. That makes sure that no Lyric_combine_music_iterator
+// will outstay its welcome (issue 2010).
+
void
Simultaneous_music_iterator::process (Moment until)
{
- bool had_good = false;
- bool had_bad = false;
SCM *proc = children_list_;
+ bool finite = !pending_moment ().main_part_.is_infinity ();
while (scm_is_pair (*proc))
{
Music_iterator *i = unsmobMusic_iterator (scm_car (*proc));
- bool run_always = i-run_always ();
- if (run_always || i-pending_moment () == until)
+ if (i-run_always () || i-pending_moment () == until)
i-process (until);
if (!i-ok ())
{
- if (!run_always)
-had_bad = true;
i-quit ();
*proc = scm_cdr (*proc);
}
else
{
- if (!run_always)
-had_good = true;
proc = SCM_CDRLOC (*proc);
}
}
- // If there were non-run-always iterators and all of them died, take
- // the rest of the run-always iterators along with them. They have
+ // If there were definite-ended iterators and all of them died, take
+ // the rest of the iterators along with them. They have
// likely lost their reference iterators. Basing this on the actual
// music contexts is not reliable since something like
// \new Voice = blah {
@@ -121,7 +118,7 @@ Simultaneous_music_iterator::process (Moment until)
// }
// cannot wait for the death of context blah before ending the
// simultaneous iterator.
- if (had_bad !had_good)
+ if (finite pending_moment ().main_part_.is_infinity ())
{
for (SCM p = children_list_; scm_is_pair (p); p = scm_cdr (p))
unsmobMusic_iterator (scm_car (p))-quit ();
@@ -147,16 +144,13 @@ Simultaneous_music_iterator::pending_moment () const
bool
Simultaneous_music_iterator::ok () const
{
- bool run_always_ok = false;
for (SCM s = children_list_; scm_is_pair (s); s = scm_cdr (s))
{
Music_iterator *it = unsmobMusic_iterator (scm_car (s));
- if (!it-run_always ())
+ if (it-ok ())
return true;
- else
-run_always_ok = run_always_ok || it-ok ();
}
- return run_always_ok;
+ return false;
}
bool
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement partial function calls. (issue 249670043 by d...@gnu.org)
On 2015/07/10 10:34:24, Trevor Daniels wrote: If I understand this correctly it permits a variable definition to be used in some circumstances where a music function definition would previously have been required to achieve the same effect. That seems a worthwhile improvement and simplification. Will this also work with \markup? e.g.: redBold = \markup \with-color #red \bold \incomplete \redBold text https://codereview.appspot.com/249670043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement partial function calls. (issue 249670043 by d...@gnu.org)
If I understand this correctly it permits a variable definition to be used in some circumstances where a music function definition would previously have been required to achieve the same effect. That seems a worthwhile improvement and simplification. Trevor https://codereview.appspot.com/249670043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement partial function calls. (issue 249670043 by d...@gnu.org)
Reviewers: Trevor Daniels, mark_opus11.net,
Message:
On 2015/07/10 10:34:24, Trevor Daniels wrote:
If I understand this correctly it permits a variable definition to be
used in
some circumstances where a music function definition would previously
have been
required to achieve the same effect.
Well, tiny correction: it just _looks_ like a variable definition. What
falls out is a music function definition (or event function or scheme
function, depending on what the last function call happens to be).
It's mostly syntactic sugar (arguments present in the definition are not
evaluated and typechecked again, so it's a bit better than open-coded
when looking at stuff like a long tweak cascade).
That seems a worthwhile improvement and simplification.
The main problem I see is that if your only tool is a hammer, you start
viewing your problems in terms of nails. This works for a cascade of
tweaks, but, say, not for overrides. So you make it work with an
override only to realize overrides don't cascade but are placed in
sequence. Oops. So you want
xxx = { ... \incomplete } as well. And so on.
So what I fear is that it's opening a can of worms because people would
like to be able to do more in that manner. And it might be hard to
stuff the genie back into its bottle again...
Description:
Implement partial function calls.
Contains two commits, see particularly the regtest as an example.
I'm not convinced this idea is as good as I thought when coming up
with it: it may be that this particular use case is not frequent
enough to warrant the complexity.
It seems nice for defining aliases like
tagv = \tag '(violinI violinII) \incomplete
or
important = \tweak color #red \tweak font-size 3 \incomplete
but I'm not sure that this warrants the effort.
Discuss.
Allow for chaining of several partial functions in a row
Chaining only works when all function calls except the last one have all
arguments supplied already, with their last argument being the rest of
the chained call.
Implement partial function calls
A partial function call acts as a function where the start of the
argument list has already been supplied. For example:
makeRed = \tweak color #red \incomplete
Then one can use this as
{ c' \makeRed d' e'-\makeRed -. }
Please review this at https://codereview.appspot.com/249670043/
Affected files (+161, -0 lines):
A input/regression/music-function-incomplete.ly
M lily/include/lily-imports.hh
M lily/lily-imports.cc
M lily/lily-lexer.cc
M lily/parser.yy
M scm/ly-syntax-constructors.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement partial function calls. (issue 249670043 by d...@gnu.org)
I appreciate your comment about this opening a can of worms, but I do like the simplification. Now I'll open a can of my own: instead of \incomplete, how about \etc? https://codereview.appspot.com/249670043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement partial function calls. (issue 249670043 by d...@gnu.org)
On 2015/07/11 02:24:58, Dan Eble wrote:
I appreciate your comment about this opening a can of worms, but I do
like the
simplification.
Now I'll open a can of my own: instead of \incomplete, how about \etc?
That's at least not overly likely to be used previously. Other
possibilities may be symbols like ; or so. ... is out since it is in
active use as part of durations. I thought of using \{ ... \} which has
the advantage of delimiting to the left as well, allowing
omit = \with-doc-string This does xxx \{ \tweak stencil #f \}
However, this does not seem overly important, one can do
omit = \tweak \stencil #f \etc
omit = \with-doc-string This does xxx #omit
Does not look as pretty, but which end user is going to set a doc string
on his functions?
And \{ ... \} seem nice to leave open for used-defined articulations.
https://codereview.appspot.com/249670043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement partial function calls. (issue 249670043 by d...@gnu.org)
On 2015/07/10 10:50:55, mark_opus11.net wrote: On 2015/07/10 10:34:24, Trevor Daniels wrote: If I understand this correctly it permits a variable definition to be used in some circumstances where a music function definition would previously have been required to achieve the same effect. That seems a worthwhile improvement and simplification. Will this also work with \markup? e.g.: redBold = \markup \with-color #red \bold \incomplete \redBold text A nice illustration of my can of worms theory. It would be quite straightforward to make this work for the case where there is only a final markup missing since the grammar already special-cases this kind of markup chain. But that would be a different issue, unrelated apart from employing the same reserved word. Markup commands are quite different from music functions. https://codereview.appspot.com/249670043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement partial function calls. (issue 249670043 by d...@gnu.org)
On 2015/07/10 11:17:37, dak wrote: On 2015/07/10 10:50:55, http://mark_opus11.net wrote: On 2015/07/10 10:34:24, Trevor Daniels wrote: If I understand this correctly it permits a variable definition to be used in some circumstances where a music function definition would previously have been required to achieve the same effect. That seems a worthwhile improvement and simplification. Will this also work with \markup? e.g.: redBold = \markup \with-color #red \bold \incomplete \redBold text A nice illustration of my can of worms theory. It would be quite straightforward to make this work for the case where there is only a final markup missing since the grammar already special-cases this kind of markup chain. Well, oopsy daisy. It's quite uncomplicated with regard to the grammar. But there is a tiny complication: as opposed to music functions et al, markup commands have a different namespace, are supported by the markup macro, and are not anonymous: defining a markup command does not just define one name but a whole slew of them. So redBold = ... cannot define a markup command (and never could). I could instead define a scheme command returning a markup. I think that those should work in comparable circumstances. https://codereview.appspot.com/249670043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement partial function calls. (issue 249670043 by d...@gnu.org)
On 2015/07/10 11:44:56, dak wrote: redBold = ... cannot define a markup command (and never could). I could instead define a scheme command returning a markup. I think that those should work in comparable circumstances. This is seriously funny. I happened to discover an old (more than a year) branch of mine lying around that very much does all of this with regard to markups and works around most of the related problems. It uses \default instead of \incomplete and the syntax rules use different names and places and concepts but it should be quite easy to fit that old branch in here: the work appears all done (though I don't know how much, if any, testing I did and whether or not this was in working state). Won't likely support the markup macro, though. https://codereview.appspot.com/249670043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove old News entry from home page
On Jul 9, 2015, at 5:39 AM, James p...@gnu.org wrote: Perhaps we can tweak the 'website' slightly (i.e. make small changes to the TexInfo code) to perhaps do something like moving some/all of the text from here http://lilypond.org/introduction.html to the front page/news and jig the menu (?) links around to fit? My thinking is that it would be good to move some or all of the examples page[1] to the main column of the home page where the news is now. That clearly shows what LilyPond can do, front and center. To me the full news listing seems less important to feature so prominently on the home page, so one idea would be for the news list to become a list of headlines in the home page side bar (possibly made wider) with each headline linking to that news entry on a separate news page. That separate news page could just be a slightly revised version of the current old news page[2] (i.e. just call it “News”). -Paul [1] http://lilypond.org/examples.html [2] http://lilypond.org/old-news.html ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove old News entry from home page
Am 10.07.2015 um 20:49 schrieb Paul Morris: On Jul 9, 2015, at 5:39 AM, James p...@gnu.org wrote: Perhaps we can tweak the 'website' slightly (i.e. make small changes to the TexInfo code) to perhaps do something like moving some/all of the text from here http://lilypond.org/introduction.html to the front page/news and jig the menu (?) links around to fit? My thinking is that it would be good to move some or all of the examples page[1] to the main column of the home page where the news is now. That clearly shows what LilyPond can do, front and center. +1 Marc To me the full news listing seems less important to feature so prominently on the home page, so one idea would be for the news list to become a list of headlines in the home page side bar (possibly made wider) with each headline linking to that news entry on a separate news page. That separate news page could just be a slightly revised version of the current old news page[2] (i.e. just call it “News”). -Paul [1] http://lilypond.org/examples.html [2] http://lilypond.org/old-news.html ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove old News entry from home page
Paul, et al, On Fri, Jul 10, 2015 at 12:49 PM, Paul Morris [via Lilypond] ml-node+s1069038n178576...@n5.nabble.com wrote: On Jul 9, 2015, at 5:39 AM, James [hidden email] http:///user/SendEmail.jtp?type=nodenode=178576i=0 wrote: Perhaps we can tweak the 'website' slightly (i.e. make small changes to the TexInfo code) to perhaps do something like moving some/all of the text from here http://lilypond.org/introduction.html to the front page/news and jig the menu (?) links around to fit? My thinking is that it would be good to move some or all of the examples page[1] to the main column of the home page where the news is now. That clearly shows what LilyPond can do, front and center. To me the full news listing seems less important to feature so prominently on the home page, so one idea would be for the news list to become a list of headlines in the home page side bar (possibly made wider) with each headline linking to that news entry on a separate news page. That separate news page could just be a slightly revised version of the current old news page[2] (i.e. just call it “News”). -Paul [1] http://lilypond.org/examples.html [2] http://lilypond.org/old-news.html I love this idea! What if, instead of moving all the contents from .../introduction.html or .../examples.html to the front page, we just brought over the secondary bar of links: [image: Inline image 1] That way visitors can quickly jump to Examples if they want, or Reviews, or Features, etc. On the other hand, if these could be set up in a tabbed format so that by clicking on one its contents would immediately appear below these links without the user leaving the homepage. I realize this isn't trivial, but it would be so much more visitor-friendly. Here's an image mock-up of what I'm thinking of (notice the News link at the top instead of Introduction): [image: Inline image 3] Just my 2 cents. - Abraham lilypond-website-mockup.png (391K) http://lilypond.1069038.n5.nabble.com/attachment/178578/0/lilypond-website-mockup.png image.png (12K) http://lilypond.1069038.n5.nabble.com/attachment/178578/1/image.png -- View this message in context: http://lilypond.1069038.n5.nabble.com/Re-Remove-old-News-entry-from-home-page-tp178527p178578.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
