Re: GSoC projects list

2017-02-05 Thread Werner LEMBERG
> So essentially per now we will have only 4/5 projects left:
> 
>   * Improving internal chord structure
>   * Adopting SMuFL
>   * Adding glyph variants
>   * openLilyLib testing and documentation
> 
> I find this list quite disappointing, and I'm afraid it won't be
> terribly attractive to potential students. So I strongly encourage
> anybody to suggest further projects, preferably together with a
> pledge to mentor them.

Some ideas, without being able to mentor them.

. Braille support
. a figured bass mode similar to (jazz) chord mode to display figured
  bass as chords
. Developing and implementing an OpenType Scheme API.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: GSoC projects list

2017-02-05 Thread Urs Liska


Am 6. Februar 2017 07:56:34 MEZ schrieb Jan-Peter Voigt :
>Hi Urs,
>
>
>Am 06.02.2017 um 00:24 schrieb Urs Liska:
>> Hi all,
>>
>> I'm somewhat worried about LilyPond's GSoC project proposals list.
>Right
>> now I'm purging the web page
>> (http://lilypond.org/google-summer-of-code.html) from projects
>without
>> mentors, and I have the feeling when this process is completed we're
>> left with an unsatisfactory state.
>>
>> From the 9 projects that are listed at the time of writing this post
>> four are right now scheduled for removal:
>>
>>   * Grace notes
>>   * Improving default beam positioning
>>   * Improving compilation behaviour
>>   * Improve Slurs and Ties
>>
>> A fifth project, MusicXML export, is still unclear.
>You asked me about this one several days ago and I didn't answer (yet).
>
>So let me do it now: I am willing to mentor the musicXML project.

Thanks,  this is great.
However, I think also the description is still somewhat unclear (which is what 
I actually wanted to say).

Urs 



>
>Best
>Jan-Peter
>
>> So essentially per now we will have only 4/5 projects left:
>>
>>   * Improving internal chord structure
>>   * Adopting SMuFL
>>   * Adding glyph variants
>>   * openLilyLib testing and documentation
>>
>> I find this list quite disappointing, and I'm afraid it won't be
>> terribly attractive to potential students. So I strongly encourage
>> anybody to suggest further projects, preferably together with a
>pledge
>> to mentor them.
>>
>> Best
>> Urs
>>
>>
>
>
>___
>lilypond-devel mailing list
>lilypond-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


GSoC projects list

2017-02-05 Thread Urs Liska
Hi all,

I'm somewhat worried about LilyPond's GSoC project proposals list. Right
now I'm purging the web page
(http://lilypond.org/google-summer-of-code.html) from projects without
mentors, and I have the feeling when this process is completed we're
left with an unsatisfactory state.

>From the 9 projects that are listed at the time of writing this post
four are right now scheduled for removal:

  * Grace notes
  * Improving default beam positioning
  * Improving compilation behaviour
  * Improve Slurs and Ties

A fifth project, MusicXML export, is still unclear.

So essentially per now we will have only 4/5 projects left:

  * Improving internal chord structure
  * Adopting SMuFL
  * Adding glyph variants
  * openLilyLib testing and documentation

I find this list quite disappointing, and I'm afraid it won't be
terribly attractive to potential students. So I strongly encourage
anybody to suggest further projects, preferably together with a pledge
to mentor them.

Best
Urs


-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: displayLilyMusic and scheme-engraver

2017-02-05 Thread Jan-Peter Voigt

Hi David,

Am 05.02.2017 um 16:19 schrieb David Kastrup:

David Kastrup  writes:


Jan-Peter Voigt  writes:


Hi folks,

I just stumbled over a bug with \displayLilyMusic and
scheme-engravers. The following fails in recent devel:

%%%

\version "2.19.55"

\displayLilyMusic \new Staff \with {
  \consists #(lambda (context)
   (make-engraver))
} \relative { bes'4 a c b }

%%%

ERROR: In procedure symbol->string:
ERROR: Wrong type argument in position 1 (expecting symbol):
#

%%%

Until 2.19.53 or 54 this didn't crash, but the output was not a
serialization of the context-mod (\with), so I assume, someone is
working on it :-)

I will have a look into the internals after lunch.


I think you are understating the problem.  \displayLilyMusic has nothing
to do with it.

yes, I do :-)


This is a "how did this ever pass testing" kind of case [checking the
regtests].

