Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: Okay, I could not resist, so here is something more capable. Thanks for not being more resistable. :-) (And for giving a nice illustration how easy it actually is to write a quick hacked-up GUI - I guess that'll be useful to me on many occasions in the future). It actually only gives you a Clone/Update button that makes sure that a local clone (hardcoded to $HOME/lilypond) is up-to-date, but at least it has a progress bar, and I verified that it works even on Windows (what with its ridiculous insistence to put everything into directories containing spaces). When I try that script, I end up with an empty directory (i.e., only the .git subdirectory is present). Running git status says that all the files in the source tree were deleted. I can thus recreate them by running git reset --hard HEAD. What's happening here? Thanks, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: omf in documentation
On Tue, Aug 11, 2009 at 12:51:18AM -0300, Han-Wen Nienhuys wrote: On Mon, Aug 10, 2009 at 10:19 PM, Graham Percivalgra...@percival-music.ca wrote: Are these for the Open Source Metadata Framework? http://www.ibiblio.org/osrt/omf/ Yes. Are they actually being used? If not, can I remove them? I can't remember. There is a script to generate the omf files, and the theory was that distributors could install them appropriately, so the lily docs would show up in centralized help systems. I think that has never happened, though. It looks like they exist in Documentation/out-www/, but not out-www/offline-root/ *shrug* I'm ok with ignoring them now. If anybody wants this in the future, they can see this (brief) discussion in the mailist, and it should be easy to send a patch that copies them into our dist tarball so that they can use them for whatever they want to use them for. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing autobeaming for 4/4 time
Carl
Yes, that looks good. Paraphrasing the beam settings, they say:
break beam at beats, but break 8th-note beams at 1/2, exactly what
Ross wants.
So these rules are fine, but they are not correctly implemented when
the final two beats have a 8 8 8 16 16 pattern. This is the bug
that has always existed, and can't be fixed by beaming rules using
the present time-step by time-step approach. It will need either a
longer look-ahead or retrospective modification of beams. I've no
idea whether either of these are feasible. That's what I meant when
I said earlier that this is a more fundamental problem.
Trevor
- Original Message -
From: Carl Sorensen c_soren...@byu.edu
To: Trevor Daniels t.dani...@treda.co.uk; Neil Puttock
n.putt...@gmail.com; Patrick McCarty pnor...@gmail.com
Cc: lilypond-devel lilypond-devel@gnu.org
Sent: Monday, August 10, 2009 11:25 PM
Subject: Re: Changing autobeaming for 4/4 time
OK, I've found a setting that works *pretty well*, with one bad
case:
\relative c'' {
\overrideBeamSettings #'Score #'(4 . 4) #'end
#'((* . (1 1 1 1))
((1 . 8) . (4 4)))
a8 a a a a a a a | % OK
\break
a16 a a8 a a
a a16 a a8 a | % OK now, was wrong, should be ...
a16[ a a8] a a
a[ a16 a] a8 a |
\break
a8 a a16 a a8
a a a a16 a | % wrong, should be ...
a8 a a16[ a a8]
a a a[ a16 a] |
\break
a8 a16 a a8 a16 a
a8 a16 a a8 a16 a | % OK now, was wrong, should be ...
a8[ a16 a] a8 a16 a
a8[ a16 a] a8 a16 a |
\break
a32 a a16 a a a a32 a a16 a
a a a32 a a16 a a a a32 a | % OK now, was wrong, should be ...
a32[ a a16 a a] a[ a32 a a16 a]
a[ a a32 a a16] a a a a32 a
}
I think I can fix this by tweaking with the START rule; it appears
to me
that what fails in measure 4 above is that the beam should be broken
at the
final beat because the beaming in the final beat contains a 1/16
beam, so
the 1/8 rule shouldn't apply. But we don't check for that at the
start of
the final beat; we only get that check at the end of the final beat.
I'll do some investigation and see if I can fix that.
But for now, I think this beaming rule for 4/4 time is the best I've
seen
yet. What do you think?
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB log always goes to linux-x86 ?
Op maandag 10-08-2009 om 21:01 uur [tijdzone -0700], schreef Patrick McCarty: `libguile-srfi-srfi-1-v-3.la' to a directory not ending in /home/lilypond/gub/target/freebsd-x86/build/guile-1.8.7/srfi/.libs make[3]: *** [install-libLTLIBRARIES] Error 1 I can reproduce this, but I am unable to discover a fix. In class Guile__linux__x86, it said def install (self): # with 1.8.7: libtool: cannot install directory not ending in... # after config.status is being re-run for building of libpath.h self.update_libtool () Guile.install (self) :-) I've moved this fix up to the main Guile class in master. Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi, On Tue, 11 Aug 2009, Maximilian Albert wrote: 2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: It actually only gives you a Clone/Update button that makes sure that a local clone (hardcoded to $HOME/lilypond) is up-to-date, but at least it has a progress bar, and I verified that it works even on Windows (what with its ridiculous insistence to put everything into directories containing spaces). When I try that script, I end up with an empty directory (i.e., only the .git subdirectory is present). Running git status says that all the files in the source tree were deleted. I can thus recreate them by running git reset --hard HEAD. What's happening here? It actually worked here, twice. But you have this wonderful output field in the GUI, what does it have to say? I imagine that it gave you some error message or some such (probably due to an older Git version that refuses to update the current 'master' branch -- which has no commit yet, though). So I would like to ask you two things: first, what was the error message (there must have been one), and second: could you change the git checkout -b master origin/master to git reset --hard origin/master git config branch.master.remote origin git config branch.master.merge refs/heads/master ? Thanks, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: It actually worked here, twice. But you have this wonderful output field in the GUI, what does it have to say? I imagine that it gave you some error message or some such (probably due to an older Git version that refuses to update the current 'master' branch -- which has no commit yet, though). Sorry, I should of course have posted the output in the first place: == Initialized empty Git repository in /home/username/lilypond/.git/ From git://repo.or.cz/lilypond * [new branch] master - origin/master warning: You appear to be on a branch yet to be born. warning: Forcing checkout of origin/master. Already on master Branch master set up to track remote branch refs/remotes/origin/master. == So it doesn't give an error, just a warning. But AFAIR I have seen this warning on my non-GUI-based checkouts, too, even though everything worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu 9.04 has to offer). So I would like to ask you two things: first, what was the error message (there must have been one), and second: could you change the git checkout -b master origin/master to git reset --hard origin/master git config branch.master.remote origin git config branch.master.merge refs/heads/master ? Still no luck. :-( The warning is gone, but the result is as before (directory is empty, 'git status' reports deleted files). Here is the output of the new script: == Initialized empty Git repository in /home/username/lilypond/.git/ From git://repo.or.cz/lilypond * [new branch] master - origin/master HEAD is now at 00c6cac Nitpick: ly:spanner-bound grob name slur - spanner. == Thanks for your help, Max P.S.: It would be nice to let the script print a short message when it's finished so that the user know when to stop waiting. ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: update from the git battlefield
Mark Polesky wrote Tuesday, August 11, 2009 12:25 AM I'm git-weary but still alive. Johannes spent *hours* debugging my problem, and eventually traced it to an undiscovered bug in gitk that only affects Microsoft Windows... Nice to have you operational again. Thanks Johannes! Can you say what the bug is? I use gitk all the time in Windows Vista and previously in Windows XP without any problems. Maybe I don't use the part of its functionality which is in error, or maybe my version is older (it doesn't want to tell me what version it is, but it came with git 1.5.4.2.1161.g1a6f0). But I'd sure like to avoid the bug :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Friday, August 07, 2009 2:49 PM
The generic approach has now been pushed to git
247f0b6d46fd8f3253a99f95a70ce14345daa5f9
There's a generic styledNoteHeads music function that applies a
note style
to music whether or not it's in a chord construct.
deadNotes and palmMute have been redefined to use the generic
functions
instead of a specific function.
I've finally got around to looking at this.
It seems the \deadNote function works fine,
but \deadNotesOn and \deadNotesOff do not.
I had a quick look at their definitions and
I think they should be
deadNotesOn =
#(define-music-function (parser location) ()
(override-head-style '(TabNoteHead NoteHead) 'cross))
rather than
deadNotesOn = {
#(override-head-style '(TabNoteHead NoteHead) 'cross)
}
since they do modify the music stream. Anyway,
after making that change it works - except it
seems not to work if placed before the very
first note in a score. Not sure why this is.
Could you check this out please, as I'm not
very sure of my ground here. Thanks.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi,
On Tue, 11 Aug 2009, Maximilian Albert wrote:
2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de:
It actually worked here, twice.
But you have this wonderful output field in the GUI, what does it have to
say? I imagine that it gave you some error message or some such (probably
due to an older Git version that refuses to update the current 'master'
branch -- which has no commit yet, though).
Sorry, I should of course have posted the output in the first place:
==
Initialized empty Git repository in /home/username/lilypond/.git/
From git://repo.or.cz/lilypond
* [new branch] master - origin/master
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of origin/master.
Already on master
Branch master set up to track remote branch refs/remotes/origin/master.
==
So it doesn't give an error, just a warning. But AFAIR I have seen this
warning on my non-GUI-based checkouts, too, even though everything
worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu
9.04 has to offer).
Ouch, I think I know what happened. Git used your _current_ working
directory as work tree. So you have some stray LilyPond files lying
around somewhere.
So I would like to ask you two things: first, what was the error message
(there must have been one), and second: could you change the
git checkout -b master origin/master
to
git reset --hard origin/master
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
?
Still no luck. :-( The warning is gone, but the result is as before
(directory is empty, 'git status' reports deleted files). Here is the
output of the new script:
==
Initialized empty Git repository in /home/username/lilypond/.git/
From git://repo.or.cz/lilypond
* [new branch] master - origin/master
HEAD is now at 00c6cac Nitpick: ly:spanner-bound grob name slur - spanner.
==
I do not know why it worked here, but you may need to add the command line
option --work-tree=$lily_dir/.. in the git function.
P.S.: It would be nice to let the script print a short message when
it's finished so that the user know when to stop waiting. ;-)
Heh. You can easily add that by refactoring the write_to_output function
thusly:
proc write_to_output {string} {
.output.text insert insert $string
.output.text see end
}
proc write_file_to_output {f} {
if {[eof $f]} {
global git_command
fconfigure $f -blocking true
if {[catch {close $f} err]} {
tk_messageBox -type ok -message Git aborted: $err
}
unset git_command
} else {
write_to_output [read $f 24]
}
}
You need to replace the callback with write_file_to_output, of course, and
at the end of the Git commands, you can say
write_to_output Done.
Ciao,
Dscho
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fails to rebuild, configure issues?
Odd behavior: if I rm -rf target/*/build/lilypond*, target/*/src/lilypond*, target/*/status/lilypond*, and target/*/installer/lilypond* (I'm trying to be safe), it seems to build ok. But if I try to rebuild with make lilypond, or if I forget to clean one directory, it fails. I thought that I'd seen error messages about needing to remove config.hh, but this last time that I cleaned things out and generated the error, there's no such message. Here's the error from target/linux-x86/log/build.log: *** Stage: compile (lilypond, darwin-ppc) invoking cd /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master make -j1 TARGET_PYTHON=/usr/bin/env python configure.in and/or stepmake/aclocal.m4 changed! Please regenerate configure with autogen.sh. make: *** [/home/lilypond/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-master/configure] Error 1 Command barfed: cd /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master make -j1 TARGET_PYTHON=/usr/bin/env python Traceback (most recent call last): ... Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: update from the git battlefield
Hi, On Tue, 11 Aug 2009, Trevor Daniels wrote: Mark Polesky wrote Tuesday, August 11, 2009 12:25 AM I'm git-weary but still alive. Johannes spent *hours* debugging my problem, and eventually traced it to an undiscovered bug in gitk that only affects Microsoft Windows... Nice to have you operational again. Thanks Johannes! Can you say what the bug is? I use gitk all the time in Windows Vista and previously in Windows XP without any problems. Maybe I don't use the part of its functionality which is in error, or maybe my version is older (it doesn't want to tell me what version it is, but it came with git 1.5.4.2.1161.g1a6f0). But I'd sure like to avoid the bug :) The problem is the limitation of the command line on Windows. Mark has a shallow clone, and it was kept shallow all the time, basically accumulating commits that are not really parent-less, but in this repository, they are. So gitk was calling git with a way-too-long command line, and it just died, taking gitk with it. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
On Tue, Aug 11, 2009 at 6:45 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: So it doesn't give an error, just a warning. But AFAIR I have seen this warning on my non-GUI-based checkouts, too, even though everything worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu 9.04 has to offer). Ouch, I think I know what happened. Git used your _current_ working directory as work tree. So you have some stray LilyPond files lying around somewhere. Aha! That's why I found a bunch of lily files in my $HOME/bin/ directory! I found a lily/ directory inadvertently last night, and now that I look, there's the Documentation, ly, make, stepmake, etc. So the files did get downloaded, just not where expected. Easily fixed... Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
On Tue, Aug 11, 2009 at 7:00 AM, Jonathan Kulp jonlancek...@gmail.comwrote:
On Tue, Aug 11, 2009 at 6:45 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
So it doesn't give an error, just a warning. But AFAIR I have seen this
warning on my non-GUI-based checkouts, too, even though everything
worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu
9.04 has to offer).
Ouch, I think I know what happened. Git used your _current_ working
directory as work tree. So you have some stray LilyPond files lying
around somewhere.
Aha! That's why I found a bunch of lily files in my $HOME/bin/ directory! I
found a lily/ directory inadvertently last night, and now that I look,
there's the Documentation, ly, make, stepmake, etc. So the files did get
downloaded, just not where expected. Easily fixed...
Success!
I chose an amateurish brute-force method but it worked. Here's my revised
update_lilypond function:
proc update_lilypond {} {
global lily_dir
if {![file exists $lily_dir]} {
file mkdir $lily_dir
cd $lily_dir ; git init
git config core.bare false
cd $lily_dir ; git remote add -t master \
origin git://repo.or.cz/lilypond.git
cd $lily_dir ; git fetch --depth 1
cd $lily_dir ; git checkout -b master origin/master
} else {
cd $lily_dir ; git pull
}
}
It's possible that the first cd $lily_dir would suffice but I wanted to be
sure without having to experiment. I know that in some circumstances the
next lines of scripts or makefiles the succeeding lines are run in the
working dir rather than the target dir.
Thanks for the cool script, Johannes. :)
Jon
--
Jonathan Kulp
http://www.jonathankulp.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fails to rebuild, configure issues?
Le mardi 11 août 2009 à 04:46 -0700, Graham Percival a écrit : Odd behavior: if I rm -rf target/*/build/lilypond*, target/*/src/lilypond*, target/*/status/lilypond*, and target/*/installer/lilypond* (I'm trying to be safe), it seems to build ok. But if I try to rebuild with make lilypond, or if I forget to clean one directory, it fails. I thought that I'd seen error messages about needing to remove config.hh, but this last time that I cleaned things out and generated the error, there's no such message. This is certainly because GUB uses smart-autogen.sh, which runs autogen.sh if only if stepmake/aclocal MD5 sums have changed since last smart-autogen.sh invocation. The problem is, Werner requested that make checks that configure script has a more recent modification time than configure.in and stepmake/aclocal.m4, which may happen even if MD5 sums of these files -- e.g. mtime of source files checked out from Git is the time when the file was last checked out or updated after merging/fast-forwarding/pulling. I'm reverting the change I made. To sum up, smart-autogen.sh is too smart for make, and this is one more reason to switch the build system to SCons, which Jan almost convinced me to do. John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi, On Tue, 11 Aug 2009, Jonathan Kulp wrote: On Tue, Aug 11, 2009 at 4:12 AM, Maximilian Albert maximilian.alb...@googlemail.com wrote: P.S.: It would be nice to let the script print a short message when it's finished so that the user know when to stop waiting. ;-) I had the same experience as Max when I tried it on Fedora 11. The only thing in there was the .git/ directory. I like the button, though. :) I pushed a new version to git://repo.or.cz/lilypond/dscho.git. You can download it directly here: http://repo.or.cz/w/lilypond/dscho.git?a=blob_plain;f=lilycontrib.tcl;hb=lilycontrib Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi, On Tue, 11 Aug 2009, Jonathan Kulp wrote: On Tue, Aug 11, 2009 at 6:45 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: So it doesn't give an error, just a warning. But AFAIR I have seen this warning on my non-GUI-based checkouts, too, even though everything worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu 9.04 has to offer). Ouch, I think I know what happened. Git used your _current_ working directory as work tree. So you have some stray LilyPond files lying around somewhere. Aha! That's why I found a bunch of lily files in my $HOME/bin/ directory! I found a lily/ directory inadvertently last night, and now that I look, there's the Documentation, ly, make, stepmake, etc. So the files did get downloaded, just not where expected. Easily fixed... Well, not as easily as I thought: git pull does not like the work-tree option. But it is fixed in the current lilycontrib script. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi,
On Tue, 11 Aug 2009, Jonathan Kulp wrote:
On Tue, Aug 11, 2009 at 7:00 AM, Jonathan Kulp jonlancek...@gmail.comwrote:
On Tue, Aug 11, 2009 at 6:45 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
So it doesn't give an error, just a warning. But AFAIR I have seen this
warning on my non-GUI-based checkouts, too, even though everything
worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu
9.04 has to offer).
Ouch, I think I know what happened. Git used your _current_ working
directory as work tree. So you have some stray LilyPond files lying
around somewhere.
Aha! That's why I found a bunch of lily files in my $HOME/bin/ directory! I
found a lily/ directory inadvertently last night, and now that I look,
there's the Documentation, ly, make, stepmake, etc. So the files did get
downloaded, just not where expected. Easily fixed...
Success!
I chose an amateurish brute-force method but it worked. Here's my revised
update_lilypond function:
proc update_lilypond {} {
global lily_dir
if {![file exists $lily_dir]} {
file mkdir $lily_dir
cd $lily_dir ; git init
git config core.bare false
cd $lily_dir ; git remote add -t master \
origin git://repo.or.cz/lilypond.git
cd $lily_dir ; git fetch --depth 1
cd $lily_dir ; git checkout -b master origin/master
} else {
cd $lily_dir ; git pull
}
}
It's possible that the first cd $lily_dir would suffice but I wanted to be
sure without having to experiment. I know that in some circumstances the
next lines of scripts or makefiles the succeeding lines are run in the
working dir rather than the target dir.
Thanks for the cool script, Johannes. :)
Heh.
I did something similar, except I used --work-tree and therefore could do
it in one place. However, I needed the file mkdir, too, and I had to
change the git pull to a git fetch and git merge combo. This is
something I wanted to do anyway, as I want to have a checkbox that says
whether you want to rebase all the time, or rather merge.
It probably should use the 'branch.name.rebase' config variable, just
like Git does itself.
Ciao,
Dscho
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi Johannes,
I pushed a new version to git://repo.or.cz/lilypond/dscho.git. You can
download it directly here:
http://repo.or.cz/w/lilypond/dscho.git?a=blob_plain;f=lilycontrib.tcl;hb=lilycontrib
Cool, works like a charm now. Thanks a lot!
One minor comment: For new contributors with no experience in git (or
version control in general) it may seem as though nothing happens
after pressing the button. Thus I'd suggest to add two messages to
indicate that the process was started, along the lines of:
==
proc update_lilypond {} {
global lily_dir
if {![file exists $lily_dir]} {
write_to_output Starting to clone LilyPond repository (this
can take some time) ...\n
file mkdir $lily_dir
git init
git config core.bare false
git remote add -t master \
origin git://repo.or.cz/lilypond.git
git fetch --depth 1
git reset --hard origin/master
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
.update configure -text Update LilyPond
} else {
write_to_output Starting to update LilyPond repository ...\n
git fetch origin
git merge origin/master
}
write_to_output Done.\n
}
==
Cheers,
Max
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
make doc failure
Hi Neil,
It looks like a grob suicides in Documentation/snippets/incipit.ly, as I
get the backtrace below when issuing 'make doc'. I suspect a check for
SCM_UNSPECIFIED should be added either in the override in incipit.ly or
in system-start-text::calc-y-offset definition, unless there should be
no grob suicide, but then I have no clue.
Backtrace:
In unknown file:
?: 0* [lilypond-main #]
In /home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily.scm:
660: 1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...)
660: 2* [lilypond-all #]
674: 3 (let* ((failed #) (separate-logs #) (ping-log #) ...)
(gc) ...)
685: 4* [for-each #procedure #f # #]
In unknown file:
?: 5* [#procedure #f (x) 06/lily-d5b250b2.ly]
In /home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily.scm:
687: 6* (let* (# # #) (if separate-logs #) (if ping-log #) ...)
698: 7* [lilypond-file #procedure #f (key failed-file)
06/lily-d5b250b2.ly]
725: 8 [catch ly-file-failed #procedure #f () #procedure #f (x .
args)]
In unknown file:
?: 9* [#procedure #f ()]
In /home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily.scm:
726: 10* [ly:parse-file 06/lily-d5b250b2.ly]
In /home/lilydev/git/lily/master/out/share/lilypond/current/ly/init.ly:
40: 11* (let* ((book-handler #)) (cond (# #) (# #)))
43: 12 (cond (# #) (# #))
In
/home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily-library.scm:
...
156: 13 [ly:book-process-to-systems #Book # Output_def ...]
In unknown file:
?: 14* [ly:axis-group-interface::height #Grob System ]
?: 15* [#procedure #f (grob) #Grob Spanner ]
In string:
5: 16* [+ 4 {#unspecified}]
string:5:22: In procedure + in expression (+ 4
(system-start-text::calc-y-offset grob)):
string:5:22: Wrong type: #unspecified
--
John Mandereau john.mander...@gmail.com
signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi,
On Tue, 11 Aug 2009, Maximilian Albert wrote:
I pushed a new version to git://repo.or.cz/lilypond/dscho.git. You
can download it directly here:
http://repo.or.cz/w/lilypond/dscho.git?a=blob_plain;f=lilycontrib.tcl;hb=lilycontrib
Cool, works like a charm now. Thanks a lot!
I actually had to change the --work-tree things, since it is utter
garbage. I _know_ why I was opposed to its inclusion.
One minor comment: For new contributors with no experience in git (or
version control in general) it may seem as though nothing happens after
pressing the button. Thus I'd suggest to add two messages to indicate
that the process was started, along the lines of:
==
proc update_lilypond {} {
global lily_dir
if {![file exists $lily_dir]} {
write_to_output Starting to clone LilyPond repository (this
can take some time) ...\n
file mkdir $lily_dir
git init
git config core.bare false
git remote add -t master \
origin git://repo.or.cz/lilypond.git
git fetch --depth 1
git reset --hard origin/master
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
.update configure -text Update LilyPond
} else {
write_to_output Starting to update LilyPond repository ...\n
git fetch origin
git merge origin/master
}
write_to_output Done.\n
}
==
I added two shorter notices, and I also set the busy cursor now.
Ciao,
Dscho
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: I actually had to change the --work-tree things, since it is utter garbage. I _know_ why I was opposed to its inclusion. [..] I added two shorter notices, and I also set the busy cursor now. Hehe, sorry for complaining again. But now the script aborts with an error about the missing $lily_dir directory. When I manually create it, the script starts and shows the Update button, but upon pressing the button the script complains that the directory is not a git repository (obviously ...). Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Re: feature-request / doc-actualization (right-margin)
Hi all,
here is the first draft of a patch concerning the margin settings for
review. (I would like to upload it on Rietveld but I don't know how)
The goals are:
- make default margin settings accessible from *.ly stuff (now in
paper-defaults-init.ly)
- set line-width automatically depending on margin settings
- calculate missing values from given values (left-margin, right-margin,
line-width)
Cheers,
Michael
From 9778370158e39bfe9e0a0015e234adcf1cab7e3e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?= xmichae...@web.de
Date: Tue, 11 Aug 2009 18:01:01 +0200
Subject: [PATCH] Implement new handling for margin and line-width settings.
---
lily/include/output-def.hh |3 +-
lily/output-def-scheme.cc | 13 +++
lily/output-def.cc | 76
ly/paper-defaults-init.ly |4 ++
scm/framework-ps.scm |7 ++--
scm/page.scm | 15 +++-
scm/paper.scm | 14 ++--
scm/titling.scm|6 ++--
8 files changed, 112 insertions(+), 26 deletions(-)
diff --git a/lily/include/output-def.hh b/lily/include/output-def.hh
index b683cc6..1d2b056 100644
--- a/lily/include/output-def.hh
+++ b/lily/include/output-def.hh
@@ -59,12 +59,13 @@ public:
SCM lookup_variable (SCM sym) const;
void set_variable (SCM sym, SCM val);
Real get_dimension (SCM symbol) const;
+ void normalize ();
};
SCM get_font_table (Output_def *def);
void assign_context_def (Output_def *m, SCM transdef);
SCM find_context_def (Output_def const *m, SCM name);
-Interval line_dimensions_int (Output_def*def, int);
+Interval line_dimensions_int (Output_def *def, int);
Font_metric *select_encoded_font (Output_def *layout, SCM chain);
diff --git a/lily/output-def-scheme.cc b/lily/output-def-scheme.cc
index 73a8048..7616e05 100644
--- a/lily/output-def-scheme.cc
+++ b/lily/output-def-scheme.cc
@@ -142,6 +142,19 @@ LY_DEFINE (ly_paper_get_number, ly:paper-get-number,
return scm_from_double (layout-get_dimension (sym));
}
+LY_DEFINE (ly_paper_params_normalize, ly:paper-params-normalize,
+ 1, 0, 0, (SCM def),
+ Checks whether @code{left-margin}, @code{right-margin} and @code{line-width)
+ are set in output definition @var{def}, add missing values when needed and return the completed output-def.
+ Additionately, check if those values are consistent, otherwise print an error.)
+{
+ LY_ASSERT_SMOB (Output_def, def, 1);
+ Output_def *paper = unsmob_output_def (def);
+ Output_def *newpaper = paper-clone ();
+ newpaper-normalize ();
+ return newpaper-unprotect ();
+}
+
LY_DEFINE (ly_paper_fonts, ly:paper-fonts,
1, 0, 0, (SCM def),
Return a list containing the fonts from output definition
diff --git a/lily/output-def.cc b/lily/output-def.cc
index f9fbda9..91d3763 100644
--- a/lily/output-def.cc
+++ b/lily/output-def.cc
@@ -11,6 +11,7 @@
#include context-def.hh
#include file-path.hh
#include global-context.hh
+#include international.hh
#include interval.hh
#include main.hh
#include output-def.hh
@@ -128,12 +129,87 @@ Output_def::set_variable (SCM sym, SCM val)
scm_module_define (scope_, sym, val);
}
+void
+Output_def::normalize ()
+{
+ Real paper_width = scm_to_double (lookup_variable (ly_symbol2scm (paper-width)));
+
+ Real left_margin;
+ Real left_margin_default = scm_to_double (lookup_variable (ly_symbol2scm (left-margin-default)));
+ SCM lmargin = lookup_variable (ly_symbol2scm (left-margin));
+
+ Real right_margin;
+ Real right_margin_default = scm_to_double (lookup_variable (ly_symbol2scm (right-margin-default)));
+ SCM rmargin = lookup_variable (ly_symbol2scm (right-margin));
+
+ Real line_width;
+ SCM lwidth = lookup_variable (ly_symbol2scm (line-width));
+
+ // Otherwise we would break such things like \score markups which inherit margins from global paper block
+ if ((lookup_variable (ly_symbol2scm (is-layout)) == SCM_BOOL_T) (lwidth != SCM_UNDEFINED)) return;
+
+ if (lwidth != SCM_UNDEFINED)
+{
+ line_width = scm_to_double (lwidth);
+ if (lmargin != SCM_UNDEFINED)
+{
+ left_margin = scm_to_double (lmargin);
+ right_margin = ((rmargin != SCM_UNDEFINED) ? scm_to_double(rmargin) : (paper_width - line_width - left_margin));
+}
+ else if (rmargin != SCM_UNDEFINED)
+{
+ right_margin = scm_to_double (rmargin);
+ left_margin = paper_width - line_width - right_margin;
+}
+else // Vertically center systems if only line-width is given. TODO: Tweakable
+ {
+left_margin = (paper_width - line_width) / 2;
+right_margin = left_margin;
+ }
+}
+ else
+{
+ left_margin = ((lmargin != SCM_UNDEFINED) ? scm_to_double(lmargin) : left_margin_default);
+ right_margin = ((rmargin != SCM_UNDEFINED) ? scm_to_double(rmargin) : right_margin_default);
+ line_width = paper_width -
Re: lilycontrib.tcl, was Re: the r in git pull -r
Hi, On Wed, 12 Aug 2009, Maximilian Albert wrote: 2009/8/11 Johannes Schindelin johannes.schinde...@gmx.de: I actually had to change the --work-tree things, since it is utter garbage. I _know_ why I was opposed to its inclusion. [..] I added two shorter notices, and I also set the busy cursor now. Hehe, sorry for complaining again. But now the script aborts with an error about the missing $lily_dir directory. When I manually create it, the script starts and shows the Update button, but upon pressing the button the script complains that the directory is not a git repository (obviously ...). Fixed and pushed. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
Michael Käppler wrote: here is the first draft of a patch concerning the margin settings for review. (I would like to upload it on Rietveld but I don't know how) See CG 8.7.7 Post patch for comments: http://kainhofer.com/~lilypond/Documentation/contributor/Adding-or-modifying-features.html - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: headers and footers with new vertical layout engine
Regarding your Top context: why do you override VerticalAxisGroup
#'Y-extent = ##f? This is likely to confuse the layout algorithm
even after the bug I mentioned is fixed.
This was necessary for the old vertical layout engine -- at least it
served me well since a few years. I'll test what happens if I remove
it.
It seems I really no longer need it. However, there are still
formatting problems, as given in the example below. See attached
image.
Werner
==
\version 2.13.4
\paper {
bookTitleMarkup = book title - book title - book title
}
\score {
\new Top {
\override VerticalAxisGroup #'staff-affinity = #DOWN
s1
\mark \default s1^\markup { q }
}
\new Staff {
R1*2
}
\layout {
\context {
\Score
\accepts Top
}
\context {
\name Top
\alias Staff
\type Engraver_group
\consists Output_property_engraver
\consists Bar_engraver
\consists Skip_event_swallow_translator
\consists Script_engraver
\consists Text_engraver
\consists Axis_group_engraver
\override BarLine #'transparent = ##t
}
}
}
inline: clash.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Now that I'm a pusher again, I'm trying to return to unfinished projects. I'm looking again at the pad-markup-pad-around conversion and I have a question. I remember discussing this before, but I couldn't find it in the archives. When grepping for pad-markup, two hits are from translated docs. Do I just silently modify them, or do I need to notify the translators? Skimming through CG 3.7.4, it mentions running make check-translation... can I do that on Windows? And do I need to update documentation PO for such a small change? Sorry if these are annoying questions. If the answers are simple, maybe a short node could be added to CG 3.4 Documentation policy. Something like Updating translations. I don't want to accidentally cause trouble, I guess. Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: update from the git battlefield
Johannes Schindelin wrote Tuesday, August 11, 2009 12:51 PM On Tue, 11 Aug 2009, Trevor Daniels wrote: Mark Polesky wrote Tuesday, August 11, 2009 12:25 AM I'm git-weary but still alive. Johannes spent *hours* debugging my problem, and eventually traced it to an undiscovered bug in gitk that only affects Microsoft Windows... Nice to have you operational again. Thanks Johannes! Can you say what the bug is? I use gitk all the time in Windows Vista and previously in Windows XP without any problems. Maybe I don't use the part of its functionality which is in error, or maybe my version is older (it doesn't want to tell me what version it is, but it came with git 1.5.4.2.1161.g1a6f0). But I'd sure like to avoid the bug :) The problem is the limitation of the command line on Windows. Mark has a shallow clone, and it was kept shallow all the time, basically accumulating commits that are not really parent-less, but in this repository, they are. So gitk was calling git with a way-too-long command line, and it just died, taking gitk with it. That explains why I don't see the problem - I have a full repo. Does that mean shallow clones are inadvisable on Windows? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: update from the git battlefield
Trevor Daniels wrote: Does that mean shallow clones are inadvisable on Windows? I'll let Johannes confirm, but I think that shallow clones should be fine on Windows now. I got the sense that he killed the beast last night. It was actually kind of exciting. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure
Le mardi 11 août 2009 à 15:44 +0200, John Mandereau a écrit : It looks like a grob suicides in Documentation/snippets/incipit.ly, as I get the backtrace below when issuing 'make doc'. I suspect a check for SCM_UNSPECIFIED should be added either in the override in incipit.ly or in system-start-text::calc-y-offset definition, unless there should be no grob suicide, but then I have no clue. Getting the Y-offset of InstrumentName seems to be really needed in this particular snippet; I'll probably push the dirty fix below to be able to complete the docs build (plus a FIXME in the texidoc) until this snippet is really fixed. diff --git a/Documentation/snippets/incipit.ly b/Documentation/snippets/incipit.ly index 3501ce2..df6d54b 100644 --- a/Documentation/snippets/incipit.ly +++ b/Documentation/snippets/incipit.ly @@ -29,7 +29,12 @@ incipit = \once \override Staff.InstrumentName #'self-alignment-Y = #UP \once \override Staff.InstrumentName #'Y-offset = #(lambda (grob) - (+ 4 (system-start-text::calc-y-offset grob))) +(let ((y-offset (system-start-text::calc-y-offset grob))) + (if (number? y-offset) +(+ 4 y-offset) +(begin + (ly:warning grob committed suicide: ~a grob) + 4 \once \override Staff.InstrumentName #'padding = #0.3 \once \override Staff.InstrumentName #'stencil = #(lambda (grob) -- John Mandereau john.mander...@gmail.com signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond concept glossary?
My concept glossary idea is now called a technical glossary. I thought the name was fine when it was suggested, but now I'm realizing something -- I'd also like it to list terms that are not specifically dealing with LilyPond *internals*. Such as: the archives the LSR the tracker Rietveld Savannah These include words in the LP vernacular. So when someone comes across one of these terms in the archives for example, they'll have a place to look up the definition. I believe that a central location for such jargon definitions will be very valuable. If they don't fit in a technical glossary than we should change the name of the glossary. Because I don't expect that anyone is in favor of adding yet another appendix? Although an argument could be made for compartmentalizing the resources... Thoughts? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure
2009/8/11 John Mandereau john.mander...@gmail.com: Getting the Y-offset of InstrumentName seems to be really needed in this particular snippet; I'll probably push the dirty fix below to be able to complete the docs build (plus a FIXME in the texidoc) until this snippet is really fixed. Sorry for the delay, John; if you can wait about ten minutes or so, I'll have a patch ready. I'll deal with the snippets separately, since I need to work out why their positioning has changed since I pushed the original patch (I think it's something to do with Joe's removal of minimum-Y-extent). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Han-Wen Nienhuys wrote: They were an in-crowd joke at some point, but I think the joke has lasted long enough. I approve of changes that bring regularity in this file naming scheme. Then I propose the following Dutch-English changes: feta-banier feta-flags feta-beugel feta-braces feta-bolletjes feta-noteheads feta-din-code feta-dynamics feta-eindelijk feta-rests feta-haak feta-brackettips feta-klef feta-clefs feta-nummer-codefeta-numbers feta-pendaalfeta-pedal feta-puntje feta-dots feta-schriftfeta-scripts feta-slag feta-trills feta-toevallig feta-accidentals I also propose changing the following for fet_begingroup symmetry: feta-arrow feta-arrowheads paremsan-heads parmesan-noteheads These two would remain unchanged: feta-accordion feta-accordion feta-timesigfeta-timesig Comments? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Tue, Aug 11, 2009 at 3:47 PM, Mark Poleskymarkpole...@yahoo.com wrote:
They were an in-crowd joke at some point, but I think the joke
has lasted long enough. I approve of changes that bring
regularity in this file naming scheme.
Then I propose the following Dutch-English changes:
feta-banier feta-flags
feta-beugel feta-braces
feta-bolletjes feta-noteheads
feta-din-code feta-dynamics
We had the -code files as a contrast to the feta-din{NUMBER}, which
included the -code ones.
feta-eindelijk feta-rests
feta-haak feta-brackettips
feta-klef feta-clefs
feta-nummer-code feta-numbers
feta-pendaal feta-pedal
be consistent with plural vs singular.
feta-puntje feta-dots
feta-schrift feta-scripts
feta-slag feta-trills
feta-toevallig feta-accidentals
I also propose changing the following for fet_begingroup symmetry:
feta-arrow feta-arrowheads
paremsan-heads parmesan-noteheads
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
feta-pendaalfeta-pedal Perhaps feta-pedalsigns? feta-accordion feta-accordion feta-accordionsigns? feta-timesigfeta-timesig feta-timesignatures? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/11 Mark Polesky markpole...@yahoo.com: When grepping for pad-markup, two hits are from translated docs. Do I just silently modify them, or do I need to notify the translators? Modifying them is OK, as long as you don't change any non-snippet documentation (see CG 8.7.3, `Write documentation') You could run update-snippets.py after amending the corresponding snippet in the english docs, but it's probably simpler just to edit the files manually (you'll have to change the index entries anyway). Skimming through CG 3.7.4, it mentions running make check-translation... can I do that on Windows? And do I need to update documentation PO for such a small change? None of this is necessary (or desirable). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Yet another doc build failure (gs)
Hi guys, Am I the only one who sometimes hits Ghostscript failure below? I have a x86_64 Fedora 11 box, I previously used a post-8.64 Git snapshot of Ghostscript, which I just replaced with released version 8.70 (all self-compiled); I got this failure with post-8.64, and no longer got it with 8.70 until today, and I'm sure I removed post-8.64 binary from my system. I almost always compile docs (I was doing so when I got this failure) with -j3 and CPU_COUNT=3. I tried to compile a merge from lilypond/translation (312cb7622db744cfa6e5157cc6d88cf1a75b297a) and master (d4310174ad62cb54939e0cf61d28e458aca8c0e0). Tail of out/lybook-db/lilypond-multi-run-0.log Processing `/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.ly' Parsing... [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/init.ly [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/declarations-init.ly [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/markup-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/music-functions-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/toc-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/nederlands.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/drumpitch-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/chord-modifiers-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/script-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/scale-definitions-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/grace-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/midi-init.ly [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/performer-init.ly]] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/paper-defaults-init.ly [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/titling-init.ly]] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/engraver-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/dynamic-scripts-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/spanners-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/property-init.ly] [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/predefined-fretboards-init.ly]] [/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.ly [/home/lilydev/git/lily/master/out/share/lilypond/current/ly/lilypond-book-preamble.ly]] Interpreting music... elapsed time: 0.00 seconds Element count 29 (spanners 6) Preprocessing graphical objects... Grob count 51 Calculating line breaks... Drawing systems... Element count 36 [0] Writing /home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76-1.signature Layout output to `/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76-1.eps'... Converting to `/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76-1.pdf'... Invoking `gs -dNOSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76-1.pdf -c .setpdfwrite -f /home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76-1.eps'... Layout output to `/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.eps'... Converting to `/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.pdf'... Invoking `gs -dNOSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.pdf -c .setpdfwrite -f /home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.eps'... Converting to PNG...[/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.eps] pngtopnm: Unable to open file '/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.png.old' for reading. fopen() returns errno 2 (No such file or directory) 2/dev/null | pnmtopng -compression 9 2/dev/null /home/lilydev/git/lily/master/out/lybook-db/1c/lily-aaf1c94a.png'... Invoking `gs -dEPSCrop -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dNOPAUSE -sDEVICE=png16m -sOutputFile=/home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.png -r202 /home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.eps -c quit'... Invoking `pngtopnm /home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.png.old | pnmscale -reduce 2 2/dev/null | pnmtopng -compression 9 2/dev/null /home/lilydev/git/lily/master/out/lybook-db/74/lily-5f8c1b76.png'... GS exited with status: 256 EOF And I list below the output files for this snippet just after the crash (Documentation/notation/changing-defaults.itely:1218): [lily...@freemousse master]$ ls -lh out/lybook-db/74/lily-5f8c1b76* -rw-rw-r--. 1 lilydev lilydev 7,1K août 11 20:15 out/lybook-db/74/lily-5f8c1b76-1.eps -rw-rw-r--. 1 lilydev lilydev 8,5K août 11 20:15
Re: Guidelines for bounding boxes?
- Original Message
From: Han-Wen Nienhuys hanw...@gmail.com
To: Mark Polesky markpole...@yahoo.com
Cc: Werner LEMBERG w...@gnu.org; lilypond-devel@gnu.org
Sent: Tuesday, August 11, 2009 11:57:48 AM
Subject: Re: Guidelines for bounding boxes?
On Tue, Aug 11, 2009 at 3:47 PM, Mark Poleskywrote:
They were an in-crowd joke at some point, but I think the joke
has lasted long enough. I approve of changes that bring
regularity in this file naming scheme.
Then I propose the following Dutch-English changes:
feta-banier feta-flags
feta-beugel feta-braces
feta-bolletjes feta-noteheads
feta-din-code feta-dynamics
We had the -code files as a contrast to the feta-din{NUMBER}, which
included the -code ones.
Is there a problem with feta-dynamics? The last feta-din{NUMBER}
was removed 5 years ago:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=90fac
And feta-din was removed 4 years ago:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=c17ec
feta-eindelijk feta-rests
feta-haak feta-brackettips
feta-klef feta-clefs
feta-nummer-codefeta-numbers
feta-pendaalfeta-pedal
be consistent with plural vs singular.
I was just following the fet_begingroup strings.
Are you suggesting to change line 18 of feta-pendaal.mf from
fet_begingroup (pedal);
to
fet_begingroup (pedals);
?
I'm not opposed to it, but that would entail a lot of other
changes, too. And what about timesigs? accordions?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/11 John Mandereau john.mander...@gmail.com: Why don't you just convert-ly docs after having written the convert-ly rule and compiled convert-ly? Is this possible on Windows? (I've never tried it myself). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Le mardi 11 août 2009 à 21:01 +0100, Neil Puttock a écrit : 2009/8/11 John Mandereau john.mander...@gmail.com: Why don't you just convert-ly docs after having written the convert-ly rule and compiled convert-ly? Is this possible on Windows? (I've never tried it myself). It should be doable in theory, as convert-ly only needs Python. However, our current build system based on autoconf and make doesn't make it easy... yet another reason to switch to SCons. John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On 8/11/09 12:47 PM, Mark Polesky markpole...@yahoo.com wrote: Han-Wen Nienhuys wrote: They were an in-crowd joke at some point, but I think the joke has lasted long enough. I approve of changes that bring regularity in this file naming scheme. Then I propose the following Dutch-English changes: feta-banier feta-flags feta-beugel feta-braces feta-bolletjes feta-noteheads feta-din-code feta-dynamics feta-eindelijk feta-rests feta-haak feta-brackettips feta-klef feta-clefs feta-nummer-codefeta-numbers feta-pendaalfeta-pedal feta-puntje feta-dots feta-schriftfeta-scripts feta-slag feta-trills feta-toevallig feta-accidentals I also propose changing the following for fet_begingroup symmetry: feta-arrow feta-arrowheads paremsan-heads parmesan-noteheads These two would remain unchanged: feta-accordion feta-accordion feta-timesigfeta-timesig feta-timesig feta-timesignatures Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond concept glossary?
Mark Polesky wrote Tuesday, August 11, 2009 7:18 PM My concept glossary idea is now called a technical glossary. I thought the name was fine when it was suggested, but now I'm realizing something -- I'd also like it to list terms that are not specifically dealing with LilyPond *internals*. Such as: the archives the LSR the tracker Rietveld Savannah These include words in the LP vernacular. So when someone comes across one of these terms in the archives for example, they'll have a place to look up the definition. I believe that a central location for such jargon definitions will be very valuable. If they don't fit in a technical glossary than we should change the name of the glossary. Because I don't expect that anyone is in favor of adding yet another appendix? Although an argument could be made for compartmentalizing the resources... Thoughts? These terms don't really belong in the Notation Reference, do they? Perhaps we need to think again whether this appendix, whatever it is called, is intended to help users or developers. If the intention is solely to help new developers then the CG is the right place. I was hoping we could also include terms which helped users, hence I placed it in the NR, but I think some of these terms would stretch an NR appendix too far. One solution would be to have a Technical Glossary in the NR specifically for users and a Concepts Glossary in the CG specifically for developers. But I'm not even sure these terms are suitable for a glossary. They should really be explained in the main body of the AU (first two) and CG (last three). Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
InstrumentName misalignment in incipit snippets
Hi Joe, While fixing the last bug with the new instrument name code, I noticed that the instrument name positioning for both inicipit snippets (Documentation/snippets/incipit.ly and input/regression/incipit.ly) has changed for the worse. By a process of elimination, I've traced the change to your commit which removed all the overrides for minimum-Y-extent in engraver-init.ly. I've played around with the new spacing overrides, but the only thing that seems to correct the misalignment is to add a manual override for MensuralStaff.VerticalAxisGroup #'Y-extent. Can you suggest an alternative to this? Thanks, Neil attachment: incipit.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
Mark Polesky wrote: See CG 8.7.7 Post patch for comments: http://kainhofer.com/~lilypond/Documentation/contributor/Adding-or-modifying-features.htm Thanks, Mark. I've updated my git package and installed git-web but git-cl doesn't work for me. Doesn't it belong to the normal git package? Cheers, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
2009/8/11 Michael Käppler xmichae...@web.de: Thanks, Mark. I've updated my git package and installed git-web but git-cl doesn't work for me. Doesn't it belong to the normal git package? It's completely separate from git. The easiest way to get it is to clone the repository, git clone git://neugierig.org/git-cl.git then add symlinks for the scripts `git-cl' and `upload.py'. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
Neil Puttock wrote: It's completely separate from git. The easiest way to get it is to clone the repository, git clone git://neugierig.org/git-cl.git then add symlinks for the scripts `git-cl' and `upload.py'. Neil (or someone), can you add this info to the CG? Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
2009/8/11 Mark Polesky markpole...@yahoo.com: Neil (or someone), can you add this info to the CG? Sure, will do. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
2009/8/11 Michael Käppler xmichae...@web.de:
here is the first draft of a patch concerning the margin settings for
review.
Some comments:
+ Checks whether @code{left-margin}, @code{right-margin}
and @code{line-width)
{line-width}
This and the following docstring lines are too long.
+ Real paper_width = scm_to_double (lookup_variable (ly_symbol2scm
(paper-width)));
+ Real left_margin_default = scm_to_double (lookup_variable
(ly_symbol2scm (left-margin-default)));
+ Real right_margin_default = scm_to_double (lookup_variable
(ly_symbol2scm (right-margin-default)));
These are unsafe, since they return SCM_UNSPECIFIED instead of a Real
if the paper variables aren't defined; using robust_scm2double () here
will ensure a default is returned.
You can see the consequences of variable lookup failure by running
bookparts.ly
(http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=input/regression/bookparts.ly;h=a814fb5e072911540ecf2ab44a7b7b09dae61835;hb=HEAD).
This snippet also fails to get a sane value for paper-height in
layout-page-init.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
Neil Puttock wrote: This and the following docstring lines are too long. Is there a common line length for docstrings? This should also be mentioned in the CG, I think. + Real paper_width = scm_to_double (lookup_variable (ly_symbol2scm (paper-width))); + Real left_margin_default = scm_to_double (lookup_variable (ly_symbol2scm (left-margin-default))); + Real right_margin_default = scm_to_double (lookup_variable (ly_symbol2scm (right-margin-default))); These are unsafe, since they return SCM_UNSPECIFIED instead of a Real if the paper variables aren't defined; using robust_scm2double () here will ensure a default is returned. You can see the consequences of variable lookup failure by running bookparts.ly (http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=input/regression/bookparts.ly;h=a814fb5e072911540ecf2ab44a7b7b09dae61835;hb=HEAD). This snippet also fails to get a sane value for paper-height in layout-page-init. Ok, thanks, I will have a closer look tomorrow. Cheers, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
It's completely separate from git. The easiest way to get it is to clone the repository, git clone git://neugierig.org/git-cl.git then add symlinks for the scripts `git-cl' and `upload.py'. Neil (or someone), can you add this info to the CG? For a single commit it is enough to do just git-cl upload without having to pass a commitish. Maybe it would be useful to add this information to CG 8.7.7, too. Regards, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond concept glossary?
On Tue, Aug 11, 2009 at 11:18:33AM -0700, Mark Polesky wrote: My concept glossary idea is now called a technical glossary. I thought the name was fine when it was suggested, but now I'm realizing something -- I'd also like it to list terms that are not specifically dealing with LilyPond *internals*. Such as: the archives What does this mean? The mailist archives? the LSR the tracker Rietveld Savannah I really think this is going overboard. Contributors will know most of these already; if I need to explain what Savannah is to one or two people, that's no problem. I would stick to explaining things like grobs. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Implement new handling for margin and line-width settings.
Thanks for the reply Michael.
Usually we like to keep responses to reviews on the -devel list, so I've
copied this there.
On 8/11/09 5:51 PM, Michael Käppler xmichae...@web.de wrote:
Hi Carl,
thanks for your review:
Don't use lmargin, rmargin, and lwidth as variable names. LilyPond
standards call for using full words in variable names. You might want to
use something like scm_left_margin, scm_right_margin, and scm_line_width.
Fixed. I used lmargin etc. because I saw it in layout-page-init as a
temporary variable, therefore I thought there would be nothing against it.
Yes, we have old code that uses that kind of variable names. As we rewrite,
we're supposed to go to full-word names.
I'd prefer the variable name consistent, instead of consistency
Fixed.
+
+ // Consistency checks. FIXME: Print warnings just once
This would be easy to add by putting the test in an if/elseif/endif block.
Hmm... I don't really understand this. The problem is that
foo-normalize () is called every time an Output_def is needed to get
information about line-width and/or margins. So if one sets wrong values
in \paper {} the function displays the error several times. But I
decided to not overwrite the original paper settings during rendering,
because maybe the original settings are later needed again. (However,
I'm pretty unsure of this)
Oh -- I misunderstood the meaning of the FIXME.
I think I'd recommend changing the settings to something that is rational.
Since we're using the changed settings, we might as well change them so we
don't keep getting errors.
It might be cleaner to define a function set_layout_props (line_width,
left_margin, right_margin) and then call it with different arguments. The
function call could be within the if/elseif/endif block described above,
and then there would be no need for the variable consistency.
See above.
I still think my suggestion for avoiding the variable consistency is a good
one. I have very rough pseudocode below
if (paper_width (line_width + left_margin + right_margin))
{
warning (paper not wide enough for margins + line);
set_paper_layout (default_left_margin, default_right_margin,
default_line_width);
}
else if ((left_margin 0) || (right_margin 0))
{
warning (right or left margin has a negative value);
set_paper_layout (default_left_margin, default_right_margin,
default_line_width);
}
else
set_paper_layout (left_margin, right_margin, line_width);
You could even be smarter in your choice of margins and line-widths to set.
For example, if left_margin 0 and right_margin 0, you could do
set_paper_layout (left_margin, line_width + right_margin, 0)
or something like that.
None of my suggestions are mandatory. They're just suggestions.
Thanks for taking on this task! It will be good for LilyPond users in the
future.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: update from the git battlefield
Hi, On Tue, 11 Aug 2009, Mark Polesky wrote: Trevor Daniels wrote: Does that mean shallow clones are inadvisable on Windows? I'll let Johannes confirm, but I think that shallow clones should be fine on Windows now. I got the sense that he killed the beast last night. It was actually kind of exciting. Welll, I did not come around today to find out if my fix was correct, or to submit the patch. But the patch is available if somebody should need it before I'm able to verify that it is correct and submit it to upstream gitk. Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB files from vc not distributed
GUB builds the binaries, but fails in dist-check. However, I'm baffled by the Documentation/css/ files -- they *are* present in the tarball generated by make dist. Any thoughts? file from VC not distributed: lilypond-2.13.4/Documentation/css/lilypond-blue.css file from VC not distributed: lilypond-2.13.4/Documentation/css/lilypond-ie-fixes.css file from VC not distributed: lilypond-2.13.4/Documentation/css/lilypond-mccarty.css file from VC not distributed: lilypond-2.13.4/Documentation/css/lilypond-web-alt1.css file from VC not distributed: lilypond-2.13.4/Documentation/css/lilypond-web-alt2.css file from VC not distributed: lilypond-2.13.4/Documentation/css/lilypond-web.css file from VC not distributed: lilypond-2.13.4/Documentation/css/lilypond.css file from VC not distributed: lilypond-2.13.4/Documentation/css/text-to-speech.css file from VC not distributed: lilypond-2.13.4/Documentation/snippets/README file from VC not distributed: lilypond-2.13.4/Documentation/topdocs/AUTHORS.texi file from VC not distributed: lilypond-2.13.4/Documentation/topdocs/GNUmakefile file from VC not distributed: lilypond-2.13.4/Documentation/topdocs/INSTALL.texi file from VC not distributed: lilypond-2.13.4/Documentation/topdocs/README.texi ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: InstrumentName misalignment in incipit snippets
On Tue, 2009-08-11 at 21:57 +0100, Neil Puttock wrote: Hi Joe, While fixing the last bug with the new instrument name code, I noticed that the instrument name positioning for both inicipit snippets (Documentation/snippets/incipit.ly and input/regression/incipit.ly) has changed for the worse. By a process of elimination, I've traced the change to your commit which removed all the overrides for minimum-Y-extent in engraver-init.ly. I've played around with the new spacing overrides, but the only thing that seems to correct the misalignment is to add a manual override for MensuralStaff.VerticalAxisGroup #'Y-extent. Can you suggest an alternative to this? I think the problem is the Y-offset callback in the snippet, which says place the top of my extent 4 staff-spaces above the center line of the staff. If top of the incipit's extent is anything other than 4 staff-spaces above its own center staff line, it won't work. IWBN if it were possible to extract the staff-refpoints of a marked up system in a grob callback (in which case we could write a less fragile Y-offset callback), but I'm not sure if it is. In the meantime, I'd suggest changing the snippet to include the Y-extent override (note that it will still break if the incipit has a note far above the staff). I'll put extracting staff refpoints from score markups on my TODO list, after the remaining spacing bugs. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Big Measures in Large Ensemble
(moved to lilypond-devel)
On Tue, 2009-08-11 at 00:22 +0100, Neil Puttock wrote:
2009/8/10 Joe Neeman joenee...@gmail.com:
If there's a \bar and a clef in the same place, then the
BreakAlignGroup will have a non-empty extent, but I think we still want
the column to be loose.
I'm not sure that's desirable; see for example the following snippet,
where the clef is spaced too close to the preceding note.
\relative c' {
c4 d \bar \clef bass c2
}
Agreed, but the problem is not looseness. The column fails anyway to be
loose because of spacing-determine-loose-columns.cc:84
But if we, for example, add a \bar to a column that would otherwise
be loose (like input/regression/spacing-folded-clef.ly) then I think it
should remain loose. (It doesn't, because of line 84 again and the fact
that every musical column gets marked as a neighbor to the bar line, but
that's another issue).
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
When doing a convert-ly rule, do I update snippets/regression tests? These two pop up with grep pad-markup: Documentation/snippets/blanking-staff-lines-using-the--whiteout-command.ly input/regression/whiteout.ly What should I do with these? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
Michael Käppler wrote: For a single commit it is enough to do just git-cl upload without having to pass a commitish. Maybe it would be useful to add this information to CG 8.7.7, too. Michael, Don't forget, you need to mention on -devel that you've posted to Rietveld, and include the link. You'll also need to close it when it's approved/resolved (CG 8.7.9). Here's Michael's patch: http://codereview.appspot.com/104085 - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: headers and footers with new vertical layout engine
On Tue, 2009-08-11 at 16:44 +0200, Werner LEMBERG wrote: Regarding your Top context: why do you override VerticalAxisGroup #'Y-extent = ##f? This is likely to confuse the layout algorithm even after the bug I mentioned is fixed. This was necessary for the old vertical layout engine -- at least it served me well since a few years. I'll test what happens if I remove it. It seems I really no longer need it. However, there are still formatting problems, as given in the example below. See attached image. Is your git up to date? With 38a4db2d15f4 (my last commit) and 16d16717f3 (current HEAD), I get the attached output. Joe attachment: test.preview.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Mon, Aug 10, 2009 at 07:02:39AM +0200, Werner LEMBERG wrote: Also, in the case of Metafont glyphs, there doesn't appear to be a clear convention: some bounding boxes are underestimated, but others are overestimated. What you call `bounding boxes' aren't real bboxes but the metrics boxes of the glyphs. In case of the bass clef, for example, the top shape is treated as with many other rounded glyphs in normal fonts: The `overshoot' sticks out. On the other hand, the height has been enlarged so that it covers the staff vertically. Similar considerations hold for other glyphs. However, I don't object to revising the metrics since the dimensions of the glyphs stem from the time where the TeX engine has been used for layout. Most restrictions are probably no longer of importance. Okay, I see the difference now. Thanks for your explanation. So, if I am understanding correctly, LilyPond currently uses the same dimensions for both the metrics box and the bounding box for each glyph. This is why the longa glyph, for example, is cropped in the EPS/PNG output. Is this true? One issue remains: Should the metrics and the bbox differ at all? My opinion is yes, but this is something Joe can probably answer best. It sounds like they should differ, depending on the case, since the boxes deal with two different concepts. I've attached examples of various cases. The longa example uses the glyph noteheads.sM2neomensural. Perhaps we have to add new fields to the lilypond tables embedded into the OpenType fonts which gives real bounding boxes. Alternatively, we can use FontForge to compute them automatically. I think it would be a good idea to compute them with FontForge. Another improvement would be to provide `shaped metrics': Currently, the metrics for a glyph consist of a single rectangle. This could be extended to a list of rectangles which are then merged. For the longa glyph, this could be these two boxes: +-+ ++ +++ | | || ||| +-+ +||=+++ || || || || || || || || || || ++ ++ Doing so would allow much enhanced precision in collision handling. This is quite interesting. But would this help with collision handling? I was under the impression that the Stencil extents (which form a box) are used for collision handling (skylines, etc.). Or is the glyph metrics information used instead of the Stencil extents? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/11/09 8:30 PM, Mark Polesky markpole...@yahoo.com wrote: When doing a convert-ly rule, do I update snippets/regression tests? The correct question is: When changing syntax, what do I do besides writing a convert-ly rule? The proper answer is: You apply it to the snippets to make sure it works. This should be in the CG but isn't. Graham summarized this earlier, but I couldn't find the message. You copy the snippet from Documentation/snippets to Documentation/snippets/new. You eliminate the comment at the top that says This snippet was automatically generated You eliminate the foreign language translations of the texidoc. You eliminate the comment that says % begin verbatim. Then you run convert-ly on that snippet, to verify the convert-ly rule works. Now, the next time somebody does makelsr.py, it will be copied back to Documentation/snippets from Documentation/snippets/new, with all of the other stuff automagically generated. And if makelsr.py hasn't been done, LilyPond will get the snippet from Documentation/snippets/new instead of Documentation/snippets. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fails to rebuild, configure issues?
On Tue, Aug 11, 2009 at 02:30:53PM +0200, John Mandereau wrote: Le mardi 11 août 2009 à 04:46 -0700, Graham Percival a écrit : Odd behavior: if I rm -rf target/*/build/lilypond*, target/*/src/lilypond*, target/*/status/lilypond*, and target/*/installer/lilypond* (I'm trying to be safe), it seems to build ok. But if I try to rebuild with make lilypond, or if I forget to clean one directory, it fails. This is certainly because GUB uses smart-autogen.sh, which runs autogen.sh if only if stepmake/aclocal MD5 sums have changed since last smart-autogen.sh invocation. ... I'm reverting the change I made. This changed the message, but the underlying problem is still there. I tried another make lilypond, without deleting anything. (a few commits changed Documentation/general/ and css stuff, but nothing else happened on master) Build failed for debian-ppc. I thought that I'd seen error messages about needing to remove config.hh, but this last time that I cleaned things out and generated the error, there's no such message. Got it now! Overall console message: ... *** Stage: compile (lilypond, darwin-ppc) Command barfed: cd /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master make -j1 TARGET_PYTHON=/usr/bin/env python Tail of target/linux-x86/log/build.log rm /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master/config.hh; ./autogen.sh make: *** [/home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master/config.hh] Error 1 Command barfed: cd /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master make -j1 TARGET_PYTHON=/usr/bin/env python Tail of target/linux-x86/log/build.log target/linux-x86/log/build.log: ... cat /home/lilypond/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-master/GNUmakefile.in GNUmakefile chmod -w GNUmakefile make[1]: Leaving directory `/home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master' *** /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master/config.hh is out of date *** Remove it and rerun autogen: rm /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master/config.hh; ./autogen.sh make: *** [/home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master/config.hh] Error 1 Command barfed: cd /home/lilypond/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master make -j1 TARGET_PYTHON=/usr/bin/env python Traceback (most recent call last): ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Tue, 2009-08-11 at 20:03 -0700, Patrick McCarty wrote: On Mon, Aug 10, 2009 at 07:02:39AM +0200, Werner LEMBERG wrote: Another improvement would be to provide `shaped metrics': Currently, the metrics for a glyph consist of a single rectangle. This could be extended to a list of rectangles which are then merged. For the longa glyph, this could be these two boxes: +-+ ++ +++ | | || ||| +-+ +||=+++ || || || || || || || || || || ++ ++ Doing so would allow much enhanced precision in collision handling. This is quite interesting. But would this help with collision handling? I was under the impression that the Stencil extents (which form a box) are used for collision handling (skylines, etc.). Or is the glyph metrics information used instead of the Stencil extents? The glyph metrics are used to compute the stencil extents. There is no particular reason, though, that we have to use a single box. Have a look at calc_skyline_spacing in axis-group-interface.cc. It uses boxes for most grobs, but more complicated outlines for others (ie. axis-groups). It could certainly be modified to use more complicated outlines for grobs that supported it. FWIW, I used to think that this would be a very important feature; now I'm not so sure. There are certainly a few cases (eg. slurs, hairpins, treble clefs) where having more accurate outlines would help. But the list is fairly short: for most glyphs, a more accurate box wouldn't matter much. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement new handling for margin and line-width settings.
Could you add some regression tests (doesn't have to be in this commit) that demonstrate some of the possible combinations of margin settings? There should also be some tests that demonstrate the warnings. http://codereview.appspot.com/104085/diff/1/4 File lily/output-def.cc (right): http://codereview.appspot.com/104085/diff/1/4#newcode149 Line 149: if ((lookup_variable (ly_symbol2scm (is-layout)) == SCM_BOOL_T) (scm_line_width != SCM_UNDEFINED)) return; put the return on a separate line http://codereview.appspot.com/104085/diff/1/4#newcode183 Line 183: if (paper_width != (line_width + left_margin + right_margin)) In case there is rounding, it is better to check if (abs (paper_width - line_width - left_margin - right_margin) 1e-6) http://codereview.appspot.com/104085/diff/1/4#newcode205 Line 205: scm_from_double(paper_width - left_margin_default - right_margin_default)); indentation http://codereview.appspot.com/104085 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilycontrib.tcl, was Re: the r in git pull -r
2009/8/12 Johannes Schindelin johannes.schinde...@gmx.de: Fixed and pushed. Yep, verified. Many thanks once again! I think this can be very useful for new contributors. Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: feature-request / doc-actualization (right-margin)
Mark Polesky wrote: Michael, Don't forget, you need to mention on -devel that you've posted to Rietveld, and include the link. You'll also need to close it when it's approved/resolved (CG 8.7.9). Here's Michael's patch: http://codereview.appspot.com/104085 - Mark Hi Mark, first I was unsure if Rietveld sends an email to the list on itself. Afterwards, having seen that this was not the case, I didn't post the link because I first wanted to make more changes today. But now it's okay anyway. Regards, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
