On 09/20/2016 11:44 AM, Urs Liska wrote:
There's a fixed review cycle (controlled by automated tests) of
new->review->countdown->push.
See also documentation in the contributor's guide here:
http://lilypond.org/doc/v2.19/Documentation/contributor/the-patch-review-cycle
-Paul
Am 20.09.2016 um 17:31 schrieb Mathieu Demange:
> Hi Urs,
>
>> is it possible that you didn't notice this:
>> https://codereview.appspot.com/308430043/?
> Oh my! I see I'm lacking some "what's up with Lily" bookmarks, right now...
>
> That's exactly it! Thanks Urs! And thanks Paul!
>
> I'm
Hi Urs,
> is it possible that you didn't notice this:
> https://codereview.appspot.com/308430043/?
Oh my! I see I'm lacking some "what's up with Lily" bookmarks, right now...
That's exactly it! Thanks Urs! And thanks Paul!
I'm curious about Lily dev cycle. AFAIK this patch is simple,
On 09/20/2016 10:38 AM, Mathieu Demange wrote:
now I'm simply looking for a way to put extra attributes in tags.
Hi Mathieu, Look no further:
https://sourceforge.net/p/testlilyissues/issues/4974/
:-) I finished working on this over the weekend and submitted a patch.
So it should just be
Hi Matheiu,
is it possible that you didn't notice this:
https://codereview.appspot.com/308430043/?
Urs
Am 20.09.2016 um 16:38 schrieb Mathieu Demange:
>> The latter seem to be dealt with sufficiently by working with Midi and
>> external tool chains: after all, the main point of LilyPond is
> The latter seem to be dealt with sufficiently by working with Midi and
> external tool chains: after all, the main point of LilyPond is turning a
> music description to an equivalent output. Though _if_ outputs can
> reasonably easy be defined in Scheme, being able to control most of the
>
Knut Petersen writes:
> Am 14.09.2016 um 12:19 schrieb David Kastrup:
>>
>> Of course it is not "necessary to rewrite the code in Scheme first"
>> before making changes to it. But for one thing, not a lot will happen
>> without it, for another, without some generally
Am 14.09.2016 um 12:19 schrieb David Kastrup:
Of course it is not "necessary to rewrite the code in Scheme first"
before making changes to it. But for one thing, not a lot will happen
without it, for another, without some generally useful output definition
possibilities, backends like Braille,
Knut Petersen writes:
> Am 13.09.2016 um 14:04 schrieb David Kastrup:
>>
>>> I believe the output backend principle is a good sign of extensibility
>>> but is it really the case? How to instruct Lilypond to use a custom
>>> one, then?
>> You'd have to make use of one
Am 13.09.2016 um 14:04 schrieb David Kastrup:
I believe the output backend principle is a good sign of extensibility
but is it really the case? How to instruct Lilypond to use a custom
one, then?
You'd have to make use of one of the existing translator groups (like
Engraver_group or
"H. S. Teoh" writes:
> On Tue, Sep 13, 2016 at 02:04:04PM +0200, David Kastrup wrote:
>> Mathieu Demange writes:
>>
>> > Hello all,
>> >
>> > Could anybody help me to know if writing a custom output backend (in
>> > scheme, of course) for
On Tue, Sep 13, 2016 at 02:04:04PM +0200, David Kastrup wrote:
> Mathieu Demange writes:
>
> > Hello all,
> >
> > Could anybody help me to know if writing a custom output backend (in
> > scheme, of course) for Lilypond is something doable? I mean without
> > modifying
Mathieu Demange writes:
> Hello all,
>
> Could anybody help me to know if writing a custom output backend (in
> scheme, of course) for Lilypond is something doable? I mean without
> modifying any of Lilypond's internals.
>
> I believe the output backend principle is a
Hello all,
Could anybody help me to know if writing a custom output backend (in scheme, of
course) for Lilypond is something doable? I mean without modifying any of
Lilypond's internals.
I believe the output backend principle is a good sign of extensibility but is
it really the case? How to
14 matches
Mail list logo