This fails a make check (reg test comparison)
--snip--
Renaming input to:
`/tmp/lilypond-autobuild/input/regression/fret-boards.ly'
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
Writing header field `texidoc' to `./2d/lily-6db94e9b.texidoc'
Dan Eble writes:
> On May 6, 2015, at 14:43 , David Kastrup wrote:
>>
>> Neither \octave { bes, c d e f } nor \octave c { c' bes as g } or
>> \octave c'' { c' bes as g } seem particularly convincing.
>
> +1
>
>> \absolute c { c; bes as g } \absolute c'’ { c' bes as g }
>
> After further thought
I've just started working again on some mensural music with associated
modern transcription. The ancient score is about 8 pages long. With
2.18.2 one of the pieces takes 97 seconds to compile. With 2.19.19 it
takes 37 seconds.
Fantastic!
___
lily
On 06.05.2015, at 20:43, David Kastrup wrote:
> Werner LEMBERG writes:
>
>>> Probably the best name is \octave, which was used for something
>>> similar
>>> until version 0.1.19
>>>
>>>\octave c'' {c4 e g c e g c'1}
>>
>> Sounds OK for me.
>
> Huh. I like the contrast \relative/\absolu
Paul Morris writes:
On May 6, 2015, at 10:48 AM, Carl Sorensen
wrote:
So, I think I'm in favor of the proposal, but with a name change away
from
\absolute.
I agree about a name change since absolute doesn't really describe
this entry mode very well.
What if \absolute were changed to
On 2015/05/07 09:56:54, dak wrote:
Be more conservative by defining a separate LY_ASSERT_DERIVED_SMOB
Still LGTM. I'll use this when I resume work on
https://code.google.com/p/lilypond/issues/detail?id=4365.
https://codereview.appspot.com/229680043/
__
2015-05-06 22:47 GMT+02:00 Janek Warchoł :
> > I'll wait for your prototype, even if it looks like a work duplication
> > already.
> > Why not improving what's already available? Which advantages have the
> tools
> > you are using?
>
> I _am_ going to improve what's already available; i'll just us
Phil Holmes writes:
> I've just started working again on some mensural music with associated
> modern transcription. The ancient score is about 8 pages long. With
> 2.18.2 one of the pieces takes 97 seconds to compile. With 2.19.19 it
> takes 37 seconds.
>
> Fantastic!
A bit too fantastic.
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Thursday, May 07, 2015 12:06 PM
Subject: Re: Windows speed improvements - update
Phil Holmes writes:
I've just started working again on some mensural music with associated
modern transcription. The ancient sc
Am 07.05.2015 um 13:06 schrieb David Kastrup:
Phil Holmes writes:
I've just started working again on some mensural music with associated
modern transcription. The ancient score is about 8 pages long. With
2.18.2 one of the pieces takes 97 seconds to compile. With 2.19.19 it
takes 37 secon
Urs Liska writes:
> However, there's one more thing to consider here, particularly with
> the recent experiences wrt .ly compilation failures, is if there's a
> significant difference between binary releases and custom builds. From
> the above only 2.19.20 is self-compiled. But a self-compiled mo
> On May 7, 2015, at 7:38 AM, d...@gnu.org wrote:
>
>> I agree about a name change since absolute doesn't really describe
>> this entry mode very well.
>
>> What if \absolute were changed to something less, well, absolute?
>> Something along these lines, just to brainstorm a bit:
>
>> \fixed
>>
From reading the code, without testing, LGTM.
If possible, please apply this rather large patch in smaller commits so
that it becomes more readable.
Thanks for working on this!
https://codereview.appspot.com/233230044/diff/20001/scm/backend-library.scm
File scm/backend-library.scm (right):
ht
> On May 7, 2015, at 10:43 AM, Paul Morris wrote:
>
> \relative [optional pitch] { ...
> \absolute [no pitch] { ...
> \octave [obligatory pitch] { …
>
> The downside with this is that \absolute is really just a subset of the
> functionality of \octave, but they have different names. \octave
If possible, please apply this rather large patch in smaller commits
so that it
becomes more readable.
At least, I'll divide about PLATFORM variable changing.
https://codereview.appspot.com/233230044/diff/20001/scm/backend-library.scm#newcode142
scm/backend-library.scm:142: ;; includeing un
2015-05-07 16:25 GMT+02:00 Urs Liska :
> \repeat unfold 800 { c' d' e'8 d' c'4 }
>
> three times with averages of
>
> 2.16.2: ~21.5 sec.
> 2.19.15: ~ 16 sec.
> 2.19.17: ~ 14 sec.
> 2.19.20: ~ 12 sec.
>
> on Debian.
>
>
I did the same test on debian (sid), running the same version several times.
Wh
Still fails make doc
--snip--
GNU LilyPond 2.19.20
Forking into jobs: (13125 13124 13123 13122 13121 13120)
logfile lilypond-multi-run-3.log (exit 1):
. #) 4 . #)]
In
/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/framework-ps.scm:
635: 24* [clip-systems-to-region
"./e3/lily-775
On 2015/05/07 17:20:48, J_lowe wrote:
Still fails make doc
--snip--
GNU LilyPond 2.19.20
Forking into jobs: (13125 13124 13123 13122 13121 13120)
logfile lilypond-multi-run-3.log (exit 1):
. #) 4 . #)]
In
/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/framework-ps.scm:
On 04/05/15 23:35, Carl Sorensen wrote:
> On 5/4/15 4:25 PM, "Dan Eble" wrote:
>
>>> But anyways, the main point of this email is to point out that pushing
>>> debian could cost you developers - I don't know how many people like me
>>> there are out there, but if I have to use a debian-based syst
On 5/7/15 3:49 PM, "Wols Lists" wrote:
>
>Basically, what I'm saying is "don't assume everyone is using Debian
>and/or lilydev when you revamp the CG", because that's where that quote
>makes it look you're heading.
Thanks for the reminder. I hope we won't head that way. I agree that we
shouldn't
Hi all,
looks like srfi-1 is not available in \layout
\version "2.19.18"
\layout { #(display (append-map identity '((1) (2 }
{ c''1 }
returns:
Unbound variable: append-map
Is this intended?
Cheers,
Harm
___
lilypond-devel mailing list
lilypond
On May 7, 2015, at 11:19 , Paul Morris wrote:
>
> Here's another possibility with just two modes:
>
> \relative [optional pitch] {…}
> \octave [obligatory pitch] {…}
>
> And then just use \octave c {…} instead of \absolute {…}.
>
> In most cases one would simply use plain {…} for absolute-en
Just to add, it seems to fail make doc quite quickly (so if this log
isn't
helping you may want to try a make, make doc and see if you can debug
it
locally).
Usually make doc can take a long time, and only fail near the end -
but this
seems to fail relatively quickly.
I've fixed.
I've s
23 matches
Mail list logo
