Re: define-void-function or define-procedure ?

2011-10-20 Thread David Kastrup
Carl Sorensen  writes:

> On 10/19/11 3:14 PM, "David Kastrup"  wrote:
>
>>
>>>
>>> I am not enthused about this particular consequence of
>>> auto-exporting Scheme expressions.  I currently don't see a better
>>> way of handling it, and it has flagged more bad code than false
>>> positives when I tried it.  But I would be quite surprised if it did
>>> not trigger regressions with existing previously valid and
>>> reasonable code.
>
> I think if we're finding bad code, it's probably an improvement.  But
> to the extent that we break valid code, it's a problem.

"previously valid".  But of course any change that non-trivially changes
rather than _merely_ extends functionality needs quite more
consideration.  Most of my changes so far I have been able to just sneak
in under the radar because they would only affect fringe code
negatively, code that nobody writes.

>>An afterthought, however: we do have an inordinate amount of
>>user-level commands that need to be called from Scheme rather than
>>with Lilypond syntax.  That does not make sense.  Void music functions
>>have been around for eternities, just a bit inconvenient to define,
>>but reasonably documented.
>
> I think that there has been some feeling in the past that defining
> void functions and using lilypond mode to handle these commands is
> just syntactic sugar.

I quite disagree since Lilypond functions have type-checked arguments
and "work fine" with convert-ly.  convert-ly does not touch Scheme code,
and so Scheme code can be reasonably considered to be effectively not
part of the language.

Now of course my current project is trying to break the barriers between
Scheme and Lilypond mode, but my main motivation is that people can
avoid having to use Scheme for a whole task that is 95% doable in
Lilypond.  If you can just squeeze the required 5% of Scheme into
Lilypond constructs not specifically designed for that, the amount of
Scheme knowledge you need before being able to do something useful is
much less.  And the probability of your code being able to survive
convert-ly passes with correct results increases.

One "I want to do that eventually" project of mine is to have #{ ... #}
parsed at compile time so that no motivation for using (markup ...) over
#{ \markup { ... } #} remains.  For user level code, I consider the
second choice quite preferable already.

Perhaps one good idea would be to have all music functions be trivially
callable in Scheme.  That way, arguments would get typechecked, and
there would be no compatibility excuses for not providing music
functions.  Old code would continue working without convert-ly hassles,
but one would change the implementation and rip out the old docs right
away.

The one thing needing consideration are the "parser location" args since
they might get used for syntax errors and #{ ... #}.  So either they
need to be required parts of the function signature, or the boilerplate
checking the arguments and rerouting the call picks them from the
context of the calling #(...) construct or from the environment of the
music function definition, if all else fails.

Or one does not provide a pure Scheme wrapper for any function that
actually uses parser and location.  Not sure whether one can wheedle
this information from Guile.

>>Maybe we need a user interface meister that tries to maintain a bit of
>>coherency and sanity when new features get added.
>
> It seems to me that you are functioning as the UI meister right now.

Not really.  I am tearing my hairs and providing infrastructure mostly,
but not actually interfering significantly with existing interfaces.

I won't be able to root out all existing bad examples to a degree where
newcomers will feel bad about providing awkward code.

So my focus is on trying to make it easy to do better.  Most people are
happy when the thing they have been concocting is able to do the job for
them.  So it needs to be easy, hopefully a total no-brainer, to do it
nice on first try.

So I am not acting as much as UI meister, but rather trying to be a good
UI manager in the sense that a good manager is one that manages not
having to manage things.

A UI meister would exercise authority, tell people not to do bad things.
I try making it hard to do bad things even without a UI meister
exercising his iron grip.  And once it is hard enough, I shout and
holler and stomp my feet without bad conscience.  When I get to see bad
things.  But most of the time I am too lazy to pay attention.

> And you're doing a great job of it -- not just trying to get new
> interfaces to be sane, but pointing out where there is insanity in the
> existing interfaces.

Drive-by shootings.

-- 
David Kastrup


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


markups and extents

2011-10-20 Thread m...@apollinemike.com
Hey all,

I'm starting to work on a markup overhaul and I've been able to frame the 
problem with the code below.  There are two callbacks each for X and pure-Y:

my-x-callback-one
my-x-callback-two
my-y-callback-one
my-y-callback-two

my-*-callback-one gives minimal estimates for the given dimension, whereas 
my-*-callback-two gives maximal estimates.
The only code that doesn't lead to overlap is the use of maximal estimates for 
everything (my-*-callback-two, which I pasted below).  Subbing in 
my-*-callback-one for either value will lead to overlapping.  However, 
my-*-callback-two being very generous, the vertical spacing becomes too large.  
So, my question before I start fiddling with the C++ side is: is there a way to 
use non-pure-heights in LilyPond's vertical layout?

