Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

On 2020/04/11 17:44:11, hanwenn wrote: > On 2020/04/11 17:19:19, dak wrote: > > > I thought of removing the other function too, and I agree in principle, but > it > > > can only break more user files. As long as we're not considering > reorganizing > > > the immutable lists, I think it can stay. >

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

On 2020/04/11 17:19:19, dak wrote: > > I thought of removing the other function too, and I agree in principle, but it > > can only break more user files. As long as we're not considering reorganizing > > the immutable lists, I think it can stay. > > Note that there is no necessity of returning a

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

On 2020/04/11 16:38:28, hanwenn wrote: > On 2020/04/11 16:02:31, dak wrote: > > The description says "[ly:grob-properties] will not return the properties that > > were \overridden." > > > > Aren't you confusing this with ly:grob-basic-properties ? I think > > ly:grob-properties will actually

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

> Fixes > Documentation/snippets/overriding-articulations-of-destinct-type, > which should be mirrored back into LSR. Fixed in LSR https://codereview.appspot.com/549840044/

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

Reviewers: dak, thomasmorley651, Message: On 2020/04/11 16:02:31, dak wrote: > The description says "[ly:grob-properties] will not return the properties that > were \overridden." > > Aren't you confusing this with ly:grob-basic-properties ? I think > ly:grob-properties will actually _only_

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

On 2020/04/11 16:32:58, thomasmorley651 wrote: > On 2020/04/11 16:31:48, thomasmorley651 wrote: > > > Btw, it's used in > > input/regression/multi-measure-rest-reminder.ly > > input/regression/scheme-text-spanner.ly > > as well. > > No, that's ly:grob-properties? > Bad grepping ... Also icky

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

On 2020/04/11 16:31:48, thomasmorley651 wrote: > Btw, it's used in > input/regression/multi-measure-rest-reminder.ly > input/regression/scheme-text-spanner.ly > as well. No, that's ly:grob-properties? Bad grepping ... https://codereview.appspot.com/549840044/

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

The change in the snippet is ofcourse nice. Though, please don't delete ly:grob-properties or ly:grob-basic-properties. I use them every day. They are tools to get insights at the grob at hand. Don't judge from our code base and the few occurencies there. Btw, it's used in

Re: Simplify mf-to-table (issue 549840043 by hanw...@gmail.com)

