Re: dist failure for gub

2010-07-05 Thread Jan Nieuwenhuizen
Op maandag 05-07-2010 om 03:51 uur [tijdzone +0200], schreef Reinhold
Kainhofer:

  Apparently the newly added lilypond-book directory does something
  stupid, builds without using a target or something.
 
 Not that I can see.

Stupid is not the right word, silly is probably better :-)

Turns out that lilypond-book-vars.make had

 LILYBOOK_TEXI_FILES = $(call src-wildcard *.texi)
 EXTRA_DIST_FILES += .. $(LILYBOOK_TEXI_FILES)

and texinfo-vars.make has

 TEXI_FILES = $(call src-wildcard *.texi)
 ALL_SOURCES += $(TEXI_FILES)

which makes that texi files were duplicated in the dist_files
list.  Now that I write this, I realise how fragile this is
and wonder why we, instead of

  $(LN) $(DIST_FILES:%=$(src-dir)/%) $(distdir)/$(localdir)

have something like

  UNIQUE_DIST_FILES = $(sort $(DIST_FILES)
  $(LN) $(UNIQUE_DIST_FILES:%=$(src-dir)/%) $(distdir)/$(localdir)

to allow duplicates in DIST_FILES.  Oh well...

Jan.

-- 
Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org
Freelance IT http://JoyOfSource.com | Avatar®  http://AvatarAcademy.nl  



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Revised autobeam settings patch (issue1682049)

2010-07-05 Thread Trevor Daniels

Hi Carl

Download and applied to current git, but make fails:

make[1]: *** No rule to make target `include/beam-settings.hh', 
needed by `out/beaming-pattern.o'.  Stop.

make[1]: Leaving directory `/media/lilypond-git/lily'
make: *** [all] Error 2

Does this need to be applied over your previous patch or
onto current git?

Trevor


- Original Message - 
From: carl.d.soren...@gmail.com

To: carl.d.soren...@gmail.com
Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org
Sent: Monday, July 05, 2010 6:23 AM
Subject: Revised autobeam settings patch (issue1682049)



Reviewers: ,

Message:
I've posted a new patch for review that has the new autobeaming 
code.


We now have three properties to control autobeaming:  baseMoment 
(which

sets the smallest time interval used for defining beaming),
beatStructure (which defines the grouping of baseMoment intervals 
to
form beats), and beamExceptions (which defines cases where the 
beaming
rules are not governed by the beat structure, such as in 4/4 where 
beats
1 and 2 are combined if the notes are all 1/8 notes, but not if 
they're

triplets or 1/16 notes.

Default values of baseMoment and beatStructure are calculated from 
the
time signature.  However, users are free to define custom values 
of
baseMoment and beatStructure for time signatures, and the 
resulting
definitions will be stored in timeSignatureSettings for use 
whenever the

time signature is changed.

All of the regressions are successfully passed.

Please review and give me any comments.

THanks,

Carl


Moving to this new structure has greatly simplified

Description:
Revised autobeam settings patch
Eliminate context properties measureGrouping, beatLength, and
beamSettings

Create new context properties baseMoment, beatStructure, and
beamExceptions.

Save time-signature-specific settings in context property
timeSignatureSettings

Do away with virtually all special rules for beaming; the beat 
structure

now governs almost all autobeaming.

Fix documentation

Please review this at http://codereview.appspot.com/1682049/show

Affected files:
  M Documentation/de/notation/rhythms.itely
  M Documentation/es/notation/rhythms.itely
  M Documentation/fr/notation/rhythms.itely
  M Documentation/notation/rhythms.itely
  M Documentation/snippets/new/beam-endings-in-score-context.ly
  M Documentation/snippets/new/beam-grouping-in-7-8-time.ly
  M Documentation/snippets/new/compound-time-signatures.ly
  M 
Documentation/snippets/new/conducting-signs,-measure-grouping-signs.ly

  M Documentation/snippets/new/fretted-headword.ly
  M Documentation/snippets/new/reverting-default-beam-endings.ly
  M input/regression/auto-beam-beaming-override.ly
  M input/regression/beaming-ternary-metrum.ly
  M input/regression/les-nereides.ly
  M lily/auto-beam-engraver.cc
  M lily/beam-engraver.cc
  M lily/beam-setting-scheme.cc
  M lily/beaming-pattern.cc
  M lily/include/beam-settings.hh
  M lily/include/beaming-pattern.hh
  M lily/measure-grouping-engraver.cc
  M lily/timing-translator.cc
  M ly/bagpipe.ly
  M ly/engraver-init.ly
  M ly/music-functions-init.ly
  M python/convertrules.py
  M scm/auto-beam.scm
  M scm/beam-settings.scm
  M scm/define-context-properties.scm
  M scm/define-music-display-methods.scm
  M scm/lily-library.scm
  M scm/lily.scm
  M scm/music-functions.scm
  A scm/time-signature-settings.scm
  M scripts/musicxml2ly.py



___
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


I screw up git release/unstable

2010-07-05 Thread Graham Percival
We had three people working on build stuff this morning, and in the
mix I decided to use different version numbers when adding \version
2.12.0 to files.  release/unstable is a mess.

Could somebody make release/unstable be exactly the same as master?  I
don't care if you delete it and make a new one, or do some fancy git
thing to move the ref around, or what... I just want to get rid of all
current differences between master and release/unstable, without doing
anything to master.  The only good change that we'd lose would be
the news item, but that was just an exact copy of the previous 10
release announcements, so no worries.

I'm too frazzled about getting my project finished before RMLL to play
more games with git.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: I screw up git release/unstable

2010-07-05 Thread David Kastrup
Graham Percival gra...@percival-music.ca writes:

 We had three people working on build stuff this morning, and in the
 mix I decided to use different version numbers when adding \version
 2.12.0 to files.  release/unstable is a mess.

 Could somebody make release/unstable be exactly the same as master?  I
 don't care if you delete it and make a new one, or do some fancy git
 thing to move the ref around, or what... I just want to get rid of all
 current differences between master and release/unstable, without doing
 anything to master.  The only good change that we'd lose would be
 the news item, but that was just an exact copy of the previous 10
 release announcements, so no worries.

 I'm too frazzled about getting my project finished before RMLL to play
 more games with git.

There are basically two ways to do that.  One is more or less a relabel
and would consequentially lose history.  The other is a trivial merge
with master with a merge strategy that lets master win always.  The
latter should make it easier for people to pull, I think.

Want me to try?

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: I screw up git release/unstable

2010-07-05 Thread Graham Percival
On Mon, Jul 5, 2010 at 12:37 PM, David Kastrup d...@gnu.org wrote:
 Graham Percival gra...@percival-music.ca writes:

 Could somebody make release/unstable be exactly the same as master?  I
 don't care if you delete it and make a new one, or do some fancy git
 thing to move the ref around, or what... I just want to get rid of all
 current differences between master and release/unstable, without doing
 anything to master.  The only good change that we'd lose would be
 the news item, but that was just an exact copy of the previous 10
 release announcements, so no worries.


... wow, apparently I even screwed up the subject line!

 There are basically two ways to do that.  One is more or less a relabel
 and would consequentially lose history.

If it loses history from release/unstable, I consider that a desirable
side effect.

  The other is a trivial merge
 with master with a merge strategy that lets master win always.  The
 latter should make it easier for people to pull, I think.

AFAIK I'm the only one who uses release/unstable, so that's not a huge concern.

Do whichever is easiest/safest for you, please.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Add \path markup command, and use it for \eyeglasses. (issue1730044)

2010-07-05 Thread Carl . D . Sorensen

On 2010/07/05 05:48:16, MikeSol wrote:


I see 3.5 places where the patch may need improvement.  1 is that

lineto and

curveto seem unnecessary, as they can be automatically detected by the

number of

function arguments.


For purposes of human readability, I think we should keep lineto and
curveto, even if they are automatically detectable.  But I also think
that even if curveto is detectable, lineto isn't because moveto has the
same number of arguments as lineto.


Two is that I try to use predefined lilypond commands as
much as possible when they exist - could the moveto's be calls to
ly:stencil-translate?


I suspect that moveto's could be rewritten as calls to
ly:stencil-translate, but then you'd need to change all the arguments.
And I don't see the benefit of it.  Both ps and svg have the moveto
functionality available; we might as well use their functionality as the
common calls, in my opinion.



Third is that I am wary of any loop and/or for-each
construct in scheme: I think there is a way to do this with

tail-regression that

dispenses with the loop and is more Schemy.


I, too am wary of loop and for-each constructs in Scheme in general, but
I think that in this case it works quite well.


Three.5, I think the extents are
off for the curves in certain problematic cases,


Certainly the extents are off for the curves; the control points bound
the curve but don't define the curve.  So the extents may be a little
bit larger than exact.


but that'll work hopefully work
itself out via this proposition, to wit:



I think the best way to move forward on this patch would be to work on

merging

its functionality and nomenclature into the connected-shape stencil.


If path and connected-shape are to be merged, I'd like to see the
resulting stencil named path and take the input that's defined in
Patrick's patch.  I think that path is a very user-friendly way to
create complex stencils, and connected-shape somewhat less so.


I'd be
more than happy to iron that out with you on the sidelines - just

shoot me an

email and we'll get that up and running.


I'm sure that you're good for this offer.  Thanks for doing so.

Carl


http://codereview.appspot.com/1730044/show

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: I screw up git release/unstable

2010-07-05 Thread Reinhold Kainhofer
Am Montag, 5. Juli 2010, 14:10:23 schrieb Graham Percival:
 On Mon, Jul 5, 2010 at 12:37 PM, David Kastrup d...@gnu.org wrote:
  There are basically two ways to do that.  One is more or less a relabel
  and would consequentially lose history.
 
 If it loses history from release/unstable, I consider that a desirable
 side effect.
 
 AFAIK I'm the only one who uses release/unstable, so that's not a huge
 concern.
 
 Do whichever is easiest/safest for you, please.

I think it's easiest to simply do (on your release/unstable copy, assuming 
your local branch is also called release/unstable):

git reset --hard origin/master
git push -f origin release/unstable

This will move the release/unstable branch tag to current origin/master (git 
push would not normally allow a push that looses commits, so you have to force 
it...). I have used that every now and then to reset dev/kainhofer to master.

Cheers,
Reinhold


-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Strange error in make doc

2010-07-05 Thread Carl Sorensen
I'm trying to build the documentation to make sure it works with my new
autobeam code.

When I do make doc-clean  make doc, I get the following error:

cd ./out-www; texi2pdf -I /Users/Carl/lilypond/Documentation -I
/Users/Carl/lilypond/input/regression/abc2ly --batch  collated-files.texi
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009)
entering extended mode

(./collated-files.texi (/Users/Carl/lilypond/tex/texinfo.tex
Loading texinfo [version 2009-08-14.15]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc,
environments,
defuns, macros, cross references, insertions,
(/usr/local/texlive/2009/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 23 July 2005
) localization, formatting, and turning on texinfo input format.)
Unknown document encoding utf-8, ignoring. (abc2ly test suite)
(./68/lily-81a6c935-systems.texi
./68/lily-81a6c935-1.pdf{/usr/local/texlive/2
009/texmf-var/fonts/map/pdftex/updmap/pdftex.map}
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
 ./68/lily-81a6c935-2.pdf ./68/lily-81a6c935-3.pdf
./68/lily-81a6c935-4.pd
f ./68/lily-81a6c935-5.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 5--5
[] 
) (./4b/lily-5084ed68-systems.texi ./4b/lily-5084ed68-1.pdf
Overfull \hbox (207.23093pt too wide) in paragraph at lines 1--1
[] 
 ./4b/lily-5084ed68-2.pdf) (./39/lily-613bbfda-systems.texi
./39/lily-613bbf
da-1.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
 ./39/lily-613bbfda-2.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 2--2
[] 
) (./90/lily-015675ea-systems.texi ./90/lily-015675ea-1.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
 ./90/lily-015675ea-2.pdf) (./ce/lily-7a303e32-systems.texi
./ce/lily-7a303e
32-1.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
[1] ./ce/lily-7a303e32-2.pdf) [2] )
(see the transcript file for additional
information)/usr/local/texlive/2009/te
xmf-dist/fonts/type1/public/amsfonts/cm/cmbx12.pfb/usr/local/texlive/2009/
tex
mf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb/usr/local/texlive/2009/te
xmf
-dist/fonts/type1/public/amsfonts/cm/cmtt10.pfb/usr/local/texlive/2009/tex
mf-
dist/fonts/type1/urw/ncntrsbk/uncb8a.pfb/usr/local/texlive/2009/texmf-dist
/fo
nts/type1/urw/ncntrsbk/uncr8a.pfb/usr/local/texlive/2009/texmf-dist/fonts/
typ
e1/urw/ncntrsbk/uncri8a.pfb
Output written on collated-files.pdf (2 pages, 165886 bytes).
Transcript written on collated-files.log.
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009)
entering extended mode

(./collated-files.texi (/Users/Carl/lilypond/tex/texinfo.tex
Loading texinfo [version 2009-08-14.15]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc,
environments,
defuns, macros, cross references, insertions,
(/usr/local/texlive/2009/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 23 July 2005
) localization, formatting, and turning on texinfo input format.)
(./collated-files.aux) Unknown document encoding utf-8, ignoring.
(abc2ly test suite) (./68/lily-81a6c935-systems.texi
./68/lily-81a6c935-1.pdf{
/usr/local/texlive/2009/texmf-var/fonts/map/pdftex/updmap/pdftex.map}
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
 ./68/lily-81a6c935-2.pdf ./68/lily-81a6c935-3.pdf
./68/lily-81a6c935-4.pd
f ./68/lily-81a6c935-5.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 5--5
[] 
) (./4b/lily-5084ed68-systems.texi ./4b/lily-5084ed68-1.pdf
Overfull \hbox (207.23093pt too wide) in paragraph at lines 1--1
[] 
 ./4b/lily-5084ed68-2.pdf) (./39/lily-613bbfda-systems.texi
./39/lily-613bbf
da-1.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
 ./39/lily-613bbfda-2.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 2--2
[] 
) (./90/lily-015675ea-systems.texi ./90/lily-015675ea-1.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
 ./90/lily-015675ea-2.pdf) (./ce/lily-7a303e32-systems.texi
./ce/lily-7a303e
32-1.pdf
Overfull \hbox (1.46217pt too wide) in paragraph at lines 1--1
[] 
[1] ./ce/lily-7a303e32-2.pdf) [2] )
(see the transcript file for additional
information)/usr/local/texlive/2009/te
xmf-dist/fonts/type1/public/amsfonts/cm/cmbx12.pfb/usr/local/texlive/2009/
tex
mf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb/usr/local/texlive/2009/te
xmf
-dist/fonts/type1/public/amsfonts/cm/cmtt10.pfb/usr/local/texlive/2009/tex
mf-
dist/fonts/type1/urw/ncntrsbk/uncb8a.pfb/usr/local/texlive/2009/texmf-dist
/fo
nts/type1/urw/ncntrsbk/uncr8a.pfb/usr/local/texlive/2009/texmf-dist/fonts/
typ
e1/urw/ncntrsbk/uncri8a.pfb
Output written on collated-files.pdf (2 pages, 165886 bytes).
Transcript written on collated-files.log.
true
rm out-www/weblinks.itexi out-www/collated-files.pdf.omf
mkdir -p ./out-www
touch ./out-www/dummy.dep
echo '*'  ./out-www/.gitignore
make[4]: *** No rule to make target `', needed by
`out-www/collated-files.tely'.  Stop.

Re: I screw up git release/unstable

2010-07-05 Thread David Kastrup
Graham Percival gra...@percival-music.ca writes:

 There are basically two ways to do that.  One is more or less a relabel
 and would consequentially lose history.

 If it loses history from release/unstable, I consider that a desirable
 side effect.

  The other is a trivial merge
 with master with a merge strategy that lets master win always.  The
 latter should make it easier for people to pull, I think.

 AFAIK I'm the only one who uses release/unstable, so that's not a huge 
 concern.

 Do whichever is easiest/safest for you, please.

I am afraid that I _kept_ the history (though trying to get rid of it).
Which likely means that merging with anything having commits that you
had in release/unstable will not include those commits again.

Sorry, I am not sure that this is the best.  One rather reliable way to
lose history should be to delete and recreate the branch, something like

git push origin :release/unstable
git push origin master:release/unstable

If it is just you using the branch, it should likely work, but not
really be helpful in the way of archiving the release/unstable history.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Graham Percival
On Mon, Jul 5, 2010 at 1:26 PM, Carl Sorensen c_soren...@byu.edu wrote:
 make[4]: *** No rule to make target `', needed by
 `out-www/collated-files.tely'.  Stop.
 make[3]: *** [WWW-1] Error 2
 rm out-www/collated-files.pdf.omf out-www/weblinks.itexi
 make[2]: *** [WWW-1] Error 2
 make[1]: *** [WWW-1] Error 2
 make: *** [doc-stage-1] Error 2


 As near as I can tell, no file has failed, but somehow we have a blank
 target.

It's to do with the lilypond-book regression test build stuff,
although I didn't realize it affected the normal doc build.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Carl Sorensen



On 7/5/10 7:22 AM, Graham Percival gra...@percival-music.ca wrote:

 On Mon, Jul 5, 2010 at 1:26 PM, Carl Sorensen c_soren...@byu.edu wrote:
 make[4]: *** No rule to make target `', needed by
 `out-www/collated-files.tely'.  Stop.
 make[3]: *** [WWW-1] Error 2
 rm out-www/collated-files.pdf.omf out-www/weblinks.itexi
 make[2]: *** [WWW-1] Error 2
 make[1]: *** [WWW-1] Error 2
 make: *** [doc-stage-1] Error 2
 
 
 As near as I can tell, no file has failed, but somehow we have a blank
 target.
 
 It's to do with the lilypond-book regression test build stuff,
 although I didn't realize it affected the normal doc build.

Any way to work around it?

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Graham Percival
On Mon, Jul 05, 2010 at 07:47:05AM -0600, Carl Sorensen wrote:
 
 On 7/5/10 7:22 AM, Graham Percival gra...@percival-music.ca wrote:
 
  It's to do with the lilypond-book regression test build stuff,
  although I didn't realize it affected the normal doc build.
 
 Any way to work around it?

Sorry, I don't know what's happening.  From git history, I know
that Jan made a change to Reinhold's build system additions for
lilypond-book regtest.   Later on, Reinhold made another change.
In the middle of all this, I flailed around randomly on
release/unstable and pushed random junk.

I'm occupied with trying to start my online survey before RMLL,
because otherwise I'll lose a month of data gathering.  I'm
buildling git from scratch right now, and if that works (which I
doubt) I'll let you know and try making 2.6.27.  But if either of
them fails, I'm not likely to have time to look at it until after
RMLL -- and even then, I'll only have one day before I go to
Vancouver.

Sorry,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Reinhold Kainhofer
Am Montag, 5. Juli 2010, 15:22:15 schrieb Graham Percival:
 On Mon, Jul 5, 2010 at 1:26 PM, Carl Sorensen c_soren...@byu.edu wrote:
  make[4]: *** No rule to make target `', needed by
  `out-www/collated-files.tely'.  Stop.
  make[3]: *** [WWW-1] Error 2
  rm out-www/collated-files.pdf.omf out-www/weblinks.itexi
  make[2]: *** [WWW-1] Error 2
  make[1]: *** [WWW-1] Error 2
  make: *** [doc-stage-1] Error 2
  
  
  As near as I can tell, no file has failed, but somehow we have a blank
  target.
 
 It's to do with the lilypond-book regression test build stuff,
 although I didn't realize it affected the normal doc build.

The problem was that Jan renamed the variable that collects the output files, 
but didn't change the GNUmakefile of the regtests, so the list of target files 
was empty... (Plus, the GNUmakefile used a wrong fallback of  instead of an 
empty variable!) My later commit fixed that.

Cheers,
Reinhold


-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Graham Percival
On Mon, Jul 5, 2010 at 3:40 PM, Reinhold Kainhofer
reinh...@kainhofer.com wrote:
 It's to do with the lilypond-book regression test build stuff,
 although I didn't realize it affected the normal doc build.

 The problem was that Jan renamed the variable that collects the output files,
 but didn't change the GNUmakefile of the regtests, so the list of target files
 was empty... (Plus, the GNUmakefile used a wrong fallback of  instead of an
 empty variable!) My later commit fixed that.

I can confirm that building from scratch, with a new ./autogen.sh and
configure, works.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Remove double periods in glossary

2010-07-05 Thread Michael
Removed four instances of double periods.
-- 
Michael
From d113bf5029d581b105fa8d764a51fe14db61368b Mon Sep 17 00:00:00 2001
From: Mikemoral thenewmikemo...@aol.com
Date: Mon, 5 Jul 2010 12:55:53 -0700
Subject: [PATCH 2/2] Remove double periods in glossary

Removed 4 instances of double periods.
---
 Documentation/music-glossary.tely |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/music-glossary.tely b/Documentation/music-glossary.tely
index 4d6f4a2..021ed9c 100644
--- a/Documentation/music-glossary.tely
+++ b/Documentation/music-glossary.tely
@@ -2337,7 +2337,7 @@ S: crescendo,
 FI: cresendo, voimistuen.
 
 Increasing volume.  Indicated by a rightwards opening horizontal wedge
-(hairpin) or the abbreviation @notation{cresc.}.
+(hairpin) or the abbreviation @notation{cresc.}
 
 @lilypond[quote,relative=2]
 \key g \major
@@ -2449,7 +2449,7 @@ DK: da capo,
 S: da capo,
 FI: da capo, alusta.
 
-Abbreviated @notation{D.C.}.  Indicates that the piece is to be repeated from
+Abbreviated @notation{D.C.}  Indicates that the piece is to be repeated from
 the beginning to the end or to a certain place marked @emph{fine}.
 
 @seealso
@@ -2487,7 +2487,7 @@ DK: dal segno,
 S: dal segno,
 FI: dal segno, lähtien merkistä.
 
-Abbreviated @notation{D.S.}.  Repetition, not from the beginning, but from
+Abbreviated @notation{D.S.}  Repetition, not from the beginning, but from
 another place frequently near the beginning marked by a sign
 (@notation{segno}):
 
@@ -2520,7 +2520,7 @@ S: decrescendo,
 FI: decresendo, hiljentyen.
 
 Decreasing tone volume.  Indicated by a leftwards opening horizontal
-wedge (hairpin) or the abbreviation @notation{decresc.}.
+wedge (hairpin) or the abbreviation @notation{decresc.}
 
 @lilypond[quote,relative=2]
 \key g \major
-- 
1.7.0.4

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: dist fixes for input/regression/lilypond-book/

2010-07-05 Thread Reinhold Kainhofer
Am Montag, 5. Juli 2010, um 20:51:26 schrieb Graham Percival:
 All the source files in this dir should appear in the dist tarball.  I
 tried a quick fix since it only complained about one file, but then it
 complained about 8 more, so I'm guessing that none of these files are
 included.
[...]
 I'm sure that the solution is a one-line or two-line fix to some build
 file somewhere or other, but I don't know more than that.

Your quick fix
EXTRA_DIST_FILES = suffix-texinfo.texinfo

was almost correct... Unfortunately, you use a =, thus overwriting the 
existing contents of the list rather than appending. The correct solution is 
to use +=:
EXTRA_DIST_FILES += suffix-texinfo.texinfo


Now, the tarball contains all files. Pushed.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Trevor Daniels


Carl, you wrote Monday, July 05, 2010 1:26 PM


I'm trying to build the documentation to make sure it works with 
my new

autobeam code.

When I do make doc-clean  make doc, I get the following error:


[snip error messages]

I get the same error.  However, I did build the docs
successfully on Sunday, using the state of git at the
time, so you could try resetting to a commit around
then and applying your patch there.  I've just started
that running now.


Carl


Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Carl Sorensen
On 7/5/10 5:39 PM, Trevor Daniels t.dani...@treda.co.uk wrote:

 
 
 Carl, you wrote Monday, July 05, 2010 1:26 PM
 
 
 I'm trying to build the documentation to make sure it works with
 my new
 autobeam code.
 
 When I do make doc-clean  make doc, I get the following error:
 
 [snip error messages]
 
 I get the same error.  However, I did build the docs
 successfully on Sunday, using the state of git at the
 time, so you could try resetting to a commit around
 then and applying your patch there.  I've just started
 that running now.

You need to get the latest git, and redo autogen.sh.

Also, there are some doc bugs (a few snippets that need to be updated).

Please don't waste time on a doc build until I indicate that it's clean.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Strange error in make doc

2010-07-05 Thread Reinhold Kainhofer
Am Dienstag, 6. Juli 2010, um 01:39:50 schrieb Trevor Daniels:
 Carl, you wrote Monday, July 05, 2010 1:26 PM
 
  I'm trying to build the documentation to make sure it works with
  my new
  autobeam code.
 
  When I do make doc-clean  make doc, I get the following error:
 [snip error messages]
 
 I get the same error.  However, I did build the docs
 successfully on Sunday, 

Strangely, I also got that error a second ago on my home machine. However, the 
daily docs build on the server worked just fine...

BTW, the error message indicates some text encoding problems in lilypond-book   
I couldn't locate the offending file to track down the problem in lilypond-
book, though...
Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: I screw up git release/unstable

2010-07-05 Thread Reinhold Kainhofer
Am Montag, 5. Juli 2010, um 14:10:23 schrieb Graham Percival:
 On Mon, Jul 5, 2010 at 12:37 PM, David Kastrup d...@gnu.org wrote:
  Graham Percival gra...@percival-music.ca writes:
  Could somebody make release/unstable be exactly the same as master?  I
  don't care if you delete it and make a new one, or do some fancy git
  thing to move the ref around, or what... I just want to get rid of all
  current differences between master and release/unstable, without doing
  anything to master.  The only good change that we'd lose would be
  the news item, but that was just an exact copy of the previous 10
  release announcements, so no worries.

Is this request still relevant (I see you have done some more commits)?

Do you want all the commits to Documentation/web/news-front.itexi preserved?

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: dist fixes for input/regression/lilypond-book/

2010-07-05 Thread Reinhold Kainhofer
Am Dienstag, 6. Juli 2010, um 01:33:16 schrieb Reinhold Kainhofer:
 Am Montag, 5. Juli 2010, um 20:51:26 schrieb Graham Percival:
  All the source files in this dir should appear in the dist tarball.  I
  tried a quick fix since it only complained about one file, but then it
  complained about 8 more, so I'm guessing that none of these files are
  included.
 
 [...]
 
  I'm sure that the solution is a one-line or two-line fix to some build
  file somewhere or other, but I don't know more than that.
[...] 
 Now, the tarball contains all files. Pushed.

Well, now I committed the proper fix: Handle the .texinfo extension in the 
regtest, too.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Edits to glossary

2010-07-05 Thread Michael
Added German name from alla breve and create consistency for cut
time.

-- 
Michael
From db8f11d1f8cfaaaccdf6c921a014378071fac29f Mon Sep 17 00:00:00 2001
From: Mikemoral thenewmikemo...@aol.com
Date: Mon, 5 Jul 2010 19:04:17 -0700
Subject: [PATCH 2/2] Edits to glossary

Added German name from alla breve and create consistancy for cut time.
---
 Documentation/music-glossary.tely |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/music-glossary.tely b/Documentation/music-glossary.tely
index 021ed9c..42373c4 100644
--- a/Documentation/music-glossary.tely
+++ b/Documentation/music-glossary.tely
@@ -680,7 +680,7 @@ Since one does not crescendo @emph{to} nothing, it is not correct to use
 ES: alla breve,
 I: ?,
 F: alla breve, à la brève,
-D: ?,
+D: Allabreve, alla breve
 NL: ?,
 DK: ?,
 S: ?,
@@ -688,7 +688,7 @@ FI: ?.
 
 [Italian: @q{on the breve}]  Twice as fast as the notation indicates.
 
-Also called @notation{in cut-time}.  The name derives from mensural
+Also called @notation{in cut time}.  The name derives from mensural
 notation, where the @notation{tactus} (or beat) is counted on the semibreve
 (the modern whole note).  Counting @q{on the breve} shifts the tactus to the
 next longest note value, which (in modern usage) effectively halves all note
@@ -5137,7 +5137,7 @@ Two mensuration signs have survived to the present day: the C-shaped sign,
 which originally designated @notation{tempus imperfectum} and
 @notation{prolatio minor} now stands for @notation{common time}; and the
 slashed C, which designated the same with @notation{diminution} now stands
-for @notation{cut-time} (essentially, it has not lost its original meaning).
+for @notation{cut time} (essentially, it has not lost its original meaning).
 
 @seealso
 @ref{diminution}, @ref{proportion}, @ref{time signature}.
@@ -5749,7 +5749,7 @@ As used in mensural notation, this fraction was more flexible: it could also
 be one-third the higher note value.  Composers indicated which proportions
 to use with various signs—two of which survive to the present day: the
 C-shaped sign for @notation{common time}, and the slashed C for
-...@notation{alla breve} or @notation{cut-time}.
+...@notation{alla breve} or @notation{cut time}.
 
 @c TODO -- add maxima to this example, in a way that doesn't break it.
 
-- 
1.7.0.4

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Revised autobeam settings patch (issue1682049)

2010-07-05 Thread Carl . D . Sorensen

OK, I've loaded patch set 2.  This patch set makes a clean doc build.

To make this patch work, you'll need to do the following:

1) Apply the patch

2) Clean out the old binaries:

make bin-clean   or  rm lily/out/*

3) Update the snippets in Documentation/snippets from
Documentation/snippets/new:

scripts/auxiliar/makelsr.py

4) Build lilypond

make

5) Build docs

make doc-clean  make doc

This last process can be sped up with

make doc-clean  make -j3 CPU_COUNT=3 doc

if you have a dual-core processor.

This patch is ready for testing, but has a few small things remaining
before pushing:

A) Eliminate the commented debug lines in scm/auto-beam.scm

B) Update convert-rules.py (it currently has the changes for the last
propose syntax, and is aimed at release 2.13.24, which obviously didn't
happen)

C) Add a note to changes.tely describing the new syntax.

Thanks,

Carl


http://codereview.appspot.com/1682049/show

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel