Re: [PATCH] beam: remove unnecessary vector of forbidden intervals

Le 17/04/2022 à 06:22, Nihal Jere a écrit : The same vector is constructed twice, so just do it once. --- Not sure if this is the right place to send patches, but here it is. lily/beam.cc | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/lily/beam.cc b/lily/beam.cc i

Re: Patch scheduling

On Feb 6, 2022, at 22:23, Colin Campbell wrote: > > For my guidance, I'd be grateful if the community would correct or amplify > the following recap of the patch handling process. > Colin, I think you summed it up well and I agree with Lukas' additions. Thanks, — Dan

Re: Patch scheduling

On 2022-02-07 02:07, Lukas-Fabian Moser wrote: Hi Colin, forgive me for butting in as someone who has made very few contributions (but followed some of the discussions quite closely over the last few years): So what I'm trying to say is: A task that seems like a trivial cron job 95% of th

Re: Patch scheduling

Hi Colin, forgive me for butting in as someone who has made very few contributions (but followed some of the discussions quite closely over the last few years): All the above can be overridden by any developer with access, where judgement calls for expediting an MR, or it is clearly trivial.

Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend

Hi Jonas, > Done (hopefully). Thank you very much; it looks like it worked! Kevin

Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend

Am Dienstag, den 28.04.2020, 18:31 +0100 schrieb Kevin Barry: > Hi James, > > > We do have a process, see: > > http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#summary-for-experienced-developers > > > > I have followed this as best I can, but it seems I need to have write > acce

Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend

Hi James, > We do have a process, see: > http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#summary-for-experienced-developers I have followed this as best I can, but it seems I need to have write access to the issue tracker before I can send patches. If that is the case then can s

Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend

Hello Kevin, On 27/04/2020 18:07, Kevin Barry wrote: Hi James, Thank you for responding. On Mon, Apr 27, 2020 at 11:09:50AM +0100, James wrote: Is this patch read for full testing or is it work-in-progress you just want someone to comment on it? It's not work in progress no - unless someone

Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend

Hi James, Thank you for responding. On Mon, Apr 27, 2020 at 11:09:50AM +0100, James wrote: > Is this patch read for full testing or is it work-in-progress you just want > someone to comment on it? It's not work in progress no - unless someone has objections or observations, but I don't mean to c

Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend

Kevin, Is this patch read for full testing or is it work-in-progress you just want someone to comment on it? James On 25/04/2020 08:42, Kevin Barry wrote: Patch is attached to this mail as a file if that is more convenient. Kevin

Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend

Patch is attached to this mail as a file if that is more convenient. Kevin >From 1c5715ad52139aab936ee7dffb2cdef3d123b369 Mon Sep 17 00:00:00 2001 From: Kevin Barry Date: Fri, 24 Apr 2020 19:26:26 +0100 Subject: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend As th

Re: [PATCH] Issue 3778: Use bounding box as skylines for markup in svg backend

On Fri, Apr 24, 2020 at 09:25:19PM +0200, Han-Wen Nienhuys wrote: > Just add a test file under input/regression/ , following the style of > other files there. Thanks for the pointer. The only other svg backend file there looks like it has been deliberately disabled, so apologies if I have done thi

Re: [PATCH] Issue 3778: Use bounding box as skylines for markup in svg backend

On Fri, Apr 24, 2020 at 09:18:10PM +0200, Han-Wen Nienhuys wrote: > Can you add a regression test that shows the problem? Yes. I'll go read the docs to see how to do that and do one up (but feel free to point me in the right direction...) Kevin

Re: [PATCH] Issue 3778: Use bounding box as skylines for markup in svg backend

On Fri, Apr 24, 2020 at 9:21 PM Kevin Barry wrote: > > On Fri, Apr 24, 2020 at 09:18:10PM +0200, Han-Wen Nienhuys wrote: > > Can you add a regression test that shows the problem? > > Yes. I'll go read the docs to see how to do that and do one up (but feel > free to point me in the right direction

Re: [PATCH] Issue 3778: Use bounding box as skylines for markup in svg backend

