Re: (Not) mentioning that URW fonts are distributetd with LilyPond
Hi, On Thu, Oct 26, 2023 at 09:36:24PM +0200, Jean Abou Samra wrote: > > https://lilypond.org/doc/v2.25/Documentation/notation/font-families > > > > still claims that LilyPond still includes URW fonts, which it doesn't > > since 2.24. > > It does — otherwise, they could not be set as the default fonts. > > If you're thinking about the change mentioned > on > http://lilypond.org/doc/v2.24/Documentation/changes/index.html#notes-for-source-compilation-and-packagers > , it only means that LilyPond's build system will not take care of installing > text fonts by itself anymore. Thanks. > Redistributors need to do that by themselves > (which they probably already wanted to do, for deduplication between > packages). > In this way of thinking, the scripts that generate the binaries distributed on > lilypond.org are a "redistributor", and indeed they do package the fonts. I think I'll just add the URW fonts to the lilypond package for now (doing an update of it for OpenBSD). Ciao, Kili
(Not) mentioning that URW fonts are distributetd with LilyPond
Hi, https://lilypond.org/doc/v2.25/Documentation/notation/font-families still claims that LilyPond still includes URW fonts, which it doesn't since 2.24. I'm not sure wether it's ok to just remove the 'distributed with LilyPond' in the corresponding paragraph or wether this would let people wonder why the URW fonts are mentioned at all. That paragraph is still useful, so completely removing it would probably not the best option. Any thoughts or suggestions? Ciao, Kili
Re: grand copyright replacement
On Fri, Jan 25, 2019 at 07:43:10AM +0100, Werner LEMBERG wrote: > I'm going to run `scripts/build/grand-replace' to update all copyright > years. I'm not completely sure, but shouldn't the copyright year(s) in a work only cover the years when the work was originally written or modified? Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
On Tue, Aug 09, 2011 at 04:26:00PM +0100, Wols Lists wrote: > > out/parser.cc:2392: warning: conversion to 'short int' from 'int' may > > alter its value [...] > [...] That "out/parser" is a perfect example - it *may* > be innocuous, or it *may* be a serious problem. It really ought to be > checked out and fixed, and if I were a boss, I would have no qualms > whatever about saying "fix it". It depends on the bison version. I don't get this warning with bison-2.3. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
On Tue, Aug 09, 2011 at 04:34:57PM +0100, Phil Holmes wrote: > >I'm afraid I'm with Reinhold. As a *programmer*, I consider it very bad > >practice to ignore warnings. For the system to hide them from me, well !!! > > > They're not being ignored. They're not even being seen. Please address my > point of how you would see them in 37,000 lines of console output. Many people are building *any* large projects with something like make 2>&1 | tee m.log and then look at m.log after the build. I do so, and I do so by default. When building distribution packages for OpenBSD, I also log the complete output of extracting, patching, configuring, building and installing and look at that log file. I won't look at any project specific logfiles. Important stuff *has* to go to stdout or stderr. If every project would invent its own way to hide important messages from stdout/stderr *by default* and put them into project specific logfiles, it would a hell for everyone who's porting those project to specific operating system distributions. I don't want to have to look *where* too look for warnings and errors. However, the normal build output won't be touched, as Graham wrote. It's only about the doc output for now, if I understood Graham correctly. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Sun, Jul 10, 2011 at 01:10:05PM +0200, Reinhold Kainhofer wrote: > But we don't solve the problem of the log output. I mean, how many people > really **want** the full output from the build system? What about a *default* output similar to what you now get with QUIET_BUILD=1? That is currently a little bit too quiet (for example, it hides ghostscript invocations), but with the missing bits added, would people really miss something? Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Sun, Jul 10, 2011 at 11:53:08AM +0100, Phil Holmes wrote: > >Little bit difficult as it seems, so here's a simple version (without > >the combined log). You can invoke it like this: > > > >lilylog.sh o.log e.log ls -l . dontexist > > > >which is the `verbose' mode (i.e. you still see stdout and stderr, but > >both get logged to the given files) or like this: > > > >lilylog.sh -q o.log e.log ls -l . dontexist > > > >which is the `quiet' mode (output goes only to the files). > > Could you explain for someone with no Unix background what this does, > please? Well, it lets you run a command, logging stdout and stderr to the logfiles given in the first two arguments, and exits with the same exit code as the cmmand did. Unless you invoke it with -q, you'll also see stdout and stderr on your screen as usual. The idea is to tweak the build system to run commands that produce too much output with this script instead, so you get less output, and, in case of a failure, get a message which log files too look at. Unfortunately, I still didn't get enough time to hack on the build system itself. Also, it looks like there are different opinions of wether to split stdout and stderr into two different log files or not. (personally, I'd just go with a single file, which would also simplify my script much). Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Fri, Jul 08, 2011 at 08:24:37AM +0200, Jan Nieuwenhuizen wrote: > Almost right. However, try not to invent something new. Please just > use the autoconf/automake behaviour, which follows mostly the convention > that Linux and Git git have set. > >http://www.gnu.org/s/hello/manual/automake/Options.html > > To summarize > > the user of the package may influence the verbosity at configure run > time as well as at make run time: > > * Passing --enable-silent-rules to configure will cause build rules to > be less verbose; the option --disable-silent-rules is the default and > will cause normal verbose output. > > [we could change this default] Please no. The problem with the too verbose build output in lilypond is not related at all to the *make* output, IMHO. --enable-silent-rules only hides crucial information. Heck, at OpenBSD we even spent time to force --disable-silent-rules on all software packages by default, because it just sucks if a build fails and you don't see the exact command line parameters passed to the compiler or the linker. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Thu, Jul 07, 2011 at 02:59:37PM +0200, Matthias Kilian wrote: > Wouldn't it be better to either collect both stdout and stderr in > the same log file or to use three log files .err.log, .out.log and > .log, where the latter contains the combined streams? Otherwise you are > loosing the context between the two, which sometimes may be important. Little bit difficult as it seems, so here's a simple version (without the combined log). You can invoke it like this: lilylog.sh o.log e.log ls -l . dontexist which is the `verbose' mode (i.e. you still see stdout and stderr, but both get logged to the given files) or like this: lilylog.sh -q o.log e.log ls -l . dontexist which is the `quiet' mode (output goes only to the files). If the command given fails (exit code != 0) so does this script. In addition, it writes (to stderr) the command that failed and the logfiles. Ciao, Kili ps: i usually use tabs in my scripts, but as you guys obviously consider tabs evil, i've run expand(1) on it ;-) lilylog.sh Description: Bourne shell script ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Thu, Jul 07, 2011 at 01:16:21PM +0100, Graham Percival wrote: > * Wherever possible, stderr output should go to *.err.log and > stdout output to *.log Wouldn't it be better to either collect both stdout and stderr in the same log file or to use three log files .err.log, .out.log and .log, where the latter contains the combined streams? Otherwise you are loosing the context between the two, which sometimes may be important. (Now hacking on a simple script for doing such logging; similar to http://tratt.net/laurie/src/supuner/, but simpler and better matching lilypond needs) Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stdout vs. stderr (was: Patch: small reduction in output from make doc)
On Sat, Jun 25, 2011 at 05:27:03PM +0100, Graham Percival wrote: > 1. what's the official unix definition of STDERR vs. STDOUT? Quoting the standard: 3.358 Standard Error An output stream usually intended to be used for diagnostic messages. [...] 3.360 Standard Output An output stream usually intended to be used for primary data output. Of course, this definition is meant for typical unix command line tools, where you want to pipe the output of one program as input into another program and still see "diagnostic messages" from the first program. Lilypond is a little bit different. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace Tab with 8 Spaces for .py files (issue4627062)
[slightly offtopic tab size rant ;-)] On Fri, Jun 24, 2011 at 04:44:21PM +0100, Graham Percival wrote: > In the old/bad style that emacs produced, one tab was used to > represent 8 spaces. Yes, it was doubly confusing. Well, no. People and/or editors who used one tab per indentation level (and probably fiddling with the displayed *tab* width other than 8 spaces) where confused. Whenever I see any file that needs a tab width other than 8 spaces to display correctly (be it programs, be it configuration files), I get *very* upset. That said, as people today don't know the difference between tab width and indentation, it's still good to forbid tabs at all in lilypond ;-) Ciao, Kili ps: when I started working on unix (in the late 80ths), I abused tabs for indentation, too. But it took me only a few months to recognize that error. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: echo but return false in make (was: Logfiles from build)
On Fri, Jun 17, 2011 at 07:35:19PM +0100, Graham Percival wrote:
> > >Again, on the shell, it would be something like this:
> > > make ...blah... || echo "build failed" && tail logfile
> > >but there might be a nicer way to do it.
> >
> > but then when blah fails, make will not stop, since the return
> > status from echo && tail is a success (assuming the log file
> > exists). How would you return failure and force make to stop?
make ...blah... || { echo "build failed"; tail logfile; false; }
> Interesting, I hadn't considered that. Hmm, is there such a thing
> as functions in bach? If so, it would be easy to return something
> after doing the echo.
>
> Of course, we can't guaranteed that bash will be present... does
> sh(1) allow functions?
Of course. Shell functions are demanded by POSIX ;-)
> Or can we write functions in make, or stepmake? Or do the same
> thing with macros somehow, if make has
> macros but not functions?
Please don't. Fiddling with (gnu) make macros (which aren't real
macros but just variables `invoked' in a special way) doesn't make
the makefiles more readable.
What should be possible (I can work on this in about one and a half
week, when I've two weeks of vacation) is something like this:
RUN_CHECK_LOG = foo() { logfile=$1; shift; ...; } && foo
...
a_target:
${RUN_CHECK_LOG} a_target.log ${MAKE} whatever
where the `...' in the definition of foo() in RUN_CHECK_LOG would
execute "$@" (i.e. the remaining arguments to foo() after the log
file name had been shifted away), and do the echo/tail/false combo
if it failed.
> The short answer is that I cannot believe that we've exhausted all
> options yet. I want Phil to look into those options; of course I
> welcome any suggestions from people on this list. But off the top
> of my head, I'd say that we can't possibly say that we're out of
> ideas until we've spent at least 5 hours googling and/or reading
> documentation about make and/or experimenting with make and
> stepmake.
Just wait a few days until I've some spare time available to help
you with this, will you?
I'll also have to read all this `silence the build' mails more
closely, because silencing the build *in geneeral* is a very bad
idea. If this all is about locating failures during the lilypond
(which *is* difficult IIRC), then the build system may be the
completely wrong place. (I can remember spending hours on tracking
down some errors coming out of ghostscript or metafont or fontforge
some years ago). If this is the case, the tools should be fixed,
not the build system.
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting - probable decision
On Wed, Jun 15, 2011 at 12:11:37AM +0100, Graham Percival wrote: > There should be absolutely no tab characters for indentation in > any .py file in lilypond git. All such files should be converted > to use spaces only. I'd go a step further and recommend (for python files) that no tabs are used at all. Because, if you're using some editor like nvi or vim and set only shiftwidth to 4 (*enver ever set tabsize to something else than 8!*), you then just can pipe the whole buffer through expand(1) and you are done. If there were tabs in the file (other than in indentations), this would introduce spurious white space changes cluttering the diffs. NB: personally, I prefer a style where initial spaces are unexpanded to (8 column) tabs, regardless of the indentation, but unfortunately there are editors (and people) around that don't get the difference between indentation and tab width. Ciao, Kili ps: IIRC, the editor in eclipse is (or was?) an example for badly mixing up tab size and indentation. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] find(1) needs a path before any expression.
This unbreaks the build in a separate directory on OpenBSD.
---
stepmake/aclocal.m4 |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4
index c062247..8fe2ddd 100644
--- a/stepmake/aclocal.m4
+++ b/stepmake/aclocal.m4
@@ -406,7 +406,7 @@ EOF
fi
for d in 2 3 4 ; do
- for mf in `cd $srcdir ; find -maxdepth $d -mindepth $d -name
GNUmakefile`; do
+ for mf in `cd $srcdir ; find . -maxdepth $d -mindepth $d -name
GNUmakefile`; do
mkdir -p $(dirname $mf)
cat < $mf
print 'depth=' + ('../' * ( $d-1 ) )
@@ -415,7 +415,7 @@ print 'include \$(configure-srcdir)/$mf'
print 'MODULE_INCLUDES += \$(src-dir)/\$(outbase)'
EOF
done
- for mf in `cd $srcdir ; find -maxdepth $d -mindepth $d -name
'*.make' | grep -v config.make `; do
+ for mf in `cd $srcdir ; find . -maxdepth $d -mindepth $d -name
'*.make' | grep -v config.make `; do
mkdir -p $(dirname $mf)
cat < $mf
print 'include \$(depth)/config\$(if \$(conf),-\$(conf),).make'
--
1.7.3.5
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
[random notes from soneone who is *not* actively hacking on LilyPond, so feel free to ignore it ;-)] On Fri, Apr 15, 2011 at 03:29:52PM +0100, Graham Percival wrote: > The reason that I'm pessimistic is that we racked up a huge amount > of "technical debt" (i.e. bugs) during 2.11 and the early phase of > 2.13. I'm concerned that if we don't have regular releases, the > unstable branch is going to accumilate bugs. Well, I think I've written this a few months ago: (stable) releases *must* happen more often (at least one or two times a year) if you want to be able to cope with stable and unstable. > I am also too tired to fight over it right now, but I also think > that this is the wrong model of branching. There's basically two > ways: > 1. keep master in a "ready-to-release" mode at all times; any > serious bug gets reverted or fixed ASAP. Unstable development > happens on separate branches, which are merged to master when > they're ready. > 2. toss whatever garbage you want onto master, and make a "stable" > branch where a bunch of poor suckers cleans up the branch until > it's ready for a release. 1. is the way to go. Sure, it would put some pressure on people working on big changes, which kind of sucks (it could even slow down implementing cool new stuff). On the other hand, it enforces smaller steps towards new features, which is good (easier to track down regressions, easier to *understand* what's going on). For maintaining a stable branch and cherry picking: the more stable and master diverge, and the bigger the changes in master are, the more difficult merges will be. I'm note sure wether something like an "unstable" branch make sense at all, because it may encourage to do big changes diverging from master over a period too long to be mergable without problems later. Just my 2p. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond logging (Re: lilypond too noisy on the cmd line)
On Mon, Jan 03, 2011 at 06:16:08AM -0500, David Santamauro wrote: > The first thing that jumps out at me is Apache log4cxx. It is a robust > logging framework based on Java log4j. It introduces dependencies on > the apache portable runtime library That together makes 29708 lines of code just for logging, only including the unix specific parts of apr and not including tests, examples and build stuff (and not including comments, lines with only single opening or closing braces etc.). The (C++) parts of LilyPond in contrast have 53860 lines of code using the same counting script. Lines of code for the OpenBSD syslogd: 2226. And for the client parts, i.e. syslog(3) & friends: 232. So, ignoring any potential licensing issue between the apache stuff and the GPLv3 for now, log4cxx doesn't look appropriate by mere size. > The opposite end of the spectrum, is a much simpler logging class that > I cook myself based on syslogd. It is controlled by command-line > argument (--level | -l), exists as a global object and exposes the > traditional methods: > error() > warn() > notice() > info() > etc... Just keep it as simple as possible. And as unconfigurable as possible (use sane default settings). For LIlyPond, I don't even see any need for ditinquishing between notice() and info(). Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sun, Jan 02, 2011 at 04:18:17PM -, Phil Holmes wrote:
> "In your original backtrace, is the X_AXIS parent of the Item in frame #2
> 0x0? If so, I'm fine with the patch."
>
> I've been using this as a learning exercise, and can say that
> Item::spanned_rank_interval calls Item::get_column to return the parent, as
> below.
>
> Paper_column *
> Item::get_column () const
> {
> Item *parent = dynamic_cast (get_parent (X_AXIS));
> return parent ? parent->get_column () : 0;
> }
>
> The call to get_parent above does return 0x0.
Yes, but not immediately for the Item in question (namely the one in
frame #2):
#0 0x0041a5f0 in Paper_column::get_rank (this=0x0) at
paper-column.hh:47
47 paper-column.hh: No such file or directory.
in paper-column.hh
(gdb) up
#1 0x004ff5f4 in Item::spanned_rank_interval (this=0x20d20d900) at
item.cc:199
199 int c = get_column ()->get_rank ();
(gdb)
#2 0x00437f7b in Axis_group_interface::adjacent_pure_heights
(smob=0x2142a0a20) at axis-group-interface.cc:197
197 Interval_t rank_span = g->spanned_rank_interval ();
(gdb) print g
$1 = (Grob *) 0x20d20d900
(gdb) print g->dim_cache_[0].parent_
$2 = (Grob *) 0x20d219a00
(gdb) print g->dim_cache_[0].parent_->dim_cache_[0].parent_
$3 = (Grob *) 0x20590b700
(gdb) print
g->dim_cache_[0].parent_->dim_cache_[0].parent_->dim_cache_[0].parent_
$4 = (Grob *) 0x202c11200
(gdb) print
g->dim_cache_[0].parent_->dim_cache_[0].parent_->dim_cache_[0].parent_->dim_cache_[0].parent_
$5 = (Grob *) 0x0
Honestly, I'm not very comfortable with the LIlyPond internals; I
was several years ago, but after not doing much with the sources
for 5 years or even longer (I don't remember), this is all black
magic for me (except on the very low-level C++ level).
Maybe some day I find more time to work on it, and even to continue
my work on the Back partitas and the Bach/Busoni Chaconne I abandoned
some years ago ;-)
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sun, Jan 02, 2011 at 12:35:28PM +0100, Matthias Kilian wrote: > > In your original backtrace, is the X_AXIS parent of the Item in frame #2 > > 0x0? If so, I'm fine with the patch. > > You mean the g in line 197 of axis-group-interface.cc? > > Interval_t rank_span = g->spanned_rank_interval (); > > No, it's not 0x0. To clarify: g->dim_cache_[0].parent_ isn't 0x0. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sun, Jan 02, 2011 at 08:39:03AM +0700, Joe Neeman wrote:
> > I tried the diff below, which `fixed' the segfault, but it may be
> > completely wrong (I'm currently not familiar with the LilyPond code
> > at all). Unfortunately, I don't have a new enough ImageMagick on my
> > system, so I can't run the regression tests.
> >
> > diff --git a/lily/metronome-engraver.cc b/lily/metronome-engraver.cc
> > index 0a41fc9..e34c0ad 100644
> > --- a/lily/metronome-engraver.cc
> > +++ b/lily/metronome-engraver.cc
> > @@ -95,7 +95,10 @@ Metronome_mark_engraver::acknowledge_break_aligned
> > (Grob_info info)
> > && safe_is_member (g->get_property ("break-align-symbol"),
> > text_->get_property ("break-align-symbols"))
> > && Item::break_visible (g))
> > -support_ = g;
> > +{
> > + support_ = g;
> > + text_->set_parent (g, X_AXIS);
> > +}
> > }
> >
>
> In your original backtrace, is the X_AXIS parent of the Item in frame #2
> 0x0? If so, I'm fine with the patch.
You mean the g in line 197 of axis-group-interface.cc?
Interval_t rank_span = g->spanned_rank_interval ();
No, it's not 0x0.
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sun, Jan 02, 2011 at 12:55:45AM +, Graham Percival wrote: > > Bisected to this one (cc'd Neil): > > Fantastic! Bisecting is one of the most useful, yet also > time-consuming, parts of fixing regressions. Maybe time-consuming, but in theory, everyone able to build lilypond from git can write a little shell script that does the make clean / autogen.sh / make all / run the test combo and pass this script to git bisect run. I didn't to this the other day, but next time I will do. > > I tried the diff below, which `fixed' the segfault, but it may be > > completely wrong (I'm currently not familiar with the LilyPond code > > at all). Unfortunately, I don't have a new enough ImageMagick on my > > system, so I can't run the regression tests. > > Sorry, my fault. You can run the regtest comparison is you revert > 49dc60e9 , or just remove "-dissimilarity-threshold" from > scripts/build/output-distance.py I've already started work on an update of the ImageMagick package for OpenBSD, and the regtest comparision already works here, too. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sat, Jan 01, 2011 at 02:10:04PM +0100, Matthias Kilian wrote:
> I don't know why gdb doesn't find paper-column.hh, but anyaway...
> it looks like Item::get_column() returns NULL, because its parent's
> get_column() returns NULL (I checked that the parent on the X_AXIS
> itself is not NULL).
Bisected to this one (cc'd Neil):
commit 6d28aebbaaab1be9961a00bf15a1ef93acb91e30
Author: Neil Puttock
Date: Mon Sep 6 22:49:28 2010 +0100
Fix metronome alignment.
Don't align on KeySignature unless explicitly requested via
'break-align-symbols and make order of 'break-align-symbols
significant.
* remove `key-signature' from 'break-align-symbols
* acknowledge break_alignment, and set this as X-parent
instead of break_aligned, but only if found break_aligned
is visible
* add regression test to test ordering
* tweak existing test to reflect change in default for
'break-align-symbols
[...]
I tried the diff below, which `fixed' the segfault, but it may be
completely wrong (I'm currently not familiar with the LilyPond code
at all). Unfortunately, I don't have a new enough ImageMagick on my
system, so I can't run the regression tests.
diff --git a/lily/metronome-engraver.cc b/lily/metronome-engraver.cc
index 0a41fc9..e34c0ad 100644
--- a/lily/metronome-engraver.cc
+++ b/lily/metronome-engraver.cc
@@ -95,7 +95,10 @@ Metronome_mark_engraver::acknowledge_break_aligned
(Grob_info info)
&& safe_is_member (g->get_property ("break-align-symbol"),
text_->get_property ("break-align-symbols"))
&& Item::break_visible (g))
-support_ = g;
+{
+ support_ = g;
+ text_->set_parent (g, X_AXIS);
+}
}
void
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
issue 1464 (was: a plea to new contributors)
On Sat, Jan 01, 2011 at 06:51:49AM +, Graham Percival wrote:
> The next step in issue 1464 is just to create a backtrace.
See the blurb below this mail (no, I'm not going to sign up at google
for adding it there).
I don't know why gdb doesn't find paper-column.hh, but anyaway...
it looks like Item::get_column() returns NULL, because its parent's
get_column() returns NULL (I checked that the parent on the X_AXIS
itself is not NULL).
{ = {_vptr$Grob = 0x7e75b0, static smob_name_ = 0x7e4af3
"Grob", static smob_tag_ = 16767, self_scm_ = 0x214b69740,
protection_cons_ = 0x404, dim_cache_ = {{extent_ = 0x0, offset_ =
0x0, parent_ = 0x210133500}, {extent_ = 0x0, offset_ = 0x0, parent_
= 0x210133000}}, layout_ = 0x20f3c7880, original_ = 0x0,
immutable_property_alist_ = 0x21504cf40, mutable_property_alist_ =
0x214b64db0, object_alist_ = 0x214b60600, interfaces_ = 0x214fcdfc0,
static x_parent_positioning_proc = 0x20f176600, static
y_parent_positioning_proc = 0x20f175a10, static stencil_height_proc
= 0x20f174960, static stencil_width_proc = 0x20f177520, static
interface_symbol_ = 0x210c36d40}, broken_to_drul_ = {array_ =
{0x210124900, 0x210124d00}}, static interface_symbol_ = 0x210c3a560,
cached_pure_height_valid_ = false, cached_pure_height_ =
{> = {array_ = {0, -0}}, }}
And here's the parent in question (*this->dim_cache_[0].parent_):
{_vptr$Grob = 0x804c90, static smob_name_ = 0x7e4af3 "Grob", static
smob_tag_ = 16767, self_scm_ = 0x214b69fd0, protection_cons_ =
0x404, dim_cache_ = {{extent_ = 0x0, offset_ = 0x0, parent_ =
0x207824b00}, {extent_ = 0x0, offset_ = 0x2075ae240, parent_ =
0x210133000}}, layout_ = 0x20f3c7880, original_ = 0x0,
immutable_property_alist_ = 0x21504d310, mutable_property_alist_ =
0x2149c7540, object_alist_ = 0x214b63410, interfaces_ = 0x214fcb720,
static x_parent_positioning_proc = 0x20f176600, static
y_parent_positioning_proc = 0x20f175a10, static stencil_height_proc
= 0x20f174960, static stencil_width_proc = 0x20f177520, static
interface_symbol_ = 0x210c36d40}
It could be possible to check the result of get_column() in
Item::spanned_rank_interval(), but I'm not sure wether this is the
*proper* bug fix (nor what interval should be returned in this
case).
Ciao,
Kili
#0 0x0041a7b0 in Paper_column::get_rank (this=0x0) at
paper-column.hh:47
47 paper-column.hh: No such file or directory.
in paper-column.hh
(gdb) bt
#0 0x0041a7b0 in Paper_column::get_rank (this=0x0) at
paper-column.hh:47
#1 0x004ff7b4 in Item::spanned_rank_interval (this=0x210133600) at
item.cc:199
#2 0x0043813b in Axis_group_interface::adjacent_pure_heights
(smob=0x214b64d80) at axis-group-interface.cc:197
#3 0x0002047115cf in scm_dapply () from /usr/local/lib/libguile.so.20.0
#4 0x004e326f in Grob::try_callback_on_alist (this=0x210133000,
alist=0x210133060, sym=0x211eb9b00, proc=0x20f0d13e0) at grob-property.cc:231
#5 0x004e3e9c in Grob::internal_get_property (this=0x210133000,
sym=0x211eb9b00) at grob-property.cc:188
#6 0x00438a04 in Axis_group_interface::begin_of_line_pure_height
(me=0x210133000, start=0) at axis-group-interface.cc:116
#7 0x00438be6 in Axis_group_interface::cached_pure_height
(me=0x210133000, start=0, end=2147483647) at axis-group-interface.cc:95
#8 0x00438ce5 in Axis_group_interface::relative_pure_height
(me=0x210133000, start=0, end=2147483647) at axis-group-interface.cc:263
#9 0x004390c9 in Axis_group_interface::pure_group_height
(me=0x210133000, start=0, end=2147483647) at axis-group-interface.cc:494
#10 0x004f45c1 in Hara_kiri_group_spanner::pure_height
(smob=0x214b64d80, start_scm=0x2, end_scm=0x1fffe) at
hara-kiri-group-spanner.cc:58
#11 0x000204711ca3 in scm_dapply () from /usr/local/lib/libguile.so.20.0
#12 0x000204716c84 in deval () from /usr/local/lib/libguile.so.20.0
#13 0x000204711cbf in scm_dapply () from /usr/local/lib/libguile.so.20.0
#14 0x004e2cd8 in call_pure_function (unpure=0x20f17ab30,
args=0x2149c2960, start=0, end=2147483647) at grob-property.cc:331
#15 0x004e2ff6 in Grob::internal_get_pure_property (this=0x210133000,
sym=0x211ec4be0, start=0, end=2147483647) at grob-property.cc:200
#16 0x004ee4e4 in Grob::pure_height (this=0x210133000,
refp=0x210133000, start=0, end=2147483647) at grob.cc:464
#17 0x0041b49d in get_skylines (me=0x210133f00,
elements=0x7f7e7350, a=Y_AXIS, pure=true, start=0, end=2147483647,
ret=0x7f7e7330) at align-interface.cc:102
#18 0x0041b9c9 in Align_interface::internal_get_minimum_translations
(me=0x210133f00, all_gro...@0x2046169e0, a=Y_AXIS, include_fixed_spacing=true,
pure=true, start=0, end=2147483647)
at align-interface.cc:191
#19 0x0041c25b in Align_interface::get_pure_minimum_translations
(me=0x210133f00, all_gro...@0x2046169e0, a=Y_AXIS, start=0, end=2147483647) at
align-interface.cc:159
#20 0x0041c2f7 in Align_inter
Re: Distributions upgrading to Python 3
On Tue, Oct 19, 2010 at 12:07:29AM +0100, Graham Percival wrote:
> >> python/ yes, since it's not something that people call manually.
> >> But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise
> >> it'll bork if you call it manually.
> >
> > But are those scripts supposed to be used without runnig autogen.sh
> > (and implied configure) first?
>
> Anything that's used to build the website (as opposed to the html
> version of the docs) cannot rely on configure. This affects
> scripts/build/ create-*.py website_post.py bib2texi.py
>
> ... admittedly, those are getting called with
> python scripts/build/foo.py
> , probably precisely to avoid this problem. So I guess that's not a concern.
Oh, it would still be better to use something like
PYTHON?=python
...
WEB_POST=${PYTHON} $(script-dir)/website_post.py
in files like make/website.make (but probably only of people using
this part start to complain about annoyances).
> > #!/usr/bin/env YOUR_FAVORITE_INTERPRETER
> >
> > should not be used ever. At least not for scripts that will be
> > installed system-wide.
>
> Why not? IIRC, we had to add this to work around some problem in OSX.
> The discussion is in the email archives... hopefully somebody can dig
> it out for us.
I didn't dig it yet, but for OSX (and every system where people
have to rely on binary installers provided by lilypond.org) it may
be that different OSX versions have python installed in different
locations. If my guess is correct, it would be nice if someone could
hack on the OSX binary to do some post-install patching on the
installed python scripts.
> If there's a good reason not to do this, and a better way of solving
> whatever problem we solved with /usr/bin/env python, I welcome a
> change.
The good reason is: whatever you install system-wide with a
#!/usr/bin/env line is out of your control. It immediately depends
on the users PATH. Ignoring security issues for now, #!/usr/bin/env
may trigger completely unexpected (for lilypond developers, or OS
package maintainers) behaviour on a users system.
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distributions upgrading to Python 3
(unlurking, i didn't spend much time on lilypond recently) On Mon, Oct 18, 2010 at 01:59:15AM +0100, Graham Percival wrote: > > --) Two scripts still have "/usr/bin/python" lines > > (python/auxiliar/manuals_definitions.py, and scripts/build/pytt.py). > > Those should be changed to "@PYTHON@", right? > > python/ yes, since it's not something that people call manually. > But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise > it'll bork if you call it manually. But are those scripts supposed to be used without runnig autogen.sh (and implied configure) first? I may have some time during the next two weeks and arrange things so those scripts will use the python detected by (or passed via environment to) configure. If you want it. > > Would it be feasible to use "#!/usr/bin/env @PYTHON@" or > > "#!/usr/bin/env @TARGET_PYTHON@" for all Python scripts, using the > > basename of the appropriate Python executable in place of the Make > > variables? #!/usr/bin/env YOUR_FAVORITE_INTERPRETER should not be used ever. At least not for scripts that will be installed system-wide. And if possible, not even for local scripts (like scripts/build in lilypond). Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
2.12.3 source tarball changed (back in january)
Hi, a fellow openbsd developer noticed that the 2.12.3 source tarball (http://download.linuxaudio.org/lilypond/sources/v2.12/lilypond-2.12.3.tar.gz) differs from the same version from late december (december, 20th, I think). Please avoid such changes in the future, they make the live of port/packages maintainers very hard, because checksums are changing, mirrors of the source tarballs have to be noticed etc. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: imprecise Taktlinie in german doc (NR)
On Wed, May 12, 2010 at 09:35:26PM +0200, Henning Plumeyer wrote: > >I'm not an active musician, and only decades ago I did do music > >with others (orchestra, choir), so I may be wrong, but I've a strong > >feeling towards `Taktnummern'. It's less ambigous. > > I've been in hundreds of rehearsals and never heard the word Taktnummern, > only Taktzahlen. Then I'm probably wrong. As said, I'm not an active musician ;-) Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: imprecise Taktlinie in german doc (NR)
On Wed, May 12, 2010 at 06:02:38PM +0200, David Kastrup wrote: > > yes, but the term Taktzahl is mainly found in technical contexts! > > I was talking about "Taktzahlen". Let's see where this leads Google: > > Results for: taktzahlen > # > Musiksoftware Forum: Taktzahlen bei Sibelius > > One for me. Well, the term `Taktzahlen' in this context still sounds really odd to me, and I'm a german native speaker, which is also an explanation for my broken english ;-) > Ulrich Siegele: Taktzahlen als Ordnungsfaktor in Suiten- und ... > > Nontechnical, but measure count. Right. The problem with `Zahlen' is that it's often a synonym for `Anzahl' (amount / count). > # > Prozzessor mit den höchsten Taktzahlen - Forum - CHIP Online > Technical. And a completely different context (clock speed of the CPU). [... snip ...] Even if www.googlefight.com shows more results for `Taktzahlen', it still doesn't mean that it's the correct word ;-) I'm not an active musician, and only decades ago I did do music with others (orchestra, choir), so I may be wrong, but I've a strong feeling towards `Taktnummern'. It's less ambigous. Ciao, Kili ___ 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: [PATCH] Use find ... | xargs rm -f instead of find ... -delete
[this is becoming slightly offtopic, but anyway...] On Tue, Dec 29, 2009 at 08:19:57PM +, Graham Percival wrote: > > > > - find $(outdir)/offline-root -type l -delete > > > > + find $(outdir)/offline-root -type l | xargs rm -f [...] > > The `-delete' primary isn't very portable, it's a GNU extension. > > IMHO, that's all we need to hear. -delete must be removed. `must' is such a strong word. There are other GNUisms (or non-portable extensions) hidden in the build system, like that `grep -L' at some places. If you guys hesitate to apply patches like the one I sent (and David is right in that my patch introduces a potential risk), that's perfectly ok for me. I've two branches on my disk: `mystuff' (containing patches I think may be helpful for all systems), and `openbsdhacks' (copntaining additional patches I need to get LilyPond built on OpenBSD, and that are probably less important for you). I could just move the find(1) diff to my `openbsdhacks' branch. > > > and less secure > > > (if somebody places files with spaces or newlines into the latter > > > directory, things may get ugly). > > That's a fairly esoteric concern; I can't imagine anybody having > the lilypond build tree in a world-writeable location unless they > also had the source tree in a world-writeable location. If they > did that (say, a shared computer where the users trusted each > other), then there's many other ways to do nasty stuff (like > changing the makefiles themselves). Yes, but David is right in that my patch was spreading bad practice. It's probably an esoteric issue for LilyPond, but someone may copy and use this unsafe command for his own project or in some random shell script. Ciao, Kili ___ 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 Tue, Dec 29, 2009 at 08:16:37AM +0100, David Kastrup wrote:
> > - find $(outdir)/offline-root -type l -delete
> > + find $(outdir)/offline-root -type l | xargs rm -f
> > endif # ifeq ($(out),www)
>
> What's the rationale?
The `-delete' primary isn't very portable, it's a GNU extension.
> The latter form is less efficient
I doubt it's measurable. Using find ... -exec ... {} ... ; would
be inefficient, but using find and xargs should be fast.
> and less secure
> (if somebody places files with spaces or newlines into the latter
> directory, things may get ugly).
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).
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make/doc-i18n-root-rules.make: grep --label=""
On Mon, Dec 28, 2009 at 10:05:51PM +0100, John Mandereau wrote: > > What's the reason for that `--label=""'? It's breaking the build [...] > The commit that added "--label" is > > commit d4401de33195113a8859629b4bd9483a03d9ab5c > Author: Werner Lemberg > Date: Thu Dec 14 15:28:27 2006 +0100 > > (lang-merge): Protect against grep's `(standard input)' output if there is > no input. I'd like to see some example. IMHO, this can't happen in the find ... | xargs grep ... pipe (there's now stdin for grep, since stdin is consumed by xargs). > It seems to me that the fact there is no input, i.e. that "find > $(outdir) -name '*.html'", is the sign of a build error, so I've removed > --label. Just in case we need to reintroduce it, or more hopefully for > my curiosity, does your implementation of grep support the option -h > a.k.a. --no-filename? Copy&Waste from our grep(1) manpage: -h Never print filename headers (i.e. filenames) with output lines. But as you write, this `(standard input)' should never happen. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Use find ... | xargs rm -f instead of find ... -delete
--- GNUmakefile.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/GNUmakefile.in b/GNUmakefile.in index 6574e65..6c2c54f 100644 --- a/GNUmakefile.in +++ b/GNUmakefile.in @@ -123,7 +123,7 @@ WWW-post: $(buildscript-dir)/mutopia-index -o $(outdir)/examples.html input/ find $(outdir) -name '*-root' | xargs rm -rf $(buildscript-dir)/www_post $(PACKAGE_NAME) $(TOPLEVEL_VERSION) $(outdir) "$(WEB_TARGETS)" - find $(outdir)/offline-root -type l -delete + find $(outdir)/offline-root -type l | xargs rm -f endif # ifeq ($(out),www) # For those who cannot for the life in them remember to type -- 1.6.5.7 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
make/doc-i18n-root-rules.make: grep --label=""
There are two make rules using a command like find $(outdir)/$* -name '*.html' | xargs grep -L --label="" 'UNTRANSLATED NODE: IGNORE ME' | ... What's the reason for that `--label=""'? It's breaking the build with OpenBSDs native grep (in /usr/bin/grep), and I don't see any difference when using GNU grep with and without --label="", so I'd like to just drop that option. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Always use $(PYTHON) scriptname.py.
On Sun, Dec 27, 2009 at 06:45:14PM +0100, John Mandereau wrote: > > It still needs the $(PYTHON), regardless wether it's in scripts/auxiliar > > or scripts/build. > > For build scripts, the $(PYTHON) is put into the shebang when writing > the script (and makeing it executable) from scripts/build to > scripts/build/out, so that's OK (modulo a fix I just pushed). Ah, thanks! Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Always use $(PYTHON) scriptname.py.
On Sun, Dec 27, 2009 at 06:09:15PM +0100, John Mandereau wrote: > > - $(auxscript-dir)/yyout2grammar.py $(outdir)/parser.output $@ > > + $(PYTHON) $(auxscript-dir)/yyout2grammar.py $(outdir)/parser.output $@ > > Oops, this script should be in scripts/build, not scripts/auxiliar, but > this is my fault, not yours :-D It still needs the $(PYTHON), regardless wether it's in scripts/auxiliar or scripts/build. Actually this target caused a build on OpenBSD to fail ;-) Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Always use $(PYTHON) scriptname.py.
The often-used idiom #!/usr/bin/env python not only is potentially dangerous, but it also fails if there are several versions of python installed, with the python binaries named python2.4, python2.5, python2.6, ... This patch hopefully catches all remaining cases of a missing $(PYTHON). --- Documentation/GNUmakefile| 20 ++-- Documentation/po/GNUmakefile |2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index 24bd966..30187d7 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -219,7 +219,7 @@ $(outdir)/notation.texi: $(outdir)/ly-grammar.txt ## Rules for the automatically generated documentation $(outdir)/ly-grammar.txt: $(top-src-dir)/lily/parser.yy cd $(outdir) && $(BISON) -v $< - $(auxscript-dir)/yyout2grammar.py $(outdir)/parser.output $@ + $(PYTHON) $(auxscript-dir)/yyout2grammar.py $(outdir)/parser.output $@ # There used to be a dependency on a dummy target, to force a rebuild # of internals every time. however, this triggers @@ -249,7 +249,7 @@ new-lang-dir: cp fr/$(DIR)/GNUmakefile $(ISOLANG)/$(DIR) sed -i -e 's/ISOLANG *= *fr/ISOLANG = $(ISOLANG)/' $(ISOLANG)/GNUmakefile $(ISOLANG)/$(DIR)/GNUmakefile rm -f $(outdir)/*.*tely $(outdir)/*.*texi - $(auxscript-dir)/texi-langutils.py -d $(outdir) -l $(ISOLANG) -o doc.pot --skeleton --gettext $$(cd $(ISOLANG) && ls -1 ../$(DIR).tely ../$(DIR).texi) + $(PYTHON) $(auxscript-dir)/texi-langutils.py -d $(outdir) -l $(ISOLANG) -o doc.pot --skeleton --gettext $$(cd $(ISOLANG) && ls -1 ../$(DIR).tely ../$(DIR).texi) for i in $$(cd $(outdir) && ls -1 $(DIR).tely $(DIR).texi); do\ test -e $(ISOLANG)/$$i || mv $(outdir)/$$i $(ISOLANG)/$$i;\ done @@ -274,11 +274,11 @@ TRANSLATION_FILES = $(shell git ls-files $(ISOLANG) | grep -v GNUmakefile) TELY_FILES = $(call src-wildcard,$(ISOLANG)/*.tely) skeleton-update: mkdir -p $(ISOLANG) - $(auxscript-dir)/texi-langutils.py -d $(outdir) -l $(ISOLANG) --skeleton $(TELY_FILES:$(ISOLANG)/%.tely=../%.tely) - $(auxscript-dir)/texi-skeleton-update.py $(ISOLANG) $(outdir) + $(PYTHON) $(auxscript-dir)/texi-langutils.py -d $(outdir) -l $(ISOLANG) --skeleton $(TELY_FILES:$(ISOLANG)/%.tely=../%.tely) + $(PYTHON) $(auxscript-dir)/texi-skeleton-update.py $(ISOLANG) $(outdir) snippet-update: - $(auxscript-dir)/update-snippets.py user $(ISOLANG) '*.itely' + $(PYTHON) $(auxscript-dir)/update-snippets.py user $(ISOLANG) '*.itely' DOCUMENTS_INCLUDES:=-I $(ISOLANG) \ -I $(top-build-dir)/Documentation/$(ISOLANG)/out-www \ @@ -297,21 +297,21 @@ DOCUMENTS_INCLUDES:=-I . \ endif # ISOLANG check-xrefs: - $(auxscript-dir)/check_texi_refs.py --batch \ + $(PYTHON) $(auxscript-dir)/check_texi_refs.py --batch \ $(DOCUMENTS_INCLUDES) $(auxpython-dir)/manuals_definitions.py fix-xrefs: - $(auxscript-dir)/check_texi_refs.py --auto-fix \ + $(PYTHON) $(auxscript-dir)/check_texi_refs.py --auto-fix \ $(DOCUMENTS_INCLUDES) $(auxpython-dir)/manuals_definitions.py check-translation: - ISOLANG=$(ISOLANG) $(auxscript-dir)/check_translation.py $(CHECK_TRANSLATION_FLAGS) $(TRANSLATION_FILES) + ISOLANG=$(ISOLANG) $(PYTHON) $(auxscript-dir)/check_translation.py $(CHECK_TRANSLATION_FLAGS) $(TRANSLATION_FILES) update-translation: - ISOLANG=$(ISOLANG) $(auxscript-dir)/check_translation.py --update $(CHECK_TRANSLATION_FLAGS) $(TRANSLATION_FILES) + ISOLANG=$(ISOLANG) $(PYTHON) $(auxscript-dir)/check_translation.py --update $(CHECK_TRANSLATION_FLAGS) $(TRANSLATION_FILES) translation-status: make -C po out=www messages - $(auxscript-dir)/translations-status.py + $(PYTHON) $(auxscript-dir)/translations-status.py .SECONDARY: diff --git a/Documentation/po/GNUmakefile b/Documentation/po/GNUmakefile index 9224f2c..65d7e3a 100644 --- a/Documentation/po/GNUmakefile +++ b/Documentation/po/GNUmakefile @@ -25,7 +25,7 @@ $(outdir)/messages: $(MO_FILES) touch $@ po-update: - $(auxscript-dir)/texi-langutils.py -d $(outdir) -o texi.pot --gettext $(TELY_FILES:%.tely=../%.tely) + $(PYTHON) $(auxscript-dir)/texi-langutils.py -d $(outdir) -o texi.pot --gettext $(TELY_FILES:%.tely=../%.tely) $(foreach i, $(DOC_PO_SOURCES), cp $(top-src-dir)/$(i) $(outdir) &&) true cd $(outdir) && sed -i -e s/_doc/_/g $(foreach i, $(DOC_PO_SOURCES), $(notdir $(i))) cd $(outdir) && xgettext -cjn -L Python -o buildscripts.pot $(foreach i, $(DOC_PO_SOURCES), $(notdir $(i))) -- 1.6.5.7 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: race condition in writing lilypond-book filenames
[sorry for mumbling to myself too much] On Sun, Dec 13, 2009 at 06:53:57PM +0100, Matthias Kilian wrote: [...] > -out = file (path + '.ly', 'w') > +out = tempfile.NamedTemporaryFile(mode = 'w', suffix = '.lytmp', > + dir = directory, delete = False) Unfortunately, this doesn't work with python < 2.6 (because the `delete' parameter is new since python-2.6). But if you gyys think that the approach of writing (and later renaming) temporary files may help, i'll make a better diff tomorrow. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix STEPMAKE_GET_VERSION for OpenBSD
On Tue, Dec 15, 2009 at 04:33:14PM +0100, Jan Nieuwenhuizen wrote:
> > (I really
> > don't remember the reason, too much time has passed since I made
> > this patch)
>
> It would be nice to know why we need this, esp. as this fix
> does not make the logic more readible.
Not necessary, I aready had a closer look. It's failing in grep(1)
for \|, which is undefined by POSIX (for basic regular expressions) and
obviously support by GNU grep but not by OpenBSDs grep.
So a much simpler fix is to use
grep -E '(^| )[0-9][0-9]*\.[0-9]'
instead of
grep -E '\(^\| \)[0-9][0-9]*\.[0-9]'
Here's a diff that does exactly this:
diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4
index 83c07c3..5bd8b73 100644
--- a/stepmake/aclocal.m4
+++ b/stepmake/aclocal.m4
@@ -32,9 +32,9 @@ AC_DEFUN(STEPMAKE_GET_VERSION, [
## for compatibility reasons.
## grab the first version number in --version output.
-eval _ver=\"\`("$1" --version || "$1" -V) 2>&1 | grep '\(^\|
\)[0-9][0-9]*\.[0-9]' \
+eval _ver=\"\`("$1" --version || "$1" -V) 2>&1 | grep -E '(^|
)[0-9][0-9]*\.[0-9]' \
| head -n 1 \
- | tr ' ' '\n' | sed 's/\([0-9][0-9]*\.[0-9][0-9.]*\).*/\1/g' | grep
'\(^\| \)[0-9][0-9]*\.[0-9]' | head -n 1\`\"
+ | tr ' ' '\n' | sed 's/\([0-9][0-9]*\.[0-9][0-9.]*\).*/\1/g' | grep -E
'(^| )[0-9][0-9]*\.[0-9]' | head -n 1\`\"
if test -z "$_ver"; then
## If empty, try date [fontforge]
An alternative diff, which just adds some linebreaks and avoids line
continuations using backslash-newline: (for improving readability a
little bit):
diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4
index 83c07c3..09afbff 100644
--- a/stepmake/aclocal.m4
+++ b/stepmake/aclocal.m4
@@ -32,9 +32,13 @@ AC_DEFUN(STEPMAKE_GET_VERSION, [
## for compatibility reasons.
## grab the first version number in --version output.
-eval _ver=\"\`("$1" --version || "$1" -V) 2>&1 | grep '\(^\|
\)[0-9][0-9]*\.[0-9]' \
-| head -n 1 \
- | tr ' ' '\n' | sed 's/\([0-9][0-9]*\.[0-9][0-9.]*\).*/\1/g' | grep
'\(^\| \)[0-9][0-9]*\.[0-9]' | head -n 1\`\"
+eval _ver=\"\`("$1" --version || "$1" -V) 2>&1 |
+ grep -E '(^| )[0-9][0-9]*\.[0-9]' |
+ head -n 1 |
+ tr ' ' '\n' |
+ sed 's/\([0-9][0-9]*\.[0-9][0-9.]*\).*/\1/g' |
+ grep -E '(^| )[0-9][0-9]*\.[0-9]' |
+ head -n 1\`\"
if test -z "$_ver"; then
## If empty, try date [fontforge]
Tested with both /bin/sh (which is a ksh here) and /usr/local/bin/bash
(bash-4.0.35).
Pick your choice.
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Use $(PYTHON), not python, to create version.itexi
diff --git a/stepmake/stepmake/texinfo-rules.make b/stepmake/stepmake/texinfo-rules.make index 84f2894..6be8c5f 100644 --- a/stepmake/stepmake/texinfo-rules.make +++ b/stepmake/stepmake/texinfo-rules.make @@ -63,7 +63,7 @@ $(outdir)/version.%: $(top-src-dir)/VERSION echo $(TOPLEVEL_VERSION)>> $@ echo '@end macro'>> $@ echo ''>> $@ - python $(top-src-dir)/scripts/build/create-version-itexi.py >> $@ + $(PYTHON) $(top-src-dir)/scripts/build/create-version-itexi.py >> $@ .SECONDARY: $(outdir)/version.itexi $(outdir)/version.texi \ $(outdir)/$(INFO_IMAGES_DIR).info-images-dir-dep \ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Don't use __attribute__ ((pure)) for unsmob
This one makes lilypond build with good old gcc-3.3.5 (which is the
default compiler on OpenBSD). It's probably debatable wether it'll
slow down lilypond runtime and accelerate global warming, so if you
don't like it, let me know; I could also add some #ifdefs (or just
keep the patch file in the OpenBSD port).
Ciao,
Kili
diff --git a/configure.in b/configure.in
index 6253b66..c1cd146 100644
--- a/configure.in
+++ b/configure.in
@@ -90,10 +90,10 @@ AC_MSG_RESULT($NCSB_SOURCE_FILES)
STEPMAKE_PYTHON(REQUIRED, 2.4)
-STEPMAKE_GCC(REQUIRED, 3.4)
+STEPMAKE_GCC(REQUIRED, 3.3.5)
STEPMAKE_CXX(REQUIRED)
-STEPMAKE_GXX(REQUIRED, 3.4)
+STEPMAKE_GXX(REQUIRED, 3.3.5)
STEPMAKE_CXXTEMPLATE
STEPMAKE_STL_DATA_METHOD
STEPMAKE_LIB(REQUIRED)
diff --git a/lily/include/smobs.hh b/lily/include/smobs.hh
index 27f9ff4..8b8e4c3 100644
--- a/lily/include/smobs.hh
+++ b/lily/include/smobs.hh
@@ -114,7 +114,7 @@
static int print_smob (SCM s, SCM p, scm_print_state*); \
public: \
static SCM equal_p (SCM a, SCM b); \
- static CL *unsmob (SCM s) __attribute__((pure)) \
+ static CL *unsmob (SCM s)\
{\
if (SCM_NIMP (s) && SCM_CELL_TYPE (s) == smob_tag_)\
return (CL *) SCM_CELL_WORD_1 (s); \
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix STEPMAKE_GET_VERSION for OpenBSD
Hi,
I have this as a patch in the lilypond port of OpenBSD for years
(since 2006, IIRC), and it looks like I still need it for the
development branch. Without this, configure isn't able to detect
the versions of at least texi2html, makeinfo and bison. (I really
don't remember the reason, too much time has passed since I made
this patch)
Please be sure that it doesn't blow up configure on other systems.
Ciao,
Kili
diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4
index 83c07c3..59a2267 100644
--- a/stepmake/aclocal.m4
+++ b/stepmake/aclocal.m4
@@ -32,9 +32,14 @@ AC_DEFUN(STEPMAKE_GET_VERSION, [
## for compatibility reasons.
## grab the first version number in --version output.
-eval _ver=\"\`("$1" --version || "$1" -V) 2>&1 | grep '\(^\|
\)[0-9][0-9]*\.[0-9]' \
-| head -n 1 \
- | tr ' ' '\n' | sed 's/\([0-9][0-9]*\.[0-9][0-9.]*\).*/\1/g' | grep
'\(^\| \)[0-9][0-9]*\.[0-9]' | head -n 1\`\"
+eval '_ver=\`'"$1"' --version 2>&1\` || _ver=\`'"$1"' -V 2>&1\` &&
+_ver=\`echo $_ver |
+ grep '\''[0-9]\.[0-9]'\'' |
+ head -n 1 |
+ tr '\'' '\'' '\''\n'\'' |
+ grep '\''[0-9]\.[0-9]'\'' |
+ head -n 1 |
+ sed '\''s/\([0-9.]*\).*/\1/g'\''\`'
if test -z "$_ver"; then
## If empty, try date [fontforge]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: race condition in writing lilypond-book filenames
On Sun, Dec 13, 2009 at 05:49:13PM +0100, Matthias Kilian wrote:
> If the a file with the same name always has the same content,
> regardless from which document it has been generated, would something
> like the following help (no real code, i'm not good at all if it
> comes to python)?
Don't laugh at me -- I can't even test this here on OpenBSD, because
I don't have all prerequisites available in the necessery versions.
diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
index 392ddd0..35a1d8a 100644
--- a/scripts/lilypond-book.py
+++ b/scripts/lilypond-book.py
@@ -1273,8 +1273,17 @@ left-margin-default right-margin-default)"
directory = os.path.split(path)[0]
if not os.path.isdir (directory):
os.makedirs (directory)
-out = file (path + '.ly', 'w')
+out = tempfile.NamedTemporaryFile(mode = 'w', suffix = '.lytmp',
+ dir = directory, delete = False)
out.write (self.full_ly ())
+out.close()
+filename = path + '.ly'
+if os.path.exists(filename):
+# What else? Print a warning? Compare both files and error
+# out if they differ?
+os.remove(out.name)
+else:
+os.rename(out.name, filename)
file (path + '.txt', 'w').write ('image of music')
def relevant_contents (self, ly):
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: race condition in writing lilypond-book filenames
Hi,
On Sun, Dec 13, 2009 at 03:55:00PM +, Graham Percival wrote:
> diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
> index 392ddd0..b9731f1 100644
> --- a/scripts/lilypond-book.py
> +++ b/scripts/lilypond-book.py
> @@ -1273,7 +1273,11 @@ left-margin-default right-margin-default)"
> directory = os.path.split(path)[0]
> if not os.path.isdir (directory):
> os.makedirs (directory)
> -out = file (path + '.ly', 'w')
> +filename = path + '.ly'
> +if os.path.exists(filename):
> +print "PANIC! ", filename, "already exists!"
> +sys.exit(1)
> +out = file (filename, 'w')
> out.write (self.full_ly ())
> file (path + '.txt', 'w').write ('image of music')
It's still possible that a file gets overwritten, for example if
one process creates the output file *after* another process checked
wether it exists, but *before* that other process actually creates
the file.
Anyway, I had an idea after seeing that diff...
> In any case, we definitely have the same filename being used multiple
> times when building lilypond. Is this a problem? I can't say for
> certainty, but I *do* know that unpredictable race conditions occur in
> the docs when building with more than one process.
If the a file with the same name always has the same content,
regardless from which document it has been generated, would something
like the following help (no real code, i'm not good at all if it
comes to python)?
- write the output to a temporary file (with a unique filename, but
within the same directory)
- after writing the temporary file, test wether a file with the final
name (path + '.ly') already exists
- if not, just rename the tempory file to the final name
- if it already existed, remove the temporary file (here one could
additionally compare the two files and error out if they differ)
There's still a race here (again, between the check wether the final
file exists and the actual renaming). However, if equally named
files are expected to have the same content, this race doesn't
matter, because renaming a file is an atomic operation, and because
the final file will always be complete.
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc failure
On Fri, Nov 13, 2009 at 09:36:44PM +, Neil Puttock wrote: > > I guess I could test this tomorrow. > > Doesn't work for me unfortunately: > > WARNING: Unable to find node 'Scheme tutorial' in book learning. > cp /home/neil/lilypond/Documentation/css/*.css out-www/contributor/ > cp /home/neil/lilypond/Documentation/css/*.css out-www/notation/ > # fix links from other manuals to general > find ./out-www -name "*.html" | xargs sed -e 's/..\/general\//..\//' -i '' > sed: can't read : No such file or directory > make[2]: *** [local-WWW-2] Error 123 Of course, both lines with this find .. | xargs sed ... -i pattern have to be changed, not only the one i mentioned in my mail. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc failure
On Fri, Nov 13, 2009 at 08:31:34PM +, Carl Sorensen wrote: > @@ -146,8 +146,8 @@ local-WWW-1: $(OUT_TEXINFO_MANUALS) > $(PDF_FILES) info > > local-WWW-2: txt-to-html $(OUT_HTML_FILES) $(DEEP_HTML_FILES) > $(source-links) $(OM > # fix links from other manuals to general > - find $(outdir) -name "*.html" | xargs sed -i 's/..\/general\//..\//' > - ls $(outdir)/*.html | xargs sed -i 's/ + find $(outdir) -name "*.html" | xargs sed -e > 's/..\/general\//..\//' -i '' > + ls $(outdir)/*.html | xargs sed -e 's/ '' > endif Please don't use -i on sed(1), it's not portable (so it wasn't portable in the original version). If you're brave, and if there are no files with "funny" names (containing linebreaks), you can use something like ls $(outdir)/*.html | while read f; do sed -e ... "$$f" > _ && mv _ "$$f" done Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: serious doubts about waf
On Wed, Nov 11, 2009 at 02:38:12PM -0800, Patrick McCarty wrote: > I don't have much experience *using* automake, but from what I've > read: > > - A Makefile.am is easier to maintain than an equivalent handcoded > makefile. > - The generated makefiles will be very portable (not reliant on GNU > make). > - Automake integrates well with Autoconf, probably more so than the > current stepmake system. One problem with automake (and autoconf) is that it's incredibly difficult to debug if something goes wrong. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Sat, Sep 19, 2009 at 11:28:11PM +0100, Anthony W. Youngman wrote: > >The snippets are taken from the LSR and a condition of submission to the > >LSR is that you consign your work to the public domain (and that you > >have the right to do so). I know, because I submitted a couple of > >snippets to the LSR and they later made it into the Lilypond docs' > >selection of snippets. > > What happens if you're German :-) > > (I don't know, but there's been a fair bit of discussion, on and off, on > debian legal as to whether it is even *possible* for some people to > consign their work to the public domain - the *law* apparently says they > *can't*) "public domain" in germany (and maybe other european countries) doesn't exist in the sense that an author can't drop authorship and decline all responsibility for his work. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: > So, having read the past discussion and looked through source code etc. > it seems like there are several general observations, some conclusions, > and some questions. > > Observations: > >(1) Lilypond isn't violating any copyright/license requirements. So what's the point of this discussion? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Iphone
On Wed, Aug 26, 2009 at 10:32:49PM +, Phil Allred wrote: > Could lilypond be packaged up for the iPhone? Has anyone explored this? I may be wrong, but doesn't the iPhone use a CPU similar to that of a Sharp Zaurus CL3200 or some of the cheap Thecus storage devices, i.e. some ARM/xscale processor running at 400 -- 600 MHz without an FPU? If I'm not wrong, I won't expect much fun from running LilyPond on the iPhone. It's really dead-slow the other machines I mentioned. Another problem may be the memory footprint. I don't know how much RAM an iPhone has, but on the Zaurus (with 64MB RAM) I can only render very simple and small tunes. More complex stuff (like the bach/busoni chaconne i still didn't finish) uses too much memory. However, if an iPhone comes with several hundred MB of RAM, the only bottleneck would be the CPU performance. Ciao, Kili -- >> Programme, die mit "k" anfangen benutze ich nicht ;-) > Und was machst Du, wenn Du mal einem Prozess ein Signal schicken willst? Dann nimmt er den Gnome-Ableger "gill" (aus Sachsen?). -- Martin Bucher, Matthias Kilian & Ralf Döblitz in der LUG-BS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken make
On Tue, Jul 14, 2009 at 09:32:16AM -0600, Carl Sorensen wrote: > > Just drop it. If the destination file has to be updated whenever > > the source file changes, let make(1) handle it. > > I dropped it in my local copy, and make succeeded. But I have not pushed > the change to git, and won't. I don't have enough confidence that I know > the build process well to be sure I'm not breaking something. I'll let John > Mandereau get to it when he has the time. Yep, it may be helpful to know *what* he was trying to fix with cp -u. Ciao, Kili -- Automake and autoconf deserve to wither and die, but unfortunately noone at GNU seems to make much of an effort to euthanasize them. -- Han-Wen Nienhuys, on Lilypond-devel mailing list ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken make
On Mon, Jul 13, 2009 at 09:18:58PM -0700, Patrick McCarty wrote: > I found this interesting link: > > https://savannah.cern.ch/bugs/?35556 > > It looks like "cp -u" will only work under Linux. John added the "-u" > flag earlier this month to avoid some error messages (likely different > from yours). > > So, we can either remove the "-u" flag or find a different solution > that still provides the fix John made. Just drop it. If the destination file has to be updated whenever the source file changes, let make(1) handle it. Oh, and for general information what options are available for standard tools: http://www.opengroup.org/onlinepubs/9699919799/toc.htm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Out of memory not properly detected on scm_* functions
Hi, when running $ gmake web on OpenBSD/amd64, lilypond tends to bail out in a very misleading and confusing way -- it segfaults. This is probably reproducible on Linux when you limit the data size using ulimit -Sd 524288 (it's really not necessary that someone actually tries to reproduce it, but if you're bored...). The problem is that when memory is tight, several of the scm_* functions like the scm_call_? family just return NULL. Indeed, some debugging and tracing showed that guiles garbage collectro tries to realloc(2), which fails, and then you just get get the NULL. Unfortunately, lilypond doesn't check the return values of the scm_* functions, so all you see is the mentioned segfault *somewhere*, probably after the realloc(2) failed several times. I'm not a libguile guru, but is there any way to force libguile to abort(2) immediately if the gc can't gc anything and also can't request more space from the system? Checking all the SCM's returned by scm_* function seems to be too cumbersome IMHO. Ciao, Kili ps: of course this all may be caused by a memory leak in lilypond, but before checking that, I'd prefer to see lilypond aborting when the realloc failure happens. -- If your program isn't worth documenting, it probably isn't worth running. -- Nagler ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: which fontforge version?
On Wed, Feb 11, 2009 at 10:42:19PM +0100, Jan Nieuwenhuizen wrote: > > while working on an update of the openbsd port of lilypond, i see > > lots of fontforge whinings like this one: > > > Internal Error in accidentals.flat.arrowdown: monotonic is both needed and > > unneeded. > > Indeed, these glyphs were recently added and seem to have issues. [...] > > And: does anyone using fontforge-20080927 on other operating systems > > running into those errors? > > I see them in my logs too. Good (in the sense of: it's not an OS specific bug). Since George seems to be quite busy with non-fontforge things, I'll just work with the CVS version for now. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
which fontforge version?
Hi, while working on an update of the openbsd port of lilypond, i see lots of fontforge whinings like this one: Invoking "fontforge -script feta13.pe feta13.pfb"... Copyright (c) 2000-2008 by George Williams. Executable based on sources from 02:38 GMT 27-Sep-2008. Library based on sources from 15:05 GMT 25-Sep-2008. Internal Error in accidentals.flat.arrowdown: monotonic is both needed and unneeded. Internal Error in accidentals.flat.arrowdown: monotonic is both needed and unneeded. Internal Error in accidentals.flat.arrowdown: Expected needed monotonic. Internal Error in accidentals.flat.arrowboth: monotonic is both needed and unneeded. Internal Error in accidentals.flat.arrowboth: monotonic is both needed and unneeded. Internal Error in accidentals.flat.arrowboth: Expected needed monotonic. What (hopefully newer) version fontforge is typically used for lilypond? And: does anyone using fontforge-20080927 on other operating systems running into those errors? Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: *Newbie question* Can I use Gcc 3.4 for compiling?
On Tue, May 06, 2008 at 01:32:12AM +, Mark wrote: > Can I use GCC 3.4. to compile the code? For LilyPond-2.10.*, try the patches at http://www.openbsd.org/cgi-bin/cvsweb/ports/print/lilypond/patches/ -- All the distortion came from the amp. -- Paul Gilbert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[patch] zap wrong assert() in lily/ttf.cc
[Applies to lilypond-2.10.25]
Seems like all you guys build with -DNDEBUG ;-)
That cur_chunk_idx isn't defined at this point of code.
Ciao,
Kili
--- lily/ttf.cc.origSat May 19 16:49:56 2007
+++ lily/ttf.cc Mon May 21 11:33:48 2007
@@ -174,7 +174,6 @@ void t42_write_table (void *out, FT_Face face, unsigne
{
chunks.push_back (last_offset - last_chunk);
last_chunk = last_offset;
- assert (cur_chunk_idx < 100);/* FIXME: only for static arrays */
}
last_offset = offset;
--
Unless your mouth is still frozen from a trip to the dentist, you
CANNOT utter the term "mibibyte" without feeling like an idiot.
-- Kjell Wooding about IEC 60027-2
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: misdetection of mftrace in 2.10.1
[list cc: changed to -devel, since it's more appropriate] On Sat, Dec 09, 2006 at 12:36:24PM +0100, Han-Wen Nienhuys wrote: > The version checking is particularly fragile; this was a fix to make the > checking work with another package. We're once again reevaluating > SCons, but the latest versions seem to have some serious problems > that prevent us from switching. Just beeing curious: did anyone ever think about using cmake? I'm not sure wether it would be a proper replacement for autotools + stepmake, but AFAIK the KDE guys are quite happy with it. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix: file descriptor leak in scm/framework-eps.scm
On Mon, Nov 13, 2006 at 11:48:18PM +0100, Matthias Kilian wrote: > Found when trying to build on OpenBSD: Fix another fd leak. To reproduce those leaks on Linux, try ulimit -n 128 (or even 64) before running make all web. BTW: this all is about LilyPond 2.10.0. --- scm/backend-library.scm.origFri Nov 10 14:44:26 2006 +++ scm/backend-library.scm Tue Nov 14 22:02:42 2006 @@ -158,7 +158,9 @@ (if (equal? "-" file-name) "" file-name)) (if (equal? file-name "-") (display value) - (display value (open-file file-name "w"))) + (let ((port (open-file file-name "w"))) + (display value port) + (close-port port))) (ly:progress "\n") "") Ciao, Kili ps: anyone using OpenBSD who wants to help please contact me offlist; you'll need some patches not yet committed to the OpenBSD trees (especially for makeinfo and guile, but also for LilyPond itself). ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix: file descriptor leak in scm/framework-eps.scm
Found when trying to build on OpenBSD: --- scm/framework-eps.scm.orig Fri Nov 10 14:44:26 2006 +++ scm/framework-eps.scm Mon Nov 13 21:53:37 2006 @@ -97,6 +97,8 @@ stencil, so LaTeX includegraphics doesn' (display "@c eof - 'eof' is a Makefile marker; do not remove. " texi-system-port) (display "% eof - 'eof' is Makefile marker; do not remove. " tex-system-port) +(close-output-port texi-system-port) +(close-output-port tex-system-port) (dump-infinite-stack-EPS stencils) (postprocess-output book framework-eps-module (format "~a.eps" basename) (ly:output-formats -- Zesterdaz, all mz kezboards were so far awaz. (Beatles) -- Claus-Peter Warnecke, dtj, 12.3.2001 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable docs build failure
Hi,
On Tue, Jul 04, 2006 at 03:54:19AM -0700, Graham Percival wrote:
> The build fails on this snippet, lily-910891298.ly on my system:
well, I'm right now trying to bring lilypond 2.8.7 to OpenBSD, and
get exactly the same error on the same file (see quote below),
except here it's line 488, not 487.
Any ideas?
Ciao,
Kili
>
> %
> % ly snippet:
> %
> \score {
> \transpose c c' {
> \set Score.timing = ##f
> \set Score.defaultBarType = "empty"
> \override NoteHead #'style = #'neomensural
> \override Staff.TimeSignature #'style = #'neomensural
> \clef "petrucci-g"
> \[ c'\maxima g \]
> s4
> \[ d\longa c\breve f e d \]
> s4
> \[ c'\maxima d'\longa \]
> s4
> \[ e'1 a g\breve \]
> }
> \layout {
> \context {
> \Voice
> \remove Ligature_bracket_engraver
> \consists Mensural_ligature_engraver
> }
> }
> }
>
>
>
> Error messages:
>
> Calculating line breaks...
> programming error: Note_spacing::get_spacing(): Common refpoint incorrect
> continuing, cross fingers
> programming error: Note_spacing::get_spacing(): Common refpoint incorrect
> continuing, cross fingers
> ...
> Layout output to
> `lily-910891298-1.eps'.../home/gperciva/usr/src/stable-lilypond/lilypond/out/share/lilypond/current/scm/framework-ps.scm:487:24:
>
> In procedure inexact->exact in expression (inexact->exact (round #)):
> /home/gperciva/usr/src/stable-lilypond/lilypond/out/share/lilypond/current/scm/framework-ps.scm:487:24:
>
> Numerical overflow
> ...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: confusion about version numbers
On Thu, Jul 27, 2006 at 10:42:29AM +0200, Han-Wen Nienhuys wrote: > It was released, mostly with minor layout fixes. I'll do a 2.8.6 Any timeline for this? Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Source release 2.8.4, documentation 2.8.5?
Hi, I'm just trying to give the OpenBSD port prepared by Matt Jibson some final polish. Unfortunately, we can't build the documentation on OpenBSD (due to an old version of makeinfo in the base system), so I decided to use the downloadable tarball, which is versioned 2.8.5 -- in contrast to the source tarball (2.8.4). Is there any official release 2.8.5 of the sources planned? The current OpenBSD port would be a real kludge, mixing LilyPond 2.8.4 and the documentation versioned 2.8.5. I could also include patches between 2.8.4 and the CVS branch 2.8, but that doesn't seem very elegant, either. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: configure find wrong python path
On Mon, Jun 26, 2006 at 12:29:24PM +0200, Karl Hammar wrote: > > ps: do we really still have to use backticks instead of $(...)? > > Anyone running LilyPond on old systems with rotten shells? > > configure is about portability, why not keep the backticks? > The same goes for shells with 32bit int arith. Gotcha ;-) > It builds and runs ok (using debian v3.1). Yep, the build on OpenBSD I started later was fine, too. Ciao, Kili -- Als Katholik muss man halt auch mal auf ein Opfer verzichten können. -- Benedikt Spranger in der lug-bs ml ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: configure find wrong python path
On Wed, May 24, 2006 at 11:51:01PM +0200, Karl Hammar wrote:
> Given:
> $ ls -l /usr/bin/python*
> lrwxrwxrwx 1 root root 9 May 24 15:51 /usr/bin/python -> python2.3
> -rwxr-xr-x 1 root root 958764 Mar 6 11:32 /usr/bin/python2.3
> -rwxr-xr-x 1 root root 1024460 Apr 23 01:34 /usr/bin/python2.4
Similar setup here on OpenBSD:
$ ls -l /usr/local/bin/python*
lrwxr-xr-x 1 root wheel 9 Jun 4 23:02 /usr/local/bin/python -> python2.3
-r-xr-xr-x 1 root bin20028 Jun 4 23:00 /usr/local/bin/python2.3
-r-xr-xr-x 1 root bin20028 Jun 4 18:07 /usr/local/bin/python2.4
> configure will report wrong path of python:
>
> $ ./configure
> ...
> checking for bash... /bin/sh
> checking for python... python
> checking python version... 2.3.5
> checking for python... /usr/bin/python
> checking for gcc... gcc
> ...
> checking New Century Schoolbook PFB files... /usr/share/fonts/type...
> checking for python... /usr/bin/python
> checking /usr/bin/python version... 2.3.5
[...]
> Attached patch corrects the error above.
Unfortunately, configure completely bails out then using something like
$ PYTHON=/usr/local/bin/python2.4 ./configure ...
The problem is in STEPMAKE_GETVERSION, since it takes the first
line that looks like it contains a version number of the output
from [Path stripped to take the line shorter]:
$ python2.4 --version 2>&1 || python2.4 -V 2>&1
which is
Unknown option: --
usage: python2.4 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.
Python 2.4.3
The net result is that, for whatever reason, configure first detects
2.4.3, but later 2.3.5.
I think the attached patch fixes this. (Works at least when configuring
on OpenBSD).
Note that the patch contains another quick hack to let the version
check work on OpenBSD and other systems where the shell has 32 bit
integer arithmetic (without it, you'll get too large version numbers
for fontforge, letting configure think that 20060413 is smaller
than the requested version).
Ciao,
Kili
ps: do we really still have to use backticks instead of $(...)?
Anyone running LilyPond on old systems with rotten shells?
pps: I *only* tested the configure step yet. No idea wether it will
actually build and run.
ppps: Matt J., I assume you're subscribed to this list, so I don'y cc: ;-)
--
Windows is so bootyful...
$OpenBSD$
--- stepmake/aclocal.m4.origThu Jun 1 13:30:35 2006
+++ stepmake/aclocal.m4 Sun Jun 25 20:34:47 2006
@@ -31,9 +31,14 @@ AC_DEFUN(STEPMAKE_GET_VERSION, [
## for compatibility reasons.
## grab the first version number in --version output.
-eval _ver=\"\`("$1" --version || "$1" -V) 2>&1 | grep '[0-9]\.[0-9]' \
-| head -n 1 \
- | tr ' ' '\n' | grep '[0-9]\.[0-9]' | head -n 1 | sed
's/\([0-9.]*\).*/\1/g'\`\"
+eval '_ver=\`'"$1"' --version 2>&1\` || _ver=\`'"$1"' -V 2>&1\` &&
+_ver=\`echo $_ver |
+ grep '\''[0-9]\.[0-9]'\'' |
+ head -n 1 |
+ tr '\'' '\'' '\''\n'\'' |
+ grep '\''[0-9]\.[0-9]'\'' |
+ head -n 1 |
+ sed '\''s/\([0-9.]*\).*/\1/g'\''\`'
if test -z "$_ver"; then
## If empty, try date [fontforge]
@@ -48,12 +53,9 @@ AC_DEFUN(STEPMAKE_GET_VERSION, [
# Calculate simplistic numeric version from version string ($1)
# As yet, we have no need for something more elaborate.
AC_DEFUN(STEPMAKE_NUMERIC_VERSION, [
-echo "$1" | awk -F. '
-{
- if ([$]3) {three = [$]3}
- else {three = 0}
-}
-{printf "%.0f\n", [$]1*100 + [$]2*1000 + three}'
+ echo "$1" | awk -F. '
+ NF==1 {print; next}
+ {printf "%.0f\n", [$]1*100 + [$]2*1000 + [$]3}'
])
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: configure: readlink problem
On Sun, Jun 04, 2006 at 02:26:22PM -0700, Graham Percival wrote: > > The -f option tells readlink to rekursively resolv all links and find > >the file which the link finally points to. Without the -f readlink just > >just gives you what this link points to. > > Hmm. FreeBSD's readlink doesn't have any option like that. Workaround (untested): f=(whatever) while [ -h "$f" ]; do f=$(readlink "$f") done Ciao, Kili -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: "too many open files" returns
On Sat, Mar 11, 2006 at 04:43:43PM -0800, Graham Percival wrote: > I'm getting the "too many open files" problem again. Using make > external_binary web now. [...] > This arose a few months ago; there was a patch to texinfo that fixed > it. Yes, I actually found and fixed many flaws in texinfo (partially for OpenBSD). I sent all patches to Karl Berry, but he didn't yet make a new texinfo release. Patches are attached. Ciao, Kili -- if you can't read a man page, you aren't qualified to read my emails either. -- Ted Unangst patches.tgz Description: application/tar-gz ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make web (documents) on OSX
On Wed, May 11, 2005 at 01:57:55AM -0700, Graham Percival wrote:
> OSX ulimit -n is set to to 256 by default. A while ago, I increased
> that
> to 512 to allow lilypond to build. I'm not certain if this is still
> necessary,
> and I'd completely forgotten about that line in my ~/.profile
> I tried setting it to 2048 and the docs built successfully.
If it's makeinfo that's bailing out, tuning the limits is the wrong
solution to the right problem :-)
There's a file descriptor leak in the official texinfo-4.8. Below's
a patch for it (and some other bugs). Note that there are more small
indexing bugs; I allready sent all my patches to Karl Berry.
Ciao,
Kili
--- makeinfo/html.c.origMon Dec 6 02:13:06 2004
+++ makeinfo/html.c Tue Apr 5 17:17:15 2005
@@ -167,6 +167,8 @@ process_css_file (char *filename)
lastchar = c;
}
+ fclose(f);
+
/* Reached the end of the file. We should not be still in a comment. */
if (state == comment_state)
warning (_("%s:%d: --css-file ended in comment"), filename, lineno);
@@ -437,7 +439,9 @@ rollback_empty_tag (char *tag)
int check_position = output_paragraph_offset;
int taglen = strlen (tag);
int rollback_happened = 0;
- char *contents = "";
+ char *contents = ""; /* FIXME (ptr to constant, later
+ assigned to malloc'd address).
+*/
char *contents_canon_white = "";
/* If output_paragraph is empty, we cannot rollback :-\ */
@@ -445,7 +449,7 @@ rollback_empty_tag (char *tag)
return 0;
/* Find the end of the previous tag. */
- while (output_paragraph[check_position-1] != '>' && check_position > 0)
+ while (check_position > 0 && output_paragraph[check_position-1] != '>')
check_position--;
/* Save stuff between tag's end to output_paragraph's end. */
@@ -462,7 +466,7 @@ rollback_empty_tag (char *tag)
}
/* Find the start of the previous tag. */
- while (output_paragraph[check_position-1] != '<' && check_position > 0)
+ while (check_position > 0 && output_paragraph[check_position-1] != '<')
check_position--;
/* Check to see if this is the tag. */
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
ec-fonts-mftraced (was: Runtime errors on OpenBSD)
On Thu, Mar 17, 2005 at 07:44:31PM -0500, David Jedlinsky wrote: > ec-fonts-mftraced takes *forever* to run. Is this normal? Or should > I have installed potrace, because it's better than autotrace in some > way? You could do it the way Matt did it: fetch the .deb package, extract this and put ec-mftrace.map to the appropriate place (texmf/fonts/map/ec-fonts-mftraced). For your other problems, I really recommend to upgrade to a recent OS version and use my or Matt's ports, if you don't have too much private ports/nonstandard software on your system. 3.7-beta runs fine for me, but backporting our ports to 3.6 shouldn't be too difficult. I just won't do this because I don't have any 3.6 installed here (and my server will be upgraded soon). Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More makefile oddities (was: Suspicious path issues...)
Again selfquoting... On Fri, Mar 11, 2005 at 05:18:16PM +0100, Matthias Kilian wrote: > Date: Fri, 11 Mar 2005 17:18:16 +0100 > From: Matthias Kilian <[EMAIL PROTECTED]> > To: lilypond-devel@gnu.org > Message-ID: <[EMAIL PROTECTED]> > Subject: More makefile oddities (was: Suspicious path issues...) > X-CRM114-Status: Good ( pR: 195.7705 ) > > Hi, > > On Thu, Mar 10, 2005 at 08:00:18PM +0100, Matthias Kilian wrote: > However, I now have the problem that gmake doesn't correctly recognize > the dependency below resp. does really odd things to $(OUT_*_IMAGES) [...] > $ gmake out=www bar > gmake: *** No rule to make target `/baer-flat-bw.eps', needed by `bar'. Stop. Solved. I used to run MAKEINFO=/usr/local/bin/makeinfo sh autogen.sh, since OpenBSD's own texinfo is too old and I'd to install a newer one in /usr/local. This, however, breaks the check for SPLITTING_MAKEINFO in aclocal.m4 (see patch below), which in turn disables the rule $(outdir)/lilypond.dvi: $(OUT_EPS_IMAGES) $(OUT_PNG_IMAGES) and the png and eps rules in Documentation/user/GNUmakefile, since those rules are in an ifeq($(SPLITTING_MAKEINFO),yes) block. My quick hack just changes the aclocal check (note that there are some more such tests in aclocal), but IMHO, the ifeq magic in the GNUmakefile is wrong and should be removed. But I could be wrong. --- stepmake/aclocal.m4.origSat Feb 12 13:05:02 2005 +++ stepmake/aclocal.m4 Fri Mar 11 18:07:07 2005 @@ -846,7 +846,7 @@ AC_DEFUN(STEPMAKE_LOCALE, [ AC_DEFUN(STEPMAKE_MAKEINFO, [ STEPMAKE_PROGS(MAKEINFO, makeinfo, $1) -if test "$MAKEINFO" = "makeinfo"; then +if test `basename "$MAKEINFO"` = "makeinfo"; then AC_MSG_CHECKING(whether makeinfo can split html by @node) mkdir -p out makeinfo --html --output=out/split <http://lists.gnu.org/mailman/listinfo/lilypond-devel
More makefile oddities (was: Suspicious path issues...)
Hi, On Thu, Mar 10, 2005 at 08:00:18PM +0100, Matthias Kilian wrote: > b) references a target `outimages' which isn't defined anywhere, thus > breaking make web. I just saw that you've removed this for 2.5, so did I on my local working copy of 2.4. However, I now have the problem that gmake doesn't correctly recognize the dependency below resp. does really odd things to $(OUT_*_IMAGES) $(outdir)/lilypond.dvi: $(OUT_EPS_IMAGES) $(OUT_PNG_IMAGES) I added the following targets for debugging: | .PHONY: foo bar | foo: | @echo $(OUT_EPS_IMAGES) | | bar: $(OUT_EPS_IMAGES) This gives the following result. $ gmake out=www foo ./out-www/baer-flat-bw.eps ./out-www/henle-flat-bw.eps ./out-www/lily-flat-bw.eps $ gmake out=www bar gmake: *** No rule to make target `/baer-flat-bw.eps', needed by `bar'. Stop. Note that this independent of --no-builtin-rules. Now comes the fun: With a Makefile stripped down to exactly this problem, it works: | depth=../.. | | IMAGES=$(wildcard *.png) | | OUT_EPS_IMAGES=$(addprefix $(outdir)/,$(IMAGES:.png=.eps)) | | .PHONY: foo bar | foo: | @echo $(OUT_EPS_IMAGES) | | bar: $(OUT_EPS_IMAGES) | | $(outdir)/%.png: %.png | convert -geometry 50x50% $< $@ | | $(outdir)/%.eps: %.png | convert $< $@ | | include $(depth)/make/stepmake.make Has anyone an idea what's going on here? Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suspicious path issues in Makefiles ;-)
On Wed, Mar 09, 2005 at 08:27:08PM +0100, Jan Nieuwenhuizen wrote: > > Sorry for any confusion I may have caused. > > That's ok, this should be fixed; I'll apply your patches. Here's yet another one I missed (I had to install a recent makeinfo before building documentation): --- stepmake/stepmake/texinfo-vars.make.origSun Oct 24 15:47:36 2004 +++ stepmake/stepmake/texinfo-vars.make Thu Mar 10 17:36:17 2005 @@ -17,7 +17,7 @@ MAKEINFO = LANG= $(MAKEINFO_PROGRAM) -- # info stuff INFO_INSTALL_FILES = $(wildcard $(addsuffix *, $(INFO_FILES))) INFO_INSTALL_COMMAND =$(if $(INFO_INSTALL_FILES),\ - $(INSTALL) -d $(DESTDIR)$(package_infodir) ; \ - $(MAKE) INSTALLATION_OUT_DIR=$(DESTDIR)$(package_infodir) \ + $(INSTALL) -d $(package_infodir) ; \ + $(MAKE) INSTALLATION_OUT_DIR=$(package_infodir) \ depth=$(depth) INSTALLATION_OUT_FILES="$(INFO_INSTALL_FILES)" \ -f $(stepdir)/install-out.sub.make,true) Further under focus is Documentation/user/GNUmakefile, which a) also seems to use DESTDIR (I just find/xargs/grep for DESTDIR), b) references a target `outimages' which isn't defined anywhere, thus breaking make web. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suspicious path issues in Makefiles ;-)
On Tue, Mar 08, 2005 at 09:23:11AM +0100, Jan Nieuwenhuizen wrote: > Hmm, that's strange. I can't seem to find where > local_lilypond_datadir would get the DESTDIR prefix, unless it would > be from $prefix. Well, I just see that I didn't mention that I'm working on LilyPond-2.4.x. There you have prefix = $(DESTDIR)@prefix@ in config.make.in, so pretty everything is prefixed by DESTDIR. Sorry for any confusion I may have caused. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suspicious path issues in Makefiles ;-)
On Tue, Mar 08, 2005 at 09:23:11AM +0100, Jan Nieuwenhuizen wrote: > Hmm, that's strange. I can't seem to find where > local_lilypond_datadir would get the DESTDIR prefix, unless it would > be from $prefix. You wouldn't be specifying them both, like > > make install prefix=../fake-i386/usr/ports DESTDIR=../fake-i136/usr/ports > > that won't work. It sets both PREFIX (all caps) and DESTDIR. I'll try to find out what exactly goes on. Ciao, Kili -- Zesterdaz, all mz kezboards were so far awaz. (Beatles) [Claus-Peter Warnecke, dtj, 12.3.2001] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suspicious path issues in Makefiles ;-)
On Mon, Mar 07, 2005 at 11:40:21PM +0100, Jan Nieuwenhuizen wrote: > > - -$(INSTALL) -d $(DESTDIR)$(local_lilypond_datadir)/dvips > > - (cd $(DESTDIR)$(local_lilypond_datadir)/dvips && ln -sf ../fonts/map .) > > + -$(INSTALL) -d $(local_lilypond_datadir)/dvips > > + (cd $(local_lilypond_datadir)/dvips && ln -sf ../fonts/map .) > > I don't get this. Why do you need it? It's used during the OpenBSD fake installation -- they set up a temporary installation hierarchy and make install with, for example, DESTDIR=/usr/ports/print/lilypond/w-lilypond-2.4.5/fake-i386. This temporary hierarchy is then used to make a binary package. Without the patch, some file go to /usr/ports//fake-i386/usr/ports//fake-i386, i.e. DESTDIR seems to be allready contained in local-lilypond_datadir. Mostly harmless, but maybe other packagers have similar problems. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suspicious path issues in Makefiles ;-)
On Mon, Mar 07, 2005 at 10:54:58PM +0100, Matthias Kilian wrote: > could anyone check wether the attached diffs are sane? I need them > for Matt's OpenBSD ports. Sorry, I'm probably a little bit too drunk ;-) here are the patches. $OpenBSD$ --- mf/GNUmakefile.orig Sat Feb 12 13:04:41 2005 +++ mf/GNUmakefile Mon Mar 7 20:09:59 2005 @@ -215,9 +215,9 @@ $(outdir)/%.enc.in: %.enc # teTeX-2.0.x compatibility. local-install: - -$(INSTALL) -d $(DESTDIR)$(local_lilypond_datadir)/dvips - (cd $(DESTDIR)$(local_lilypond_datadir)/dvips && ln -sf ../fonts/map .) + -$(INSTALL) -d $(local_lilypond_datadir)/dvips + (cd $(local_lilypond_datadir)/dvips && ln -sf ../fonts/map .) local-uninstall: - -rm -f $(DESTDIR)$(local_lilypond_datadir)/dvips/map - -rmdir $(DESTDIR)$(local_lilypond_datadir)/dvips + -rm -f $(local_lilypond_datadir)/dvips/map + -rmdir $(local_lilypond_datadir)/dvips $OpenBSD$ --- tex/GNUmakefile.origSat Feb 12 13:05:11 2005 +++ tex/GNUmakefile Mon Mar 7 20:09:59 2005 @@ -26,12 +26,12 @@ $(outdir)/latin1.enc: GNUmakefile # teTeX-2.0.x compatibility. local-install: - -$(INSTALL) -d $(DESTDIR)$(local_lilypond_datadir)/tex - (cd $(DESTDIR)$(local_lilypond_datadir)/tex && ln -sf ../fonts/enc .) + -$(INSTALL) -d $(local_lilypond_datadir)/tex + (cd $(local_lilypond_datadir)/tex && ln -sf ../fonts/enc .) local-uninstall: - -rm -f $(DESTDIR)$(local_lilypond_datadir)/tex/enc - -rmdir $(DESTDIR)$(local_lilypond_datadir)/tex + -rm -f $(local_lilypond_datadir)/tex/enc + -rmdir $(local_lilypond_datadir)/tex all: $(INSTALLATION_FILES) $(INSTALLATION_OUT_FILES1) $OpenBSD$ --- stepmake/stepmake/help2man-targets.make.origMon Jun 23 00:36:47 2003 +++ stepmake/stepmake/help2man-targets.make Mon Mar 7 20:09:59 2005 @@ -3,9 +3,9 @@ default: man local-install: install-help2man install-help2man: man - -$(INSTALL) -d $(DESTDIR)$(mandir)/man1 + -$(INSTALL) -d $(mandir)/man1 $(foreach a, $(HELP2MAN_GROFFS), \ - $(INSTALL) -m 644 $(a) $(DESTDIR)$(mandir)/man1 && ) true + $(INSTALL) -m 644 $(a) $(mandir)/man1 && ) true man: $(HELP2MAN_GROFFS) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Suspicious path issues in Makefiles ;-)
Hi, could anyone check wether the attached diffs are sane? I need them for Matt's OpenBSD ports. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Missing CVS release tags
Hi, is there any good reason that lilypond releases aren't tagged in the CVS since 2_4_2? $ cvs -qz7 status -v VERSION | sed 15q === File: VERSION Status: Up-to-date Working revision:1.621 Repository revision: 1.621 /cvsroot/lilypond/lilypond/VERSION,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: lilypond_2_4_2 (revision: 1.602.2.2) lilypond_2_4(branch: 1.602.2) lilypond_2_3_25 (revision: 1.600) lilypond_2_3_24 (revision: 1.599) lilypond_2_3_23 (revision: 1.598) Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compilation on FreeBSD
On Mon, Feb 28, 2005 at 11:54:54AM +0100, Jan Nieuwenhuizen wrote: > > FreeBSD maintainer of Lilypond is irresponsive :-( > > That's too bad. FYI: Matt Jibson currently works on an OpenBSD port (of LilyPond and related tools), that I hope to test and watch over soon. May be that this can be backported to FreeBSD. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile use
On Tue, Jun 01, 2004 at 01:58:08PM -0300, Pedro Kroger wrote: > http://www.gnu.org/software/guile/gnu-guile-projects.html > > "snd" uses guile heavily, for sure as extensively as lilypond. I don't > know about the others. The big difference between LilyPond and Snd is: LilyPond itself is partially implemented in guile, but Snd uses guile just for extending it. For Snd, you can even ./configure --without-guile (for whatever reason). Ciao, Kili ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile use
On Tue, Jun 01, 2004 at 08:09:22PM +0200, Han-Wen Nienhuys wrote: > > Just curious: Is there any other project which uses Guile as > > extensively as LilyPond? I would like to have a comparison. > > Not sure. You might want to look at Gnucash and texmacs. Also, I > believe GUILE is the primary platform for common music/notation > nowadays, but they running on top of GUILE, not using it as an > extension language. Snd (see http://ccrma.stanford.edu/software/snd/) may be an exception; it makes use of guile (and nowadays optionally ruby) for extension and control. Guile is for snd what emacs-lisp is for emacs. However, I didn't do much wich snd an nothing at all with snd+guile, since I'm a victim of the bad big time-eating monster ;-) Ciao, Kili ps: I hope to get my hands back on my ciaconna project(s) next month. ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why not to implement everything in scheme?
On Mon, Mar 22, 2004 at 09:33:34PM +0100, Nicolas Sceaux wrote: > You're unfair, you have deleted my smiley when quoting me. It was the > short way for expressing your last paragraph (sort of). Sorry, I probably was in a bad mood (for reasons not related to LilyPond). Ciao, Kili ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: 'make all' still fails ChangeLog 1.1942 --follow-up
On Tue, Mar 23, 2004 at 06:12:03PM +, David Bobroff wrote: > > please double check,- fixed this error a long time ago. If unsure, rm > > accidental-engraver.cc and update from CVS. > > Tried again with a fresh checkout. Same story: > -o out/accidental-engraver.o accidental-engraver.cc > accidental-engraver.cc: In member function `virtual void >Accidental_engraver::acknowledge_grob(Grob_info)': > accidental-engraver.cc:444: cannot convert `const char*' to > `scm_unused_struct* >' for argument `1' to `bool to_boolean(scm_unused_struct*)' [...] Same here. A (cvs) diff between HEAD and 2.1.33 (or 2.1.34 and 2.1.33) shows that the call in question is new. Seems to be a missing get_property()? Ciao, Kili ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Why not to implement everything in scheme?
On Mon, Mar 22, 2004 at 08:37:24PM +0100, Nicolas Sceaux wrote: > I'm not sure that there will be pletor of volonteers for recoding > thousands of C++ LOC in whatever other language. You just have to write a C++2scm translator ;-) > hmmm, thinking of it... I volonteer for LilyPond in Common Lisp!!! > cliclypond is so easier to pronounce. I'd prefer RubyPond :-) To be serious: the current implementation is o.k., and, IIRC, Han-Wen mentioned in the interview at linuxmusician.com that the C++ part is planned to shrink away. I also thought a lot of wether using scheme/guile as semi-backend is the best choice. It's a matter of taste and readability. Personally, I don't like scheme very much; allthough it's small and easy to learn, it's IMHO difficult to read and looks ugly. Thus, using something like Ruby *may* be an alternative, possibly attracting more volunteers, possibly not. Anyways. Wether you like/disklike C++, Scheme, Ruby, Python, Haskell, whatever: those who do participate in active LilyPond development should concentrate on improving LilyPond, not in using endless time by changing the languages used. At least not until a certain point of stabilization has been reached. Ciao, Kili ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
script-abbreciations.ly: text attatchments broken
Hi,
I just built 2.1.33, and since the script-abbreviations.ly is still
completely broken, I kind of "repaired" it (see attachment).
Unfortunately, it's still incorrect (wrong characters for `|' and `>'
due to math mode), but at least now it displays something reasonable.
Ciao,
Kili
% this chart is used in the manual too.
\version "2.1.33"
\header { texidoc = "@cindex Script Abbreviations
Some articulations may be entered using an abbreviation.
"
}
\score {
\notes \context Voice {
\override TextScript #'font-family = #'typewriter
\override TextScript #'font-shape = #'upright
c''4-._"c-." s4
c''4--_"c-{}-"s4
c''4-+_"c-+" s4
c''4-|_"c-$|$"s4
c''4->_"c-$>$"s4
c''4-^_"c-\^~"s4
c''4-__"c-\_" s4
}
}
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: anomalies with 2.1.32
[Changed to development list, since it's really a bleeding-edge issue]
On Sat, Mar 20, 2004 at 04:43:34PM +, David Bobroff wrote:
> I'm still getting those same anomalies with v2.1.32; that is, dismbodied
> beams, multimeasure rest numbers displaced to the right, etc. [...]
Me, too :-(
For example, both 2.1.32 and the head revision (ChangeLog 1.1917) give
me very strange results for script-abbreviations.ly (and others). See
attached files (script-abbreviations.ly and script-abbreviations.png).
There are other, even more strange errors on my chaconne example, such
as noteheads at completely wrong places, overlapping systems, randomly
misplaced accidentals, etc. Unfortunately, I didn't manage to reproduce
those effects with a small file.
Ciao,
Kili
% this chart is used in the manual too.
\version "2.1.30"
\header { texidoc = "@cindex Script Abbreviations
Some articulations may be entered using an abbreviation.
"
}
\score {
\notes \context Voice {
\override TextScript #'font-family = #'typewriter
\override TextScript #'font-shape = #'upright
c''4-._"c-." s4
c''4--_"c-{}-"s4
c''4-+_"c-+" s4
c''4-|_"c-|" s4
c''4->_"c->" s4
c''4-^_"c\\^{ }" s4
c''4-__"c\_" s4
}
}
<>___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: CVS problems (savannah down?)
On Fri, Mar 19, 2004 at 01:29:47AM +0100, Han-Wen Nienhuys wrote: > > is it only me who can't access the CVS server at savannah.gnu.org for > > the last three days? [...] > For me, it's been up again since this morning. Thanks. I can access it again, too. Ciao, Kili -- Könn't man kyrillisch, wär's echt idyllisch. ["hwicht" in de.rec.motorrad] ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
CVS problems (savannah down?)
Hi, is it only me who can't access the CVS server at savannah.gnu.org for the last three days? Even ping or traceroute don't get a response. However, some recent mails on the LilyPond lists made me think that some people get connections to the server. That's really odd, and it's not a problem of my provider (a friend had the same problem from a t-online access). Ciao, Kili, suffering LilyPond-Junkie -- Just wait. My crystal ball is infallible. [Linux Torvalds, 20.1.2001] ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: Less restrictive LilyPond identifiers?
On Sun, Mar 07, 2004 at 03:03:30PM +0100, Matthias Kilian wrote:
[Letters and digits in identifiers]
> If there's no other reason for disallowing digits than to keep
> parser/scanner, I could try to write a patch.
Quick hack alert! The patch below appears to work. However, it applies
only to scanner rules using NOTECOMMAND. And, of course, documentation
and emacs and vim configuration would have to be changed. I'd work on
documentation and vim configuration if this patch is accepted.
Ciao,
Kili
diff -x CVS -rNup ../lilypond-2.1.29/lily/lexer.ll ./lily/lexer.ll
--- ../lilypond-2.1.29/lily/lexer.ll2004-02-24 21:00:57.0 +0100
+++ ./lily/lexer.ll 2004-03-07 18:25:38.0 +0100
@@ -112,12 +112,13 @@ SCM (* scm_parse_error_handler) (void *)
A [a-zA-Z]
AA {A}|_
N [0-9]
-AN {AA}|{N}
+AN {A}|{N}
+AAN{AA}|{N}
PUNCT [?!:'`]
ACCENT \\[`'"^]
NATIONAL [\001-\006\021-\027\031\036\200-\377]
TEX{AA}|-|{PUNCT}|{ACCENT}|{NATIONAL}
-WORD {A}{AN}*
+WORD {A}{AAN}*
ALPHAWORD {A}+
DIGIT {N}
UNSIGNED {N}+
@@ -130,7 +131,7 @@ WHITE [ \n\t\f\r]
HORIZONTALWHITE[ \t]
BLACK [^ \n\t\f\r]
RESTNAME [rs]
-NOTECOMMAND\\{A}+
+NOTECOMMAND\\{A}{AN}*
MARKUPCOMMAND \\({A}|[-_])+
LYRICS ({AA}|{TEX})[^0-9 \t\n\r\f]*
ESCAPED[nt\\'"]
diff -x CVS -rNup ../lilypond-2.1.29/lily/parser.yy ./lily/parser.yy
--- ../lilypond-2.1.29/lily/parser.yy 2004-02-26 22:59:50.0 +0100
+++ ./lily/parser.yy2004-03-07 18:27:21.0 +0100
@@ -123,11 +123,10 @@ is_regular_identifier (SCM id)
String str = ly_scm2string (id);
char const *s = str.to_str0 () ;
- bool v = true;
- while (*s && v)
+ bool v = *s && isalpha(*s);
+ while (*++s && v)
{
-v = v && isalpha (*s);
-s++;
+v = v && isalnum (*s);
}
return v;
}
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Less restrictive LilyPond identifiers?
Hi,
are there any reasons to restrict identifiers in LilyPond to contain only
letters? IMO, it would be nice to at least also allow digits. That would
make it easier to write large pieces by defining small chuncs of music:
Part1Voice1 = \notes {...}
Part1Voice2 = \notes {...}
...
At least for allowing digits, nothing of the tests, examples and
documentation of LilyPond would be broken, since a quick
$ find . -type f | xargs grep -l '\\[[:alpha:]]\+[[:digit:]]'
only lists some non-ly files.
Allowing _ or - would certainly break existing LilyPond input (for
example, the \fermata_"Cadenza ad lib." in the Mozart example).
If there's no other reason for disallowing digits than to keep
parser/scanner, I could try to write a patch.
Ciao,
Kili
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation error
On Sat, Mar 06, 2004 at 12:44:13AM +0100, Matthias Kilian wrote: > introducing "exotic" dependencies like makeinfo CVS, there should be > also workarounds that make LilyPond (and it's documenation) compile with > standard versions (i.e. good-old makeinfo-4.5 or 4.6). Please forget what I wrote. Using makeinfo-4.6 the compilation succeeds. Ciao, Kili ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: compilation error
Hi! On Mon, Mar 01, 2004 at 06:36:46PM +0100, Jan Nieuwenhuizen wrote: > > Even then -- I tried to compile the texinfo CVS, which relies on a > > brand new automake version which > > Point taken; you don't need texinfo CVS. Using the current LilyPond CVS (seems to be an upcoming 2.1.29) and makeinfo-4.5, I still get "Too many errors!" and a core dump :-( On Wed, Mar 03, 2004 at 12:44:53AM +0100, Jan Nieuwenhuizen wrote: [Discourage users from compiling LilyPond] > You are right. Maybe we are sending conflicting messages: do not > compile Lily! Help us (with the docs), send patches! > > What to do? Maybe we should just change the 'do not compile' attitude > a bit, and have 'supported' development platforms with a detailed > recipe to compile lily. The contributers of binary releases should > make sure that the recipe stays up to date. Would this work? Well, I've *no* distribution at all. Nevertheless, LilyPond builds without problems (with the exception of the makeinfo problems). Requirements are mentioned in INSTALL.texi (BTW: makeinfo CVS is missing), so there's no reasaon to discourage people from compiling LilyPond at all or to restrict them to use "certified" environments. "Use the Source, Luke!" That's what open source is about. LilyPond says "Better don't use the Source, it may cause fear, fear causes anger, anger causes hate, and hate leads you to he dark side of the power^WSource." :-) IMO, whoever wants to contribute *should* be able to use (and build from) the sources, and (s)he should be encouraged to do so. Thus, when introducing "exotic" dependencies like makeinfo CVS, there should be also workarounds that make LilyPond (and it's documenation) compile with standard versions (i.e. good-old makeinfo-4.5 or 4.6). Ciao, Kili ps: I'll try to make `make web' working with old `standard' makeinfo (4.5) installations. Expect patches on sunday. -- "How do I read this file?" - "You uudecode it." - "I I I decode it?" ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: How to debug/play with scheme code?
On Mon, Mar 01, 2004 at 08:43:55PM +0100, Nicolas Sceaux wrote: [interactive Scheme] > > try #(top-repl) > > that's cute :-) Indeed. Allthough it's a guile-feature, it should be mentioned somewhere in the documentation. I'll record all glitches/pitfalls/tricks while learning LilyPond internals. This could be a base for starting a "LilyPond-Hacking-HOWTO". Regards, Kili ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
How to debug/play with scheme code?
Hi, since I'd like to become a "brilliant LilyPond hacker", and I currently want to do some more ore less evil scheme hacking, I wonder wether there's an easy way to debug scheme code or to get something like an interactive scheme interpreter with LilyPond's extensions allready loaded. Starting with .ly files isn't very convenient. Thanks in advance. Regards, Kili ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Documentation patch (Vim mode)
Hi,
the configuration instructions for the Vim mode contain a small error
(at least when using vim-6.2). See attached patch.
Regards,
Kili
diff -rNup ../lilypond-2.1.28/Documentation/topdocs/INSTALL.texi
./Documentation/topdocs/INSTALL.texi
--- ../lilypond-2.1.28/Documentation/topdocs/INSTALL.texi 2004-01-21
22:07:35.0 +0100
+++ ./Documentation/topdocs/INSTALL.texi2004-02-29 17:47:21.0 +0100
@@ -253,7 +253,7 @@ and appending the following to @file{~/.
endif
augroup filetypedetect
au! BufRead,BufNewFile *.ly setfiletype lilypond
- augroup
+ augroup END
@end example
@end quotation
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
