lily-git: amending patches
We either need one more button for lily-git, or one less. Taking a completely hypthetical example, suppose a new doc contributors writes a nice addition for the docs, but only uses one space after a period (the heretic!). I ask for an updated patch. Our fearless contributor edits the file accordingly, then presses "2. local commit" and "3. generate patches" (or whatever the buttons are). He now has two patches; one of which is just fixing the mistakes in the previous one. I see two possibilities: - "one less button": eliminate the "2. local commit"; just make button 3 produce a patch including _any_ difference between the source tree and origin. - "one more button": add a button for "un-commit", which takes the patch out of the git history, but leaves the files modified. The contributor can then edit the file and do a "local commit" like normal. This would require a prompt for which local commit to un-commit. I think we can assume that contributors can recognize the correct patch to un-commit; they'll generally only have one or two. And if they *do* get confused, it'll be a good lesson to write better changelog message. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
relative dir of share/ in scripts/build/output-distance.py
Commit 79396368e20724a89d34c7a4c53989b8dace5814 (below) changes this
from %s/../share/ to %s/share/. This is required to make the regtest
comparison work in GUB wiht the new regtest names.
I'm not 100% certain that this doesn't mess up the normal "make
test-check" or whatever it is that programmers use, but I can't test
GUB without this, so I pushed it. If this commit causes any problems
whatsoever, please revert it.
Cheers,
- Graham
--- a/scripts/build/output-distance.py
+++ b/scripts/build/output-distance.py
@@ -611,7 +611,7 @@ class SignatureFileLink (FileLink):
outfile = (dest_dir + '/' + f).replace ('.eps', '.png')
data_option = ''
if options.local_data_dir:
-data_option =
('-slilypond-datadir=%s/../share/lilypond/current '
+data_option =
('-slilypond-datadir=%s/share/lilypond/current '
% os.path.dirname(infile))
mkdir (os.path.split (outfile)[0])
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
scheme programmable engravers
http://codereview.appspot.com/181109/show
there are some open todos, which I'll look into, probably over the
weekend, but here is a sample:
Interpreting music... (initialize #
)(start-trans #
)(process-music #
)(process-acknowledged #
)(saw: # coming from #)(process-acknowledged #
)(process-acknowledged #
)(process-acknowledged #
)(start-trans #
)(caught event #) (elements) (duration .
#) (origin . #))((display-methods
#) (name . RestEvent) (types general-music
event rhythmic-event rest-event)) >
) (length . #) (elements) (duration . #) (origin
. #))((class .
rest-event)) >
create:
#
)(process-music #
)(process-acknowledged #
)(process-acknowledged #
)(process-acknowledged #
)(start-trans #
)(process-music #
)(process-acknowledged #
)(saw: # coming from #)(process-acknowledged #
)(process-acknowledged #
)(start-trans #
)(process-music #
)(process-acknowledged #
)(finalize #
)
Preprocessing graphical objects...
Solving 1 page-breaking chunks...[1: 1 pages]
Drawing systems...
Layout output to `scheme-engraver.ps'...
Converting to `./scheme-engraver.pdf'...
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
\header {
texidoc = "\\consists can take a scheme alist as arguments, which
should be functions, which will be invoked as engraver functions."
}
\layout {
\context {
\Voice
\consists
#(list
(cons 'initialize
(lambda (trans)
(display (list "initialize"
(ly:context-moment (ly:translator-context trans)) "\n"
(cons 'start-translation-timestep
(lambda (trans)
(display (list "start-trans"
(ly:context-moment (ly:translator-context trans)) "\n"
(cons 'listeners
(list
(cons 'rest-event (lambda (engraver event)
(let*
((x (ly:engraver-make-grob engraver 'TextScript event)))
(display (list "caught event" event "\ncreate:\n" x "\n"))
(ly:grob-set-property! x 'text "hi"))
))
))
(cons 'acknowledgers
(list
(cons 'note-head-interface
(lambda (engraver grob source-engraver)
(display (list "saw: " grob " coming from " source-engraver))
))
))
(cons 'process-music
(lambda (trans)
(display (list "process-music"
(ly:context-moment (ly:translator-context trans)) "\n"
(cons 'process-acknowledged
(lambda (trans)
(display (list "process-acknowledged"
(ly:context-moment (ly:translator-context trans)) "\n"
(cons 'start-translation-timestep
(lambda (trans)
(display (list "stop-trans"
(ly:context-moment (ly:translator-context trans)) "\n"
(cons 'finalize
(lambda (trans)
(display (list "finalize"
(ly:context-moment (ly:translator-context trans)) "\n"
)
}}
\relative { c4 r4 c }
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: StaffGrouper vs. VerticalAxisGroup: syntax inconsistencies
On Wed, 2009-12-30 at 06:35 +0100, Werner LEMBERG wrote:
> Folks,
>
>
> why can I say
>
> \new PianoStaff \with {
> \override StaffGrouper
> #'between-staff-spacing #'minimum-distance = #20
> } ...
>
> but not
>
> \new Staff \with {
> \override VerticalAxisGroup
> #'next-staff-spacing #'minimum-distance = #20
> } ...
>
> ?
Because next-staff-spacing defaults to a callback rather than to an
alist. IWBN if one could use the nested property syntax for overriding
callbacks but it isn't quite trivial to implement, as far as I can see.
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: configure failure: OSX gcc building two arches SOLVED
On 12/30/09 4:47 PM, "Graham Percival" wrote: > On Wed, Dec 30, 2009 at 04:40:01PM -0700, Carl Sorensen wrote: >> >> configure:9182: checking pango/pangoft2.h usability >> configure:9182: gcc -c > ... >> -arch ppc -arch i386 > > Hmm. > >> It looks to me like the warning is generated because we have 2 architectures >> in the gcc call, so the error here appears to be a red herring. But I have >> so little experience with this that I can't be sure. > > I see. > > So now we suspect that in apple's latest update, they changed > something such that configure decides that gcc should build ppc > and i386? This change would only happen when you do a fresh > ./configure, so it's not surprising the problem wasn't noticed > until now. OK, so I had two things that I needed to do to fix it. First, I had to turn off the system installed Python, but commenting out the lines in .bash_profile that added it to the path. Second, I had to give CFLAGS to the configure command: ./configure CFLAGS='-arch i686' Probably it would have been sufficient to just fix the Python path, because the real error was that it couldn't find Python.h. And that problem was covered up by the multiple architecture errors. At any rate, now I'm building. Thanks for your help in figuring this out. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with tablature angle brackets
On Wed, Dec 30, 2009 at 4:26 PM, Patrick McCarty wrote: > > Would it be a good idea to *draw* these angle brackets instead of > using glyphs from a font? I'm thinking that there would be fewer > problems that way. Or maybe we could add a set of angle brackets to the Emmentaler font, and use those instead? -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Problems with tablature angle brackets
Hello, Recently James reported a problem compiling the tablature regression tests containing angle brackets (entered with \harmonic). See the thread here: http://lists.gnu.org/archive/html/lilypond-user/2009-12/msg00511.html The problem is that relatively few fonts contain the Unicode characters U+2329 and U+232A, which are the characters used for the angle brackets. Additionally, there are problems with using these glyphs, since they are canonically equivalent to two CJK characters. I tried switching the lookups to U+27E8 and U+27E9 instead, but these glyphs don't look as nice with my default serif font (DejaVu Serif). Would it be a good idea to *draw* these angle brackets instead of using glyphs from a font? I'm thinking that there would be fewer problems that way. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
configure failure: OSX gcc building two arches
On Wed, Dec 30, 2009 at 04:40:01PM -0700, Carl Sorensen wrote: > > configure:9182: checking pango/pangoft2.h usability > configure:9182: gcc -c ... > -arch ppc -arch i386 Hmm. > It looks to me like the warning is generated because we have 2 architectures > in the gcc call, so the error here appears to be a red herring. But I have > so little experience with this that I can't be sure. I see. So now we suspect that in apple's latest update, they changed something such that configure decides that gcc should build ppc and i386? This change would only happen when you do a fresh ./configure, so it's not surprising the problem wasn't noticed until now. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On 12/30/09 3:20 PM, "Graham Percival" wrote: > On Wed, Dec 30, 2009 at 01:52:56PM -0700, Carl Sorensen wrote: >> >> This is METAFONT, Version 2.71828 (Web2C 7.5.6) >> kpathsea: Running mktexfmt mf.base >> tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not >> found. >> fmtutil: config file `fmtutil.cnf' not found. >> I can't find the base file `mf.base'! >> make[1]: *** [out/feta11.log] Error 1 >> make: *** [all] Error 2 >> >> cd to /, and doing >> >> find . -name feta11.log > > Well, you want to find fmtutil.cnf or mf.base, not feta11.log. > fmutil.cnf is in /opt/local/share/texmf/web2c mf.base is not found. > Three things come to mind: > 1) you don't have the right texlive installation (unlikely, > since you've built it before) I'm in the process of reinstalling texlive with macports. Still the same results. > 2) this build method needs extra configuration to point to the > right texlive installation > 3) important system files are disappearing because your HD is > dying. Back up immediately. I'me backed up on two different backup systems, so I think I'm OK with backups. Thanks for the help, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On 12/30/09 4:15 PM, "Graham Percival" wrote: > On Wed, Dec 30, 2009 at 04:06:12PM -0700, Carl Sorensen wrote: >> >> On 12/30/09 3:14 PM, "Graham Percival" wrote: >> configure: WARNING: Python.h: accepted by the compiler, rejected by the preprocessor! >>> >>> That's not normal. >> >> How can I find out about the tests used to check "usability" and "presence"? >> I would like to know what exactly is failing. That might give me a clue. >> >> Every one of the strange warnings says that *.h is usable, but not present. >> That seems strange. > > IIRC, the exact command would be in config.log. Thanks, that helped. Here's the one for pango: configure:9182: checking pango/pangoft2.h usability configure:9182: gcc -c -O2 -finline-functions -g -pipe -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/opt/local/include/pango-1.0 -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include conftest.c >&5 conftest.c:9:1: warning: "PACKAGE_NAME" redefined conftest.c:2:1: warning: this is the location of the previous definition conftest.c:9:1: warning: "PACKAGE_NAME" redefined conftest.c:2:1: warning: this is the location of the previous definition configure:9182: $? = 0 configure:9182: result: yes configure:9182: checking pango/pangoft2.h presence configure:9182: gcc -E -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/opt/local/include/pango-1.0 -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include conftest.c gcc-4.0: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags configure:9182: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define PACKAGE "lilypond" | #define PACKAGE_NAME "LilyPond" | #define TOPLEVEL_VERSION "2.13.10" | #define DIRSEP '/' | #define PATHSEP ':' | #define DATADIR "NONE/share" | #define BUILD_PACKAGE_DATADIR "/Users/Carl/new-lilypond/lilypond-working/out/share/lilypond" | #define LIBDIR "NONE/lib" | #define BUILD_PACKAGE_LIBDIR "/Users/Carl/new-lilypond/lilypond-working/out/lib/lilypond" | #define NDEBUG 1 | #define HAVE_LIBDL 1 | #define HAVE_DLOPEN 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_FLEXLEXER_H 1 | #define LOCALEDIR "/usr/local/share/locale" | #define HAVE_LIBINTL 1 | #define HAVE_GETTEXT 1 | #define HAVE_LIBGUILE_H 1 | #define HAVE_LIBGUILE 1 | #define HAVE_SCM_BOOT_GUILE 1 | #define GUILE_MAJOR_VERSION 1 | #define GUILE_MINOR_VERSION 8 | #define GUILE_PATCH_LEVEL 7 | #define HAVE_PYTHON_H 1 | #define HAVE_ASSERT_H 1 | #define HAVE_GRP_H 1 | #define HAVE_PWD_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_WCHAR_H 1 | #define HAVE_SSTREAM 1 | #define HAVE_GETTEXT 1 | #define HAVE_PANGO16 1 | #define HAVE_PANGO_FT2 1 | /* end confdefs.h. */ | #include configure:9182: result: no configure:9182: WARNING: pango/pangoft2.h: accepted by the compiler, rejected by the preprocessor! configure:9182: WARNING: pango/pangoft2.h: proceeding with the compiler's result configure:9182: checking for pango/pangoft2.h configure:9182: result: yes It looks to me like the warning is generated because we have 2 architectures in the gcc call, so the error here appears to be a red herring. But I have so little experience with this that I can't be sure. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On Wed, Dec 30, 2009 at 04:06:12PM -0700, Carl Sorensen wrote: > > On 12/30/09 3:14 PM, "Graham Percival" wrote: > > >> configure: WARNING: Python.h: accepted by the compiler, rejected by the > >> preprocessor! > > > > That's not normal. > > How can I find out about the tests used to check "usability" and "presence"? > I would like to know what exactly is failing. That might give me a clue. > > Every one of the strange warnings says that *.h is usable, but not present. > That seems strange. IIRC, the exact command would be in config.log. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On 12/30/09 3:14 PM, "Graham Percival" wrote: > On Wed, Dec 30, 2009 at 08:31:11AM -0700, Carl Sorensen wrote: >> >> I did end up doing a reconfigure (due to trying the out-of-tree build, which >> also failed, but that's another story). >> >> During my configure, I've found the following warnings: >> >> checking g++ version... 4.0.1 >> configure: WARNING: autoconf <= 2.59 with g++ >= 3.3 gettext test broken. >> configure: WARNING: Trying gcc, cross fingers. > > That's normal, and has been for years. (IIRC, we even have an > open issue for "clean up the configure so people don't get > confused by pointless warnings") That was my memory. > >> checking Python.h usability... yes >> checking Python.h presence... no >> configure: WARNING: Python.h: accepted by the compiler, rejected by the >> preprocessor! > > That's not normal. How can I find out about the tests used to check "usability" and "presence"? I would like to know what exactly is failing. That might give me a clue. Every one of the strange warnings says that *.h is usable, but not present. That seems strange. > > Well, the problem is either in the git source, or something > special on your system. The last change to configure.in was > removing some old pango stuff in Nov, which I can't imagine > causing this. > > So what happened recently on your system? Did you move the > lilypond git dir onto a removable HD? I had some weird problems > with configure, but it turned out that I'd put it on an SD card > and the whole drive was marked noexec. (security issue) I downloaded some Mac system updates (and make worked fine after I did so). I haven't done anything with the git sources. I did decide to try the out-of-tree build, which required me to do a new configure. I thought I could do a configure in the out-of-tree build directrory, but the error messages said I had to do a make distclean first. After doing make distclean, configure doesn't seem to work any more. > > Did you update macports? A new version of gcc, or make, or > automake, or autoconf, or whatever, could cause it. When I did the ivo boumans build instructions to try to build 2.12 using macports, it updated a *bunch* of stuff, but it made no difference. Neither 2.12 nor 2.13 will build now. > > Did you change your .profile ? Maybe you added > export PATH=/opt/new/version/of/matlab > instead of > export PATH=/opt/new/version/of/matlab:$PATH No, no changes to profile. My paths seem to be OK. > > If none of those turn up anything... well, is your HD dying? > Apparently the SMART disk checker (in OSX, it's in the disk > utility) isn't terribly reliable; google found that a third of > their HDs died without any warnings (and nobody on earth who is > allowed to publish unclassified research papers uses more HDs than > google). But hey, that still gives a 2/3 chance that if there > _is_ someting wrong, it'll show up. Disk checker shows no problems. > > > After all, once we've eliminated the impossible, the only thing > left, however improbable, is the cause. Something like that, at > least. > > Cheers, > - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On Wed, Dec 30, 2009 at 2:14 PM, Graham Percival wrote: > On Wed, Dec 30, 2009 at 08:31:11AM -0700, Carl Sorensen wrote: >> >> I did end up doing a reconfigure (due to trying the out-of-tree build, which >> also failed, but that's another story). >> >> During my configure, I've found the following warnings: >> >> checking g++ version... 4.0.1 >> configure: WARNING: autoconf <= 2.59 with g++ >= 3.3 gettext test broken. >> configure: WARNING: Trying gcc, cross fingers. > > That's normal, and has been for years. (IIRC, we even have an > open issue for "clean up the configure so people don't get > confused by pointless warnings") > >> checking Python.h usability... yes >> checking Python.h presence... no >> configure: WARNING: Python.h: accepted by the compiler, rejected by the >> preprocessor! > > That's not normal. > >> configure: WARNING: assert.h: accepted by the compiler, rejected by the >> preprocessor! > > Definitely not normal. > >> I don't remember seeing any of these before, but having all of these >> warnings causes me to think that perhaps there's a bad include path, but I >> have no clue about how to troubleshoot it. > > Well, the problem is either in the git source, or something > special on your system. The last change to configure.in was > removing some old pango stuff in Nov, which I can't imagine > causing this. I agree that these warnings (except for the "Trying gcc, cross fingers" one) are not normal. Though I seem to recall that some Mac users (maybe Patrick Schmidt) have reported them before. Another thing you (Carl) could try is doing a local "git clone" of your LilyPond repository into a new directory, and try doing ./autogen.sh from scratch. The reason I suggest doing a *local* git clone is so that you don't need to download 120MB unnecessarily. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On Wed, Dec 30, 2009 at 01:52:56PM -0700, Carl Sorensen wrote: > > This is METAFONT, Version 2.71828 (Web2C 7.5.6) > kpathsea: Running mktexfmt mf.base > tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not > found. > fmtutil: config file `fmtutil.cnf' not found. > I can't find the base file `mf.base'! > make[1]: *** [out/feta11.log] Error 1 > make: *** [all] Error 2 > > cd to /, and doing > > find . -name feta11.log Well, you want to find fmtutil.cnf or mf.base, not feta11.log. Three things come to mind: 1) you don't have the right texlive installation (unlikely, since you've built it before) 2) this build method needs extra configuration to point to the right texlive installation 3) important system files are disappearing because your HD is dying. Back up immediately. Frankly, at this stage I'd be backing up anyway as a precaution. Of course, my brother makes the world's best backup software with http://tarsnap.com , so it only takes me a minute run my script that backs up everything I care about on offsite storage . In all seriousness, this is sounding really fishy. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On Wed, Dec 30, 2009 at 08:31:11AM -0700, Carl Sorensen wrote: > > I did end up doing a reconfigure (due to trying the out-of-tree build, which > also failed, but that's another story). > > During my configure, I've found the following warnings: > > checking g++ version... 4.0.1 > configure: WARNING: autoconf <= 2.59 with g++ >= 3.3 gettext test broken. > configure: WARNING: Trying gcc, cross fingers. That's normal, and has been for years. (IIRC, we even have an open issue for "clean up the configure so people don't get confused by pointless warnings") > checking Python.h usability... yes > checking Python.h presence... no > configure: WARNING: Python.h: accepted by the compiler, rejected by the > preprocessor! That's not normal. > configure: WARNING: assert.h: accepted by the compiler, rejected by the > preprocessor! Definitely not normal. > I don't remember seeing any of these before, but having all of these > warnings causes me to think that perhaps there's a bad include path, but I > have no clue about how to troubleshoot it. Well, the problem is either in the git source, or something special on your system. The last change to configure.in was removing some old pango stuff in Nov, which I can't imagine causing this. So what happened recently on your system? Did you move the lilypond git dir onto a removable HD? I had some weird problems with configure, but it turned out that I'd put it on an SD card and the whole drive was marked noexec. (security issue) Did you update macports? A new version of gcc, or make, or automake, or autoconf, or whatever, could cause it. Did you change your .profile ? Maybe you added export PATH=/opt/new/version/of/matlab instead of export PATH=/opt/new/version/of/matlab:$PATH If none of those turn up anything... well, is your HD dying? Apparently the SMART disk checker (in OSX, it's in the disk utility) isn't terribly reliable; google found that a third of their HDs died without any warnings (and nobody on earth who is allowed to publish unclassified research papers uses more HDs than google). But hey, that still gives a 2/3 chance that if there _is_ someting wrong, it'll show up. After all, once we've eliminated the impossible, the only thing left, however improbable, is the cause. Something like that, at least. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On 12/29/09 10:26 PM, "Graham Percival" wrote: > On Wed, Dec 30, 2009 at 5:13 AM, Carl Sorensen wrote: >> >> So now make fails, with this error message: > > Interesting. When was the last time you did a fresh "make" ? Was it > before 21 Dec 2009 ? > >> ./include/libc-extension.hh:51: error: declaration does not declare anything >> ./include/libc-extension.hh:51: error: declaration does not declare anything >> lipo: can't open input file: >> /var/folders/Rv/RvqP2cCoEOawyy1FGSxWZU+++TI/-Tmp-//ccyBa9Qz.out (No such >> file or directory) > > Silly question: you're not out of HD space, are you? :) > >> Any thoughts? > > My first thought is > http://code.google.com/p/lilypond/issues/detail?id=947 > which was applied on 21 Dec here: > http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=6b78efc2ea0cb064 > 850c264ff225d9930353a178 > > but I can't see any vector in libc-extension.hh. So then the question > is "what version of gcc are you using exactly", and we start fishing > around with various low-level issues. > > I can't see how the recent texinfo macro games would possibly affect this. > So now I've tried doing a port install of LilyPond, as suggested in Ivo's website: http://ivo.bouwmans.name/lilypondleopard/#Build under option D1. It failed with This is METAFONT, Version 2.71828 (Web2C 7.5.6) kpathsea: Running mktexfmt mf.base tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not found. fmtutil: config file `fmtutil.cnf' not found. I can't find the base file `mf.base'! make[1]: *** [out/feta11.log] Error 1 make: *** [all] Error 2 cd to /, and doing find . -name feta11.log showed only three old versions of feta11.log. I'm pretty much stumped on this, and would appreciate any help that anybody can give me. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Use find ... | xargs rm -f instead of find ... -delete
On Wed, Dec 30, 2009 at 09:59:51AM +0100, David Kastrup wrote:
> >>> find $(outdir)/offline-root -type -l -exec rm -f -- '{}' +
[...]
> >> Well, if that's part of POSIX, then adding it can't be a bad
> >> thing. :)
> >
> > Isn't AFAIK.
>
> The '+' thing appears to be POSIX if I am reading the GNU documentation
> correctly. I have my doubts regarding the veracity of this information
> (but one could look that up),
http://www.opengroup.org/onlinepubs/9699919799/utilities/find.html
> and about how widely it is implemented.
Free- and NetBSD implement it, all GNU-based Linuxes (and cygwin)
are using GNU find. MacOS X uses large parts of FreeBSD userland,
so it should support that feature, too (someone should check this).
I'll try to unslack and implement it for OpenBSD. If all else fails,
I can maintain a local patch in my LilyPond port for OpenBSD that
still uses xargs.
For other systems (OpenSolaris, older Solarises and SunOS, HPUX,
AIX, IRIX, ...) I'd like to hear from anyone who at least tried to
build LilyPond (and required tools and libraries) on them.
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On 12/29/09 10:26 PM, "Graham Percival" wrote: > On Wed, Dec 30, 2009 at 5:13 AM, Carl Sorensen wrote: >> >> So now make fails, with this error message: > > Interesting. When was the last time you did a fresh "make" ? Was it > before 21 Dec 2009 ? No, I've done several fresh makes since then. > >> ./include/libc-extension.hh:51: error: declaration does not declare anything >> ./include/libc-extension.hh:51: error: declaration does not declare anything >> lipo: can't open input file: >> /var/folders/Rv/RvqP2cCoEOawyy1FGSxWZU+++TI/-Tmp-//ccyBa9Qz.out (No such >> file or directory) > > Silly question: you're not out of HD space, are you? :) 25 Gb free. > >> Any thoughts? > > My first thought is > http://code.google.com/p/lilypond/issues/detail?id=947 > which was applied on 21 Dec here: > http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=6b78efc2ea0cb064 > 850c264ff225d9930353a178 > > but I can't see any vector in libc-extension.hh. So then the question > is "what version of gcc are you using exactly", and we start fishing > around with various low-level issues. sorensen2:lilypond-working Carl$ gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465) I did end up doing a reconfigure (due to trying the out-of-tree build, which also failed, but that's another story). During my configure, I've found the following warnings: checking g++ version... 4.0.1 configure: WARNING: autoconf <= 2.59 with g++ >= 3.3 gettext test broken. configure: WARNING: Trying gcc, cross fingers. checking Python.h usability... yes checking Python.h presence... no configure: WARNING: Python.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: Python.h: proceeding with the compiler's result checking for Python.h... yes checking assert.h usability... yes checking assert.h presence... no configure: WARNING: assert.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: assert.h: proceeding with the compiler's result checking for assert.h... yes checking grp.h usability... yes checking grp.h presence... no configure: WARNING: grp.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: grp.h: proceeding with the compiler's result checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... no configure: WARNING: pwd.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: pwd.h: proceeding with the compiler's result checking for pwd.h... yes checking wchar.h usability... yes checking wchar.h presence... no configure: WARNING: wchar.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: wchar.h: proceeding with the compiler's result checking for wchar.h... yes checking sstream usability... yes checking sstream presence... no configure: WARNING: sstream: accepted by the compiler, rejected by the preprocessor! configure: WARNING: sstream: proceeding with the compiler's result checking for sstream... yes checking pango/pangoft2.h usability... yes checking pango/pangoft2.h presence... no configure: WARNING: pango/pangoft2.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: pango/pangoft2.h: proceeding with the compiler's result checking for pango/pangoft2.h... yes I don't remember seeing any of these before, but having all of these warnings causes me to think that perhaps there's a bad include path, but I have no clue about how to troubleshoot it. > > I can't see how the recent texinfo macro games would possibly affect this. Me either. :( Last night I was ready to be done with LilyPond development after spending 2 1/2 hours doing make-clean, configure, etc. and having it all fail. Today I'm ready to work some more on it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
Carl Sorensen schrieb: On 12/30/09 6:06 AM, "Marc Hohl" wrote: @Carl: I am not at all familiar with SVG. Could you please produce a file similar to the one you sent already with different rotating angles? I can only produce a file like that with the clefs you have designed if you generate svg output instead of (or in addition to) the pdf output. Use lilypond -fsvg myfile.ly in order to generate svg output (see Command line options for lilypond in section 1.2 of Usage). Oh, sorry, I wasn't clear enough. I meant you to create this file with the original liypond clef. Then we can find the ideal rotating angle, and I'll implement that in metafont. Thanks Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Wikipedia article
2009/12/30 Jan Nieuwenhuizen : > Op zaterdag 05-09-2009 om 18:53 uur [tijdzone +0200], schreef Francisco > Vila: > > Hi Francisco, > >> I've been updating a bit the Spanish Wikipedia page for LilyPond. > >> http://es.wikipedia.org/wiki/GNU_LilyPond > > Great, thanks! This has become quite an article. Did you > consider thoughts in this thread > > http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00092.html Yes, some of them. > esp, I don't think it's necessary (or wise) to mention Finale, Sibelius > etc in the first or second paragraph. I notice that other softwares, eg > > http://en.wikipedia.org/wiki/Sibelius_(software) > > do not talk about about other softwares until the very bottom of the > page, and say nothing much about them? I agree, I'll try to improve this. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com No le des el mando a distancia a Microsoft. No utilices Windows 7. http://windows7sins.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
On 12/30/09 6:06 AM, "Marc Hohl" wrote: > > @Carl: > I am not at all familiar with SVG. Could you please produce a file > similar to the one you sent already with different rotating angles? I can only produce a file like that with the clefs you have designed if you generate svg output instead of (or in addition to) the pdf output. Use lilypond -fsvg myfile.ly in order to generate svg output (see Command line options for lilypond in section 1.2 of Usage). > > (By the way: it is interesting to compare the values: my first > rude approach was done with value 3; > Carl proposes 1.5 which yields to a rotating angle of 1.1 degrees; > Francisco votes for 2, this is 1.5 degrees; > so the range between 1 and about 1.7 degrees seems to be the > most interesting one). > And my first test suggested somewhere between 1 and 2.5 degrees of just pure rotation on the whole clef. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
Francisco Vila schrieb: 2009/12/29 Marc Hohl : I concatenated the pdfs to one file, which is too big for the list, so I put it on my website: http://www.hohlart.de/marc/gclef-slant.pdf I know that there is a spurious error on value 2, but I think that's not the main problem. Which value looks best? At a risk of being the "upper loop man" I have to say that starting from parameter=0 upwards, the upper loop grows continuously. If this is what you mean when you say this still has to be normalized, then forget me. Yes, I wanted the loop to be corrected at step 3 ;-) The width of the vertical seems to be thinner starting at 4. Several things change at once in the sequence, but my amateurish vote is for 2 even when it has the error, because it is between 1.5 and 2.5 which I like less. Taking into account the other/earlier responses from David and Carl, I now think that the three-step plan is wrong, because it first destroys the existing balance to try to mend it later again. @Carl: I am not at all familiar with SVG. Could you please produce a file similar to the one you sent already with different rotating angles? (By the way: it is interesting to compare the values: my first rude approach was done with value 3; Carl proposes 1.5 which yields to a rotating angle of 1.1 degrees; Francisco votes for 2, this is 1.5 degrees; so the range between 1 and about 1.7 degrees seems to be the most interesting one). Then, if we have a decision about the "right" rotating angle, I think I can implement this in metafont. A small correction of the bulb will probably be needed afterwards, but this should not be too difficult, and once I got the right rotation amount, I can generate comparison tests like my first one with different bulbs. I wanted to create a real life example to see the clef in its natural environment, but in addition, I will cutout the clefs and collect them onto a png file for better one-to-one comparison, once the rotation is fixed. Thanks for your resposes! Greetings Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Wikipedia article
Op zaterdag 05-09-2009 om 18:53 uur [tijdzone +0200], schreef Francisco Vila: Hi Francisco, > I've been updating a bit the Spanish Wikipedia page for LilyPond. > http://es.wikipedia.org/wiki/GNU_LilyPond Great, thanks! This has become quite an article. Did you consider thoughts in this thread http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00092.html esp, I don't think it's necessary (or wise) to mention Finale, Sibelius etc in the first or second paragraph. I notice that other softwares, eg http://en.wikipedia.org/wiki/Sibelius_(software) do not talk about about other softwares until the very bottom of the page, and say nothing much about them? > Some sections need more work and there are untouched blocks. Feel free > to reuse that material for other languages, I could help on the Es->En > translating if needed. I don't think an english translation/rewrite has been attempted yet? Greetings, Jan. -- Jan Nieuwenhuizen | 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: Autobeaming
On 30 Dec 2009, at 12:53, Reinhold Kainhofer wrote: Am Mittwoch, 30. Dezember 2009 12:27:25 schrieb David Kastrup: Hans Aberg writes: Take tuplets. If there are quintuplets, then it should be a 5' unless specified as typically 2'+3' or 3'+2'. For sextuplets, there is a convention that the should be in 3, so there is an implicit rule 3'+3' - there should be no subbeaming of the 3'. But a compose might want to change that. I am not sure I understand that. Why use sextuplets when you could just use triplets as 3'+3'? I should think that sextuplets make most sense when you need 2'+2'+2' as a rhythmic pattern. In several violin parts, sextuplets are real sextuplets without any subdividing. The beaming should also span all six notes in that case. What I mentioned is from Hindemith, "Elementary training", p. 116 f, which I think is a CPP convention. He does not subbeam it as 3'+3'. So I think it just reflects different way to notate. One may not use subbeaming to indicate subaccents. The notation is simply ambiguous, and it is left to the musician to interpret. One may want to specify the subaccents by subbeaming. If that is the case, the not subbeamed sextuplet will be unambiguous, meaning no subaccents. But somehow it must be communicated that you are using this convention. In order to capture this ambiguity, I want "+" to indicate subaccents, but it does not imply any specify relation between these subaccents, or say that there should be no other accents. Take 9 = 4+2+3 as example (Bela Bartok use it). It means there should be two subaccents. This meter is BUlgarian, where it is often grouped as 9 = (2'+2')+(2'+3'). The way I describe it, this for is also a 9=4+2+3 meter - it just has a refined specification or more accents. One can also write 9 = 2+2+2+3. So strictly speaking, one deals with three types of numbers: those that do not specify subaccents, those that are "in one", and those that imply a subaccents. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 30 Dec 2009, at 12:27, David Kastrup wrote: Hans Aberg writes: Take tuplets. If there are quintuplets, then it should be a 5' unless specified as typically 2'+3' or 3'+2'. For sextuplets, there is a convention that the should be in 3, so there is an implicit rule 3'+3' - there should be no subbeaming of the 3'. But a compose might want to change that. I am not sure I understand that. Why use sextuplets when you could just use triplets as 3'+3'? I should think that sextuplets make most sense when you need 2'+2'+2' as a rhythmic pattern. I have had very little exposure to them, actually, that's just my mathematical gut feeling. It's just a CPP convention, mentioned in Hindemith, "Elementary training", p. 116 f. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
Am Mittwoch, 30. Dezember 2009 12:27:25 schrieb David Kastrup: > Hans Aberg writes: > > Take tuplets. If there are quintuplets, then it should be a 5' unless > > specified as typically 2'+3' or 3'+2'. > > > > For sextuplets, there is a convention that the should be in 3, so > > there is an implicit rule 3'+3' - there should be no subbeaming of the > > 3'. But a compose might want to change that. > > I am not sure I understand that. Why use sextuplets when you could just > use triplets as 3'+3'? I should think that sextuplets make most sense > when you need 2'+2'+2' as a rhythmic pattern. In several violin parts, sextuplets are real sextuplets without any subdividing. The beaming should also span all six notes in that case. Cheers, Reinhld -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: remove duplicate anchor generation in texi2html
Am Mittwoch, 30. Dezember 2009 06:55:38 schrieb Patrick McCarty: > I forgot to mention that with this patch, hyperlinks have a "#" > appended to them instead of a "#" followed by the node name. So it's > still not satisfactory. > > I tried to figure out where the hyperlink names are generated. I > assume the procedure does a simple concatenation of the filename, #, > and the node name (id), but the location of this code has evaded me so > far. -) do_external_href in texi2html.pl, which calls -) external_href in tex2html.init Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
Hans Aberg writes: > Take tuplets. If there are quintuplets, then it should be a 5' unless > specified as typically 2'+3' or 3'+2'. > > For sextuplets, there is a convention that the should be in 3, so > there is an implicit rule 3'+3' - there should be no subbeaming of the > 3'. But a compose might want to change that. I am not sure I understand that. Why use sextuplets when you could just use triplets as 3'+3'? I should think that sextuplets make most sense when you need 2'+2'+2' as a rhythmic pattern. I have had very little exposure to them, actually, that's just my mathematical gut feeling. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
http://tecnocode.co.uk/2009/12/29/non-recursive-automake/
fyi, this just might be a nice idea ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 30 Dec 2009, at 00:17, Carl Sorensen wrote: I find the current LilyPond structure hard to cope with when wanting subbeaming. Yes, right now there is no sound method for dealing with subbeaming (or beam subdivision, as I think it's called). I hope to fix that. That would be good. I think that the beaming structures without the meter concept are essentially the same, so it might fix the beaming problem altogether. The smallest units is "in one", where one only has a time segment which should be beamed as much as possible - on the time level subdivision it expresses. Ross and Read talk about this smallest unit as a "beat", and it is not necessarily the denominator of the time signature. I got the term "in one" from Steve Latham, who said it was used in Finale, and also by musicians when performing for example Beethoven's 5th, which is written in 2/4, but normally played "in one", that is, with only one metric accent per measure. A strict time signature would have been 1/2, but apparentlty, that is not used in CPP. There is the Bulgarian "Eleno Mome" which the Bulgarian musicologists write in 13/16, 13 = 4+4+2+3, but the 3 here indicates a time bend which is performed typically very close to 4. So I think a correct writing would be 7/8, where 7 = 2+2+1+2, or (2+2)+(1+2) if subaccents should be displayed. I then avoid the use of "beat" because it is ambiguous here. The time units can be so short it is not possible to count on them. (Here the quarter note is at about 144 bpm.) In fact, in what they refer to as "compound time" or "compound meter", the beat is three times the denominator of the time signature. Such terms are ambiguous: there seems to be a divide between a "Latin" and a "Germanic" tradition, going down in the middle of Europe, with the Netherlands on the dividing line. In the Latin tradition, "duple" and "triple" time refers to how the notes of the piece are subdivided. So 4/4 is duple time. In the Germanic tradition, it has to with the time signature. So 4/4 is quadruple time. This then affects the interpretation of "compound time". I stick to essentially Germanic tradition. Meters that can be written without a + are simple, others are compound. So 6 = 3'+3' is compound. 4 is simple, but compound when interpreted as 2+2. Meters that are built up in a regular way I call regular, the others irregular. So 9 = 3'+3'+3' is regular and compound (can be rewritten as a 3, which is simple), but 9 = (2'+2')+(2'+3'), common in the Balkans, is irregular and compound. English speaking may find this confusing, but is close to the Germanic tradition. Then one can repeat that either equally by an integer multiple or a "+". For example, 6/8 calls for a "in one" 3+3 division of the time unit which is the 1/8th note, which at the same time is the same as 2 times the dotted 1/4th note. So doing some pseudocode, it might be written (3+3) x 1/8 or 2 x 3/8 = 2 x 1/4. (dotted 1/4th) However, in the first one, the 3's should be "in one", and not be beamed as "in three", expressing metric subaccents. So perhaps one needs to distinguish between these two types of integers, say write "in one" as 3'. Then the first one should be written (3'+3') x 1/8 So if I understand correctly, you mean that all the notes in each of the 3' sections should be beamed together, thus avoiding metric subaccents? Yes, I think that is the lowest level, and also default if there are no conventions. Take tuplets. If there are quintuplets, then it should be a 5' unless specified as typically 2'+3' or 3'+2'. For sextuplets, there is a convention that the should be in 3, so there is an implicit rule 3'+3' - there should be no subbeaming of the 3'. But a compose might want to change that. Triplets are by convention in 3 - the 3 not the 3' Then take a time signature like 4/4. It has i fact two common interpretations: (2'+2') x 1/4 4 x 1/4 Now one might also use tuplets tied to the metric. For example, in Macedonian 7/16, one may normally play as (3'+(2'+2')) x 1/16 But one may shift to using quadruplets on the 3s divided as 2'+2', which one might want to express in the subbeaming. So one might want a second rule like (3:4 (2'+2') + (2'+2')) x 1/16 So the \meter should have a sequence of such rules. I believe that these rules are exactly what the current autobeaming rules can express (although the rules that express this are not in the current default beam settings). I have had problems in the past when doing subbeaming. So I have no problems getting the 3'+2'+2'. But strange things tend to happen when doing subbeaming. For example, getting the quadruplet subbeaming 3:4 2'+'2 might be hard. Unfortunately, there is a very popular Macedonian meter (Ibraim Odza, for example) ((3:4 (2'+2') + (2'+2')) + 3:4 ((2'+2') + 2') x 1/16 or 12/16. When writing a time signature, some may want to just adding it all in
Re: [PATCH] Use find ... | xargs rm -f instead of find ... -delete
David Kastrup writes:
> Graham Percival writes:
>
>>> Then change it to something like this:
>>>
>>> find $(outdir)/offline-root -type l -print0 | xargs -0 rm -f --
>>>
>>> Or even this (completely POSIX compliant):
>>>
>>> find $(outdir)/offline-root -type -l -exec rm -f -- '{}' +
>>>
>>> (but then I've to patch it again, since find(1) on OpenBSD doesn't yet
>>> support the `-exec command {} +' primary).
>>
>> Well, if that's part of POSIX, then adding it can't be a bad
>> thing. :)
>
> Isn't AFAIK.
The '+' thing appears to be POSIX if I am reading the GNU documentation
correctly. I have my doubts regarding the veracity of this information
(but one could look that up), and about how widely it is implemented.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
