staff-symbol-referencer: ledger logic; issue 4184 (issue 167040043 by k-ohara5...@oco.net)

[lemzwerg]

LGTM


https://codereview.appspot.com/167040043/diff/1/lily/side-position-interface.cc
File lily/side-position-interface.cc (right):

https://codereview.appspot.com/167040043/diff/1/lily/side-position-interface.cc#newcode383
lily/side-position-interface.cc:383: /* If we are closer to the staff
than the notehad, quantize for ledger lines. */
s/notehad/notehead/

But I wonder whether this is the best description – it's rather about
note heads and attached grobs having the same direction, right?

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

Re: Issue 1321: Enhancement: add partcombineUp and partcombineDown functions (issue 13242056)

[k-ohara5a5a]

No need to pass the context modifications through the lower-level
functions, when they can be applied at the level of the \partcombineUp
music function as Dan does now in his lilypond input.  These
modifications do not affect the operation of \partcombine, but are
merely added to its output so they should not be arguments to
\partcombine.


https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):

https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc#newcode37
lily/part-combine-iterator.cc:37: = {"one", "two", "shared", "solo",
"null"};
Setting these to  one, two, one, one, null
seems to do what Dan wishes.

If these names could be changed, maybe through a signal carried by a
music property, then we could name them
   innerUp, outerUp, innerUp, innerUp, null
   innerDown, outerDown, innerDown, innerDown, null
for partcombine Up/Down and two pairs of partcombined pares co-exist on
the staff.

https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc#newcode388
lily/part-combine-iterator.cc:388: apply_property_operations (solo,
mod->get_mods ());
Maybe do this at the Scheme level, in the \partcombine* music functions?

https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly#newcode1168
ly/music-functions-init.ly:1168: #{ \partcombine \with { \voiceOne }
\with { \voiceOne } #part1
On 2014/11/01 15:26:57, Dan Eble wrote:

In one way, this is cleaner than what I currently have to do to

modify

one/share/two context properties.  (That is refer to the voice

contexts in

parallel with \partcombine and set their properties.)  One thing I

like about

this is that I don't have to rely on the names of the voices that

\partcombine

creates.  One thing I don't like about it is that I'll have to consult

the

manual to check which context mods apply to "shared" and which apply

to all.  I

see nothing mnemonic about their position.


I don't think the idea was for users to use these optional parameters,
but only the wrapper functions \partcombine{Up,Down}


Stepping back, for the \partcombineUp use case, I think it would make

more

  sense for the partcombiner to distribute the input notes into just

two

voices instead of [four].


I think it could rather easily be changed to do that.

https://codereview.appspot.com/13242056/

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

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ballads gmail.com)

[Keith OHara]

  gnu.org> writes:
> On 2014/10/31 22:50:35, Dan Eble wrote:
> 
> > One thing just occurred to me.  If this option is going into the UI,
> do you
> > think the numbers should be 1-based for easier comprehension by
> musicians?  

