Re: AUTHORS material (re)started

On Fri, Dec 04, 2009 at 12:34:34AM +, Graham Percival wrote: > - the Jurgen Reuter under Font names is duplicated... oh wait, one > is an http. Hmm. I generally dislike http links with > _link text_, since the documentation is also available in pdf > and some people print it off. Could

Re: AUTHORS material (re)started

On Thu, Dec 03, 2009 at 07:05:10PM -0500, James Lowe wrote: > > I know this is easy, but it will let us test that everything is > > working. The next steps are only slightly harder. :) > > Can't wait. I hope I passed basic training ;) Thanks, added! A few requests for next time: - the page has

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

On 12/3/09 2:47 PM, "David Kastrup" wrote: > Graham Percival writes: > >> On Thu, Dec 03, 2009 at 09:57:39PM +0100, David Kastrup wrote: >>> Graham Percival writes: >>> Yes, Carl made a mistake. That's unfortunate, but he's human. >>> >>> So what do you think I am? >> >> I think yo

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

2009/12/3 David Kastrup : > I keep asking for the testing, with little success so far.  I still > don't know whether the changes from a week ago solve the memory > leak/corruption problem reported with a previous version. Thanks, the latest patchset works fine (see attached test results), and the

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

On 2009/12/03 17:34:24, c_sorensen_byu.edu wrote: > > I have not yet done anything in that respect since I have no idea yet > where to properly place the code turning on/off the documentation > collection. > How about scm/document-markup.scm? AFAICS scm/document-markup.scm is only loaded

Re: AUTHORS material (re)started

On Thu, Dec 03, 2009 at 03:06:46PM +, P Kayex wrote: > Mr Percival, I found this thread while searching around > for something that I could possibly help with to > contribute to the lily 'community'. > and saw that no one had replied to it, > so I assume this task is still open? Yes! Than

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Graham Percival writes: > On Thu, Dec 03, 2009 at 09:57:39PM +0100, David Kastrup wrote: >> Graham Percival writes: >> >> > Yes, Carl made a mistake. That's unfortunate, but he's human. >> >> So what do you think I am? > > I think you're a human. > >> > If anything, this incident should show

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Graham Percival writes: > On Thu, Dec 03, 2009 at 09:57:39PM +0100, David Kastrup wrote: > >> Are you suggesting that this incident should show that newcomers are >> to jump through even higher hoops while the regulars continue to work >> efficiently? > > No. It shows that regular committers *sh

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

On Thu, Dec 03, 2009 at 09:57:39PM +0100, David Kastrup wrote: > Graham Percival writes: > > > Yes, Carl made a mistake. That's unfortunate, but he's human. > > So what do you think I am? I think you're a human. > > If anything, this incident should show that jumping through hoops > > is even

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Carl Sorensen writes: > On 12/3/09 11:35 AM, "David Kastrup" wrote: >> >> But I certainly will not invest a lot of work, upload, branch creation, >> discussion whatever because you are not interested in making your fix >> cleaner after being told how. > > Fair enough. I apologize for replying

file sizes jumped from 2.13.1 to 2.13.2

I am probably to blame for this, but just a short heads up: lilypond-2.13.1-1.linux-64.sh 01-Jun-2009 16:28 15.7M lilypond-2.13.1-2.linux-64.sh 04-Jun-2009 18:53 22.4M lilypond-2.13.1-1.linux-x86.sh 01-Jun-2009 16:28 15.1M lilypond-2.13.1-2.linux-x86.sh 04-Jun-2009 18:47

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Graham Percival writes: > On Thu, Dec 03, 2009 at 07:35:49PM +0100, David Kastrup wrote: >> I have been told by Graham that the segfault from script-column.cc was >> what precluded reviews of my older patch set. > > To clarify, I was giving a good explanation of what other > programmers were work

Re: UTF-8 support needs implementing to fix all bidi/rtl/ltr issues

Here is the lilypond file: http://hymns.reactor-core.org/HaikVantoura/Shema4.ly It produces this output: http://hymns.reactor-core.org/HaikVantoura/Shema4.pdf But I should be able to use the unicode codes referenced previously to make the output look like this: http://hymns.reactor-core

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

On 12/3/09 11:35 AM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On 12/3/09 10:54 AM, "David Kastrup" wrote: >> >>> Carl Sorensen writes: >>> A (slightly different) fix has already been pushed. >>> >>> I might add, a fix that is much more complex, uses more variables, uses

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

On Thu, Dec 03, 2009 at 07:35:49PM +0100, David Kastrup wrote: > I have been told by Graham that the segfault from script-column.cc was > what precluded reviews of my older patch set. To clarify, I was giving a good explanation of what other programmers were working on. I think their priorities w

Re: UTF-8 support needs implementing to fix all bidi/rtl/ltr issues

On 2009-12-03, Ted Walther wrote: > I was really happy to see UTF-8 support in Lilypond. Is there any > possibility of getting the following codes supported? > > U+200E > U+200F > U+202A > U+202B > U+202C > U+202D > U+202E > > Proper support for them would clear up all rtl/ltr bidrectionality is

UTF-8 support needs implementing to fix all bidi/rtl/ltr issues

