"m...@apollinemike.com" writes:
> \markup { \column { \italic foo bar }} would use line as its layout
> manager and have two elements, one markup that used nothing as its
> layout manager (markups with 1 element cannot have layout managers)
> and had no transformations and one markup that used no
On Mon, Oct 24, 2011 at 08:53:16AM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > Hmm. At the moment, master and dev/staging cannot be "combined"
> > (to use hopefully non-specific terminology) with --ff-only.
> > Bertrand's 6ee8c04678442855cb794d4598c056c15c42673b gets in the
>
>
Graham Percival writes:
> On Mon, Oct 24, 2011 at 08:53:16AM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Hmm. At the moment, master and dev/staging cannot be "combined"
>> > (to use hopefully non-specific terminology) with --ff-only.
>> > Bertrand's 6ee8c04678442855cb794d459
On Oct 24, 2011, at 8:57 AM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> \markup { \column { \italic foo bar }} would use line as its layout
>> manager and have two elements, one markup that used nothing as its
>> layout manager (markups with 1 element cannot have layout managers
2011/10/23 Federico Bruni :
> I've almost gave up here.
> I don't have skills nor time to spend on this issue, sorry.
I understand it. It is probably my fault, to be unable of explaining
it more clearly. _I_ am sorry.
> The attached patch fixes the bad object error.
> I have no idea if it's corr
LGTM.
http://codereview.appspot.com/5303063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Bertrand, Mike, David, Reinhold and everyone in the \markup rewrite
gang,
Here is a bulletin from the Guile V2 migration cave.
I am currently brewing a patch for Tracer 1686.
The markup facility as written is a major PITA when running with Guile
V2, and is currently blocking progress on this
Ian Hulin writes:
> Hi Bertrand, Mike, David, Reinhold and everyone in the \markup rewrite
> gang,
>
> Here is a bulletin from the Guile V2 migration cave.
>
> I am currently brewing a patch for Tracer 1686.
>
> The markup facility as written is a major PITA when running with Guile
> V2, and is c
Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
master, as far as I can see without any discussion and without going
through staging.
I changed the rules somewhat in order make them get useful output for
\once\override as well, and pushed this directly to master as a
followup
On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>
> Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
> master, as far as I can see without any discussion and without going
> through staging.
>
This got to patch push after going through a countdown.
As for staging, I'm stil
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>
>>
>> Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
>> master, as far as I can see without any discussion and without going
>> through staging.
>>
>
> This got to patch push after going
On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>>
>>>
>>> Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
>>> master, as far as I can see without any discussion and without going
>>
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>
>> "m...@apollinemike.com" writes:
>>
>>> On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>>>
Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
master, as far as I can see
On Oct 24, 2011, at 5:29 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>>
>>> "m...@apollinemike.com" writes:
>>>
On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>
> Mike has pushed directly 671b7b634088
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 5:29 PM, David Kastrup wrote:
>
>> The problem is that eventually, somebody else _will_ run
>> scripts/auxiliar/update-with-convert-ly and then those files get
>> "fixed" again if the version string indicates they have not yet been
>> fixed.
>
Hi all,
Is there am easy way of generating a shared library with all the
scheme definitions generated in code by the C++ macro LY_DEFINE and
friends? I would like have a way of testing scheme files from the
Guile repl.
It would take some of the grief out of hacking for the Guile V2 scheme
port as
Dear developers,
I compiled yesterday (with 2.15.14) a file that was first compiled with
2.15.5. I was surprised to see that the default line breaks were quite
different and some measures were really ugly (speaking of horizontal
spacing) with the latest version!
I have a passage with many 32th n
On 14 October 2011 00:33, Kieren MacMillan
wrote:
>
> This is a little frustrating, as it was part of a bounty fix from some
> time ago.
>
> I understand the ultimate fix is [apparently] difficult — and Neil
> generously gave me a hack to tweak certain issues, especially at line
> breaks — but it
On Oct 24, 2011, at 5:53 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 24, 2011, at 5:29 PM, David Kastrup wrote:
>>
>>> The problem is that eventually, somebody else _will_ run
>>> scripts/auxiliar/update-with-convert-ly and then those files get
>>> "fixed" again if th
Xavier Scheuer writes:
> On 14 October 2011 00:33, Kieren MacMillan
> wrote:
>>
>> This is a little frustrating, as it was part of a bounty fix from some
>> time ago.
>>
>> I understand the ultimate fix is [apparently] difficult — and Neil
>> generously gave me a hack to tweak certain issues, es
"m...@apollinemike.com" writes:
> 3) When patches come out and are on review, especially when the
> patches go through the review cycle more than once, it'd be great if
> this sort of thing were addressed. Originally I didn't add convert-ly
> rules because I wasn't 100% sure on the syntax and wa
On Oct 24, 2011, at 8:44 PM, Xavier Scheuer wrote:
> Dear developers,
>
> I compiled yesterday (with 2.15.14) a file that was first compiled with
> 2.15.5. I was surprised to see that the default line breaks were quite
> different and some measures were really ugly (speaking of horizontal
> spac
"m...@apollinemike.com" writes:
> I now see what the problem is. I had updated the version number all
> the snippets that needed updating, but all of the offending snippets
> are in the .tely files. The \version statement for these snippets is
> not in the snippets themselves (I thought they we
Seems like my suggestion to update the version numbers of files with
manual fixes (in a separate commit) in order not to get them updated
again got lost, as well as the bit about rereading the diff for
problems.
http://codereview.appspot.com/5309059/diff/1/Documentation/es/learning/tweaks.itely
One obvious change to get it to compile, and then it looks good to me.
If you email me a patch from `git format-patch` I'll push it with you as
author; otherwise I'll just push it after countdown.
http://codereview.appspot.com/4974075/diff/33001/lily/staff-symbol.cc
File lily/staff-symbol.cc (r
http://codereview.appspot.com/5293060/diff/2001/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/5293060/diff/2001/lily/beam.cc#newcode987
lily/beam.cc:987: Beam::calc_x_span (Grob *me_non_spanner, Grob
*commonx)
Why should the x-span of a line-broken beam depend on whether
On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
> git fetch
> git rebase origin/dev/staging
> git push origin HEAD:dev/staging
>From the rebase command on my local branch, I got:
fatal: Needed a single revision
invalid upstream origin/dev/staging
Any hints on what to do?
Cheers,
MS
_
On Oct 24, 2011, at 11:41 PM, d...@gnu.org wrote:
> Seems like my suggestion to update the version numbers of files with
> manual fixes (in a separate commit) in order not to get them updated
> again got lost, as well as the bit about rereading the diff for
> problems.
>
>
I'll redo the patch -
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>
>> git fetch
>> git rebase origin/dev/staging
>> git push origin HEAD:dev/staging
>
> From the rebase command on my local branch, I got:
>
> fatal: Needed a single revision
> invalid upstream origin/dev/staging
LGTM and makes just about every output score look much better.
http://codereview.appspot.com/5241047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>>
>>> git fetch
>>> git rebase origin/dev/staging
>>> git push origin HEAD:dev/staging
>>
>> From the rebase command on my local branch, I got:
>>
>> fat
On Oct 25, 2011, at 5:52 AM, k-ohara5...@oco.net wrote:
>
> http://codereview.appspot.com/5293060/diff/2001/lily/beam.cc
> File lily/beam.cc (right):
>
> http://codereview.appspot.com/5293060/diff/2001/lily/beam.cc#newcode987
> lily/beam.cc:987: Beam::calc_x_span (Grob *me_non_spanner, Grob
> *c
On Oct 24, 2011, at 11:05 PM, David Kastrup wrote:
>
>
>> 2) A reminder in 10.9.5 to change versions when moving stuff to
>> Documents/snippets/new would be great too.
>
> I am not sure whether that is not something Graham wants to do himself.
> However, I think it is harmless enough to do it o
"m...@apollinemike.com" writes:
> On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
>
>> "m...@apollinemike.com" writes:
>>
>>> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>>>
git fetch
git rebase origin/dev/staging
git push origin HEAD:dev/staging
>>>
>>> From the rebase
34 matches
Mail list logo