> As a UI, numbers instead of intervals (possibly represented only by a
> pitch in relation to c' like \transposition does) do not make much
> sense.

I may be having trouble with the negative sentence construction, but
if you mean that
  \partcombine  {} {}
would be the intuitive way to indicate seconds through octave may be
be combined into chords, then I disagree.  Or, maybe you were joking.

Numbers are very good for representing intervals; we use numerical
names to represent them.  Numbers are also good for representing
differences in staff-position as well.  Either 1-based or 0-based
should be fine, if the docs consistently speak in terms of intervals
of the chords, or in terms of the graphical separation between noteheads,
respectively.

> Regarding such user interface extensions, I think we should rather go in
> the direction of
> https://code.google.com/p/lilypond/issues/detail?id=1321#c30>.
> Using context modifications makes it reasonably straightforward to add
> arbitrary named settings in arbitrary order on demand.

Well, the currently-proposed patch at your link uses optional
arguments to \partcombine, which would also be appropriate here
for the chord-range, and later for 'no-solo.  If that is the 
direction you mean, we all agree:  optional input argument #'(2 . 8)

If you mean to use context properties, they cannot be context 
properties of the output Voices because those are not created when
the chord-range needs to have its effect.  they cannot be
properties of the temporary Voices for the same reasons that idea
failed for the interface to force part-combine decisions.

Generally issue 1321 concerns how the voices output from partcombine
are set on the staff, so it should not change the input interface to
partcombine at all.


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

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> Masamichi HOSODA  writes:
> 
>> How about this patch?
>>
>> --- librestrict/xstatconv.c.org  2014-10-19 09:52:52.951262300 +0900
>> +++ librestrict/xstatconv.c  2014-11-01 20:26:35.734854500 +0900
>> @@ -48,20 +48,16 @@
>>{
>>  struct stat *buf = ubuf;
>>  
>> +/* zero clear */
>> +memset(buf, 0, sizeof(*buf));
>>  /* Convert to current kernel version of `struct stat'.  */
>>  buf->st_dev = kbuf->st_dev;
> 
> On the surface of it, this looks very reasonable.  However, since
> everything is guarded with #ifdef and similar and the definitions are
> probably generated by autoconf, it would appear that different versions
> of stat.h are employed in the compilation and the resulting mismatch of
> definitions and structures (possibly between host and target
> definitions) could lead to crashes and memory corruption.
> 
> So it would seem like a good idea to first figure out what goes wrong
> here before fixing it in this manner.  It might be a nice fix (and the
> code certainly looks nicer for it) but I have no idea if it is correct.
> The "if it were that easy, it would have been written like that in the
> first place" mantra may be wrong surprisingly often, but it would still
> be nice to make sure.
> 
> -- 
> David Kastrup

librestrict does not have a configure script. 
Therefore, it does not use autoconf.
Furthermore, in my understanding, librestrict is not cross compiled. 
That is, the host and the target is always the same as host OS.

If this is right, I think that my patch does not have a problem. 

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

Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ball...@gmail.com)

[Dan Eble]

On Nov 1, 2014, at 18:48 , Noeck  wrote:
> 
>>> I haven’t implemented the double-C cases yet.
>> 
>> This is what I think would be best:
>> 
>> * leave the default style alone
>> * add to the C style: 4/2 -> CC, 2/1 -> cut-CC
>> 
>> This would end the equivalence of default and C styles.  Does that seem like 
>> a bad idea to any seasoned Lilypond developers?  I would prefer to hear it 
>> now than to implement it first and hear about it in code review.
>> 
>> My reasoning is that the CC and cut-CC time signatures seem too obscure to 
>> be enabled by default, but too closely related to the C and cut-C time 
>> signatures to deserve a separate style.  The new time signatures would make 
>> sense within this matrix:
>> 
>>numberedsingle-digit
>>C   single-C
> 
> Hi Dan,
> 
> it is not my intention to bother you, but I would like to understand
> this. Is this your plan?
> 
> style
> defaultc¢   2/4  2/1  4/2  8/4  3/4  6/8
> C  c¢   2/4  ¢¢   cc   8/4  3/4  6/8 <---
> single-C   c¢   [¢]   ¢c   8/4  3/4  6/8 <---
> numbered  4/4  2/2  2/4  2/1  4/2  8/4  3/4  6/8
> single-digit   42224836

It’s no bother.  I corrected one entry [in brackets].  (single-C is based on 
the numerator only, just like single-digit.)  Thanks for taking the time to 
type this out for everyone.

The single-C style is waiting to be pushed 
(https://code.google.com/p/lilypond/issues/detail?id=3286)

The bug squad has accepted my suggestion to rename single-digit to 
single-number (https://code.google.com/p/lilypond/issues/detail?id=4178).
— 
Dan


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

Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ball...@gmail.com)

[Noeck]

>> I haven’t implemented the double-C cases yet.
> 
> This is what I think would be best:
> 
> * leave the default style alone
> * add to the C style: 4/2 -> CC, 2/1 -> cut-CC
> 
> This would end the equivalence of default and C styles.  Does that seem like 
> a bad idea to any seasoned Lilypond developers?  I would prefer to hear it 
> now than to implement it first and hear about it in code review.
> 
> My reasoning is that the CC and cut-CC time signatures seem too obscure to be 
> enabled by default, but too closely related to the C and cut-C time 
> signatures to deserve a separate style.  The new time signatures would make 
> sense within this matrix:
> 
> numberedsingle-digit
> C   single-C

Hi Dan,

it is not my intention to bother you, but I would like to understand
this. Is this your plan?

style
defaultc¢   2/4  2/1  4/2  8/4  3/4  6/8
C  c¢   2/4  ¢¢   cc   8/4  3/4  6/8 <---
single-C   c¢   2/4   ¢c   8/4  3/4  6/8 <---
numbered  4/4  2/2  2/4  2/1  4/2  8/4  3/4  6/8
single-digit   42224836

With this meaning:
 - I indicate the C symbols with c and ¢
 - a mono space font needed
 - default means the current C style
 - C means your C style

Will single-digit be renamed to single-number?

Source for showing time signatures:

\version "2.18.2"
%http://www.lilypond.org/doc/v2.18/Documentation/internals/time_002dsignature_002dinterface

music = {
  \time 4/4 s1 \time 2/2 s
  \time 2/4 s2
  \time 2/1 s1*2 \time 4/2 s \time 8/4 s
  \time 3/4 s2. \time 6/8 s2.
}

 <<
  \new Staff { \override Staff.TimeSignature.style = #'default
<>^"default"  \music }
  \new Staff { \override Staff.TimeSignature.style = #'C
<>^"C"\music }
 %\new Staff { \override Staff.TimeSignature.style = #'single-C
<>^"single-C" \music }
  \new Staff { \override Staff.TimeSignature.style = #'numbered
<>^"numbered" \music }
  \new Staff { \override Staff.TimeSignature.style = #'single-digit
<>^"single-digit" \music }
  \new Staff { \override Staff.TimeSignature.style = #'mensural
<>^"mensural" \music }
  \new Staff { \override Staff.TimeSignature.style = #'neomensural
<>^"neomensural"  \music }
 >>

Cheers,
Joram

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

Re: Happy 18th birthday, LilyPond

[Pierre Perol-Schneider]

Hi Han-Wen

2014-11-01 21:05 GMT+01:00 Han-Wen Nienhuys :

> The 0.0.0 release happened in the first half of October 1996. I can't
> remember the exact date, but it was a weekday and I celebrated by
> having a beer with my dorm-mates.
>


So maybe you remember which day : 12th & 13th was resp. a Saturday and a
Sunday?...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Happy 18th birthday, LilyPond

[Han-Wen Nienhuys]

The 0.0.0 release happened in the first half of October 1996. I can't
remember the exact date, but it was a weekday and I celebrated by
having a beer with my dorm-mates.



On Sat, Nov 1, 2014 at 6:11 AM, Francisco Vila  wrote:
> Sorry for the cross-posting. Just a short note to say LIlyPond is 18
> since october if our git history is true.
>
> Congrats to all for using/developing/maintaining/enjoying this great
> piece of software.
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

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

Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ball...@gmail.com)

[Dan Eble]

On Oct 26, 2014, at 17:19 , Dan Eble  wrote:
> 
> I haven’t implemented the double-C cases yet.

This is what I think would be best:

* leave the default style alone
* add to the C style: 4/2 -> CC, 2/1 -> cut-CC

This would end the equivalence of default and C styles.  Does that seem like a 
bad idea to any seasoned Lilypond developers?  I would prefer to hear it now 
than to implement it first and hear about it in code review.

My reasoning is that the CC and cut-CC time signatures seem too obscure to be 
enabled by default, but too closely related to the C and cut-C time signatures 
to deserve a separate style.  The new time signatures would make sense within 
this matrix:

numberedsingle-digit
C   single-C

Thanks,
— 
Dan


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

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

On 2014/11/01 18:32:49, dak wrote:

On 2014/11/01 18:04:31, Dan Eble wrote:
> Would you settle for my original approach of adding an internal

argument but

> not exposing any UI for it until after more thought is put into the

many

> interrelated issues that have been mentioned?



Well, you may have to rework once we have progressed on how we

organize

internals.  But that beats getting nowhere because of deadlocking on

everything

that might change.


What I am using now is a monolithic alternative part combiner.  A small
contribution that reduces the risk and extent of conflicts with new work
is still valuable to me.

After this, I think there might be one or two tiny bug-fixes that I can
extract, but the main thing that remains is solo inhibition. When I get
to that, I will try to consider the whole problem including forced
decisions, output voice selection, and context modification.  You have
shown me a lot in this review.  It strikes me as a project worthy of two
months of full-time work, but maybe I'll stumble upon some ideas that
eventually contribute to progress.


And it *is* sort of ridiculous that for every proposal regarding the

part

combiner I pull an old issue out of the hat where I did not ultimately
commit anything because I was not really happy with it either.


You said it. :-)

