Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(184)

Issue 581600043: Issue 5740: Add \post to defer context actions to end of time step

Can't Edit
Can't Publish+Mail
Start Review
Created:
3 weeks, 2 days ago by Dan Eble
Modified:
3 weeks ago
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

https://sourceforge.net/p/testlilyissues/issues/5740/ I've carved this off of some experimental work that allows expressing in ly code the post-increment of a context property without sensitivity to the number of times the music that requests it is iterated. That is something that the rehearsal-mark engraver does, and I believe it can only be done currently by an engraver/performer. The implementation of \post is similar to the way \once reverts an effect at the end of the time step. In fact, I first implemented it the same way for the sake of simplicity; but after testing, I decided to complicate it. \once reversions naturally occur in reverse order, but it seems more natural for \post actions to run in the order given in the ly code. It also seems more natural for all \once reversions to precede all \post actions regardless of their order in the ly code. Because of those differences, they are handled separately. TODOs and questions: * Is \post per se worthy to be merged, or should I wait until the whole group of post-increment features is ready, which is possibly much later or never? It would be easier for me to finish \post and merge it so that I have less to rebase on a regular basis. Can you think of places that \post would be useful right now? * Test coverage is insufficient. I've provided a few cases to show the basic idea. * Are there editor configs that I need to update to say that \post is a built-in command? Other similar things? * Should this be called \post, \atEndOfTimeStep, or something else?

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+234 lines, -21 lines) Patch
A input/regression/set-once-post.ly View 1 chunk +42 lines, -0 lines 0 comments Download
A input/regression/set-post.ly View 1 chunk +23 lines, -0 lines 0 comments Download
M lily/apply-context-iterator.cc View 1 chunk +11 lines, -4 lines 0 comments Download
M lily/context.cc View 5 chunks +67 lines, -7 lines 0 comments Download
M lily/context-scheme.cc View 1 chunk +13 lines, -0 lines 0 comments Download
M lily/global-context.cc View 2 chunks +20 lines, -4 lines 0 comments Download
M lily/include/context.hh View 4 chunks +10 lines, -1 line 0 comments Download
M lily/include/global-context.hh View 1 chunk +9 lines, -1 line 0 comments Download
M lily/include/lily-imports.hh View 1 chunk +1 line, -0 lines 0 comments Download
M lily/lily-imports.cc View 1 chunk +1 line, -0 lines 0 comments Download
M lily/property-iterator.cc View 4 chunks +6 lines, -2 lines 0 comments Download
M ly/music-functions-init.ly View 1 chunk +24 lines, -0 lines 0 comments Download
M scm/define-context-properties.scm View 2 chunks +6 lines, -2 lines 0 comments Download
M scm/define-music-properties.scm View 1 chunk +1 line, -0 lines 0 comments Download

Messages

Total messages: 10
thomasmorley651
Hi Dan, I've difficulties to understand what this is about. And my lack of C++-knowledge ...
3 weeks, 2 days ago (2020-02-05 23:11:39 UTC) #1
hanwenn
I haven't looked in detail at the code, but I couldn't work out why you ...
3 weeks, 1 day ago (2020-02-06 09:28:20 UTC) #2
Dan Eble
The reviewers are turning the first question I asked around and asking it back to ...
3 weeks, 1 day ago (2020-02-06 14:29:55 UTC) #3
benko.pal
On 2020/02/06 14:29:55, Dan Eble wrote: > The reviewers are turning the first question I ...
3 weeks ago (2020-02-07 08:45:53 UTC) #4
hanwenn
On 2020/02/06 14:29:55, Dan Eble wrote: > The reviewers are turning the first question I ...
3 weeks ago (2020-02-07 09:19:03 UTC) #5
dak
On 2020/02/07 09:19:03, hanwenn wrote: > David mentions \cadenzaOff in the issue tracker. I think ...
3 weeks ago (2020-02-07 12:34:38 UTC) #6
hanwenn
On Fri, Feb 7, 2020 at 1:34 PM <dak@gnu.org> wrote: > On 2020/02/07 09:19:03, hanwenn ...
3 weeks ago (2020-02-07 12:58:07 UTC) #7
Dan Eble
On 2020/02/07 09:19:03, hanwenn wrote: > On 2020/02/06 14:29:55, Dan Eble wrote: > More code ...
3 weeks ago (2020-02-07 15:43:30 UTC) #8
dak
On 2020/02/07 15:43:30, Dan Eble wrote: > On 2020/02/07 09:19:03, hanwenn wrote: > > On ...
3 weeks ago (2020-02-07 16:00:48 UTC) #9
hanwenn
3 weeks ago (2020-02-07 16:03:38 UTC) #10
On Fri, Feb 7, 2020 at 4:43 PM <nine.fierce.ballads@gmail.com> wrote:

> On 2020/02/07 09:19:03, hanwenn wrote:
> > On 2020/02/06 14:29:55, Dan Eble wrote:
> > More code means more maintenance liability, so unless
> > it either solves a problem, or it simplifies the existing system, it
> would be a
> > net negative.
>
> You're preaching to the choir.
>

Thanks; sorry for the lecture.

> I would really like the problem defined before we try solving it.
> [...]
> > I hope I am not demoralizing you
>
> It's a good thing you threw in that last part, because from over here it
> was sounding rather like you resented my posting this for review.  I'll
> try to keep my reply descriptive.
>

 I was confused by the review, because it both claims to be experimental
("maybe never"), but also asks questions that are only relevant if this is
going to be a bona fide feature (editor configs, naming). The latter part
motivated the lecture.


I have seen that mailing-list discussions on detailed design--even for
> features people recognize they need, but especially for those they
> don't--do not go far or fast.  I suppose it's because few people have
> the level of familiarity, the current interest, or the time to devote to
> written communication on those topics.  I'm not blaming them; it's just
> my diagnosis.  Posting a review gives them something concrete to comment
> on, and that gets a discussion going.
>
> I have the sense that most of my successful contributions have gone this
> way.  Is this approach as effective as one that might be taken by a
> professional software development team?  No, but my code is in LilyPond.
>  Are the factors that make this the most effective approach in this
> context going to change?  Not likely.
>

You have a good point, but hopefully, I will be able to make enough time to
comment on technical feasibility so design questions can get better answers
henceforth.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b