Re: Issue 2240 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Updates: Labels: -Patch-needs_work Patch-new Comment #7 on issue 2240 by d...@gnu.org: Patch: Don't wrap EventChord around rhythmic events by default. http://code.google.com/p/lilypond/issues/detail?id=2240 Ok, here is another theory about your failure: you have old versions of lily/rhythmic-music-iterator.cc and lily/include/rhythmic-music-iterator.hh in your tree, and if you do git apply patch-from-Rietveld you get an error message that they are already there, and they don't get updated. Remove them before calling git apply. Here is how to avoid this in future: Always when you use git-apply, use git apply --index. Never anything else. Why does this help? It means that the patch is not just applied to the working directory, but also is something git knows about _independently_. If you afterwards to git reset --hard, git will _not_ touch files in the working it does not know about. In this case, the old versions of the rhythmic music iterator. So they stick around perpetually. If you did git apply --index instead, git _does_ know about those files. When the patch created them, git reset --hard will remove them again. So please check again after removing those unregistered files from your work directory manually. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2240 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Comment #8 on issue 2240 by d...@gnu.org: Patch: Don't wrap EventChord around rhythmic events by default. http://code.google.com/p/lilypond/issues/detail?id=2240#c8 Don't wrap EventChord around rhythmic events by default. This changes quite a number of things and required quite a few code changes. It is obvious that there is a lot of code duplication in Lilypond. A number of regtest differences show up: most of them actually demonstrate bugs in the preexisting code base that fails to typeset things like with the same carefulness as c-. is typeset. Since c-. is no longer treated like -. this becomes obvious in a number of cases. The part combiner has several problems, the tablature code has a few, relying on string numbers getting lost by default does no longer work, the fingering engraver is affected. Displaying music obviously is no longer working; this is not a defect of the old code but rather needs work to match the new realities. All in all, things could be worse. This is merely a first sketch and should at least provide for interesting experiments. http://codereview.appspot.com/5440084 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2241 in lilypond: Book only puts copyright information on the first page
Status: Accepted
Owner:
Labels: Type-Other
New issue 2241 by philehol...@gmail.com: Book only puts copyright
information on the first page
http://code.google.com/p/lilypond/issues/detail?id=2241
Reported by Christopher Maden:
When using multiple bookparts within a book, it would be common for each to
have its own copyright. However, it only seems possible to put copyright
information on the first page. When using book and bookpart, lilypond
should use the relevant copyright for each bookpart.
\version "2.14.2"
#(set-default-paper-size "letter")
\paper {
print-all-headers = ##t
}
\book {
\header {
title = "LilyPond Copyright Test Main Title"
copyright = "Copyright for first score"
}
\bookpart {
\score {
\relative c' { c c c c }
\header {
title = "Title Bookpart 1"
}
}
}
\bookpart {
\score {
\relative c' { c d e f }
\header {
title = "Title Bookpart 2"
copyright = "Copyright Bookpart 2"
}
}
}
\bookpart {
\score {
\relative c' { c d e f }
\header {
title = "Title Bookpart 3"
copyright = "Copyright Bookpart 3"
}
}
}
}
Attachments:
copyright.pdf 32.9 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond ignores copyright assertions for scores in a book.
"Christopher R. Maden" wrote in message news:loom.20120122t055416-...@post.gmane.org... As posted to lilypond-user, assertion of copyright in a score header has no discernible effect on the output. I don’t much care where it ends up, but it ought to do something. The attached tiny example was made with 2.12, but apparently the problem persists in 2.14 and up. [Er... I don’t seem to be able to attach files via the Web interface. The file copyright.ly was posted by me to lilypond-user, see https://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00521.html >.] ~Chris Added as http://code.google.com/p/lilypond/issues/detail?id=2241 -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: empty strings: tabStaff insists on stringnumbers and looses notes
"s. runkel" wrote in message
news:loom.20120121t151646-...@post.gmane.org...
Hi,
Just upgraded from 2.12 to 2.14.2.
Problem:
Compiling the example below results in a waring in the log file:
Warnung: Keine Saite fuer Tonhoehe # (Bund (5) angegeben)
and the c note is lost.
However, that note was shown as the empty 4th string in 2.12.
\score {
\new TabStaff {
% cister-tuning defined in string-tunings-init.ly:
% (cister-tuning . ,#{#})
\set Staff.stringTunings = #cister-tuning
1 1
}
}
I get the following error when trying to test this on 2.12.3:
TabStaffLosesNotes.ly:5:33: error: GUILE signaled an error for the
expression beginning here
\set Staff.stringTunings = #
cister-tuning
Please supply a complete working example.
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tabstaff: Epmty String no longer prefered when accord spans 2 octaves
"s. runkel" wrote in message
news:loom.20120121t142956-...@post.gmane.org...
Hi,
Just upgraded from 2.12 to 2.14.2.
Problem:
If an accord spans more than or equal to 2 octaves,
an empty string is not used but the lowest string shows a fretted
position.
Example:
\score {
\new TabStaff {
< a, gis' >1
< a, a' >1
< a, ais' >1
< a, dis a' >1
}
}
Thanks. Entered as http://code.google.com/p/lilypond/issues/detail?id=2242.
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2242 in lilypond: Incorrect tabstaff fingering
Status: Accepted
Owner:
Labels: Type-Critical Regression
New issue 2242 by philehol...@gmail.com: Incorrect tabstaff fingering
http://code.google.com/p/lilypond/issues/detail?id=2242
Reported by S Runkel:
If an accord spans more than or equal to 2 octaves, an empty string is not
used but the lowest string shows a fretted position.
\score {
\new TabStaff {
< a, gis' >1
< a, a' >1
< a, ais' >1
< a, dis a' >1
}
}
The output is incorrect in every 2.13.x release post 2.13.31 (PH's
earliest) and changed to its current output in 2.13.34. It appears this
may not be being tested in a regtest.
Attachments:
TabStaff2.12.3.png 2.2 KB
TabStaff2.15.24.png 2.4 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2243 in lilypond: Incorrect subdivision of beams
Status: Accepted
Owner:
Labels: Type-Critical Regression
New issue 2243 by philehol...@gmail.com: Incorrect subdivision of beams
http://code.google.com/p/lilypond/issues/detail?id=2243
Reported by Xavier:
Just reported on the French Users mailing list:
Snippet
%% subdivideBeams does not work anymore with 16th tuplets.
%% With 2.15.26 only the second beat is subdivided as expected.
%% Worked well with stable 2.14.2, so this is a Regression.
\version "2.15.26"
\relative c'' {
\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1 8)
\set beatStructure = #'(2 2 2 2)
\repeat unfold 8 {
\times 2/3 { c16 e d }
}
}
PH reports that 2.15.18 is OK, the beam pattern changed by 2.15.21 and
again at 2.15.24.
Attachments:
SubdivideBeams.15.18.png 3.6 KB
SubdivideBeams.15.21.png 3.5 KB
SubdivideBeams.15.24.png 3.5 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Regression: 16th tuplets not subdivided with subdivideBeams
"Xavier Scheuer" wrote in message
news:CADGqHRfMs2GpBr3qw=axfs2cxuug8sa-yfrnfempjvs0+zp...@mail.gmail.com...
Hello,
Just reported on the French Users mailing list:
Snippet
%% subdivideBeams does not work anymore with 16th tuplets.
%% With 2.15.26 only the second beat is subdivided as expected.
%% Worked well with stable 2.14.2, so this is a Regression.
\version "2.15.26"
\relative c'' {
\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1 8)
\set beatStructure = #'(2 2 2 2)
\repeat unfold 8 {
\times 2/3 { c16 e d }
}
}
End of snippet
Cheers,
Xavier
Added as http://code.google.com/p/lilypond/issues/detail?id=2243
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tuplet Bracket Spacing Bug
"Jay Anderson" wrote in message
news:cakwqkfzu2gb0vknqox-z_3squup6ch4nkazdokmcqncpv0c...@mail.gmail.com...
\version "2.15.26"
\score
{
\new Staff \relative c''
{
\times 2/3 {c4\ff c c}
}
}
It looks like the bracket is making space for the dynamic, but the
dynamic is staying outside anyway. The same effect happens with beamed
tuplets, but in that case there's no bracket to move. It was
introduced sometime between 2.15.23 and 2.15.24 (I haven't narrowed it
down to the commit).
-Jay
Added by James as http://code.google.com/p/lilypond/issues/detail?id=2231
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Defect [new]: \partcombine: accidental reminders of first partlost.
"Xavier Scheuer" wrote in message
news:cadgqhrcgnbtac4ze_hnwgl-nvn7rx9znpsh6rakudmz1bmc...@mail.gmail.com...
On 19 January 2012 18:06, Peter Häring wrote:
\partcombine { bes'1 b'! } { g'1 b' }
%Second example: second part has a reminder natural; it is shown in
combined
% parts (as it should be).
\partcombine { d''1 b' } { bes'1 b'! }
Workaround:
\partcombine { bes'1 \partcombineApartOnce b'! } { g'1 b' }
\partcombine { d''1 b' } { bes'1 \partcombineApartOnce b'! }
but then we fall in the case of displaying "complex chords", like
. I thought we had this accidentals in "complex chords" as an
issue on the tracker but I do not find it. It as been discussed several
times on various LilyPond mailing lists, there is a snippet "Displaying
complex chords" on the LSR: http://lsr.dsi.unimi.it/LSR/Item?id=505
(not always "usable").
AFAIK developers would like examples of how such situations are handled
by music publishers. Do they use separate note heads, where do they
place the accidentals, etc. But if "complex accidentals in chords" is
not tracked yet, then it should be added IMHO.
Relevant code showing the issue is simply
If someone could have a look at what Ross, Read or Gould say about this,
how to engrave it, that would be very kind.
I do not know how (forced, cautionary) accidentals are handled by
\partcombine but that may require a separate issue.
Cheers,
Xavier
--
Xavier Scheuer
Marek added this as http://code.google.com/p/lilypond/issues/detail?id=2235
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2244 in lilypond: Beamlet orientation is wrong in compound meters
Status: Accepted
Owner:
Labels: Type-Critical Regression
New issue 2244 by philehol...@gmail.com: Beamlet orientation is wrong in
compound meters
http://code.google.com/p/lilypond/issues/detail?id=2244
Reported by Martin Straeten
\score {
\relative c'{
\time 6/8
c16 d e f8. c8. d16 e f
\time 3/4
c16 d e f8. c8. d16 e f
}
}
Much discussion at
http://old.nabble.com/wrong-beamlet-direction-in-6-8-and-3-4-measure-for-dotted-quaver-and-semiquavers-td33144616.html
Attachments:
BeamingII.png 4.1 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2240 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Updates: Labels: -Patch-new Patch-review Comment #9 on issue 2240 by d...@gnu.org: Patch: Don't wrap EventChord around rhythmic events by default. http://code.google.com/p/lilypond/issues/detail?id=2240 Manually changed to Patch-review after very extensive manual testing since it would appear that Patchy's automated testing got confused by stale files in its work tree and will not be accurate in a timely manner. If you are testing from a Rietveld patch (actually any patch), please use git apply --index for applying the patch so that git sees newly added files in the worktree and will remove them when you do git reset --hard If you tested this patch previously, please make sure that you don't have stale files in your work tree before applying the patch again. Running git clean might work for that. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2210 in lilypond: Patch: Build: Top-level GNUmakefile
Comment #6 on issue 2210 by philehol...@gmail.com: Patch: Build: Top-level GNUmakefile http://code.google.com/p/lilypond/issues/detail?id=2210 I think I'm having some problems relating to this. If I run this: rm -f -r build sh autogen.sh --noconfigure mkdir -p build cd build ../configure I get: Source directory already configured. Please clean the source directory make -C /home/phil/lilypond-git distclean and rerun configure. This comes from if test -f $srcdir/GNUmakefile; then in configure. So it looks like it assumes that the presence of a file called GNUmakefile in topdir stops configur from completing properly. If I rename GNUmakefile it runs as expected - albeit without a GNUmakefile at all in the git directory - even after running make. Please advise (running with renamed GNUmakefile.old at present). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2210 in lilypond: Patch: Build: Top-level GNUmakefile
Comment #7 on issue 2210 by julien.r...@gmail.com: Patch: Build: Top-level GNUmakefile http://code.google.com/p/lilypond/issues/detail?id=2210 It thinks that you previously ran ./configure in the source dir and doesn't like that. Howcome you have a GNUmakefile in your source dir? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #11 on issue 2146 by philehol...@gmail.com: Error: Illegal entry in
bfrange block in ToUnicode CMap
http://code.google.com/p/lilypond/issues/detail?id=2146
OK - been doing some work on this with Julien, and here's what I've found.
Using a patch Julien kindly prepared led to the error not being fixed. The
problem appeared to be that Werner's test fix above uses
/usr/share/ghostscript/fonts/ as the path to the directory, whereas
NCSB_DIR resolves to /usr/share/fonts/type1/gsfonts/ (which is where the
fonts actually are) - there's no trace of the other path on my system.
After a fair amount of checking, I've concluded that the way Werner's fix
actually worked was that it was pointing to a non-existent file - do this
and the error disappears. In other words, putting this:
\pdfmapline{=pncr8r CenturySchL-Roma at the top of notation.tely causes notation to compile with no bfrange
errors (there are normally 88) and with properly displayed Cyrillic text.
So it appears that all that's necessary is to create font mappings to a
font file in a non-existent directory. Hmm. I'm a bit loathe to do this
without someone else confirming that this would be an acceptable solution.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2210 in lilypond: Patch: Build: Top-level GNUmakefile
Comment #8 on issue 2210 by philehol...@gmail.com: Patch: Build: Top-level GNUmakefile http://code.google.com/p/lilypond/issues/detail?id=2210 Ah. I'd been testing by running configur and must have accidentally run it from the source dir. Thanks. I'll delete it. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2210 in lilypond: Patch: Build: Top-level GNUmakefile
Comment #9 on issue 2210 by julien.r...@gmail.com: Patch: Build: Top-level GNUmakefile http://code.google.com/p/lilypond/issues/detail?id=2210 If that's the case then you'd better run `make distclean' as it suggests. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1183 in lilypond: @rcontrib{} from topdocs doesn't work
Updates:
Status: Fixed
Comment #2 on issue 1183 by julien.r...@gmail.com: @rcontrib{} from topdocs
doesn't work
http://code.google.com/p/lilypond/issues/detail?id=1183
As far as I can see the topdocs no longer link to the rest of the docs.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2245 in lilypond: wrong/inconsistent placement of lyrics under suspended notes
Status: Accepted
Owner:
Labels: Type-Enhancement Needs-design
New issue 2245 by janek.li...@gmail.com: wrong/inconsistent placement of
lyrics under suspended notes
http://code.google.com/p/lilypond/issues/detail?id=2245
When a lyric syllabe is attached to a chord with suspended notes, it is
aligned to the first note in input.
\version "2.15.26"
{ 2 s s }
\addlyrics { blah blah }
This is wrong, lyric placement should not depend on input order.
I think that the syllabe should be always aligned to the "main" notehead,
but i'm not 100% sure. It may look better when aligned to the stem in such
cases.
http://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00371.html
http://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00372.html
Attachments:
lyrics to suspended notes.png 4.8 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #12 on issue 2146 by lemzw...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 On my box, the fonts *are* in /usr/share/ghostscript/fonts. However, this is completely irrelevant, since we should set up something derived from NCSB_DIR, as discussed above. I'm actually surprised that you get proper Cyrillics. Have you looked into the pdfTeX log file and actually checked that the font hasn't been substituted with a different one? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2246 in lilypond: beaming in 3/4 - a setting to not beam 3 eights against the beat.
Status: Accepted
Owner:
CC: carl.d.s...@gmail.com
Labels: Type-Enhancement
New issue 2246 by janek.li...@gmail.com: beaming in 3/4 - a setting to not
beam 3 eights against the beat.
http://code.google.com/p/lilypond/issues/detail?id=2246
Take this fragment of music written in 3/4 meter;
\relative c'' {
\time 3/4
a4. a8 a a
}
Current Lily beaming is: a4. a8[ a a]
Many engravings have beaming like this. However, beaming all 3 eights
together is against the beat, and Ted Ross explicitly forbids such
beaming: "Do not notate a 3/4 measure that looks like a measure in 6/8
time. Flag should be used instead of beam on all 3 notes". So Ross says
the beaming should be
a4. a8 a[ a]
This problem is quite similar to issue 2228. To fix 2228, a setting
strictBeatBeaming was introduced. I suggest we should use this setting
here, too.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: ERROR: Unable to find file "ice-9/boot-9.scm" in load path
Hi Damian,
1. Try running up lilypond with --loglevel=DEBUG, you'll see a lot more
about directories and the values for PATH etc.
2. Guile does *not* like lists being passed to it as GUILE_LOAD_PATH or
as -L prompt from the command line. It is absolutely not parsed like
the bash shell PATH. These get simply added to Guile's %load-path
variable, which is a scheme list.
3. LilyPond in its start-up code prepends its own root directory (let's
call it $LILYPOND_DATADIR) *and* $LILYPOND_DATADIR/scm to guile/scheme's
%load-path variable.
4. Run up the guile REPL from the command-line and type
guile> %load-path
You should see something like:
guile> %load-path
("/usr/local/share/guile/site" "/usr/local/share/guile/1.8"
"/usr/local/share/guile")
guile>
Cheers,
Ian
On 21/01/12 13:20, Damian leGassick wrote:
>
> On 21 Jan 2012, at 13:09, James wrote:
>
>> Hello,
>>
>> On 21 January 2012 12:55, m...@apollinemike.com
>> wrote:
>>> On Jan 21, 2012, at 1:47 PM, Damian leGassick wrote:
>>>
On 21 Jan 2012, at 12:08, Damian leGassick wrote:
> Hi
>
> I've seen this before and a search through the list says it was fixed in
> 2.14
>
> just upgraded to 2.15.26 and i get
>
> GNU LilyPond 2.15.26
> ERROR: In procedure primitive-load-path:
> ERROR: Unable to find file "ice-9/boot-9.scm" in load path
>
> is there a simple fix for this? I've tried adding the ice-9 folder to the
> PATH
>
> echo $PATH gives:
>
> /usr/local/git/bin:/usr/texbin:/usr/X11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin:/Applications/LilyPond.app/Contents/Resources/bin:/Applications/LilyPond.app/Contents/Resources/share/guile/1.8/ice-9:/usr/texbin
>
Ok - I get that it's I it's a guile error message
I added export
GUILE_LOAD_PATH="/Applications/LilyPond.app/Contents/Resources/share/guile/1.8"
to my .bash_profile
guile now launches in the terminal without the error, but lilypond still
won't
Damian (btw, Mac OSX10.6.8)
>>>
>>> Damian,
>>>
>>> I've cc'ed my response to the bug list - this should be opened up as an
>>> issue on the tracker.
>>> What would help a lot is if you added things to your PATH variable until
>>> LilyPond started working and let us know what the key addition(s) proved to
>>> be.
>>> Also, make sure to open a new terminal window every time you modify
>>> .bash_profile (I'm not assuming that you are not doing this, but I forget
>>> to do this all the time, so I figured it was worth saying).
>>>
>>
>> Also, and I had this same message on my Linux Box, and found it was to
>> do with the relation of where I ran the command and where the file I
>> am running LP on.
>>
>> So, for example if you use Terminal and cd *into* the same dir as the
>> .ly file do you get the same message?
>>
>>
>> --
>> --
>>
>> James
>
> James, you are correct - cd-ing into the directory works, thanks
> Mike - I tried adding everything I could think of (I'm not a guile expert!)
> but couldn't make progress beyond:
>
> export
> GUILE_LOAD_PATH="/Applications/LilyPond.app/Contents/Resources/share/guile/1.8"
>
> export
> GUILE_LOAD_PATH=$GUILE_LOAD_PATH:/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm
>
>
> which gives the error:
>
> GNU LilyPond 2.15.26
> /Applications/LilyPond.app/Contents/Resources/share/guile/1.8/srfi/srfi-1.scm:223:1:
> In procedure dynamic-link in expression (load-extension
> "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"):
> /Applications/LilyPond.app/Contents/Resources/share/guile/1.8/srfi/srfi-1.scm:223:1:
> file: "libguile-srfi-srfi-1-v-3", message: "file not found"
>
> Damian
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #13 on issue 2146 by philehol...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 In the pdfTeX logfile notation.log, which is produced by texi2pdf, there is no sign of any font substitution at all, AFAICS. Happy to zip it for you to check what's going on, if that would be useful. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2247 in lilypond: Patch: parser.yy: strip music-wrapper-music inside of EventChord
Status: New Owner: Labels: Type-Enhancement Patch-new New issue 2247 by d...@gnu.org: Patch: parser.yy: strip music-wrapper-music inside of EventChord http://code.google.com/p/lilypond/issues/detail?id=2247 parser.yy: strip music-wrapper-music inside of EventChord This makes things likework. Patch depends on the work of issue 2240 http://codereview.appspot.com/5561058 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
make doc problem
Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), which means 40' for a "make doc LANGS='fr' and about 2 hours for all languages, I now have to "make doc-clean" in order to view a corrected typo. I've tried a "touch masterfile.tely" before "make doc" but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2247 in lilypond: Patch: parser.yy: strip music-wrapper-music inside of EventChord
Updates: Status: Started Owner: d...@gnu.org Labels: -Patch-new Patch-waiting Blockedon: 2240 Comment #1 on issue 2247 by d...@gnu.org: Patch: parser.yy: strip music-wrapper-music inside of EventChord http://code.google.com/p/lilypond/issues/detail?id=2247 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2240 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Issue 2240: Patch: Don't wrap EventChord around rhythmic events by default. http://code.google.com/p/lilypond/issues/detail?id=2240 This issue is now blocking issue 2247. See http://code.google.com/p/lilypond/issues/detail?id=2247 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
- Original Message - From: "Jean-Charles Malahieude" To: "Lily Bugs" ; "lilypond-devel" ; "Julien Rioux" Sent: Sunday, January 22, 2012 6:19 PM Subject: make doc problem Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), which means 40' for a "make doc LANGS='fr' and about 2 hours for all languages, I now have to "make doc-clean" in order to view a corrected typo. I've tried a "touch masterfile.tely" before "make doc" but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
On 22/01/2012 1:19 PM, Jean-Charles Malahieude wrote: Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), which means 40' for a "make doc LANGS='fr' and about 2 hours for all languages, I now have to "make doc-clean" in order to view a corrected typo. I've tried a "touch masterfile.tely" before "make doc" but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles Hi Jean-Charles, I can't run -j, I have a single core. Can you please report more precisely why you can no longer use it? The second issue I have not seen. If I correct a typo in a file in Documentation then make doc will rebuild it. OK I should check Documentation/fr right now... Regards, Julien ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes I've hit a roadblock with issue 2125 which attempted to fix that make doc; make doc problem. With that patch, on my machine the second make doc reports `nothing to be done'. So it works on my machine but not yours and I haven't quite figured it out yet. Regards, Julien ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
- Original Message - From: "Julien Rioux" To: "Phil Holmes" Cc: "Jean-Charles Malahieude" ; "LilyPond Bugs" ; "LilyPond Devel" Sent: Sunday, January 22, 2012 6:35 PM Subject: Re: make doc problem On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes I've hit a roadblock with issue 2125 which attempted to fix that make doc; make doc problem. With that patch, on my machine the second make doc reports `nothing to be done'. So it works on my machine but not yours and I haven't quite figured it out yet. Regards, Julien Please shout if you want logfiles or testing. I can run tests fairly quickly if I've got my lily machine up and running. -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
On 22/01/2012 1:32 PM, Julien Rioux wrote: The second issue I have not seen. If I correct a typo in a file in Documentation then make doc will rebuild it. OK I should check Documentation/fr right now... When I edit Documentation/fr/essay/literature.itely and issue a make doc from within build/Documentation/fr then Documentation/fr/essay.tely is recompiled. I can see the result in Documentation/fr/out-www/essay/* and in Documentation/out-www/essay.fr.* [1] Please report in more details the problems that you encounter, e.g. which file are you modifying and how are you calling make. Thanks, Regards, Julien [1] Big side note: It doesn't work flawlessly: notation.tely and a bunch of other manuals are also recompiled when they shouldn't, since I didn't touch any of their source files. This problem I trace back to the CHAIN_RULE in make/ly-rules.make, which I didn't dare touch up to now. This rule states that web depends on usage depends on notation depends on... etc. so that only one instance of lilypond-book is running at once on any given manual. As a side-effect it means that manuals depend on each other when that isn't in fact the case. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
Le 22/01/2012 19:32, Julien Rioux disait : On 22/01/2012 1:19 PM, Jean-Charles Malahieude wrote: Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), [...] I can't run -j, I have a single core. Can you please report more precisely why you can no longer use it? I make a clean and let you now... -- Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and "make -j3 doc LANGS='fr'" File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows "Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond." -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and "make -j3 doc LANGS='fr'" File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows "Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond." -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien Done: 930dbeff8f5d31faa9654365c8ed84a30e489e83 Hope this fixes it for you as well. Thanks, Julien ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
Julien Rioux writes: > I can't run -j, I have a single core. This is factually incorrect. You can run -j just fine, but you can't expect much of a speedup. On a single-core machine, make -j 2 typically gives you a speedup of maybe 15% (given sufficient memory) since the CPU can keep busy on processing a second job when the other job is waiting for the disk to provide new input. More importantly, you'll get to see the same kind of problems that the true multi-core people experience when using -j. So very much recommended for testing. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #14 on issue 2146 by lemzw...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 Ok, I've tested what you suggest, and now I know that you are right and wrong at the same time :-) Making the font unknown to pdftex (as you've done with `/nodir/...') is a viable solution, since texinfo exclusively uses CMR fonts. Since it can't find the font, it doesn't try to merge or replace the font from the included PDF. [Please remember that we are trying to circumvent a bug in pdftex.] However, pdftex now *never* tries to merge this font! Look at the attached files, which is a slight variation of your test: It includes `BFEx.pdf' ten times. `BFtest1.texi' uses your solution, giving a PDF size of 105kByte. My solution `BFtest2.texi' needs only 49kByte! So I still think that it is best to fix this issue with a correct lilypond.map file. Attachments: BFimage.texi 20 bytes BFtest1.texi 681 bytes BFtest1.pdf 102 KB BFtest2.texi 703 bytes BFtest2.pdf 48.2 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
Le 22/01/2012 20:22, Julien Rioux disait : On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and "make -j3 doc LANGS='fr'" File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows "Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond." -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien Done: 930dbeff8f5d31faa9654365c8ed84a30e489e83 Hope this fixes it for you as well. Yes, many thanks! -- Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
On 22/01/2012 2:38 PM, David Kastrup wrote: Julien Rioux writes: I can't run -j, I have a single core. This is factually incorrect. You can run -j just fine, but you can't expect much of a speedup. On a single-core machine, make -j 2 typically gives you a speedup of maybe 15% (given sufficient memory) since the CPU can keep busy on processing a second job when the other job is waiting for the disk to provide new input. More importantly, you'll get to see the same kind of problems that the true multi-core people experience when using -j. So very much recommended for testing. Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. -- Julien ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #15 on issue 2146 by philehol...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 I agree in principle. The problem I have is that, on my vanilla lilypond-ubuntu installation - I don't appear to have the correct files. We need to deliver them if we're going to use them. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
Julien Rioux writes: > Thanks, you're quite right CPU is not the limiting factor for the > build. Disk access and usage of swap when compiling > input/regression/collated-files slows down the build to a crawl for > me. If it is really usage of swap: getting more memory will be by far the cheapest method of speeding up your computer much more than buying a faster CPU ever could. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #16 on issue 2146 by julien.r...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 The configure script looks for these files on your system. Does it not complain when it does not find them? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make doc problem
"Julien Rioux" wrote in message news:4f1c6a79.3040...@physics.utoronto.ca... On 22/01/2012 2:38 PM, David Kastrup wrote: Julien Rioux writes: I can't run -j, I have a single core. This is factually incorrect. You can run -j just fine, but you can't expect much of a speedup. On a single-core machine, make -j 2 typically gives you a speedup of maybe 15% (given sufficient memory) since the CPU can keep busy on processing a second job when the other job is waiting for the disk to provide new input. More importantly, you'll get to see the same kind of problems that the true multi-core people experience when using -j. So very much recommended for testing. Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. -- Julien As a general rule, CPU is very much the limiting factor on make and make doc. With my "single cpu" virtual machine on my Windows box, the CPU is stuck at 100%. With my multi-core Ubuntu box, most of the time all 8 CPUs run 100%, with memory never over 1.5 Gigs. This is using a fairly large SSD, but I'm 99% certain that, all other things being equal, CPU is king when building lily. -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #17 on issue 2146 by philehol...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 I think it finds the "wrong" ones - i.e. those delivered without the Cyrillic fonts. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1964 in lilypond: lilydev 2.0
Comment #18 on issue 1964 by janek.li...@gmail.com: lilydev 2.0 http://code.google.com/p/lilypond/issues/detail?id=1964 there's a nice addition mentioned in new git instructions (http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode215): adding this line export PS1="\u@\h \w\$(__git_ps1)$ " to hidden file ~/.bashrc results in currently checked-out branch name being displayed at command line prompt. It's quite useful and i think it would be good to have it in Lilydev by default. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2223 in lilypond: Regtest for lilypond-book are not running
Comment #5 on issue 2223 by jri...@lyx.org: Regtest for lilypond-book are not running http://code.google.com/p/lilypond/issues/detail?id=2223 Summary of problems with current regtests (if you would compile them by hand): suffix-lyxml: Fails, image '05/lily-f58ad554.pdf' not found. tex-twocolumn: Fails, image has full-page width. texinfo-language-detection: Suspicious, has the doctitle and texidoctitle popping up between the snippet's filename and the image of music and the string @lydoctitle. texinfo-musicxml-file-options: Suspicious, no visible difference compared to texinfo-musicxml-file (no options). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2226 in lilypond: Patch: Docs: Explain the difference between ritardando and rallentando
Updates: Labels: -Patch-new Comment #3 on issue 2226 by julien.r...@gmail.com: Patch: Docs: Explain the difference between ritardando and rallentando http://code.google.com/p/lilypond/issues/detail?id=2226 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2237 in lilypond: Patch: Fix spelling in input/regression/*.ly
Updates: Status: Verified Labels: -Patch-push Fixed_2_15_27 Comment #5 on issue 2237 by julien.r...@gmail.com: Patch: Fix spelling in input/regression/*.ly http://code.google.com/p/lilypond/issues/detail?id=2237 Some changes in log files appear in regtests after this. Would be nice to suppress them. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #18 on issue 2146 by lemzw...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 Ah, I haven't thought of this. You are right, this can happen. So we perhaps have to scan the (possibly binary) fonts directly and check whether they contain Cyrillic characters. Fortunately, this isn't too hard since the copyright note is always visible as plain text. It would be sufficient to scan for the word `Cyrillic' (in the /Notice string). To summarize: . Modify the configure.in code so that we always get NCSB_DIR variable, either given by the user or computed from the location found by fontconfig. . Use grep (which is already a prerequisite of building lilypond) to check for the string `Cyrillic' in all four fonts. Abort if this fails. . Construct a proper `lilypond.map' file which gets included in the `macros.texi' file. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
