tdanielsmusic | 25 May 23:22 2015

Docs: clean up after \relative conversion (issue 239250043 by k-ohara5a5a <at>

Apart from a really trivial nitpick, LGTM
(but I haven't checked if anything has been missed)

File Documentation/notation/pitches.itely (right):
Documentation/notation/pitches.itely:303:  <at> code{ <at> w{\relative}} is
interpreted just the same as
Don't need  <at> w now
MacUpdate | 25 May 17:56 2015

MacUpdate - your app listing has been updated

                               top background

                            App Listing Updated

   Hi, We have updated your application listing for LilyPond
   2.19.21-1 on [2] Please take a moment to review your
   application's information to make sure that everything is correct.

   [3]View your updated app listing view your updated app
    You can [4]login to your Developer Account to reply to comments and
   view stats, or [5]submit new updates and changes to your app listing.

                 [6]MacUpdate Desktop install compatibility

   Desktop Install Compatibility

   MacUpdate Desktop 6 is helping developers make it easier for users to
   fully install and use their apps. Download Desktop 6 and to ensure your
   app works with the "Install" link on our download pages.

   Advertise With MacUpdate

      The best Mac devs advertise their apps on because it's
      the most targeted, highly performing Mac app advertising you can find
      on the web. Contact ads <at> to guarantee your annual ad
      campaigns get booked and expand your app's audience.

   Learn more view your updated app
(Continue reading)

Phil Holmes | 25 May 16:27 2015

PDF is broken for <at> notation{} encoding

Look at page 22 of the most recent PDF of Learning, and you'll see that 
whenever we use  <at> notation{text}, then there is a paragraph break before 
the "text".  It took a while to figure out the guilty commit, but it is
9f3c7711bb73baf3aea8502227fb5fd2d2851753: "update texinfo.tex from 

Anyone know what's happening here?
pkx166h | 25 May 13:52 2015

Doc: Fix configure option (issue 236450043 by trueroad <at>

Patch on countdown for May 28th
paulwmorris | 24 May 19:30 2015

add stencil-whiteout-outline function (issue 236480043 by paulwmorris <at>

Reviewers: ,

Please review, thanks.

See discussion here for background and usage demo:

I have not yet done a regtest, but will add one if this is reviewed
favorably for inclusion in LilyPond.

add stencil-whiteout-outline function

clean up code formatting in stencil-whiteout

Please review this at

Affected files (+55, -5 lines):
   M scm/stencil.scm

Index: scm/stencil.scm
diff --git a/scm/stencil.scm b/scm/stencil.scm
--- a/scm/stencil.scm
+++ b/scm/stencil.scm
 <at>  <at>  -688,15 +688,65  <at>  <at>  box, remains the same."
  (define-public (stencil-whiteout stencil)
(Continue reading)

trueroad | 24 May 17:08 2015

Fix png filename handling (issue 241760043 by trueroad <at>

Reviewers: ,

I've found that LilyPond fail to compile the source file whose name
contains `%' to png files.
For example, the following command fails.

$ lilypond --png

This patch solve it.

Fix png filename handling

     This patch can compile the source file
     whose name contains `%' and convert to png files.
     (e.g. `' to `%foobar.png')

Use ly:system in make-ps-images (ps-to-png.scm)

     In make-ps-images,
     use ly:system instead of my-system for invoking gs.
     It is the same way as postscript->pdf

Delete duplicate procedures in ps-to-png.scm

     PLATFORM: lily.scm
     search-executable: backend-library.scm
     search-gs: backend-library.scm
(Continue reading)

PhilEHolmes | 24 May 15:56 2015

Remove CR LF from snippets using makelsr (issue 238520043 by PhilEHolmes <at>

Reviewers: ,

Please review.

Some of the snippets imported from the LSR (notably some of the
headwords) have CR LF at the end of their lines.  This appears to be
viewed as excess whitespace and stripped when the git repo is updated.
As a result, any import of the LSR flags these snippets as changed.
This simple fix replaces CR LF with LF during the import with makelsr.
This fixes the excess whitespace problem.

Please review this at

Affected files (+1, -0 lines):
   M scripts/auxiliar/

Index: scripts/auxiliar/
diff --git a/scripts/auxiliar/ b/scripts/auxiliar/
--- a/scripts/auxiliar/
+++ b/scripts/auxiliar/
 <at>  <at>  -251,6 +251,7  <at>  <at>  def copy_ly (srcdir, name, tags):
      s = strip_white_spaces_re.sub ('', s)
      s = final_empty_lines_re.sub ('\n', s)
      s = escape_backslashes_in_header (s)
+    s = s.replace ("\r\n", "\n")
(Continue reading)

Phil Holmes | 22 May 16:46 2015

Master fails to compile

phil <at> Ubuntu:~/lilypond-git$ rm -rf build
phil <at> Ubuntu:~/lilypond-git$ sh --noconfigure &> dev\null
phil <at> Ubuntu:~/lilypond-git$ mkdir -p build
phil <at> Ubuntu:~/lilypond-git$ cd build
phil <at> Ubuntu:~/lilypond-git/build$ ../configure &> dev\null
phil <at> Ubuntu:~/lilypond-git/build$ make -s -j9 &> ~/MakeFail220515.txt

On a clean build directory as above, current master fails to compile as follows:

/lilypond-git/lily/include/listener.hh: In static member function 
'static void Listener::smob_proc_init(scm_t_bits)':
/lilypond-git/lily/include/listener.hh:104: error: insufficient 
contextual information to determine type
/lilypond-git/lily/include/listener.hh: In static member function 
'static void Callback_wrapper::smob_proc_init(scm_t_bits)':
/lilypond-git/lily/include/listener.hh:182: error: insufficient
 contextual information to determine type

I can supply the full output of make if required, this is just an extract.

With the same commands on HEAD~2, the compile completes successfully.
David Kastrup | 21 May 10:01 2015


In the CG I read

    For certain grobs, the  <at> code{Y-extent} is based on the  <at> code{stencil}
    property, overriding the stencil property of one of these will
    require an additional  <at> code{Y-extent} override with an unpure-pure
    container.  When a function overrides a  <at> code{Y-offset} and/or
     <at> code{Y-extent} it is assumed that this will trigger line breaking
    calculations too early during compilation.  So the function is not
    evaluated at all (usually returning a value of  <at> samp{0} or
     <at> samp{'(0 . 0)}) which can result in collisions.  A  <at> q{pure} function
    will not affect properties, objects or grob suicides and therefore will
    always have its Y-axis-related evaluated correctly.

    Currently, there are about thirty functions that are already considered
     <at> q{pure} and Unpure-pure containers are a way to set functions not on
    this list as  <at> q{pure}.  The  <at> q{pure} function is evaluated  <at> emph{before}
    any line-breaking and so the horizontal spacing can be adjusted
     <at> q{in time}.  The  <at> q{unpure} function is then evaluated  <at> emph{after}
    line breaking.

This is all very nice.  Except that it is the function calls labelled as
*pure* that actually receive start/end values indicating particular
breakpoints of the system that the respective grob is in.  What's the
deal with that?


David Kastrup
nine.fierce.ballads | 21 May 04:43 2015

Re: Part_combine_iterator: treat child iterators as a set (issue 240020043 by nine.fierce.ballads <at>
Trevor Daniels | 21 May 00:19 2015

Re: Assessment of Allura at SourceForge

Trevor Daniels wrote Sunday, May 17, 2015 9:33 AM
Subject: Assessment of Allura at SourceForge

> Hi
> I've now completed my assessment of Allura at SourceForge against the list of requirements supplied by Phil.
> There are some differences from GoogleCode, but these are relatively minor and can be accommodated by
small changes in our procedures.  In particular the Blocking and Duplicate facilities will be different,
and the various posts in the discussion are fully threaded and so are not numbered, meaning
cross-referencing is by link rather than number.  The emails sent out following additions and amendments
are not formatted as nicely as those from GoogleCode, but contain all the information.  Support is by +ve
and -ve voting rather than starring.  Finally, the Owner field in the transferred tickets is not
populated.  The owner is identified in the text of the ticket,  so the field can be manually amended after the
event in the few tickets where this matters.
> Other than that the facilities are remarkably similar, and apart from congestion the transfer of the DB is
fairly trouble-free.

I'm becoming increasingly concerned about the loading of Allura at SourceForge, maybe due to other
projects attempting to migrate from GoogleCode.  After exporting our Issues DB on Sat evening and
modifying the Post authors to "GoogleImporter" I attempted to re-import it.  During Saturday evening,
all day on Sunday, and early on Monday my attempt was rejected due to the load on the server.  The import
request was finally accepted on Monday afternoon, but failed after loading about a quarter of the issues. 
No details given.  I initiated the import again late on Monday evening, and this had completed
successfully by early Wed morning, after running for 33 hours.  So weekends are a dead loss, and altogether
it took me almost 5 days just to re-import the DB.

Furthermore, I've observed today that searches are frequently rejected with "Errno 111 Connection
(Continue reading)