Re: Naming question for get_property, set_property

[Han-Wen Nienhuys]

On Tue, Feb 11, 2020 at 10:17 PM David Kastrup  wrote:

> > the reason being that it is better if the source code looks like plain
> C++,
> > even though they might actually be macros that do advanced magic. Having
> > normal looking source code helps editors and tooling (astyle,
> clang-format)
> > make sensible decisions.
>
> get_property (pointer, "property")
> set_property (pointer, "property", value);
>
> would achieve that as well.  Doesn't look like a member function, but
> the thing looking like a member function also never actually was one.
>
>
Earlier you said:

"and for "reasons" I
need to know the type, so the call would become something akin to"

how does this work for the above?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Special-case syntax error of duration before octave marks (issue 557410043 by d...@gnu.org)

[hanwenn]

https://codereview.appspot.com/557410043/diff/545570043/lily/parser.yy
File lily/parser.yy (right):

https://codereview.appspot.com/557410043/diff/545570043/lily/parser.yy#newcode3676
lily/parser.yy:3676: | pitch exclamations questions octave_check
duration stray_quotes optional_rest post_events {
why can't this case be folded in to the preceding rule? Maybe this
comment says it already; if so an example would help.

https://codereview.appspot.com/557410043/diff/545570043/lily/parser.yy#newcode3706
lily/parser.yy:3706: parser->parser_error (@6, _ ("octave marks must
precede duration"));
add a comment that we sholudn't drop this error, even though this works
for users (I think we don't want that because it makes parsing .ly
harder for others.)

https://codereview.appspot.com/557410043/

Re: Special-case syntax error of duration before octave marks (issue 557410043 by d...@gnu.org)

[dak]

Reviewers: lemzwerg, Carl,

Message:
On 2020/02/11 22:37:39, Carl wrote:
> On 2020/02/11 21:46:52, lemzwerg wrote:
> > Good idea!  From inspection only, LGTM.
> 
> Sounds like a great idea!
> 
> Carl

Well, I sort of got a feature request. 


Description:
Special-case syntax error of duration before octave marks

A somewhat common note-entry error is to write something like c4''
that is (judging from my own experience) not even unusual for
experienced users to fall victim to occasionally.  So make a special
parser rule that deals "correctly" with that entry and delivers a more
helpful error message than the parser would muster on its own.

Please review this at https://codereview.appspot.com/557410043/

Affected files (+44, -0 lines):
  M lily/parser.yy


Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index 
89511c5d9d67a8091cbf9e043d9b99def124be58..78f0269a55a4cb5999525b2d54c4aa03fdb2ea05
 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -3294,6 +3294,11 @@ quotes:
 | sup_quotes
 ;
 
+stray_quotes:
+   sub_quotes
+   | sup_quotes
+   ;
+
 sup_quotes:
'\'' {
$$ = scm_from_int (1);
@@ -3661,6 +3666,45 @@ pitch_or_music:
$$ = n->unprotect ();
}
} %prec ':'
+   // Next rule is a frequent note entry error, like c4''
+   //
+   // It is quite unlikely that an octave check precedes a
+   // duration, but we have to keep it in the rule in order not
+   // to force the parser into early decisions before actually
+   // seeing a stray quote.  So we try to best interpret that
+   // case as well, even though it's not a likely error case.
+   | pitch exclamations questions octave_check duration stray_quotes 
optional_rest post_events {
+   if (!parser->lexer_->is_note_state ())
+   parser->parser_error (@1, _ ("have to be in Note mode 
for notes"));
+   {
+   Music *n = 0;
+   if (scm_is_true ($7))
+   n = MY_MAKE_MUSIC ("RestEvent", @$);
+   else
+   n = MY_MAKE_MUSIC ("NoteEvent", @$);
+
+   if (scm_is_number ($4))
+   {
+   int q = scm_to_int ($4) + scm_to_int ($6);
+   n->set_property ("absolute-octave", 
scm_from_int (q-1));
+   } else
+   $1 = unsmob ($1)->transposed
+   (Pitch (scm_to_int ($6), 
0)).smobbed_copy ();
+
+   n->set_property ("pitch", $1);
+   n->set_property ("duration", $5);
+
+   if (to_boolean ($3))
+   n->set_property ("cautionary", SCM_BOOL_T);
+   if (to_boolean ($2) || to_boolean ($3))
+   n->set_property ("force-accidental", 
SCM_BOOL_T);
+   if (scm_is_pair ($8))
+   n->set_property ("articulations",
+scm_reverse_x ($8, SCM_EOL));
+   $$ = n->unprotect ();
+   }
+   parser->parser_error (@6, _ ("octave marks must precede 
duration"));
+   } %prec ':'
| new_chord post_events {
if (!parser->lexer_->is_chord_state ())
 parser->parser_error (@1, _ ("have to be in Chord mode 
for chords"));

Re: Special-case syntax error of duration before octave marks (issue 557410043 by d...@gnu.org)

[Carl . D . Sorensen]

On 2020/02/11 21:46:52, lemzwerg wrote:
> Good idea!  From inspection only, LGTM.

Sounds like a great idea!

Carl


https://codereview.appspot.com/557410043/

Special-case syntax error of duration before octave marks (issue 557410043 by d...@gnu.org)

[lemzwerg--- via Discussions on LilyPond development]

Good idea!  From inspection only, LGTM.

https://codereview.appspot.com/557410043/

Re: Naming question for get_property, set_property

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Mon, Feb 10, 2020 at 11:48 PM David Kastrup  wrote:
>
>>
>> So for longterm efficiency reasons I am planning to reimplement the
>> get_property/set_property macros and underlying data structures that map
>> to get_property_internal/set_property_internal.  They are currently used
>> across a number of types in a sort of polymorphism, and for "reasons" I
>> need to know the type, so the call would become something akin to
>>
>> I'm curious about your plans. Can you say more?
>
>
>> get_property (Grob, "color");
>> or
>> set_property (Grob, "stencil", SCM_BOOL_F);
>>
>> Now this is longer than before.  Removing _property is not really an
>> option since that lands us with std::set getting mapped to
>> std::set_property_internal (or whatever).
>>
>> So Set and Get ?  Or set_prop and get_prop ?  Or Set_prop and Get_prop ?
>>
>> Or, since there are not all that many types to cater for, grob_set,
>> grob_get, music_set, music_get, event_set, event_get (those obviously
>> without the extra type argument) and what else I've been missing?
>>
>
> I recommend simply reverting to what we had before I unified things, ie.
>
>   get_grob_property
>   set_grob_property
>   get_music_property
>   .. etc.
>
> the reason being that it is better if the source code looks like plain C++,
> even though they might actually be macros that do advanced magic. Having
> normal looking source code helps editors and tooling (astyle, clang-format)
> make sensible decisions.

get_property (pointer, "property")
set_property (pointer, "property", value);

would achieve that as well.  Doesn't look like a member function, but
the thing looking like a member function also never actually was one.

Your proposal certainly causes fewer headaches in the sed script
department.  It's just that many uses of get_property/set_property
already lead to comparatively long lines.

And Dan appeared to be no fan of what will end up in code like

get_grob_property (grob, "property")

since usually the name of the pointer already suggests the type.  So I
lean toward's the non-member-function-like variant.  Let's see whether
my sed-foo convinces me otherwise when I get there.

-- 
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: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

[hanwenn]

fixed nits.

https://codereview.appspot.com/557380044/

Re: Naming question for get_property, set_property

[Han-Wen Nienhuys]

On Mon, Feb 10, 2020 at 11:48 PM David Kastrup  wrote:

>
> So for longterm efficiency reasons I am planning to reimplement the
> get_property/set_property macros and underlying data structures that map
> to get_property_internal/set_property_internal.  They are currently used
> across a number of types in a sort of polymorphism, and for "reasons" I
> need to know the type, so the call would become something akin to
>
> I'm curious about your plans. Can you say more?


> get_property (Grob, "color");
> or
> set_property (Grob, "stencil", SCM_BOOL_F);
>
> Now this is longer than before.  Removing _property is not really an
> option since that lands us with std::set getting mapped to
> std::set_property_internal (or whatever).
>
> So Set and Get ?  Or set_prop and get_prop ?  Or Set_prop and Get_prop ?
>
> Or, since there are not all that many types to cater for, grob_set,
> grob_get, music_set, music_get, event_set, event_get (those obviously
> without the extra type argument) and what else I've been missing?
>

I recommend simply reverting to what we had before I unified things, ie.

  get_grob_property
  set_grob_property
  get_music_property
  .. etc.

the reason being that it is better if the source code looks like plain C++,
even though they might actually be macros that do advanced magic. Having
normal looking source code helps editors and tooling (astyle, clang-format)
make sensible decisions.



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Fix and align musicxml and input language "deutsch" (issue 547610043 by d...@gnu.org)

[dak]

https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py
File python/musicexp.py (right):

https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py#newcode324
python/musicexp.py:324: return str
On 2020/02/11 20:39:14, Be-3 wrote:
> Proposal:
> keep 1st character and replace 'fq' by 'tq' in the suffix:
> 
>   return str[:1] + str[1:].replace ('fq', 'tq')

Your proposal does not work for sqs.  Did an independent fix, as I have
not seen your proposal in time.  Please test since this should also
still make it into 2.20.

https://codereview.appspot.com/547610043/

Re: Fix and align musicxml and input language "deutsch" (issue 547610043 by d...@gnu.org)

[torsten . haemmerle]

Proposed solution for English
(I know that this issue is about German only, but as English has been
touched, too, by removing a pointless replace statement).



https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py
File python/musicexp.py (right):

https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py#newcode324
python/musicexp.py:324: return str
Proposal:
keep 1st character and replace 'fq' by 'tq' in the suffix:

  return str[:1] + str[1:].replace ('fq', 'tq')

https://codereview.appspot.com/547610043/

Re: Fix and align musicxml and input language "deutsch" (issue 547610043 by d...@gnu.org)

[torsten . haemmerle]

We still have issues with English THREE-Q-* pitches (never worked,
though).

Please see my comment in musicexp.py

Torsten


https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py
File python/musicexp.py (right):

https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py#newcode324
python/musicexp.py:324: return str
does not work for quartertones yet: THREE-Q-FLAT will come out as -fqf,
but it should be -tqf (like "three quarter flat").

fqf, (F SEMI-FLAT), however, must remain fqf, etc.
So, a substring-recplacement of fqf will not generally work.
It's a mess...

The same holds true for -fqs (THREE-Q-SHARP).

https://codereview.appspot.com/547610043/

Re: [RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 14:37 +0100 schrieb Jonas Hahnfeld:
> Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup:
> > Jonas Hahnfeld <
> > hah...@hahnjo.de
> > 
> > > writes:
> > > Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
> > > > Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
> > > > hah...@hahnjo.de
> > > > 
> > > > 
> > > > 
> > > > ha scritto:
> > > > > >  > Another shortcoming is that links to other issues are broken
> > > > > >  > (transformed in links to non-existing anchors in current issue).
> > > > > > 
> > > > > >  I think that is because some issues have not (yet) been migrated. I
> > > > > >  hope these links start to work once all is there.
> > > > > 
> > > > > So I eventually convinced my script to migrate close to all issues 
> > > > > [1],
> > > > > and all references to other issues that I checked so far are now
> > > > > working. Could you maybe check again and let me know if something's
> > > > > still broken? In any case I've already modified my script to first 
> > > > > sort
> > > > > the issues and not take the (random?) order from SF.
> > > > 
> > > > I still see the problem.
> > > > 
> > > > Take issue 34 as example.
> > > > All the "Issue $NUMBER" have a wrong link:
> > > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
> > > > 
> > > > 
> > > > 
> > > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
> > > > 
> > > > 
> > > > 
> > > > 
> > > > But I can see an "issue 34" link working fine:
> > > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Perhaps your script is considering only the lower case "issue"?
> > > 
> > > Well no, I'm relying on GitLab magic here - my script attached for
> > > reference.
> > > But I think I see what's going on: When the script migrated issue #34,
> > > the referenced issues were not there yet and apparently GitLab does
> > > some evaluation when the text is posted. If I migrate the issue now
> > > (see 
> > > https://gitlab.com/lilypond-issues/lilypond/issues/5742
> > > 
> > > ), the
> > > links work - also note how "#25" in the first comment comes live.
> > > (I manually edited two comments in the original #34, so these do work
> > > now. The reference to "Issue 1302" is still broken though as I didn't
> > > touch that comment.)
> > > 
> > > Unfortunately this means that my strategy to create the issues "in
> > > order" doesn't work because comments can reference later issues that
> > > were created in the mean-time. So instead I'll try to first create all
> > > issues and then migrate all comments. That doesn't work for later edits
> > > of the issue description, but that should be the minority.
> > > I'll wait a few days for other problems before starting another
> > > attempt.
> > 
> > May I point out the tool-to-use for this task?
> > 
> > File: coreutils.info,  Node: tsort invocation,  Prev: ptx invocation,  Up: 
> > Operating on sorted files
> > 
> > 7.6 ‘tsort’: Topological sort
> > =
> > 
> > [...]
> > 
> > Now of course the non-linear manner of being able to update issues and
> > the desire to have cross-reference means that we _will_ have cycles.  So
> > this is not a cure-all, and cycles may need reediting the issues that
> > are broken by cycles.  But at least for the more linear reference
> > chains, this should be a good help.
> 
> Let me look into how many issue descriptions actually reference other
> issues. If there are none (or at least none that reference earlier
> issues), we can just be happy with the two-stage approach of migrating
> all issues first and add the comments in a second step.

Of course there are references, and sure enough some of them are
circular - see attached list. Most of them are fine if the migration
script creates the issues in order. The ones that are not:
23-Issue #636 references #498
24:Issue #650 references #651 - ERROR
25-Issue #651 references #650
26:Issue #663 references #664 - ERROR
27-Issue #664 references #663
--
105-Issue #1387 references #1365
106:Issue #1395 references #1396 - ERROR
107-Issue #1396 references #1395
--
174-Issue #2130 references #2057
175:Issue #2141 references #2142 - ERROR
176-Issue #2142 references #2141
--
242-Issue #2632 references #1773
243:Issue #2634 references #3290 - ERROR
244-Issue #2638 references #2148
--
414-Issue #3841 references #355
415:Issue #3847 references #3855 - ERROR
416-Issue #3855 references #10

So there's nothing we can do for 650/651, 663/664, 1395/1396, and
2141/2142, I would propose to just manually fix the links.
The other two are actually false positives:
#2634 references a Python bug report, and #3847 is meant to link to
issue #355.

So, no topological sorting needed as far as I can see.
Jonas
#!/usr/bin/env python3

import json
import os
import re
import sys

json_file = sys.argv[1]
with open(json_file, 'r') as f:
issues = json.load(f)

tickets = 

Re: What kind of forum are we lacking?

[David Kastrup]

Karlin High  writes:

> On 2/11/2020 10:03 AM, David Kastrup wrote:
>> There
>> is nothing wrong per se with the user list, but it's not indexed in a
>> manner where many of the high quality answers would be accumulated into
>> wisdom, and it is comparatively rare that something gets condensed into
>> the somewhat hard to find LSR, and then the educational aspect goes
>> somewhat missing.  This kind of stuff does not rise to the level where
>> making a package of the code makes a lot of sense either.
>> Just throwing this out in case somebody has an idea for such things.
>
> How about if email list traffic was periodically summarized and posted
> to the "Scores of Beauty" blog  ?

This sounds like something that would warrant Graham's talent of getting
people to do ultimately beneficial tasks for extended amounts of time.

An organised index of interesting solution threads...  Would make for an
interesting if somewhat arbitrary Wiki page.

-- 
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: What kind of forum are we lacking?

[Karlin High]

On 2/11/2020 10:03 AM, David Kastrup wrote:

There
is nothing wrong per se with the user list, but it's not indexed in a
manner where many of the high quality answers would be accumulated into
wisdom, and it is comparatively rare that something gets condensed into
the somewhat hard to find LSR, and then the educational aspect goes
somewhat missing.  This kind of stuff does not rise to the level where
making a package of the code makes a lot of sense either.

Just throwing this out in case somebody has an idea for such things.


How about if email list traffic was periodically summarized and posted 
to the "Scores of Beauty" blog  ?

--
Karlin High
Missouri, USA

What kind of forum are we lacking?

[David Kastrup]

I just reencountered the following StackExchange exchange when looking
for something else:



It has almost sort of a tutorial answer by some one-time poster (not all
that rare for LilyPond questions, almost as if somebody were trying to
avoid building up a reputation).

At some time in the distant past, there was the "LilyPond Report" for
capturing a bit of content

but it was not as much in Q form and not that much searchable.  There
is nothing wrong per se with the user list, but it's not indexed in a
manner where many of the high quality answers would be accumulated into
wisdom, and it is comparatively rare that something gets condensed into
the somewhat hard to find LSR, and then the educational aspect goes
somewhat missing.  This kind of stuff does not rise to the level where
making a package of the code makes a lot of sense either.

Just throwing this out in case somebody has an idea for such things.

-- 
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: [RFC] switch to GitLab / gitlab.com

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup:
>> 7.6 ‘tsort’: Topological sort
>> =
>> 
>> [...]
>> 
>> Now of course the non-linear manner of being able to update issues and
>> the desire to have cross-reference means that we _will_ have cycles.  So
>> this is not a cure-all, and cycles may need reediting the issues that
>> are broken by cycles.  But at least for the more linear reference
>> chains, this should be a good help.
>
> Let me look into how many issue descriptions actually reference other
> issues. If there are none (or at least none that reference earlier
> issues), we can just be happy with the two-stage approach of migrating
> all issues first and add the comments in a second step.

Or migrate first omitting all links in the descriptions, and afterwards
update all descriptions with links.

One could first create all issues with a stock description, but if that
doesn't trigger spam filters I don't know what will.  So using the
original descriptions in the first pass with links removed...

Actually possibly even with links intact.  As long as one _can_ resubmit
the descriptions afterwards, there should be no problem.

-- 
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: [RFC] switch to GitLab / gitlab.com

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 11.02.2020, 14:16 +0100 schrieb David Kastrup:
>> I am not sure of when and how and whether at all it might make sense
>> suggesting to GitLab that we would be a good showcase project, being
>> ancient and with significant history of different trackers etc.  Just
>> to reduce the long-term likelihood of us overstaying our welcome
>> regarding free resources.  Probably something to think about at a
>> considerably later point of time.  Or when we have significant
>> migration problems.
>
> I don't understand this point. Do you mean we should ask the GitLab
> devs for help with the migration?

Not before we run into a serious dead end, I think.  I don't mean to say
that I understand my point, either.  It just feels like if we are using
a free offering, we might want to think about what in our project would
be useful for making GitLab think it is a good idea hosting us.  I have
a vague feeling that there is some opportunity for social engineering.
I cannot entirely vouch for it since my specialty is more social
demolition.

-- 
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: Naming question for get_property, set_property

[David Kastrup]

Dan Eble  writes:

> On Feb 10, 2020, at 20:48, David Kastrup  wrote:
>> 
>> Templating on a string constant is, unfortunately, not a thing at least
>> in C++11 (don't know whether they managed since then).  Or one could go
>> that route rather than GCC-specific in-expression use of a static
>> initializer.
>
> Well, constexpr enables some new and interesting things, though I
> imagine that having to interact with Guile nixes them.

For the purpose of generating a near-compile-time constant that would
not be a problem, static initialization to the win.

Like

template 
SCM make_symbol ()
{
  static SCM sym = scm_permanent_object (scm_string_to_symbol (symbol));
  return sym;
}

which would generate one function per symbol that on its _first_ call
(when the Guile subsystem is already active) converts the symbol into
SCM and then memoizes it.  But as far as I know, C++11 cannot template
on string constants (C or C++) like that.  You need to create a named
character array or pointer and then can template on _that_ and that's a
lot more cumbersome in practice.

> Here, someone has figured out how to compute a CRC of a literal string
> at compile time: https://stackoverflow.com/a/9842857

We would not need anything that complicated.

-- 
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: [RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
> > > Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
> > > hah...@hahnjo.de
> > > 
> > > 
> > > ha scritto:
> > > > >  > Another shortcoming is that links to other issues are broken
> > > > >  > (transformed in links to non-existing anchors in current issue).
> > > > > 
> > > > >  I think that is because some issues have not (yet) been migrated. I
> > > > >  hope these links start to work once all is there.
> > > > 
> > > > So I eventually convinced my script to migrate close to all issues 
> > > > [1],
> > > > and all references to other issues that I checked so far are now
> > > > working. Could you maybe check again and let me know if something's
> > > > still broken? In any case I've already modified my script to first 
> > > > sort
> > > > the issues and not take the (random?) order from SF.
> > > 
> > > I still see the problem.
> > > 
> > > Take issue 34 as example.
> > > All the "Issue $NUMBER" have a wrong link:
> > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
> > > 
> > > 
> > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
> > > 
> > > 
> > > 
> > > But I can see an "issue 34" link working fine:
> > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
> > > 
> > > 
> > > 
> > > Perhaps your script is considering only the lower case "issue"?
> > 
> > Well no, I'm relying on GitLab magic here - my script attached for
> > reference.
> > But I think I see what's going on: When the script migrated issue #34,
> > the referenced issues were not there yet and apparently GitLab does
> > some evaluation when the text is posted. If I migrate the issue now
> > (see 
> > https://gitlab.com/lilypond-issues/lilypond/issues/5742
> > ), the
> > links work - also note how "#25" in the first comment comes live.
> > (I manually edited two comments in the original #34, so these do work
> > now. The reference to "Issue 1302" is still broken though as I didn't
> > touch that comment.)
> > 
> > Unfortunately this means that my strategy to create the issues "in
> > order" doesn't work because comments can reference later issues that
> > were created in the mean-time. So instead I'll try to first create all
> > issues and then migrate all comments. That doesn't work for later edits
> > of the issue description, but that should be the minority.
> > I'll wait a few days for other problems before starting another
> > attempt.
> 
> May I point out the tool-to-use for this task?
> 
> File: coreutils.info,  Node: tsort invocation,  Prev: ptx invocation,  Up: 
> Operating on sorted files
> 
> 7.6 ‘tsort’: Topological sort
> =
> 
> [...]
> 
> Now of course the non-linear manner of being able to update issues and
> the desire to have cross-reference means that we _will_ have cycles.  So
> this is not a cure-all, and cycles may need reediting the issues that
> are broken by cycles.  But at least for the more linear reference
> chains, this should be a good help.

Let me look into how many issue descriptions actually reference other
issues. If there are none (or at least none that reference earlier
issues), we can just be happy with the two-stage approach of migrating
all issues first and add the comments in a second step.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: [RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 14:16 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld:
> > > Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni:
> > > > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld <
> > > > hah...@hahnjo.de
> > > > 
> > > > 
> > > > 
> > > > ha scritto:
> > > > > Thanks for sharing! I put together a simplistic script to create a
> > > > > proof-of-concept: 
> > > > > https://gitlab.com/lilypond-issues/lilypond/issues
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > It's only 1137 issues (now my server is blacklisted for spamming...),
> > > > > but it has some important features mentioned so far:
> > > > >  * It preserves the issue numbers, and additionally has a link to SF.
> > > > >  * It migrates the current description and all comments.
> > > > >  * It copies the attachments and adds links / previews.
> > > > >  * Status, Type, and Priority are migrated as labels.
> > > > >  * The migrated issue is closed when it was closed on SF.
> > > > > 
> > > > > Obviously I can't post in other person's names, so it has "Originally
> > > > > reported / posted by" lines at the beginning of every issue and 
> > > > > comment
> > > > > (unless it had already been migrated from Google Code). Another
> > > > > shortcoming is that I could not reproduce the threaded structure on 
> > > > > SF,
> > > > > so all comments are sorted chronologically.
> > > > > 
> > > > > Please all take a look and let me know what you think!
> > > > 
> > > > Pretty impressive! I gave a quick glance and it looks great.
> > > > I suggest you eventually share the script in the gitlab.com issue I 
> > > > linked before so others can use it...
> > > 
> > > Will do, probably put it in a public repository (possibly even below
> > > the lilypond group), just for archival purposes.
> > > 
> > > > Another shortcoming is that links to other issues are broken 
> > > > (transformed in links to non-existing anchors in current issue).
> > > 
> > > I think that is because some issues have not (yet) been migrated. I
> > > hope these links start to work once all is there.
> > 
> > So I eventually convinced my script to migrate close to all issues [1],
> > and all references to other issues that I checked so far are now
> > working. Could you maybe check again and let me know if something's
> > still broken? In any case I've already modified my script to first sort
> > the issues and not take the (random?) order from SF.
> > 
> > Jonas
> > 
> > 1: except for #2965, #2044, #2765, #1939, #3654, #4778, #887, #162,
> > #328, #689, #1181, #1618, #1854 - these were considered "spam" but this
> > can be easily worked around by making the repo private for the course
> > of the migration.
> 
> This looks pretty good.  Any idea on whether the tracker should even be
> able to do threading in its issue tracking?  That one's not a
> showstopper.

I looked into this and GitLab does support threading - but not how
SourceForge did: You can turn a comment into a thread, but all replies
to it are again linearized. So not much gained here.

> But of course there are two elephants in the room.  The first is that a
> major point of the exercise is that we want to supplant Rietveld.  Just
> changing the tracker is not a net win.  We are not likely to transfer
> existing Rietveld issues, I guess.  It would be quite-nice to have but
> again: as long as Rietveld sticks around, not a showstopper.  But we
> definitely want to check out the issue flow there.

As per my original proposal, we would start using GitLab MRs for review
but still follow the current process for everything else. I agree that
we don't need to migrate old Rietveld issues (we still have the links).

> So we need a few volunteers getting accounts and emulating our process
> there.  I'm up to volunteering, I guess.
> 
> And of course, once we have a few issues washed through there (and
> likely referenced from our current tracker for the "real" process),

We can of course play with the test migrations (let me know your
account names and I can add you), but I would not put real reviews into
it: I plan to delete all migration tests, we should have one canonical
start for the new platform.

> we
> need to ask James for a look and for feedback of what would be mandatory
> and what would be good for him to have for getting on at least as well
> as he does now.  And we need to take that serious: the amount of work he
> puts in at the _current_ point of time already is nothing that one would
> lightly ask of a volunteer, so we should make sure that what is expected
> to be a net win for the average contributor does not yet make things
> harder for him.
> 
> We don't want to be in the situation that should he one day decide to
> spend more time working with LilyPond than working for LilyPond, we have
> to close shop.
> 
> I am not sure of when and how and whether at all it might make sense

Re: Naming question for get_property, set_property

[Dan Eble]

On Feb 10, 2020, at 20:48, David Kastrup  wrote:
> 
> Templating on a string constant is, unfortunately, not a thing at least
> in C++11 (don't know whether they managed since then).  Or one could go
> that route rather than GCC-specific in-expression use of a static
> initializer.

Well, constexpr enables some new and interesting things, though I imagine that 
having to interact with Guile nixes them.

Here, someone has figured out how to compute a CRC of a literal string at 
compile time:
https://stackoverflow.com/a/9842857
— 
Dan

Re: [RFC] switch to GitLab / gitlab.com

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
>> Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > 
>> ha scritto:
>> > >  > Another shortcoming is that links to other issues are broken
>> > >  > (transformed in links to non-existing anchors in current issue).
>> > > 
>> > >  I think that is because some issues have not (yet) been migrated. I
>> > >  hope these links start to work once all is there.
>> > 
>> > So I eventually convinced my script to migrate close to all issues 
>> > [1],
>> > and all references to other issues that I checked so far are now
>> > working. Could you maybe check again and let me know if something's
>> > still broken? In any case I've already modified my script to first 
>> > sort
>> > the issues and not take the (random?) order from SF.
>> 
>> I still see the problem.
>> 
>> Take issue 34 as example.
>> All the "Issue $NUMBER" have a wrong link:
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
>> 
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
>> 
>> 
>> But I can see an "issue 34" link working fine:
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
>> 
>> 
>> Perhaps your script is considering only the lower case "issue"?
>
> Well no, I'm relying on GitLab magic here - my script attached for
> reference.
> But I think I see what's going on: When the script migrated issue #34,
> the referenced issues were not there yet and apparently GitLab does
> some evaluation when the text is posted. If I migrate the issue now
> (see https://gitlab.com/lilypond-issues/lilypond/issues/5742), the
> links work - also note how "#25" in the first comment comes live.
> (I manually edited two comments in the original #34, so these do work
> now. The reference to "Issue 1302" is still broken though as I didn't
> touch that comment.)
>
> Unfortunately this means that my strategy to create the issues "in
> order" doesn't work because comments can reference later issues that
> were created in the mean-time. So instead I'll try to first create all
> issues and then migrate all comments. That doesn't work for later edits
> of the issue description, but that should be the minority.
> I'll wait a few days for other problems before starting another
> attempt.

May I point out the tool-to-use for this task?

File: coreutils.info,  Node: tsort invocation,  Prev: ptx invocation,  Up: 
Operating on sorted files

7.6 ‘tsort’: Topological sort
=

‘tsort’ performs a topological sort on the given FILE, or standard input
if no input file is given or for a FILE of ‘-’.  For more details and
some history, see *note tsort background::.  Synopsis:

 tsort [OPTION] [FILE]

   ‘tsort’ reads its input as pairs of strings, separated by blanks,
indicating a partial ordering.  The output is a total ordering that
corresponds to the given partial ordering.

   For example

 tsort <

Re: [RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
> Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
> hah...@hahnjo.de
> > 
> ha scritto:
> > >  > Another shortcoming is that links to other issues are broken
> > >  > (transformed in links to non-existing anchors in current issue).
> > > 
> > >  I think that is because some issues have not (yet) been migrated. I
> > >  hope these links start to work once all is there.
> > 
> > So I eventually convinced my script to migrate close to all issues 
> > [1],
> > and all references to other issues that I checked so far are now
> > working. Could you maybe check again and let me know if something's
> > still broken? In any case I've already modified my script to first 
> > sort
> > the issues and not take the (random?) order from SF.
> 
> I still see the problem.
> 
> Take issue 34 as example.
> All the "Issue $NUMBER" have a wrong link:
> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
> 
> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
> 
> 
> But I can see an "issue 34" link working fine:
> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
> 
> 
> Perhaps your script is considering only the lower case "issue"?

Well no, I'm relying on GitLab magic here - my script attached for
reference.
But I think I see what's going on: When the script migrated issue #34,
the referenced issues were not there yet and apparently GitLab does
some evaluation when the text is posted. If I migrate the issue now
(see https://gitlab.com/lilypond-issues/lilypond/issues/5742), the
links work - also note how "#25" in the first comment comes live.
(I manually edited two comments in the original #34, so these do work
now. The reference to "Issue 1302" is still broken though as I didn't
touch that comment.)

Unfortunately this means that my strategy to create the issues "in
order" doesn't work because comments can reference later issues that
were created in the mean-time. So instead I'll try to first create all
issues and then migrate all comments. That doesn't work for later edits
of the issue description, but that should be the minority.
I'll wait a few days for other problems before starting another
attempt.

Thanks
Jonas
#!/usr/bin/env python3

import argparse
from datetime import datetime
import json
import os
import requests
import sys
from urllib3.util.retry import Retry

GITLAB_API = 'https://gitlab.com/api/v4'
GITLAB_API_UPLOAD = GITLAB_API + '/projects/{repo}/uploads'
GITLAB_API_ISSUE_CREATE = GITLAB_API + '/projects/{repo}/issues'
GITLAB_API_ISSUE_UPDATE = GITLAB_API + '/projects/{repo}/issues/{issue}'
GITLAB_API_ISSUE_NOTE = GITLAB_API + '/projects/{repo}/issues/{issue}/notes'
GITLAB_API_ISSUE_UNSCRIBE = GITLAB_API + '/projects/{repo}/issues/{issue}/unsubscribe'

GITLAB_ISSUE = 'https://gitlab.com/{repo}/issues/{issue}'

SF_ISSUE = 'https://sourceforge.net{url}{issue}'

SF_USER = 'https://sourceforge.net/u/{user}'
TEMPLATE_USER = '[{user}](%s)' % SF_USER

ATTACHMENT_TEMPLATE = '![{file}]({url})'
ATTACHMENTS = '\n\n**Attachments**:  \n'

DESCRIPTION_TEMPLATE_AUTHOR = '*Originally reported by:* {author}\n\n{description}'
DESCRIPTION_TEMPLATE_URL = '{description}\n\n---\n*Original URL*: {url}'

COMMENT_TEMPLATE_AUTHOR = '*Originally posted by:* {author}\n\n{text}'

def get_parser():
parser = argparse.ArgumentParser(
description='Migrate LilyPond issues to GitLab',
)
parser.add_argument(
'--token',
help=(
'GitLab token, get it at ' +
'https://gitlab.com/profile/personal_access_tokens'
),
required=True,
)
parser.add_argument(
'--repo',
help='GitLab repository where to import',
required=True
)
parser.add_argument(
'export',
help='Directory with export from SourceForge'
)
return parser

parser = get_parser()
args = parser.parse_args(sys.argv[1:])
api_repo = args.repo.replace('/', '%2F')

export_dir = args.export
json_file = os.path.join(export_dir, 'issues.json')
if not os.path.isfile(json_file):
print('No export found in `%s`' % export)
sys.exit(1)

with open(json_file, 'r') as f:
issues = json.load(f)

tickets = issues['tickets']
sf_url = issues['tracker_config']['options']['url']
# issues['milestones'] is empty
issues_custom_fields = issues['custom_fields']
open_status_names = issues['open_status_names'].split(' ')
closed_status_names = issues['closed_status_names'].split(' ')
# issues['saved_bins'] contains our pre-defined search queries

api = requests.Session()
# Supply token
api.headers = {'Private-Token': args.token}
# Retry on "Internal Server Error"
retries = Retry(
method_whitelist=['POST','PUT'],
status_forcelist=[500],
)
adapter = requests.adapters.HTTPAdapter(max_retries=retries)
api.mount(GITLAB_API, adapter)

def get_ticket_num(ticket):
return ticket['ticket_num']

def is_author(author):
return author not in 

Re: [RFC] switch to GitLab / gitlab.com

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni:
>> > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld <
>> > hah...@hahnjo.de
>> > 
>> > 
>> > ha scritto:
>> > > Thanks for sharing! I put together a simplistic script to create a
>> > > proof-of-concept: 
>> > > https://gitlab.com/lilypond-issues/lilypond/issues
>> > > 
>> > > 
>> > > 
>> > > It's only 1137 issues (now my server is blacklisted for spamming...),
>> > > but it has some important features mentioned so far:
>> > >  * It preserves the issue numbers, and additionally has a link to SF.
>> > >  * It migrates the current description and all comments.
>> > >  * It copies the attachments and adds links / previews.
>> > >  * Status, Type, and Priority are migrated as labels.
>> > >  * The migrated issue is closed when it was closed on SF.
>> > > 
>> > > Obviously I can't post in other person's names, so it has "Originally
>> > > reported / posted by" lines at the beginning of every issue and 
>> > > comment
>> > > (unless it had already been migrated from Google Code). Another
>> > > shortcoming is that I could not reproduce the threaded structure on 
>> > > SF,
>> > > so all comments are sorted chronologically.
>> > > 
>> > > Please all take a look and let me know what you think!
>> > 
>> > Pretty impressive! I gave a quick glance and it looks great.
>> > I suggest you eventually share the script in the gitlab.com issue I 
>> > linked before so others can use it...
>> 
>> Will do, probably put it in a public repository (possibly even below
>> the lilypond group), just for archival purposes.
>> 
>> > Another shortcoming is that links to other issues are broken 
>> > (transformed in links to non-existing anchors in current issue).
>> 
>> I think that is because some issues have not (yet) been migrated. I
>> hope these links start to work once all is there.
>
> So I eventually convinced my script to migrate close to all issues [1],
> and all references to other issues that I checked so far are now
> working. Could you maybe check again and let me know if something's
> still broken? In any case I've already modified my script to first sort
> the issues and not take the (random?) order from SF.
>
> Jonas
>
> 1: except for #2965, #2044, #2765, #1939, #3654, #4778, #887, #162,
> #328, #689, #1181, #1618, #1854 - these were considered "spam" but this
> can be easily worked around by making the repo private for the course
> of the migration.

This looks pretty good.  Any idea on whether the tracker should even be
able to do threading in its issue tracking?  That one's not a
showstopper.

But of course there are two elephants in the room.  The first is that a
major point of the exercise is that we want to supplant Rietveld.  Just
changing the tracker is not a net win.  We are not likely to transfer
existing Rietveld issues, I guess.  It would be quite-nice to have but
again: as long as Rietveld sticks around, not a showstopper.  But we
definitely want to check out the issue flow there.

So we need a few volunteers getting accounts and emulating our process
there.  I'm up to volunteering, I guess.

And of course, once we have a few issues washed through there (and
likely referenced from our current tracker for the "real" process), we
need to ask James for a look and for feedback of what would be mandatory
and what would be good for him to have for getting on at least as well
as he does now.  And we need to take that serious: the amount of work he
puts in at the _current_ point of time already is nothing that one would
lightly ask of a volunteer, so we should make sure that what is expected
to be a net win for the average contributor does not yet make things
harder for him.

We don't want to be in the situation that should he one day decide to
spend more time working with LilyPond than working for LilyPond, we have
to close shop.

I am not sure of when and how and whether at all it might make sense
suggesting to GitLab that we would be a good showcase project, being
ancient and with significant history of different trackers etc.  Just to
reduce the long-term likelihood of us overstaying our welcome regarding
free resources.  Probably something to think about at a considerably
later point of time.  Or when we have significant migration problems.

-- 
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: [RFC] switch to GitLab / gitlab.com

[Federico Bruni]

Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld  
ha scritto:

 > Another shortcoming is that links to other issues are broken
 > (transformed in links to non-existing anchors in current issue).

 I think that is because some issues have not (yet) been migrated. I
 hope these links start to work once all is there.


So I eventually convinced my script to migrate close to all issues 
[1],

and all references to other issues that I checked so far are now
working. Could you maybe check again and let me know if something's
still broken? In any case I've already modified my script to first 
sort

the issues and not take the (random?) order from SF.


I still see the problem.

Take issue 34 as example.
All the "Issue $NUMBER" have a wrong link:
https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298

But I can see an "issue 34" link working fine:
https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318

Perhaps your script is considering only the lower case "issue"?

Re: [RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld:
> Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni:
> > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld <
> > hah...@hahnjo.de
> > 
> > 
> > ha scritto:
> > > Thanks for sharing! I put together a simplistic script to create a
> > > proof-of-concept: 
> > > https://gitlab.com/lilypond-issues/lilypond/issues
> > > 
> > > 
> > > 
> > > It's only 1137 issues (now my server is blacklisted for spamming...),
> > > but it has some important features mentioned so far:
> > >  * It preserves the issue numbers, and additionally has a link to SF.
> > >  * It migrates the current description and all comments.
> > >  * It copies the attachments and adds links / previews.
> > >  * Status, Type, and Priority are migrated as labels.
> > >  * The migrated issue is closed when it was closed on SF.
> > > 
> > > Obviously I can't post in other person's names, so it has "Originally
> > > reported / posted by" lines at the beginning of every issue and 
> > > comment
> > > (unless it had already been migrated from Google Code). Another
> > > shortcoming is that I could not reproduce the threaded structure on 
> > > SF,
> > > so all comments are sorted chronologically.
> > > 
> > > Please all take a look and let me know what you think!
> > 
> > Pretty impressive! I gave a quick glance and it looks great.
> > I suggest you eventually share the script in the gitlab.com issue I 
> > linked before so others can use it...
> 
> Will do, probably put it in a public repository (possibly even below
> the lilypond group), just for archival purposes.
> 
> > Another shortcoming is that links to other issues are broken 
> > (transformed in links to non-existing anchors in current issue).
> 
> I think that is because some issues have not (yet) been migrated. I
> hope these links start to work once all is there.

So I eventually convinced my script to migrate close to all issues [1],
and all references to other issues that I checked so far are now
working. Could you maybe check again and let me know if something's
still broken? In any case I've already modified my script to first sort
the issues and not take the (random?) order from SF.

Jonas

1: except for #2965, #2044, #2765, #1939, #3654, #4778, #887, #162,
#328, #689, #1181, #1618, #1854 - these were considered "spam" but this
can be easily worked around by making the repo private for the course
of the migration.


signature.asc
Description: This is a digitally signed message part

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

[jonas . hahnfeld]

On 2020/02/10 21:28:53, hahnjo wrote:
> Thanks for providing a test. Not able to run it right now, maybe
tomorrow.

Looks good to me (modulo the nits), see
https://sourceforge.net/p/testlilyissues/issues/5747/ for how the output
looks like.

https://codereview.appspot.com/557380044/

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[michael . kaeppler--- via Discussions on LilyPond development]

On 2020/02/11 11:22:40, lilypond_ptoye.com wrote:
> Monday, February 10, 2020, 10:00:03 PM, you wrote:
> 
> > On 2020/02/09 16:15:53, thomasmorley651 wrote:
> >> On 2020/02/09 15:32:14, http://lilypond_ptoye.com wrote:
> >> 
> >> > Surely "standard scale pitch or previously altered pitch". In D
> > major: "cis c
> >> > cis" the first note is an alteration but not an accidental, the
> > second is an
> >> > accidental but not an alteration, the third is both. Now I'm
really
> > splitting
> >> > hairs.
> >> 
> >> I read this as "In D major the note c _is_ an accidental". 
> >> Or did you mean _has_ an accidental?
> >> 
> >> > I'm beginning to think that this is all getting too theologial.
I'm
> > a
> >> practising musician, not a theorist, and I raised the point as I'd
never
> heard of
> >> > 'alteration' used in this rather technical sense. If people are
> > happy with the
> >> > distinction let's just keep it and I withdraw my suggestion.
> >> 
> >> Wait. If we try to improve the docs we need to care about best
> > wordings, so that
> >> people speaking different language and with different musical
> > education
> >> understand what we want to express.
> 
> > +1
> 
> >> 
> >> Furthermore we need to explain how we do things in LilyPond.
> >> Look at:
> >> mus = { \key d \major cis'4 }
> >> #(display-scheme-music (car (music-pitches mus)))
> >> #(display-scheme-music (ly:pitch-alteration (car (music-pitches
> > mus
> >> =>
> >> (ly:make-pitch 0 0 1/2)
> >> 1/2
> >> 
> >> First how the cis is seen in LilyPond, second the alteration.
> > (ofcourse no
> >> Accidental is printed in pdf)
> >> Do the same with note c and you see no alteration, i.e. 0 (ofcourse
an
> >> Accidental is printed)
> >> Do similar with c and cis (and you see the alteration for cis again
> > and an
> >> accidental for cis is printed)
> 
> > However, I think that the description of
> > LilyPond's internal pitch data
> > structure
> > is not helpful for this (pretty introductory) part of the docs.
> > The longer I think about it, the more I'm unsure if the term
> > "alteration" makes
> > sense for a basic understanding how pitches are entered in LilyPond.
> > If I think about a, lets say D major scale, I would not say that the
> > pitch 'fis' is an 'altered' note, though it is stored that way in
the
> > data structure. 'Alteration' for me always
> > refers to some 'unaltered'
> > form. 
> > Our pitch naming system with a 'nucleus' (e.g. 'f') and some
suffices
> > (e.g. '-is') OTOH supports the conclusion, that a pitch consists of
> > some base, diatonic pitch and possibles alterations.
> > It is also conclusive, though, that LilyPond 
> > uses the C major scale as the base for its pitch structure.
> 
> The nub of the question is the difference between how a musician
thinks of a
> note name and how it get written/engraved. If I'm working on paper I
don't think
> of  'C sharp' as 'C' modified by 'sharp'. I think of it as a single
entity. It's
> about 70 years since I learnt musical notation, and that was in the
English
> system on the piano, where the white notes have names which are
letters, and the
> black notes have what I was told (somewhat incorrectly) were called
> 'accidentals'. I think key signatures came later. I discovered about
German
> notation using 'B' for the note one diatonic tone below C much later -
so my
> previous comment about the 'black notes' doesn't work.

I fully agree with this point. I think we have to distinguish
the 'normal', colloquial use of the term 'note name' (which
refers to the whole note name as an entity) from the internal
data structure that uses the term 'note name' for 
the diatonic nucleus. (As Harm pointed out in #26)
There is even a function, called 'ly:pitch-notename' 
that (IIRC) does not return a string like 'fis' as one could
think, but an integer refering to the steps of the
default scale. 

I would propose to use the term 'note name' in the 
introductory docs only in the former sense.

> 
> I've just had a very quick look at musicXML and I have to admit that
this seems
> to take the same view as LilyPond - note plus alteration - and they
even use the
> tag  for the latter. So the use of 'alteration' as a technical
term does
> at least have some justification. 
> 
> But my concern was, and still is, that a newbie coming to Lilypond and
needing
> to check up on exactly how to engrave a C sharp won't find much help
in the
> section headings in the LM. I speak from experience form my early
fumblings with
> LP. We shouldn't discourage new users by hiding what are, in practical
terms,
> the easy bits.

Would it help if we used 'Pitch entry' or 'Entering pitches' for the
section
in LM 2.1.2, instead of 'Pitch alterations'?
This would involve changing of cross-references, though.



https://codereview.appspot.com/579280043/

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[michael . kaeppler--- via Discussions on LilyPond development]

On 2020/02/11 11:04:59, Jean-Charles wrote:
> Have a look at Documentation/HOWTO.index
> 
>
https://codereview.appspot.com/579280043/diff/563510048/Documentation/notation/input.itely
> File Documentation/notation/input.itely (right):
> 
>
https://codereview.appspot.com/579280043/diff/563510048/Documentation/notation/input.itely#newcode880
> Documentation/notation/input.itely:880: @cindex footers, page
> Index them as singular

Thanks for pointing me to the HOWTO.
Done.

https://codereview.appspot.com/579280043/

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[lilypond]

Monday, February 10, 2020, 10:00:03 PM, you wrote:

> On 2020/02/09 16:15:53, thomasmorley651 wrote:
>> On 2020/02/09 15:32:14, http://lilypond_ptoye.com wrote:
>> 
>> > Surely "standard scale pitch or previously altered pitch". In D
> major: "cis c
>> > cis" the first note is an alteration but not an accidental, the
> second is an
>> > accidental but not an alteration, the third is both. Now I'm really
> splitting
>> > hairs.
>> 
>> I read this as "In D major the note c _is_ an accidental". 
>> Or did you mean _has_ an accidental?
>> 
>> > I'm beginning to think that this is all getting too theologial. I'm
> a
>> practising musician, not a theorist, and I raised the point as I'd never 
>> heard of
>> > 'alteration' used in this rather technical sense. If people are
> happy with the
>> > distinction let's just keep it and I withdraw my suggestion.
>> 
>> Wait. If we try to improve the docs we need to care about best
> wordings, so that
>> people speaking different language and with different musical
> education
>> understand what we want to express.

> +1

>> 
>> Furthermore we need to explain how we do things in LilyPond.
>> Look at:
>> mus = { \key d \major cis'4 }
>> #(display-scheme-music (car (music-pitches mus)))
>> #(display-scheme-music (ly:pitch-alteration (car (music-pitches
> mus
>> =>
>> (ly:make-pitch 0 0 1/2)
>> 1/2
>> 
>> First how the cis is seen in LilyPond, second the alteration.
> (ofcourse no
>> Accidental is printed in pdf)
>> Do the same with note c and you see no alteration, i.e. 0 (ofcourse an
>> Accidental is printed)
>> Do similar with c and cis (and you see the alteration for cis again
> and an
>> accidental for cis is printed)

> However, I think that the description of
> LilyPond's internal pitch data
> structure
> is not helpful for this (pretty introductory) part of the docs.
> The longer I think about it, the more I'm unsure if the term
> "alteration" makes
> sense for a basic understanding how pitches are entered in LilyPond.
> If I think about a, lets say D major scale, I would not say that the
> pitch 'fis' is an 'altered' note, though it is stored that way in the
> data structure. 'Alteration' for me always
> refers to some 'unaltered'
> form. 
> Our pitch naming system with a 'nucleus' (e.g. 'f') and some suffices
> (e.g. '-is') OTOH supports the conclusion, that a pitch consists of
> some base, diatonic pitch and possibles alterations.
> It is also conclusive, though, that LilyPond 
> uses the C major scale as the base for its pitch structure.

The nub of the question is the difference between how a musician thinks of a 
note name and how it get written/engraved. If I'm working on paper I don't 
think of  'C sharp' as 'C' modified by 'sharp'. I think of it as a single 
entity. It's about 70 years since I learnt musical notation, and that was in 
the English system on the piano, where the white notes have names which are 
letters, and the black notes have what I was told (somewhat incorrectly) were 
called 'accidentals'. I think key signatures came later. I discovered about 
German notation using 'B' for the note one diatonic tone below C much later - 
so my previous comment about the 'black notes' doesn't work.

I've just had a very quick look at musicXML and I have to admit that this seems 
to take the same view as LilyPond - note plus alteration - and they even use 
the tag  for the latter. So the use of 'alteration' as a technical term 
does at least have some justification. 

But my concern was, and still is, that a newbie coming to Lilypond and needing 
to check up on exactly how to engrave a C sharp won't find much help in the 
section headings in the LM. I speak from experience form my early fumblings 
with LP. We shouldn't discourage new users by hiding what are, in practical 
terms, the easy bits.


>> 
>> This is absolutely inline with my thinking.
>> Though, c itself in D major can't be called an accidental.
>> In my book an Accidental is always the printed ♯-sign or ♭-sign or
> natural or
>> double-sharp/flat, nothing else, never the note itself.

> +1

Agreed, it's a note with and accidental natural sign. I've already covered this 
in other replies here.

>> 
>> Furthermore in german we have the distinction between "Vorzeichen" and
>> "Versetzungszeichen", in lilypond that would be the accidental-grobs
> from
>> KeySignature and the additional "on the fly"  Accidentals in music.

> Can you cite sources for this? Being also a
> practising german musician
> I've never used the term "Versetzungszeichen" and I thought it to
> be synonymous with "Vorzeichen". What I know and (rarely) use is
> the term "Generalvorzeichen". These would be the KeySignature
> accidentals. 


> https://codereview.appspot.com/579280043/

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[lilyfan]

Have a look at Documentation/HOWTO.index


https://codereview.appspot.com/579280043/diff/563510048/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/579280043/diff/563510048/Documentation/notation/input.itely#newcode880
Documentation/notation/input.itely:880: @cindex footers, page
Index them as singular

https://codereview.appspot.com/579280043/

Re: input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

[lilyfan]

Are you a French forensics? (DNA is adn for us)


https://codereview.appspot.com/557380044/diff/563510046/input/regression/multi-measure-rest-reminder.ly
File input/regression/multi-measure-rest-reminder.ly (right):

https://codereview.appspot.com/557380044/diff/563510046/input/regression/multi-measure-rest-reminder.ly#newcode6
input/regression/multi-measure-rest-reminder.ly:6: This is a demo of
user-defined engravers, adn defining grobs using
adn -> and

https://codereview.appspot.com/557380044/

Re: Integration of Guilev2 branches into master

[Joram Noeck]

I /think/ it is Unicode in NTFS now, but UCS/UTF-16 and not UTF-8:

https://stackoverflow.com/questions/2050973/what-encoding-are-filenames-in-ntfs-stored-as
https://en.wikipedia.org/wiki/Universal_Coded_Character_Set#Relationship_with_Unicode

Joram

Re: Naming question for get_property, set_property

[Joram Noeck]

FWIW, python has getattr and setattr which would perhaps suggest

get_prop(grob, "property") and
set_prop(grob, "property", VALUE)

I am not a fan of "arbitrary abbreviations" and get_property and
set_property are only 4 characters longer. So maybe I would choose the
latter (modulo your naming conventions w.r.t case) – just as one more
data point, feel free to ignore it.

Joram

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

[lilypond]

Monday, February 10, 2020, 9:40:53 PM, you wrote:

> On 2020/02/09 14:16:51, Carl wrote:
>> I'm a native US speaker.  The following is my opinion.
>> 
>> Alteration is a change in pitch from the base pitch.  Base pitch is C,
>> alteration is sharp, actual pitch is C#.
>> 
>> Accidental is a change in pitch from the standard scale pitch.  As
> mentioned by
>> Peter, C# in a D major scale is not an accidental, although it is an
> alteration.

> From my point of view a note can never _be_ an accidental, it can
> only _have_ an accidental attached to it. But maybe this is a
> misunderstanding of the English terms...

No- you're right and I'd already replied to Carl Sorenson's correction here. It 
doesn't affect the argument one jot, though.

>> 
>> I would totally support cleaning up this in NR 1.1.1 Accidentals (Note
> -- we
>> don't have 1.1.1.4 in the NR; the lowest level of headings is not
> numbered).

> It seems to me that this section does mix up "Entering pitches" and
> "Displaying pitches".
> The question whether a note is altered is decided within input.
> The question whether this note will show up with an accidental is
> decided during 
> typesetting and depends on the key signature,
> the accidental-style and
> so on.

> It is difficult to split up this topics
> clearly, however, because
> any example of pitch entry will include
> displaying the pitches, too.




>> 
>> Carl



> https://codereview.appspot.com/579280043/

Re: Parse inline scheme using per-expression port (issue 557330043 by hanw...@gmail.com)

[hanwenn]

note: this goes on top of DAK's recent patch for the .SCM file. 

https://codereview.appspot.com/557330043/

Re: Parse inline scheme using per-expression port (issue 557330043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Mon, Feb 10, 2020 at 11:21 PM David Kastrup  wrote:

>
> Or maybe the file offset got advanced because Guile peeked ahead in
> order to check whether there is an UTF-8 signature?  I forget what they
> are called, basically zero-space characters.  Byte order mark?  I am not
> saying that it is that, but I remember that Guile could do some pretty
> funky things at opening even something like a string port.
>


More mundane. Source_file::get_counts returns a byte_offset, but that is
not a global but per-line offset.

PTAL

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen