Re: Python path
Han-Wen Nienhuys wrote: Manuzhai escreveu: Hello there, I installed Lilypond a while ago on my Windows workstation. Today I discovered that this installation is quite aggressive: it puts Lilypond front-and-center in my PATH, so that, for example, I get Lilypond's Python whereas I might like to get my own ActivePython. I moved the LilyPond path to further down the PATH list, but maybe this should be the way it is when installed? thanks, path is now at the end. Note that we had good reasons to move LilyPond to the front of the path, see for example http://lists.gnu.org/archive/html/bug-lilypond/2005-12/msg00076.html /Mats -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python path
Graham Percival escreveu: thanks, path is now at the end. What if they have a different version of python installed? Would lilypond try to use an unsupported version of python and fail, or does lily only use its own installed python? our python is rather wobbly. Chances are that the installed version is a native python , and would work better. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
Werner LEMBERG escreveu: Consider the test file apply-output.ly. During `make web', extended debugging is active, and processing the file gives this warning: programming error: Grob `NoteHead' has no interface for property `text' continuing, cross fingers Hanwen, do you have an answer to my original question? Or is this `ancient notation'? There is no easy way. You have to write a bit of scheme code that adds to the list in the interfaces detail property in the meta property. There are many other warnings similar to this, and I think it would be good to fix them all. 95% of these warnings come from the ancient notation code; that needs to be fixed first IMO. Please give an example, together with the `right' syntax. this is not about syntax, but about the ancient notation code misusing the current structure in ways that it wasn't designed to do. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Context aliases
hi, In my quest for softcoding context-defs, I will need to revisit the \alias system. This is not on the top of my todo, but I'd like to hear any protests early. I suggest that the \alias mechanism is scrapped altogether, and replaced with something else: - junk Bottom alias, instead make is_bottom_context accessible from scheme. - other aliases are replaced with appropriate boolean context properties, with more intuitive names (e.g. property 'isLyricMelody replaces current \alias Voice). I think this will be an improvement, because we remove the concept of aliases, which confuses users (at least it confuses me a bit); in addition we don't need to do anything extra to softcode aliases. All this is post-2.10 of course. -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote: Werner LEMBERG escreveu: Consider the test file apply-output.ly. During `make web', extended debugging is active, and processing the file gives this warning: programming error: Grob `NoteHead' has no interface for property `text' continuing, cross fingers Hanwen, do you have an answer to my original question? Or is this `ancient notation'? There is no easy way. You have to write a bit of scheme code that adds to the list in the interfaces detail property in the meta property. There are many other warnings similar to this, and I think it would be good to fix them all. 95% of these warnings come from the ancient notation code; that needs to be fixed first IMO. Please give an example, together with the `right' syntax. this is not about syntax, but about the ancient notation code misusing the current structure in ways that it wasn't designed to do. Ancient notation uses "head prefixes" like \virga, \quilisma, etc. that are kind of attributes of the note heads for their further characterization (in the source code, these note heads also called "ligature primitives", if used in the context of ligatures). These attributes further describe the heads, such as "select a virga glyph for this note head". Still, the actual note head glyph depends not only on the attribute(s) of the note head, but also on the attributes of the left and right neighbour note head. Hence, it does not make sense to store these attributes e.g. as notehead style. Additionally, some implicit attributes derive from the combination of attributes of two adjacent note heads (e.g. for deciding if a vertical line has to be drawn between two adjacent note heads). When the music is processed by the parser, I somewhere have to store this information that refers to individual note heads. Obviously, the note heads themselves are the best place. However, one of the design requirements of adding ancient notation to lily was to separate the new code as far as possible from existing code; in particular, ancient notation code was required not to "pollute" existing code of lily, such as note-heads.cc. As a result, ancient notation inofficially uses these attributes without officially declaring them in noteheads.cc. One theoretical solution would be to introduce a new "ligatureheads.cc" file instead of using the "noteheads.cc" functionality. However, it turned out that almost all of the functionality of noteheads.cc would have to be cloned. Even worse, some other parts of lily call methods in noteheads.cc (at least in earlier versions of lily they did; I have not checked for recent versions). That is, when introducing a "ligatureheads.cc" I would have to add calls to methods in "ligatureheads.cc" all around the existing code, which would also pollute the code; i.e. introducing a "ligatureheads.cc" is not a solution. Subclassing "noteheads.cc" did not work for some technical detail that I currently can not remember. The easiest solution that I can see is to tolerate little polution of "noteheads.cc" and just add the missing interface declaration at the end of this file. However, that's not my decision... Any comments to solve this problem are welcome; however, my time is currently extremely limited (still writing on my thesis and running out of time...), so I currently can contribute only cosmetic changes, if at all. By the way, the particular warning "programming error: Grob `NoteHead' has no interface for property `text'" does not origin from ancient notation, as far as I can see. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python path
Manuzhai escreveu: On 11/6/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: our python is rather wobbly. Chances are that the installed version is a native python , and would work better. But unless you have some way to fix this, the other installed Python will not have Lilypond's modules in it's site-packages, right? So it wouldn't work at all... It should work, because the LilyPond scripts modify PYTHONPATH appropriately. Or at least, it should work. I don't have a windows machine to test this out (and frankly: I'm glad I don't). We'd be very glad with someone who has the tenacity and know how to build LilyPond for and test on Windows32. Also, I wonder what would make the Lilypond version "wobbly". We cross-compile Python on a linux box, using the MinGW GCC compiler. All sorts of things tend to go wrong when creating when creating python modules from windows DLLs. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
ghostscript bug with Luxi Mono
Han-Wen, You might follow this bug (I've CCed you in the bugzilla): http://bugs.ghostscript.com/show_bug.cgi?id=688982 It might be a good idea to not use LuxiMono in the two lilypond regression files... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
`Vera Bold' replaced by `AlbanyAMT-Bold'
Inspite of explicitly selecting `Vera Bold' (in file font-name.ly), lilypond gets a wrong font on my system: It uses `AlbanyAMT-Bold' instead. Bad, bad. This is pango 1.4.0, together with fontconfig 2.3.2. Doing some tests with fc-match, I get this: fc-match "Vera" -> albw.ttf: "Albany AMT" "Regular" fc-match "Bitstream Vera Serif" -> VeraSe.ttf: "Bitstream Vera Serif" "Roman" fc-match "Bitstream Vera Serif:style=Bold" -> VeraSeBd.ttf: "Bitstream Vera Serif" "Bold" Hm, hm. I don't consider this user-friendly. fontconfig should look up substrings IMHO before trying a completely different font. Is this a problem on my side? Is my fontconfig version too old? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
Juergen Reuter escreveu: One theoretical solution would be to introduce a new "ligatureheads.cc" file instead of using the "noteheads.cc" functionality. However, it turned out that almost all of the functionality of noteheads.cc would > have to be cloned. Even worse, some other parts of lily call methods in > noteheads.cc (at least in earlier versions of lily they did; I have not This might have been true when you added this stuff (~ 4 years ago, I think), but nowadays, note-head.cc has 7 routines, of which 3 aren't used anywhere else. For good measure, I just removed Note_head::get_balltype() as well. The other routines have to do with stem attachments, which aren't applicable to ligatures anyway. The easiest solution that I can see is to tolerate little polution of "noteheads.cc" and just add the missing interface declaration at the end of this file. However, that's not my decision... I think that this is going about the problem in the wrong way. Given how much lily has changed over the years, the proper solution IMO is to redo the ligature stuff completely. IF my hunches are correct, most of the code will collapse and disappear because of improvements in the rest of LilyPond. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context aliases
Erik Sandberg escreveu: hi, In my quest for softcoding context-defs, I will need to revisit the \alias system. This is not on the top of my todo, but I'd like to hear any protests early. I suggest that the \alias mechanism is scrapped altogether, and replaced with something else: - junk Bottom alias, instead make is_bottom_context accessible from scheme. - other aliases are replaced with appropriate boolean context properties, with more intuitive names (e.g. property 'isLyricMelody replaces current \alias Voice). I think this will be an improvement, because we remove the concept of aliases, which confuses users (at least it confuses me a bit); in addition we don't need to do anything extra to softcode aliases. I don't understand. How will this work in practice? Ie. if I do \set Timing.measurePosition = #.. how will it be processed? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ghostscript bug with Luxi Mono
Werner LEMBERG escreveu: Han-Wen, You might follow this bug (I've CCed you in the bugzilla): http://bugs.ghostscript.com/show_bug.cgi?id=688982 It might be a good idea to not use LuxiMono in the two lilypond regression files... This doesn't happen with GS rev. 7120, and neither with TTF patches for GS 8.15. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `Vera Bold' replaced by `AlbanyAMT-Bold'
Werner LEMBERG escreveu: Is this a problem on my side? Is my fontconfig version too old? This is a fontconfig problem, and should be reported over there. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ghostscript bug with Luxi Mono
> > It might be a good idea to not use LuxiMono in the two lilypond > > regression files... > > This doesn't happen with GS rev. 7120, and neither with TTF patches > for GS 8.15. OK, I've just checked out the SVN and will use it. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `Vera Bold' replaced by `AlbanyAMT-Bold'
> > Is this a problem on my side? Is my fontconfig version too old? > > This is a fontconfig problem, and should be reported over there. Hmm. What do you get with fc-match? Just for comparison purposes. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `Vera Bold' replaced by `AlbanyAMT-Bold'
Werner LEMBERG escreveu: Is this a problem on my side? Is my fontconfig version too old? This is a fontconfig problem, and should be reported over there. Hmm. What do you get with fc-match? Just for comparison purposes. [EMAIL PROTECTED] lilypond]$ fc-match Vera DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book" [EMAIL PROTECTED] fonts]$ grep -i Albany /etc/fonts/*/* conf.avail/30-amt-aliases.conf: Albany AMT conf.avail/40-generic.conf: Albany AMT conf.avail/60-latin.conf: Albany AMT conf.d/30-aliases-fedora.conf: Albany conf.d/30-aliases-fedora.conf: Albany AMT conf.d/30-aliases-fedora.conf:Albany conf.d/30-aliases-fedora.conf:Albany AMT conf.d/30-aliases-fedora.conf:Albany conf.d/30-aliases-fedora.conf:Albany AMT conf.d/30-aliases-fedora.conf:Albany conf.d/30-aliases-fedora.conf:Albany AMT conf.d/30-aliases-fedora.conf:Albany AMT conf.d/30-aliases-fedora.conf:Albany conf.d/30-amt-aliases.conf: Albany AMT conf.d/40-generic.conf: Albany AMT conf.d/60-latin.conf: Albany AMT -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote: Juergen Reuter escreveu: One theoretical solution would be to introduce a new "ligatureheads.cc" file instead of using the "noteheads.cc" functionality. However, it turned out that almost all of the functionality of noteheads.cc would have to be cloned. Even worse, some other parts of lily call methods in noteheads.cc (at least in earlier versions of lily they did; I have not This might have been true when you added this stuff (~ 4 years ago, I think), but nowadays, note-head.cc has 7 routines, of which 3 aren't used anywhere else. For good measure, I just removed Note_head::get_balltype() as well. The other routines have to do with stem attachments, which aren't applicable to ligatures anyway. Ok, I will eventually check. (BTW, I suspect there are a bunches of unused #include's that could be removed...) The easiest solution that I can see is to tolerate little polution of "noteheads.cc" and just add the missing interface declaration at the end of this file. However, that's not my decision... I think that this is going about the problem in the wrong way. Given how much lily has changed over the years, the proper solution IMO is to redo the ligature stuff completely. Mmmh, but how? Given, that things have changed, as you state, do you think there should be a completely new "ligatureheads.cc"? If so, should I clone the print and internal_print methods or rather try to create a subclass? I think a ligature primitive _is_ a special note head, so modeling it as a subclass does not sound bad, even if stems are not used. IF my hunches are correct, most of the code will collapse and disappear because of improvements in the rest of LilyPond. I don't think so. Most of the code is about matching grobs and moving them from different paper columns into a single one, determining the correct glyph for each notehead by evaluating local and neighbour heads' properties, adding new grobs (such as vertical lines) in the right place, collecting dots from different heads in different paper columns and moving them into a single dot column (I am already using DotColumn!), etc. I do not see any similar code elsewhere, so I am confident that the code would not remarkably collapse. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
Juergen Reuter escreveu: The easiest solution that I can see is to tolerate little polution of "noteheads.cc" and just add the missing interface declaration at the end of this file. However, that's not my decision... I think that this is going about the problem in the wrong way. Given how much lily has changed over the years, the proper solution IMO is to redo the ligature stuff completely. Mmmh, but how? Given, that things have changed, as you state, do you think there should be a completely new "ligatureheads.cc"? If so, should I clone the print and internal_print methods or rather try to create a subclass? I think a ligature primitive _is_ a special note head, so modeling it as a subclass does not sound bad, even if stems are not used. The formatting backend doesn't use subclassing at all, except for the spanner vs. item distinction. Therefore, subclassing by definition is the wrong approach. How to organize code should be decided by looking which code is shared. This is easiest to find out by first writing the code independently from the existing code, and then collapsing the common parts. Without knowing the details, I think it is easiest to define a LigatureNoteHead or XLigatureNoteHead, and a XxxxLigature in define-grobs.scm. (X = Gregorian, Vaticana, Coherent, Mensural) By copying some definitions of the NoteHead grob, some C++ of Note_head can be shared. A special XXX_Ligature engraver will create those heads, and arrange them correctly within the appropriate XxxxLigature. If the XLigature is an Item, then it will be on a single PaperColumn. By putting the XxxxNoteHeads on the XLigature Item, the notes will also be on the same PaperColumn. The XxxxLigature knows all of the ligature contents, and hence, it can determine the final desired shape. IF my hunches are correct, most of the code will collapse and disappear because of improvements in the rest of LilyPond. I don't think so. Most of the code is about matching grobs and moving them from different paper columns into a single one, determining the correct glyph for each notehead by evaluating local and neighbour heads' properties, adding new grobs (such as vertical lines) in the right place, collecting dots from different heads in different paper columns and moving them into a single dot column (I am already using DotColumn!), etc. Moving stuff around between paper columns should not be done in the typography backend. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further GUB problems
Jan Nieuwenhuizen escreveu:
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
undefined reference to [EMAIL PROTECTED]'
It seems that libgmp.so in local was linked against another libc than
the libc we're linking against now. Can you check the libc.* files
in local/system/usr/lib and linux-64/system/usr/lib, esp. look for any
symlinks pointing to /.
As Han-Wen says, can you try a realclean build?
I can reproduce this now, hold on.
>
HW: yesterday I just did a real clean build on oliebij (x86), using
lily from CVS, from repo did not compile:
make bootstrap
GUB_CVS=1 make download native BRANCH=HEAD
... boom
Curious. This must be a debian/ubuntu vs. Fedora problem. This is what
I need to compile afresh over here, with
GUB_CVS=1 make BUILD_PLATFORM=linux-x86 PLATFORMS=linux-x86 BRANCH=HEAD
bootstrap
GUB_CVS=1 make BUILD_PLATFORM=linux-x86 PLATFORMS=linux-x86 BRANCH=HEAD
download native
[EMAIL PROTECTED] gub]$ darcs whatsnew
{
hunk ./lib/debian.py 98
-libc6_version = '2.3.6.ds1-4'
+libc6_version = '2.3.6.ds1-7'
hunk ./lib/repository.py 347
-if not os.path.isdir (dir):
-self.system ('mkdir -p %s' % dir)
+if not os.path.isdir (self.repo_dir):
+self.system ('mkdir -p %s' % self.repo_dir)
}
Jan.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further GUB problems
Jan Nieuwenhuizen escreveu: make bootstrap GUB_CVS=1 make download native BRANCH=HEAD ... boom what kind of boom are we talking about now? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote: The formatting backend doesn't use subclassing at all, except for the spanner vs. item distinction. Therefore, subclassing by definition is the wrong approach. How to organize code should be decided by looking which code is shared. This is easiest to find out by first writing the code independently from the existing code, and then collapsing the common parts. Without knowing the details, I think it is easiest to define a LigatureNoteHead or XLigatureNoteHead, and a XxxxLigature in define-grobs.scm. (X = Gregorian, Vaticana, Coherent, Mensural) By copying some definitions of the NoteHead grob, some C++ of Note_head can be shared. A special XXX_Ligature engraver will create those heads, and arrange them correctly within the appropriate XxxxLigature. If the XLigature is an Item, then it will be on a single PaperColumn. By putting the XxxxNoteHeads on the XLigature Item, the notes will also be on the same PaperColumn. The XxxxLigature knows all of the ligature contents, and hence, it can determine the final desired shape. Ok, this may work provided that there is no code elsewhere in lily that receives grobs, looks into them and does some things if and only if this grob is a NoteHead. Otherwise, this code would not apply to ligature heads, thus failing special treatment of note heads that should also apply on ligature heads. I actually tried this approach a couple of years ago, and it did not work for this reason. Of course, lily has changed dramatically since then; probably I should try again. IF my hunches are correct, most of the code will collapse and disappear because of improvements in the rest of LilyPond. I don't think so. Most of the code is about matching grobs and moving them from different paper columns into a single one, determining the correct glyph for each notehead by evaluating local and neighbour heads' properties, adding new grobs (such as vertical lines) in the right place, collecting dots from different heads in different paper columns and moving them into a single dot column (I am already using DotColumn!), etc. Moving stuff around between paper columns should not be done in the typography backend. Sorry, I was imprecise. Moving stuff around between paper columns is done in the engravers, of course. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
Juergen Reuter escreveu: Ok, this may work provided that there is no code elsewhere in lily that receives grobs, looks into them and does some things if and only if this grob is a NoteHead. Otherwise, this code would not apply to ligature heads, thus failing special treatment of note heads that should also apply on ligature heads. I actually tried this approach a couple of years ago, and it did not work for this reason. Of course, lily has changed dramatically since then; probably I should try again. this is usually done by inspecting whether the 'interfaces property contains 'note-head-interface -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further GUB problems
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> ... boom
>
> what kind of boom are we talking about now?
There is problem with the linker path, that creates a mix between
libraries in local and linux-x86.
linux-x86's config.log says:
configure:8612: i686-linux-gcc
-I/home/janneke/bzr/gub/target/linux-x86/build/lilypond-origin -o conftest
-O2 -finline-functions -g -pipe
-I/home/janneke/bzr/gub/target/linux-x86/system/usr/include
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/bin
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib/w32api -Wl,--as-needed
-Wl,--rpath,'$${ORIGIN}/../lib/' conftest.c -lguile
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib -lguile -lgmp -ldl >&5
conftest.c:8:1: warning: "PACKAGE_NAME" redefined
conftest.c:2:1: warning: this is the location of the previous definition
/home/janneke/bzr/gub/target/local/system/usr//lib/libgmp.so.3: undefined
reference to [EMAIL PROTECTED]'
ie, while linking to guile (-lguile), which *should* be
target/linux-x86/system/usr/lib/libguile.la (.so)
we get an error about gmp in *local*. Of course libgmp (and libguile)
in local is linked against /usr/lib/libc; while gmp, guile in linux-x86
are linked against linux-86/syste/usr/lib/libc.
If you do not see it, chances are that your libc versions are
compatible, but you'll still linking the wrong libraries.
One step further: if I try the link command manually, it works:
$ target/linux-x86/system/usr/cross/bin/i686-linux-gcc
-I/home/janneke/bzr/gub/target/linux-x86/build/lilypond-origin -O2
-finline-functions -g -pipe
-I/home/janneke/bzr/gub/target/linux-x86/system/usr/include
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/bin
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib/w32api -Wl,--as-needed
-Wl,--rpath,'$${ORIGIN}/../lib/' ugh.c -lguile
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib -lguile -lgmp -ldl
so configure is called with an environment setting (LDFLAGS?) that
makes gcc look in local.
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further GUB problems
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
> so configure is called with an environment setting (LDFLAGS?) that
> makes gcc look in local.
The problem is LD_LIBRARY_PATH.
$ LD_LIBRARY_PATH=/home/janneke/bzr/gub/target/local/system/usr/lib
target/linux-x86/system/usr/cross/bin/i686-linux-gcc
-I/home/janneke/bzr/gub/target/linux-x86/build/lilypond-origin -O2
-finline-functions -g -pipe
-I/home/janneke/bzr/gub/target/linux-x86/system/usr/include
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/bin
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib/w32api -Wl,--as-needed
-Wl,--rpath,'$${ORIGIN}/../lib/' ugh.c -lguile
-L/home/janneke/bzr/gub/target/linux-x86/system/usr/lib -lguile -lgmp -ldl
/home/janneke/bzr/gub/target/local/system/usr/lib/libgmp.so.3: undefined
reference to [EMAIL PROTECTED]'
collect2: ld gaf exit-status 1 terug
We have a bit of a problem here. For all tools (from local) that we run,
LD_LIBRARY_PATH must to point to local (first), but during link time
it must be unset (or point to linux-x86, but the cross compile will do
that for us).
So, either we wrap all executables in local, or we call the cross compiler
`LD_LIBRARY_PATH= i686-linux-gcc'.
Jan.
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: warnings during `make web'
On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote: Juergen Reuter escreveu: Ok, this may work provided that there is no code elsewhere in lily that receives grobs, looks into them and does some things if and only if this grob is a NoteHead. Otherwise, this code would not apply to ligature heads, thus failing special treatment of note heads that should also apply on ligature heads. I actually tried this approach a couple of years ago, and it did not work for this reason. Of course, lily has changed dramatically since then; probably I should try again. this is usually done by inspecting whether the 'interfaces property contains 'note-head-interface Ah, ok. This is valuable information to know! Thanks! Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python path
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: >> Also, I wonder what would make the Lilypond version "wobbly". > > We cross-compile Python on a linux box, using the MinGW GCC > compiler. All sorts of things tend to go wrong when creating when > creating python modules from windows DLLs. Wobbly or not, it works and we have some sort of control over it. We have absolutely no idea what the python in front of the path is? The question is: how much do we want to make sure that lilypond just works after installation, and how much do we want to break someone's python preference? Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further GUB problems
Jan Nieuwenhuizen escreveu: So, either we wrap all executables in local, or we call the cross compiler `LD_LIBRARY_PATH= i686-linux-gcc'. the latter is the quickest fix, I presume. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python path
Jan Nieuwenhuizen escreveu: The question is: how much do we want to make sure that lilypond just works after installation, and how much do we want to break someone's python preference? The breakage would occur with people that have python installed themselves; I think it's safe to assume that they (should) be able to cope with a semi-functional lilypond python scripts. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context aliases
On Monday 06 November 2006 13:04, Han-Wen Nienhuys wrote: > Erik Sandberg escreveu: > > hi, > > > > In my quest for softcoding context-defs, I will need to revisit the > > \alias system. This is not on the top of my todo, but I'd like to hear > > any protests early. > > > > I suggest that the \alias mechanism is scrapped altogether, and replaced > > with something else: > > - junk Bottom alias, instead make is_bottom_context accessible from > > scheme. - other aliases are replaced with appropriate boolean context > > properties, with more intuitive names (e.g. property 'isLyricMelody > > replaces current \alias Voice). > > > > I think this will be an improvement, because we remove the concept of > > aliases, which confuses users (at least it confuses me a bit); in > > addition we don't need to do anything extra to softcode aliases. > > I don't understand. How will this work in practice? Ie. if I do > >\set Timing.measurePosition = #.. > > how will it be processed? We will have to change that to an \applyContext which finds/creates a context with the 'timing property set, something like \findContextWithPredicate #'timing \set measurePosition = #... -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context aliases
Erik Sandberg escreveu: I think this will be an improvement, because we remove the concept of aliases, which confuses users (at least it confuses me a bit); in addition we don't need to do anything extra to softcode aliases. I don't understand. How will this work in practice? Ie. if I do \set Timing.measurePosition = #.. how will it be processed? We will have to change that to an \applyContext which finds/creates a context with the 'timing property set, something like \findContextWithPredicate #'timing \set measurePosition = #... I still don't understand why you want to scrap it. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beam breaking in tuplets
On Monday 06 November 2006 12:59, Mats Bengtsson wrote:
> Erik Sandberg wrote:
> > On Monday 06 November 2006 09:25, Mats Bengtsson wrote:
> >
> > Mats, do you think it would be useful with an operator \newClone to clone
> > the current context? E.g.
> > \new Staff \with {\consists Foo_engraver bar=#'baz}
> > { c d \tiny e f \newClone Staff { g f e d} c d e }
> > would be equivalent to:
> > \new Staff \with {\consists Foo_engraver bar=#'baz}
> > { c d \tiny e f \new Staff \with {\consists Foo_engraver bar=#'baz} {
> > \tiny g f e d} c d e }
> >
> > (I think such operator can come out as a side-effect of some work I'm
> > doing)
>
> Would it even make sense to make this the default behaviour of \new?
> At least, it would probably cause less surprise to a newbie than the
> current implementation, in examples like:
> \relative c'{ \tiny c d <<{e d} \\ {c b}>> }
You have a point here. Perhaps we could have a context property
cloneNewContexts, defaulted to #t for voices, which makes sure that contexts
creations in the current context clone the current context, if the context
types match. (so below, the context hierarchy would be Global-Score-Lyrics
where the inner Voice is created, hence no settings would be inherited; this
also means that the inner \new Voice should create a new staff implicitly).
I think the difficult thing is that the syntactical hierarchy of our input
language doesn't match the hierarchy of contexts.
> On the other hand, it would probably make it less obvious for the advanced
> user to predict exactly what LilyPond does, for example in situations like
>
> \relative c' \new Voice{
> c d e f
> <<
> c1
> \new Lyrics \lyricmode {
> Some4 text
> << \new Voice \notemode { c d e2 }
> {some more text }
>
> }
>
> }
> where it's not obvious if the inner Voice context would inherit anything
> from the outer one (maybe this is already crystal clear to you).
--
Erik
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `Vera Bold' replaced by `AlbanyAMT-Bold'
> > Hmm. What do you get with fc-match? Just for comparison purposes. > > [EMAIL PROTECTED] lilypond]$ fc-match Vera > DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book" Ah, ok, so you also don't get `Vera'. This is good to know. And which font is finally used in your environment for font-name.ly? If you don't get Vera Bold, we should either not say This text is large Vera Bold or fix the font name to get a proper result. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `Vera Bold' replaced by `AlbanyAMT-Bold'
Werner: > > > Hmm. What do you get with fc-match? Just for comparison purposes. > > [EMAIL PROTECTED] lilypond]$ fc-match Vera > > DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book" > Ah, ok, so you also don't get `Vera'. This is good to know. ... Don't be too happy: $ fc-match Vera Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman" $ fc-match Albany Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman" $ fc-match DejaVu Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman" $ fc-match courie Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman" $ fc-match courier cour.pfa: "Courier" "Regular" $ fc-match --version fontconfig version 2.4.1 Seems that vera is something of a default over here. Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: documentation translation
Le dimanche 05 novembre 2006 à 15:02 -0800, Graham Percival a écrit : > John Mandereau wrote: > > A number of French users have created a page or a section about Lily on > > their personal sites, sometimes with briliant ideas and words explaining > > what LilyPond is and does. That's great and bad at the same time. It's > > great because this work is independent from the LilyPond team, and > > therefore berings more different points of view; and it's bad because it > > certainly doesn't have the audience of lilypond.org. > > I recognize your point about having more different points of view... but > if more people joined the devel team, we could have those different > points of view from the outset. Of course. I hope I manage to convince the authors of these pages to contribute to the docs. I would be glad to join the devel team, but I'm very busy with mathematics and oboe studies. My current participation to LilyPond is: - maintaining French translation of lilypond.org and LilyPond messages (very little work actually) - administrating and moderating the [EMAIL PROTECTED] list (essentially spam filtering and replies on general issues) - (in progress) extending makefiles and writing scripts to make posible a translation of the user manual integrated with the English one. When the latter is done, I will manage translation of the user manual, which means at least checking translations and committing them to cvs. I can't take other LilyPond jobs for the coming months. All this benefits the French-speaking community, but I'm sure it will benefits the entire community sooner or later thanks to reciprocal translation, too. > > It might be worth > > encouraging these authors to contribute to the French docs, and/or > > creating a "Planet LilyPond" page listing links to these sites. > > Is the market big enough? -- I mean, are there _so_ many pages that > it's impossible to incorporate their useful documentation material into > the main manual? (this is my view on the wiki: there aren't enough > people contributing to it to really make it worthwhile) No, certainly not. Computer music notation is a very specialized work, it will always have less users than word processors. So to be the most efficient, the community should ideally not be too spread out, but very close to the devel team. > For example, consider Geoff Horton's lilypond lyrics page. I haven't > seen it recently (and I don't have an internet connection at the > moment), but my impression was that if somebody spent a two hours > integrating that material into the current docs, Geoff's page would be > unnecessary. (The only reason I haven't done that is that I don't do > lyrics) Sorry, I have neither done any yet, so I currently can't do anything for that. > In the case of the French pages, I suppose that I _could_ integrate them > (I haven't spoken or read French for ten years, but I was fluent before > that))... but I'm having enough trouble keeping up with the main doc > stuff and bug reports. Don't worry about this: if a French piece of documentation that's not a translation from English is added, I'll submit it to you, in English of course! > It would be nice if we had a "Translation Doc Helper" -- somebody who > looked for good doc tips in other languages and translated them into > English so we could include them in the manual. Any volunteers? There can't be only one "Translation Doc Helper" as soon as the docs are in many languages, there should be one per language instead. I may take the "French Translation Doc Helper" job when the makefiles infrastructure for translating the user manual is done (I've been working on this for a few days and that's not finished...). Cheers, -- John Mandereau <[EMAIL PROTECTED]> ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `Vera Bold' replaced by `AlbanyAMT-Bold'
> > > > Hmm. What do you get with fc-match? Just for comparison purposes. > > > [EMAIL PROTECTED] lilypond]$ fc-match Vera > > > DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book" > > Ah, ok, so you also don't get `Vera'. This is good to know. > ... > > Don't be too happy: > > $ fc-match Vera > Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman" > $ fc-match Albany > Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman" > > [...] This is OK. My very concern was whether asking for `Vera Bold' *must* return the Vera font, and this assumption was wrong. That we all have different defaults if the font name doesn't match exactly is a Linux distribution thing. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
CVS 2006-Nov-11 22:30 MET compilation error
Processing `/home/wl/cvs/lilypond.compiled/ly/generate-documentation.ly' Parsing...[...][scm/document-backend.scm error: define-grob-properties.scm: can't find interface for property: balloon-text Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: documentation translation
Francisco Vila wrote: > I'd like to start the translation of all docs to spanish. I beg your > advice on how to easily do this, in a manner that it keeps being > integrated with new developments. > > - which files to translate and what parts of them > - what to do with the translated files, who I have to send them to, > > et cetera > > Thanks! > > Is there already a spanish team doing this?? As far as I can see, there isn't: 1) es.po (that's the file containing Spanish translation of LilyPond binaries messages on screen output) from latest CVS says: "PO-Revision-Date: 2002-06-28 15:46CET\n" "Last-Translator: Quique <[EMAIL PROTECTED]>\n" 2) no page is translated in Spanish on lilypond.org 3) there is currently no dedicated infrastructure to translate the docs, but keep an eye on this list, because I will send a partial patch for this in the coming days. You can always translate the current docs by replacing the Encglish sources with their translation. We (the French translators) have tried once, and it isn't very statisfying. I may suggest you to start with 1) and 2) as you like, and wait for 3)? The developers may also give you instructions. Resources (assuming you have a box with a Unix-like shell, cvs, make, a good text editor, ...): 1) edit the es.po file from CVS repository ( http://savannah.gnu.org/cvs/?group=lilypond ; get module lilypond), with vim, emacs or kbabel for example. 2) get lilypond.org sources (module newweb from the CVS repository), and follow instructions in README, TRANSLATION and http://lilypondwiki.tuxfamily.org/index.php?title=Translations_HOWTO Good luck! A French translator -- John Mandereau <[EMAIL PROTECTED]> ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CVS 2006-Nov-11 22:30 MET compilation error
Fixed in CVSErlendOn 11/6/06, Werner LEMBERG <[EMAIL PROTECTED]> wrote: Processing `/home/wl/cvs/lilypond.compiled/ly/generate-documentation.ly'Parsing...[...][scm/document-backend.scmerror: define-grob-properties.scm: can't find interface for property: balloon-text Werner___lilypond-devel mailing listlilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CVS 2006-Nov-11 22:30 MET compilation error
Erlend Aasland escreveu: Fixed in CVS this was actually fixed in GIT some time ago, see http://repo.or.cz/w/lilypond.git?a=commit;h=db1423b71d013ba9ef07a74ddf15e16e6e6b4368 the plan is to move asap to GIT on savannah.gnu.org but this still is pending some technical issues (not in the last place getting GUB to work smoothly with a distributed VC scheme). I try to put the GIT fixes back in CVS regularly, but don't do it every hour. Until that time, please check http://repo.or.cz/w/lilypond.git before committing any fixes to CVS. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python path
My experience is that the native Python installation has always worked better than the python bundled with LilyPond, so for that reason I don't see any problems to move lilypond to the end of the PATH. However, I'm more worried about Ghostscript dependencies, especially if the user happens to have Cygwin included in the PATH (I'm not sure how common that is, though). The native Windows Ghostscript executable is called gswin32.exe so that shouldn't be a problem, though. /Mats Jan Nieuwenhuizen wrote: Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: Also, I wonder what would make the Lilypond version "wobbly". We cross-compile Python on a linux box, using the MinGW GCC compiler. All sorts of things tend to go wrong when creating when creating python modules from windows DLLs. Wobbly or not, it works and we have some sort of control over it. We have absolutely no idea what the python in front of the path is? The question is: how much do we want to make sure that lilypond just works after installation, and how much do we want to break someone's python preference? Jan. -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context aliases
On Monday 06 November 2006 17:02, Han-Wen Nienhuys wrote: > Erik Sandberg escreveu: > >>> I think this will be an improvement, because we remove the concept of > >>> aliases, which confuses users (at least it confuses me a bit); in > >>> addition we don't need to do anything extra to softcode aliases. > >> > >> I don't understand. How will this work in practice? Ie. if I do > >> > >>\set Timing.measurePosition = #.. > >> > >> how will it be processed? > > > > We will have to change that to an \applyContext which finds/creates a > > context with the 'timing property set, something like > > \findContextWithPredicate #'timing \set measurePosition = #... > > I still don't understand why you want to scrap it. The main reason is to have one event less in the stream API (if we will keep the current alias mechanism, I will have to create an add-alias stream event). IWBN to keep that API minimal, and to me it seems that aliases aren't much used anyways. However, you have a very point that functions like \applyoutput will get more complicated if we want to keep full backward compatibility. -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