If not, my proposed game plan is the following (suggestions welcome!):

1) Create a variable in the Paper_column class called pure_x_offset_
2) From constrained-breaking.cc, run the spring and rods problem on an 
infinitely long line.  Give all paper columns a pure_x_offset_ that comes from 
this spring and rods problem (this, I'd argue, is the ideal horizontal spacing, 
unfettered by the length and width of a page).
3) Create a TextScriptSpanner
4) The pure height function of a text script spanner 
(Text_script_spanner::pure_height (SCM smob, SCM start, SCM end)) would go like 
such:
---) if `start' is to the right of the TextScriptSpanner's left bound, return 0.
---) otherwise, find the distance between the pure_x_offset_ of the 
TextScriptSpanner's left bound and the pure_x_offset_ of the column at `end'
---) use this line-width to justify the text, then find the Y-extent of this 
stencil.  this is the pure-Y value between `start' and `end'.

Obviously, pure_x_offset_ will get progressively off as a piece continues, but 
for small ranges of columns, it will likely provide a good estimation of grobs' 
spacing.

But, again, before I spend the 4ish hours necessary to do this, does anyone see 
any problems with it?

Cheers,
MS

#(define (define-grob-property symbol type? description)
 (if (not (equal? (object-property symbol 'backend-doc) #f))
 (ly:error (_ "symbol ~S redefined") symbol))

 (set-object-property! symbol 'backend-type? type?)
 (set-object-property! symbol 'backend-doc description)
 symbol)

#(define (has-interface? grob interface)
 (member interface
  (assoc-get 'interfaces
 (ly:grob-property grob 'meta

#(define-grob-property 'nuggets list? "List of text for a markup.")

#(define (my-max x y) (if (> (interval-length x) (interval-length y)) x y))

#(define (my-add x y) (cons (car x) (+ (cdr x) (interval-length y

#(define (my-x-callback-one grob)
 (reduce my-max -1000 (map (lambda (x) (ly:stencil-extent 
(grob-interpret-markup grob x) X))
(ly:grob-property grob 'nuggets

#(define (my-x-callback-two grob)
 (ly:stencil-extent (grob-interpret-markup grob (make-line-markup 
(ly:grob-property grob 'nuggets))) X))

#(define (my-y-callback-one grob start end)
 (ly:stencil-extent (grob-interpret-markup grob (make-line-markup 
(ly:grob-property grob 'nuggets))) Y))

#(define (my-y-callback-two grob start end)
 (reduce my-add '(0 . 0) (map (lambda (x) (ly:stencil-extent 
(grob-interpret-markup grob x) X))
(ly:grob-property grob 'nuggets

#(define (find-system grob)
(if (has-interface? grob 'system-interface)
  grob
  (find-system (ly:grob-parent grob X

#(define (my-stencil grob)
 (let* ((system (find-system grob))
(mkups (map (lambda (x) (markup x)) (ly:grob-property grob 'nuggets)))
(r-bound (ly:spanner-bound system RIGHT))
(l-coord (ly:grob-relative-coordinate grob system X))
(r-coord (ly:grob-relative-coordinate r-bound system X)))
   (grob-interpret-markup grob (markup #:override `(line-width . ,(- r-coord 
l-coord)) (make-justify-markup mkups)

foo =
#(define-music-function (parser location s) (string?)
#{
 \once \override TextScript #'nuggets = #(string-split $s #\space)
 \once \override TextScript #'Y-extent = #(ly:make-unpure-pure-container 
ly:grob::stencil-height my-y-callback-two)
 \once \override TextScript #'X-extent = #my-x-callback-two
 \once \override TextScript #'stencil = #my-stencil
#})


\relative c' {
 \override Score . PaperColumn #'keep-inside-line = ##f
 \repeat unfold 40 { \foo #"Hello world this is a test of a Scheme markup 
splitting system." d^\markup { \null } a b c d e f g }
}


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


Re: Make accidental styles available as context mods. (issue 4819064)

2011-10-20 Thread n . puttock

On 2011/10/20 04:06:03, Keith wrote:

Neil, don't forget to push this.
I've been looking forward to it.


I'll try to sort it out at the weekend.  Unfortunately I don't have a
working Linux install at the moment, and foolishly neglected to back it
up for easier restoring.

Cheers,
Neil

http://codereview.appspot.com/4819064/

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


Re: Make accidental styles available as context mods. (issue 4819064)

2011-10-20 Thread n . puttock

On 2011/10/20 05:44:38, dak wrote:

Sorry, I always start thinking only when far too late in the game.

Anyway, here

is a musing:
should't the _main_ interface to accidental modifications be context

mods?  You

won't need to set them in midcontext except in unusual situations, and

then

\applyContext (?) is available.


That would be possible, though you'd probably want a nicer interface
than using \applyContext directly.  A music function would have to have
two args: the optional context string and the context-mod identifier.

Cheers,
Neil


http://codereview.appspot.com/4819064/

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


Re: GUB

2011-10-20 Thread Colin Campbell

On 11-10-19 10:42 PM, Graham Percival wrote:

On Wed, Oct 19, 2011 at 10:00:26PM -0600, Colin Campbell wrote:

Command barfed: cd /home/colin/gub/target/tools/build/curl-7.19.0
&&  make -j4

Tail of target/tools/log/curl.log
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/colin/gub/target/tools/build/curl-7.19.0/src'
make: *** [all-recursive] Error 1
Command barfed: cd
/home/colin/gub/target/tools/build/curl-7.19.0&&  make -j4
  Tail of target/tools/log/curl.log

Well, what do you see in target/tools/log/curl.log ?  The portion
of that logfile that GUB showed you doesn't contain any useful
info, so please manually open up that logfile and look for
anything suspicious.

also, exactly what OS/hardware are you using?  By chance I started
working on the "recompile everything" issue earlier tonight, and
curl built on my lilydev ubuntu machine.

Cheers,
- Graham



The error seems to be just above the tailed part:
libtool: link: gcc -I/home/colin/gub/target/tools/root/usr/include 
-Wl,-rpath -Wl,\$ORIGIN/../lib -Wl,-rpath 
-Wl,/home/colin/gub/target/tools/root/usr/lib -o .libs/curl main.o 
hugehelp.o urlglob.o writeout.o writeenv.o getpass.o homedir.o 
curlutil.o strtoofft.o strdup.o  
-L/home/colin/gub/target/tools/root/usr/lib ../lib/.libs/libcurl.so 
-lidn -lldap -lrt -lssl -lcrypto -lz

../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method'
collect2: ld returned 1 exit status
make[2]: *** [curl] Error 1
make[2]: Leaving directory 
`/home/colin/gub/target/tools/build/curl-7.19.0/src'



I tried a git grep "SSLv2_client_method" but got nothing.

This is on Ubuntu 11.10 on an x86-64 machine, running natively.  I'll 
try my VM 32-bit Ubuntu at the office later today.


Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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


Sketch for in-notes. (issue 5293053)

2011-10-20 Thread mtsolo

Reviewers: ,

Message:
Hey all,

As part of project markup & at the suggestion of Nicolas Sceaux by way
of Valentin's opera, I've implemented in-notes in LilyPond.  These notes
hover above systems and come up a fair bit in vocal music.

It works, but I have one major and one semi-major snag that I'd like to
run by people.  Please don't run the regtests on this yet until these
snags are worked out.

Semi-major-snag: get_footnotes_from_lines should only ever be called
once and should stash its results in the systems and/or probs.  I'll
figure out how to do this in the near future.

Major snag.  On about 1 out of every 5 runs of this patch, it leads to
way-too-big spacing.  This is because the stencils of in notes are, for
some reason, registering infinite extents in page-spacing.cc when
they're being counted (check account_for_footnotes and you'll see that
the value of the extent for in_notes is occasionally really really
really large).  This is strange because when the in_notes are added to
the breaker (System::get_in_notes_in_range), these extents are  correct.
 I think it is an issue with pointers and garbage collection of stencils
- does anyone have any intuition about this.

Here's a test file:

\version "2.15.15"

\header {
  texidoc = "LilyPond does in-notes.  The positioning of these notes can
be above or below the staff via the paper variable @code{in note
direction}
and spaced via the variable @{in-note-padding}.
"
}

\relative c' {
  \repeat unfold 5 {
\repeat unfold 20 { a\< b c d\! }
% activates the in-note
\once \override FootnoteItem #'footnote = ##f
\footnoteGrob #'NoteHead #'(0 . 0)
  "" \markup { \box \fill-line { "this is a test this is
a test" } }
a b c d
\repeat unfold 20 { a b c d }
\autoFootnoteGrob #'NoteHead #'(-1 . 1) "foo bar foo bar"
a b c d
   \repeat unfold 20 { a\< b c d\! }
  }
}

Description:
Sketch for in-notes.

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

Affected files:
  M lily/constrained-breaking.cc
  M lily/include/constrained-breaking.hh
  M lily/include/page-breaking.hh
  M lily/include/page-layout-problem.hh
  M lily/include/system.hh
  M lily/page-breaking.cc
  M lily/page-layout-problem.cc
  M lily/page-spacing.cc
  M lily/system.cc
  M scm/define-grob-interfaces.scm
  M scm/define-grob-properties.scm
  M scm/define-grobs.scm
  M scm/paper-system.scm



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


Re: Sketch for in-notes. (issue 5293053)

2011-10-20 Thread mtsolo

The memory management issue is now fixed.
A new patch will be coming down the pipe in 2-3 hours with a regtest.

Cheers,
MS

http://codereview.appspot.com/5293053/

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


Re: How do feel people about the following change in syntax?

2011-10-20 Thread David Kastrup
David Kastrup  writes:

> Now here is one thing worth considering: currently the predicate scheme?
> is defined as
> (define-public (scheme? x) #t)
>
> I lean towards defining it instead as
> (define-public (scheme? x) (not (eq? x (begin
> so that it will accept anything _except_ void expressions.
>
> Does that appear like a good idea?

Ugh, it means that define-void-function can't be a special case of
define-scheme-function: define-void-function will always return a void
expression, and define-scheme-function is defined to return a value of
type scheme?, so Lilypond would protest if you tried to return a void
expression and probably return #f after flagging an error.

define-scheme-function is pretty young, so perhaps disallowing it from
returning void expressions makes some sense without all too much
compatibility pain as long as define-void-function is available for
functions not returning anything.

Is it ok if I do this as one commit series?

-- 
David Kastrup


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


Re: Sketch for in-notes. (issue 5293053)

2011-10-20 Thread mtsolo

Hey all,

The patch is now ready to be tested - I got a clean bill of health from
the regtests.

Cheers,
MS

http://codereview.appspot.com/5293053/

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


Re: GUB

2011-10-20 Thread Graham Percival
On Thu, Oct 20, 2011 at 07:05:54AM -0600, Colin Campbell wrote:
> ../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method'
> collect2: ld returned 1 exit status
> 
> I tried a git grep "SSLv2_client_method" but got nothing.

Try this:
  sudo apt-get install libssl-dev
then try the bootstrap again

If that works, I'll add it to the dependencies listed in the
README.

Cheers,
- Graham

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


Re: Sketch for broken beams with consistent slopes (issue 4961041)

2011-10-20 Thread n . puttock


http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely
File Documentation/changes.tely (right):

http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode66
Documentation/changes.tely:66: \override Beam #'breakable = ##t
no indent

http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode68
Documentation/changes.tely:68: a8 [ b c d e f g \bar "" \break f e d c b
a ]
a8[
a]

http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode78
Documentation/changes.tely:78: the beam grob. All Scheme functions that
used these callbacks are now
two spaces after full stop/period

http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode79
Documentation/changes.tely:79: simplified.  For examples, see
@file{input/regression/beam-concave.ly}
You shouldn't reference regression tests here.  Will frighten users. :)

http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly
File input/regression/beam-consistent-broken-slope.ly (right):

http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly#newcode2
input/regression/beam-consistent-broken-slope.ly:2: \version "2.15.12"
2.15.15

http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly#newcode12
input/regression/beam-consistent-broken-slope.ly:12: \override Beam
#'breakable = ##t
indent, code style

http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly#newcode13
input/regression/beam-consistent-broken-slope.ly:13: a8 [ b c d e f g
\bar "" \break f e d c b a ]
a8[
a]

etc.

http://codereview.appspot.com/4961041/diff/60001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/4961041/diff/60001/scm/define-grob-properties.scm#newcode749
scm/define-grob-properties.scm:749: (skip-quanting ,boolean? "Should
beam quanting be skipped?")
Is this likely to be used outside regression testing?

http://codereview.appspot.com/4961041/diff/60001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/4961041/diff/60001/scm/define-grobs.scm#newcode386
scm/define-grobs.scm:386: (positions .  ,ly:beam::quanting)
remove extra space

http://codereview.appspot.com/4961041/diff/60001/scm/layout-beam.scm
File scm/layout-beam.scm (right):

http://codereview.appspot.com/4961041/diff/60001/scm/layout-beam.scm#newcode65
scm/layout-beam.scm:65: grob
indent

http://codereview.appspot.com/4961041/diff/60001/scm/layout-beam.scm#newcode72
scm/layout-beam.scm:72: grob
indent

http://codereview.appspot.com/4961041/

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


Re: GUB

2011-10-20 Thread Colin Campbell

On 11-10-20 12:29 PM, Graham Percival wrote:

On Thu, Oct 20, 2011 at 07:05:54AM -0600, Colin Campbell wrote:

../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method'
collect2: ld returned 1 exit status

I tried a git grep "SSLv2_client_method" but got nothing.

Try this:
   sudo apt-get install libssl-dev
then try the bootstrap again

If that works, I'll add it to the dependencies listed in the
README.

Cheers,
- Graham




I already had it installed (version 1.0.0e-2ubuntu4 FWIW).

Cheers
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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


Re: First stab at getting script offsets right. (issue 5235052)

2011-10-20 Thread bordage . bertrand

LGTM, but the result is really disturbing.  We need to think about a
better approach of character boxes in MetaFont.  The ideal solution
would be to create a mask for each character.  For example, a mask for
the "espressivo" glyph would be a "fill" between its 6 dots.

I know it's impossible to interpret this mask in C++...

Anyway, I think this patch can be pushed as the first part of a fix to
issue 1951.

Bertrand


http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc
File lily/script-engraver.cc (right):

http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc#newcode208
lily/script-engraver.cc:208: int script_count = scripts_.size ();
vsize instead of int.  Could you change the others above?

http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc#newcode209
lily/script-engraver.cc:209: for (int i = 0; i < script_count; i++)
vsize.

http://codereview.appspot.com/5235052/diff/23001/lily/slur.cc
File lily/slur.cc (right):

http://codereview.appspot.com/5235052/diff/23001/lily/slur.cc#newcode275
lily/slur.cc:275: // cannot use is empty because some 0-extent scripts
I don't understand.  Did you meant "if empty"?

http://codereview.appspot.com/5235052/

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


PATCH: Countdown to 20111023

2011-10-20 Thread Colin Campbell

For 22:00 MDT Sunday October 23
Issue 1506 : 
\tempo after StopStaff/StartStaff forces extension of staff symbol - R 
5303043 


Issue 1663 : 
Images missing on web site - R 5276054 



Issue 1951 : 
Scripts collide with accidentals - R 5235052 



Issue 1979 : 
Patch: convert-ly rules for Stem \#'stencil = \#\#f - R 5316041 



Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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


Re: First stab at getting script offsets right. (issue 5235052)

2011-10-20 Thread m...@apollinemike.com
On Oct 21, 2011, at 3:41 AM, bordage.bertr...@gmail.com wrote:

> LGTM, but the result is really disturbing.  We need to think about a
> better approach of character boxes in MetaFont.  The ideal solution
> would be to create a mask for each character.  For example, a mask for
> the "espressivo" glyph would be a "fill" between its 6 dots.
> 
> I know it's impossible to interpret this mask in C++...
> 

Not necessarily - you can stash all sorts of information in font tables, which 
are then accessible via the otf_tables.
The same thing needs to be done for flags, which have been glued to stems via a 
kludge in the X-offset function for some time.
Janek was toying around with font tables last time I checked in with him - it'd 
take me some time to learn how the metafont part of the code works, so if this 
is something you think you could tackle, I'd be able to implement the C++ side.

> Anyway, I think this patch can be pushed as the first part of a fix to
> issue 1951.
> 
> Bertrand
> 
> 
> http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc
> File lily/script-engraver.cc (right):
> 
> http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc#newcode208
> lily/script-engraver.cc:208: int script_count = scripts_.size ();
> vsize instead of int.  Could you change the others above?

fixed.

> 
> http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc#newcode209
> lily/script-engraver.cc:209: for (int i = 0; i < script_count; i++)
> vsize.

fixed.

> 
> http://codereview.appspot.com/5235052/diff/23001/lily/slur.cc
> File lily/slur.cc (right):
> 
> http://codereview.appspot.com/5235052/diff/23001/lily/slur.cc#newcode275
> lily/slur.cc:275: // cannot use is empty because some 0-extent scripts
> I don't understand.  Did you meant "if empty"?

I meant is_empty (the function).

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Sketch for broken beams with consistent slopes (issue 4961041)

2011-10-20 Thread Mike Solomon
Thanks Neil!

On Oct 20, 2011, at 9:24 PM, n.putt...@gmail.com wrote:

> http://codereview.appspot.com/4961041/diff/60001/scm/define-grob-properties.scm
> File scm/define-grob-properties.scm (right):
> 
> http://codereview.appspot.com/4961041/diff/60001/scm/define-grob-properties.scm#newcode749
> scm/define-grob-properties.scm:749: (skip-quanting ,boolean? "Should
> beam quanting be skipped?")
> Is this likely to be used outside regression testing?

Of this I am not sure.  My gut says yes, but I don't know why the regtest that 
skips quanting was added and the extent to which quantless-beams are used by 
users.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel