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 t
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 insta
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
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_
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, cro
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
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 lis
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
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
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 Bo
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 p
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.l
> > 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
___
lily
> > 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
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: "DejaV
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 cl
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 m
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/sys
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 mailin
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
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 th
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/
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
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, t
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
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 M
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
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 \alia
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
\
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
> > 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?
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-Ver
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
> > > > 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
> B
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-
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
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__
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 p
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 ha
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 alias
40 matches
Mail list logo
