Re: PATCH: Countdown to 20120705

Colin Campbell writes: > Enhancement: >     Issue 2632: Allow multiple occurences of Footnote_engraver - R > 6353056 >     Issue 2636: Patch: Reject \footnote ... \default without grob > specification - R 6353056 and possibly     > 6354064 Uh yes, you got it as right as it gets. Having the two

PATCH: Countdown to 20120705

For 20:00 MDT Thursday July 5 Build: Issue 2635 : Configure search for NCSB fonts does not work in Debian Squeeze - R 6353058 Documentation: Issue 2579

Re: Gets vertical skylines from grob stencils (issue 5626052)

On Tue, 03 Jul 2012 10:51:05 -0700, m...@apollinemike.com wrote: Could you tell me the page and the document where the system overlay happens? Second page of the bassoon part. http://k-ohara.oco.net/Lilypond/TightSkylines/woods-Bassoon1.pdf The source is one directory up, but it's a big so

Re: building master / fixed all Critical?

On Mon, Jul 02, 2012 at 01:21:31PM +0200, John Mandereau wrote: > Il giorno dom, 01/07/2012 alle 23.29 +0100, Graham Percival ha scritto: > > Could we get a clear note about which commit(s) were reverted and > > are presumably in limbo? > > The only patch that has been reverted so far is > 512d405

Re: git-cl under Windows

Graham Percival wrote Tuesday, July 03, 2012 2:36 PM > On Tue, Jul 03, 2012 at 11:40:58AM +0100, Trevor Daniels wrote: >> The version from github.com/gperciva/git-cl.git ships without >> the readline module. It is not required for Unixes as it is >> included with Unix python, I believe. > > Hmm.

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

On Tue, Jul 3, 2012 at 10:19 PM, David Kastrup wrote: > It is almost certainly a problem with your system clock. If you have > touched source files with a future clock, and now the clock is right, > then compiled files will be outdated ("older" than the source file) > immediately after compilatio

Re: git-cl under Windows

David Kastrup wrote Tuesday, July 03, 2012 10:46 PM > Graham Percival writes: > >> On Tue, Jul 03, 2012 at 10:26:18PM +0200, David Kastrup wrote: >>> "Trevor Daniels" writes: >>> >>> >> Description empty; aborting. >>> >>> That just means that git-cl called what it considered an editor, and

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

Werner LEMBERG writes: >> It is almost certainly a problem with your system clock. If you have >> touched source files with a future clock, and now the clock is right, >> then compiled files will be outdated ("older" than the source file) >> immediately after compilation again. > > There is a sp

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

> It is almost certainly a problem with your system clock. If you have > touched source files with a future clock, and now the clock is right, > then compiled files will be outdated ("older" than the source file) > immediately after compilation again. There is a special built-in target in GNU ma

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

Janek Warchoł writes: > On Tue, Jul 3, 2012 at 8:55 PM, Janek Warchoł > wrote: >> Now comes the most surprising part: just to make sure, i just did >> the following: >> checkout origin/master # local master contained a revert of that commit >> make from scratch >> add a trivial change >> make

Re: git-cl under Windows

Graham Percival writes: > On Tue, Jul 03, 2012 at 10:26:18PM +0200, David Kastrup wrote: >> "Trevor Daniels" writes: >> >> >> Description empty; aborting. >> >> That just means that git-cl called what it considered an editor, and the >> file for editing did not change, so git-cl aborted. > > A

Re: git-cl under Windows

On Tue, Jul 03, 2012 at 10:26:18PM +0200, David Kastrup wrote: > "Trevor Daniels" writes: > > >> Description empty; aborting. > > That just means that git-cl called what it considered an editor, and the > file for editing did not change, so git-cl aborted. Another option would be to change git-

Re: git-cl under Windows

"Trevor Daniels" writes: >> $ git cl upload master >> WARNING: terminal is not fully functional >> Documentation/notation/input.itely | 56 + >> 1 files changed, 56 insertions(+), 0 deletions(-) >> 'vi' is not recognized as an internal or external command, >> operable program or

Re: git-cl under Windows

David Kastrup wrote Tuesday, July 03, 2012 4:34 PM > Namely, git-cl first tries importing readline unconditionally, then it > tries importing it again conditionally. > > That does not look all too clever. Perhaps removing the unconditional > import is all that is needed? Yes, this seems to byp

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

On Tue, Jul 3, 2012 at 8:55 PM, Janek Warchoł wrote: > Now comes the most surprising part: just to make sure, i just did the > following: > checkout origin/master # local master contained a revert of that commit > make from scratch > add a trivial change > make bin ...succeeds! Are you a magic

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

