Re: Fix portuguese in all copies of utf-8.ly (issue 571640044 by hanw...@gmail.com)
> Werner, may I ask you to have a look? What exactly shall I check? https://codereview.appspot.com/571640044/
PATCHES - Countdown for February 18th
Hello, Here is the current patch countdown list. The next countdown will be on February 20th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ *** Push: 5765 Fix portuguese in all copies of utf-8.ly - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5765 http://codereview.appspot.com/571640044 5762 Remove log-clean target - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5762 http://codereview.appspot.com/561450044 5760 musicxml2ly: portugues notenames and quarternotes in español - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5760 http://codereview.appspot.com/571630043 5759 Avoid empty locale while building LilyPond. - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5759 http://codereview.appspot.com/571610043 5758 Update web infrastructure - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5758 http://codereview.appspot.com/559470043 5757 Add a RAII wrapper for extracting FT_Face from PangoFcFont - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5757 http://codereview.appspot.com/549560043 5756 Make Pango >= 1.36 mandatory. - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5756 http://codereview.appspot.com/565660044 5755 Remove unused ly_hash_scm - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5755 http://codereview.appspot.com/569340043 5754 Don't count terminating \0 in Source_file::length - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5754 http://codereview.appspot.com/579310043 5738 Doc: Some miscellaneous suggestions from Peter Toye - xmichael-k https://sourceforge.net/p/testlilyissues/issues/5738 http://codereview.appspot.com/579280043 5703 Run scripts/auxiliar/fixcc.py - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5703 http://codereview.appspot.com/549480043 Countdown: 5769 axis-group-interface: avoid some cast warnings - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5769 http://codereview.appspot.com/583510045 5768 Express define-markup-list-command-internal using define-markup-command-internal - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5768 http://codereview.appspot.com/555300043 5766 fix various warnings - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5766 http://codereview.appspot.com/583510043 5764 flower: Drop unused functions - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5764 http://codereview.appspot.com/563550046 5763 flower: Delete old files - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5763 http://codereview.appspot.com/571640043 Review: 5772 Confirm grob-status in input/regression/multi-measure-rest-reminder.ly - Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5772 http://codereview.appspot.com/547670044 5770 Generate dependency files with Clang - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5770 http://codereview.appspot.com/555300044 5747 input/regression/multi-measure-rest-reminder: a demo of user-defined grobs - Han-Wen Nienhuys https://sourceforge.net/p/testlilyissues/issues/5747 http://codereview.appspot.com/557380044 New: No new patches at this time. Waiting: 5771 remove unnecessary (descend-to-context ... 'Score) - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5771 http://codereview.appspot.com/557440043 5740 Add \post to defer context actions to end of time step - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5740 http://codereview.appspot.com/581600043 *** Regards, James
Re: 2.20 and 2.21 release plans
Urs Liska writes: > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: >> Ok, I think 2.20 is basically done and we should push it out by the >> end >> of this week. > > This is really great news! > I'm somewhat undecided whether it is a cause for celebration or not to > finally release a "stable" version after six years. But at the end of > the day I think we should praise those who have actually worked so hard > to make it happen. And all of us who benefit from that work might think > about what we can do to help bringing the *next* stable release over > the goal line in less than six years. > > I have one side remark to that, although I'm not sure if it's > appropriate to inject it into this thread. > > I haven't commented on the issue of a package loading mechanism > recently, for two reasons: I don't have any time right now, and I > thought it would be a distraction from the more pressing issues around > the build system, contribution workflow/tooling and finalizing a > release. > While it has been clear from the start that integrating a package > loading mechanism was not in question for 2.20.0, I would like to ask > if it can be considered making this go into a 2.20.x release and not > keep it on the 2.21 track as would be the natural itinerary. Doing so > (the latter) would force openLilyLib and - more importantly - > interfaces like Frescobaldi to support two alternative syntaxes of > loading packages until a 2.22 release. > So I would be glad if we could spend sufficient effort after 2.20.0 and > 2.21.0 releases to discussing, implementing, and testing a package > loading mechansim sufficiently that we can integrate it not only in the > 2.21.x but also a 2.20.x release. I don't think that would make a lot of sense since 2.21.x is the test and maturing bed for 2.22. But there is nobody forcing us to take 6 years for 2.22. Or 3.0. A fully functional package organisation system would in my opinion justify a major version number change. Also it does look like the next stable release is going to contain Guile 2+ support that is less of an abomination than what we have so far been able to provide. At any rate, I don't think it makes sense to nail down too many specifics of unreleased versions. Not if we want to end up more timely than this time round. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: 2.20 and 2.21 release plans
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > Ok, I think 2.20 is basically done and we should push it out by the > end > of this week. This is really great news! I'm somewhat undecided whether it is a cause for celebration or not to finally release a "stable" version after six years. But at the end of the day I think we should praise those who have actually worked so hard to make it happen. And all of us who benefit from that work might think about what we can do to help bringing the *next* stable release over the goal line in less than six years. I have one side remark to that, although I'm not sure if it's appropriate to inject it into this thread. I haven't commented on the issue of a package loading mechanism recently, for two reasons: I don't have any time right now, and I thought it would be a distraction from the more pressing issues around the build system, contribution workflow/tooling and finalizing a release. While it has been clear from the start that integrating a package loading mechanism was not in question for 2.20.0, I would like to ask if it can be considered making this go into a 2.20.x release and not keep it on the 2.21 track as would be the natural itinerary. Doing so (the latter) would force openLilyLib and - more importantly - interfaces like Frescobaldi to support two alternative syntaxes of loading packages until a 2.22 release. So I would be glad if we could spend sufficient effort after 2.20.0 and 2.21.0 releases to discussing, implementing, and testing a package loading mechansim sufficiently that we can integrate it not only in the 2.21.x but also a 2.20.x release. Urs > 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. > > What does this mean for 2.21.0? I think we should aim to push it out > fast afterwards, basically a few days later at most, just to get > kinks > with webpage/versioning from 2.20 ironed out. > > I am not sure it is realistic to expect to get the translations > merged > into 2.21.0 already: because of the significant divergence > experienced > so far, I expect this to be a significant merging headache. It would > be > nice to have, but not essential: this is the unstable branch after > all. > > For more extensive changes of internals and/or syntax, I would > recommend > to let them sit till 2.21.1 before committing, assuming that we _do_ > manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite > significantly diverged from 2.20.0. If something does not quite > work, > it would be nice to have a _released_ version to compare to, and > nothing > but 2.21.0 would really serve that role satisfactorily. Particularly > where problems are detected a long time after getting introduced, > having > an installable version as a reference is nice, and "it stopped > working > in 2.21.0" is enough of a quagmire already that we do not really want > to > add a lot more here. > > The size of the headache basically is commensurate with how long the > stable branch has diverged. Hopefully we manage to find some > combination of process and responsible persons next time around that > delivers faster. > > Nevertheless, I am glad we are getting there. >
Re: lilypond-darwin-64 app doesn't work on Mac OS Lion
>> LilyPond Error > > Does it ship with Python, or using the native? The 2.19.83 from the > site uses 2.6, not 2.7. > python --version Python 2.7.17 Werner
Re: Fix portuguese in all copies of utf-8.ly (issue 571640044 by hanw...@gmail.com)
On 2020/02/15 21:41:57, thomasmorley651 wrote: > https://codereview.appspot.com/571640044/diff/571650043/Documentation/snippets/utf-8.ly > File Documentation/snippets/utf-8.ly (right): > > https://codereview.appspot.com/571640044/diff/571650043/Documentation/snippets/utf-8.ly#newcode1 > Documentation/snippets/utf-8.ly:1: % DO NOT EDIT this file manually; it is > automatically > Makes no sense to fix this snippet here. > It is superseded by the snippet in Documentation/snippets/new. > Furthermore next LSR-import would override it again. > Thus the fix should be done in LSR. > > Alas, LSR seems down, atm... LSR is up again. Though, I'm puzzled how characters are displayed. I feel unable to fix it. Werner, may I ask you to have a look? https://codereview.appspot.com/571640044/
Re: [translations] 2.20 and 2.21 release plans
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.
Re: [translations] 2.20 and 2.21 release plans
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. -- David Kastrup
Re: [translations] 2.20 and 2.21 release plans
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). Cheers, -- Jean-Charles
Confirm grob-status in input/regression/multi-measure-rest-reminder.ly (issue 547670044 by thomasmorle...@gmail.com)
Reviewers: ,
Description:
Confirm grob-status in input/regression/multi-measure-rest-reminder.ly
Oversight
Please review this at https://codereview.appspot.com/547670044/
Affected files (+2, -0 lines):
M input/regression/multi-measure-rest-reminder.ly
Index: input/regression/multi-measure-rest-reminder.ly
diff --git a/input/regression/multi-measure-rest-reminder.ly
b/input/regression/multi-measure-rest-reminder.ly
index
111d6965f478f3c9bca6698706447686b11fbdcf..07e5c56ea9c0ec1b9ebdbf9175d691d71778df1a
100644
--- a/input/regression/multi-measure-rest-reminder.ly
+++ b/input/regression/multi-measure-rest-reminder.ly
@@ -24,6 +24,8 @@ multiMeasureReminderEngraver =
% Set the type of MultiMeasureRestReminder so we can assign to it.
#(set-object-property! 'MultiMeasureRestReminder 'translation-type?
ly:grob-properties?)
+% Confirm MultiMeasureRestReminder is a grob syntactically.
+#(set-object-property! 'MultiMeasureRestReminder 'is-grob? #t)
\layout {
\context {
Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)
On 2020/02/17 10:01:29, hanwenn wrote: > https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly > File input/regression/multi-measure-rest-reminder.ly (right): > > https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly#newcode26 > input/regression/multi-measure-rest-reminder.ly:26: #(set-object-property! > 'MultiMeasureRestReminder 'translation-type? ly:grob-properties?) > On 2020/02/16 13:45:30, thomasmorley651 wrote: > > To make further overrides possible, add: > > #(set-object-property! 'MultiMeasureRestReminder 'is-grob? #t) > > > > Would solve the issue in my recent comment > > Feel free to send a change! Done. https://sourceforge.net/p/testlilyissues/issues/5772/ https://codereview.appspot.com/547670044 https://codereview.appspot.com/557380044/
Re: Issue 5771: simplify \partial (issue 557440043 by nine.fierce.ball...@gmail.com)
On 2020/02/17 19:17:04, Dan Eble wrote: > On 2020/02/17 18:41:58, dak wrote: > > Are you sure this is actually a working idea? At the beginning of music, > Score > > does not exist and 'Timing is only (reliably?) established as an alias by the > > Timing_translator. For polyrhythmic pieces, the Timing context alias is moved > > down the hierarchy along with the Timing_translator. > > What I'm sure of is that the stated scenario for using descend-to-context here > was "the Timing_translator is moved," that > input/regression/partial-polymetric.ly moves the Timing_translator, and this > patch did not make any change in the regression tests. I won't claim that there > is full coverage because I didn't investigate that thoroughly. > > About the alias: I see this in the Score definition in ly/engraver-init.ly: > > \alias "Timing" > > %% An alias for Timing is established by the Timing_translator in > %% whatever context it is initialized, and the timing variables are > %% then copied from wherever Timing had been previously established. > %% The alias at Score level provides a target for initializing > %% Timing variables in layout definitions before any > %% Timing_translator has been run. > > The only state in which (descend-to-context ... 'Score) should have an effect is > when the current context is Global. In any other state, it should change > nothing. And if the current context is Global, (context-spec-music ... 'Timing) > should find-or-create the Score because of the alias; descending to Score first > should not be necessary. Well, with a bit of juggling around things I have not been able to trigger a difference. I am a bit skeptical that that means nobody else can: we have inventive users and the startup of Timing has been one area where combinations of things like \skip, \partial and \time have managed to create crashes. Since we have various other context-related changes slated in 2.21.0, this is one of the cases where I'd likely be happier if the final push had this change end up in 2.21.1. https://codereview.appspot.com/557440043/
Re: Issue 5771: simplify \partial (issue 557440043 by nine.fierce.ball...@gmail.com)
On 2020/02/17 18:41:58, dak wrote: > Are you sure this is actually a working idea? At the beginning of music, Score > does not exist and 'Timing is only (reliably?) established as an alias by the > Timing_translator. For polyrhythmic pieces, the Timing context alias is moved > down the hierarchy along with the Timing_translator. What I'm sure of is that the stated scenario for using descend-to-context here was "the Timing_translator is moved," that input/regression/partial-polymetric.ly moves the Timing_translator, and this patch did not make any change in the regression tests. I won't claim that there is full coverage because I didn't investigate that thoroughly. About the alias: I see this in the Score definition in ly/engraver-init.ly: \alias "Timing" %% An alias for Timing is established by the Timing_translator in %% whatever context it is initialized, and the timing variables are %% then copied from wherever Timing had been previously established. %% The alias at Score level provides a target for initializing %% Timing variables in layout definitions before any %% Timing_translator has been run. The only state in which (descend-to-context ... 'Score) should have an effect is when the current context is Global. In any other state, it should change nothing. And if the current context is Global, (context-spec-music ... 'Timing) should find-or-create the Score because of the alias; descending to Score first should not be necessary. https://codereview.appspot.com/557440043/
Re: Issue 5771: simplify \partial (issue 557440043 by nine.fierce.ball...@gmail.com)
https://codereview.appspot.com/557440043/diff/547670043/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/557440043/diff/547670043/ly/music-functions-init.ly#newcode1319 ly/music-functions-init.ly:1319: 'origin (*location*) On 2020/02/17 16:59:54, Dan Eble wrote: > I'm curious about when it is important to provide 'origin (*location*) to > make-music and when it is not. Some functions do it and some don't. define-music-function tacks the origin on the top-level music expression it returns. In this case here, that does not help. Are you sure this is actually a working idea? At the beginning of music, Score does not exist and 'Timing is only (reliably?) established as an alias by the Timing_translator. For polyrhythmic pieces, the Timing context alias is moved down the hierarchy along with the Timing_translator. https://codereview.appspot.com/557440043/
Re: lilypond-darwin-64 app doesn't work on Mac OS Lion
> On 17 Feb 2020, at 17:04, Werner LEMBERG wrote: > > > For fun I tried to execute > > > https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83/2.19.83.build20200207173449 > > on my old MacOS Lion box, with the following error. > > Traceback (most recent call last): > … > ImportError: dlopen(.../LilyPond > 2.app/Contents/Resources/lib/python2.7/lib-dynload/ob > jc/_objc.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject >Referenced from: .../LilyPond > 2.app/Contents/Resources/lib/python2.7/lib-dynload/obj > c/_objc.so >Expected in: /usr/lib/libobjc.A.dylib > in .../LilyPond > 2.app/Contents/Resources/lib/python2.7/lib-dynload/objc/_objc.so > LilyPond Error Does it ship with Python, or using the native? The 2.19.83 from the site uses 2.6, not 2.7.
Issue 5771: simplify \partial (issue 557440043 by nine.fierce.ball...@gmail.com)
Reviewers: , https://codereview.appspot.com/557440043/diff/547670043/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/557440043/diff/547670043/ly/music-functions-init.ly#newcode1319 ly/music-functions-init.ly:1319: 'origin (*location*) I'm curious about when it is important to provide 'origin (*location*) to make-music and when it is not. Some functions do it and some don't. Description: https://sourceforge.net/p/testlilyissues/issues/5771/ Remove an unnecessary (descend-to-context ... 'Score). I started looking for a reason for this code, but I lost interest once I saw how old it is. input/regression/partial-polymetric.ly seems to cover the relevant case, and it still passes after removing this code. Please review this at https://codereview.appspot.com/557440043/ Affected files (+7, -14 lines): M ly/music-functions-init.ly M scm/define-music-display-methods.scm Index: ly/music-functions-init.ly diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly index f3893fab2ffb4062d60f496e63b978195b858c7c..42c1075f13c657bf38dbbc196b3fe6dfafd83cb3 100644 --- a/ly/music-functions-init.ly +++ b/ly/music-functions-init.ly @@ -1315,15 +1315,10 @@ that they share a staff with stems directed downward.") partial = #(define-music-function (dur) (ly:duration?) (_i "Make a partial measure.") - - ;; We use `descend-to-context' here instead of `context-spec-music' to - ;; ensure \partial still works if the Timing_translator is moved -(descend-to-context - (context-spec-music (make-music 'PartialSet - 'origin (*location*) - 'duration dur) - 'Timing) - 'Score)) + (context-spec-music (make-music 'PartialSet + 'origin (*location*) + 'duration dur) + 'Timing)) pitchedTrill = #(define-music-function Index: scm/define-music-display-methods.scm diff --git a/scm/define-music-display-methods.scm b/scm/define-music-display-methods.scm index 3516286c17def21193ce9074a17433e2b2171bb1..5cead5e0a1b9dfddad73d39356c47d49562391b7 100644 --- a/scm/define-music-display-methods.scm +++ b/scm/define-music-display-methods.scm @@ -988,12 +988,10 @@ Otherwise, return #f." Otherwise, return #f." (with-music-match (expr (music 'ContextSpeccedMusic + context-type 'Timing element (music -'ContextSpeccedMusic -context-type 'Timing -element (music - 'PartialSet - duration ?duration +'PartialSet +duration ?duration))) (and ?duration (format #f "\\partial ~a"
lilypond-darwin-64 app doesn't work on Mac OS Lion
For fun I tried to execute https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83/2.19.83.build20200207173449 on my old MacOS Lion box, with the following error. Traceback (most recent call last): File ".../LilyPond 2.app/Contents/Resources/__boot__.py", line 98, in _run() File ".../LilyPond 2.app/Contents/Resources/__boot__.py", line 82, in _run exec(compile(source, path, 'exec'), globals(), globals()) File ".../LilyPond 2.app/Contents/Resources/LilyPond.py", line 3, in from PyObjCTools import AppHelper File "PyObjCTools/AppHelper.pyc", line 14, in File "AppKit/__init__.pyc", line 8, in File "objc/__init__.pyc", line 18, in File "objc/__init__.pyc", line 15, in _update File "objc/_objc.pyc", line 14, in File "objc/_objc.pyc", line 10, in __load ImportError: dlopen(.../LilyPond 2.app/Contents/Resources/lib/python2.7/lib-dynload/ob jc/_objc.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject Referenced from: .../LilyPond 2.app/Contents/Resources/lib/python2.7/lib-dynload/obj c/_objc.so Expected in: /usr/lib/libobjc.A.dylib in .../LilyPond 2.app/Contents/Resources/lib/python2.7/lib-dynload/objc/_objc.so LilyPond Error Not sure whether this platform is supported at all... If not it would be nice if a sensible error message could be emitted instead of this error. Werner
Re: 2.20 and 2.21 release plans
Jonas Hahnfeld writes: > Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup: > >> Yes, GUB for 2.21.0. We don't want to have another indeterminate >> backlog on unstable releases. That means that GUB needs to get switched >> over to Python 3. > > For those following along: It's not that we need to convert GUB to > Python 3, just switch the dependencies of the LilyPond spec. > >> It may make it more prudent, should we need to >> release 2.20.1 at some time, to also go to the cherry-picking nightmare >> required to bring stable/2.20 up to Python 3. > > My point of view remains: Just keep an old version of GUB around and > we're fine for 2.20.x, x > 0. In the end, it will depend on how it works out for the person creating the releases, I guess. -- David Kastrup
Re: 2.20 and 2.21 release plans
Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > > > 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. > > > > Wohoo! > > > > > [...] > > > > > > What does this mean for 2.21.0? I think we should aim to push it out > > > fast afterwards, basically a few days later at most, just to get kinks > > > with webpage/versioning from 2.20 ironed out. > > > > > > [...] > > > > > > For more extensive changes of internals and/or syntax, I would recommend > > > to let them sit till 2.21.1 before committing, assuming that we _do_ > > > manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite > > > significantly diverged from 2.20.0. If something does not quite work, > > > it would be nice to have a _released_ version to compare to, and nothing > > > but 2.21.0 would really serve that role satisfactorily. Particularly > > > where problems are detected a long time after getting introduced, having > > > an installable version as a reference is nice, and "it stopped working > > > in 2.21.0" is enough of a quagmire already that we do not really want to > > > add a lot more here. > > > > Sounds good (well, Python 3 is already in). To be sure: This also means > > we'll be using GUB for 2.21.0? I'd like to propose a new system (yes, > > *with* support for Windows) soon, but not sure that I can make it in > > the next week or so... > > Yes, GUB for 2.21.0. We don't want to have another indeterminate > backlog on unstable releases. That means that GUB needs to get switched > over to Python 3. For those following along: It's not that we need to convert GUB to Python 3, just switch the dependencies of the LilyPond spec. > It may make it more prudent, should we need to > release 2.20.1 at some time, to also go to the cherry-picking nightmare > required to bring stable/2.20 up to Python 3. My point of view remains: Just keep an old version of GUB around and we're fine for 2.20.x, x > 0. Jonas signature.asc Description: This is a digitally signed message part
Re: 2.20 and 2.21 release plans
Jonas Hahnfeld writes: > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: >> 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. > > Wohoo! > >> [...] >> >> What does this mean for 2.21.0? I think we should aim to push it out >> fast afterwards, basically a few days later at most, just to get kinks >> with webpage/versioning from 2.20 ironed out. >> >> [...] >> >> For more extensive changes of internals and/or syntax, I would recommend >> to let them sit till 2.21.1 before committing, assuming that we _do_ >> manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite >> significantly diverged from 2.20.0. If something does not quite work, >> it would be nice to have a _released_ version to compare to, and nothing >> but 2.21.0 would really serve that role satisfactorily. Particularly >> where problems are detected a long time after getting introduced, having >> an installable version as a reference is nice, and "it stopped working >> in 2.21.0" is enough of a quagmire already that we do not really want to >> add a lot more here. > > Sounds good (well, Python 3 is already in). To be sure: This also means > we'll be using GUB for 2.21.0? I'd like to propose a new system (yes, > *with* support for Windows) soon, but not sure that I can make it in > the next week or so... Yes, GUB for 2.21.0. We don't want to have another indeterminate backlog on unstable releases. That means that GUB needs to get switched over to Python 3. It may make it more prudent, should we need to release 2.20.1 at some time, to also go to the cherry-picking nightmare required to bring stable/2.20 up to Python 3. Definitely a holdup I would not have wanted for 2.20.0. If we want to switch over to a different release method, we can do that comfortably without unstable releases being blocked. Whether we want to eventually bring out a 2.20 version in that manner too (which might bring different platform support) or save it for 2.22 or whenever is something I don't think we should try pinning down now. >> The size of the headache basically is commensurate with how long the >> stable branch has diverged. Hopefully we manage to find some >> combination of process and responsible persons next time around that >> delivers faster. > > To throw this idea onto the mailing list: Time-based releases seem to > encourage a predictable schedule. I don't think it makes sense to have > monthly stable releases as, for example, GitLab does. But maybe > tracking something like once in a year to 18 months with defined > windows for alpha and beta releases? We have to see how this pans out. The last release cycle saw something like a half-year blockage due to GUB problems. It's not like anybody wanted this to keep up for as long as it did. And there is no point in committing to schedules if there are no persons tied into the commitment. It's not like I didn't offer the release manager job for grabs several times round with no takers. Committing to regular schedules with me as sole release manager candidate is a predictable setup for disappointment. -- David Kastrup
Re: 2.20 and 2.21 release plans
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > 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. Wohoo! > [...] > > What does this mean for 2.21.0? I think we should aim to push it out > fast afterwards, basically a few days later at most, just to get kinks > with webpage/versioning from 2.20 ironed out. > > [...] > > For more extensive changes of internals and/or syntax, I would recommend > to let them sit till 2.21.1 before committing, assuming that we _do_ > manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite > significantly diverged from 2.20.0. If something does not quite work, > it would be nice to have a _released_ version to compare to, and nothing > but 2.21.0 would really serve that role satisfactorily. Particularly > where problems are detected a long time after getting introduced, having > an installable version as a reference is nice, and "it stopped working > in 2.21.0" is enough of a quagmire already that we do not really want to > add a lot more here. Sounds good (well, Python 3 is already in). To be sure: This also means we'll be using GUB for 2.21.0? I'd like to propose a new system (yes, *with* support for Windows) soon, but not sure that I can make it in the next week or so... > The size of the headache basically is commensurate with how long the > stable branch has diverged. Hopefully we manage to find some > combination of process and responsible persons next time around that > delivers faster. To throw this idea onto the mailing list: Time-based releases seem to encourage a predictable schedule. I don't think it makes sense to have monthly stable releases as, for example, GitLab does. But maybe tracking something like once in a year to 18 months with defined windows for alpha and beta releases? Jonas signature.asc Description: This is a digitally signed message part
2.20 and 2.21 release plans
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. What does this mean for 2.21.0? I think we should aim to push it out fast afterwards, basically a few days later at most, just to get kinks with webpage/versioning from 2.20 ironed out. I am not sure it is realistic to expect to get the translations merged into 2.21.0 already: because of the significant divergence experienced so far, I expect this to be a significant merging headache. It would be nice to have, but not essential: this is the unstable branch after all. For more extensive changes of internals and/or syntax, I would recommend to let them sit till 2.21.1 before committing, assuming that we _do_ manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite significantly diverged from 2.20.0. If something does not quite work, it would be nice to have a _released_ version to compare to, and nothing but 2.21.0 would really serve that role satisfactorily. Particularly where problems are detected a long time after getting introduced, having an installable version as a reference is nice, and "it stopped working in 2.21.0" is enough of a quagmire already that we do not really want to add a lot more here. The size of the headache basically is commensurate with how long the stable branch has diverged. Hopefully we manage to find some combination of process and responsible persons next time around that delivers faster. Nevertheless, I am glad we are getting there. -- David Kastrup
Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)
On 2020/02/17 10:01:29, hanwenn wrote: > https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly > File input/regression/multi-measure-rest-reminder.ly (right): > > https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly#newcode26 > input/regression/multi-measure-rest-reminder.ly:26: #(set-object-property! > 'MultiMeasureRestReminder 'translation-type? ly:grob-properties?) > On 2020/02/16 13:45:30, thomasmorley651 wrote: > > To make further overrides possible, add: > > #(set-object-property! 'MultiMeasureRestReminder 'is-grob? #t) > > > > Would solve the issue in my recent comment > > Feel free to send a change! > > I don't understand why we need is-grob? if the symbol is already marked with > translation-type? == ly:grob-properties? > > David? Comparatively unrelated things. At any rate, "the symbol is marked" is historical baggage and we should instead of using "object-properties" use an explicit weak hashtable for such things since that would make it possible to _reset_ the hashtable between user files and thus make sure that user-defined properties don't bleed from one file to the next. I just haven't got around to doing this change yet which will break all user-created grobs (and some other things implemented in the same manner) and provide a more official way of extension. At any rate, is-grob? is the way of checking that something is a grob name syntactically. translation-type?, in contrast, is the type of the context property storing the current grob definition. Historically, this was an alist I think, and mixing \set and \override on the same property consequently could cause fascinating crashes. Using the alist directly did not allow for reliably overriding and reverting nested context properties. People patched around that area for years, further obfuscating the logical impossibility of getting this done correctly and getting the errors to become more obscure and trigger in different circumstances. So at one point of time, I introduced the ly:grob-properties? data structure tracking nested overrides separately and "cooking" the resulting alist only on an as-needed base. That it is needed for nothing else is not inherently related to it being tied to a named grob. https://codereview.appspot.com/557380044/
Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)
https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly File input/regression/multi-measure-rest-reminder.ly (right): https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly#newcode26 input/regression/multi-measure-rest-reminder.ly:26: #(set-object-property! 'MultiMeasureRestReminder 'translation-type? ly:grob-properties?) On 2020/02/16 13:45:30, thomasmorley651 wrote: > To make further overrides possible, add: > #(set-object-property! 'MultiMeasureRestReminder 'is-grob? #t) > > Would solve the issue in my recent comment Feel free to send a change! I don't understand why we need is-grob? if the symbol is already marked with translation-type? == ly:grob-properties? David? https://codereview.appspot.com/557380044/
Re: Quarter Note Support for All Languages etc.
On Sat, Feb 15, 2020 at 6:54 PM Torsten Hämmerle wrote: > How about consistently introducing languages in their proper spelling (but > keeping the old names as an alternative? > SGTM. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)
On Sun, Feb 16, 2020 at 10:40 PM David Kastrup wrote: > >> > In this commit, extra support for the case where command-and-args is > >> empty was added, ie. > >> > >> That characterisation is completely wrong. The support is not for the > >> cases "where command-and-args is empty" but rather where > >> command-and-args is not a list but a single symbol. Just like > >> > >> (define symbol value) > >> and > >> (define (symbol arg1 arg2) body...) > >> > > > > I'm trying to get the markup macros working with GUILE 2.x compilation, > > which means that all calls to module-define! have to go. > > > > As a prelude to that, I'm trying to understand what this code is trying > to > > do. > > > > I don't think supporting > > > > (define-markup-command sym1 sym2) > > > > is very useful, but if you really want to have this, it should be > > documented and tested. > > It is not as much (define-markup-command sym1 sym2) rather than > > (define-markup-command sym1 (markup-lambda (...)) > > where the markup-lambda expression is independently created. > > This was supposed to be the implementation used in parser.yy for things > like > > \markup big-red = \markup \big \with-color #red \etc > > where defined name and definition are separate entities. It turned out > that calling macros from C did not work well, so I instead I had to call > the non-macro internals. It still made no sense scrapping that > functionality since it is similarly useful from Scheme where it looks > decidedly more natural than using the internals. > > It would appear I am not alone in considering that useful: > > git blame d03a3486639de982cfb6c6c315d76039bc5a0ac5 ly/markup-init.ly > > shows Nicolas Sceaux already implementing this ability independently in > 2006. > I'll take the blame for not having reviewed it carefully enough. This functionality was undocumented and untested in 2006, and I bet that I didn't understand it back then. I had a hard time keeping up with Nicolas' mastery of Scheme macros. I propose that if we keep it, it gets commented, documented and tested. Could you propose change to do so? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)
On Mon, Feb 17, 2020 at 8:18 AM wrote: > On 2020/02/16 21:25:42, hanwenn wrote: > > please, for the love of god, do not use automake. > > > > It is slow and arcane, and generally a complete PITA to work with. We > created > > stepmake after fighting with automake for a while. > > Do you have concrete numbers for automake being "slow" and are you sure > that it's still the case? My experience has been that automake is built on top of make, and whenever you touch a file (eg. Makefile), it is prone to rerunning itself. This then incurs another configure step, because if Makefile.in changes, you have to rerun configure (or config.status) again. It is also fundamentally a Makefile-per-directory approach, so it is fundamentally broken. It doesn't do wildcards, and they're proud of it ( https://www.gnu.org/software/automake/manual/html_node/Wildcards.html), so if you add or rename a file, you have to rerun automake for the build to pick it up. It is easy to forget such manual steps, which leads to hard to debug problems. The whole infrastructure stack is terminally broken. The standard GNU build system is a stack where you run a 250kb Perl program (long live the 1990s), to construct the input for a 500kb m4 program (long live the 1980s), so it can generate a 500kb shell script to find out where the compiler lives. The shell script is compatible with pre-3.0 UWin KSh. The resulting makefile (long live the 1970s) is compatible with a host of odd-ball versions of Make. For building the software, you then have to run libtool, a 300kb shell script. The shell script is compatible with all kinds obscure unixes. So, it'll be possible to build a dynamic library for lilypond on Solaris 4 and SGI Irix 5. (long live the 1990s). The GNU build technology makes things very complicated so you can use it on obsolete platforms. > At the moment Stepmake is just broken in so > many points (*) and a nightmare to maintain. So IMO it would be ok to > trade off 5% performance during configure (which we can easily offset by > removing outdated checks) with probably the same performance during > builds - maybe even better. > There is some value in fixing our build system, but it may be smaller than you think. The C++ part of LilyPond is utterly trivial to compile. The hard part is that the fonts, the documentation and the regression tests have custom logic, and if you move to a different system, you'll have to rewrite that logic from scratch. If you do this in Automake, this will be extra hard, because you cannot write the Makefiles directly (remember, automake output is compatible with Make versions that don't support $(wildcard), so you write the input to the automake process). So you have to rewrite it to be somehow compatible with Automake's idea of a makefile. The real problem with stepmake was that we tried to make something generic and usable in other programs. That has caused some over-engineering, and it would be good to clean that up. We could improve it by moving to something else (Cmake+Ninja? Scons?), but before contemplating a move, it would be good to decide what precisely is the problem. And I would stay a away from whatever the GNU project thinks is a good idea, because it was utterly broken 20 years ago, and even more so now. (*) Take this change as one example. Another one that hits my mind > (because I experienced it yesterday) is how our build system reorders > compilation, ie when invoking a serial `make' you don't get the same > order of .cc -> .o files. This is really insane if you work on headers, > want to fix one particular issue in one translation unit and suddenly > get errors + warnings from another file! > I don't think there is an innate guarantee of ordering, but you can probably make this more predictable by calling $(sort ) whereever we call $(wildcard ). Also, if you do parallel compilation, all bets about ordering are off. If you need to work on a translation unit, just run "make out/unit.o" -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)
On 2020/02/17 07:18:25, hahnjo wrote: > On 2020/02/16 21:25:42, hanwenn wrote: > > please, for the love of god, do not use automake. > > > > It is slow and arcane, and generally a complete PITA to work with. We created > > stepmake after fighting with automake for a while. > > Do you have concrete numbers for automake being "slow" and are you sure that > it's still the case? At the moment Stepmake is just broken in so many points (*) > and a nightmare to maintain. So IMO it would be ok to trade off 5% performance > during configure (which we can easily offset by removing outdated checks) with > probably the same performance during builds - maybe even better. > > (*) Take this change as one example. Another one that hits my mind (because I > experienced it yesterday) is how our build system reorders compilation, ie when > invoking a serial `make' you don't get the same order of .cc -> .o files. This > is really insane if you work on headers, want to fix one particular issue in one > translation unit and suddenly get errors + warnings from another file! To be clear: I'm not looking into using Automake yet, just cleaning up long overdue stuff. My observation is merely that it's insane to maintain our own build system (because of decisions years ago), that time could be spent much better. https://codereview.appspot.com/555300044/