The regtests don't use \with at all but only layout redefinitions.

This is a showstopper in case anybody was thinking of rolling a
developer release right now.


Ok, no it isn't a showstopper.  The problem here is that (make-engraver)
returns an empty list, and an empty list is not accepted right now as an
engraver.  The moment you actually have anything that deserves the name
"engraver", it works.

Arguably, this wants fixing but it is sort of a "meh" example.


Thank you very much!
So I have empty engravers creeping around ... that is easy to fix!

Best
Jan-Peter



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Web-GSoC: Remove Grace note project (issue 317210043 by g...@ursliska.de)

2017-02-05 Thread Urs Liska


Am 5. Februar 2017 15:21:54 MEZ schrieb d...@gnu.org:
>The problem with "mentoring" this is that the expertise for
>successfully
>mentoring this project is the same as for doing it yourself.  This is
>not a question of making a plan and then implementing its parts over
>the
>course of several weeks.
>
>Either an idea works or not.  And it needs to be tied a whole lot into
>LilyPond's internals to work.  Anybody wanting a dozen dead branches
>that worked _not_: I have some lying around.
>
>So this really is not a student level problem, or even a master level
>problem where having a student to do boring parts would help.

Well, somehow I thought so, and that's part of why I'm not very hesitating 
about removing it from the proposals list.
But of course for some reasons we once had agreed upon adding it - probably 
because we all want this problem to finally go away.

Urs

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: displayLilyMusic and scheme-engraver

2017-02-05 Thread David Kastrup
David Kastrup  writes:

> Jan-Peter Voigt  writes:
>
>> Hi folks,
>>
>> I just stumbled over a bug with \displayLilyMusic and
>> scheme-engravers. The following fails in recent devel:
>>
>> %%%
>>
>> \version "2.19.55"
>>
>> \displayLilyMusic \new Staff \with {
>>   \consists #(lambda (context)
>>(make-engraver))
>> } \relative { bes'4 a c b }
>>
>> %%%
>>
>> ERROR: In procedure symbol->string:
>> ERROR: Wrong type argument in position 1 (expecting symbol):
>> #
>>
>> %%%
>>
>> Until 2.19.53 or 54 this didn't crash, but the output was not a
>> serialization of the context-mod (\with), so I assume, someone is
>> working on it :-)
>>
>> I will have a look into the internals after lunch.
>
> I think you are understating the problem.  \displayLilyMusic has nothing
> to do with it.
>
> This is a "how did this ever pass testing" kind of case [checking the
> regtests].
>
> The regtests don't use \with at all but only layout redefinitions.
>
> This is a showstopper in case anybody was thinking of rolling a
> developer release right now.

Ok, no it isn't a showstopper.  The problem here is that (make-engraver)
returns an empty list, and an empty list is not accepted right now as an
engraver.  The moment you actually have anything that deserves the name
"engraver", it works.

Arguably, this wants fixing but it is sort of a "meh" example.

How do people even think of those things?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: displayLilyMusic and scheme-engraver

2017-02-05 Thread David Kastrup
Jan-Peter Voigt  writes:

> Hi folks,
>
> I just stumbled over a bug with \displayLilyMusic and
> scheme-engravers. The following fails in recent devel:
>
> %%%
>
> \version "2.19.55"
>
> \displayLilyMusic \new Staff \with {
>   \consists #(lambda (context)
>(make-engraver))
> } \relative { bes'4 a c b }
>
> %%%
>
> ERROR: In procedure symbol->string:
> ERROR: Wrong type argument in position 1 (expecting symbol):
> #
>
> %%%
>
> Until 2.19.53 or 54 this didn't crash, but the output was not a
> serialization of the context-mod (\with), so I assume, someone is
> working on it :-)
>
> I will have a look into the internals after lunch.

I think you are understating the problem.  \displayLilyMusic has nothing
to do with it.

This is a "how did this ever pass testing" kind of case [checking the
regtests].

The regtests don't use \with at all but only layout redefinitions.

This is a showstopper in case anybody was thinking of rolling a
developer release right now.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: displayLilyMusic and scheme-engraver

2017-02-05 Thread David Kastrup
Jan-Peter Voigt  writes:

