Re: Implement Grob::event_cause, Grob::ultimate_event_cause (issue 559500043 by d...@gnu.org)
Reviewers: hahnjo, hanwenn, Dan Eble,
https://codereview.appspot.com/559500043/diff/559510043/lily/grob.cc
File lily/grob.cc (right):
https://codereview.appspot.com/559500043/diff/559510043/lily/grob.cc#newcode733
lily/grob.cc:733: while (unsmob (cause))
On 2020/02/21 00:13:25, Dan Eble wrote:
> I appreciate that issuing warnings is not performance-sensitive, and
that you
> simply transplanted this code, but what do you think about avoiding
repeating
> the unsmob, to set a good example? Something like ...
>
> while (const Grob *g = unsmob (cause))
> {
> cause = g->get_property ("cause");
> }
Not going to use const here since it is pointless while we have nothing
like const_unsmob, and would not use that order anyway since I consider
it misleading (it suggests a declaration of a constant, rather than a
pointer to a constant). Other than that, fine.
Description:
Implement Grob::event_cause, Grob::ultimate_event_cause
Those were implemented in Grob_info only previously which does not make
a lot of sense,
given that they don't access anything particular to Grob_info.
Also contains commit:
Use Grob::event_cause and Grob::ultimate_event_cause where useful
Frankly, this one has been bugging me on and off for years. I just
had one compilation error too much today.
Please review this at https://codereview.appspot.com/559500043/
Affected files (+42, -37 lines):
M lily/accidental-engraver.cc
M lily/accidental-placement.cc
M lily/grob.cc
M lily/grob-info.cc
M lily/include/grob.hh
M lily/lyric-engraver.cc
M lily/percent-repeat-item.cc
M lily/slur-engraver.cc
M lily/tie-engraver.cc
Index: lily/accidental-engraver.cc
diff --git a/lily/accidental-engraver.cc b/lily/accidental-engraver.cc
index
f15981ebb4f3d79f8f16ca073ef1c51935303413..877ec1cc5ba0c21d96fb808ab20d11d19741e06c
100644
--- a/lily/accidental-engraver.cc
+++ b/lily/accidental-engraver.cc
@@ -374,8 +374,8 @@ Accidental_engraver::stop_translation_timestep ()
{
// Don't mark accidentals as "tied" when the pitch is not
// actually the same. This is relevant for enharmonic ties.
- Stream_event *le = unsmob (l->get_property ("cause"));
- Stream_event *re = unsmob (r->get_property ("cause"));
+ Stream_event *le = l->event_cause ();
+ Stream_event *re = r->event_cause ();
if (le && re
&& !ly_is_equal (le->get_property ("pitch"), re->get_property
("pitch")))
continue;
Index: lily/accidental-placement.cc
diff --git a/lily/accidental-placement.cc b/lily/accidental-placement.cc
index
7965fcb4b9613399eca830f44a9087aa5709f1ee..e34bfb85293b1c55712d8fd3ac175d2169c2603c
100644
--- a/lily/accidental-placement.cc
+++ b/lily/accidental-placement.cc
@@ -39,9 +39,8 @@ using std::vector;
static Pitch *
accidental_pitch (Grob *acc)
{
- SCM cause = acc->get_parent (Y_AXIS)->get_property ("cause");
+ Stream_event *mcause = acc->get_parent (Y_AXIS)->event_cause ();
- Stream_event *mcause = unsmob (cause);
if (!mcause)
{
programming_error ("note head has no event cause");
Index: lily/grob-info.cc
diff --git a/lily/grob-info.cc b/lily/grob-info.cc
index
70e2ef55b4b966019f8b35e9f437d6637eea6ef0..9b1c265db31ceba86eb00caef323dda4b75319ff
100644
--- a/lily/grob-info.cc
+++ b/lily/grob-info.cc
@@ -46,8 +46,7 @@ Grob_info::Grob_info ()
Stream_event *
Grob_info::event_cause () const
{
- SCM cause = grob_->get_property ("cause");
- return unsmob (cause);
+ return grob_->event_cause ();
}
Context *
@@ -59,12 +58,7 @@ Grob_info::context () const
Stream_event *
Grob_info::ultimate_event_cause () const
{
- SCM cause = grob_->self_scm ();
- while (unsmob (cause))
-{
- cause = unsmob (cause)->get_property ("cause");
-}
- return unsmob (cause);
+ return grob_->ultimate_event_cause ();
}
bool
Index: lily/grob.cc
diff --git a/lily/grob.cc b/lily/grob.cc
index
a17869b00adf97f330d16ee23c887132899c780c..c4646b96b59d7bd6bb277e20438d19eef14bb126
100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -716,20 +716,36 @@ Grob::internal_vertical_less (Grob *g1, Grob *g2, bool
pure)
return false;
}
+/
+ CAUSES
+/
+Stream_event *
+Grob::event_cause () const
+{
+ SCM cause = get_property ("cause");
+ return unsmob (cause);
+}
+
+Stream_event *
+Grob::ultimate_event_cause () const
+{
+ SCM cause = self_scm ();
+ while (unsmob (cause))
+{
+ cause = unsmob (cause)->get_property ("cause");
+}
+ return unsmob (cause);
+}
+
+
+
/
MESSAGES
/
void
Grob::programming_error (const string ) const
{
- SCM cause = self_scm ();
- while (Grob *g = unsmob (cause))
-cause = g->get_property ("cause");
-
- /* ES TODO:
Re: Implement Grob::event_cause, Grob::ultimate_event_cause (issue 559500043 by d...@gnu.org)
LGTM
https://codereview.appspot.com/559500043/diff/559510043/lily/grob.cc
File lily/grob.cc (right):
https://codereview.appspot.com/559500043/diff/559510043/lily/grob.cc#newcode733
lily/grob.cc:733: while (unsmob (cause))
I appreciate that issuing warnings is not performance-sensitive, and
that you simply transplanted this code, but what do you think about
avoiding repeating the unsmob, to set a good example? Something like
...
while (const Grob *g = unsmob (cause))
{
cause = g->get_property ("cause");
}
https://codereview.appspot.com/559500043/
Re: Implement Grob::event_cause, Grob::ultimate_event_cause (issue 559500043 by d...@gnu.org)
LGTM https://codereview.appspot.com/559500043/
Re: Staging broken.
Here are the relevant parts of a correspondence between me and David. > > "We have a situation where catering to several versions of Pango has > > proven tricky to the degree of tripping you up." > > > > I think you see this patch as a proof that there is something > > inherently tricky about working with Pango. > > The old interface is deprecated in current version, you want to tackle > the warnings while the new interface is not available in all versions > that are supposed to be supported after the patch. > > That is not inherently tricky about working with Pango, it means that > the problem you are trying to tackle with the second one of the patches > just does not have a good single non-#ifdefed solution within the > version range you are trying to cover. That was not obvious from the > original patch without delving into Pango documentation. Can you read the patches again, carefully? Neither of the two patches change any functionality: HAVE_PANGO_FT2 is true since forever. The RAII patch just moves the same calls to the same deprecated function to a central place so there are less warnings. > > I disagree; there is nothing special about this; the only problem is > > that we need to get feedback of compiling against different Linux > > distributions before we submit code. By contrast, staring at the code > > longer, or letting it sit in countdown for more time is not going to > > help. > > An "I am going to just do this; anybody have a better idea? Otherwise I > am just going to go ahead." would help avoid the impression that one > considers other developers and their interests unnecessary baggage. > It's not formal countdown, will add perhaps half a day to the delay of > something that nobody knows to be urgent. And if it is urgent, just > mentioning the reason while going ahead will at least keep others in the > loop. > > Part of the staging system process is to remove the sense of urgency > that expresses itself in fixes shot from the hip and tends to get > tempers higher rather than lower. > > [..] > > If you feel that it's pointless for anybody to see whether the > dependencies can be resolved in a manner that appears more tenable for It's not pointless to improve this, but it's also not mutually exclusive with going ahead with the current 2 patches, which are semantic no-op cleanups. [..] So, yes, please put these back on staging. If you find it breaks somewhere somehow, I will come up with a way to fix and test it quickly. On Thu, Feb 20, 2020 at 8:28 PM Jonas Hahnfeld wrote: > > Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup: > > Jonas Hahnfeld < > > hah...@hahnjo.de > > > writes: > > > > > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup: > > > > David Kastrup < > > > > d...@gnu.org > > > > > > > > > writes: > > > > > Han-Wen Nienhuys < > > > > > hanw...@gmail.com > > > > > > > > > > > writes: > > > > > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys < > > > > > > hanw...@gmail.com > > > > > > > > > > > > > wrote: > > > > > > > > +// Necessary for supporting pango_context_new() and > > > > > > > > +// pango_context_set_font_map() in Pango < 1.22 > > > > > > > > +#define PANGO_ENABLE_BACKEND > > > > > > > > + > > > > > > > > > > > > > > > > > > > > > > .. > > > > > > > I'm preparing a docker image for my lilypond-ci scripts that lets > > > > > > > me check > > > > > > > for this case too. > > > > > > > > > > > > > > > > > > > I did this, see > > > > > > > > > > > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056 > > > > > > > > > > > > > > > > > > > > > > > > it reproduces the failure. I added a fix, and verified it passes on > > > > > > Ubuntu > > > > > > 19.04. > > > > > > > > > > > > I pushed it to staging. > > > > > > > > > > > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, > > > > > > but don't > > > > > > have time to investigate now. > > > > > > > > > > Could you explain the urgency warranting an immediate hotfix bypassing > > > > > all review, feedback and proper solution-finding? > > > > > > > > Moved this to dev/pango branch for now so that we have a chance to > > > > discuss this. > > > > > > For the record, you seem to have pushed to commits to staging -> master > > > again, right? > > > > Yes. Han-Wen and I had an off-list discussion about the impact of the > > changes, and they are at least not a regression in respect to the > > previous state we had, even if they cannot reduce the number of warnings > > in newer versions of Pango to zero while still supporting a range of > > older versions. > > May I ask to have such discussion on-list for the next time? That's why > we have a lilypond-devel, right? > > Jonas -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Let flex handle the input stack (issue 563560043 by jonas.hahnf...@gmail.com)
LGTM https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4#newcode556 aclocal.m4:556: # check for yyFlexLexer.yypop_buffer_state () since flex 2.5.29 On 2020/02/20 14:21:08, hahnjo wrote: > Random thought: Do we want to check for features introduced in 2003 or can we > just assume that we never come across ancient versions that don't support this? could we check the version number instead? https://codereview.appspot.com/563560043/
Re: lilypond.org now serving HTTPS
I think the automatic update of lilypond.org has stopped working. Let me look into it. On Thu, Feb 20, 2020 at 10:03 PM Joram Noeck wrote: > > > My browser complains about mixed content, i.e. http-linked media on the > > page. > > > > Urs > > Here (Firefox 73), the only warning is about the "Valid HTML 4.01" image > in the page footer. All other images (on the pages I looked at) have > relative src attributes and are served directly from lilypond.org via https. > > Joram > > > > PS: Btw, the only other warning I get is about -moz-border-radius which > was renamed to border-radius (without vendor prefix) in 2011 if I am not > mistaken. I also see commits that changed this in 2015¹, but perhaps > too late for the 2.18 website? Or I don't why the latest css is not served. > > > ¹: > https://github.com/lilypond/lilypond/commit/a6f369ae2efe399ef9644a702d98187e93129a87 -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Confirm grob-status in input/regression/multi-measure-rest-reminder.ly (issue 583530043 by thomasmorle...@gmail.com)
LGTM https://codereview.appspot.com/583530043/
flower: Drop unused functions (issue 563550046 by jonas.hahnf...@gmail.com)
LGTM https://codereview.appspot.com/563550046/
Re: lilypond.org now serving HTTPS
> My browser complains about mixed content, i.e. http-linked media on the
> page.
>
> Urs
Here (Firefox 73), the only warning is about the "Valid HTML 4.01" image
in the page footer. All other images (on the pages I looked at) have
relative src attributes and are served directly from lilypond.org via https.
Joram
PS: Btw, the only other warning I get is about -moz-border-radius which
was renamed to border-radius (without vendor prefix) in 2011 if I am not
mistaken. I also see commits that changed this in 2015¹, but perhaps
too late for the 2.18 website? Or I don't why the latest css is not served.
¹:
https://github.com/lilypond/lilypond/commit/a6f369ae2efe399ef9644a702d98187e93129a87
diff --git a/lilypond-manuals.css b/lilypond-manuals.css
index 995c217..8bff14a 100644
--- a/lilypond-manuals.css
+++ b/lilypond-manuals.css
@@ -450,9 +450,7 @@ div#search p, div#search form {
text-align: left;
padding: 0;
border: 1px solid green;
- /* Experimental rounded corners */
- -moz-border-radius: 10px;
- -webkit-border-radius: 10px;
+ border-radius: 10px;
margin: 1em;
}
@@ -461,8 +459,6 @@ div#search p, div#search form {
text-align: left;
padding: 0;
border: 1px solid green;
- /* Experimental rounded corners */
- -moz-border-radius: 10px;
- -webkit-border-radius: 10px;
+ border-radius: 10px;
margin: 0.5em 0.5em 2em 3em;
}
Re: lilypond.org now serving HTTPS
Am Donnerstag, den 13.02.2020, 18:48 +0100 schrieb Jean-Charles Malahieude: > Le 13/02/2020 à 15:10, Han-Wen Nienhuys a écrit : > > FYI, lilypond.org is now serving on HTTPS > > > > See here https://codereview.appspot.com/559470043/ for background. > > > > This should be applied on stable/2.20 as well. > > Cheers, > -- > Jean-Charles > My browser complains about mixed content, i.e. http-linked media on the page. Urs
Re: Staging broken.
Jonas Hahnfeld writes: > Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> >> > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup: >> > > David Kastrup < >> > > d...@gnu.org >> > > >> > > Moved this to dev/pango branch for now so that we have a chance to >> > > discuss this. >> > >> > For the record, you seem to have pushed to commits to staging -> master >> > again, right? >> >> Yes. Han-Wen and I had an off-list discussion about the impact of the >> changes, and they are at least not a regression in respect to the >> previous state we had, even if they cannot reduce the number of warnings >> in newer versions of Pango to zero while still supporting a range of >> older versions. > > May I ask to have such discussion on-list for the next time? That's why > we have a lilypond-devel, right? My description of the discussion was not complete. If it is deemed important enough, I can try extracting the technically relevant parts of it, but I am currently trying to at least manage translating the Changes file into German (for which I've seen no other volunteers) and I'd prefer to stay away from other emotionally draining tasks until I am through with that. -- David Kastrup
Re: Staging broken.
Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup: > > > David Kastrup < > > > d...@gnu.org > > > > > > > writes: > > > > Han-Wen Nienhuys < > > > > hanw...@gmail.com > > > > > > > > > writes: > > > > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys < > > > > > hanw...@gmail.com > > > > > > > > > > > wrote: > > > > > > > +// Necessary for supporting pango_context_new() and > > > > > > > +// pango_context_set_font_map() in Pango < 1.22 > > > > > > > +#define PANGO_ENABLE_BACKEND > > > > > > > + > > > > > > > > > > > > > > > > > > > .. > > > > > > I'm preparing a docker image for my lilypond-ci scripts that lets > > > > > > me check > > > > > > for this case too. > > > > > > > > > > > > > > > > I did this, see > > > > > > > > > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056 > > > > > > > > > > > > > > > > > > > > it reproduces the failure. I added a fix, and verified it passes on > > > > > Ubuntu > > > > > 19.04. > > > > > > > > > > I pushed it to staging. > > > > > > > > > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but > > > > > don't > > > > > have time to investigate now. > > > > > > > > Could you explain the urgency warranting an immediate hotfix bypassing > > > > all review, feedback and proper solution-finding? > > > > > > Moved this to dev/pango branch for now so that we have a chance to > > > discuss this. > > > > For the record, you seem to have pushed to commits to staging -> master > > again, right? > > Yes. Han-Wen and I had an off-list discussion about the impact of the > changes, and they are at least not a regression in respect to the > previous state we had, even if they cannot reduce the number of warnings > in newer versions of Pango to zero while still supporting a range of > older versions. May I ask to have such discussion on-list for the next time? That's why we have a lilypond-devel, right? Jonas signature.asc Description: This is a digitally signed message part
Re: Staging broken.
Jonas Hahnfeld writes: > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup: >> David Kastrup < >> d...@gnu.org >> > writes: >> >> > Han-Wen Nienhuys < >> > hanw...@gmail.com >> > > writes: >> > >> > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys < >> > > hanw...@gmail.com >> > > > wrote: >> > > >> > > > > +// Necessary for supporting pango_context_new() and >> > > > > +// pango_context_set_font_map() in Pango < 1.22 >> > > > > +#define PANGO_ENABLE_BACKEND >> > > > > + >> > > > > >> > > > >> > > > .. >> > > > I'm preparing a docker image for my lilypond-ci scripts that lets me >> > > > check >> > > > for this case too. >> > > > >> > > >> > > I did this, see >> > > >> > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056 >> > > >> > > >> > > it reproduces the failure. I added a fix, and verified it passes on >> > > Ubuntu >> > > 19.04. >> > > >> > > I pushed it to staging. >> > > >> > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but >> > > don't >> > > have time to investigate now. >> > >> > Could you explain the urgency warranting an immediate hotfix bypassing >> > all review, feedback and proper solution-finding? >> >> Moved this to dev/pango branch for now so that we have a chance to >> discuss this. > > For the record, you seem to have pushed to commits to staging -> master > again, right? Yes. Han-Wen and I had an off-list discussion about the impact of the changes, and they are at least not a regression in respect to the previous state we had, even if they cannot reduce the number of warnings in newer versions of Pango to zero while still supporting a range of older versions. If anybody can come up with a better/cleaner fix covering the intended version range, feel free to do so. -- David Kastrup
GSoC
Just to let you know: GNU has been accepted as a GSoC mentoring organization. a) This means that now people may visit https://lilypond.org/google-summer-of-code.html and look at our GSoC project ideas. So if anythingg could be added (or fixed or removed) there now would be the (latest) time to do so. b) If you know of any distribution channels for this information please share https://summerofcode.withgoogle.com/ https://www.gnu.org/software/soc-projects/ideas-2020.html and the link from a) Urs
Re: Staging broken.
Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup: > David Kastrup < > d...@gnu.org > > writes: > > > Han-Wen Nienhuys < > > hanw...@gmail.com > > > writes: > > > > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys < > > > hanw...@gmail.com > > > > wrote: > > > > > > > > +// Necessary for supporting pango_context_new() and > > > > > +// pango_context_set_font_map() in Pango < 1.22 > > > > > +#define PANGO_ENABLE_BACKEND > > > > > + > > > > > > > > > > > > > .. > > > > I'm preparing a docker image for my lilypond-ci scripts that lets me > > > > check > > > > for this case too. > > > > > > > > > > I did this, see > > > > > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056 > > > > > > > > > it reproduces the failure. I added a fix, and verified it passes on Ubuntu > > > 19.04. > > > > > > I pushed it to staging. > > > > > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but > > > don't > > > have time to investigate now. > > > > Could you explain the urgency warranting an immediate hotfix bypassing > > all review, feedback and proper solution-finding? > > Moved this to dev/pango branch for now so that we have a chance to > discuss this. For the record, you seem to have pushed to commits to staging -> master again, right? Jonas signature.asc Description: This is a digitally signed message part
Re: music-cause
David Kastrup writes:
> David Kastrup writes:
>
>> Graham Percival writes:
>>
>>> On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
Anybody actually using the "music-cause"? Inside of LilyPond, the only
appearance (apart from its declaration) would be
/*
ES TODO: This is a temporary fix. Stream_events should not be
aware of music.
*/
e->set_property ("music-cause", self_scm ());
>>>
>>> If it's used anywhere, it would be here:
>>> http://lilypond.org/website/pdf/thesis-erik-sandberg
>>>
>>> It may have been added just so he could produce some graphs or
>>> tables or something? I know that I have a ton of "graph-producing
>>> code" in Artifastring and Vivi like that.
>>
>> Seems somewhat pointless since events take the whole mutable property
>> list of their originating music event anyway. If you need more for
>> tracking, you could just do
>>
>> maketrackable =
>> #(define-music-function (parser location m)
>> (music-map
>> (lambda (m)
>>(set! ly:music-property 'music-cause m)
>>m)
>> m))
>>
>> and call that on your music before processing.
>
> I lean towards going through with my threat here and removing
> music-cause which seems like a weird punch-through kind of property.
> Any objections here? Anybody actually using it anywhere?
Darn it. I see that the edition engraver sets this somewhere, so
removing music-cause will possibly make the edition engraver bomb out.
Or do we check music properties (as a note aside: this is likely going
to happen with some change of mine that will eventually end up in
LilyPond, at the latest). I should have gone through when I asked
first: bad ideas are certain to get picked up eventually.
So what now?
--
David Kastrup
Re: music-cause
Am Donnerstag, den 20.02.2020, 17:12 +0100 schrieb David Kastrup:
> David Kastrup writes:
>
> > Graham Percival writes:
> >
> > > On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
> > > > Anybody actually using the "music-cause"? Inside of LilyPond,
> > > > the only
> > > > appearance (apart from its declaration) would be
> > > >
> > > > /*
> > > > ES TODO: This is a temporary fix. Stream_events should not
> > > > be
> > > > aware of music.
> > > > */
> > > > e->set_property ("music-cause", self_scm ());
> > >
> > > If it's used anywhere, it would be here:
> > > http://lilypond.org/website/pdf/thesis-erik-sandberg
> > >
> > > It may have been added just so he could produce some graphs or
> > > tables or something? I know that I have a ton of "graph-
> > > producing
> > > code" in Artifastring and Vivi like that.
> >
> > Seems somewhat pointless since events take the whole mutable
> > property
> > list of their originating music event anyway. If you need more for
> > tracking, you could just do
> >
> > maketrackable =
> > #(define-music-function (parser location m)
> > (music-map
> > (lambda (m)
> >(set! ly:music-property 'music-cause m)
> >m)
> > m))
> >
> > and call that on your music before processing.
>
> I lean towards going through with my threat here and removing
> music-cause which seems like a weird punch-through kind of property.
> Any objections here? Anybody actually using it anywhere?
>
It is used in openLilyLib a few times, I assume by Jan-Peter:
$ grep -rnw . -e 'music-cause'
./snippets/editorial-tools/auto-
transpose/module.ily:79: ; (ly:make-stream-event 'key-
change-event `((music-cause . ,key-sig)) ))
./snippets/editorial-tools/auto-transpose/module.ily:92:(cond-
transp engraver (ly:event-property event 'music-cause)))
./snippets/editorial-tools/auto-transpose/module.ily:95:(cond-
transp engraver (ly:event-property event 'music-cause)))
./edition-
engraver/engine.scm:944: (music-
cause . mod)
./lilypond-export/api.scm:147: ; search for music-cause of grob
./lilypond-export/api.scm:152: ((ly:stream-event? grob) (grob-
cause (ly:event-property grob 'music-cause)))
./lilypond-export/api.scm:205:(music (ly:event-property
event 'music-cause))
./lilypond-export/api.scm:468: (music (ly:event-property
event 'music-cause))
./oll-misc/pitch/auto-
transpose/module.ily:79: ; (ly:make-stream-event 'key-
change-event `((music-cause . ,key-sig)) ))
./oll-misc/pitch/auto-transpose/module.ily:92:(cond-transp
engraver (ly:event-property event 'music-cause)))
./oll-misc/pitch/auto-transpose/module.ily:95:(cond-transp
engraver (ly:event-property event 'music-cause)))
Re: music-cause
David Kastrup writes:
> Graham Percival writes:
>
>> On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
>>>
>>> Anybody actually using the "music-cause"? Inside of LilyPond, the only
>>> appearance (apart from its declaration) would be
>>>
>>> /*
>>> ES TODO: This is a temporary fix. Stream_events should not be
>>> aware of music.
>>> */
>>> e->set_property ("music-cause", self_scm ());
>>
>> If it's used anywhere, it would be here:
>> http://lilypond.org/website/pdf/thesis-erik-sandberg
>>
>> It may have been added just so he could produce some graphs or
>> tables or something? I know that I have a ton of "graph-producing
>> code" in Artifastring and Vivi like that.
>
> Seems somewhat pointless since events take the whole mutable property
> list of their originating music event anyway. If you need more for
> tracking, you could just do
>
> maketrackable =
> #(define-music-function (parser location m)
> (music-map
> (lambda (m)
>(set! ly:music-property 'music-cause m)
>m)
> m))
>
> and call that on your music before processing.
I lean towards going through with my threat here and removing
music-cause which seems like a weird punch-through kind of property.
Any objections here? Anybody actually using it anywhere?
--
David Kastrup
Implement Grob::event_cause, Grob::ultimate_event_cause (issue 559500043 by d...@gnu.org)
LGTM, nice cleanup https://codereview.appspot.com/559500043/
Remove redundant checks with C++11 (issue 583550043 by jonas.hahnf...@gmail.com)
Very nice, thanks! LGTM https://codereview.appspot.com/583550043/
Re: [translations] Re: 2.20.0 release coordination with translation, also Germans?
Il giorno gio 20 feb 2020 alle 15:21, David Kastrup ha scritto: I could not actually get any script to do anything helpful. I remember this being different at some point of time in the past. I use `make check-translation` regularly and has always worked. But you should be aware that: 1. you must run it in the Documentation/ dir 2. if you've configured an out-of-tree build (very likely as you are a developer), you'll probably get problems. So I think you should download the translation branch in a separate clean directory.
Re: 2.20.0 release coordination with translation, also Germans?
Federico Bruni writes: > Il giorno gio 20 feb 2020 alle 14:06, David Kastrup ha > scritto: >> In unrelated news, I tried my hand at translating at least the Changes >> file into German and am about 50% done. Anybody want to work from the >> bottom so that we should coordinate in order to avoid duplicate >> effort? >> I got kind of a headache so far. Hats off to people who tackle a >> whole >> translation rather than just a puny file. > > Indeed, it requires a strong commitment... it took me almost 10 years > to translate all the manuals! > > Translation infrastructure is another area which could be improved. > After 2.20 is out I'll try to bring it up for discussion. I could not actually get any script to do anything helpful. I remember this being different at some point of time in the past. -- David Kastrup
Let flex handle the input stack (issue 563560043 by jonas.hahnf...@gmail.com)
Reviewers: ,
https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4
File aclocal.m4 (right):
https://codereview.appspot.com/563560043/diff/567260043/aclocal.m4#newcode556
aclocal.m4:556: # check for yyFlexLexer.yypop_buffer_state () since flex
2.5.29
Random thought: Do we want to check for features introduced in 2003 or
can we just assume that we never come across ancient versions that don't
support this?
https://codereview.appspot.com/563560043/diff/567260043/lily/lexer.ll
File lily/lexer.ll (right):
https://codereview.appspot.com/563560043/diff/567260043/lily/lexer.ll#newcode753
lily/lexer.ll:753: {ANY_CHAR} {
David, you added this code in commit 6b0ff05318 ("Make lexer more robust
against unexpected EOF"). Do you have an idea what I have to do to end
up in this code path? I didn't manage to trigger so far :-( I think that
the new code is equivalent to the old one, but would prefer to check on
an example.
Description:
Let flex handle the input stack
This requires at least flex 2.5.29 released in 2003.
Prior cleanups:
1) Use Includable_lexer::new_input in Lily_lexer
Only Includable_lexer::new_input (const string &, Sources *) is virtual,
the method with type (const string &, const string &, Sources *) should
not be declared.
2) Deduplicate code from Includable_lexer::new_input
Please review this at https://codereview.appspot.com/563560043/
Affected files (+41, -87 lines):
M aclocal.m4
M config.hh.in
M lily/includable-lexer.cc
M lily/include/includable-lexer.hh
M lily/include/lily-lexer.hh
M lily/lexer.ll
M lily/lily-lexer.cc
Re: 2.20.0 release coordination with translation, also Germans? (was: [translations] 2.20 and 2.21 release plans)
Il giorno gio 20 feb 2020 alle 14:06, David Kastrup ha scritto: In unrelated news, I tried my hand at translating at least the Changes file into German and am about 50% done. Anybody want to work from the bottom so that we should coordinate in order to avoid duplicate effort? I got kind of a headache so far. Hats off to people who tackle a whole translation rather than just a puny file. Indeed, it requires a strong commitment... it took me almost 10 years to translate all the manuals! Translation infrastructure is another area which could be improved. After 2.20 is out I'll try to bring it up for discussion.
2.20.0 release coordination with translation, also Germans? (was: [translations] 2.20 and 2.21 release plans)
Federico Bruni writes: > Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni > ha scritto: >> I'm working on the italian update and I hope to be ready before >> Thursday night. >> > > Can we have one day delay? So deadline to push to translation branch > by Friday night? > I guess I won't have enough time to complete the update but at least I > can use some spare time tomorrow to get close to the goal. There was no fixed deadline. My goal was "this weekend", but if that makes things ugly, there is no point in not delaying some more days after the years we spent on this. In unrelated news, I tried my hand at translating at least the Changes file into German and am about 50% done. Anybody want to work from the bottom so that we should coordinate in order to avoid duplicate effort? I got kind of a headache so far. Hats off to people who tackle a whole translation rather than just a puny file. -- David Kastrup
Re: [translations] 2.20 and 2.21 release plans
Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni ha scritto: Il giorno lun 17 feb 2020 alle 22:35, David Kastrup ha scritto: Jean-Charles Malahieude writes: Le 17/02/2020 à 13:25, David Kastrup a écrit : Ok, I think 2.20 is basically done and we should push it out by the end of this week. This leaves a few days for the translation team to catch up with the current state. In particular HINT HINT HINT it gives the opportunity to native speakers of languages not as meticulously maintained as the currently most active translations to at least tackle the Changes document and maybe check a few other points of the web presence. This is more addressed to people reading this announcement on the lilypond-devel list than to lurkers on the translations list, though of course the latter would be equally welcome. I've planned to merge translation into stable on Thursday night, with the French part fully updated (lots of work with Werner's indexing). That sounds great. Well yes, the indexing changes have been very recent and pretty large. If anybody else feels like their work would benefit from a minor delay, please speak up. I'm working on the italian update and I hope to be ready before Thursday night. Can we have one day delay? So deadline to push to translation branch by Friday night? I guess I won't have enough time to complete the update but at least I can use some spare time tomorrow to get close to the goal.
