Re: Lilypond python upgrade

2016-12-07 Thread Werner LEMBERG

> Moving a thread across from the user list, I just wanted to let
> people know that I will be starting on the work of upgrading
> lilypond to use Python 3 - yes, with all the complexity that
> entails.  I am happy to have a serious shot at this task.

Great, and thanks in advance!  I guess your goal is to make the Python
stuff work with both versions 2 and 3, right?


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


Re: Lilypond python upgrade

2016-12-07 Thread Carl Sorensen


On 12/7/16 6:28 PM, "lilypond-devel on behalf of Andrew Bernard"
 wrote:

>Hi All,
>
> 
>
>Moving a thread across from the user list, I just wanted to let people
>know
>that I will be starting on the work of upgrading lilypond to use Python 3
>-
>yes, with all the complexity that entails. I am happy to have  a serious
>shot at this task.

Wow, I thought we were just talking about going from 2.6 to 2.7.  But 3 is
even newer, so it should have a longer life.

Great news!  Be sure to get Graham's help; he has lots of experience with
the build system and will know where many of the land mines lie.

Thanks again,

Carl


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


Lilypond python upgrade

2016-12-07 Thread Andrew Bernard
Hi All,

 

Moving a thread across from the user list, I just wanted to let people know
that I will be starting on the work of upgrading lilypond to use Python 3 -
yes, with all the complexity that entails. I am happy to have  a serious
shot at this task.

 

Andrew

 

 

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


Re: bypassing the patch countdown

2016-12-07 Thread Phil Holmes
- Original Message - 
From: "Graham Percival" 

To: 
Sent: Wednesday, December 07, 2016 10:34 PM
Subject: bypassing the patch countdown



Is this still an accepted practice?  If not, I suggest that it
should be.  If I had to formalize it, I'd say something like "if
two developers with push ability agree that a fix is trivial and
obvious, it can go straight to staging".



Adding to the other responses - I often do this with updates to the CG, for 
example.  Since  I'm possibly the only one who reads the release checklist, 
it makes no sense to require a countdown to changes there.  I make a change, 
do a test make and make doc and if it's OK, push to staging.


--
Phil Holmes 



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


Re: bypassing the patch countdown

2016-12-07 Thread Trevor Daniels

Graham Percival wrote Wednesday, December 07, 2016 10:34 PM

> We instituted the policy of patch countdowns and Patchy after the
> lengthy wait for 2.14.0, which was due to a large number of
> regression bugs due to patches which either broke the compile, or
> broke previously-working output.
> 
> However, even after that, I still pushed some commits directly to
> staging, bypassing the countdown.  Obviously I did this for
> updating the VERSION when making a release, but I also did it for
> a few typo fixes as well.
> 
> Is this still an accepted practice?

It is.  But as a minimum it must have been tested locally with
a build or (partial) doc build, or passed the automated tests 
before pushing to staging.  Of course significant changes still
need to go through countdown.

Trevor

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


Re: bypassing the patch countdown

2016-12-07 Thread Thomas Morley
2016-12-07 23:58 GMT+01:00 Urs Liska :
>
>
> Am 7. Dezember 2016 23:34:39 MEZ, schrieb Graham Percival 
> :
>>I was going to wait a month or two before suggesting this, just to
>>make sure I was fully "up to date", but I'll jump in now.
>>
>>We instituted the policy of patch countdowns and Patchy after the
>>lengthy wait for 2.14.0, which was due to a large number of
>>regression bugs due to patches which either broke the compile, or
>>broke previously-working output.
>>
>>However, even after that, I still pushed some commits directly to
>>staging, bypassing the countdown.  Obviously I did this for
>>updating the VERSION when making a release, but I also did it for
>>a few typo fixes as well.
>>
>>Is this still an accepted practice?  If not, I suggest that it
>>should be.  If I had to formalize it, I'd say something like "if
>>two developers with push ability agree that a fix is trivial and
>>obvious, it can go straight to staging".
>>
>
> Yes, this is still common practice.
> Developers can and do take this liberty occasionally.

Indeed.

> An alternative giving some extra safety is to upload a patch and wait for the 
> first automated tests before pushing to staging.

