> The minimum length of the stem of the middle note is forcing the
> beams down.
Sounds sensible. Can you provide a patch to fix that? The minimum
stem length for french beams must be handled identically to the
non-french case.
Werner
Am 25. Januar 2020 08:56:44 MEZ schrieb Werner LEMBERG :
>
>> What is "french beaming" supposed to do/be?
>
>No stems within the beam.
Ah, yes. Sorry for forgetting that...
>
>
>Werner
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Am Sa., 25. Jan. 2020 um 08:58 Uhr schrieb Kevin Barry :
>
> The minimum length of the stem of the middle note is forcing the beams down.
Not here. It's more the relevant value of
beamed-extreme-minimum-free-lengths. See:
\relative c'' {
r16 f d f
\override Stem.details.beamed-extreme-mi
Am Fr., 24. Jan. 2020 um 22:28 Uhr schrieb Thomas Morley
:
>
> Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble :
> >
> > On Jan 24, 2020, at 15:13, David Kastrup wrote:
> >
> >
> > Thomas Morley writes:
> >
> > ...
> >
> > In member function 'std::string Interval_t::to_string() const':
> > /h
On Sat, Jan 25, 2020 at 09:27:07AM +0100, Thomas Morley wrote:
> Am Sa., 25. Jan. 2020 um 08:58 Uhr schrieb Kevin Barry :
> >
> > The minimum length of the stem of the middle note is forcing the beams down.
>
> Not here. It's more the relevant value of
> beamed-extreme-minimum-free-lengths. See:
>
Thomas Morley writes:
> Am Fr., 24. Jan. 2020 um 22:28 Uhr schrieb Thomas Morley
> :
>>
>> Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble :
>> >
>> > On Jan 24, 2020, at 15:13, David Kastrup wrote:
>> >
>> >
>> > Thomas Morley writes:
>> >
>> > ...
>> >
>> > In member function 'std::string
LGTM, thanks
https://codereview.appspot.com/571420055/diff/571400046/configure.ac
File configure.ac (right):
https://codereview.appspot.com/571420055/diff/571400046/configure.ac#newcode391
configure.ac:391: ["(Using Ghostscript >= 9.20 together with Extract
PDFmark"])
I suggest to use the progra
Reviewers: lemzwerg,
https://codereview.appspot.com/571420055/diff/571400046/configure.ac
File configure.ac (right):
https://codereview.appspot.com/571420055/diff/571400046/configure.ac#newcode391
configure.ac:391: ["(Using Ghostscript >= 9.20 together with Extract
PDFmark"])
On 2020/01/25 09:15
Am 25.01.20 um 08:12 schrieb Werner LEMBERG:
Before adding it to the bug tracker I want to check this group's
knowledge whether there is a reason that French beams are longer than
normal:
\relative c'' {
r16 f d f
\override Stem.french-beaming = ##t
r16 f d f
}
Looking
Hello,
On 25/01/2020 09:43, Malte Meyn wrote:
Am 25.01.20 um 08:12 schrieb Werner LEMBERG:
Before adding it to the bug tracker I want to check this group's
knowledge whether there is a reason that French beams are longer than
normal:
\relative c'' {
r16 f d f
\override Stem.fr
Hello,
Here is the current patch countdown list. The next countdown will be on
January 27th
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
Push:
5676 remove obsolete lines from lily-guile-macros.hh - hanwen
https://codereview.appspot.com/573400043/diff/549420043/lily/sources.cc
File lily/sources.cc (right):
https://codereview.appspot.com/573400043/diff/549420043/lily/sources.cc#newcode60
lily/sources.cc:60: Sources::find_full_path(string file_string, string
const ¤t_dir)
On 2020/01/21 13:42:27, Dan
On 2020/01/24 15:50:22, Dan Eble wrote:
> On 2020/01/24 15:17:02, dak wrote:
> > On 2020/01/24 14:11:59, Dan Eble wrote:
> > > On 2020/01/24 14:06:22, hanwenn wrote:
> > > > If the allocation cost becomes problematic, we can use another
hashmap
> > > instead.
> > >
> > > "We" could profile it and
d...@gnu.org writes:
> On 2020/01/24 15:26:06, dak wrote:
>
> What I meant to say: I guess I should be able to handle those
> comparatively obvious merge conflicts.
>
> https://codereview.appspot.com/579240043/
But frankly, I have not been reckoning with having to deal with the ilk
of
commit 6f4
That seems weird for me. The topic states "this provides a way to run
LilyPond with Guile 2.2" but garbage collection with Guile 2.2 works out
of the box already. This patch only causes extra work and will slow
down garbage collection further.
The only way in which it could make sense is if in r
With https://codereview.appspot.com/551390047/
it looks like I can run LilyPond against GUILE 2.2 mostly:
$ time lilypond input/regression/mozart-hrn-3.ly
GNU LilyPond 2.21.0
Import (ice-9 threads) to have access to `call-with-new-thread'.
Import (ice-9 threads) to have access to `current-thread'
Reviewers: dak,
Message:
On 2020/01/25 12:37:32, dak wrote:
> That seems weird for me. The topic states "this provides a way to run
LilyPond
> with Guile 2.2" but garbage collection with Guile 2.2 works out of the
box
> already. This patch only causes extra work and will slow down garbage
> coll
On 2020/01/25 12:50:15, hanwenn wrote:
> On 2020/01/25 12:37:32, dak wrote:
> > That seems weird for me. The topic states "this provides a way to
run
> LilyPond
> > with Guile 2.2" but garbage collection with Guile 2.2 works out of
the box
> > already. This patch only causes extra work and will s
I've pushed all my local branches to
https://github.com/hanwen/lilypond , which make the rebasing and such
easier.
How does the pushing process go? Even though I am busy, maybe Jonas is
right that it's easier for everyone if I push directly.
On Sat, Jan 25, 2020 at 1:26 PM David Kastrup wrote:
>
(and in the process, I erroneously clobbered
https://github.com/lilypond/lilypond, which I am fixing now.
On Sat, Jan 25, 2020 at 2:01 PM Han-Wen Nienhuys wrote:
>
> I've pushed all my local branches to
> https://github.com/hanwen/lilypond , which make the rebasing and such
> easier.
>
> How does
On Jan 25, 2020, at 07:26, David Kastrup wrote:
>
> - Interval hex = head->extent (common_[X_AXIS], X_AXIS);
> + Interval head_ext = head->extent (common_[X_AXIS], X_AXIS);
...
>
> That last part applies part of a patch from an unrelated issue of
> Han-Wen. Please don't do stuff like
Am Sa., 25. Jan. 2020 um 13:48 Uhr schrieb Han-Wen Nienhuys :
>
> With https://codereview.appspot.com/551390047/
> it looks like I can run LilyPond against GUILE 2.2 mostly:
>
>
> $ time lilypond input/regression/mozart-hrn-3.ly
> GNU LilyPond 2.21.0
> Import (ice-9 threads) to have access to `call
> I'm going to call
>
> git push --mirror g...@github.com:lilypond/lilypond.git
>
> to update the github mirror. However, this will cause the following
> changes:
I've now done a push, and it seems to have worked correctly. Please
check.
Werner
Han-Wen Nienhuys writes:
> With https://codereview.appspot.com/551390047/
That patch is papering over a problem rather than fixing it. It might
be a reoccurence of something like
commit c01a2a757e3c59727bdfa8d77568bf42525fbe05
Author: Andy Wingo
Date: Thu Jun 23 11:47:42 2016 +0200
Fix
On Sat, Jan 25, 2020 at 2:45 PM Thomas Morley wrote:
> Compiling the same file with my slow loptop and
> released 2.19.83
>
..
> Without the error with string-append
interesting. I was on 2.2.4; maybe these were bugs fixed in 2.2.6 or
beyond. Let me see if I can upgrade things.
> > These timings
Han-Wen Nienhuys writes:
> I've pushed all my local branches to
> https://github.com/hanwen/lilypond , which make the rebasing and such
> easier.
>
> How does the pushing process go? Even though I am busy, maybe Jonas is
> right that it's easier for everyone if I push directly.
Current batch is
Am Sa., 25. Jan. 2020 um 15:03 Uhr schrieb Han-Wen Nienhuys :
>
> On Sat, Jan 25, 2020 at 2:45 PM Thomas Morley
> wrote:
> > Compiling the same file with my slow loptop and
> > released 2.19.83
> >
> ..
> > Without the error with string-append
>
> interesting. I was on 2.2.4; maybe these were bug
Dan Eble writes:
> On Jan 25, 2020, at 07:26, David Kastrup wrote:
>>
>> - Interval hex = head->extent (common_[X_AXIS], X_AXIS);
>> + Interval head_ext = head->extent (common_[X_AXIS], X_AXIS);
> ...
>>
>> That last part applies part of a patch from an unrelated issue of
>> Han-Wen.
Am Samstag, den 25.01.2020, 14:45 +0100 schrieb Thomas Morley:
> Am Sa., 25. Jan. 2020 um 13:48 Uhr schrieb Han-Wen Nienhuys <
> hanw...@gmail.com
> >:
> > [...]
> > I think it is clear that we should not be targeting GUILE 2.0, but GUILE
> > 2.2.
>
> I dropped any work for guile-2.0 long ago.
>
Am Samstag, den 25.01.2020, 14:01 +0100 schrieb Han-Wen Nienhuys:
> I've pushed all my local branches to
> https://github.com/hanwen/lilypond
> , which make the rebasing and such
> easier.
>
> How does the pushing process go? Even though I am busy, maybe Jonas is
> right that it's easier for ever
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Am Samstag, den 25.01.2020, 14:45 +0100 schrieb Thomas Morley:
>> Am Sa., 25. Jan. 2020 um 13:48 Uhr schrieb Han-Wen Nienhuys <
>> hanw...@gmail.com
>> >:
>> > [...]
>> > I think it is clear that we should not be targeting GUILE 2.0
Am Samstag, den 25.01.2020, 15:26 +0100 schrieb David Kastrup:
> Jonas Hahnfeld via Discussions on LilyPond development
> <
> lilypond-devel@gnu.org
> > writes:
>
> > Am Samstag, den 25.01.2020, 14:45 +0100 schrieb Thomas Morley:
> > > Am Sa., 25. Jan. 2020 um 13:48 Uhr schrieb Han-Wen Nienhuys <
Jonas Hahnfeld writes:
> Am Samstag, den 25.01.2020, 15:26 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond development
>> <
>> lilypond-devel@gnu.org
>> > writes:
>>
>> > Am Samstag, den 25.01.2020, 14:45 +0100 schrieb Thomas Morley:
>> > > Am Sa., 25. Jan. 2020 um 13:
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> With https://codereview.appspot.com/551390047/
>
> That patch is papering over a problem rather than fixing it. It might
> be a reoccurence of something like
>
> commit c01a2a757e3c59727bdfa8d77568bf42525fbe05
> Author: Andy Wingo
> Date:
On 2020/01/24 19:29:56, hanwenn wrote:
> I'm not asking for anyone to review. It's context to the other change
about
> multi-measure-rests.
OIC. An MMR reminder sounds interesting. Does the problem tie in with
others like repeating the current chord name after a page break?
https://codereview.
Reviewers: ,
Message:
It isn't clear to me how a dimension is different from a normal number,
but the current doc string seems to be incorrect all the same.
Description:
Doc: Corrected doc string for ly:dimension?
ly:dimension? is a predicate - it does not return a number.
Please review this at
https://codereview.appspot.com/577380046/
Reviewers: ,
Description:
https://sourceforge.net/p/testlilyissues/issues/5695/
Here are a few miscellaneous things that I've been holding onto for a
while because they would have been out of context in other reviews.
Each file is in a separate commit, though they're squashed in this
review.
1:
https://codereview.appspot.com/575530107/diff/581530050/lily/spaceable-grob.cc
File lily/spaceable-grob.cc (right):
https://codereview.appspot.com/575530107/diff/581530050/lily/spaceable-grob.cc#newcode92
lily/spaceable-grob.cc:92: break;
That looks still too complicated. Just do return *next_s
On Sat, Jan 25, 2020 at 3:57 PM wrote:
> > I'm not asking for anyone to review. It's context to the other change
> about
> > multi-measure-rests.
>
> OIC. An MMR reminder sounds interesting. Does the problem tie in with
> others like repeating the current chord name after a page break?
>
> https
https://codereview.appspot.com/577380046/diff/553430046/lily/dot-configuration.cc
File lily/dot-configuration.cc (right):
https://codereview.appspot.com/577380046/diff/553430046/lily/dot-configuration.cc#newcode69
lily/dot-configuration.cc:69: auto process_entry = [d, k, &new_cfg,
&offset](const
LGTM
https://codereview.appspot.com/573440043/
On 2020/01/25 18:24:32, hanwenn wrote:
>
https://codereview.appspot.com/577380046/diff/553430046/lily/dot-configuration.cc
> File lily/dot-configuration.cc (right):
>
>
https://codereview.appspot.com/577380046/diff/553430046/lily/dot-configuration.cc#newcode69
> lily/dot-configuration.cc:69: auto
On Sat, Jan 25, 2020 at 7:37 PM wrote:
>
> On 2020/01/25 18:24:32, hanwenn wrote:
> >
> https://codereview.appspot.com/577380046/diff/553430046/lily/dot-configuration.cc
> > File lily/dot-configuration.cc (right):
> >
> >
> https://codereview.appspot.com/577380046/diff/553430046/lily/dot-configura
On Sat, Jan 25, 2020 at 3:50 PM David Kastrup wrote:
> > That patch is papering over a problem rather than fixing it. It might
> > be a reoccurence of something like
> >
> > commit c01a2a757e3c59727bdfa8d77568bf42525fbe05
> > Author: Andy Wingo
> > Date: Thu Jun 23 11:47:42 2016 +0200
> >
> >
LGTM
https://codereview.appspot.com/553430047/diff/573430051/python/lilylib.py
File python/lilylib.py (right):
https://codereview.appspot.com/553430047/diff/573430051/python/lilylib.py#newcode257
python/lilylib.py:257: sys.stderr.write('command failed: %s\n' % cmd)
With space before the '(' or w
Han-Wen Nienhuys writes:
> On Sat, Jan 25, 2020 at 3:50 PM David Kastrup wrote:
>> > That patch is papering over a problem rather than fixing it. It might
>> > be a reoccurence of something like
>> >
>> > commit c01a2a757e3c59727bdfa8d77568bf42525fbe05
>> > Author: Andy Wingo
>> > Date: Thu
On Sat, Jan 25, 2020 at 8:16 PM David Kastrup wrote:
> > $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
> > -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> > -dAutoRotatePages=/None -dPrinted=false -sOutputFile=mozart-hrn-3.pdf
> > -c.setpdfwrite -f/tm
48 matches
Mail list logo