I was really happy to see UTF-8 support in Lilypond. Is there any possibility of getting the following codes supported? U+200E U+200F U+202A U+202B U+202C U+202D U+202E Proper support for them would clear up all rtl/ltr bidrectionality issues. Documentation on what those codes mean and how to

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Carl Sorensen writes: > On 12/3/09 10:54 AM, "David Kastrup" wrote: > >> Carl Sorensen writes: >> >>> A (slightly different) fix has already been pushed. >> >> I might add, a fix that is much more complex, uses more variables, uses >> more code, and checks conditions multiple times in differen

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

On 12/3/09 10:54 AM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On 12/3/09 9:12 AM, "David Kastrup" wrote: >> >>> Graham Percival writes: Are you aware that the world does not revolve around you? For the past few days, the git tree has been broken -- I cannot compile >

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Carl Sorensen writes: > On 12/3/09 9:12 AM, "David Kastrup" wrote: > >> Graham Percival writes: >>> Are you aware that the world does not revolve around you? For the >>> past few days, the git tree has been broken -- I cannot compile >>> the regression tests or documentation. Not just "the re

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

On 12/3/09 9:14 AM, "d...@gnu.org" wrote: > http://codereview.appspot.com/160048/diff/4008/6007#newcode131 > scm/markup.scm:131: ;; Register the new function, for markup > documentation > On 2009/12/03 14:58:38, nicolas.sceaux wrote: >> I still have the feeling that user defined commands shou

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

On 12/3/09 9:12 AM, "David Kastrup" wrote: > Graham Percival writes: > >> On Thu, Dec 03, 2009 at 10:00:13AM +0100, David Kastrup wrote: >>> the current version of the patch set >>> http://codereview.appspot.com/160048> has been sitting there on >>> Rietveld for about a week. >> >> Marek: I

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

Thanks for looking this over. This patch set is sort of a moving target due to the removal of markup-init.ly. For example, recently documentation about the module related definitions in markup-init.ly has been added to the programmer's documentation. If removing markup-init.ly can be done succe

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Graham Percival writes: > On Thu, Dec 03, 2009 at 10:00:13AM +0100, David Kastrup wrote: >> the current version of the patch set >> http://codereview.appspot.com/160048> has been sitting there on >> Rietveld for about a week. > > Marek: I guess it's time to add this as a PATCH item to the google

Re: AUTHORS material (re)started

Graham Percival percival-music.ca> writes: > > Long ago, ...we had Documentation/topdocs/AUTHORS.texi, > ... we added a THANKS...everybody stopped updating AUTHORS...I'm not > even certain if the THANKS is maintained. > > As part of the new website... > Documentation/general/basic-authors.i

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

Hi, When defining a user markup command, it would be better not to modify at all the variables from the (lily) module, even if you took care of the memory leak. Also, there is one file to be deleted, and the associated \include to be removed from an init .ly file. Nicolas http://codereview.app

Re: Issue 787 in lilypond: script stack order fails with 2 more notes

On 12/2/09 4:56 PM, "Trevor Daniels" wrote: > > > Carl Sorensen wrote Wednesday, December 02, 2009 10:29 PM >> >> In order to do the proper explanation, it seems to me we need to >> be clear on >> three things: >> >> 1) Stacking priority depends on outside-staff-priority if it's >> present

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

On Thu, Dec 03, 2009 at 10:00:13AM +0100, David Kastrup wrote: > the current version of the patch set > http://codereview.appspot.com/160048> has been sitting there on > Rietveld for about a week. Marek: I guess it's time to add this as a PATCH item to the google tracker. > For the current versio

Re: Chord repetition: \relative mode (issue164096)

On Thu, Dec 3, 2009 at 1:36 PM, Nicolas Sceaux wrote: > The link really is Oh, sorry for the noise. I thought you were jokingly refering to our issues numbering. I must be spending too much time on the bug tracker :) Cheers, Valentin _

Re: Chord repetition: \relative mode (issue164096)

Le 3 déc. 2009 à 13:26, Valentin Villenave a écrit : > On Thu, Dec 3, 2009 at 11:56 AM, wrote: >> Here is a patch to make chord repetition work in \relative mode. > > You forgot the link: http://code.google.com/p/lilypond/issues/detail?id=164096 The link really is

Re: Chord repetition: \relative mode (issue164096)

On Thu, Dec 3, 2009 at 11:56 AM, wrote: > Here is a patch to make chord repetition work in \relative mode. You forgot the link: http://code.google.com/p/lilypond/issues/detail?id=164096 :-) Cheers, Valentin ___ lilypond-devel mailing list lilypond-

Re: Cron 404 report

Op donderdag 03-12-2009 om 05:25 uur [tijdzone +0100], schreef Jan Nieuwenhuizen: > popularity page >[referrer]... > > 3275 /download/v2.4/lilypond-2.4.5.tar.gz Does anyone know what's going on here? > 240 /v2.12/input/lsr/lilypond-snippets/Rhythms/ > http://lilypond.org/v2.

Chord repetition: \relative mode (issue164096)

Reviewers: , Message: Hi, Here is a patch to make chord repetition work in \relative mode. As I'm not sure how exactly music translation works, might someone comment the RepeatedChord music type definition, and the relative callback? In particular, I don't know what the RepeatedChord types prope

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

As a reminder: the current version of the patch set http://codereview.appspot.com/160048> has been sitting there on Rietveld for about a week. I have not been able to corroborate the memory corruption problem reported on a previous patch. So the current patch set, which works well like the prev