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

2020-02-12 Thread torsten . haemmerle
German and English successfully tested.

proposal for espanol (missing quarter notes) and portuques (still
completely missing) added (as it is about 2.20)


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



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

2020-02-12 Thread torsten . haemmerle
On 2020/02/11 20:54:19, dak wrote:
>
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.

Yep, I forgot about the quarter tone sharps.

I've now successfully tested your English solution with a complete set
of all notes ranging from c to b using all accidentals in quarter tone
steps from double-flat to double-sharp.

Having a quick look at the other languages, espanol import is still
completely missing out quarter tones, even if there are Spanish quarter
note names. And portugues is completely missing.


def pitch_espanol (pitch):
str = pitch_generic (pitch, ['do', 're', 'mi', 'fa', 'sol', 'la',
'si'], ['b', 'cb', 'cs', 's'])
return str.replace ('bc', 'tc').replace ('sc', 'tc')

and 

def pitch_portugues (pitch):
str = pitch_generic (pitch, ['do', 're', 'mi', 'fa', 'sol', 'la',
'si'], ['b', 'bqt', 'sqt', 's'])
return str.replace ('bbqt', 'btqt').replace ('ssqt', 'stqt')

would do the trick, tested with the complete set.

Torsten


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



Re: Remove unused GUILE_LDFLAGS from config.make.in (issue 567220044 by hanw...@gmail.com)

2020-02-12 Thread lemzwerg--- via Discussions on LilyPond development
> LGTM.

And I think this can be directly pushed.

https://codereview.appspot.com/567220044/



Remove unused GUILE_LDFLAGS from config.make.in (issue 567220044 by hanw...@gmail.com)

2020-02-12 Thread lemzwerg--- via Discussions on LilyPond development
LGTM.

https://codereview.appspot.com/567220044/



Move include guard for fluid.hh (issue 565640043 by hanw...@gmail.com)

2020-02-12 Thread dak
Guess a full test cycle for this one would be excessive.  As far as I am
concerned, feel free to push this one.

https://codereview.appspot.com/565640043/



Re: Drop support for multiple configurations (issue 581630043 by jonas.hahnf...@gmail.com)

2020-02-12 Thread hanwenn


https://codereview.appspot.com/581630043/diff/563520043/Documentation/included/compile.itexi
File Documentation/included/compile.itexi (left):

https://codereview.appspot.com/581630043/diff/563520043/Documentation/included/compile.itexi#oldcode895
Documentation/included/compile.itexi:895: @node Compiling for multiple
platforms
On 2020/02/12 16:50:30, Carl wrote:
> I wonder if we should keep the heading "Compiling for multiple
platforms", and
> just have it say "Use a separate build directory for each different
platform,
> and run configure in each build directory."  Perhaps even use the same
example,
> and show how to handle this situation.

people that need to do this are probably expert enough to already know
how to achieve it.

https://codereview.appspot.com/581630043/



Re: Drop support for multiple configurations (issue 581630043 by jonas.hahnf...@gmail.com)

2020-02-12 Thread hanwenn
Oh no! I was using this just this week for GUILE2 vs GUILE1.8


(but OK to remove, I agree it is too baroque).

https://codereview.appspot.com/581630043/



