Re: Implement new markup-command combine-list (issue 264960043 by thomasmorle...@gmail.com)
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.
https://codereview.appspot.com/264960043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
Hello, On 30/08/15 11:34, Phil Holmes wrote: OK - it looks like lilypond.org is now back, and I can SSH to it again. However, I still can't complete the upload of files because of lack of disk space on the server. I've emailed the admin but no response yet. That said, we do seem to be storing an enormous amount of potentially unneeded stuff there. Do we really need _all_ the 2.15 and 2.17 documentation stored there? (http://lilypond.org/download/binaries/documentation/) And all the test output? (http://lilypond.org/download/binaries/test-output/) Please look at http://lilypond.org/download/binaries/ and let me know whether you think we can delete some of that, or potentially archive it elsewhere. I would probably at least start by removing all the old unstable release stuff (2.15.x and 2.17.x) we're not going to need those really are we? James ___ 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)
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. https://codereview.appspot.com/264960043/diff/1/scm/define-markup-commands.scm#newcode1778 scm/define-markup-commands.scm:1778: (map (lambda (e) (interpret-markup layout props e)) args))) This does not work for markup lists built using markup list commands. The whole line should rather be (interpret-markup-list layout props args))) https://codereview.appspot.com/264960043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
Phil Holmes wrote Sunday, August 30, 2015 11:34 AM OK - it looks like lilypond.org is now back, and I can SSH to it again. However, I still can't complete the upload of files because of lack of disk space on the server. I've emailed the admin but no response yet. That said, we do seem to be storing an enormous amount of potentially unneeded stuff there. Do we really need _all_ the 2.15 and 2.17 documentation stored there? (http://lilypond.org/download/binaries/documentation/) And all the test output? (http://lilypond.org/download/binaries/test-output/) Please look at http://lilypond.org/download/binaries/ and let me know whether you think we can delete some of that, or potentially archive it elsewhere. We should keep all the even-numbered releases, but could delete all the stuff relating to the 2.15 release now, IMO. That should free up enough space for the moment. 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)
Passes make, make check and a full make doc PATCH_REVIEW https://codereview.appspot.com/264960043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond.org - file storage
OK - it looks like lilypond.org is now back, and I can SSH to it again. However, I still can't complete the upload of files because of lack of disk space on the server. I've emailed the admin but no response yet. That said, we do seem to be storing an enormous amount of potentially unneeded stuff there. Do we really need _all_ the 2.15 and 2.17 documentation stored there? (http://lilypond.org/download/binaries/documentation/) And all the test output? (http://lilypond.org/download/binaries/test-output/) Please look at http://lilypond.org/download/binaries/ and let me know whether you think we can delete some of that, or potentially archive it elsewhere. Thanks. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement new markup-command combine-list (issue 264960043 by thomasmorle...@gmail.com)
Reviewers: ,
Message:
Please review
PATCH_NEW
Description:
Implement new markup-command combine-list
Allows for \markup \combine-list { a list }
Please review this at https://codereview.appspot.com/264960043/
Affected files (+23, -5 lines):
M scm/define-markup-commands.scm
Index: scm/define-markup-commands.scm
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index
505ca246c7bf6e6489f47b9f4351e6ce9c2f58e3..1206ee3ace8a1029c387f187c154d91d8df5d068
100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -1740,11 +1740,7 @@ the line width, where @var{X} is the number of staff
spaces.
Print two markups on top of each other.
Note: @code{\\combine} cannot take a list of markups enclosed in
-curly braces as an argument; the follow example will not compile:
-
-@example
-\\combine @{ a list @}
-@end example
+curly braces as an argument; for this purpose use @code{\\combine-list}
instead.
@lilypond[verbatim,quote]
\\markup {
@@ -1759,6 +1755,28 @@ curly braces as an argument; the follow example will
not compile:
(s2 (interpret-markup layout props arg2)))
(ly:stencil-add s1 s2)))
+(define-markup-command (combine-list layout props args)
+ (markup-list?)
+ #:category align
+
+@cindex merging text
+
+Takes a list of markups combining them.
+
+@lilypond[verbatim,quote]
+\\markup {
+ \\fontsize #5
+ \\override #'(thickness . 2)
+ \\combine-list {
+\\draw-line #'(0 . 4)
+\\arrow-head #Y #DOWN ##f
+\\translate #'(0 . 4)\\arrow-head #Y #UP ##f
+ }
+}
+@end lilypond
+ (apply ly:stencil-add
+(map (lambda (e) (interpret-markup layout props e)) args)))
+
;;
;; TODO: should extract baseline-skip from each argument somehow..
;;
___
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)
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, 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 }
https://codereview.appspot.com/264960043/diff/1/scm/define-markup-commands.scm#newcode1778
scm/define-markup-commands.scm:1778: (map (lambda (e)
(interpret-markup layout
props e)) args)))
This does not work for markup lists built using markup list commands.
The whole
line should rather be (interpret-markup-list layout props args)))
Done.
Thanks.
PATCH_NEW
https://codereview.appspot.com/264960043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CL output language within lily-git.tcl
2015-08-30 23:27 GMT+02:00 Simon Albrecht simon.albre...@mail.de: Am 30.08.2015 um 22:29 schrieb Simon Albrecht: Hello, I’m quite surprised that the command line output of Git displayed in lily-git.tcl is in German While the messages from lily-git itself are English… – if I run Git directly from the terminal, it’s English, and indeed I’ve even changed the language of my whole system to English by now (that was before I had lily-git.tcl). How can I fix that? German git output is quite annoying… TIA, Simon Hi Simon, I started using git with lily-git.tcl, though it's too long ago. Can't be of any help with your current language problem. Though, I'd like to suggest to get used to use git directly as soon as possible. Once you'll need more than one branch at the same time the gui is not helpful anymore, iirc. I remember as a starter I messed up my local git at least once a day or the like. And the desk of my table has some bite marks now ... Good training to sort it out, though. Ofcourse I had great help from the list. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clear fret-diagram- and harp-pedal-input-strings from whitespace (issue 257580043 by thomasmorle...@gmail.com)
Passes make, make check and a full make doc PATCH_REVIEW https://codereview.appspot.com/257580043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Learning about Allura
Am 30.08.2015 um 22:27 schrieb Trevor Daniels: @Bug Squad I've noticed a couple of things about Allura which are worth mentioning: a) When you add a new issue or change the status, patch, label, etc, of an existing one, it takes some time, i.e. several minutes, before it shows up in searches involving the new value. Allura maintains a large inverted index in order to reduce the time and resource needed to perform complex searches, but the price for this is the increased time required to modify that index when one of the field values changes. b) This is a real nuisance. The body text of issues uses markup. See Formatting Help underneath the search buttons. Some of this is useful, but some not. In particular, a line with # in column one means format as a huge header. So a line of Scheme which is not indented appears huge. This means that Lily source code should be either indented by four spaces or a tab. Alternatively, insert a line containing 4 (or more) tildes before and after the Lily code. As an example, see https://sourceforge.net/p/testlilyissues/issues/4581/ before Simon works out how to fix it ;) So I’ll wait a little until I do so :-) Cheers, Simon Trevor ___ bug-lilypond mailing list bug-lilyp...@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New template for 'lilypond' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to coordina...@translationproject.org.) A new POT file for textual domain 'lilypond' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/lilypond-2.19.26.pot 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. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: http://download.linuxaudio.org/lilypond/source/v2.19/lilypond-2.19.26.tar.gz We can arrange things so that translated PO files are automatically e-mailed to you when they arrive. Ask at the address below if you want this. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
CL output language within lily-git.tcl
Hello, I’m quite surprised that the command line output of Git displayed in lily-git.tcl is in German – if I run Git directly from the terminal, it’s English, and indeed I’ve even changed the language of my whole system to English by now (that was before I had lily-git.tcl). How can I fix that? German git output is quite annoying… TIA, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Learning about Allura
@Bug Squad I've noticed a couple of things about Allura which are worth mentioning: a) When you add a new issue or change the status, patch, label, etc, of an existing one, it takes some time, i.e. several minutes, before it shows up in searches involving the new value. Allura maintains a large inverted index in order to reduce the time and resource needed to perform complex searches, but the price for this is the increased time required to modify that index when one of the field values changes. b) This is a real nuisance. The body text of issues uses markup. See Formatting Help underneath the search buttons. Some of this is useful, but some not. In particular, a line with # in column one means format as a huge header. So a line of Scheme which is not indented appears huge. This means that Lily source code should be either indented by four spaces or a tab. Alternatively, insert a line containing 4 (or more) tildes before and after the Lily code. As an example, see https://sourceforge.net/p/testlilyissues/issues/4581/ before Simon works out how to fix it ;) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CL output language within lily-git.tcl
Am 30.08.2015 um 22:29 schrieb Simon Albrecht: Hello, I’m quite surprised that the command line output of Git displayed in lily-git.tcl is in German While the messages from lily-git itself are English… – if I run Git directly from the terminal, it’s English, and indeed I’ve even changed the language of my whole system to English by now (that was before I had lily-git.tcl). How can I fix that? German git output is quite annoying… TIA, Simon ___ 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: lilypond.org - file storage
- Original Message - From: Jean-Charles Malahieude lily...@orange.fr To: Graham Percival gra...@percival-music.ca; Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, August 30, 2015 4:57 PM Subject: Re: lilypond.org - file storage Le 30/08/2015 17:45, Graham Percival a écrit : On Sun, Aug 30, 2015 at 01:15:48PM +0100, Phil Holmes wrote: We also have source files back to 0.0 and 1.0. I assume we could never recreate these from Git, but are we ever going to need to? It certainly seems pointless keeping lots of source tarballs, given that all the more recent history is in Git. I think it would be nice to keep the ancient history around; software archeology research sometimes look at open-source projects. That said, they don't necessarily need to be on that particular web server. Something like Amazon Glacier could work well for that, or maybe google drive... there are other storage platforms available. (and no, I'm not in a position to offer to take care of this) I fully support deleting all test-output for non-current development versions. (though again, in an ideal world they would be stored on some other server or service) BTW, is there any difference between download/source and download/sources ? Cheers, Jean-Charles One is a symlink to the other. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, August 30, 2015 4:45 PM Subject: Re: lilypond.org - file storage On Sun, Aug 30, 2015 at 01:15:48PM +0100, Phil Holmes wrote: We also have source files back to 0.0 and 1.0. I assume we could never recreate these from Git, but are we ever going to need to? It certainly seems pointless keeping lots of source tarballs, given that all the more recent history is in Git. I think it would be nice to keep the ancient history around; software archeology research sometimes look at open-source projects. That said, they don't necessarily need to be on that particular web server. Something like Amazon Glacier could work well for that, or maybe google drive... there are other storage platforms available. (and no, I'm not in a position to offer to take care of this) I fully support deleting all test-output for non-current development versions. (though again, in an ideal world they would be stored on some other server or service) Cheers, - Graham I'm happy in principle with keeping as much as we can, and happy to do the work. Problem is, AFAIK we only have SSH access to lilypond.org, so the only way to move these files somewhere else is via my PC via DSL: very slow and will kill my bandwidth limit. The best way to do this would be to another server with ftp, SCP or whatever support: but these tend not to be provided by the free providers. If all else fails I'd be prepared to buy lifetime hosting of an unlimited package with my current provider, but before doing that: is there any part of the Free community that provides free archiving? -- Phil Holmes ___ 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)
Passes make, make check and a full make doc PATCH_REVIEW https://codereview.appspot.com/264960043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.19.26 regtests
There's lots of differences, presumably down to font changes, but I'd like someone who understands autochange to look at autochange-inside-grace.ly http://lilypond.org/test/v2.19.26-1/compare-v2.19.25-1/index.html Is this change expected? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.19.26 regtests
Phil Holmes m...@philholmes.net writes: There's lots of differences, presumably down to font changes, but I'd like someone who understands autochange to look at autochange-inside-grace.ly http://lilypond.org/test/v2.19.26-1/compare-v2.19.25-1/index.html Is this change expected? Yes, this change is expected and a bug fix. See URL:https://code.google.com/p/lilypond/issues/detail?id=4569#c2. Since \autochange no longer moves from an existing Voice into the first Voice of the up Staff at startup, the final c' is typeset where \autochange left the Voice started in the down Staff after the grace notes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
- Original Message - From: James p...@gnu.org To: Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org Sent: Sunday, August 30, 2015 11:57 AM Subject: Re: lilypond.org - file storage Hello, On 30/08/15 11:34, Phil Holmes wrote: OK - it looks like lilypond.org is now back, and I can SSH to it again. However, I still can't complete the upload of files because of lack of disk space on the server. I've emailed the admin but no response yet. That said, we do seem to be storing an enormous amount of potentially unneeded stuff there. Do we really need _all_ the 2.15 and 2.17 documentation stored there? (http://lilypond.org/download/binaries/documentation/) And all the test output? (http://lilypond.org/download/binaries/test-output/) Please look at http://lilypond.org/download/binaries/ and let me know whether you think we can delete some of that, or potentially archive it elsewhere. I would probably at least start by removing all the old unstable release stuff (2.15.x and 2.17.x) we're not going to need those really are we? James I've actually downloaded the test-output for 2.15.30 - 39 in case anyone objects, and it looks like the upload is back running again. I'll leave it another day or so, but then plan to *delete* all the 2.15 files, except 15.95. We also have source files back to 0.0 and 1.0. I assume we could never recreate these from Git, but are we ever going to need to? It certainly seems pointless keeping lots of source tarballs, given that all the more recent history is in Git. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allura at SF is ready
Hello Trevor, Some comments if I may be so bold. 1. I think it would be useful to have 'Searches' (defined on that left hand side panel) for each of the Patch states New Review Countdown Push At the moment we have 'Review' only. The 'Fixed' search 2. It seems that the 'Needs' field is mandatory and this is going to be misleading I think. For example if you look at the new issue I entered manually: https://sourceforge.net/p/testlilyissues/issues/4576/ This has a 'Needs: design' tag which is inappropriate (and incorrect). Otherwise it seems simple enough. Thank you. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.19.26 regtests
Mark Knoop m...@opus11.net writes: At 14:41 on 30 Aug 2015, Phil Holmes wrote: 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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allura at SF is ready
Hello Trevor, On 30/08/15 15:00, Trevor Daniels wrote: James, you wrote Sunday, August 30, 2015 1:47 PM Some comments if I may be so bold. Of course - most welcome! 1. I think it would be useful to have 'Searches' (defined on that left hand side panel) for each of the Patch states New Review Countdown Push Presumably you'd like these restricted to status:Started? Otherwise you'll see lots of status:Verified, Abandoned, etc. Anyway, that's what I've done - easily changed though. These are the four Patch( ... ) searches. Open(Patch) now shows all the Started issues with a non-zero patch field. Useful for finding issues with incorrectly set fields. As a dev you can fix these. It also includes the needs_work, abandoned, and waiting patch states. The 'Fixed' search This shows all the patches waiting to be Verified. Useful for the bug squad. 2. It seems that the 'Needs' field is mandatory and this is going to be misleading I think. For example if you look at the new issue I entered manually: https://sourceforge.net/p/testlilyissues/issues/4576/ This has a 'Needs: design' tag which is inappropriate (and incorrect). I've defined as the default for this field; should be OK for new issues now. That also reminded me to define defaults for other fields too. Otherwise it seems simple enough. Thanks! Trevor Thank you. 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? james ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
On Sun, Aug 30, 2015 at 05:57:45PM +0200, Jean-Charles Malahieude wrote: BTW, is there any difference between download/source and download/sources ? I'm pretty certain that one is a symlink of the other. If not, then one was a place to store some odd tarballs for GUB to download. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.19.26 regtests
Mark Knoop m...@opus11.net writes: At 14:41 on 30 Aug 2015, Phil Holmes wrote: 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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
On Sun, Aug 30, 2015 at 01:15:48PM +0100, Phil Holmes wrote: We also have source files back to 0.0 and 1.0. I assume we could never recreate these from Git, but are we ever going to need to? It certainly seems pointless keeping lots of source tarballs, given that all the more recent history is in Git. I think it would be nice to keep the ancient history around; software archeology research sometimes look at open-source projects. That said, they don't necessarily need to be on that particular web server. Something like Amazon Glacier could work well for that, or maybe google drive... there are other storage platforms available. (and no, I'm not in a position to offer to take care of this) I fully support deleting all test-output for non-current development versions. (though again, in an ideal world they would be stored on some other server or service) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allura at SF is ready
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? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
Le 30/08/2015 17:45, Graham Percival a écrit : On Sun, Aug 30, 2015 at 01:15:48PM +0100, Phil Holmes wrote: We also have source files back to 0.0 and 1.0. I assume we could never recreate these from Git, but are we ever going to need to? It certainly seems pointless keeping lots of source tarballs, given that all the more recent history is in Git. I think it would be nice to keep the ancient history around; software archeology research sometimes look at open-source projects. That said, they don't necessarily need to be on that particular web server. Something like Amazon Glacier could work well for that, or maybe google drive... there are other storage platforms available. (and no, I'm not in a position to offer to take care of this) I fully support deleting all test-output for non-current development versions. (though again, in an ideal world they would be stored on some other server or service) BTW, is there any difference between download/source and download/sources ? Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allura at SF is ready
James, you wrote Sunday, August 30, 2015 1:47 PM Some comments if I may be so bold. Of course - most welcome! 1. I think it would be useful to have 'Searches' (defined on that left hand side panel) for each of the Patch states New Review Countdown Push Presumably you'd like these restricted to status:Started? Otherwise you'll see lots of status:Verified, Abandoned, etc. Anyway, that's what I've done - easily changed though. These are the four Patch( ... ) searches. Open(Patch) now shows all the Started issues with a non-zero patch field. Useful for finding issues with incorrectly set fields. As a dev you can fix these. It also includes the needs_work, abandoned, and waiting patch states. The 'Fixed' search This shows all the patches waiting to be Verified. Useful for the bug squad. 2. It seems that the 'Needs' field is mandatory and this is going to be misleading I think. For example if you look at the new issue I entered manually: https://sourceforge.net/p/testlilyissues/issues/4576/ This has a 'Needs: design' tag which is inappropriate (and incorrect). I've defined as the default for this field; should be OK for new issues now. That also reminded me to define defaults for other fields too. Otherwise it seems simple enough. Thanks! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-2.19.26
Hi, Please find a new tarball for LilyPond at http://download.linuxaudio.org/lilypond/source/v2.19/lilypond-2.19.26.tar.gz Cheers, Jean-Charles Malahieude ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [testlilyissues:issues] #4579 NR Changing Defaults: Explain sticky contexts accurately
Hi James The issues and issue numbers you've added don't seem to correspond with those Simon posted on the bug list. For example: Simon's: ID: 4579 STATUS: New SUMMARY: Document tweaking of StaffSymbol and LedgerLineSpanner TYPE: Documentation Yours: ** [issues:#4579] NR Changing Defaults: Explain sticky contexts accurately** **Status:** Started **Created:** Sun Aug 30, 2015 02:54 PM UTC by pkx166h **Last Updated:** Sun Aug 30, 2015 02:54 PM UTC **Owner:** pkx166h So it looks like the DB and the bug list are out of sync already. That was why I asked Simon to add his first, as he'd already bagged the next four serial numbers. Ah well - just shows we'd better start using the new Allura DB properly ASAP so there is just one authoratative source. We'll have to ignore Simon's numbers, but don't forget to add them! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.19.26 regtests
At 14:41 on 30 Aug 2015, Phil Holmes wrote: 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 -- Mark Knoop ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.org - file storage
Phil Holmes wrote Sunday, August 30, 2015 1:15 PM I've actually downloaded the test-output for 2.15.30 - 39 in case anyone objects, and it looks like the upload is back running again. I'll leave it another day or so, but then plan to *delete* all the 2.15 files, except 15.95. We also have source files back to 0.0 and 1.0. I assume we could never recreate these from Git, but are we ever going to need to? It certainly seems pointless keeping lots of source tarballs, given that all the more recent history is in Git. Like Graham, I prefer not to delete history if it can be avoided, although it is clearly more important to make sure we can continue running smoothly. What you suggest sounds very sensible. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bug Squad invited to join Allura
@Bug Squad The new Issues DB at SourceForge is live and has been updated by James to reflect the current state of patches. There are a few new issues that are yet to be added, in particular the ones Simon raised on the bug list. These will now need to be given new serial numbers as James has bagged the ones Simon chose. So, to enable you to complete the updating and to continue your maintenance of the Issues DB I suggest you now go to https://sourceforge.net/p/testlilyissues/issues/ click on Join at top right and register as a member. Then send me the username you've chosen so I can add you as a developer. If you are spam-averse I suggest you use a disposable email address so you can make a clean break after we move to Savannah. The intention is to migrate the data from SF (not GC) to Savannah, so any work you do now will be preserved, DV. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4504: Let whiteout-box take a number argument (issue 264810043 by paulwmor...@gmail.com)
Pushed: authorPaul Morris paulwmor...@gmail.com Sun, 23 Aug 2015 02:32:42 + (22:32 -0400) committerJames Lowe pkx1...@gmail.com Sun, 30 Aug 2015 07:33:48 + (08:33 +0100) commita3fc862086a720201e4a4764c7beb952fab5f106 https://codereview.appspot.com/264810043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
