bordage.bertrand | 1 Aug 2011 01:09
Picon
Gravatar

Re: New alist to replace special characters. (issue4553056)

Ouch...

The problem with '&' is that it fails on lyrics:
this works:
\new Lyrics \lyricmode { a&s; }

but this doesn't:
\new Lyrics \lyricmode { &s; }

There is the same kind of issues with almost every easy-to-type special
character:
 <at>  % $ # \ / < > ^ ~ + = * ; ( ) [ ] { }

This is the exact list of every possible escape characters for a french
keyboard under linux:
§ £ µ € ¤ ¹ ² ' ` © ¨ ø Ø ≤ ≥ « » “ ” ↓ ¬ × ÷ ¿ ¡ ∕ ⋅ …

Of course, only a few of them are available under windows:
§ £ µ € ¤ ' `

If we consider US, british, german and spanish keyboards, this only
gives these two very bad characters:
' `

The best solution may be to solve this lyric problem first :\

Bertrand

http://codereview.appspot.com/4553056/

_______________________________________________
(Continue reading)

Han-Wen Nienhuys | 1 Aug 2011 04:28
Picon

Re: Anything speaking against this simplification?

On Sat, Jul 30, 2011 at 5:19 PM, David Kastrup <dak <at> gnu.org> wrote:
> music_list in parser.yy temporarily maintains an awkward
> half-self-referential data structure in order to have "fast append".  It
> makes more sense in my opinion to use prepend and reverse afterwards.
> "Fast append" in theory may show minimally better cache coherency at the
> cost of uglier code and uglier data structures.  So I'd just like to do
> the following (no full regtest yet).
>
> Comments?

I'm fine either way.

Originally all lists in the parser were C++ ones (doubly linked IIRC)
with a consistent direction. Having the Scheme lists not reverse
direction may have seemed easier at the time.

The performance overhead (even if you used non-destructive reverse) is
probably neglible; I wouldn't bother measuring it.

--

-- 
Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen

_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lemniskata.bernoullego | 1 Aug 2011 07:17
Picon

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

New patch set uploaded (adding a regtest).

2011/8/1 Wols Lists <antlists <at> youngman.org.uk>:
> Regression test attached. I've looked at the other regression tests
and
> tried to make it similar.

Great!

http://codereview.appspot.com/4800051/diff/14003/input/regression/chord-capo.ly
File input/regression/chord-capo.ly (right):

http://codereview.appspot.com/4800051/diff/14003/input/regression/chord-capo.ly#newcode4
input/regression/chord-capo.ly:4: texidoc="Properties capoPitch,
capoVertical: display chordnames, suitably
trailing whitespace here

http://codereview.appspot.com/4800051/
Keith OHara | 1 Aug 2011 07:21

Re: fixcc.py run on Aug 01

Graham Percival <graham <at> percival-music.ca> writes:

> 
> I will be running fixcc.py on the git repo 

Tabs-to-spaces and trailing-spaces-strip are now done by the Python script, so 
you don't need to do these steps by hand.

> Apologies for the inconvenience; this should be a one-time painful
> transition.

I did a dry run on my outstanding patches and found it inconvenient, 
but not really painful.  

I thought the option "git rebase --ignore-whitespace" might make everything
automatic, but I still needed to hand-merge.  (In fact, git did just well 
without the option, on my patches.)

There were two nits that I had found with fixcc after discussion died down.  
One of them makes a couple files change on the /second/ run of fixcc.  
People might end up running the script twice, and then would need to merge 
these files.  Therefore I pushed my (well-tested) nitpick fix. 
pkx166h | 1 Aug 2011 09:29
Picon

Re: Doc: Usage - new option for lilypond-book (issue4806050)

Reviewers: Graham Percival,

Message:
Pushed as

Commit 23cdda9506931d5b9a1e75ee8be8be8b74f9084a7c0

James

Description:
Doc: Usage - new option for lilypond-book

Documenting new feature made in

Commit 23cdda9506931d5b9a1e75ee8be8be8b74f9084a7c0

Also for Tracker issue 1730 adding information for 'gui' option for
windows users running lilypond-windows.exe -dgui.

Please review this at http://codereview.appspot.com/4806050/

Affected files:
   M Documentation/usage/lilypond-book.itely
   M Documentation/usage/running.itely

Index: Documentation/usage/lilypond-book.itely
diff --git a/Documentation/usage/lilypond-book.itely  
b/Documentation/usage/lilypond-book.itely
index  
9d018275ef1fa2b61426c0fbabff3f57c60d70c3..d1018be507685bbcd4dad5dc0c3988cf90bbe8c9  
(Continue reading)

pkx166h | 1 Aug 2011 09:34
Picon

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

Passes Make and reg tests

http://codereview.appspot.com/4800051/
Reinhold Kainhofer | 1 Aug 2011 13:12
Favicon
Gravatar

Re: auto numbering footnote checkin doesn't play with \null and \musicglyph

Am Freitag, 29. Juli 2011, 13:30:30 schrieb mike <at> apollinemike.com:
> AUTOMATIC-FOOTNOTES
> 
> In automatic footnotes, there are three pertinent commands
> \autoFootnote
> \autoFootnoteGrob
> \footnote

For the documentation: The first two are music functions, the third one is a 
markup function.

> footnote-auto-numbering (default = ##t)
[..]
> -- a function that takes ONE AND ONLY ONE INPUT, which should be an
> INTEGER, and returns the appropriate markup to be used in numbering the
> current prefabbed functions in output-lib.scm that work with this are
> `numbered-footnotes' and `symbol-footnotes'.  You can create your own w/o
> too much hassle, ie: footnote-numbering-function = #(lambda (x) (markup
> #:tiny "thank you james!")) reset-footnotes-on-new-page (default = ##t)
> -- automatic footnote annotations reset on each new page.
> All non-automatic paper-block commands apply to automatic footnotes as
> well.

How about calling that property footnote-numbering?

> NON-AUTOMATIC-FOOTNOTES
> 
> *** ATTENTION ***
> For non-automatic footnotes, the paper block MUST contain
> footnote-auto-number = ##f Otherwise, LilyPond will spew numbers all over
(Continue reading)

benko.pal | 1 Aug 2011 13:31
Picon

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

hi Bertrand,

(I'm not a grand-master, :( )

good that you caught the problem with hole in usable-duration-logs, but,
I think, that makes more comment necessary, see below.

all reviewers: is there a convention about using assertions in C++ code?

http://codereview.appspot.com/4536068/diff/55001/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):

http://codereview.appspot.com/4536068/diff/55001/lily/multi-measure-rest.cc#newcode255
lily/multi-measure-rest.cc:255: find the longest usable rest fitting
into l:
fitting into measure_count

http://codereview.appspot.com/4536068/diff/55001/lily/multi-measure-rest.cc#newcode257
lily/multi-measure-rest.cc:257: length is its duration (in mdl units)
append to the comment something like

       note: if length were zero on exit, the while-loop wouldn't
terminate,
       but this shouldn't happen since mdl is known to be in
duration_logs_list

and perhaps (what is LP convention?) add an

     assert(length > 0);

(Continue reading)

Wols Lists | 1 Aug 2011 16:47
Picon

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

On 31/07/11 23:35, Carl Sorensen wrote:
> On 7/31/11 4:17 PM, "Wols Lists" <antlists <at> youngman.org.uk> wrote:
> 
>> On 31/07/11 22:00, Janek Warchoł wrote:
>>> 2011/7/31 Wols Lists <antlists <at> youngman.org.uk>:
>>>>
>>>> Assuming that it's okay and is applied, I've redone my docu patch.
>>>
>>> Uploaded to Rietveld.  I see one trailing whitespace (after "By
>>> default the chords are"), also there should be two spaces after a
>>> period which ends sentence.
>>>
>>>> The snippet prints a four-bar phrase with just the standard chord
>>>> (to trap the regression that bit us this time :-), then sets the capoPitch
>>>> to print transposed chords for the next four bars, then sets capoVertical
>>>> to print chords one above the other for the last four bars.
> 
> Do we need four bars?  Why not just do three bars -- one with capoPitch '(),
> another with capoPitch set, and a third with capoVertical?
> 
> We like to get examples and regtests as simple as can be.
> 
New modified regtest attached. I've cut it down to one line, two bars
per section so six in total. (I know you want minimal, but cutting it
down to one note per section feels a bit two much, and two minims looked
naff.) The other thing is, the new regtest doesn't have N/C, which
doesn't seem to matter, but that was almost the first thing I thought
needed checking when I first saw the chord-mode documentation I based my
sample and reg-test on.

(Continue reading)

Graham Percival | 1 Aug 2011 21:28
Picon
Favicon

fixcc.py done

I have pushed the grand ficc.py run (including Keith's last fix).
  4a401ca1c60f428daa242dbdd102fdb3f327ebfb

For all patch authors for C++ code: please update your local git
tree, and then create a new patch(es), because your current
patch(es) on Rietveld cannot be applied to git master.

If you encounter difficulties in doing this, please ask for help;
there is assistance for git available.  Whatever you do, don't
panic.  In the very worst case, we can still get your hard work
from the existing Riteveld issue and do some manual fiddling
around to create an updated patch.

Cheers,
- Graham

Gmane