>> My question remains: should we sort alphabetically the list under
>> "Programs that can export LilyPond code" in the following webpage? It
>> looks like a mess.
>
> Yes, they should be sorted alphabetically.
It is now done. New patch uploaded: http://codereview.appspot.com/6448169/
Also fixed m
Reviewers: marc, Keith, dak,
Message:
all changes in a single commit; I'm happy to resubmit it in four; I can
also push (after review and coutdown) in one or four or as you wish.
Description:
issue 2533 continued: fix problematic uses of line-count in bar-line
- modify regtests to show when to
I have now four commits: regtest changes plus one change
in three (sort of unrelated) functions each in bar-line.scm
(colon, extent and line-span computation).
what review process do you prefer/suggest?
one review per commit or review in one, push in four?
uploaded in a single commit for review:
On Mon, Aug 20, 2012 at 09:58:19PM +0200, Frédéric Bron wrote:
> My question remains: should we sort alphabetically the list under
> "Programs that can export LilyPond code" in the following webpage? It
> looks like a mess.
Yes, they should be sorted alphabetically. I'll note that it's
almost don
>> Please review this at http://codereview.appspot.com/6448169/
>> Affected files:
>> M Documentation/fr/web/introduction.itexi
>> M Documentation/web/introduction.itexi
>
> While you are at it, you could add https://github.com/hanwen/go-enc2ly here
> too.
Done, added link to go-enc2ly.
Pleas
LGTM
http://codereview.appspot.com/6454121/diff/7/input/regression/relative-repeat.ly
File input/regression/relative-repeat.ly (right):
http://codereview.appspot.com/6454121/diff/7/input/regression/relative-repeat.ly#newcode4
input/regression/relative-repeat.ly:4: system has alll the notes with
LGTM
http://codereview.appspot.com/6453137/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/6448170/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I've never got so far than this time, as I've managed to complete
make bootstrap
make -f lilypond.make bootstrap
at the price of ugly kludgy operations, so I thought a report would be
of some interest for GUB hackers.
After this, any attempt to build LilyPond with GUB failed at configure,
with a
Il giorno lun, 20/08/2012 alle 16.59 +0100, James ha scritto:
> Would it be 'easier' to copy test-patches (so to speak) and rename it
> to make-doc-patches and then we have a third command - test-* accept-*
> make-doc-* - and I could run
>
> make-doc-patches 2345
This could be easier for you call
John,
On 20 August 2012 16:32, John Mandereau wrote:
> Il giorno lun, 20/08/2012 alle 15.53 +0100, James ha scritto:
>> What might be more convenient - depending on the approach - is to be
>> able to arbitrarily run ./test-patchy.py at a tracker issue regardless
>> of patch status and build the d
Il giorno lun, 20/08/2012 alle 15.53 +0100, James ha scritto:
> What might be more convenient - depending on the approach - is to be
> able to arbitrarily run ./test-patchy.py at a tracker issue regardless
> of patch status and build the doc based on it.
This was added in
commit cbd969135e8ec8c08f
John,
On 20 August 2012 14:28, John Mandereau wrote:
> Il giorno lun, 20/08/2012 alle 13.53 +0100, James ha scritto:
>> On 20 August 2012 13:09, John Mandereau wrote:
>> > If you mean the BUILD_ALL_DOCS switch in the core code of the builder
>> > (patches/compile_lilypond_test/__init__.py),
>>
>
On 20 août 2012, at 05:13, m...@mikesolomon.org wrote:
>
> On 19 août 2012, at 21:20, m...@mikesolomon.org wrote:
>
>>
>> On 19 août 2012, at 20:58, John Mandereau wrote:
>>
>>> Il giorno dom, 19/08/2012 alle 20.28 -0400, m...@mikesolomon.org ha
>>> scritto:
Nothing to do with iosnoop,
Il giorno lun, 20/08/2012 alle 13.53 +0100, James ha scritto:
> On 20 August 2012 13:09, John Mandereau wrote:
> > If you mean the BUILD_ALL_DOCS switch in the core code of the builder
> > (patches/compile_lilypond_test/__init__.py),
>
> Yes I was.
The ability to run "make doc" for testing patch
http://lilypond.org/~graham/gop/gop_5.html
** Proposal summary
C++ will remain as-is, using astyle 2.02 (not astyle2.02.1) with
scripts/auxiliar/fixcc.py
Scheme will be indented with emacs --batch mode.
There should be no tabs in any C++ or scheme files.
** Motivation
It would be nice if we
James wrote Monday, August 20, 2012 10:40 AM
> If someone can verify it 'WORKSFORME' then I'll take another look.
>
> It would mean I could make doc on every patch that needs testing, to
> give people like Trevor more confidence when their patches are tested.
It would be very helpful (at least
John,
On 20 August 2012 13:09, John Mandereau wrote:
> Hi James,
> Il giorno lun, 20/08/2012 alle 10.40 +0100, James ha scritto:
>> I am not able to work out how to force patchy during a test-patches.py
>> to also make doc as well as the test and test-baseline.
>>
>> I don't have access to my mac
Hi James,
Il giorno lun, 20/08/2012 alle 10.40 +0100, James ha scritto:
> I am not able to work out how to force patchy during a test-patches.py
> to also make doc as well as the test and test-baseline.
>
> I don't have access to my machine I run patchy on at the moment - it
> is at home and I am
Il giorno lun, 20/08/2012 alle 12.49 +0200, David Kastrup ha scritto:
> Sigh. I have _never_ been proposing indent-tabs-mode in scheme-mode,
> and most certainly my patch proposal was _quite_ the opposite, with the
> _opposite_ effect.
>
> Please don't further spread that myth.
>
> It is not my
John Mandereau writes:
> Il giorno lun, 20/08/2012 alle 10.11 +, d...@gnu.org ha scritto:
>> http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh
>> File scripts/auxiliar/fixscm.sh (right):
>>
>> http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh#newco
Il giorno lun, 20/08/2012 alle 10.11 +, d...@gnu.org ha scritto:
> http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh
> File scripts/auxiliar/fixscm.sh (right):
>
> http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh#newcode15
> scripts/auxiliar/fixscm.
http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh
File scripts/auxiliar/fixscm.sh (right):
http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh#newcode15
scripts/auxiliar/fixscm.sh:15: emacs -batch "$@" --eval
"${elisp_expression}"
Can you verify that ema
Il giorno lun, 20/08/2012 alle 08.28 +0200, David Kastrup ha scritto:
> The possibly contentious case is when the user has put up an independent
> .dir-local.el file. Git will complain before overwriting that without
> confirmation, so you'll get warning (not for git reset --hard or similar
> thou
Reviewers: ,
Message:
Note: these two new files (.dir-locals.el from David Kastrup and
fixscm.sh from me) actually operate independently, see
http://lists.gnu.org/archive/html/lilypond-devel/2012-08/msg00450.html
and so they may be applied independently one from the other; if both are
applied, t
On 2012/08/20 09:32:18, Trevor Daniels wrote:
On 2012/08/20 08:13:32, dak wrote:
> or it is plain English, in which case it should be written
> system start, namely without a dash in the middle.
It /is/ plain English; system-start is a compound
adjective of clef.
Shouldn't it then be syst
John (and possibly Graham/David/Phil),
I am not able to work out how to force patchy during a test-patches.py
to also make doc as well as the test and test-baseline.
I don't have access to my machine I run patchy on at the moment - it
is at home and I am at work - but there is an entry in one of
On 2012/08/20 08:13:32, dak wrote:
or it is plain English, in which case it should be written
system start, namely without a dash in the middle.
It /is/ plain English; system-start is a compound
adjective of clef. Whether it is hyphenated or not is
a matter of personal preference. Rather tha
On 19 août 2012, at 21:20, m...@mikesolomon.org wrote:
>
> On 19 août 2012, at 20:58, John Mandereau wrote:
>
>> Il giorno dom, 19/08/2012 alle 20.28 -0400, m...@mikesolomon.org ha
>> scritto:
>>> Nothing to do with iosnoop, but I did some snooping in the code base and I
>>> can't figure out
http://codereview.appspot.com/6446160/diff/1/lily/bar-engraver.cc
File lily/bar-engraver.cc (right):
http://codereview.appspot.com/6446160/diff/1/lily/bar-engraver.cc#newcode119
lily/bar-engraver.cc:119: " is required to trigger the creation of
system-start clefs.",
system-start is either an ide
Reviewers: ,
Message:
This minor change hardly needs the full review
machinery, especially as I've checked it with
a make doc.
Should I should push directly to staging?
Trevor
Description:
Doc: Bar_engraver is required for system-start clefs (2694)
Add sentence to doc string of Bar_engraver
31 matches
Mail list logo