On Tue, Jul 3, 2012 at 7:35 PM, David Kastrup wrote: > So obviously something else is wrong here. Try removing > lily/out/smobs.dep and lily/out/smobs.o and see whether this helps. > > To be expected is a large amount of recompilation _once_ since a lot of > files need smobs.hh. If it occurs rep

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

On 3 juil. 2012, at 19:46, Jean-Charles Malahieude wrote: > Le 03/07/2012 19:23, Janek Warchoł disait : >> Hi, >> >> until recently, 'make bin' was a very smart tool: it recompiled only >> necessary .cc files, not everything. That was lifesaving: instead of >> having to wait for 5 minutes, i got

Re: Gets vertical skylines from grob stencils (issue 5626052)

On 2 juil. 2012, at 01:03, k-ohara5...@oco.net wrote: > I like the direction in which this goes, making things closer, because > it is easier for users to add padding when needed than to persuade > LilyPond to space things more closely. > > I did a quick test on some music.

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

Le 03/07/2012 19:23, Janek Warchoł disait : Hi, until recently, 'make bin' was a very smart tool: it recompiled only necessary .cc files, not everything. That was lifesaving: instead of having to wait for 5 minutes, i got the results of my changes in 5 seconds. Unfortunately, this is no longer

Re: make bin got dumb because of "Fix description in lily/include/smobs.hh"

Janek Warchoł writes: > until recently, 'make bin' was a very smart tool: it recompiled only > necessary .cc files, not everything. That was lifesaving: instead of > having to wait for 5 minutes, i got the results of my changes in 5 > seconds. Unfortunately, this is no longer the case: no matte

make bin got dumb because of "Fix description in lily/include/smobs.hh"

Hi, until recently, 'make bin' was a very smart tool: it recompiled only necessary .cc files, not everything. That was lifesaving: instead of having to wait for 5 minutes, i got the results of my changes in 5 seconds. Unfortunately, this is no longer the case: no matter how trivial the change, m

[PATCH] Don't load readline unconditionally

David Kastrup writes: > Namely, git-cl first tries importing readline unconditionally, then it > tries importing it again conditionally. > > That does not look all too clever. Perhaps removing the unconditional > import is all that is needed? >From d5d718a5335935b9268aefc49eb3b0cc77fe62ec Mon S

Re: git-cl under Windows

David Kastrup writes: > Graham Percival writes: > >> On Tue, Jul 03, 2012 at 04:50:13PM +0200, David Kastrup wrote: >>> Graham Percival writes: >>> >>> > Good luck. >>> >>> My personal take on this is not to bother but disable use of the >>> readline module if unavailable. git cl does not as

Re: git-cl under Windows

Graham Percival writes: > On Tue, Jul 03, 2012 at 04:50:13PM +0200, David Kastrup wrote: >> Graham Percival writes: >> >> > Good luck. >> >> My personal take on this is not to bother but disable use of the >> readline module if unavailable. git cl does not ask for interactive >> input often e

Re: git-cl under Windows

On Tue, Jul 03, 2012 at 04:50:13PM +0200, David Kastrup wrote: > Graham Percival writes: > > > Good luck. > > My personal take on this is not to bother but disable use of the > readline module if unavailable. git cl does not ask for interactive > input often enough to make that worth the troubl

Re: git-cl under Windows

Graham Percival writes: > On Tue, Jul 03, 2012 at 11:40:58AM +0100, Trevor Daniels wrote: >> The version from github.com/gperciva/git-cl.git ships without >> the readline module. It is not required for Unixes as it is >> included with Unix python, I believe. > > Hmm. If it's as simple as includ

Re: git-cl under Windows

On Tue, Jul 03, 2012 at 11:40:58AM +0100, Trevor Daniels wrote: > The version from github.com/gperciva/git-cl.git ships without > the readline module. It is not required for Unixes as it is > included with Unix python, I believe. Hmm. If it's as simple as including a bunch of extra .py files, th

git-cl under Windows

Has anyone managed to run git-cl under Windows successfully? The version from github.com/gperciva/git-cl.git ships without the readline module. It is not required for Unixes as it is included with Unix python, I believe. But it is not included with the Windows version of python. There is a W

Re: Gets vertical skylines from grob stencils (issue 5626052)

Hi all, my favorite patch returned! Yay! I did some testing and the results are here: http://lilypond-stuff.1065243.n5.nabble.com/file/n5705594/patchset37-results.tar.gz (sorry, too big for an attachment - 200 kB) In short: - staffswitch lines are broken - barnumbers collide with ties - some ties

Re: formatted GNUmakefile

Werner LEMBERG writes: > I'll take care of formatting > However, there is a lot of activity recently on the Makefiles, so it > might be better if I do the whole thing later so that patches and > changes stay valid, probably after release 2.16... Great, thanks. Jan -- Jan Nieuwenhuizen | GNU L