Re: [Jose E. Marchesi] [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020

2020-02-12 Thread David Kastrup
Urs Liska  writes:

> I just told them to copy last year's proposal, which basically links to *our* 
> GSoC page.

Thanks.

-- 
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: [Jose E. Marchesi] [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020

2020-02-12 Thread Urs Liska
I just told them to copy last year's proposal, which basically links to *our* 
GSoC page.

Urs

Am 12. Februar 2020 20:03:49 MEZ schrieb David Kastrup :
>
>Someone with a good idea?
>
> Start of forwarded message 
>From: jema...@gnu.org (Jose E. Marchesi)
>To: gnu-prog-disc...@gnu.org
>Date: Wed, 12 Feb 2020 19:50:06 +0100
>Subject: [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020
>
>
>Hi people!
>
>Once again, we are applying as a mentoring organization for GSOC 2020.
>At this point, we need to populate our ideas page with projects [1].
>
>This should be done before this Thursday (yes tomorrow).  So, if you
>want your GNU package to participate in GSOC, please send us your ideas
>to summer-of-c...@gnu.org ASAP!
>
>For each project idea, we need:
>
>- Name of the GNU program.
>  Example: GNU poke.
>
>- Summary of the project/idea.
>  Example: DWARF to Poke translator
>
>- Little paragraph explaining the project/idea.
>
>- Skills required.
>  Example: Good knowledge of DWARF, C programming.
>
>- Contact address for interested students.
>  Example: poke-de...@gnu.org
>
>If you have an external page where you are documenting your ideas, then
>please send us the URL so we can list it in the main page.
>
>Sorry for the late notice!
>And thanks! :)
>
>[1] https://www.gnu.org/software/soc-projects/ideas.html
>
>
>
> End of forwarded message 
>
>-- 
>David Kastrup

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


[Jose E. Marchesi] [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020

2020-02-12 Thread David Kastrup


Someone with a good idea?

 Start of forwarded message 
From: jema...@gnu.org (Jose E. Marchesi)
To: gnu-prog-disc...@gnu.org
Date: Wed, 12 Feb 2020 19:50:06 +0100
Subject: [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020


Hi people!

Once again, we are applying as a mentoring organization for GSOC 2020.
At this point, we need to populate our ideas page with projects [1].

This should be done before this Thursday (yes tomorrow).  So, if you
want your GNU package to participate in GSOC, please send us your ideas
to summer-of-c...@gnu.org ASAP!

For each project idea, we need:

- Name of the GNU program.
  Example: GNU poke.

- Summary of the project/idea.
  Example: DWARF to Poke translator

- Little paragraph explaining the project/idea.

- Skills required.
  Example: Good knowledge of DWARF, C programming.

- Contact address for interested students.
  Example: poke-de...@gnu.org

If you have an external page where you are documenting your ideas, then
please send us the URL so we can list it in the main page.

Sorry for the late notice!
And thanks! :)

[1] https://www.gnu.org/software/soc-projects/ideas.html



 End of forwarded message 

-- 
David Kastrup




Re: Drop support for multiple configurations (issue 581630043 by jonas.hahnf...@gmail.com)

2020-02-12 Thread Carl . D . Sorensen
I really like the work.  I just wonder if we should eliminate the
instructions on how to achieve the objective.


https://codereview.appspot.com/581630043/diff/563520043/Documentation/included/compile.itexi
File Documentation/included/compile.itexi (left):

https://codereview.appspot.com/581630043/diff/563520043/Documentation/included/compile.itexi#oldcode895
Documentation/included/compile.itexi:895: @node Compiling for multiple
platforms
I wonder if we should keep the heading "Compiling for multiple
platforms", and just have it say "Use a separate build directory for
each different platform, and run configure in each build directory." 
Perhaps even use the same example, and show how to handle this
situation.

https://codereview.appspot.com/581630043/



Drop support for multiple configurations (issue 581630043 by jonas.hahnf...@gmail.com)

2020-02-12 Thread lemzwerg--- via Discussions on LilyPond development
LGTM, thanks!

https://codereview.appspot.com/581630043/



PATCHES - Countdown for February 12th

2020-02-12 Thread James
 Hello,

 Here is the current patch countdown list. The next countdown will be on
 February 14th.

 A quick synopsis of all patches currently in the review process can be
 found here:

http://philholmes.net/lilypond/allura/ [1]

*** 

PUSH:

5745 GUILE2: softcode GC environment tuning - Han-Wen Nienhuys
 https://sourceforge.net/p/testlilyissues/issues/5745 [2]
http://codereview.appspot.com/563500045 [3] 

5744 parser-ly-from-scheme: Make #{ compilable - David Kastrup
 https://sourceforge.net/p/testlilyissues/issues/5744 [4]
http://codereview.appspot.com/581610043 [5] 

5743 Don't let display-lily-tests use anonymous functions - David
Kastrup
 https://sourceforge.net/p/testlilyissues/issues/5743 [6]
http://codereview.appspot.com/545550044 [7] 

5742 Add support for itexi files to the vim config - David Kastrup
 https://sourceforge.net/p/testlilyissues/issues/5742 [8]
http://codereview.appspot.com/557350044 [9] 

5718 Grow heap aggressively during music interpretation - Han-Wen
Nienhuys
 https://sourceforge.net/p/testlilyissues/issues/5718 [10]
http://codereview.appspot.com/561390043 [11] 

5703 Run scripts/auxiliar/fixcc.py - David Kastrup
 https://sourceforge.net/p/testlilyissues/issues/5703 [12]
http://codereview.appspot.com/549480043 [13] 

5679 In verbose mode, dump time spent on parsing lily.scm and friends. -
Han-Wen Nienhuys
 https://sourceforge.net/p/testlilyissues/issues/5679 [14]
http://codereview.appspot.com/573420043

COUNTDOWN:

5748 engraver: continue when trying to create non-existent Grob -
Han-Wen Nienhuys
 https://sourceforge.net/p/testlilyissues/issues/5748 [15]
http://codereview.appspot.com/547620043 [16] 

5741 Parse inline scheme using per-expression port - Han-Wen Nienhuys
 https://sourceforge.net/p/testlilyissues/issues/5741 [17]
http://codereview.appspot.com/557330043

REVIEW:

5709 Use a pointer for the output parameter of Lily_lexer::scan_word -
Han-Wen Nienhuys
 https://sourceforge.net/p/testlilyissues/issues/5709 [18]
http://codereview.appspot.com/577440044

NEW:

5750 Drop support for multiple configurations - Jonas Hahnfeld
 https://sourceforge.net/p/testlilyissues/issues/5750 [19]
http://codereview.appspot.com/581630043 [20] 

5749 Special-case syntax error of duration before octave marks - David
Kastrup
 https://sourceforge.net/p/testlilyissues/issues/5749 [21]
http://codereview.appspot.com/557410043 [22] 

5747 input/regression/multi-measure-rest-reminder: a demo of
user-defined grobs - Han-Wen Nienhuys
 https://sourceforge.net/p/testlilyissues/issues/5747 [23]
http://codereview.appspot.com/557380044 [24] 

5746 Fix and align musicxml and input language "deutsch" - David Kastrup
 https://sourceforge.net/p/testlilyissues/issues/5746 [25]
http://codereview.appspot.com/547610043 [26] 

5738 Doc: Some miscellaneous suggestions from Peter Toye - xmichael-k
 https://sourceforge.net/p/testlilyissues/issues/5738 [27]
http://codereview.appspot.com/579280043 [28] 

WAITING:

5740 Add post to defer context actions to end of time step - Dan Eble
 https://sourceforge.net/p/testlilyissues/issues/5740 [29]
http://codereview.appspot.com/581600043 [30] 

4943 Manual page breaking causing assertion failure - Thomas Morley
 https://sourceforge.net/p/testlilyissues/issues/4943 [31]
http://codereview.appspot.com/575600043 [32] 

*** 

 Regards,

 James

 

Links:
--
[1] http://philholmes.net/lilypond/allura/
[2] https://sourceforge.net/p/testlilyissues/issues/5745
[3] http://codereview.appspot.com/563500045
[4] https://sourceforge.net/p/testlilyissues/issues/5744
[5] http://codereview.appspot.com/581610043
[6] https://sourceforge.net/p/testlilyissues/issues/5743
[7] http://codereview.appspot.com/545550044
[8] https://sourceforge.net/p/testlilyissues/issues/5742
[9] http://codereview.appspot.com/557350044
[10] https://sourceforge.net/p/testlilyissues/issues/5718
[11] http://codereview.appspot.com/561390043
[12] https://sourceforge.net/p/testlilyissues/issues/5703
[13] http://codereview.appspot.com/549480043
[14] https://sourceforge.net/p/testlilyissues/issues/5679
[15] https://sourceforge.net/p/testlilyissues/issues/5748
[16] http://codereview.appspot.com/547620043
[17] https://sourceforge.net/p/testlilyissues/issues/5741
[18] https://sourceforge.net/p/testlilyissues/issues/5709
[19] https://sourceforge.net/p/testlilyissues/issues/5750
[20] http://codereview.appspot.com/581630043
[21] https://sourceforge.net/p/testlilyissues/issues/5749
[22] http://codereview.appspot.com/557410043
[23] https://sourceforge.net/p/testlilyissues/issues/5747
[24] http://codereview.appspot.com/557380044
[25] https://sourceforge.net/p/testlilyissues/issues/5746
[26] http://codereview.appspot.com/547610043
[27] https://sourceforge.net/p/testlilyissues/issues/5738
[28] http://codereview.appspot.com/579280043
[29] https://sourceforge.net/p/testlilyissues/issues/5740
[30] http://codereview.appspot.com/581600043
[31] https://sourceforge.net/p/testlilyissues/issues/4943
[32] 

New Spanish PO file for 'lilypond' (version 2.19.84)

2020-02-12 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'lilypond' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/lilypond/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/lilypond/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/lilypond.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.





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

2020-02-12 Thread dak


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 {
On 2020/02/12 06:45:08, hanwenn wrote:
> why can't this case be folded in to the preceding rule? Maybe this
comment says
> it already; if so an example would help.

Astute observation.  We print out the grammar in the manual and mixing
error productions and normal productions seems weird and misleading. 
However, there is no way to hide error productions from the grammar, so
my version is not better in that regard (though stray_quotes seems
rather obvious).

But you are right: this calls for making folding into the previous rule.
Will do.

https://codereview.appspot.com/557410043/diff/545570043/lily/parser.yy#newcode3706
lily/parser.yy:3706: parser->parser_error (@6, _ ("octave marks must
precede duration"));
On 2020/02/12 06:45:08, hanwenn wrote:
> 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.)

Accepting that "syntax" would give me a rash.  I had enough of a problem
giving the compiler knowledge about it.  Having it accept it would make
me very unhappy.

I'll try to put in an appropriate comment.

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



Re: Naming question for get_property, set_property

2020-02-12 Thread David Kastrup
Han-Wen Nienhuys  writes:

> 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?

decltype (*(pointer))

Basically the macro does not need to know the type by name, just in some
manner it can tell the compiler.

For the current syntax ->get_property ("property") I just have no
conceivable handle to get at the type of the pointer.

-- 
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".



New Dutch PO file for 'lilypond' (version 2.19.84)

2020-02-12 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'lilypond' has been submitted
by the Dutch team of translators.  The file is available at:

https://translationproject.org/latest/lilypond/nl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/lilypond/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/lilypond.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.