Re: Allura API

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: 
Sent: Monday, August 31, 2015 2:26 PM
Subject: Allura API



You might like to know that I'm investigating the Allura API to see how we
could use it for Patchy, git-cl, etc.  With any luck I'll have a demo web
page up in an hour or so.


Very quick and dirty proof of concept.  This lists all the patches with the 
status "Started" and finds their Rietveld URLs.  The theory works just as 
well with patch:new, but there were so few results it didn't demonstrate 
much.


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

--
Phil Holmes 



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

Re: Allura API

[Trevor Daniels]

Phil Holmes wrote Monday, August 31, 2015 4:10 PM
>
> Very quick and dirty proof of concept.  This lists all the patches with the 
> status "Started" and finds their Rietveld URLs.  The theory works just as 
> well with patch:new, but there were so few results it didn't demonstrate 
> much.
> 
> http://philholmes.net/lilypond/allura/

Promising start, Phil!  Shows you've mastered the authentication and API 
documentation.  No mean feat.

I think you've found status:Started && _patch:review, rather than just 
status:Started, yes?
Or maybe just _patch:review.

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

Re: Allura API

[Phil Holmes]

- Original Message - 
From: "Trevor Daniels" 

To: "Phil Holmes" ; 
Sent: Monday, August 31, 2015 4:23 PM
Subject: Re: Allura API




Phil Holmes wrote Monday, August 31, 2015 4:10 PM


Very quick and dirty proof of concept.  This lists all the patches with 
the

status "Started" and finds their Rietveld URLs.  The theory works just as
well with patch:new, but there were so few results it didn't demonstrate
much.

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


Promising start, Phil!  Shows you've mastered the authentication and API 
documentation.  No mean feat.


I think you've found status:Started && _patch:review, rather than just 
status:Started, yes?

Or maybe just _patch:review.

Trevor



No authentication needed to do this, so I've not mastered that :-(.  I meant 
what you said about the labels, but posted inaccurately.


Most difficult bit was working out how to parse JSON in c# :-o  Oh: and 
navigating the almost impenetrable documentation to the one page I found 
useful: https://sourceforge.net/p/forge/documentation/Allura%20API/


This points out that something like

https://sourceforge.net/rest/p/testlilyissues/issues/4584

returns the JSON representation of ticket 4584.

--
Phil Holmes 



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

Re: Allura API

[Trevor Daniels]

Phil, you wrote Monday, August 31, 2015 4:28 PM

> No authentication needed to do this, so I've not mastered that :-(.  I meant 
> what you said about the labels, but posted inaccurately.

Ah, maybe authentication is only needed for making changes.
 
> Most difficult bit was working out how to parse JSON in c# :-o  Oh: and 
> navigating the almost impenetrable documentation to the one page I found 
> useful: https://sourceforge.net/p/forge/documentation/Allura%20API/
> 
> This points out that something like
> 
> https://sourceforge.net/rest/p/testlilyissues/issues/4584
> 
> returns the JSON representation of ticket 4584.

Export provides the JSON representation of the entire DB.  I use that to change 
the original author from *anonymous to GoogleImporter before re-importing, so 
the whole world doesn't have write access.

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

New French PO file for 'lilypond' (version 2.19.26)

