On 12 août 2012, at 22:05, Werner LEMBERG w...@gnu.org wrote:
Odd...I'll look into it.
Thanks!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hey Werner,
Had a
Ian Hulin i...@hulin.org.uk writes:
Dear all, (especially David and Graham)
Contrary to all indications, I have actually been slowly (very slowly)
chugging away on this, developing on my netbook.
In order to achieve this, we'll need produce a series of patches. The
criterion for accepting
Personally, I am almost in favor of a rather hard cut where we switch
from Guilev1 to Guilev2.
+1
Most direct would be a hard cut: exchange the Guile version, and get
everybody working furiously until LilyPond works again.
Yes :-)
Given that these patches will be quite extensive, is now
Le dimanche 12 août 2012 à 14:48 +0200, David Kastrup a écrit :
Documentation improvements are still admissable, documentation rewrites
not necessarily as we want to avoid significant changes between the
English documentation and reasonably well-maintained translations. I
have no clear view
David Kastrup d...@gnu.org writes:
2. Add new lily-guile2.scm, this is lily.scm re-written to use new
(include-from-path) guile macro instead of loading component files.
The current code in lily.scm is copied unchanged to lily-guile1.scm
and the lily.scm becomes a shim with
(cond-expand
I haven't built (well, a make all is going to test this change with
makeinfo --info, but even only this takes ages on an Intel Atom), but
LGTM. (FWIW I checked that all occurences have been dealt with in
Pitches and Rhythms with
git grep subheading Documentation/notation/*
.)
LGTM other than one slightly quibble.
http://codereview.appspot.com/6443116/diff/1/Documentation/common-macros.itexi
File Documentation/common-macros.itexi (right):
http://codereview.appspot.com/6443116/diff/1/Documentation/common-macros.itexi#newcode81
Documentation/common-macros.itexi:81:
LGTM
http://codereview.appspot.com/6464045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/6454140/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
John Mandereau john.mander...@gmail.com writes:
Le dimanche 12 août 2012 à 14:48 +0200, David Kastrup a écrit :
Documentation improvements are still admissable, documentation rewrites
not necessarily as we want to avoid significant changes between the
English documentation and reasonably
On Mon, Aug 13, 2012 at 09:38:15AM +0200, David Kastrup wrote:
3. Where there are significant changes to component .scm files for
guile V2, these will also be converted into a shim similar to lily.scm
and will have file-guile-1.scm and file-guile-2.scm files
produced.
Personally, I am
Graham Percival gra...@percival-music.ca writes:
On Mon, Aug 13, 2012 at 09:38:15AM +0200, David Kastrup wrote:
3. Where there are significant changes to component .scm files for
guile V2, these will also be converted into a shim similar to lily.scm
and will have file-guile-1.scm and
Reviewers: John Mandereau, Graham Percival,
Message:
On 2012/08/13 08:46:10, Graham Percival wrote:
How do you feel about @subsubsubheading {TEXT}?
Perfectly happy! I'll change it and complete
Chapter 1 in the next patch set.
Description:
Doc: standardise level 5 headings (2730)
- add
You have taken the path of removing THANKS altogether if I understand
correctly.
I am not sure whether we should not replace it by the edited output of
git shortlog -s release/2.14.2-1..release/2.15.95-1
instead, manually. That would cause the least disruption to the code.
At any rate,
On 13 août 2012, at 11:14, David Kastrup d...@gnu.org wrote:
Graham Percival gra...@percival-music.ca writes:
On Mon, Aug 13, 2012 at 09:38:15AM +0200, David Kastrup wrote:
3. Where there are significant changes to component .scm files for
guile V2, these will also be converted into a shim
Hello,
Just an FYI for those that understand this stuff:
I notice a warning during make doc
--snip--
/home/james/lilypond-git/build/python/out/book_snippets.py:744:
DeprecationWarning: os.popen3 is deprecated. Use the subprocess
module.
(stdin, stdout, stderr) = os.popen3 (cmd)
--snip--
On Mon, Aug 13, 2012 at 11:26:21AM +0100, James wrote:
Just an FYI for those that understand this stuff:
/home/james/lilypond-git/build/python/out/book_snippets.py:744:
DeprecationWarning: os.popen3 is deprecated. Use the subprocess
module.
(stdin, stdout, stderr) = os.popen3 (cmd)
I have
Le lundi 13 août 2012 à 10:55 +0200, David Kastrup a écrit :
I haven't really tracked translations so far, so my own level of
suitability here is pretty close to zero, modulo non-task-specific
computer expertise (which some people deem sufficient for making me
useful for Windows support, a
On 2012-08-13 02:44, Ian Hulin wrote:
Given that these patches will be quite extensive, is now a good time
to set up a guile-2 branch in git, forking off from the start of the
V2.17.0 development?
Setting up a dev/guile-2 branch on our git server is a good idea any
time you want your changes
Reinhold Kainhofer reinh...@fam.tuwien.ac.at writes:
I haven't checked,
That's the rub.
but I think the push command could also simply be:
git push origin dev/guile-2
(i.e. simply push the currently checked out branch to the
server(=origin) as branch dev/guile-2)
This only works for
John Mandereau john.mander...@gmail.com writes:
If I handled backporting translation updates,
If I handled it, I would try cherry-picking and praying. If your
proposal is in your comfort zone, I'd not mind letting you handle it.
However, I am not sure that the typical translator will
m...@mikesolomon.org m...@mikesolomon.org writes:
On 13 août 2012, at 11:14, David Kastrup d...@gnu.org wrote:
Graham Percival gra...@percival-music.ca writes:
On Mon, Aug 13, 2012 at 09:38:15AM +0200, David Kastrup wrote:
3. Where there are significant changes to component .scm files for
On 13/08/2012 15:54, David Kastrup wrote:
Reinhold Kainhofer reinh...@fam.tuwien.ac.at writes:
I haven't checked,
That's the rub.
See below...
This only works for existing branches/tags. Otherwise, git will not
know how to disambiguate the reference.
It seems to work here:
Simply include the attached file somewhere at the beginning of a
document to have Cyrillic support (however, due to the used
extension mechanism, you don't get kerning or hyphenation, even if
you set the document language to Russian).
I've committed a slightly improved version to the git
Reinhold Kainhofer reinh...@kainhofer.com writes:
On 13/08/2012 15:54, David Kastrup wrote:
Reinhold Kainhofer reinh...@fam.tuwien.ac.at writes:
I haven't checked,
That's the rub.
See below...
This only works for existing branches/tags. Otherwise, git will not
know how to disambiguate
Werner LEMBERG w...@gnu.org writes:
Simply include the attached file somewhere at the beginning of a
document to have Cyrillic support (however, due to the used
extension mechanism, you don't get kerning or hyphenation, even if
you set the document language to Russian).
I've committed a
I don't see this hack as the canonical way to go forward,
Interesting. I'm all ears to any more sensible solution which extends
the texinfo.tex framework without completely rewriting the font
selection mechanism.
and it is certainly not of the obviously trivial and correct
quality
Werner LEMBERG w...@gnu.org writes:
I don't see this hack as the canonical way to go forward,
Interesting. I'm all ears to any more sensible solution which extends
the texinfo.tex framework without completely rewriting the font
selection mechanism.
and it is certainly not of the obviously
I don't have more than the power of appeal to ask people from
refraining sabotaging the development branch until the settling
phase of 2.16 is mostly over, and that will be the case when 2.16.0
and 2.17.0 have been released: everything that actually should be
in 2.16.0 but did not warrant
Werner LEMBERG w...@gnu.org writes:
I don't have more than the power of appeal to ask people from
refraining sabotaging the development branch until the settling
phase of 2.16 is mostly over, and that will be the case when 2.16.0
and 2.17.0 have been released: everything that actually should
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to coordina...@translationproject.org.)
A new POT file for textual domain 'lilypond' has been made available
to the language teams for translation. It is archived as:
On Mon, Aug 13, 2012 at 08:16:48PM +0200, David Kastrup wrote:
Werner LEMBERG w...@gnu.org writes:
Hmm, `wild changes' is a mild exaggeration, isn't it? It makes
50 Cyrillic characters appear in the PDFs which were simply missing
previously. It's a one-line change in `macros.itexi'
and
http://codereview.appspot.com/6454121/diff/11001/input/regression/markup-user.ly
File input/regression/markup-user.ly (right):
http://codereview.appspot.com/6454121/diff/11001/input/regression/markup-user.ly#newcode22
input/regression/markup-user.ly:22: \override PaperColumn
#'keep-inside-line
In macros.itexi which is used throughout the entire documentation, for
every single Texinfo document, whether generating PDF, info, HTML. Have
you checked the performance impact?
Performance impact? For building the documentation? Are you kidding?
Building the snippets with LilyPond takes
But as soon as somebody complained (regardless of who it was,
regardless of the reason), I would revert the commit, and send the
patch for review+countdown.
Just done.
In the future, we'll all remember that changes to texinfo.tex can be
problematic, so we'll be slightly less likely to take
Graham Percival gra...@percival-music.ca writes:
On Mon, Aug 13, 2012 at 08:16:48PM +0200, David Kastrup wrote:
Werner LEMBERG w...@gnu.org writes:
Hmm, `wild changes' is a mild exaggeration, isn't it? It makes
50 Cyrillic characters appear in the PDFs which were simply missing
Reviewers: ,
Message:
It would be nice if a Russian speaking person could fix the Cyrillic
index entries. However, since we don't have Cyrillic characters in the
index, this is not an urgent issue (and maybe we never need this).
Description:
Add support for Cyrillic in texinfo.
Please review
Pushing to staging means I consider this change to be safe and
can't imagine anybody suggesting anything to change.
Actually, this is what I still believe. However, we probably agree to
disagree, and going the Rietveld route is certainly the safe way.
For changes with potentially large
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi
File Documentation/cyrillic.itexi (right):
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi#newcode14
Documentation/cyrillic.itexi:14: \gdef\cyrfont{%
The lack of kerning seems quite unnecessary.
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi
File Documentation/cyrillic.itexi (right):
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi#newcode14
Documentation/cyrillic.itexi:14: \gdef\cyrfont{%
I fully agree. However, I'm simply mimicking
On Mon, Aug 13, 2012 at 09:16:24PM +0200, David Kastrup wrote:
Graham Percival gra...@percival-music.ca writes:
Yes. Pushing directly to staging is basically a gamble:
IF YOU WIN: you avoid the delay and hassle of git-cl, reviews, a
patch countdown, etc.
IF YOU LOSE: somebody doesn't
http://codereview.appspot.com/6459081/diff/1/Documentation/macros.itexi
File Documentation/macros.itexi (right):
http://codereview.appspot.com/6459081/diff/1/Documentation/macros.itexi#newcode14
Documentation/macros.itexi:14: @include cyrillic.itexi
On 2012/08/13 19:37:26, lemzwerg wrote:
It's
Notation, section `Kievan contexts', or `snippets/utf-8.ly'.
http://codereview.appspot.com/6459081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6459081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Marc, Keith, all,
here is an intermediate report on how I stand with bar lines,
find attached a newer version.
Keith, I hope I fixed lyrics-bar.ly.
Marc, there are still differences from the c++ version:
1. in repeat-sign.ly the thick-lined staff has now the dots
outside of staff, while the
On 2012/08/13 19:17:28, lemzwerg wrote:
It would be nice if a Russian speaking person could fix the Cyrillic
index
entries. However, since we don't have Cyrillic characters in the
index, this is
not an urgent issue (and maybe we never need this).
Could you explain what you mean by fix the
For example, `Cyrillic letter V' currently maps to the `V', and
`Cyrillic letter G' maps to `G'. [All Cyrillic characters start
with prefix `' so that they get sorted after all Latin letters].
But this is certainly not the correct collation order for Russian!
AFAIK, `Cyrillic letter
Dear users of Patchy,
I have pushed a lot of changes, especially to staging/master branch, it
would be good if you could pull from lilypond-extra:master to test them:
https://github.com/gperciva/lilypond-extra/commit/054d8101e7bcd54bc8db40092b617bb8b2220b84
I have already tested these features
David == David Kastrup d...@gnu.org writes:
David Fragments may use the
David `papersize=STRING'
David Where STRING is a paper size defined in `scm/paper.scm' i.e.
David `a5', `quarto', `11x17' etc.
David Values not defined in `scm/paper.scm' will be ignored,
01:00:02 (UTC) Begin LilyPond compile, previous commit at
1dedaf12fb71d557b062412bddcd2ccba75df365
01:00:11 *** FAILED STEP ***
merge from staging
global name 'ActiveLock' is not defined
___
lilypond-devel mailing list
Needs a tweak for \endSpanners
http://codereview.appspot.com/5440084/diff/14005/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/5440084/diff/14005/ly/music-functions-init.ly#newcode296
ly/music-functions-init.ly:296: (if (memq
Worked nicely on some piano music and a Dvorak symphony.
The code is bewildering. So far I've mostly read the comments.
The bit with the activation-factor is pretty ugly.
What was the size of the problem ? Did the script that should have fit
lack space of padding, 0.5*padding, or epsilon ?
52 matches
Mail list logo