That's how I personally do it, even for most trivial patches.
(It's too asy to delete a bracket or something else by accident, not
noticing it.)

Cheers,
  Harm

>
> In the current case the point is not that it would take a significant  effort 
> to update the news but rather that it's not woth touching at all, given the 
> temporary nature of the information.
>
> Urs
>
>>
>>(please note that I'm not suggesting that anybody should feel
>>obligated to make such typo fixes -- instead, I'm checking that
>>the "door is open".  So that if we manage to get 1 or 2 users who
>>are able to fix typos, and those fixes are very obvious, they
>>wouldn't need to wait 2-4 days.  In this case, the "two
>>developers" would be "1 mentor, and the release or patch
>>meister".)
>>
>>Cheers,
>>- Graham
>>
>>___
>>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

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


Re: bypassing the patch countdown

2016-12-07 Thread Graham Percival
On Wed, Dec 07, 2016 at 11:58:14PM +0100, Urs Liska wrote:
> Am 7. Dezember 2016 23:34:39 MEZ, schrieb Graham Percival 
> :
> >(please note that I'm not suggesting that anybody should feel
> >obligated to make such typo fixes -- instead, I'm checking that
> >the "door is open".  So that if we manage to get 1 or 2 users
>
> In the current case the point is not that it would take a
> significant  effort to update the news but rather that it's not
> woth touching at all, given the temporary nature of the
> information. 

Oh, absolutely, I'm not suggesting that anybody here should update
the news!  I'm just checking that if a user thinks they're capable
of making such contributions, I can encourage and mentor them with
a good conscience.

Cheers,
- Graham

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


Re: bypassing the patch countdown

2016-12-07 Thread Urs Liska


Am 7. Dezember 2016 23:34:39 MEZ, schrieb Graham Percival 
:
>I was going to wait a month or two before suggesting this, just to
>make sure I was fully "up to date", but I'll jump in now.
>
>We instituted the policy of patch countdowns and Patchy after the
>lengthy wait for 2.14.0, which was due to a large number of
>regression bugs due to patches which either broke the compile, or
>broke previously-working output.
>
>However, even after that, I still pushed some commits directly to
>staging, bypassing the countdown.  Obviously I did this for
>updating the VERSION when making a release, but I also did it for
>a few typo fixes as well.
>
>Is this still an accepted practice?  If not, I suggest that it
>should be.  If I had to formalize it, I'd say something like "if
>two developers with push ability agree that a fix is trivial and
>obvious, it can go straight to staging".
>

Yes, this is still common practice.
Developers can and do take this liberty occasionally.
An alternative giving some extra safety is to upload a patch and wait for the 
first automated tests before pushing to staging.

In the current case the point is not that it would take a significant  effort 
to update the news but rather that it's not woth touching at all, given the 
temporary nature of the information. 

Urs

>
>(please note that I'm not suggesting that anybody should feel
>obligated to make such typo fixes -- instead, I'm checking that
>the "door is open".  So that if we manage to get 1 or 2 users who
>are able to fix typos, and those fixes are very obvious, they
>wouldn't need to wait 2-4 days.  In this case, the "two
>developers" would be "1 mentor, and the release or patch
>meister".)
>
>Cheers,
>- Graham
>
>___
>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


bypassing the patch countdown

2016-12-07 Thread Graham Percival
I was going to wait a month or two before suggesting this, just to
make sure I was fully "up to date", but I'll jump in now.

We instituted the policy of patch countdowns and Patchy after the
lengthy wait for 2.14.0, which was due to a large number of
regression bugs due to patches which either broke the compile, or
broke previously-working output.

However, even after that, I still pushed some commits directly to
staging, bypassing the countdown.  Obviously I did this for
updating the VERSION when making a release, but I also did it for
a few typo fixes as well.

Is this still an accepted practice?  If not, I suggest that it
should be.  If I had to formalize it, I'd say something like "if
two developers with push ability agree that a fix is trivial and
obvious, it can go straight to staging".


(please note that I'm not suggesting that anybody should feel
obligated to make such typo fixes -- instead, I'm checking that
the "door is open".  So that if we manage to get 1 or 2 users who
are able to fix typos, and those fixes are very obvious, they
wouldn't need to wait 2-4 days.  In this case, the "two
developers" would be "1 mentor, and the release or patch
meister".)

Cheers,
- Graham

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


Re: referencing hash key with music symbol

2016-12-07 Thread David Kastrup
Urs Liska  writes:

> Am 7. Dezember 2016 19:20:26 MEZ, schrieb David Kastrup :
>>>
>>> In that context, "Slur" is of course an arbitrary name. However, when
>>a
>>> symbol is used to indicate what item is being annotated in scholarly,
>>e.g.:
>>>
>>>
>>> \criticalRemark \with {
>>>
>>> message = "my message"
>>>
>>> apply = addition
>>>
>>> } Slur f'( g') %  "Slur" indicated here
>>
>>What are the argument predicates of criticalRemark ?
>
> See https://github.com/openlilylib/scholarly/blob/master/annotate/module.ily
>
>>
>>Slur can be a string, a symbol, a symbol list, a music expression (in
>>lyrics mode) depending on the predicate it is seen with.
>
> In this case it's symbol-list-or-music? so a symbol.

Uh what?  A symbol would not match that predicate, so it is a symbol
list.  I'd have to try it out to tell what it would be in lyrics mode,
though.

-- 
David Kastrup

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


Re: referencing hash key with music symbol

2016-12-07 Thread Urs Liska


Am 7. Dezember 2016 19:20:26 MEZ, schrieb David Kastrup :
>Jeffery Shivers  writes:
>
>> Hi LP team,
>>
>> I am working on automating editorial commands with ScholarLY, and I
>am
>> having some trouble pulling a music function that is stored in a hash
>> table. If I make a table and assign a key 'Slur to slurDashed, I can
>use it
>> successfully in the following example:
>>
>> #(define mytable (make-hash-table))
>>
>> #(hash-set! mytable 'Slur slurDashed)
>>
>>
>> \score {
>>
>> \new Staff {
>>
>> #(let ((func (hash-ref mytable 'Slur)))
>>
>> #{
>>
>> #func f'( g')
>>
>> #})
>>
>> }
>>
>> }
>>
>>
>> In that context, "Slur" is of course an arbitrary name. However, when
>a
>> symbol is used to indicate what item is being annotated in scholarly,
>e.g.:
>>
>>
>> \criticalRemark \with {
>>
>> message = "my message"
>>
>> apply = addition
>>
>> } Slur f'( g') %  "Slur" indicated here
>
>What are the argument predicates of criticalRemark ?

See https://github.com/openlilylib/scholarly/blob/master/annotate/module.ily

>
>Slur can be a string, a symbol, a symbol list, a music expression (in
>lyrics mode) depending on the predicate it is seen with.

In this case it's symbol-list-or-music? so a symbol.

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


Re: cross-voice spanners

2016-12-07 Thread Francisco Vila
2016-12-07 19:45 GMT+01:00 David Kastrup :
> You'll find that the above works fine already in versions where Nathan
> has not yet been involved.
>
> Its internals are slightly modified now in order to prepare for better
> integration of Nathan's code.  Even if that code were already committed,
> it would not in the current state touch slurs but rather some other
> constructs.
>
> So I would have reason to be frustrated since my work on this feature
> went under the radar completely, and Nathan would have reason to be
> frustrated since the work he is praised for is actually something else.

Then, congratulations to whoever worked on this at any conceivable
level! Thank y'all!

No pun intended. As I said, lack of closely tracking the issue made me
to over-simplify the whole thing.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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


Re: cross-voice spanners

2016-12-07 Thread David Kastrup
Francisco Vila  writes:

> 2016-12-07 19:22 GMT+01:00 David Kastrup :
>> Francisco Vila  writes:
>>
>>> 2016-12-03 22:38 GMT+01:00 Nathan Chou :
 { f\=1( g\=2( a\=1) b\=2) }
>>>
>>> Thank you for this, it is very useful. Good work.
>>
>> Now Nathan and I just need to figure out who of us two has more reason
>> to be frustrated.
>
> Frustrated, for something I said? I hope not. I'm afraid I have
> less-than-needed context for making sense of that.

You'll find that the above works fine already in versions where Nathan
has not yet been involved.

Its internals are slightly modified now in order to prepare for better
integration of Nathan's code.  Even if that code were already committed,
it would not in the current state touch slurs but rather some other
constructs.

So I would have reason to be frustrated since my work on this feature
went under the radar completely, and Nathan would have reason to be
frustrated since the work he is praised for is actually something else.

-- 
David Kastrup

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


Re: cross-voice spanners

2016-12-07 Thread Francisco Vila
2016-12-07 19:22 GMT+01:00 David Kastrup :
> Francisco Vila  writes:
>
>> 2016-12-03 22:38 GMT+01:00 Nathan Chou :
>>> { f\=1( g\=2( a\=1) b\=2) }
>>
>> Thank you for this, it is very useful. Good work.
>
> Now Nathan and I just need to figure out who of us two has more reason
> to be frustrated.
>
> --
> David Kastrup

Frustrated, for something I said? I hope not. I'm afraid I have
less-than-needed context for making sense of that.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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


guile-2: error when running make doc

2016-12-07 Thread Federico Bruni

Hi all

I get this error when I run `make doc` on the dev/guile-v2-work branch.
I'm running Debian testing in a 686 VM.

Drawing systems...
warning: compressing over-full page by 32.6 staff-spaces
Writing header field `texidoc' to `./e1/lily-0581dc11.texidoc'...
Writing ./e1/lily-0581dc11-1.signature
Writing ./e1/lily-0581dc11-2.signature
Layout output to `./e1/lily-0581dc11.eps'...
Converting to `./e1/lily-0581dc11.pdf'...
warning: g_spawn_sync failed (0): gs: Failed to fork (Cannot allocate 
memory)

Converting to PNG...
warning: g_spawn_sync failed (0): gs: Failed to fork (Cannot allocate 
memory)

Backtrace:
In ice-9/boot-9.scm:
160: 16 [catch #t # ...]
In unknown file:
  ?: 15 [apply-smob/1 #]
In ice-9/eval.scm:
411: 14 [eval # #]
432: 13 [eval # #]
In srfi/srfi-1.scm:
613: 12 [for-each # #]
In ice-9/eval.scm:
432: 11 [eval # #]
In ice-9/boot-9.scm:
160: 10 [catch ly-file-failed #ice-9/eval.scm:416:20 ()> ...]

In unknown file:
  ?: 9 [ly:parse-file "e1/lily-0581dc11.ly"]
  ?: 8 [ly:book-process-to-systems # #< Output_def> ...]
In ice-9/eval.scm:
432: 7 [eval # #]
432: 6 [eval # #]
In srfi/srfi-1.scm:
616: 5 [for-each # #]
In ice-9/eval.scm:
432: 4 [eval # #]
432: 3 [eval # #]
In srfi/srfi-1.scm:
616: 2 [for-each # #]
In ice-9/eval.scm:
432: 1 [eval # #]
In unknown file:
  ?: 0 [copy-file "./e1/lily-0581dc11.png" "/tmp/lilypond-zIa3I4"]

ERROR: In procedure copy-file:
ERROR: In procedure copy-file: No such file or directory




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


Re: cross-voice spanners

2016-12-07 Thread David Kastrup
Francisco Vila  writes:

> 2016-12-03 22:38 GMT+01:00 Nathan Chou :
>> { f\=1( g\=2( a\=1) b\=2) }
>
> Thank you for this, it is very useful. Good work.

Now Nathan and I just need to figure out who of us two has more reason
to be frustrated.

-- 
David Kastrup

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


Re: guile-2.0 and debian

2016-12-07 Thread David Kastrup
Antonio Ospite  writes:

> On Wed, 7 Dec 2016 08:42:29 +0100
> Urs Liska  wrote:
>  
>> Am 07.11.2016 um 17:08 schrieb Federico Bruni:
>> > In case you don't know already, last news about guile2 and debian:
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#216
>> 
>> Just for the record (although it's probably evident):
>> This doesn't only mean one can't install "lilypond" from Debian testing
>> but it's also not possible to do
>> 
>> # apt-get build-dep lilypond
>> 
>> So is there a way to get LilyPond's build-dependencies on that distro
>> (either a list of dependencies to install manually or by pinning it to
>> an older release?
>>
>
> Hi Urs,
>
> I contacted the debian package maintainers again to see if they can
> apply the changes dev/guile-v2-work and upload a package.

A package based on Guile 2 would deliver an absolutely devastatingly bad
LilyPond experience at the current point of time.  Awfully slow (we are
talking about a factor of 3 or similar) and rather buggy.

-- 
David Kastrup

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


Re: referencing hash key with music symbol

2016-12-07 Thread David Kastrup
Jeffery Shivers  writes:

> Hi LP team,
>
> I am working on automating editorial commands with ScholarLY, and I am
> having some trouble pulling a music function that is stored in a hash
> table. If I make a table and assign a key 'Slur to slurDashed, I can use it
> successfully in the following example:
>
> #(define mytable (make-hash-table))
>
> #(hash-set! mytable 'Slur slurDashed)
>
>
> \score {
>
> \new Staff {
>
> #(let ((func (hash-ref mytable 'Slur)))
>
> #{
>
> #func f'( g')
>
> #})
>
> }
>
> }
>
>
> In that context, "Slur" is of course an arbitrary name. However, when a
> symbol is used to indicate what item is being annotated in scholarly, e.g.:
>
>
> \criticalRemark \with {
>
> message = "my message"
>
> apply = addition
>
> } Slur f'( g') %  "Slur" indicated here

What are the argument predicates of criticalRemark ?

Slur can be a string, a symbol, a symbol list, a music expression (in
lyrics mode) depending on the predicate it is seen with.

-- 
David Kastrup

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


Re: preparing LilyDev for guile-v2-work branch

2016-12-07 Thread Federico Bruni
Il giorno lun 5 dic 2016 alle 13:20, Federico Bruni 
 ha scritto:
Il giorno ven 2 dic 2016 alle 23:53, Thomas Morley 
 ha scritto:

no clue what's causing the error for you.

I just checked again with the following command-sequence (nothing 
unusual):


git checkout remotes/origin/dev/guile-v2-work
git checkout -b dev/guile-v2-work-test
sh autogen.sh --noconfigure
mkdir -p build/
cd build/
../configure --enable-guile2
make -j5

Success!

Top in remotes/origin/dev/guile-v2-work is:
commit 645edd5a37a6c4fc0e5e15490681bd113a4162bb
Author: Antonio Ospite 
Date:   Tue Nov 22 16:25:01 2016 +0100

XXX reset the locale when building index.html


Sorry being of not more help,


Thanks for checking.

Everything fine after deleting build/ and starting again. I should 
have tried it before asking here..
Probably the problem was that the first time I run configure without 
the --enable-guile2 option.


I've stumbled upon the same error again.
This time I solved by changing the locale from default it_IT to C:

export LANG=C

I suspect that last Monday I did the same on my second try, to be able 
to share error messages in english on this list, and I wrongly thought 
that deleting build and restart from scratch solved the problem.


Anyway, I have holidays next two days, so I should be able to release 
the new LilyDev tomorrow or Friday.





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


Re: cross-voice spanners

2016-12-07 Thread Francisco Vila
2016-12-03 22:38 GMT+01:00 Nathan Chou :
> { f\=1( g\=2( a\=1) b\=2) }

Thank you for this, it is very useful. Good work.


-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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


Re: guile-2.0 and debian

2016-12-07 Thread Federico Bruni
Il giorno mer 7 dic 2016 alle 13:34, Dr. Tobias Quathamer 
 ha scritto:
The link points to the obsolete dependencies. You'll want this link 
instead:




This has an updated fonts package list as well.


Thanks for the link.

The fonts package list is really updated? I ask because it includes 
some dummy transitional packages, e.g. ttf-dejavu, which has been 
replaced by fonts-dejavu IIUC.


Yesterday I was building a debian image with live-build, which failed 
to install ttf-dejavu. Should I use fonts-dejavu?





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


PATCHES: Countdown for December 7th

2016-12-07 Thread James

Hello,

Here is the current patch countdown list. The next countdown will be on
December 10th.

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

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


__


Push:


5002 Correct the guns for hire list under "Community" - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5002
http://codereview.appspot.com/318010043


Countdown:


5007 Proposed additional info for Contributor's Guide 6.1, Introduction 
to website work - gperciva

https://sourceforge.net/p/testlilyissues/issues/5007
http://codereview.appspot.com/315130043


5003 unfoldRepeats can be restricted to certain repeat-types - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/5003
http://codereview.appspot.com/318890043


Review: No patches in review at this time.


New: No New patches at this time.


Regards

James

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



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


Re: Fix MusicXML reg tests that have both Lyrics and Chords (issue 316950043 by pkx1...@gmail.com)

2016-12-07 Thread pkx166h

author  Vincent Le Ligeour   
Wed, 7 Dec 2016 13:10:32 + (13:10 +)
committer   James Lowe 
Wed, 7 Dec 2016 13:10:38 + (13:10 +)
commit  503a553ab5a1ace4a4f03a321d2d353f253bf5f4

Thank you Vincent.

https://codereview.appspot.com/316950043/

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


Re: guile-2.0 and debian

2016-12-07 Thread Dr. Tobias Quathamer

Am 07.12.2016 um 11:06 schrieb Urs Liska:

Am 07.12.2016 um 10:31 schrieb Antonio Ospite:

For the time being, you can still get the list of dependencies from
here:
https://anonscm.debian.org/git/collab-maint/lilypond.git/tree/debian/control?h=debian

And pass the list to apt-get.


Yes, but as mentioned in my other reply this will fail once asking apt
to install guile-1.8-dev (restarting the cycle ...)


The link points to the obsolete dependencies. You'll want this link instead:



This has an updated fonts package list as well.

Regards,
Tobias




signature.asc
Description: OpenPGP digital signature
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: guile-2.0 and debian

2016-12-07 Thread Federico Bruni
Il giorno mer 7 dic 2016 alle 11:41, Urs Liska  ha 
scritto:

 Sorry, I should have told you to install guile-1.8-dev instead of
 guile-2.0-dev (now the default in LilyDev, as we want other people 
to

 test the work on guile2 migration).


And where do I get this from as it has been removed from Debian 
testing

(I'm not talking about LilyDev but a vanilla Debian installation)?


You are right, I didn't check.
I'm afraid that you have to pin it from Jessie:
https://packages.debian.org/jessie/guile-1.8-dev




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


Re: guile-2.0 and debian

2016-12-07 Thread Urs Liska


Am 07.12.2016 um 11:34 schrieb Federico Bruni:
> Il giorno mer 7 dic 2016 alle 10:28, Urs Liska  ha
> scritto:
>> OK, thank you.
>> After installing these building LilyPond fails with the following error:
>>
>> WARNING: Please consider installing optional programs or files:  URW++
>> OTF fonts (download OTF files from
>> 'http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=79bcdfb34fbce12b592cce389fa7a19da6b5b018'
>>
>> and put them under '~/.local/share/fonts' etc., or use
>> --with-urwotf-dir) guile extractpdfmark (Optionally using Ghostscript >=
>> 9.20 together with Extract PDFmark can significantly reduce the disk
>> space required for building the documentation and the final PDF files.)
>>
>> ERROR: Please install required programs:  guile-config (guile-devel,
>> guile-dev or libguile-dev package) libguile (libguile-dev, guile-devel
>> or guile-dev package). GUILE-with-rational-bugfix Python.h
>> (python-devel, python-dev or libpython-dev package) pkg-config makeinfo
>> texi2html texi2pdf texindex
>>
>> So it seems I'll be at the same stage as before because there won't be a
>> guile 1.8 available ...
>>
>
> Sorry, I should have told you to install guile-1.8-dev instead of
> guile-2.0-dev (now the default in LilyDev, as we want other people to
> test the work on guile2 migration).

And where do I get this from as it has been removed from Debian testing
(I'm not talking about LilyDev but a vanilla Debian installation)?

> In that list there is texi2html, so I'm surprised that it seems not
> installed in your system. Try to install it again.

Indeed, that's somewhat strange as it was in the list I copied from your
earlier link.
Have fixed that one.

Urs


>
>
>
>


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


Re: guile-2.0 and debian

2016-12-07 Thread Federico Bruni
Il giorno mer 7 dic 2016 alle 10:28, Urs Liska  ha 
scritto:

OK, thank you.
After installing these building LilyPond fails with the following 
error:


WARNING: Please consider installing optional programs or files:  URW++
OTF fonts (download OTF files from
'http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=79bcdfb34fbce12b592cce389fa7a19da6b5b018'
and put them under '~/.local/share/fonts' etc., or use
--with-urwotf-dir) guile extractpdfmark (Optionally using Ghostscript 
>=

9.20 together with Extract PDFmark can significantly reduce the disk
space required for building the documentation and the final PDF 
files.)


ERROR: Please install required programs:  guile-config (guile-devel,
guile-dev or libguile-dev package) libguile (libguile-dev, guile-devel
or guile-dev package). GUILE-with-rational-bugfix Python.h
(python-devel, python-dev or libpython-dev package) pkg-config 
makeinfo

texi2html texi2pdf texindex

So it seems I'll be at the same stage as before because there won't 
be a

guile 1.8 available ...



Sorry, I should have told you to install guile-1.8-dev instead of 
guile-2.0-dev (now the default in LilyDev, as we want other people to 
test the work on guile2 migration).
In that list there is texi2html, so I'm surprised that it seems not 
installed in your system. Try to install it again.






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


Re: guile-2.0 and debian

2016-12-07 Thread Urs Liska


Am 07.12.2016 um 10:31 schrieb Antonio Ospite:
> On Wed, 7 Dec 2016 08:42:29 +0100
> Urs Liska  wrote:
>  
>> Am 07.11.2016 um 17:08 schrieb Federico Bruni:
>>> In case you don't know already, last news about guile2 and debian:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#216
>> Just for the record (although it's probably evident):
>> This doesn't only mean one can't install "lilypond" from Debian testing
>> but it's also not possible to do
>>
>> # apt-get build-dep lilypond
>>
>> So is there a way to get LilyPond's build-dependencies on that distro
>> (either a list of dependencies to install manually or by pinning it to
>> an older release?
>>
> Hi Urs,
>
> I contacted the debian package maintainers again to see if they can
> apply the changes dev/guile-v2-work and upload a package.
>
> For the time being, you can still get the list of dependencies from
> here:
> https://anonscm.debian.org/git/collab-maint/lilypond.git/tree/debian/control?h=debian
>
> And pass the list to apt-get.

Yes, but as mentioned in my other reply this will fail once asking apt
to install guile-1.8-dev (restarting the cycle ...)


> Ciao,
>Antonio
>


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


Re: guile-2.0 and debian

2016-12-07 Thread Antonio Ospite
On Wed, 7 Dec 2016 08:42:29 +0100
Urs Liska  wrote:
 
> Am 07.11.2016 um 17:08 schrieb Federico Bruni:
> > In case you don't know already, last news about guile2 and debian:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#216
> 
> Just for the record (although it's probably evident):
> This doesn't only mean one can't install "lilypond" from Debian testing
> but it's also not possible to do
> 
> # apt-get build-dep lilypond
> 
> So is there a way to get LilyPond's build-dependencies on that distro
> (either a list of dependencies to install manually or by pinning it to
> an older release?
>

Hi Urs,

I contacted the debian package maintainers again to see if they can
apply the changes dev/guile-v2-work and upload a package.

For the time being, you can still get the list of dependencies from
here:
https://anonscm.debian.org/git/collab-maint/lilypond.git/tree/debian/control?h=debian

And pass the list to apt-get.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

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


Re: guile-2.0 and debian

2016-12-07 Thread Urs Liska


Am 07.12.2016 um 09:53 schrieb Federico Bruni:
> Il giorno mer 7 dic 2016 alle 8:42, Urs Liska  ha
> scritto:
>>>  In case you don't know already, last news about guile2 and debian:
>>>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#216
>>
>> Just for the record (although it's probably evident):
>> This doesn't only mean one can't install "lilypond" from Debian testing
>> but it's also not possible to do
>>
>> # apt-get build-dep lilypond
>
> I discovered it just yesterday.
>
>>
>> So is there a way to get LilyPond's build-dependencies on that distro
>> (either a list of dependencies to install manually or by pinning it to
>> an older release?
>
> You can find a list here (change it to a one line so you can paste it
> on a terminal):
> https://github.com/fedelibre/LilyDev/blob/master/config/package-lists/lilypond.list.chroot
>

OK, thank you.
After installing these building LilyPond fails with the following error:

WARNING: Please consider installing optional programs or files:  URW++
OTF fonts (download OTF files from
'http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=79bcdfb34fbce12b592cce389fa7a19da6b5b018'
and put them under '~/.local/share/fonts' etc., or use
--with-urwotf-dir) guile extractpdfmark (Optionally using Ghostscript >=
9.20 together with Extract PDFmark can significantly reduce the disk
space required for building the documentation and the final PDF files.)

ERROR: Please install required programs:  guile-config (guile-devel,
guile-dev or libguile-dev package) libguile (libguile-dev, guile-devel
or guile-dev package). GUILE-with-rational-bugfix Python.h
(python-devel, python-dev or libpython-dev package) pkg-config makeinfo
texi2html texi2pdf texindex

So it seems I'll be at the same stage as before because there won't be a
guile 1.8 available ...

Seems I traded running Frescobaldi for not being able to build LilyPond
anymore ...

Best
Urs


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


Re: guile-2.0 and debian

2016-12-07 Thread Urs Liska


Am 07.12.2016 um 09:53 schrieb Federico Bruni:
> Yesterday I was updating LilyDev to stretch (now testing) and I found
> that ttf- packages are no more in Debian. B

I wanted to install ttf-inconsolata and was directed to install
fonts-inconsolata instead. Does that help?

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


Re: referencing hash key with music symbol

2016-12-07 Thread Han-Wen Nienhuys
On Sat, Jul 9, 2016 at 10:37 AM, Jeffery Shivers
 wrote:
>
> \criticalRemark \with {
>
> message = "my message"
>
> apply = addition
>
> } Slur f'( g') %  "Slur" indicated here
>
>
> ... we will use that symbol to determine what function, previously assigned
> to the so-named key in the hash table, to apply to the music. However, when
> I attempt to do this, Lily (or maybe Guile) doesn't cooperate. I don't have

just a guess, but Slur unadorned like that becomes a string rather
than symbol. Have you tried converting strings to symbols before doing
the hash lookup?

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

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


Re: guile-2.0 and debian

2016-12-07 Thread Federico Bruni
Il giorno mer 7 dic 2016 alle 8:42, Urs Liska  ha 
scritto:

 In case you don't know already, last news about guile2 and debian:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#216


Just for the record (although it's probably evident):
This doesn't only mean one can't install "lilypond" from Debian 
testing

but it's also not possible to do

# apt-get build-dep lilypond


I discovered it just yesterday.



So is there a way to get LilyPond's build-dependencies on that distro
(either a list of dependencies to install manually or by pinning it to
an older release?


You can find a list here (change it to a one line so you can paste it 
on a terminal):

https://github.com/fedelibre/LilyDev/blob/master/config/package-lists/lilypond.list.chroot

Yesterday I was updating LilyDev to stretch (now testing) and I found 
that ttf- packages are no more in Debian. But lilypond configure does 
not complain. And same for xfonts-intl packages. Maybe recent changes 
by Masamichi changed the dependencies? I did not investigate.


I think that you can ignore these packages:

ttf-dejavu
ttf-freefont
ttf-kochi-gothic
ttf-kochi-mincho
xfonts-intl-arabic
xfonts-intl-asian
xfonts-intl-chinese
xfonts-intl-chinese-big
xfonts-intl-european
xfonts-intl-japanese
xfonts-intl-japanese-big
xfonts-intl-phonetic




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