I expect to post another patch set with minor revisions soon.
(Hopefully it will show the deltas; this review was originally created
with my problematic LilyDev 2 installation.)

https://codereview.appspot.com/144170043/

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

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)

[dak]

On 2014/11/01 18:04:31, Dan Eble wrote:

On 2014/11/01 06:37:11, dak wrote:
> I can rebase that patch if you want to see whether fitting a user

interface

> there feels better.



Would you settle for my original approach of adding an internal

argument but not

exposing any UI for it until after more thought is put into the many
interrelated issues that have been mentioned?


Well, you may have to rework once we have progressed on how we organize
internals.  But that beats getting nowhere because of deadlocking on
everything that might change.

With the user interface, it's a bit more icky.  At the very least, what
we get in 2.20 should either stay around or be fully upgradable using
convert-ly.  I am skeptical that we can really guarantee this for even
the current forced partcombine decisions yet.

I'm not getting half of the stuff done I want to.  And it *is* sort of
ridiculous that for every proposal regarding the part combiner I pull an
old issue out of the hat where I did not ultimately commit anything
because I was not really happy with it either.

But again: maybe I should just commit those and accept that we'll get
nowhere fast, and likely have interfaces in 2.20 that we cannot really
save or convert into 2.22.

https://codereview.appspot.com/144170043/

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

Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

On 2014/11/01 06:37:11, dak wrote:

I can rebase that patch if you want to see whether fitting a user

interface

there feels better.


Would you settle for my original approach of adding an internal argument
but not exposing any UI for it until after more thought is put into the
many interrelated issues that have been mentioned?

https://codereview.appspot.com/144170043/

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

Re: Happy 18th birthday, LilyPond

[Francisco Vila]

2014-11-01 11:43 GMT+01:00 David Kastrup :
> So it's more like 19 since July for (work on?) version 1.0.1 though our
> git history seems rather messed up.  Just out of interest: where did you
> get that 18-year number?

You guessed it: I used the most naïve method possible. I moved the
scroll bar in gitk (without --all) at the bottom and there it was:

commit 4f4ad24a3bfeb77cfd0ecca104319607bfd28a63
Author: Han-Wen Nienhuys 
Date:   Wed Oct 9 14:04:46 1996 +0100

Initial.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Issue 1321: Enhancement: add partcombineUp and partcombineDown functions (issue 13242056)

[dak]

https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly#newcode1168
ly/music-functions-init.ly:1168: #{ \partcombine \with { \voiceOne }
\with { \voiceOne } #part1
On 2014/11/01 15:26:57, Dan Eble wrote:

In one way, this is cleaner than what I currently have to do to modify
one/share/two context properties.  (That is refer to the voice

contexts in

parallel with \partcombine and set their properties.)  One thing I

like about

this is that I don't have to rely on the names of the voices that

\partcombine

creates.  One thing I don't like about it is that I'll have to consult

the

manual to check which context mods apply to "shared" and which apply

to all.  I

see nothing mnemonic about their position.


The end of the branch is actually another commit where the context mods
for first and second part are not part of the arguments.  Instead, you
use
\new Voice \with { ... } { ... }
to specify context mods that are only part of first and second part.
Then there is one optional context mod before the first part that counts
for all parts (in the most significant position), and one "shared"
before the first part (still awkward, yes) that's only active for shared
parts.

That commit is "work in progress", not yet finished.  It leaves a few
less things in the "I have to look the position up in the manual"
category.

Is that sufficient to be good?  I'm not sure.  It's really not easy to
come up with something that is flexible, extensible, and yet not "I have
to look this up constantly".