[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 French team of translators.  The file is available at:

http://translationproject.org/latest/lilypond/fr.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:

http://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:

http://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.



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

Re: 2.19.26 regtests

[Masamichi HOSODA]

I've post a message to the tracker.
https://sourceforge.net/p/testlilyissues/issues/4585/

I've made a GUB's patch and send pull request.
https://github.com/gperciva/gub/pull/20

Would you merge it and try following command before make lilypond?

$ git fetch orign
$ git checkout master
$ git merge origin/master
$ rm -fr downloads/fonts-urw-core35/

> I've forwarded this to the bug list so someone should create a
> tracker.
> 
> Please note the bug list is now at
> http://sourceforge.net/p/testlilyissues/issues/
> 
> --
> Phil Holmes
> 
> 
> - Original Message - 
> From: "Masamichi HOSODA" 
> To: 
> Cc: 
> Sent: Monday, August 31, 2015 3:17 PM
> Subject: Re: 2.19.26 regtests
> 
> 
>There's lots of differences, presumably down to font changes,

 Also sans \bold and \italic do not seem to work in
 font-family-override.ly
>>>
>>> Well, I call uh-oh.  It will probably take a few more unstable
>>> releases
>>> to shake out the problems from the font setup changes.
>>
>> Probably, it caused by URW fonts problem and/or Pango version.
>>
>> In my experiment, with newest URW fonts release (commit date is
>> 2015-08-28)
>> and newest Pango (version 1.36.8, 2014-09), there is no problem.
>> Attached file is the result.
>>
>>
>> First, the previous URW fonts release (commit date is 2015-08-25)
>> seems broken.
>> It has "Nimbus Sans Regular", "Nimbus Sans L Bold",
>> "Nimbus Sans L Regular Italic", "Nimbus Sans L Bold Italic".
>> Only "Regular" font's family name is "Nimbus Sans"
>> but others are "Nimbus Sans L".
>>
>> http://bugs.ghostscript.com/show_bug.cgi?id=696089
>> http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commitdiff;h=ee2beed6
>>
>> The newest URW fonts release has no "Nimbus Sans" but "Nimbus Sans L".
>>
>> http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=c983ed400dc278dcf20bdff68252fad6d9db7af9
>>
>>
>> Next, we use old Pango (version 1.28.3, 2010-09) in GUB.
>> In four years, many bugs would have been fixed.
>>
>>
>> So I'll make a GUB's patch that updates URW fonts and Pango.
>>
>>
>> Would I create an Issue on tracker?
>> How can I do so?
>> Or, would someone create it?
>>
> 
> 
> 
> 
> 
>> ___
>> 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: 2.19.26 regtests

[Masamichi HOSODA]

There's lots of differences, presumably down to font changes,
>>>
>>> Also sans \bold and \italic do not seem to work in font-family-override.ly
>> 
>> And in kievan-notation.ly the spacing of the lyrics in-syllable is
>> awful.  Whatever font we chose there has metrics that appear hardly
>> suitable to me for running text.
> 
> kievan-notation.ly seems to use DejaVu Serif.
> It should be Linux Libertine like utf-8.ly using.
> I'll make a patch.

I've created Issue 4587.
http://sourceforge.net/p/testlilyissues/issues/4587/

And, I've uploaded a patch.
https://codereview.appspot.com/264080043

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

Re: 2.19.26 regtests

[David Kastrup]

Masamichi HOSODA  writes:

>There's lots of differences, presumably down to font changes,

 Also sans \bold and \italic do not seem to work in font-family-override.ly
>>> 
>>> And in kievan-notation.ly the spacing of the lyrics in-syllable is
>>> awful.  Whatever font we chose there has metrics that appear hardly
>>> suitable to me for running text.
>> 
>> kievan-notation.ly seems to use DejaVu Serif.
>> It should be Linux Libertine like utf-8.ly using.
>> I'll make a patch.
>
> I've created Issue 4587.
> http://sourceforge.net/p/testlilyissues/issues/4587/
>
> And, I've uploaded a patch.
> https://codereview.appspot.com/264080043

Thanks.

-- 
David Kastrup

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

Issue 4587: Add font settings to kievan-notation.ly (issue 264080043 by truer...@gmail.com)

[lemzwerg]

LGTM

https://codereview.appspot.com/264080043/

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

Fix regtest "dynamics-broken-hairpin.ly" (issue 258470044 by simon.albre...@mail.de)

[simon . albrecht]

Reviewers: ,

Message:
My first patch :-)

Description:
Fix regtest "dynamics-broken-hairpin.ly"

Change regtest to match its title, including an updated description.

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

Affected files (+9, -5 lines):
  M input/regression/dynamics-broken-hairpin.ly


Index: input/regression/dynamics-broken-hairpin.ly
diff --git a/input/regression/dynamics-broken-hairpin.ly  
b/input/regression/dynamics-broken-hairpin.ly
index  
b412a7ea9428904e23192da6139f3610cede1919..cfd6d90f575c096e8f4e6d80eefb6cf111c6cde1  
100644

--- a/input/regression/dynamics-broken-hairpin.ly
+++ b/input/regression/dynamics-broken-hairpin.ly
@@ -1,7 +1,7 @@
+\version "2.19.25"