> Hi folks,
>
> I just stumbled over a bug with \displayLilyMusic and
> scheme-engravers. The following fails in recent devel:
>
> %%%
>
> \version "2.19.55"
>
> \displayLilyMusic \new Staff \with {
>   \consists #(lambda (context)
>(make-engraver))
> } \relative { bes'4 a c b }
>
> %%%
>
> ERROR: In procedure symbol->string:
> ERROR: Wrong type argument in position 1 (expecting symbol):
> #
>
> %%%
>
> Until 2.19.53 or 54 this didn't crash, but the output was not a
> serialization of the context-mod (\with), so I assume, someone is
> working on it :-)
>
> I will have a look into the internals after lunch.

That will likely be in connection with issue 1365.  I'll take a look.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Web-GSoC: Remove Grace note project (issue 317210043 by g...@ursliska.de)

2017-02-05 Thread dak

The problem with "mentoring" this is that the expertise for successfully
mentoring this project is the same as for doing it yourself.  This is
not a question of making a plan and then implementing its parts over the
course of several weeks.

Either an idea works or not.  And it needs to be tied a whole lot into
LilyPond's internals to work.  Anybody wanting a dozen dead branches
that worked _not_: I have some lying around.

So this really is not a student level problem, or even a master level
problem where having a student to do boring parts would help.

https://codereview.appspot.com/317210043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


PATCHES - Countdown for Sunday February 05

2017-02-05 Thread James
Hello,

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


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

http://philholmes.net/lilypond/allura/



Push:


5039 Replace \set Staff.instrumentName with \with form in doc examples
- James Lowe https://sourceforge.net/p/testlilyissues/issues/5039
http://codereview.appspot.com/313400043


5038 Web: Review GSoC page introduction - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5038
http://codereview.appspot.com/315410043


Countdown:


5049 Web-GSoC: Remove compilation behaviour project - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5049
http://codereview.appspot.com/320130043


5046 Remove some dead code from issue 1504 - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5046
http://codereview.appspot.com/312380043


5050 Web-GSoC: Remove Grace note project - Urs Liska
https://sourceforge.net/p/testlilyissues/issues/5050
http://codereview.appspot.com/317210043


Review: No patches in Review at this time.


New:


5055 HTML 4.01 requires "type" attribute for "script" element - David
Kastrup https://sourceforge.net/p/testlilyissues/issues/5055
http://codereview.appspot.com/315540043


5054 Fix SCM/int confusion in clef engravers - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5054
http://codereview.appspot.com/313530043


5053 Fix extendersOverRests property - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5053
http://codereview.appspot.com/317230043


5052 Information preserving parts of issue 4342 - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5052
http://codereview.appspot.com/318440043


Waiting:


4600 Let notes/rests suppress multi-measure rest grobs - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/4600
http://codereview.appspot.com/265160043


Regards

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


displayLilyMusic and scheme-engraver

2017-02-05 Thread Jan-Peter Voigt

Hi folks,

I just stumbled over a bug with \displayLilyMusic and scheme-engravers. 
The following fails in recent devel:


%%%

\version "2.19.55"

\displayLilyMusic \new Staff \with {
  \consists #(lambda (context)
   (make-engraver))
} \relative { bes'4 a c b }

%%%

ERROR: In procedure symbol->string:
ERROR: Wrong type argument in position 1 (expecting symbol): ##f (context)>


%%%

Until 2.19.53 or 54 this didn't crash, but the output was not a 
serialization of the context-mod (\with), so I assume, someone is 
working on it :-)


I will have a look into the internals after lunch.

Jan-Peter


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: trouble uploading a patch

2017-02-05 Thread David Kastrup
David Nalesnik  writes:

> On Sat, Feb 4, 2017 at 7:02 PM, David Nalesnik  
> wrote:
>> Yes, I've run it a number of times.
>>
>> All I can think is that somewhere during the upload process I lose my
>> authenticated connection with www.google.com.
>>
>> Hmmm.  I've rebased everything to a single commit, and that's what
>> I'm uploading.

Don't do that.  Always keep your work in recognizable pieces (sometimes
it takes a bit of work to turn "historic" pieces into "logic" pieces,
but git rebase -i helps with that, as do git checkout -p and similar).

>> Maybe I should break it down into several commits?

I don't think git-cl works with more than the diffs anyway.  We really
need some actually git-aware tool at one point of time.

> Nope.  Broke it up into 4 commits.  Same result.
>
> Always the same two files lead to "error: old chunk mismatch"--so the
> base files aren't getting uploaded.

Really have no idea about that.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel