Re: Releasing 2.20

2017-06-09 Thread Paul 

On 06/08/2017 03:31 PM, David Kastrup wrote:


Sounds good to me.  I have a few things I'd like to get into the
stable release, one way or another, if possible.

- Some CSS edits for the docs that I started but havent
finished/submitted for review yet.  I'll try to get that done in the
next few days if I can.

Shouldn't matter a lot regarding stable/unstable but we should get the
bikeshedding finished by release time.


Sounds good.


- Might be worth looking again at issue 3884, either to just go with
the initial patch for now, or try for one of the other approaches in
that discussion?
https://sourceforge.net/p/testlilyissues/issues/3884/

Ugh, looks like another ball I dropped.  I'll take to pencil and paper
some time tomorrow.


I see you already have a proposal/fix.  That was fast!  I'll try to take 
a look and reply in the other thread.



- This doesn't really matter, but it might be worth renaming the
"staffLineLayoutFunction" context property (which is not really about
staff lines...) to something better, maybe
"pitchToStaffPositionFunction" or pitchToStaffPositionProcedure"? (It
takes a pitch and returns an integer indicating a vertical staff
position.  It's used in note-heads-engraver.cc)

Well, discussion needs to have converged really well for changes to
preexisting conventions to get into stable: we don't really want to do
gratuitous changes that might get changed again or do not provide a
definite payback for the hassle.


OK, sounds like a discussion to have for 2.21 / 2.22 then.

A few other possibilities, for later:

  pitchToStaffLayoutFunction

  pitchToStaffLayoutProcedure

  staffPitchLayoutFunction

  staffPitchLayoutProcedure

Cheers,
-Paul


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

Re: Releasing 2.20

2017-06-09 Thread David Kastrup 
Masamichi Hosoda  writes:

>> Hans Aikema  writes:
>> 
>>> David,
>>>
>>> Make sure that your main focus will be getting back into good shape.
>>>
>>> If schedule and energy levels allow for starting of a 2.20 branch I
>>> think it would be good to update ghostscript to a version that has the
>>> PNG-transparency glitches fixed that surfaced in 2.19.51.
>>> Ghostscript has made a release with the fix for the issue that was
>>> created by Masamichi Hosoda as a result of the discovery of the
>>> PNG-transparency bug in the 2.19.51 Lilypond build)
>> 
>> That's more a matter of GUB than of LilyPond.  GhostScript is more of a
>> runtime dependency so it's not really something we would refuse a build
>> for.
>
> I've sent a pull request that updates GUB's Ghostscript to 9.21.
> https://github.com/gperciva/gub/pull/39
>
> However, on FreeBSD 32 bit, both Ghostscript 9.20 and 9.21 crash.
> So only for FreeBSD 32 bit, Ghostscript 9.15 is used.
>
> Linux 64 bit, Linux 32 bit, Linux PPC, FreeBSD 64 bit,
> and Windows are no problem.
>
> In my humble opinion, after or before releasing 2.20,
> it is better to discontinue some platforms' binary release.

If we call it "stable", it better be stable.  So I think it would make
sense to make the decision for the release.

-- 
David Kastrup

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

Re: Releasing 2.20

2017-06-09 Thread Masamichi Hosoda 
> Hans Aikema  writes:
> 
>> David,
>>
>> Make sure that your main focus will be getting back into good shape.
>>
>> If schedule and energy levels allow for starting of a 2.20 branch I
>> think it would be good to update ghostscript to a version that has the
>> PNG-transparency glitches fixed that surfaced in 2.19.51.
>> Ghostscript has made a release with the fix for the issue that was
>> created by Masamichi Hosoda as a result of the discovery of the
>> PNG-transparency bug in the 2.19.51 Lilypond build)
> 
> That's more a matter of GUB than of LilyPond.  GhostScript is more of a
> runtime dependency so it's not really something we would refuse a build
> for.

I've sent a pull request that updates GUB's Ghostscript to 9.21.
https://github.com/gperciva/gub/pull/39

However, on FreeBSD 32 bit, both Ghostscript 9.20 and 9.21 crash.
So only for FreeBSD 32 bit, Ghostscript 9.15 is used.

Linux 64 bit, Linux 32 bit, Linux PPC, FreeBSD 64 bit,
and Windows are no problem.

In my humble opinion, after or before releasing 2.20,
it is better to discontinue some platforms' binary release.

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

Re: Add on-page-greater-than, -less-than (on-the-fly) (issue 74540044)

2017-06-09 Thread dak 

Ok, I've taken another look at something that should help with this
amount of fine-grained definitions.  Do you think that the following
macro markup-when would be fine-grained enough to forego these kind of
definition?  I demonstrate it for implementing on-page-greater-than but
of course one may use it directly.  Its first argument is of the same
style as the #:properties keyword arg for define-markup-command .

#(define-macro (markup-when properties cond)
  `(lambda (layout props arg)
(let ,(map (lambda (p)
(if (pair? p)
 `(,(car p) (chain-assoc-get ',(car p) props ,@(cdr p)))
 `(,p (chain-assoc-get ',p props
   properties)
 (if ,cond (interpret-markup layout props arg)
  empty-stencil

#(define (on-page-greater-than nmbr)
  (markup-when ((page:page-number -1))
   (> page:page-number nmbr)))

\paper {
  #(set-paper-size "a7landscape")
  oddFooterMarkup = \markup \on-the-fly #(on-page-greater-than 3) "This
is long!"
}

\score {
  \repeat unfold 256 c'1
}


https://codereview.appspot.com/74540044/

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