Can you add a regression test that shows the problem? On Fri, Apr 24, 2020 at 8:50 PM Kevin Barry wrote: > > As there is no routine for determining skylines for utf-8-string > stencils, they normally fall back to the grob's bounding box, which is > fine. However, when there is a mixture of utf-8

Re: Patch on dynamics and \RemoveEmptyStaves

On 3/26/20, James Lowe wrote: > Yes David K is correct. If someone could take a look at the scripts in > git-cl and get them working smoothly again (there are other errors > reported on this list about git-cl) it would be a boon to the dev team. By the way (this is not directly related but may or

Re: Patch on dynamics and \RemoveEmptyStaves

On 26/03/2020 12:15, David Kastrup wrote: Jean Abou Samra writes: Hi, Le 24/03/2020 à 23:05, Trevor a écrit : Hi "Jean Abou Samra", you wrote My SourceForge username is jean-abou-samra. Could someone please give me write access to the issue tracker? Added as a Developer, with Update and

Re: Patch on dynamics and \RemoveEmptyStaves

Jean Abou Samra writes: > Hi, > > Le 24/03/2020 à 23:05, Trevor a écrit : > >> Hi "Jean Abou Samra", you wrote >>> My SourceForge username is jean-abou-samra. Could someone please >>> give me write access to the issue tracker? >> >> Added as a Developer, with Update and Create permissions in addi

Re: Patch on dynamics and \RemoveEmptyStaves

Hi, Le 24/03/2020 à 23:05, Trevor a écrit : Hi "Jean Abou Samra", you wrote My SourceForge username is jean-abou-samra. Could someone please give me write access to the issue tracker? Added as a Developer, with Update and Create permissions in addition to Read. Welcome aboard! Trevor T

Re: Patch on dynamics and \RemoveEmptyStaves

Hi Valentin, How strange it sounds to write you in English. Le 24/03/2020 à 19:24, Valentin Villenave a écrit :Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html Thanks for the pointer. My SourceForge username

Re: Patch on dynamics and \RemoveEmptyStaves

On 3/24/20, Jean Abou Samra wrote: > I have the attached very simple patch for LilyPond. Could anyone please > guide me through the process for patch submission? Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html

Re: Patch to Axis_group_engraver + Scheme engraver for staff combining

Hello list, On Wed, 6 Mar 2019 20:57:07 -0800, Saul Tobin wrote: > Hi all, > > I posted some earlier versions of this Scheme engraver to the user list. It > provides an intuitive user interface to control whether shared or separate > staves are printed, and should work for combinations of 4 or

Re: [PATCH] Some hooks useful for video production

Knut, On Tue, 25 Jul 2017 09:40:51 +0200 Knut Petersen wrote: > Hi everybody! > > The attached patch implements some hooks that would allow my video > generation script to work without the requirement to patch some of > lilyponds scm and ps files. > > Knut I did a cursory test of this patch a

Re: Patch to fix centering of some bass figures on whole notes and longer.

On Thu, 2017-07-13 at 15:07 +0200, David Kastrup wrote: > Richard Shann writes: > > > On Thu, 2017-07-13 at 12:47 +0100, James wrote: > >> > I am not top posting > >> > >> This 'patch' does not apply to current master so I could not test it > >> even if I wanted to > > > > Ah, yes, sorry, I look

Re: Patch to fix centering of some bass figures on whole notes and longer.

Richard Shann writes: > On Thu, 2017-07-13 at 12:47 +0100, James wrote: >> > I am not top posting >> >> This 'patch' does not apply to current master so I could not test it >> even if I wanted to > > Ah, yes, sorry, I looked into what parameters git uses for its diff but > didn't think about the

Re: Patch to fix centering of some bass figures on whole notes and longer.

On Thu, 2017-07-13 at 12:47 +0100, James wrote: > > I am not top posting > > This 'patch' does not apply to current master so I could not test it > even if I wanted to Ah, yes, sorry, I looked into what parameters git uses for its diff but didn't think about the directory you would want to run pa

Re: Patch to fix centering of some bass figures on whole notes and longer.

On Sun, 2017-07-09 at 18:46 +0200, David Kastrup wrote: > Richard Shann writes: > > > Simon Albrecht suggested I start a new thread for this (apologies for > > any confusion) > > > > Attached is a patch that fixes the centering of single bass figures over > > notes of duration whole note and more

Re: Patch to fix centering of some bass figures on whole notes and longer.

Richard Shann writes: > Simon Albrecht suggested I start a new thread for this (apologies for > any confusion) > > Attached is a patch that fixes the centering of single bass figures over > notes of duration whole note and more. The duration is tested and a > translate applied horizontally if nee

Re: [patch] Add a work to "we wrote" list

I would like to push this patch if nobody explicitly opposses. El 15/04/17 a las 13:03, Francisco Vila escribió: > Thanks James for waiting for me to get home. > > 2017-04-07 16:56 GMT+02:00 Han-Wen Nienhuys : >> This links to https://cloud.paconet.org/tesis/tesis.pdf, which is 404. >> I think yo

Re: [patch] Add a work to "we wrote" list

Thanks James for waiting for me to get home. 2017-04-07 16:56 GMT+02:00 Han-Wen Nienhuys : > This links to https://cloud.paconet.org/tesis/tesis.pdf, which is 404. > I think you mean https://paconet.org/tesis/tesis.pdf ? This is the deep link but I'd rather link to a wiki page containing some met

Re: [patch] Add a work to "we wrote" list

This links to https://cloud.paconet.org/tesis/tesis.pdf, which is 404. I think you mean https://paconet.org/tesis/tesis.pdf ? On Thu, Apr 6, 2017 at 10:24 AM, Francisco Vila wrote: > Hello, > > this adds my PhD thesis to the list in the web. Sorry for not > uploading the patch in a more formal wa

Re: [patch] Add a work to "we wrote" list

Hello, On Thu, 6 Apr 2017 10:24:42 +0200 Francisco Vila wrote: > Hello, > > this adds my PhD thesis to the list in the web. Sorry for not > uploading the patch in a more formal way; I can not recall if I've > done it anytime. I'm willing to, however. > > I'll be relatively unreachable for a we

Re: [PATCH] no-outline-stencil backend property

Knut Petersen writes: > Am 24.01.2017 um 14:49 schrieb David Kastrup: >> What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. P

Re: [PATCH] no-outline-stencil backend property

Knut Petersen writes: > Am 24.01.2017 um 14:49 schrieb David Kastrup: >> What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. P

Re: [PATCH] no-outline-stencil backend property

Knut Petersen writes: > Am 24.01.2017 um 14:49 schrieb David Kastrup: >> What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. P

Re: [PATCH] no-outline-stencil backend property

Am 24.01.2017 um 14:49 schrieb David Kastrup: What a steaming heap of something. So your code would likely have worked in LilyPond 2.16. I think it would make sense to create a new type of stencil expression explicitly intended to bypass outlining. Probably by just containing _two_ stencils: on

Re: [PATCH] no-outline-stencil backend property

Knut Petersen writes: > Hi David! > >> What a steaming heap of something. So your code would likely have >> worked in LilyPond 2.16. I think it would make sense to create a new >> type of stencil expression explicitly intended to bypass >> outlining. Probably by just containing _two_ stencils: on

Re: patch for git-cl

2017-01-09 0:09 GMT+01:00 Graham Percival : > On Sun, Jan 08, 2017 at 09:02:51PM +, Thomas Morley wrote: >> attached a little patch for git-cl to replace googlecodeissue by >> trackerissue in cl_settings.py, which will result in correct info in >> .git/config >> >> How do we handle patches to g

Re: patch for git-cl

On Sun, Jan 08, 2017 at 09:02:51PM +, Thomas Morley wrote: > attached a little patch for git-cl to replace googlecodeissue by > trackerissue in cl_settings.py, which will result in correct info in > .git/config > > How do we handle patches to git-cl? In general, I'd recommend a PR, but I've a

Re: patch for git-cl

On Sun, Jan 08, 2017 at 10:15:24PM +, James wrote: > On Sun, 8 Jan 2017 21:02:51 + > Thomas Morley wrote: > > > attached a little patch for git-cl to replace googlecodeissue by > > trackerissue in cl_settings.py, which will result in correct info in > > .git/config > > > > How do we hand

Re: patch for git-cl

On Sun, 8 Jan 2017 21:02:51 + Thomas Morley wrote: > Hi, > > attached a little patch for git-cl to replace googlecodeissue by > trackerissue in cl_settings.py, which will result in correct info in > .git/config > > How do we handle patches to git-cl? I imagine pull requests to https://gi

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

On 28/12/16 01:06, Alexander Kobel wrote: Essentially, my recent bug report should be enough for a regtest. Cheerio, Miss Sophie! (Sorry, can't help. Not sure if you share our nation's yearly half-an-hour of British humour with "Dinner for One" on the isles - it's Germany's traditional New

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

On 2016-12-27 21:25, Trevor Daniels wrote: Alexander Kobel wrote Monday, December 26, 2016 1:00 AM Oh well, it's late. I didn't spot measure 7, with the 8( 8) in alto. Same there. And, of course, you should have an extender there in the second verse, and you should have extenders in measure 1 (w

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Alexander Kobel wrote Monday, December 26, 2016 1:00 AM > Oh well, it's late. I didn't spot measure 7, with the 8( 8) in alto. > Same there. > And, of course, you should have an extender there in the second verse, > and you should have extenders in measure 1 (was/was/shall) an measure 9 > (sh

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

On 2016-12-26 01:01, Alexander Kobel wrote: On 2016-12-26 00:38, Trevor Daniels wrote: I attach a recent example - very Christmassy! Nice one, thanks. Note that, due to the fixed voice association to soprano in the SATB template, you should manually left-align the syllables where the bass has

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

On 2016-12-26 00:38, Trevor Daniels wrote: Alexander Kobel wrote Sunday, December 25, 2016 2:19 PM But: I cannot imagine a situation where I would not use automatic extenders, so I'm a really bad person to judge the need and requirements for a manual mode. One obvious and fairly common situat

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Alexander Kobel wrote Sunday, December 25, 2016 2:19 PM > But: I cannot imagine a situation where I would not use automatic > extenders, so I'm a really bad person to judge the need and requirements > for a manual mode. One obvious and fairly common situation is when there are several verses s

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Am 25.12.2016 um 13:14 schrieb Noeck: As extender events are generated automatically now it probably is a good idea to tell yacc / bison to recognize but ignore "__" tokens. I don't know at which level the __, \overrides and the automatic extenders interact. But would it make sense to use __ now

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Hi all. On 2016-12-25 13:14, Noeck wrote: As extender events are generated automatically now it probably is a good idea to tell yacc / bison to recognize but ignore "__" tokens. I don't know at which level the __, \overrides and the automatic extenders interact. But would it make sense to use

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

> As extender events are generated automatically now it probably is a > good idea to tell yacc / bison to recognize but ignore "__" tokens. I don't know at which level the __, \overrides and the automatic extenders interact. But would it make sense to use __ now, to force an extender e.g. on a si

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Hi Alexander et al.! As extender events are generated automatically now it probably is a good idea to tell yacc / bison to recognize but ignore "__" tokens. cu, Knut >From 768bf54ad8563b0cb6c2cbce692385656db3a535 Mon Sep 17 00:00:00 2001 From: Knut Petersen Date: Sat, 24 Dec 2016 21:09:40 +010

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Dear all, I just uploaded Knut's patch (with minor reformatting, to obey the 80-char-per-line limit) to Rietveld; see https://codereview.appspot.com/313240043 The corresponding issue can be found at https://sourceforge.net/p/testlilyissues/issues/5018/ I missed the warnings hidden by the

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

On 23.12.2016 22:36, Alexander Kobel wrote: The corresponding issue can be found at https://sourceforge.net/p/testlilyissues/issues/5018/ …which I took the liberty to merge with . Thanks for the work and happy holidays as well! Best, Sim

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

Dear all, I just uploaded Knut's patch (with minor reformatting, to obey the 80-char-per-line limit) to Rietveld; see https://codereview.appspot.com/313240043 The corresponding issue can be found at https://sourceforge.net/p/testlilyissues/issues/5018/ Thanks again Knut for this great cont

Re: [PATCH] Automatic lyric extenders

>> One nit: Please avoid overlong lines in the source code; it should >> be limited to 80 characters per line to improve legibility. > > Well, a number of lines are longer than 80 characters, but most are > shorter than their predecessors. If the 80 character limit should > be obeyed, it would b

Re: [PATCH] Automatic lyric extenders

On 2016-12-22 14:53, Knut Petersen wrote: Hi Alexander et al.! how about putting the patch on Rietveld? I agree that this should go into a normal patch review process now. Knut, are you familiar with the git cl proceedings? If not, it’s explained in the CG 1.3 and 2.3. +1. Let us know if you

Re: [PATCH] Automatic lyric extenders

Am 22.12.2016 um 15:00 schrieb Knut Petersen: > Hi Werner! > >> One nit: Please avoid overlong lines in the source code; it should be >> limited to 80 characters per line to improve legibility. >> > > Well, a number of lines are longer than 80 characters, but most are > shorter than > their prede

Re: [PATCH] Automatic lyric extenders

Hi Werner! One nit: Please avoid overlong lines in the source code; it should be limited to 80 characters per line to improve legibility. Well, a number of lines are longer than 80 characters, but most are shorter than their predecessors. If the 80 character limit should be obeyed, it would b

Re: [PATCH] Automatic lyric extenders

Hi Alexander et al.! how about putting the patch on Rietveld? I agree that this should go into a normal patch review process now. Knut, are you familiar with the git cl proceedings? If not, it’s explained in the CG 1.3 and 2.3. +1. Let us know if you need help. I went through the procedure ju

Re: [PATCH] Automatic lyric extenders

On 2016-12-22 13:03, Simon Albrecht wrote: On 22.12.2016 02:17, Thomas Morley wrote: 2016-12-22 1:33 GMT+01:00 Knut Petersen: Hi everybody! Attached find a new version of the patch. Please test. Read the updated manuals. Feel free to provide corrections and translations! cu, Knut Hi Knut

Re: [PATCH] Automatic lyric extenders

Knut Petersen wrote Thursday, December 22, 2016 12:33 AM > Attached find a new version of the patch. > Please test. Read the updated manuals. > > Feel free to provide corrections and translations! Looks promising. I have several comments to make, but it will be much easier to do that when the

Re: [PATCH] Automatic lyric extenders

On 22.12.2016 02:17, Thomas Morley wrote: 2016-12-22 1:33 GMT+01:00 Knut Petersen: Hi everybody! Attached find a new version of the patch. Please test. Read the updated manuals. Feel free to provide corrections and translations! cu, Knut Hi Knut, how about putting the patch on Rietveld?

Re: [PATCH] Automatic lyric extenders

> Attached find a new version of the patch. > Please test. Read the updated manuals. Without testing: LGTM. Thanks for working on this! > Feel free to provide corrections and translations! One nit: Please avoid overlong lines in the source code; it should be limited to 80 characters per line t

Re: [PATCH] Automatic lyric extenders

2016-12-22 1:33 GMT+01:00 Knut Petersen : > Hi everybody! > > Attached find a new version of the patch. > Please test. Read the updated manuals. > > Feel free to provide corrections and translations! > > cu, > Knut Hi Knut, how about putting the patch on Rietveld? Up to now I haven't found th

Re: [PATCH] remove www from lilypond.org URL

Suggest you start a review as normal, so that patchy can test that there's nothing broken. Providing that passes OK, push straight to staging. -- Phil Holmes - Original Message - From: "Federico Bruni" To: Sent: Tuesday, December 20, 2016 3:48 PM Subject: [PATCH] remove www from l

Re: [PATCH] musicxml2ly fix for lyrics when chord is present (fixes 61e)

Vincent, On 29/11/16 09:50, Vincent Le Ligeour wrote: > As commented in the patch I did not find any documentation if a chord > element can contain multiple lyrics, so I just assumed that the first note > of the chord contained the lyrics (consistant with Finale and Muscore > exports). Thanks, ad

Re: Patch

Steven, you wrote Friday, May 27, 2016 9:22 PM >>Thomas Morley wrote Friday, May 27, 2016 3:07 PM >> >>> 2016-05-27 6:11 GMT+02:00 Steven Weber : Since I don't have an official mentor and the recommendation is that you send your first couple of patches to your mentor first, I thoug

Re: Patch

Hi Steven Thomas Morley wrote Friday, May 27, 2016 3:07 PM > 2016-05-27 6:11 GMT+02:00 Steven Weber : >> >> Since I don't have an official mentor and the recommendation is that you >> send your first couple of patches to your mentor first, I thought I'd send >> it to the list and see if someone

Re: Patch

2016-05-27 6:11 GMT+02:00 Steven Weber : > Hey lily-dev! > > > > Since I don't have an official mentor and the recommendation is that you > send your first couple of patches to your mentor first, I thought I'd send > it to the list and see if someone can take a look. > > > > This patch adds the non

Re: Patch

Am 27.05.2016 um 06:11 schrieb Steven Weber: > Hey lily-dev! > > > > Since I don't have an official mentor and the recommendation is that you > send your first couple of patches to your mentor first, I thought I'd send > it to the list and see if someone can take a look. > I think this is a g

Re: [PATCH] Make Translator/Performer/Engraver abstract base classes

On 02/05/16 17:31, David Kastrup wrote: It does not make sense for them to be instantiable. https://sourceforge.net/p/testlilyissues/issues/4840/ Thanks James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/l

Re: [PATCH] Remove routing information from Grob_info

James writes: [git cl, Rietveld, Ubuntu 16.04] > Well I do get an issue but not quite the same as yours. [...] > Issue updated. URL: http://codereview.appspot.com/294410043 > We were not able to associate this patch with a tracker issue. > Please enter a valid tracker issue number > (or enter

Re: [PATCH] Remove routing information from Grob_info

David, On 28/04/16 13:07, David Kastrup wrote: James Lowe writes: P.S. do you still need someone to verify Ubuntu 16 Xenial Xylophones - or whatever it is called - is the root of the issue you are having with git-cl? I may have some spare cycles today. If someone else is using Xenial, I'd li

Re: [PATCH] Remove routing information from Grob_info

David On 28/04/16 13:07, David Kastrup wrote: James Lowe writes: P.S. do you still need someone to verify Ubuntu 16 Xenial Xylophones - or whatever it is called - is the root of the issue you are having with git-cl? I may have some spare cycles today. If someone else is using Xenial, I'd lik

Re: [PATCH] Remove routing information from Grob_info

James Lowe writes: > P.S. do you still need someone to verify Ubuntu 16 Xenial Xylophones - > or whatever it is called - is the root of the issue you are having > with git-cl? I may have some spare cycles today. If someone else is using Xenial, I'd like to hear how they are faring with git-cl.

Re: [PATCH] Remove routing information from Grob_info

Good morning David, On 25/04/16 16:24, David Kastrup wrote: It passes information to acknowledgers that does not really belong there and instead manages how information gets there. Moving this information into arguments for the various kinds of announce_grob procedure is cleaner and allows to

Re: [PATCH] Avoid some C++ comparisons of SCM values

David On 20/04/16 13:54, David Kastrup wrote: --- lily/axis-group-interface.cc | 2 +- lily/output-def-scheme.cc| 4 ++-- lily/scheme-engraver.cc | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lily/axis-group-interface.cc b/lily/axis-group-interface.cc index

Re: [PATCH] Avoid some C++ comparisons of SCM values

This is a minor patch sent to the developer list since my upload.py (part of git-cl) stopped working in the course of updating Ubuntu to version 16.04. It seems to be related with urllib2/urllib3 but so far I have found no information making it easy for me to get this back to working. upload.py

Re: [PATCH] musicxml2ly: Avoid duplicate "tr" if both and, are present

Thomas, On 13/12/15 21:48, Thomas Weber wrote: > Another patch for musicxml2ly: In situations like this: > > > > > this will be created: > > \trill \startTrillSpan > > It should only be \startTrillSpan. > > (My changes can also be found on Github: https://github.com/th-we/lilypond.)

Re: [PATCH] musicxml2ly: Make sure movement_title exists before using it

Hello, On 13/12/15 21:32, Thomas Weber wrote: > fixed problem and was generated by Sibelius' internal MusicXML export > functionality (not Dolet). Ticket created at: https://sourceforge.net/rest/p/testlilyissues/issues/4699/ Thanks James ___ lilypond

Re: [PATCH] musicxml2ly: Avoid duplicate "tr" if both and, are present

Am 15.12.2015 um 09:06 schrieb James: > Ticket created at: > https://sourceforge.net/rest/p/testlilyissues/issues/4698/ http://sourceforge.net/p/testlilyissues/issues/4698/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/ma

Re: [PATCH] musicxml2ly: Avoid duplicate "tr" if both and, are present

Hello, On 13/12/15 21:48, Thomas Weber wrote: > In situations like this: > > > > > this will be created: > > \trill \startTrillSpan > > It should only be \startTrillSpan Ticket created at: https://sourceforge.net/rest/p/testlilyissues/issues/4698/ Thanks James

Re: Patch status cleanup - apologies in advance

On 19/09/15 17:33, Trevor Daniels wrote: > > James Lowe wrote Saturday, September 19, 2015 4:26 PM > >> If nothing is lost and you can see the discussion when you edit the >> ticket I don't see the point of the work that this will take for issues >> that were and Fixed/Verified as that is all I t

Re: Patch status cleanup - apologies in advance

James Lowe wrote Saturday, September 19, 2015 4:26 PM > If nothing is lost and you can see the discussion when you edit the > ticket I don't see the point of the work that this will take for issues > that were and Fixed/Verified as that is all I touched. > > We haven't lost the issue title, so i

Re: Patch status cleanup - apologies in advance

Trevor On 19/09/15 15:04, Trevor Daniels wrote: > > James Lowe wrote Saturday, September 19, 2015 1:14 PM > >> I hope people don't mind, but I am doing a bit of housekeeping with some >> of the issues so that it makes it easier for me to search 'current' >> issues vs issues that have been closed

Re: Patch status cleanup - apologies in advance

On 19/09/15 15:04, Trevor Daniels wrote: > > James Lowe wrote Saturday, September 19, 2015 1:14 PM > >> I hope people don't mind, but I am doing a bit of housekeeping with some >> of the issues so that it makes it easier for me to search 'current' >> issues vs issues that have been closed for day

Re: Patch status cleanup - apologies in advance

On 19/09/15 15:04, Trevor Daniels wrote: > > James Lowe wrote Saturday, September 19, 2015 1:14 PM > >> I hope people don't mind, but I am doing a bit of housekeeping with some >> of the issues so that it makes it easier for me to search 'current' >> issues vs issues that have been closed for day

Re: Patch status cleanup - apologies in advance

James Lowe wrote Saturday, September 19, 2015 1:14 PM > I hope people don't mind, but I am doing a bit of housekeeping with some > of the issues so that it makes it easier for me to search 'current' > issues vs issues that have been closed for days/weeks/months/years. > > The bulk-edit facility

Re: PATCH: Change PDF 'author' field to use /Author (issue 260200043by pkx1...@gmail.com)

- Original Message - From: To: Cc: ; Sent: Sunday, August 16, 2015 12:41 AM Subject: Re: PATCH: Change PDF 'author' field to use /Author (issue 260200043by pkx1...@gmail.com) https://codereview.appspot.com/260200043/diff/1/scm/framework-ps.scm File scm/framework-ps.

Re: PATCH: Change PDF 'author' field to use /Author (issue 260200043 by pkx1...@gmail.com)

https://codereview.appspot.com/260200043/diff/1/scm/framework-ps.scm File scm/framework-ps.scm (right): https://codereview.appspot.com/260200043/diff/1/scm/framework-ps.scm#newcode462 scm/framework-ps.scm:462: (metadata-lookup-output 'pdfauthor 'composer "Author") If I understand the reason for

Re: [PATCH 1/5] Remove parser/location global variable setup

Am 31.05.2015 um 07:47 schrieb David Kastrup: [...] Well, that was actually more what I considered strange: the lack of comment on the result/merits rather than on the particular implementation. I can just speak for myself, but the actual benefit of this patch was not obviously clear for me, b

Re: [PATCH 1/5] Remove parser/location global variable setup

"Trevor Daniels" writes: > David Kastrup wrote Saturday, May 30, 2015 7:51 PM > >> Oh, and regarding the %parser and %location names: GUILE itself uses >> names like that for several fluids. >> >> At any rate: huh. I propose getting rid of a 10-year old syntactic >> artifact and the only resp

Re: [PATCH 1/5] Remove parser/location global variable setup

David Kastrup wrote Saturday, May 30, 2015 7:51 PM > Oh, and regarding the %parser and %location names: GUILE itself uses > names like that for several fluids. > > At any rate: huh. I propose getting rid of a 10-year old syntactic > artifact and the only response are naming convention enquirie

Re: [PATCH 1/5] Remove parser/location global variable setup

Carl Sorensen writes: > On 5/30/15 12:51 PM, "David Kastrup" wrote: > >>David Kastrup writes: >> >>At any rate: huh. I propose getting rid of a 10-year old syntactic >>artifact and the only response are naming convention enquiries. I mean: >>good to know that there are still developers alive.

Re: [PATCH 1/5] Remove parser/location global variable setup

On 5/30/15 12:51 PM, "David Kastrup" wrote: >David Kastrup writes: > >At any rate: huh. I propose getting rid of a 10-year old syntactic >artifact and the only response are naming convention enquiries. I mean: >good to know that there are still developers alive. > >I still think it may have th

Re: [PATCH 1/5] Remove parser/location global variable setup

David Kastrup writes: > Dan Eble writes: > >> On May 27, 2015, at 05:45 , David Kastrup wrote: >>> >>> +(define %parser (make-fluid)) >>> +(define %location (make-fluid)) >> >>> +(define-public (*parser*) (fluid-ref %parser)) >>> +(define-public (*location*) (fluid-ref %location)) >> >> Are th

Re: [PATCH 1/5] Remove parser/location global variable setup

Dan Eble writes: > On May 27, 2015, at 05:45 , David Kastrup wrote: >> >> +(define %parser (make-fluid)) >> +(define %location (make-fluid)) > >> +(define-public (*parser*) (fluid-ref %parser)) >> +(define-public (*location*) (fluid-ref %location)) > > Are the decorations on these names ad-hoc

Re: [PATCH 1/5] Remove parser/location global variable setup

On May 27, 2015, at 05:45 , David Kastrup wrote: > > +(define %parser (make-fluid)) > +(define %location (make-fluid)) > +(define-public (*parser*) (fluid-ref %parser)) > +(define-public (*location*) (fluid-ref %location)) Are the decorations on these names ad-hoc or are you following a convent

Re: [PATCH 1/5] Remove parser/location global variable setup

This patch series is obviously related to issue 4421 as it makes the latter issue quite more elegant to use, and there is no feasible way to autoconvert issue 4421 to calling Scheme functions without parser/location arguments. So this issue should come first. Unfortunately, git cl/Rietveld curren

Re: Patch for issue 3882: stencils with stroke-thickness set to zero (issue 201520044 by luk.piet...@gmail.com)

author Lukas Pietsch Sun, 8 Mar 2015 10:34:32 + (10:34 +) committer James Lowe Sun, 8 Mar 2015 10:39:06 + (10:39 +) commit b7fdbfc2ceb805cfca5b386b43e1dec831702b17 (I downloaded the diff file from Rietveld and applied that way). This issue can be c

  1   2   3   4   5   6   7   8   9   10   >