Re: [PATCH] Use find ... | xargs rm -f instead of find ... -delete
Matthias Kilian writes: > 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. Please mention this in the commit message. -- David Kastrup ___ 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
Graham Percival writes:
>> Then change it to something like this:
>>
>> find $(outdir)/offline-root -type l -print0 | xargs -0 rm -f --
>>
>> Or even this (completely POSIX compliant):
>>
>> find $(outdir)/offline-root -type -l -exec rm -f -- '{}' +
>>
>> (but then I've to patch it again, since find(1) on OpenBSD doesn't yet
>> support the `-exec command {} +' primary).
>
> Well, if that's part of POSIX, then adding it can't be a bad
> thing. :)
Isn't AFAIK.
> But for the purposes of the lilypond build scripts, I don't think it's
> necessary. The first version of the patch should be fine.
Ok, if the directory is complete under user control (not world-writable
in general: if it were, you could just put nasties in the Makefiles
anyway).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
translation files not distributed
file from VC not distributed: lilypond-2.13.10/Documentation/hu/web.texi file from VC not distributed: lilypond-2.13.10/Documentation/hu/web/download.itexi file from VC not distributed: lilypond-2.13.10/Documentation/hu/web/introduction.itexi file from VC not distributed: lilypond-2.13.10/Documentation/hu/web/manuals.itexi Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: remove duplicate anchor generation in texi2html
On 2009-12-29, Patrick McCarty wrote:
>
> After an hour digging through the texi2html source, I was not able to
> figure it out, so I'll come back this issue in a couple of days.
>
> Though, as an experiment, I tried nulling the first return value
> instead of the second, and the second-layer TOC did not disappear. I
> don't know if this causes problems elsewhere though. See the diff
> below.
>
>
> diff --git a/Documentation/lilypond-texi2html.init
> b/Documentation/lilypond-texi2html.init
> index 1ff5d8a..2906347 100644
> --- a/Documentation/lilypond-texi2html.init
> +++ b/Documentation/lilypond-texi2html.init
> @@ -733,7 +733,10 @@ sub lilypond_element_target_name($$$)
># TODO: Once texi2html correctly prints out the target and not the id for
># the sections, change this back to ($id, $target)
>$target = lc($target);
> - return ($target, $target);
> +
> + # remove duplicate anchor generation
> + return ("", $target);
> + #return ($target, $target);
> }
I forgot to mention that with this patch, hyperlinks have a "#"
appended to them instead of a "#" followed by the node name. So it's
still not satisfactory.
I tried to figure out where the hyperlink names are generated. I
assume the procedure does a simple concatenation of the filename, #,
and the node name (id), but the location of this code has evaded me so
far.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: remove duplicate anchor generation in texi2html
On 2009-12-29, Patrick McCarty wrote:
> On Mon, Dec 28, 2009 at 2:26 PM, Graham Percival
> wrote:
> > The below patch stops texi2html from creating two anchors, making the
> > webpage navigation much more comfortable. However, it also makes the
> > TOC navbars disappear.
> >
> > diff --git a/Documentation/lilypond-texi2html.init
> > b/Documentation/lilypond-texi
> > index 1ff5d8a..2ca1a67 100644
> > --- a/Documentation/lilypond-texi2html.init
> > +++ b/Documentation/lilypond-texi2html.init
> > @@ -733,7 +733,10 @@ sub lilypond_element_target_name($$$)
> > # TODO: Once texi2html correctly prints out the target and not the id for
> > # the sections, change this back to ($id, $target)
> > $target = lc($target);
> > - return ($target, $target);
> > +
> > +# removes duplicate anchor generation
> > + return ($target, "");
> > +# return ($target, $target);
> > }
>
> The HTML for the second-layer TOC is missing after applying this
> patch, so the CSS is not broken, just the HTML. div#tocframe is still
> generated, but only for the top-level TOC.
>
> Also, it's only an accident that this would make the webpage
> navigation more comfortable, since the real solution is to remove the
> anchors from the hyperlink URLs when the texinfo is split by section
> (I'm working on it). With this patch, the hyperlink anchors point to
> a non-existent anchors; while harmless, it's still annoying. :-)
After an hour digging through the texi2html source, I was not able to
figure it out, so I'll come back this issue in a couple of days.
Though, as an experiment, I tried nulling the first return value
instead of the second, and the second-layer TOC did not disappear. I
don't know if this causes problems elsewhere though. See the diff
below.
Thanks,
Patrick
diff --git a/Documentation/lilypond-texi2html.init
b/Documentation/lilypond-texi2html.init
index 1ff5d8a..2906347 100644
--- a/Documentation/lilypond-texi2html.init
+++ b/Documentation/lilypond-texi2html.init
@@ -733,7 +733,10 @@ sub lilypond_element_target_name($$$)
# TODO: Once texi2html correctly prints out the target and not the id for
# the sections, change this back to ($id, $target)
$target = lc($target);
- return ($target, $target);
+
+ # remove duplicate anchor generation
+ return ("", $target);
+ #return ($target, $target);
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
StaffGrouper vs. VerticalAxisGroup: syntax inconsistencies
Folks,
why can I say
\new PianoStaff \with {
\override StaffGrouper
#'between-staff-spacing #'minimum-distance = #20
} ...
but not
\new Staff \with {
\override VerticalAxisGroup
#'next-staff-spacing #'minimum-distance = #20
} ...
?
The latter gives this warning:
warning: type check for `next-staff-spacing' failed;
value `((minimum-distance . 12) .
#)'
must be of type `list'
I would like to use former syntax form for the latter too, and it
seems to be a real syntax inconsistency since both the
`between-staff-spacing' and `next-staff-spacing' lists contain the
same elements.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On Wed, Dec 30, 2009 at 5:13 AM, Carl Sorensen wrote: > > So now make fails, with this error message: Interesting. When was the last time you did a fresh "make" ? Was it before 21 Dec 2009 ? > ./include/libc-extension.hh:51: error: declaration does not declare anything > ./include/libc-extension.hh:51: error: declaration does not declare anything > lipo: can't open input file: > /var/folders/Rv/RvqP2cCoEOawyy1FGSxWZU+++TI/-Tmp-//ccyBa9Qz.out (No such > file or directory) Silly question: you're not out of HD space, are you? :) > Any thoughts? My first thought is http://code.google.com/p/lilypond/issues/detail?id=947 which was applied on 21 Dec here: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=6b78efc2ea0cb064850c264ff225d9930353a178 but I can't see any vector in libc-extension.hh. So then the question is "what version of gcc are you using exactly", and we start fishing around with various low-level issues. I can't see how the recent texinfo macro games would possibly affect this. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please do a "make doc-clean; make clean"
On 12/29/09 9:32 PM, "Graham Percival" wrote: > Oops, relied off-list by accident. > > Please do a new pull, and build from a fresh tree. This mess was > fixed in 7b34eac90f81c8123feaf2670fafae236101f14c and I can confirm > that it's ok in 80ebf95c872dd6afd587ce388e7fa3ca216937aa . > > I don't know if the "make clean" is strictly necessary, but it can't hurt. So now make fails, with this error message: cp -p /Users/Carl/lilypond-working/config.hh out/config.hh rm -f ./out/file-cookie.dep; DEPENDENCIES_OUTPUT="./out/file-cookie.dep ./out/file-cookie.o" g++ -c -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -DHAVE_CONFIG_H -DNDEBUG -I./include -I./out -I../flower/include -I../flower/./out -I/opt/local/include -O2 -finline-functions -g -pipe -I/opt/local/include -I/opt/local/include -D_THREAD_SAFE -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/pango-1.0 -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -W -Wall -Wconversion -o out/file-cookie.o file-cookie.cc ./include/libc-extension.hh:51: error: declaration does not declare anything ./include/libc-extension.hh:51: error: declaration does not declare anything lipo: can't open input file: /var/folders/Rv/RvqP2cCoEOawyy1FGSxWZU+++TI/-Tmp-//ccyBa9Qz.out (No such file or directory) make[1]: *** [out/file-cookie.o] Error 1 make: *** [all] Error 2 sorensen2:lilypond-working Carl$ flower/include/libc-extension.hh looks like this: 48 49 #if ! HAVE_SNPRINTF /* GNU extension. */ 50 int snprintf (char *str, size_t n, char const *format, ...); 51 __attribute__ ((format (printf, 3, 4))); 52 #endif 53 Any thoughts? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
please do a "make doc-clean; make clean"
Oops, relied off-list by accident.
Please do a new pull, and build from a fresh tree. This mess was
fixed in 7b34eac90f81c8123feaf2670fafae236101f14c and I can confirm
that it's ok in 80ebf95c872dd6afd587ce388e7fa3ca216937aa .
I don't know if the "make clean" is strictly necessary, but it can't hurt.
Cheers,
- Graham
On Wed, Dec 30, 2009 at 3:37 AM, Carl Sorensen wrote:
> The documentation is broken right now due to the french translation of the
> Notation reference.
>
> A bad index entry is found in Documentation/fr/out-www/notation.cp
>
> Line 2 in this file is:
>
> \entry{\par }{1}{\code {\par }}
>
>
> In the corresponding file Documentation/out-www/notation.cp, line 2 is
>
> \entry{Manuals}{1}{\code {Manuals}}
>
>
> I'm guessing there's something wrong with the translation, and that's beyond
> my expertise, so I'm just reporting it.
>
> Thanks,
>
> Carl
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Make doc broken by french translation
The documentation is broken right now due to the french translation of the
Notation reference.
A bad index entry is found in Documentation/fr/out-www/notation.cp
Line 2 in this file is:
\entry{\par }{1}{\code {\par }}
In the corresponding file Documentation/out-www/notation.cp, line 2 is
\entry{Manuals}{1}{\code {Manuals}}
I'm guessing there's something wrong with the translation, and that's beyond
my expertise, so I'm just reporting it.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: remove duplicate anchor generation in texi2html
On Mon, Dec 28, 2009 at 2:26 PM, Graham Percival wrote: > The below patch stops texi2html from creating two anchors, making the > webpage navigation much more comfortable. However, it also makes the > TOC navbars disappear. > > diff --git a/Documentation/lilypond-texi2html.init > b/Documentation/lilypond-texi > index 1ff5d8a..2ca1a67 100644 > --- a/Documentation/lilypond-texi2html.init > +++ b/Documentation/lilypond-texi2html.init > @@ -733,7 +733,10 @@ sub lilypond_element_target_name($$$) > # TODO: Once texi2html correctly prints out the target and not the id for > # the sections, change this back to ($id, $target) > $target = lc($target); > - return ($target, $target); > + > +# removes duplicate anchor generation > + return ($target, ""); > +# return ($target, $target); > } The HTML for the second-layer TOC is missing after applying this patch, so the CSS is not broken, just the HTML. div#tocframe is still generated, but only for the top-level TOC. Also, it's only an accident that this would make the webpage navigation more comfortable, since the real solution is to remove the anchors from the hyperlink URLs when the texinfo is split by section (I'm working on it). With this patch, the hyperlink anchors point to a non-existent anchors; while harmless, it's still annoying. :-) Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond mentors
The Frogs have been around for a year, and I recently got two new doc
contributors, so I've been thinking about how things have been going
and some of the problems we've had. I'm thinking about proposing a
(semi-?)formal system of mentors.
One thing I learned from GDP was that things work better if individual
people have individual responsibilities -- for the first four months,
I said "let's all look at {pitches, rhythms, etc} and fix stuff"; not
much happened. After that, I switched to assigning one person to each
section, and that person took the editing effort a lot more seriously.
The mentors would be a similar thing: instead of having a general
Frogs list and asking experienced developers to help out in general,
we'll try to assign specific contributors (both programming and
non-programming) to specific developer-mentors. The mentor will help
the contributor -- demystifying git, letting them know which file(s)
to edit, maybe finding problems for them to work on, etc.
Anybody interested in mentoring? I'll take responsibility for
everybody not doing translations or programming. At the moment, this
means James and Colin... that said, if anybody wants to take them on,
I can certainly find more work to do.
At the moment, we're not trying to gather more contributors; this is
just to retain the current ones and get them more productive. GOP
(wherein we _will_ aggressively try to recruit more contributors) is
still slated for after 2.14 is out. It would be good to test the
mentor system for a few weeks or months before that, anyway.
Here's material to to add to the docs.
in the CG: (Introduction chapter?)
--
Mentors
We have a semi-formal system of mentorship, similar to the Debian
mentors, Freebsd sponsors, and the medieval "journeyman/master"
training system. New contributors will have a dedicated mentor to
help them "learn the ropes".
@warning{This is subject to the availability of mentors; certain
jobs have more potential mentors than others.}
Contributor responsibilities: (FIXME: would a different name be better?)
1. ask your mentor which sections of the CG you should read.
2. if you get stuck for longer than 10 minutes, ask your mentor.
They might not be able to help you with all problems, but we find
that new contributors often get stuck with something that could be
solved/explained with 2 or 3 sentences from a mentor.
3. send patches to your mentor for initial comments
4. inform your mentor if you're going to be away for a month, or
if you leave entirely. Contributing to lilypond isn't for
everybody; just let your mentor know so that we can reassign that
work to somebody else.
Mentor responsibilities:
1. respond to questions from your contributor(s) promptly, even if
the reponse is just "sorry, I don't know" or "sorry, I'm very busy
for the next 3 days; I'll get back to you then". Make sure they
feel valued. :)
2. inform your contributor(s) about the expected turnaround for
your emails -- do you work on lilypond every day, or every
weekend, or what? Also, if you'll be unavailable for longer than
usual (say, if you normally reply within 24 hours, but you'll be
at a conference for a week), let your contributors know. Again,
make sure thay feel valued, and that your silence (if they ask a
question during that period) isn't their fault.
3. inform your contributor(s) if they need to do anything unusual
for the builds, such as doing a "make clean / doc-clean" or
switching git branches (not expected, but just in case...)
4. you don't need to be able to completely approve patches. Make
sure the patch meets whatever you know of the guidelines (for doc
style, code indentation, whatever), and then send it on to the
frog list or -devel for more comments. If you feel confident
about the patch, you can push it directly (this is mainly intended
for docs and translations; code patches should almost always go to
-devel before being pushed).
5. keep track of patches from your contributor. If you've sent a
patch to -devel, it's your responsibility to pester people to get
comments for it, or at very least add it to the google tracker.
on the website (help wanted: projects)
--
- "contributor spots": places available for documentation,
translations (FIXME: check with John, or see if experienced
translators can serve as mentors for new ones), and anything other
than programming. I don't know if we have any mentors available
for programming at the moment.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
On 12/29/09 1:54 PM, "Marc Hohl" wrote: > Marc Hohl schrieb: >> Francisco Vila schrieb: >>> Just to add a bit to the brainstorming: >>> >>> The uppermost lace of our G-clef already was slightly oversized. >>> I cannot explain why, but latest proposals I've seen are getting it >>> even greater. >>> >>> Anyone appreciates the same? >>> >> Well spotted. I was not sure whether this is kind of an optical illusion, >> but I think there are some side effects, caused by (hidden) depencies >> of the variables which describe the outline of the clef. >> >> I'll investigate further. > I decided to start from scratch, because tuning a little bit here and there > seems not to be the best strategy. > > Being aware that there may be some nonlinearities, I would like to follow > these items: > > 1) finding an optimal angle for the "spine" > 2) adapting the lower bulb > 3) adjusting the upper "loop" In response to Jan's earlier question, I rotated the whole clef, not just the spine. IIUC, rotating the spine makes the upper loop larger and unbalances the split of the lower loop caused by the spine. Perhaps we ought to consider just rotating the whole clef. I find it very hard to compare the clefs on different pages. I realize that it's too late for this test, but in the future, if you make your output in SVG format, then we can copy clefs from one document to the other and get a good side-by-side comparision. > > (perhaps 2 and 3 should go together for overall balance, and finally, 1 > should be adapted to the results of 2 and 3, but ...) > > So I created a batch script which adds 0, 0.5, 1, ... 5 (in arbitrary units) > to the x coordinate of the "spine vector" (which will then be normalized > anyway, > so the only thing that's changing is the angle) in the metafont sources, > compiles the feta font from scratch and uses this new font to typeset an > example. This took quite a long time (approximately about 75% of the > time my daughter needed to watch "twilight" on the same machine while > metafont was bleeding...) > > I concatenated the pdfs to one file, which is too big for the list, so I > put it on my website: > > http://www.hohlart.de/marc/gclef-slant.pdf > > I know that there is a spurious error on value 2, but I think that's not the > main problem. Which value looks best? I think I prefer 1.5. Thanks for all this work! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
2009/12/29 Marc Hohl : > I concatenated the pdfs to one file, which is too big for the list, so I > put it on my website: > > http://www.hohlart.de/marc/gclef-slant.pdf > > I know that there is a spurious error on value 2, but I think that's not the > main problem. Which value looks best? At a risk of being the "upper loop man" I have to say that starting from parameter=0 upwards, the upper loop grows continuously. If this is what you mean when you say this still has to be normalized, then forget me. The width of the vertical seems to be thinner starting at 4. Several things change at once in the sequence, but my amateurish vote is for 2 even when it has the error, because it is between 1.5 and 2.5 which I like less. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com No le des el mando a distancia a Microsoft. No utilices Windows 7. http://windows7sins.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 12/29/09 3:06 PM, "Hans Aberg" wrote: > > > On 29 Dec 2009, at 22:00, Carl Sorensen wrote: > Does this seem like a feasible architecture? >>> >>> I think a system that determines the [meter] from the time signature >>> is fundamentally flawed. I think in terms of a \meter that can be >>> used >>> to define the beaming structure. I substructure of that is summed up, >>> and written as a time signature. If one has defined a set of such >>> time >>> signatures, then one can use that for a lookup. >> >> I believe that is what I am proposing. Instead of trying to calculate >> beatLength and measureGrouping from the time signature, we set them, >> along >> with intended beamGrouping. That way, the meter is determined by >> the user, >> rather than inferred by the code. > > I find the current LilyPond structure hard to cope with when wanting > subbeaming. Yes, right now there is no sound method for dealing with subbeaming (or beam subdivision, as I think it's called). I hope to fix that. > Also, some beaming wanted for that was discussed on the > LilyPond lists in the past breaks the simple idea of beaming > expressing a hierarchy of metric accents - though I do not want > anything that. My interpretation of it is like this, though I found it > hard to express formally: > > The smallest units is "in one", where one only has a time segment > which should be beamed as much as possible - on the time level > subdivision it expresses. Ross and Read talk about this smallest unit as a "beat", and it is not necessarily the denominator of the time signature. In fact, in what they refer to as "compound time" or "compound meter", the beat is three times the denominator of the time signature. > > Then one can repeat that either equally by an integer multiple or a > "+". For example, 6/8 calls for a "in one" 3+3 division of the time > unit which is the 1/8th note, which at the same time is the same as 2 > times the dotted 1/4th note. So doing some pseudocode, it might be > written >(3+3) x 1/8 > or >2 x 3/8 = 2 x 1/4. (dotted 1/4th) > > However, in the first one, the 3's should be "in one", and not be > beamed as "in three", expressing metric subaccents. So perhaps one > needs to distinguish between these two types of integers, say write > "in one" as 3'. Then the first one should be written >(3'+3') x 1/8 So if I understand correctly, you mean that all the notes in each of the 3' sections should be beamed together, thus avoiding metric subaccents? > > Then take a time signature like 4/4. It has i fact two common > interpretations: >(2'+2') x 1/4 >4 x 1/4 > > Now one might also use tuplets tied to the metric. For example, in > Macedonian 7/16, one may normally play as >(3'+(2'+2')) x 1/16 > But one may shift to using quadruplets on the 3s divided as 2'+2', > which one might want to express in the subbeaming. So one might want a > second rule like >(3:4 (2'+2') + (2'+2')) x 1/16 > So the \meter should have a sequence of such rules. I believe that these rules are exactly what the current autobeaming rules can express (although the rules that express this are not in the current default beam settings). > > When writing a time signature, some may want to just adding it all in > one number, and other want to write a "+", Bartok style. That might be > described by replacing some of the (..) with [..] on one of the rules. > For example >[3'+(2'+2')] x 1/16 > would be written as > 7 >16 > But there is a problem already here, as one might want to writ it as >3+2+2 > 16 > even though the beaming is (3'+(2'+2')). Writing >[3'+[2'+2']] x 1/16 > would strictly speaking lead to a time signature >3+(2+2) > 16 > though it is probably uncommon to have (..) in the time signature. > I believe we currently have the capability of writing compound time signatures (which governs the display of the time signature). With the new properties, we'll be able to set the measure grouping and the beaming characteristics, so I think the full flexibility will be there. > I think some may then want to write a different time signature than > what is strictly implied by the beaming. > > Together with the defined has defined a \meter structure, one needs to > also specify how it should be rendered. On the top level, it might > express a meter change between measures, using various dotted bars > ":", then comes space break, and after that some subbeaming. > > So that is roughly how I think about it. - LilyPond has some of it, > but I think cannot express that hierarchy properly in a suitable human > interface. The human interface in LilyPond is likely to continue to be sub-optimal at least for the near future. But I believe that in the near future the capability to display the appropriate time signatures, measure grouping, beaming, and subbeaming will be present. Thanks, Carl ___ lilypond-devel mailing list lil
Re: Autobeaming
On 12/29/09 2:14 PM, "Joe Neeman" wrote: > On Tue, 2009-12-29 at 11:27 -0700, Carl Sorensen wrote: >> >> >> On 12/29/09 8:41 AM, "Carl Sorensen" wrote: >> >>> >>> >>> >>> >>> On 12/29/09 4:48 AM, "Trevor Daniels" wrote: >>> Hi Carl This looks like a much better approach. It means the special \overrideTimeSignatureSettings will be required only rarely, and setting autoBeamRules for just the current time signature should have a much simpler format as the time signature is known - is that right? >>> >>> Sort of. >>> >>> I wouldn't recommend setting autoBeamRules for the current time signature, >>> because that setting will disappear if the time signature changes. >>> >>> I think that proper way to get new autoBeamRules is to override the >>> timeSignatureSettings. >>> >>> But if one wants to avoid that complication, one can just set autoBeamRules >>> for the current time signature. >>> >> >> I think I've got a consistent idea now. I think I can add a property >> (probably 'details to avoid namespace pollution, but maybe >> timeSignatureDefaults) to the TimeSignature grob. > > I much prefer leaving it as a context property. Grob properties of the > TimeSignature grob should be things that affect the appearance of the > TimeSignature grob, not the creation of beams. > > If you were to use a context property, why would you need the special > command \overrideTimeSignatureSettings to change it? That is, why > couldn't people just use \set? If it helps, we could extend \set to > allow nested properties (the same thing that > http://codereview.appspot.com/182042/show does for paper-block > variables). Because I want to be able to \revert, not just \unset. I want to be able to change to some custom behavior, then go back to the default behavior without having to know what the default behavior is in detail. IIUC, \override is roughly equivalent to \set value (cons new-value old-value). I want to have that functionality, so that old-value is still available for a \revert. But certainly nested properties would help in making this change. Why have we decided that context properties can only be \set, and grob properties can only be \overridden? In version 2.0 we had two kinds of properties, layout properties and translation properties. I think that translation properties in those days are what we now call context properties, and that what were then called layout properties are now called grob properties. Also, in version 2.0 we could either \set (destructively assign a value) or \override (push a value on the stack). In fact, according to the documentation, \override and \revert were the equivalent of push and pop. Now I think we have different behavior: context properties get \set and \unset; grob properties get \override and \revert. And IIUC, \override pushes a value on the stack, but \revert doesn't pull a value, instead it goes back to the default value. That is, if I do \override Context.Grob #'my-prop = #'13 \override Context.Grob #'my-prop = #'15 \revert Context.Grob #'my-prop the value of #'my-prop will not be 13; instead it will be the value it had before the first \override. I'm actually fine with this behavior; that way both \revert and \override are consistent, regardless of where they come in the file. \override sets a new value, and \revert puts me back to the default value. But for some reason unknown to me, when LilyPond 2.1.22 was released, (see http://thread.gmane.org/gmane.comp.gnu.lilypond.announce/143), the syntax changed. According to what I can read, the syntax changed for two reasons. First, it was an attempt to delineate between translator (context) properties, and layout (grob) properties. Second, it was to reduce some shift/reduce conflicts in the parser. I would actually prefer the terminology of translation and layout properties, where translation affects the conversion of music expressions to grobs, and layout affects the appearance of grobs. This seems to me to be more logically consistent, and helps me understand the difference between the two types of properties. But I wish that both types of properties had \override and \revert functionality. In 2.0 they did; in 2.1.22 the \set functionality was eliminated from layout properties and the \override functionality was eliminated from translator properties. When we don't have nested context properties, \override is probably not very important. But if we do, I think that \override functionality (regardless of what it's called) is quite important. If we could allow nested context properties, and get \set to do the equivalent of \override, and \unset do the equivalent of \revert, then I'd be all set to do TimeSignatureDefinitions as a context property. Thanks, Carl Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 29 Dec 2009, at 22:00, Carl Sorensen wrote: Does this seem like a feasible architecture? I think a system that determines the [meter] from the time signature is fundamentally flawed. I think in terms of a \meter that can be used to define the beaming structure. I substructure of that is summed up, and written as a time signature. If one has defined a set of such time signatures, then one can use that for a lookup. I believe that is what I am proposing. Instead of trying to calculate beatLength and measureGrouping from the time signature, we set them, along with intended beamGrouping. That way, the meter is determined by the user, rather than inferred by the code. I find the current LilyPond structure hard to cope with when wanting subbeaming. Also, some beaming wanted for that was discussed on the LilyPond lists in the past breaks the simple idea of beaming expressing a hierarchy of metric accents - though I do not want anything that. My interpretation of it is like this, though I found it hard to express formally: The smallest units is "in one", where one only has a time segment which should be beamed as much as possible - on the time level subdivision it expresses. Then one can repeat that either equally by an integer multiple or a "+". For example, 6/8 calls for a "in one" 3+3 division of the time unit which is the 1/8th note, which at the same time is the same as 2 times the dotted 1/4th note. So doing some pseudocode, it might be written (3+3) x 1/8 or 2 x 3/8 = 2 x 1/4. (dotted 1/4th) However, in the first one, the 3's should be "in one", and not be beamed as "in three", expressing metric subaccents. So perhaps one needs to distinguish between these two types of integers, say write "in one" as 3'. Then the first one should be written (3'+3') x 1/8 Then take a time signature like 4/4. It has i fact two common interpretations: (2'+2') x 1/4 4 x 1/4 Now one might also use tuplets tied to the metric. For example, in Macedonian 7/16, one may normally play as (3'+(2'+2')) x 1/16 But one may shift to using quadruplets on the 3s divided as 2'+2', which one might want to express in the subbeaming. So one might want a second rule like (3:4 (2'+2') + (2'+2')) x 1/16 So the \meter should have a sequence of such rules. When writing a time signature, some may want to just adding it all in one number, and other want to write a "+", Bartok style. That might be described by replacing some of the (..) with [..] on one of the rules. For example [3'+(2'+2')] x 1/16 would be written as 7 16 But there is a problem already here, as one might want to writ it as 3+2+2 16 even though the beaming is (3'+(2'+2')). Writing [3'+[2'+2']] x 1/16 would strictly speaking lead to a time signature 3+(2+2) 16 though it is probably uncommon to have (..) in the time signature. I think some may then want to write a different time signature than what is strictly implied by the beaming. Together with the defined has defined a \meter structure, one needs to also specify how it should be rendered. On the top level, it might express a meter change between measures, using various dotted bars ":", then comes space break, and after that some subbeaming. So that is roughly how I think about it. - LilyPond has some of it, but I think cannot express that hierarchy properly in a suitable human interface. Hans ___ 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
Le mardi 29 décembre 2009 à 22:05 +0100, Matthias Kilian a écrit : > `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. This will disappear in some future (when Texinfo has a good enough i18n support, maybe not before the next major version of Texinfo). > 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. I think we shouldn't hesitate in any case the GNUism is replaced by something as reliable and not significantly more complicated. > 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. Errm, who would be crazy enough to learn good shell programming from LilyPond makefiles? :-) More seriously, I agree with Graham about the security issues; if somebody has good reasons to be picky about building LilyPond (or any software) in a secure way, she should build in a visrtual machine or chroot jail. FWIW building Lily under a dedicated user account is enough for me. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On Tue, 2009-12-29 at 11:27 -0700, Carl Sorensen wrote: > > > On 12/29/09 8:41 AM, "Carl Sorensen" wrote: > > > > > > > > > > > On 12/29/09 4:48 AM, "Trevor Daniels" wrote: > > > >> Hi Carl > >> > >> This looks like a much better approach. It means the > >> special \overrideTimeSignatureSettings will be required > >> only rarely, and setting autoBeamRules for just the > >> current time signature should have a much simpler > >> format as the time signature is known - is that right? > > > > Sort of. > > > > I wouldn't recommend setting autoBeamRules for the current time signature, > > because that setting will disappear if the time signature changes. > > > > I think that proper way to get new autoBeamRules is to override the > > timeSignatureSettings. > > > > But if one wants to avoid that complication, one can just set autoBeamRules > > for the current time signature. > > > > I think I've got a consistent idea now. I think I can add a property > (probably 'details to avoid namespace pollution, but maybe > timeSignatureDefaults) to the TimeSignature grob. I much prefer leaving it as a context property. Grob properties of the TimeSignature grob should be things that affect the appearance of the TimeSignature grob, not the creation of beams. If you were to use a context property, why would you need the special command \overrideTimeSignatureSettings to change it? That is, why couldn't people just use \set? If it helps, we could extend \set to allow nested properties (the same thing that http://codereview.appspot.com/182042/show does for paper-block variables). Joe ___ 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: Autobeaming
On 12/29/09 12:31 PM, "Hans Aberg" wrote: > On 29 Dec 2009, at 03:11, Carl Sorensen wrote: > >> Does this seem like a feasible architecture? > > I think a system that determines the measure from the time signature > is fundamentally flawed. I think n terms of a \meter that can be used > to define the beaming structure. I substructure of that is summed up, > and written as a time signature. If one has defined a set of such time > signatures, then one can use that for a lookup. > I believe that is what I am proposing. Instead of trying to calculate beatLength and measureGrouping from the time signature, we set them, along with intended beamGrouping. That way, the meter is determined by the user, rather than inferred by the code. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Use find ... | xargs rm -f instead of find ... -delete
Le mardi 29 décembre 2009 à 20:19 +, Graham Percival a écrit : > On Tue, Dec 29, 2009 at 08:00:46PM +0100, Matthias Kilian wrote: > > The `-delete' primary isn't very portable, it's a GNU extension. > > IMHO, that's all we need to hear. -delete must be removed. Yes, that's what I figured out in order to decide to apply. find man page didn't help me in doing this by not mentioning explicitly which options are GNU extensions :-P [snip] > (I'm not totally certain, though, so I'm not applying it) What are you not applying? The patch that started this thread that I applied yesterday? Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
G clef changes [was: Re: Alternative music font]
Marc Hohl schrieb: Francisco Vila schrieb: Just to add a bit to the brainstorming: The uppermost lace of our G-clef already was slightly oversized. I cannot explain why, but latest proposals I've seen are getting it even greater. Anyone appreciates the same? Well spotted. I was not sure whether this is kind of an optical illusion, but I think there are some side effects, caused by (hidden) depencies of the variables which describe the outline of the clef. I'll investigate further. I decided to start from scratch, because tuning a little bit here and there seems not to be the best strategy. Being aware that there may be some nonlinearities, I would like to follow these items: 1) finding an optimal angle for the "spine" 2) adapting the lower bulb 3) adjusting the upper "loop" (perhaps 2 and 3 should go together for overall balance, and finally, 1 should be adapted to the results of 2 and 3, but ...) So I created a batch script which adds 0, 0.5, 1, ... 5 (in arbitrary units) to the x coordinate of the "spine vector" (which will then be normalized anyway, so the only thing that's changing is the angle) in the metafont sources, compiles the feta font from scratch and uses this new font to typeset an example. This took quite a long time (approximately about 75% of the time my daughter needed to watch "twilight" on the same machine while metafont was bleeding...) I concatenated the pdfs to one file, which is too big for the list, so I put it on my website: http://www.hohlart.de/marc/gclef-slant.pdf I know that there is a spurious error on value 2, but I think that's not the main problem. Which value looks best? Greetings Marc Merry christmas! Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Use find ... | xargs rm -f instead of find ... -delete
On Tue, Dec 29, 2009 at 08:00:46PM +0100, Matthias Kilian wrote:
> 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.
IMHO, that's all we need to hear. -delete must be removed.
> > 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).
> Then change it to something like this:
>
> find $(outdir)/offline-root -type l -print0 | xargs -0 rm -f --
>
> Or even this (completely POSIX compliant):
>
> find $(outdir)/offline-root -type -l -exec rm -f -- '{}' +
>
> (but then I've to patch it again, since find(1) on OpenBSD doesn't yet
> support the `-exec command {} +' primary).
Well, if that's part of POSIX, then adding it can't be a bad
thing. :) But for the purposes of the lilypond build scripts, I
don't think it's necessary. The first version of the patch should
be fine.
(I'm not totally certain, though, so I'm not applying it)
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 29 Dec 2009, at 03:11, Carl Sorensen wrote: Does this seem like a feasible architecture? I think a system that determines the measure from the time signature is fundamentally flawed. I think n terms of a \meter that can be used to define the beaming structure. I substructure of that is summed up, and written as a time signature. If one has defined a set of such time signatures, then one can use that for a lookup. Hans ___ 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: Autobeaming
On 12/29/09 8:41 AM, "Carl Sorensen" wrote: > > > > > On 12/29/09 4:48 AM, "Trevor Daniels" wrote: > >> Hi Carl >> >> This looks like a much better approach. It means the >> special \overrideTimeSignatureSettings will be required >> only rarely, and setting autoBeamRules for just the >> current time signature should have a much simpler >> format as the time signature is known - is that right? > > Sort of. > > I wouldn't recommend setting autoBeamRules for the current time signature, > because that setting will disappear if the time signature changes. > > I think that proper way to get new autoBeamRules is to override the > timeSignatureSettings. > > But if one wants to avoid that complication, one can just set autoBeamRules > for the current time signature. > I think I've got a consistent idea now. I think I can add a property (probably 'details to avoid namespace pollution, but maybe timeSignatureDefaults) to the TimeSignature grob. Then I can use standard /override and /revert to set the autobeaming rules. What do you think of that idea? Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 12/29/09 1:40 AM, "David Kastrup" wrote: > Carl Sorensen writes: > >> Then, if desired, the user can change the values of beatLength, >> measureGrouping, or autoBeamRules, they can do so directly by means of >> the \set command. >> >> If a user wants to change the timeSignatureSettings values for beatLength, >> measureGrouping, or autoBeamRules, they can do so with an >> \overrideTimeSignatureSettings or \revertTimeSignatureSettings command. >> Having done so, a simple change of time signature will implement the new >> time signature settings. >> >> Does this seem like a feasible architecture? > > I don't like compound contraptions like \overrideTimeSignatureSettings. > Can't this be made to work with \override timeSignatureSettings (or > similar) in some manner? I don't like them either. But I haven't been able to figure out another way to do it. \override requires a grob; timeSignatureSettings is a context property, not a grob description, so it won't work with \override. I went through some attempts earlier to try to make \override work, but wasn't successful. http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/21942/ http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/20632/ http://thread.gmane.org/gmane.comp.gnu.lilypond.general/41837/focus=20624 If you can figure out how to make it work with \override, I'd be delighted. But this gets back to your initial question (which probably never got answered to your satisfaction) as to the difference between context properties and grob descriptions. So, since I couldn't figure out a way to make it work, I did a workaround. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 12/29/09 4:48 AM, "Trevor Daniels" wrote: > Hi Carl > > This looks like a much better approach. It means the > special \overrideTimeSignatureSettings will be required > only rarely, and setting autoBeamRules for just the > current time signature should have a much simpler > format as the time signature is known - is that right? Sort of. I wouldn't recommend setting autoBeamRules for the current time signature, because that setting will disappear if the time signature changes. I think that proper way to get new autoBeamRules is to override the timeSignatureSettings. But if one wants to avoid that complication, one can just set autoBeamRules for the current time signature. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Corrected patch for Issue #830
Mark Polesky schrieb: Marc Hohl wrote: By the way, it would be easier for you developers when the patches go directly to rietveld. How can I archieve this? Does somebody need to create an account for me? See CG "Adding or modifying features"; scroll down to 8.7.9 "Post patch for comments". Ah, thanks a lot! Marc - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
Hi Carl This looks like a much better approach. It means the special \overrideTimeSignatureSettings will be required only rarely, and setting autoBeamRules for just the current time signature should have a much simpler format as the time signature is known - is that right? Trevor - Original Message - From: "Carl Sorensen" To: "lilypond-devel" Sent: Tuesday, December 29, 2009 2:11 AM Subject: Autobeaming I've been continuing to work on the logical structure of autobeaming rules, because the rules aren't right yet. There are still some rules that don't make sense, and in trying to make things make sense, I've run into some philosophical issues. I'm starting to believe that there should be a context property timeSignatureSettings that contains the settings that should go with a time signature. These settings should include beatLength, measureGrouping, and beaming rules (right now, just end rules, but eventually subdivide and potentially begin). This property stores default values for beatLength, measureGrouping, and autoBeamRules. Then, when the time signature is changed, the context properties of beatLength, measureGrouping, and autoBeamRules are set to the values from the timeSignatureSettings. Then, if desired, the user can change the values of beatLength, measureGrouping, or autoBeamRules, they can do so directly by means of the \set command. If a user wants to change the timeSignatureSettings values for beatLength, measureGrouping, or autoBeamRules, they can do so with an \overrideTimeSignatureSettings or \revertTimeSignatureSettings command. Having done so, a simple change of time signature will implement the new time signature settings. Does this seem like a feasible architecture? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
Carl Sorensen writes: > Then, if desired, the user can change the values of beatLength, > measureGrouping, or autoBeamRules, they can do so directly by means of > the \set command. > > If a user wants to change the timeSignatureSettings values for beatLength, > measureGrouping, or autoBeamRules, they can do so with an > \overrideTimeSignatureSettings or \revertTimeSignatureSettings command. > Having done so, a simple change of time signature will implement the new > time signature settings. > > Does this seem like a feasible architecture? I don't like compound contraptions like \overrideTimeSignatureSettings. Can't this be made to work with \override timeSignatureSettings (or similar) in some manner? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