In short, this is nice, but not clearly better than the status quo,

unless there

is something I'm missing.


You are obviously not missing all too much since I did not get this
finished yet.  However, the main purpose would have been to make it easy
to add additional properties.


Stepping back, for the \partcombineUp use case, I think it would make

more sense

for the partcombiner to distribute the input notes into just two

voices instead

of three.  Rather than putting notes into Voices "one" and "shared"

that need to

be configured separately with the same context properties, just direct

all

top-part notes into "shared" and never into "one."  That also has a

chance of

making some things that would use or iterate over that voice work

better.

Lyrics come to mind, though NullVoice is a good workaround nowadays.

I *think*

it would improve the outcome of automatic beaming, but let me find an

example

before you assume that I know what I'm talking about.


So far this is an area where the current codebase is useful for a lot
less than what it _could_ be the workhorse for, and a significant part
of that shortcoming is a reasonably flexible and extensible user
interface that still is not arbitrary to a degree to require looking in
the manual all the time.

https://codereview.appspot.com/13242056/

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

Re: Issue 1321: Enhancement: add partcombineUp and partcombineDown functions (issue 13242056)

[nine . fierce . ballads]

On 2014/11/01 15:26:57, Dan Eble wrote:

I *think*
it would improve the outcome of automatic beaming, but let me find an

example

before you assume that I know what I'm talking about.