Thanks for the cleanup, a few nits inline. (I assume the description wasn't updated according to your local commit text?) https://codereview.appspot.com/549840043/diff/553830043/scripts/build/mf-to-table.py File scripts/build/mf-to-table.py (right):

Re: flower: Get rid of libc-extension (issue 553740043 by jonas.hahnf...@gmail.com)

On 2020/04/11 15:59:32, hahnjo wrote: > Rename my_round() to round_halfway_up() As promised, the updated patch keeps the functionality. However I've renamed the function and added clear documentation that it should not be used in new code. https://codereview.appspot.com/553740043/

Re: Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

The description says "[ly:grob-properties] will not return the properties that were \overridden." Aren't you confusing this with ly:grob-basic-properties ? I think ly:grob-properties will actually _only_ return the properties that were overriden. https://codereview.appspot.com/549840044/

Remove ly:grob-properties (issue 549840044 by hanw...@gmail.com)

https://codereview.appspot.com/549840044/diff/567430043/lily/grob-scheme.cc File lily/grob-scheme.cc (left): https://codereview.appspot.com/549840044/diff/567430043/lily/grob-scheme.cc#oldcode327 lily/grob-scheme.cc:327: LY_DEFINE (ly_grob_basic_properties, "ly:grob-basic-properties", There is

Re: stale git branches

Am Samstag, den 11.04.2020, 14:48 +0200 schrieb Han-Wen Nienhuys: > On Sat, Apr 11, 2020 at 2:13 PM Jonas Hahnfeld < > hah...@hahnjo.de > > wrote: > > following removal of dev/translation-* branches, I took a closer look > > at stale branches. I think it would make sense to keep unscoped > >

Re: Refactor get/set_property to take the item as first argument (issue 573670043 by d...@gnu.org)

Han-Wen Nienhuys writes: > On Fri, Apr 10, 2020 at 1:07 PM David Kastrup wrote: >> > * memory use: each SCM value takes 8 bytes, and there are 416 grob >> > properties today, for a total of 3328 bytes. Morgenlied is single page >> > of music and has 3704 grobs. So storage for the vectors (which

Re: stale git branches

Am 11. April 2020 15:33:06 MESZ schrieb David Kastrup : >Jonas Hahnfeld writes: > >> Hi all, >> >> following removal of dev/translation-* branches, I took a closer look >> at stale branches. I think it would make sense to keep unscoped >> branches (outside of dev/user/) to a minimum. This

Re: stale git branches

Jonas Hahnfeld writes: > Hi all, > > following removal of dev/translation-* branches, I took a closer look > at stale branches. I think it would make sense to keep unscoped > branches (outside of dev/user/) to a minimum. This should also avoid > overlooking old changes that have not been merged

Re: Refactor get/set_property to take the item as first argument (issue 573670043 by d...@gnu.org)

On Sat, Apr 11, 2020 at 2:53 PM Jonas Hahnfeld wrote: > > Am Samstag, den 11.04.2020, 14:45 +0200 schrieb Han-Wen Nienhuys: > > I think it is not out of the ordinary to discuss plans invasive plans > > before implementing them. > > To be fair, David did ask about it two months ago: >

Re: Refactor get/set_property to take the item as first argument (issue 573670043 by d...@gnu.org)

Am Samstag, den 11.04.2020, 14:45 +0200 schrieb Han-Wen Nienhuys: > I think it is not out of the ordinary to discuss plans invasive plans > before implementing them. To be fair, David did ask about it two months ago: https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg00668.html (I

Re: Refactor get/set_property to take the item as first argument (issue 573670043 by d...@gnu.org)

On Sat, Apr 11, 2020 at 2:45 PM Han-Wen Nienhuys wrote: > > What you call a "giant rewrite" is basically this patch. It's a purely > > syntactical patch only extending rather than reducing possible > > approaches and perfectly compatible with different implementations. The > > work for that

Re: stale git branches

On Sat, Apr 11, 2020 at 2:13 PM Jonas Hahnfeld wrote: > following removal of dev/translation-* branches, I took a closer look > at stale branches. I think it would make sense to keep unscoped > branches (outside of dev/user/) to a minimum. This should also avoid > overlooking old changes that

Re: Refactor get/set_property to take the item as first argument (issue 573670043 by d...@gnu.org)

On Fri, Apr 10, 2020 at 1:07 PM David Kastrup wrote: > > * memory use: each SCM value takes 8 bytes, and there are 416 grob > > properties today, for a total of 3328 bytes. Morgenlied is single page > > of music and has 3704 grobs. So storage for the vectors (which will be > > mostly empty) will

Re: python error running make doc

Am Samstag, den 11.04.2020, 14:33 +0200 schrieb Federico Bruni: > Fedora 31. /usr/bin/python points to version 3.7.6. > I'm running `make doc` in the translation branch and I get this error: > > $ make -j3 doc > GNUmakefile:30: warning: overriding recipe for target 'po-update' >

python error running make doc

Fedora 31. /usr/bin/python points to version 3.7.6. I'm running `make doc` in the translation branch and I get this error: $ make -j3 doc GNUmakefile:30: warning: overriding recipe for target 'po-update' /home/fede/src/lilypond-translation/stepmake/stepmake/podir-targets.make:14: warning:

stale git branches

Hi all, following removal of dev/translation-* branches, I took a closer look at stale branches. I think it would make sense to keep unscoped branches (outside of dev/user/) to a minimum. This should also avoid overlooking old changes that have not been merged yet. The following list is by no

Re: Reimplement Scheme_hash_table using linear probing. (issue 559790043 by hanw...@gmail.com)

On 2020/04/11 11:36:16, hanwenn wrote: > On Sat, Apr 11, 2020 at 1:05 PM wrote: > > > > On 2020/04/11 05:37:39, hanwenn wrote: > > > > In addition, I don't think that it is used to a degree where it > > would > > > significantly affect LilyPond's performance. > >

Re: Reimplement Scheme_hash_table using linear probing. (issue 559790043 by hanw...@gmail.com)

On Sat, Apr 11, 2020 at 1:05 PM wrote: > > On 2020/04/11 05:37:39, hanwenn wrote: > > > In addition, I don't think that it is used to a degree where it > would > > significantly affect LilyPond's performance. > > > > It is not yet. > > > > My plan is to plugin this into Grob and Prob and see if

Re: Reimplement Scheme_hash_table using linear probing. (issue 559790043 by hanw...@gmail.com)

On 2020/04/11 05:37:39, hanwenn wrote: > > In addition, I don't think that it is used to a degree where it would > significantly affect LilyPond's performance. > > It is not yet. > > My plan is to plugin this into Grob and Prob and see if there is a measurable > speed improvement. You cannot

Re: Reimplement Scheme_hash_table using linear probing. (issue 559790043 by hanw...@gmail.com)

On 2020/04/11 05:37:39, hanwenn wrote: > > In addition, I don't think that it is used to a degree where it would > significantly affect LilyPond's performance. > > It is not yet. > > My plan is to plugin this into Grob and Prob and see if there is a measurable > speed improvement. If there is

Re: Web: update documentation symlinks, and use https in RewriteRules (issue 551650043 by v.villen...@gmail.com)

On 2020/04/09 19:52:47, c_sorensen wrote: > I'm OK to have you push it, but I'd like to hear from those involved in the > release whether or not the steps in the CG were followed. Well, I introduced new CG additions to that effect a few weeks ago:

Re: Fix line comments for new snippets (issue 549820043 by d...@gnu.org)

https://codereview.appspot.com/549820043/diff/565880043/scripts/auxiliar/makelsr.py File scripts/auxiliar/makelsr.py (right): https://codereview.appspot.com/549820043/diff/565880043/scripts/auxiliar/makelsr.py#newcode38 scripts/auxiliar/makelsr.py:38: new_lys_marker = "%% generated from %s" %

PATCHES - Countdown for April 11th

Hello, Here is the current patch countdown list. The next countdown will be on April 13th A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ *** Push: 5881 Fix line comments for new snippets - David Kastrup

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

https://codereview.appspot.com/557640051/diff/565870043/input/regression/font-name-add-files.ly File input/regression/font-name-add-files.ly (right): https://codereview.appspot.com/557640051/diff/565870043/input/regression/font-name-add-files.ly#newcode244