Hi all,
Am 03.06.2012 22:58, schrieb Thomas Morley:
Hi,
together with Marc Hohl I was working on Issue 1320 for a couple of weeks.
Now we have a first working version using a new approach to design BarLines:
Only simple BarLines are predefined e.g | . : etc (plus some
exceptions).
Some
Am 05.06.2012 08:29, schrieb Marc Hohl:
Hi all,
Am 03.06.2012 22:58, schrieb Thomas Morley:
Hi,
together with Marc Hohl I was working on Issue 1320 for a couple of
weeks.
Now we have a first working version using a new approach to design
BarLines:
Only simple BarLines are predefined e.g |
Hello,
Now that I have looked at the scripts for building staging and merging
it into master, upgraded my Fedora installation, a cron job runs this
every two hours on my computer in the lab, and sends an email
notification only if something fails or when a build is done. How about
adding merging
2012/6/5 John Mandereau john.mander...@gmail.com:
Hello,
Now that I have looked at the scripts for building staging and merging
it into master, upgraded my Fedora installation, a cron job runs this
every two hours on my computer in the lab, and sends an email
notification only if something
John Mandereau john.mander...@gmail.com writes:
Hello,
Now that I have looked at the scripts for building staging and merging
it into master, upgraded my Fedora installation, a cron job runs this
every two hours on my computer in the lab, and sends an email
notification only if something
2012/6/5 David Kastrup d...@gnu.org:
The only automatic merges that are actually safe to do are
fast-forwards, and the translation merges are not of that kind.
Sure? we change our own distinct files.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
Francisco Vila paconet@gmail.com writes:
2012/6/5 David Kastrup d...@gnu.org:
The only automatic merges that are actually safe to do are
fast-forwards, and the translation merges are not of that kind.
Sure? we change our own distinct files.
commit
Il giorno mar, 05/06/2012 alle 12.15 +0200, David Kastrup ha scritto:
Change A redefines a function and its callers.
Change B introduces another call of the function.
No merge conflict.
I see. You're right, in an ideal world change B would always produce a
build error, but in the real
John Mandereau john.mander...@gmail.com writes:
Il giorno mar, 05/06/2012 alle 12.15 +0200, David Kastrup ha scritto:
Change A redefines a function and its callers.
Change B introduces another call of the function.
No merge conflict.
I see. You're right, in an ideal world change B
http://codereview.appspot.com/6272046/diff/9001/lily/slur-engraver.cc
File lily/slur-engraver.cc (right):
http://codereview.appspot.com/6272046/diff/9001/lily/slur-engraver.cc#newcode174
lily/slur-engraver.cc:174: bool ended = false;
Moving this out of the loop is simply wrong. This will get a
Graham Percival gra...@percival-music.ca writes:
On Tue, Jun 05, 2012 at 10:11:46AM +0200, John Mandereau wrote:
Now that I have looked at the scripts for building staging and merging
it into master, upgraded my Fedora installation, a cron job runs this
every two hours on my computer in the
file from VC not distributed:
lilypond-2.15.40/Documentation/fr/texidocs/broken-crescendo-hairpin.ly
rm -rf /tmp/tmpEc298t
Traceback (most recent call last):
File test-lily/dist-check.py, line 137, in module
main ()
File test-lily/dist-check.py, line 132, in main
check_files (tarball,
On Tue, Jun 5, 2012 at 5:11 AM, John Mandereau john.mander...@gmail.com wrote:
What do you think of this?
The only objection I'm seeing for now is that there are too frequent
issues of files non distributed in tarball; for dealing with this I
propose to use dist-check from GUB, with an
2012/6/5 Graham Percival gra...@percival-music.ca:
file from VC not distributed:
lilypond-2.15.40/Documentation/fr/texidocs/broken-crescendo-hairpin.ly
How is this possible?
Documentation/xx/texicods/GNUmakefile is identical for xx = es fr de etc.
In case this is not only possible but a fact,
- Original Message -
From: Francisco Vila paconet@gmail.com
To: Graham Percival gra...@percival-music.ca
Cc: lilypond-devel@gnu.org
Sent: Tuesday, June 05, 2012 3:52 PM
Subject: Re: another GUB build failure from translations
2012/6/5 Graham Percival gra...@percival-music.ca:
2012/6/5 Phil Holmes m...@philholmes.net:
It looks like an error in the French translation's file name - it's there as
broken-crescendo-hairpin.ly whereas in es/texidocs/ (for example) it's
broken-crescendo-hairpin.texidoc
Ah yes, thank you, I will fix it in staging. Right?
--
Francisco Vila.
On Tue, Jun 05, 2012 at 05:15:54PM +0200, Francisco Vila wrote:
2012/6/5 Phil Holmes m...@philholmes.net:
It looks like an error in the French translation's file name - it's there as
broken-crescendo-hairpin.ly whereas in es/texidocs/ (for example) it's
broken-crescendo-hairpin.texidoc
- Original Message -
From: Graham Percival gra...@percival-music.ca
To: Francisco Vila paconet@gmail.com
Cc: Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org
Sent: Tuesday, June 05, 2012 4:19 PM
Subject: Re: another GUB build failure from translations
On Tue, Jun 05, 2012
On Tue, Jun 05, 2012 at 06:47:28PM +0100, Colin Hall wrote:
I'm aware that libmpfr is a listed requirement for GUB and I have
apt-get installed it.
However, I see that libmpfr is also built by GUB. Not sure if it is
host or cross.
The history here is a bit vague, but in case you haven't
There is a patch up for possible countdown, but I don't see any
agreement on whether or not it is ready. I propose to leave it on
review, and ask that other devels have a look at Issue 2584
http://code.google.com/p/lilypond/issues/detail?id=2584: please make
partcombine merge slurs - R
20 matches
Mail list logo