Here's an example that shows both how I override voice settings now and
what I mean about using only two voices for partcombineUp.  It would
benefit other cases too.  This example is from a song that I had to beam
manually to work around the current behavior.  (I know this is not
entirely relevant to this ticket, but everything related to the part
combiner seems to be very intertwined, doesn't it?)

\version "2.18.0"

% input to part combiner
soprano = \relative f' { \partial 4. f8 a c f4. }
alto = \relative f' { \partial 4. \partcombineApartOnce f8 f a a4. }

% proposed result of \partcombineUp
shared = \relative f' { \partial 4. f8   4. }
two = \relative f' { \partial 4. f8 s s s4. }

\markup "3-voice output (current)"
\score {
  \new Staff \with { printPartCombineTexts = ##f } <<

% Speaking as a user, this is ugly, but at least it is obvious
% which voice gets which settings.

\new Voice = "one" \with { \override NoteHead.color = #green } { }
\new Voice = "shared" \with { \override NoteHead.color = #red } { }
\new Voice = "two" \with { \override NoteHead.color = #blue } { }

\partcombineUp \soprano \alto
  >>
}

\markup "2-voice output (proposed)"
\score {
  \new Staff <<
\new Voice \with { \override NoteHead.color = #red \voiceOne }
\shared
\new Voice \with { \override NoteHead.color = #blue \voiceThree }
\two
  >>
}

https://codereview.appspot.com/13242056/

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

Re: Issue 1321: Enhancement: add partcombineUp and partcombineDown functions (issue 13242056)

[nine . fierce . ballads]

https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly#newcode1168
ly/music-functions-init.ly:1168: #{ \partcombine \with { \voiceOne }
\with { \voiceOne } #part1
In one way, this is cleaner than what I currently have to do to modify
one/share/two context properties.  (That is refer to the voice contexts
in parallel with \partcombine and set their properties.)  One thing I
like about this is that I don't have to rely on the names of the voices
that \partcombine creates.  One thing I don't like about it is that I'll
have to consult the manual to check which context mods apply to "shared"
and which apply to all.  I see nothing mnemonic about their position.

In short, this is nice, but not clearly better than the status quo,
unless there is something I'm missing.

Stepping back, for the \partcombineUp use case, I think it would make
more sense for the partcombiner to distribute the input notes into just
two voices instead of three.  Rather than putting notes into Voices
"one" and "shared" that need to be configured separately with the same
context properties, just direct all top-part notes into "shared" and
never into "one."  That also has a chance of making some things that
would use or iterate over that voice work better.  Lyrics come to mind,
though NullVoice is a good workaround nowadays.  I *think* it would
improve the outcome of automatic beaming, but let me find an example
before you assume that I know what I'm talking about.

https://codereview.appspot.com/13242056/

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

Re: Happy 18th birthday, LilyPond

[Pierre Perol-Schneider]

Happy brithday ! :)

2014-11-01 12:07 GMT+01:00 David Kastrup :


> Well, one gets the idea: this looks more like conception/pregnancy than
> the actual birth of LilyPond.  So maybe the Oct 1996 date is indeed the
> point to celebrate.
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Time signature markups

[Hans Aberg]

> On 1 Nov 2014, at 13:53, Dan Eble  wrote:
> 
> On Oct 29, 2014, at 13:01 , Hans Aberg  wrote:
>> 
>> On 26 Oct 2014, at 14:02, Trevor Daniels  wrote:
>>> 
>>> Dan Eble wrote Sunday, October 26, 2014 12:34 AM
>>> 
 time-signature.cc  has a comment at the top 
 saying, “This file should go; the formatting can completely be done with 
 markups.”  Can anyone point me to a good example of that, or is it a 
 unique idea?
>>> 
>>> Well, that comment was placed in the file by Han-Wen in Sep 2003, so doing 
>>> it doesn't seem excessively urgent.
>> 
>> One cannot have separate markups on clef, key and time signatures, because 
>> they end up at the same markup event time. So perhaps that calls for the 
>> opposite of the above mentioned file.
> 
> Please bear with my shallow knowledge of Lilypond.  I’m not sure what action 
> you suggest.

One might want to have markups using
  \mark \markup { "..." }
However, if tried simultaneously clef, key and time signatures, LilyPond will 
see they occur at the same time, and trash all but one. A similar problem 
appears if one wants markup both above and below the staff. There are snippets 
for workarounds, but they are not very convenient.

> Maybe because the comment is so old, there is a looser interpretation that is 
> still a good idea, like “this should be done in Scheme."
> 
> For example, I see that in define-grobs.scm, BarLine’s stencil property is 
> defaulted to ly:bar-line::print, which is defined in bar-line.scm.  On the 
> other hand, ly:time-signature::print is defined in C++.  Would I go wrong 
> trying to following BarLine?

I’m not sure what the comment means, but the markup system has some limitations 
- if you move it over to there, I worried it might cut on other markup 
possibilities.



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

Re: make doc, problem with bibtex

[Federico Bruni]

Il giorno sab 1 nov 2014 alle 12:18, David Kastrup  ha 
scritto:

 Probably not related, but some days ago I changed default TMPDIR
 (/tmp) to save some space on / partition:

 $ echo $TMPDIR
 /home/fede/.cache


It looks to me like .cache starts with a dot...


Ok, the easiest fix was changing TMPDIR to ~/tmp
Thanks
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  writes:

> How about this patch?
>
> --- librestrict/xstatconv.c.org   2014-10-19 09:52:52.951262300 +0900
> +++ librestrict/xstatconv.c   2014-11-01 20:26:35.734854500 +0900
> @@ -48,20 +48,16 @@
>{
>   struct stat *buf = ubuf;
>  
> + /* zero clear */
> + memset(buf, 0, sizeof(*buf));
>   /* Convert to current kernel version of `struct stat'.  */
>   buf->st_dev = kbuf->st_dev;

On the surface of it, this looks very reasonable.  However, since
everything is guarded with #ifdef and similar and the definitions are
probably generated by autoconf, it would appear that different versions
of stat.h are employed in the compilation and the resulting mismatch of
definitions and structures (possibly between host and target
definitions) could lead to crashes and memory corruption.

So it would seem like a good idea to first figure out what goes wrong
here before fixing it in this manner.  It might be a nice fix (and the
code certainly looks nicer for it) but I have no idea if it is correct.
The "if it were that easy, it would have been written like that in the
first place" mantra may be wrong surprisingly often, but it would still
be nice to make sure.

-- 
David Kastrup

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

Re: Time signature markups

[Dan Eble]

On Oct 29, 2014, at 13:01 , Hans Aberg  wrote:
> 
> On 26 Oct 2014, at 14:02, Trevor Daniels  wrote:
>> 
>> Dan Eble wrote Sunday, October 26, 2014 12:34 AM
>> 
>>> time-signature.cc  has a comment at the top 
>>> saying, “This file should go; the formatting can completely be done with 
>>> markups.”  Can anyone point me to a good example of that, or is it a unique 
>>> idea?
>> 
>> Well, that comment was placed in the file by Han-Wen in Sep 2003, so doing 
>> it doesn't seem excessively urgent.
> 
> One cannot have separate markups on clef, key and time signatures, because 
> they end up at the same markup event time. So perhaps that calls for the 
> opposite of the above mentioned file.

Please bear with my shallow knowledge of Lilypond.  I’m not sure what action 
you suggest.

Maybe because the comment is so old, there is a looser interpretation that is 
still a good idea, like “this should be done in Scheme."

For example, I see that in define-grobs.scm, BarLine’s stencil property is 
defaulted to ly:bar-line::print, which is defined in bar-line.scm.  On the 
other hand, ly:time-signature::print is defined in C++.  Would I go wrong 
trying to following BarLine?

Thanks,
— 
Dan


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

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

How about this patch?

--- librestrict/xstatconv.c.org 2014-10-19 09:52:52.951262300 +0900
+++ librestrict/xstatconv.c 2014-11-01 20:26:35.734854500 +0900
@@ -48,20 +48,16 @@
   {
struct stat *buf = ubuf;
 
+   /* zero clear */
+   memset(buf, 0, sizeof(*buf));
/* Convert to current kernel version of `struct stat'.  */
buf->st_dev = kbuf->st_dev;
-#ifdef _HAVE_STAT___PAD1
-   buf->__pad1 = 0;
-#endif
buf->st_ino = kbuf->st_ino;
buf->st_mode = kbuf->st_mode;
buf->st_nlink = kbuf->st_nlink;
buf->st_uid = kbuf->st_uid;
buf->st_gid = kbuf->st_gid;
buf->st_rdev = kbuf->st_rdev;
-#ifdef _HAVE_STAT___PAD2
-   buf->__pad2 = 0;
-#endif
buf->st_size = kbuf->st_size;
buf->st_blksize = kbuf->st_blksize;
buf->st_blocks = kbuf->st_blocks;
@@ -77,21 +73,6 @@
buf->st_mtime = kbuf->st_mtime;
buf->st_ctime = kbuf->st_ctime;
 #endif
-#ifdef _HAVE_STAT___UNUSED1
-   buf->__unused1 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED2
-   buf->__unused2 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED3
-   buf->__unused3 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED4
-   buf->__unused4 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED5
-   buf->__unused5 = 0;
-#endif
   }
   break;
 
@@ -116,11 +97,10 @@
   {
struct stat64 *buf = ubuf;
 
+   /* zero clear */
+   memset(buf, 0, sizeof(*buf));
/* Convert to current kernel version of `struct stat64'.  */
buf->st_dev = kbuf->st_dev;
-#ifdef _HAVE_STAT64___PAD1
-   buf->__pad1 = 0;
-#endif
buf->st_ino = kbuf->st_ino;
 #ifdef _HAVE_STAT64___ST_INO
buf->__st_ino = kbuf->st_ino;
@@ -130,9 +110,6 @@
buf->st_uid = kbuf->st_uid;
buf->st_gid = kbuf->st_gid;
buf->st_rdev = kbuf->st_rdev;
-#ifdef _HAVE_STAT64___PAD2
-   buf->__pad2 = 0;
-#endif
buf->st_size = kbuf->st_size;
buf->st_blksize = kbuf->st_blksize;
buf->st_blocks = kbuf->st_blocks;
@@ -148,21 +125,6 @@
buf->st_mtime = kbuf->st_mtime;
buf->st_ctime = kbuf->st_ctime;
 #endif
-#ifdef _HAVE_STAT64___UNUSED1
-   buf->__unused1 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED2
-   buf->__unused2 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED3
-   buf->__unused3 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED4
-   buf->__unused4 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED5
-   buf->__unused5 = 0;
-#endif
   }
   break;
 
@@ -185,12 +147,11 @@
 {
 case _STAT_VER_LINUX:
   {
+   /* zero clear */
+   memset(buf, 0, sizeof(*buf));
/* Convert current kernel version of `struct stat64' to
`struct stat'.  */
buf->st_dev = kbuf->st_dev;
-#ifdef _HAVE_STAT___PAD1
-   buf->__pad1 = 0;
-#endif
 #ifdef _HAVE_STAT64___ST_INO
 # if __ASSUME_ST_INO_64_BIT == 0
if (kbuf->st_ino == 0)
@@ -220,9 +181,6 @@
buf->st_uid = kbuf->st_uid;
buf->st_gid = kbuf->st_gid;
buf->st_rdev = kbuf->st_rdev;
-#ifdef _HAVE_STAT___PAD2
-   buf->__pad2 = 0;
-#endif
buf->st_size = kbuf->st_size;
/* Check for overflow.  */
if (sizeof (buf->st_size) != sizeof (kbuf->st_size)
@@ -253,21 +211,6 @@
buf->st_ctime = kbuf->st_ctime;
 #endif
 
-#ifdef _HAVE_STAT___UNUSED1
-   buf->__unused1 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED2
-   buf->__unused2 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED3
-   buf->__unused3 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED4
-   buf->__unused4 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED5
-   buf->__unused5 = 0;
-#endif
   }
   break;
 


> I get:
> 
> ~/gub/target/tools/build/librestrict-1.9.a$ gcc -W -Wall
> -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so
> restrict-stat.c
> In file included from restrict-stat.c:106:0:
> ./xstatconv.c: In function ‘__xstat_conv’:
> ./xstatconv.c:90:5: error: ‘struct stat’ has no member named
> ‘__unused4’
> buf->__unused4 = 0;
> ^
> ./xstatconv.c:93:5: error: ‘struct stat’ has no member named
> ‘__unused5’
> buf->__unused5 = 0;
> ^
> ./xstatconv.c: In function ‘__xstat32_conv’:
> ./xstatconv.c:266:5: error: ‘struct stat’ has no member named
> ‘__unused4’
> buf->__unused4 = 0;
> ^
> ./xstatconv.c:269:5: error: ‘struct stat’ has no member named
> ‘__unused5’
> buf->__unused5 = 0;
> ^
> 
> 
> --
> Phil Holmes
> 
> 
> - Original Message - 
> From: "Jan Nieuwenhuizen" 
> To: "Phil Holmes" 
> Cc: "David Kastrup" ; "Federico Bruni"
> ; 
> Sent: Tuesday, October 28, 2014 12:58 PM
> Subject: Re: GUB and mpfr/mpc
> 
> 
> Phil Holmes writes:
> 
> If there's nothing in the log file, you'll have to investigate by
> hand.
> Go to the build directory and see
> 
>cd /home/gub/gub/target/tools/build/librestrict-1.9.a
>gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
>librestrict-stat.so restrict-stat.c
> 
> (eg, doing gcc -vvv or cpp -E or somesuch) why it fails to compile.
> It's a simple c file wit

Re: make doc, problem with bibtex

[David Kastrup]

Federico Bruni  writes:

> 'make doc' is returning the error below, can you help me?
>
> make[2]: Entering directory '/home/fede/lilypond-git/Documentation'
> BSTINPUTS=./essay /home/fede/lilypond-git/scripts/build/out/bib2texi \
> -s /home/fede/lilypond-git/Documentation/lily-bib \
> -o ./out-www/colorado.itexi \
> -q \
> ./essay/colorado.bib
>
> bibtex: Not writing to /home/fede/.cache/tmpzYBXQHbib2texi.blg
> (openout_any = p).

  9. TeX can write output files, via the '\openout' primitive; this
 opens a security hole vulnerable to Trojan horse attack: an
 unwitting user could run a TeX program that overwrites, say,
 '~/.rhosts'.  Analogous security holes exist for many other
 programs.  To alleviate this, there is a configuration variable
 'openout_any', which selects one of three levels of security.  When
 it is set to 'a' (for "any"), no restrictions are imposed.  When it
 is set to 'r' (for "restricted"), filenames beginning with '.' are
 disallowed (except '.tex' because LaTeX needs it).  When it is set
 to 'p' (for "paranoid") additional restrictions are imposed: an
 absolute filename must refer to a file in (a subdirectory) of
 'TEXMFOUTPUT', and any attempt to go up a directory level is
 forbidden (that is, paths may not contain a '..' component).  The
 paranoid setting is the default.  (For backwards compatibility, 'y'
 and '1' are synonyms of 'a', while 'n' and '0' are synonyms for
 'r'.)  The function 'kpathsea_out_name_ok', with a filename as
 second argument, returns 'true' if that filename is acceptable to
 be opend for output or 'false' otherwise.

> Probably not related, but some days ago I changed default TMPDIR
> (/tmp) to save some space on / partition:
>
> $ echo $TMPDIR
> /home/fede/.cache

It looks to me like .cache starts with a dot...

-- 
David Kastrup

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

Re: Happy 18th birthday, LilyPond

[David Kastrup]

Federico Bruni  writes:

> Il giorno sab 1 nov 2014 alle 11:43, David Kastrup  ha
> scritto:
>> So it's more like 19 since July for (work on?) version 1.0.1 though
>> our
>> git history seems rather messed up.  Just out of interest: where did
>> you
>> get that 18-year number?
>
> probably he didn't use the --all
>
> $ git log --date-order --reverse
> commit 4f4ad24a3bfeb77cfd0ecca104319607bfd28a63
> Author: Han-Wen Nienhuys 
> Date: Wed Oct 9 14:04:46 1996 +0100
>
>Initial.
>
> commit 675bd3e6ea001c3af033b51a6e2eeab6a5809e86
> Author: Han-Wen Nienhuys 
> Date: Wed Oct 9 14:04:47 1996 +0200
>
>release: 0.0.1
>
> commit 727cdcbadf23c1986b0aed547aa645c9813f351b
> Author: Han-Wen Nienhuys 
> Date: Tue Oct 22 22:09:43 1996 +0200
>
>release: 0.0.2

So according to our Git history, lilypond-1.0.1 is on record more than a
year before 0.0.1.

That's – interesting.

More interesting is to add --source.  That would indicate that the early
commits are reachable through refs/tags/release/1.7.25:

commit c4823afaaa48ef634ed9a2f6ce0441c1c0f894d2
Merge: af31352 4b2ad63
Author: janneke 
Date:   Fri Jul 18 00:04:55 2003 +

This commit was manufactured by cvs2svn to create tag 'lilypond_1_7_25'.

Now why is that commit/branch not in our normal history?

What _is_ this history?

git log --stat --all --date-order --reverse --source |head -400 >/tmp/hist

commit 0ff96d5d41379dbb968507fd848642da518dc50b refs/tags/release/1.7.25
Author: fred 
Date:   Tue Jul 18 00:23:16 1995 +

lilypond-1.0.1

 intl/gettext.h | 105 +
 1 file changed, 105 insertions(+)

commit 93d1d90d4645fc0f64ae310e0df224f00228ee78 refs/tags/release/1.7.25
Author: fred 
Date:   Thu Sep 21 11:20:44 1995 +

lilypond-1.0.1

 intl/intl-compat.c | 76 ++
 1 file changed, 76 insertions(+)

commit c369b62fc955f44df7464709d9b8ccd6eaf5b112 refs/tags/release/1.7.25
Author: fred 
Date:   Wed Sep 27 00:42:09 1995 +

lilypond-1.0.1

 intl/dgettext.c | 59 +
 1 file changed, 59 insertions(+)

commit f3e3a164f40ca6f48261a23c7d4f8036ba9c8e79 refs/tags/release/1.7.25
Author: fred 
Date:   Wed Sep 27 00:55:11 1995 +

lilypond-1.0.1

 intl/textdomain.c | 97 +++
 1 file changed, 97 insertions(+)

commit 269f694c15d9d7eee4d6a9cb74ad3b46a29a0555 refs/tags/release/1.7.25
Author: fred 
Date:   Wed Sep 27 20:14:38 1995 +

lilypond-1.0.1

 intl/bindtextdom.c | 172 +
 1 file changed, 172 insertions(+)

commit b1a9a734bf98c6dd15f84d7ec9541c71bd92a34c refs/tags/release/1.7.25
Author: fred 
Date:   Thu Nov 2 17:40:31 1995 +

lilypond-1.0.1

 intl/gettext.c | 70 ++
 1 file changed, 70 insertions(+)

commit 3934c1ff38595198aa8f6dea24b5794e035e5fa5 refs/tags/release/1.7.25
Author: fred 
Date:   Sun Nov 5 12:24:30 1995 +

lilypond-1.0.1

 intl/loadmsgcat.c | 191 ++
 1 file changed, 191 insertions(+)

commit 11d3a2fd4403b3f6b9c927df4ff75c69d2b49d6c refs/tags/release/1.7.25
Author: fred 
Date:   Tue Nov 7 14:21:04 1995 +

lilypond-1.0.1

 intl/finddomain.c | 503 ++
 1 file changed, 503 insertions(+)

commit c41f9e6a811fcaf2a0a27d41146b72f42e536738 refs/tags/release/1.7.25
Author: fred 
Date:   Sun Nov 12 12:41:39 1995 +

lilypond-1.0.1

 intl/gettextP.h | 79 +
 1 file changed, 79 insertions(+)

commit 6307b0b9806d4acabb4def1090d02c1fa118b143 refs/tags/release/1.7.25
Author: fred 
Date:   Mon Nov 20 16:20:57 1995 +

lilypond-1.0.1

 intl/localealias.c | 317 +
 1 file changed, 317 insertions(+)

commit dcaf504442744419880660b2a1102bdcd9d63fb4 refs/tags/release/1.7.25
Author: fred 
Date:   Thu Nov 23 01:45:24 1995 +

lilypond-1.0.1

 intl/linux-msg.sed | 100 +++
 intl/po2tbl.sed.in | 102 
 intl/xopen-msg.sed | 104 +
 3 files changed, 306 insertions(+)

commit 56d2b082a3ff1d62bd6d339c2f4a57a7489cf4ea refs/tags/release/1.7.25
Author: fred 
Date:   Sat Nov 25 02:34:41 1995 +

lilypond-1.0.1

 intl/libgettext.h | 177 ++
 1 file changed, 177 insertions(+)

commit e0e03f14a6182005211c27c977c0fd33cb6c30be refs/tags/release/1.7.25
Author: fred 
Date:   Sat Nov 25 11:30:40 1995 +

lilypond-1.0.1

 intl/dcgettext.c | 522 +++
 1 file changed, 522 insertions(+)

commit ee940257d9d4adc36868ba83243ab20f91e84b34 refs/

make doc, problem with bibtex

[Federico Bruni]

'make doc' is returning the error below, can you help me?

make[2]: Entering directory '/home/fede/lilypond-git/Documentation'
BSTINPUTS=./essay /home/fede/lilypond-git/scripts/build/out/bib2texi \
-s /home/fede/lilypond-git/Documentation/lily-bib \
-o ./out-www/colorado.itexi \
-q \
./essay/colorado.bib

bibtex: Not writing to /home/fede/.cache/tmpzYBXQHbib2texi.blg 
(openout_any = p).

I couldn't open file name `/home/fede/.cache/tmpzYBXQHbib2texi.blg'
Bibtex exited with nonzero exit status!GNUmakefile:118: recipe for 
target 'out-www/colorado.itexi' failed

make[2]: *** [out-www/colorado.itexi] Error 1
make[2]: Leaving directory '/home/fede/lilypond-git/Documentation'
/home/fede/lilypond-git/stepmake/stepmake/generic-targets.make:166: 
recipe for target 'WWW-1' failed

make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory '/home/fede/lilypond-git'
/home/fede/lilypond-git/stepmake/stepmake/generic-targets.make:182: 
recipe for target 'doc-stage-1' failed

make: *** [doc-stage-1] Error 2

fede@laptop:~/lilypond-git$ ls ../.cache/tmpzYBXQHbib2texi
tmpzYBXQHbib2texi tmpzYBXQHbib2texi.aux

.blg file is not there.


$ apt-cache policy texlive-bibtex-extra | grep Installed
 Installed: 2014.20141024-1

Probably not related, but some days ago I changed default TMPDIR (/tmp) 
to save some space on / partition:


$ echo $TMPDIR
/home/fede/.cache



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

Re: Happy 18th birthday, LilyPond

[Federico Bruni]

Il giorno sab 1 nov 2014 alle 11:43, David Kastrup  ha 
scritto:
So it's more like 19 since July for (work on?) version 1.0.1 though 
our
git history seems rather messed up.  Just out of interest: where did 
you

get that 18-year number?


probably he didn't use the --all

$ git log --date-order --reverse
commit 4f4ad24a3bfeb77cfd0ecca104319607bfd28a63
Author: Han-Wen Nienhuys 
Date: Wed Oct 9 14:04:46 1996 +0100

   Initial.

commit 675bd3e6ea001c3af033b51a6e2eeab6a5809e86
Author: Han-Wen Nienhuys 
Date: Wed Oct 9 14:04:47 1996 +0200

   release: 0.0.1

commit 727cdcbadf23c1986b0aed547aa645c9813f351b
Author: Han-Wen Nienhuys 
Date: Tue Oct 22 22:09:43 1996 +0200

   release: 0.0.2


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

Re: Happy 18th birthday, LilyPond

[David Kastrup]

Francisco Vila  writes:

> Sorry for the cross-posting. Just a short note to say LIlyPond is 18
> since october if our git history is true.
>
> Congrats to all for using/developing/maintaining/enjoying this great
> piece of software.

git log --all --date-order --reverse

starts with the following here:

commit 0ff96d5d41379dbb968507fd848642da518dc50b
Author: fred 
Date:   Tue Jul 18 00:23:16 1995 +

lilypond-1.0.1

commit 93d1d90d4645fc0f64ae310e0df224f00228ee78
Author: fred 
Date:   Thu Sep 21 11:20:44 1995 +

lilypond-1.0.1

commit c369b62fc955f44df7464709d9b8ccd6eaf5b112
Author: fred 
Date:   Wed Sep 27 00:42:09 1995 +

lilypond-1.0.1

commit f3e3a164f40ca6f48261a23c7d4f8036ba9c8e79
Author: fred 
Date:   Wed Sep 27 00:55:11 1995 +

lilypond-1.0.1

commit 269f694c15d9d7eee4d6a9cb74ad3b46a29a0555
Author: fred 
Date:   Wed Sep 27 20:14:38 1995 +

lilypond-1.0.1


So it's more like 19 since July for (work on?) version 1.0.1 though our
git history seems rather messed up.  Just out of interest: where did you
get that 18-year number?

-- 
David Kastrup

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

Happy 18th birthday, LilyPond

[Francisco Vila]

Sorry for the cross-posting. Just a short note to say LIlyPond is 18
since october if our git history is true.

Congrats to all for using/developing/maintaining/enjoying this great
piece of software.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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