-\version "2.19.21"
-\header{
-texidoc = "Broken crescendi should be open on one side."
+\header {
+  texidoc = "When a hairpin is broken, the broken parts should be open at  
the ‘breaking point’."

 }

 \layout {
@@ -9,7 +9,11 @@ texidoc = "Broken crescendi should be open on one side."
 }


-\relative {
-  c''1 \< \break c1\!  \> \break c1\!
+\relative {
+   c''1 \< \break
+   c
+   c\> \break
+   c
+   c\!
 }



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

Re: Fix regtest "dynamics-broken-hairpin.ly" (issue 258470044 by simon.albre...@mail.de)

[david . nalesnik]

https://codereview.appspot.com/258470044/diff/1/input/regression/dynamics-broken-hairpin.ly
File input/regression/dynamics-broken-hairpin.ly (right):

https://codereview.appspot.com/258470044/diff/1/input/regression/dynamics-broken-hairpin.ly#newcode1
input/regression/dynamics-broken-hairpin.ly:1: \version "2.19.25"
\version "2.19.27"

https://codereview.appspot.com/258470044/

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

Re: New bug tracker?

[Trevor Daniels]

Javier Ruiz-Alma wrote Monday, August 31, 2015 4:12 AM

> Is there a new bug tracker for Lilypond?
> LP site still points to the now-read-only tracker:
> http://lilypond.org/bug-reports.html
 
We are currently in transition between bug trackers.  The intention is to 
migrate to a new bug tracker at Savannah, and this is being set up at present.

In the meantime we have an interim bug tracker for use by developers only, so 
we can keep track of changes.  I'd rather not direct users to this temporary 
arrangement to avoid confusion later.

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

Re: Implement new markup-command combine-list (issue 264960043 by thomasmorle...@gmail.com)

[dak]

On 2015/08/30 12:08:29, dak wrote:

On 2015/08/30 12:02:14, thomasmorley651 wrote:
> On 2015/08/30 11:44:52, dak wrote:
> >


https://codereview.appspot.com/264960043/diff/1/scm/define-markup-commands.scm

> > File scm/define-markup-commands.scm (right):
> >
> >
>


https://codereview.appspot.com/264960043/diff/1/scm/define-markup-commands.scm#newcode1758

> > scm/define-markup-commands.scm:1758: (define-markup-command

(combine-list

> layout
> > props args)
> > For better or worse, we don't have other commands of *-list form.

Commands

> that
> > _deliver_ a markup list are usually named *-lines for whatever

reason.  But

> this
> > command delivers a single markup.  I don't have a better proposal

though.

>
> I thought about deleting old \combine,



Yes, that sounds like a sensible path forward.



>but too much user-code relies on it.
> Apart from not knowing python I really have no clue how something

like the

below
> could be caught by a convert-rule:
>
> \markup {
> \combine
>  arg1
>  \combine
>   arg2
>   \combine
>arg3
>arg4
> }
>
> and transformed to:
>
> \markup \combine-list { arg1 arg2 arg3 arg4 }



Probably more doable than recognizing a single markup reliably.  I'd

have to see

how well this works.


Ok, I've taken a look.  Markups are so undelimited in their nature that
there is not much of an option other than convert-ly actually knowing
all markup commands with their signatures.  That's doable but rather
onerous.  In addition, musicxml2ly uses the \combine command as well.

So we are likely better off with a new command name.  "\combines" would
also be a possibility but is probably too cute/confusing/unhyphenated.
Now if we basically phase out \combine and replace most of its uses
manually, it would become an option just to use some _unrelated_ word.

Like \superimpose or \overlay or \collect or something other nice.  Or
just keep the bikeshed in the originally proposed color.

https://codereview.appspot.com/264960043/

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

Re: Allura at SF is ready

[Trevor Daniels]

James Lowe wrote Monday, August 31, 2015 9:29 AM
 
> @Trevor
> 
> Assuming that you eventually start the migration, I assume you'll tell
> the group and we'd best hold off updating SF until it is completed (so
> that we don't interfere with the migration)?

Yes, that would be sensible.  It should take little more than two days, 
assuming no glitches or gotchas, as only one import should be required (not the 
two needed when migrating from GC).  To be sure of the migration state I would 
disable updating during the migration proper anyway.

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

Re: Allura at SF is ready

[James Lowe]

Trevor,

On 30/08/15 16:57, Trevor Daniels wrote:
> 
> James wrote Sunday, August 30, 2015 4:22 PM
> 
>> I've 'synced' my list of Patches I've been keeping track of
>> manually with the issues list now.
>> 
>> Is this set of issues going to be the one we migrate to the 'new'
>> non-SF system?
>> 
>> I.e. do we now treat this as a live system?
> 
> Yes.  When we migrate to Allura at Savannah I will export from this
> SF system and import to the Savannah system.  I shall not be
> returning to GoogleCode (unless some disaster befalls).
> 
> Now you've completed your work I'll invite the Bug Squad to join up
> so they can continue their work in catching new issues.
> 
> I've not heard anything from Federico or Josiah for over a week, so
> I've no idea what state Allura at Savannah is in.  I suggest we
> wait a few days for news before inviting devs to join at SF, in
> case the Savannah system comes on line soon.  Are you willing to
> update the DB with pushes when they occur for a few days?
> 

Not a problem - how I 'display' those in the PATCHES email is
something I need to work on, as the make-countdown-announcement.sh no
longer works.

@everyone:

So from now on (unless anyone thinks I shouldn't), I won't be updating
Rietvelds with PATCH statuses anymore, but using SF instead. If I find
anything in my current list that doesn't have an issue in SF (for
whatever reason, I will add it and will 'own' that - each issue has to
have an email of the owner - and ask that dev to register so they can
take the issue themselves.

@Trevor

Assuming that you eventually start the migration, I assume you'll tell
the group and we'd best hold off updating SF until it is completed (so
that we don't interfere with the migration)?

James




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

Re: 2.19.26 regtests

[Masamichi HOSODA]

>>>There's lots of differences, presumably down to font changes,
>>
>> Also sans \bold and \italic do not seem to work in
>> font-family-override.ly
> 
> Well, I call uh-oh.  It will probably take a few more unstable releases
> to shake out the problems from the font setup changes.

Probably, it caused by URW fonts problem and/or Pango version.

In my experiment, with newest URW fonts release (commit date is 2015-08-28)
and newest Pango (version 1.36.8, 2014-09), there is no problem.
Attached file is the result.


First, the previous URW fonts release (commit date is 2015-08-25) seems broken.
It has "Nimbus Sans Regular", "Nimbus Sans L Bold",
"Nimbus Sans L Regular Italic", "Nimbus Sans L Bold Italic".
Only "Regular" font's family name is "Nimbus Sans"
but others are "Nimbus Sans L".

http://bugs.ghostscript.com/show_bug.cgi?id=696089
http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commitdiff;h=ee2beed6

The newest URW fonts release has no "Nimbus Sans" but "Nimbus Sans L".

http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=c983ed400dc278dcf20bdff68252fad6d9db7af9


Next, we use old Pango (version 1.28.3, 2010-09) in GUB.
In four years, many bugs would have been fixed.


So I'll make a GUB's patch that updates URW fonts and Pango.


Would I create an Issue on tracker?
How can I do so?
Or, would someone create it?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 2.19.26 regtests

[Phil Holmes]

I've forwarded this to the bug list so someone should create a tracker.

Please note the bug list is now at 
http://sourceforge.net/p/testlilyissues/issues/


--
Phil Holmes


- Original Message - 
From: "Masamichi HOSODA" 

To: 
Cc: 
Sent: Monday, August 31, 2015 3:17 PM
Subject: Re: 2.19.26 regtests



There's lots of differences, presumably down to font changes,


Also sans \bold and \italic do not seem to work in
font-family-override.ly


Well, I call uh-oh.  It will probably take a few more unstable releases
to shake out the problems from the font setup changes.


Probably, it caused by URW fonts problem and/or Pango version.

In my experiment, with newest URW fonts release (commit date is 
2015-08-28)

and newest Pango (version 1.36.8, 2014-09), there is no problem.
Attached file is the result.


First, the previous URW fonts release (commit date is 2015-08-25) seems 
broken.

It has "Nimbus Sans Regular", "Nimbus Sans L Bold",
"Nimbus Sans L Regular Italic", "Nimbus Sans L Bold Italic".
Only "Regular" font's family name is "Nimbus Sans"
but others are "Nimbus Sans L".

http://bugs.ghostscript.com/show_bug.cgi?id=696089
http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commitdiff;h=ee2beed6

The newest URW fonts release has no "Nimbus Sans" but "Nimbus Sans L".

http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=c983ed400dc278dcf20bdff68252fad6d9db7af9


Next, we use old Pango (version 1.28.3, 2010-09) in GUB.
In four years, many bugs would have been fixed.


So I'll make a GUB's patch that updates URW fonts and Pango.


Would I create an Issue on tracker?
How can I do so?
Or, would someone create it?








___
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

Allura API

[Phil Holmes]

You might like to know that I'm investigating the Allura API to see how we 
could use it for Patchy, git-cl, etc.  With any luck I'll have a demo web 
page up in an hour or so.


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

Re: Allura API

[David Kastrup]

Phil Holmes  writes:

> You might like to know that I'm investigating the Allura API to see
> how we could use it for Patchy, git-cl, etc.  With any luck I'll have
> a demo web page up in an hour or so.

Well, that would certainly be something rather valuable.

-- 
David Kastrup

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

Re: 2.19.26 regtests

[Masamichi HOSODA]

>>>There's lots of differences, presumably down to font changes,
>>
>> Also sans \bold and \italic do not seem to work in font-family-override.ly
> 
> And in kievan-notation.ly the spacing of the lyrics in-syllable is
> awful.  Whatever font we chose there has metrics that appear hardly
> suitable to me for running text.

kievan-notation.ly seems to use DejaVu Serif.
It should be Linux Libertine like utf-8.ly using.
I'll make a patch.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel