Re: 5th anniversary conference? :)

[Mike Blackstock]

re "Let’s keep this discussion going... I teach in the Annex (Randolph
College) three times a week — we should grab lunch/tea/pints some day.  "

For sure... I live at Bloor/Albany, just a few minutes walk from Randolph;
I walk past Randolph
all the time but didn't know it was a college. Right next door is the
Centre for Social Innovation,
which I've played at a few times for Amnesty International's annual
get-together there.

I propose  a get-together at the Annex Billiards Club, just above the Bulk
Barn on Bloor... cheap pints, good
billiards tables, nice atmosphere. I live 2 minutes away... I can be there
on a moment's notice, starting next week.

This is exciting!

On Fri, 23 Feb 2024 at 07:48, Kieren MacMillan 
wrote:

> Hi Mike!
>
> > I live in Toronto, in the Annex.  I'd love to help organize something
> here if there's interest. I'm right
> > close to the  University of Toronto campus.
>
> 1. Let’s keep this discussion going, and see if it actually gains traction!
>
> 2. I teach in the Annex (Randolph College) three times a week — we should
> grab lunch/tea/pints some day.  :)
>
> Cheers,
> Kieren.
> __
>
> My work day may look different than your work day. Please do not feel
> obligated to read or respond to this email outside of your normal working
> hours.
>
>

-- 
https://blackstock.media

Re: 5th anniversary conference? :)

[Mike Blackstock]

re. possible toronto conference location

I live in Toronto, in the Annex.  I'd love to help organize something here
if there's interest. I'm right
close to the  University of Toronto campus.

-Mike

On Thu, 15 Feb 2024 at 09:19, Kieren MacMillan 
wrote:

> Hey all,
>
> >> I was just waxing nostalgic about that fabulous Salzburg conference in
> 2020, and noted that in Jan 2025 — just under a year from now! — it will
> have been five years since we got together, talked music/notation, and
> raised [more than] a few pints together.
> >> Any chance for a repeat? :)
> >
> > Would be great. Count me as "will try to come if it gets organized".
>
> As I said back then, I’d be more than happy to organize a conference here
> in Toronto… but we decided that too many people would have to travel this
> direction over the Atlantic. It really does seem to be most efficient to
> hold this kind of gathering in Europe somewhere.
>
> Cheers,
> Kieren
> __
>
> My work day may look different than your work day. Please do not feel
> obligated to read or respond to this email outside of your normal working
> hours.
>
>
>

-- 
https://blackstock.media

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

On 2020/02/05 18:17:25, c_sorensen wrote:
> I recognize that Mike Solomon has a different opinion.  I mean no
disrespect to
> Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I
highly value
> the team spirit of the LilyPond team.

>Well said.  Here's the current tally as I understand it:
>For: Han-Wen, Janek, Mike, Urs, Werner
>Against: Carl, Dan, David K., Trevor
>Mixed: David N.

Mike, you asked,
> What are the blockers to making a decision about this patch?
> Does it need more discussion or more buy in?

>5-4 halfway through the first day doesn't look like buy-in to me.

That's a really good point and I see where Carl and David N are coming from. It 
seems like a Code of Conduct is not a good fit at this time. More people in the 
community would need to come around to the idea for it to work.

Maybe what I'll do is touch base in a few months and see if any opinions have 
changed, including of course my own. In the meantime, I would encourage people 
to reflect on LilyPond's shrinking number of contributions and developers and 
consider if a lack of a code of conduct could be one of the reasons it is 
difficult to grow. As a benchmark, one good place to look is the Contributors 
Covenant website. There is a list of communities that have implemented it. Ask 
the maintainers how they feel about it, cite the concerns brought up here, and 
ask if they feel it could, from their outsider perspective, be helpful for 
LilyPond. I know that, personally, I have really appreciated the code of 
conduct in projects that I have contributed to since leaving LilyPond 
development. I have also appreciated the relative ideological and demographic 
diversity of those projects, which has introduced me to perspectives about race 
and gender that are lacking in the LilyPond community.

It could of course also be the case that people are happy with the status quo 
in LilyPond, in which case it (or other things to grow the community in size 
and inclusivity) are not necessary. I personally am saddened by my own leaving, 
the leaving of others, the lack of growth and the lack of diversity, and this 
is one proposal to start changing it, but I understand the objections.

~Mike

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Mike Solomon  writes:

>> What does "implement" mean?
>
> Sorry, I wasn't clear. I meant merge the PR.

> Uh, words have meanings.  There would be no point of putting something
into our documentation that we are not going to follow through with.

By merging it, the idea would be that the first committee of 3 started acting 
as a CoC committee.

What are the blockers to making a decision about this patch? Does it need more 
discussion or more buy in? As I've been out of the community for so long, I no 
longer have a sense of when things are merged.

~Mike

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

> What does "implement" mean?

Sorry, I wasn't clear. I meant merge the PR.

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

One procedural question: what are acceptance procedures for a PR like this? 
There is good debate and a variety of opinions, but at a certain point we will 
need to make a decision - do we implement the CoC or not? I doubt that any new 
arguments will emerge on either side.  David has made several good arguments 
against it, and while the points are valid, they don't outweigh IMO the 
potential for it to improve the problem of low contribution volume and a 
shrinking pool of developers. I'm also admittedly biased in that I don't feel 
comfortable contributing unless there is a code of conduct with clear steps for 
reporting violations and consequences for repeat offenders, so I'm probably not 
the best person to make the final call.

~Mike

RE: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Mike Solomon  writes:

> The preamble and intent is one thing; adding a corrective committee with the 
> authority to enact punishments based on anonymous reports is another.  It 
> implements hierarchies and institutions exerting coercive power based on 
> incomplete and secret information.  That is inherently an entity offering an 
> opportunity for "pulling strings".  I am not really a fan of constructs with 
> a life and dynamics of their own.

It's a big responsibility. I think the way to do it is talk to successful 
committees (ie the Facebook Open Source CoC Committee) and learn how they've 
dealt with challenging situations.

One example: in communities that are more gender balanced, I've heard of 
situations where a man starts writing inappropriate messages to a woman and she 
reports the messages to the CoC committee.  In this case, I think secrecy, 
hierarchy and coercive decision making power is important to preserve the 
dignity of all parties.  It also encourages people to come forward, which is 
much harder to do in the open.

I don't know of many communities with good gender balance that don’t have codes 
of conduct, probably for this reason.  Ultimately, I think the benefits of 
secrecy, hierarchy and possible coercion in matters of conduct outweigh the 
negatives, although I agree with you that secrecy and hierarchy should be the 
exception and not the rule. Most communication should be in the open and 
hierarchy free.

Thanks,
~Mike

RE: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Janek Warchoł  writes:

> Hi,
>
> śr., 5 lut 2020, 00:34 użytkownik  napisał:
>
>> What problem are we trying to solve here?
>>
>
> In short, it's been found (I think Mike will be able to give you 
> specific
> examples) that having code of conduct encourages contributions from 
> newcomers.

> I rather think that a friendly atmosphere encourages contributions from 
> newcomers.  Whether an upfront requirement to commit to a set of rules with 
> an enforcement team is perceived as a guarantee of a friendly atmosphere is 
> debatable.

I personally would feel more comfortable if there were a code of conduct, and I 
know within my company one employee will not attend a conference or participate 
in a project unless there is a code of conduct.  I don't have any hard stats to 
prove this, but have a gut feeling that a code of conduct opens more doors than 
it closes.

> So in light of my personal experiences with this kind of backroom channel 
> (and it's worth noting that even the cited Linux developer list removed the 
> corrective measures part from the CoC they are using), I would very much like 
> to see some more imminent reason of why LilyPond would stand to benefit from 
> adopting a code and accepting a corrective committee that has basically 
> proposed itself rather than being the result of a list-wide election and 
> where just one member has been a permanent fixture on the lists for a longer 
> amount of time at this moment.

A list-wide election is a good idea.

At the Salzburg meetup, one common thing a lot of people brought up was a 
slow-down in development and a shrinking pool of contributors.  IMO we should 
do several experiments to fix this. The CoC I proposed is used in over 40,000 
projects including many of the most active and diverse open source projects on 
github, so it seems like a reasonable experiment. If it proves to be a dud, we 
can get rid of it.

~Mike

Re: Stepping down and moving on

[Mike Solomon]

+1 many times over.
Thank you for your excellent, creative, and vital work in helping LilyPond 
become the world’s best and most stable digital music engraver.

Best of luck!
~Mike


On 10 November 2016 at 13.23.24, Kieren MacMillan 
(kieren_macmil...@sympatico.ca) wrote:

Dear David,

Congratulations on the new position! I hope it brings you great personal 
satisfaction and financial security.

Your programming and code-shepherding efforts in the ‘Pond have been nearly 
miraculous, and the codebase is immeasurably better for you having been on the 
team. Thank you so much for everything you did to make Lilypond better for 
everyone, users and developers alike.

Sincerely,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: GSoC 2016 - GNU website listing

[Mike Solomon]

Hey!
Late to the party - I unfortunately cannot do mentoring this summer. However, 
all of the issues on the current website are still valid and I'd love to see 
someone work on them!
All the best,~Mike


Sent from my Samsung Galaxy smartphone. Original message From: 
Urs Liska  Date: 27/01/2016  10:12 PM  (GMT+02:00) To: 
lilypond-devel@gnu.org Subject: Re: GSoC 2016 - GNU website listing 


Am 27.01.2016 um 21:02 schrieb Paul Morris:
> So students can find us as one of the GNU projects, we should get LilyPond 
> listed on the GNU GSoC suggestions page.  Here’s the one for last summer:  
> http://www.gnu.org/software/soc-projects/ideas-2015.html
>
> Seems we should just have a listing like those that point to external 
> webpages, like this:
>
> LilyPond maintains their list of ideas for GSOC in an external webpage: 
> http://lilypond.org/google-summer-of-code.html 
> <http://lilypond.org/google-summer-of-code.html>
>
>
> Possibly we could add a description like this (from the 2012 GNU GSoC page):
>
> LilyPond is a music engraving program, devoted to producing the 
> highest-quality sheet music possible. It is somewhat similar to TeX — the 
> user describes the music using a high level description input, which is 
> processed with LilyPond to produce a pdf file. Languages used: mostly C++, 
> Scheme and Python.  
>
> -Paul

Agreed.
So how would one have to proceed here? Who is responsible for compiling
that page for 2016? And who from us should best approach that person/team?

Urs

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


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

Re: Beginning contributor needs mentor

[Mike Solomon]

I'll scour the tracker - there is a bit of low hanging fruit in the beautifying 
department that is nice because it will not be too sprawling and will result in 
immediately perceptible visual improvements.
~Mike

Sent from my Samsung device

 Original message 
From: John Gourlay  
Date: 10/11/2015  10:47 PM  (GMT+02:00) 
To: Mike Solomon  
Cc: lilypond-devel@gnu.org 
Subject: Re: Beginning contributor needs mentor 

Mike,

Yes, I am the spacing-a-line-of-music John Gourlay, pleased that my early 
contributions have turned out to be useful. I’ve been out of the loop for about 
30 years, however, so it won’t happen that I’ll be doing any mentoring myself 
for some time. Indeed I’ve been working in Windows for the past 20 years or so, 
usually very close to the machine, helping in the development of real-time 
software for testing engines and transmissions used by the big auto 
manufacturers at the ends of their assembly lines. Only now that I’ve retired 
from that job do I feel like I have time to give back to the open-source 
community. I only learned about LilyPond about two years ago from Daniel 
Spreadbury who tracked me down hoping to get some of the unpublished MusiCopy 
reports. (Of course I can make them available to you, too, if you like.) He was 
working for Steinberg in England on a new music scoring application and wanted 
to use some of the ideas from the MusiCopy project. As we conversed he pointed 
out that the ideas are already in use in a number of music formatting systems 
including LilyPond. Unfortunately I’ve never heard that the Steinberg product 
was released. 

So, where do I go from here? If you have a narrow, low-priority bug or new 
feature for me to work on it could help me focus my attention. I certainly need 
to spend more time with the Contributor’s Guide; the messages on lilypond-devel 
are mostly inscrutable to me, and I don’t know anything yet about the tools 
used to track bugs, fixes, reviews, and releases. Separately, I feel like I 
ought to learn more about using LilyPond so that I can better understand new 
feature requests and judge whether or not a fix is appropriate. Regardless, 
I’ll take whatever suggestions you’d like to make to help me get started.

John

> On Nov 10, 2015, at 10:53 AM, Mike Solomon  wrote:
> 
> Wait wait wait, are you THE John Gourlay?
> As in "Spacing a Line of Music" 1987 John Gourlay? If so, you should be 
> mentoring us, not the other way around! I think I've cited you in every paper 
> I've ever written about notation.
> 
> I'd love to help you get started. It is your algorithm at the heart of 
> LilyPond's horizontal spacing engine, so that can be a place to start if 
> you're up for it!
> 
> Cheers,
> ~Mike
> 
> PS If you're not the John Gourlay of which I speak, my offer for help still 
> stands!
> 
> 
> 
> Sent from my Samsung device
> 
> 
>  Original message 
> From: John Gourlay  
> Date: 10/11/2015 5:36 PM (GMT+02:00) 
> To: lilypond-devel@gnu.org 
> Subject: Beginning contributor needs mentor 
> 
> I’m an aspiring LilyPond contributor who needs a mentor. How can I get one?
> 
> So far I can compile LilyDev itself and the documentation, and I’m becoming 
> familiar with git. I’m looking at the LilyPond Contributor’s Guide, but I 
> have to admit that it’s a bit overwhelming. I’m a recently retired software 
> engineer highly experienced with C++, less with Unix and open-source 
> development, and not at all with Scheme. I’m not a musician, and I’ve used 
> LilyPond only for toy examples so far. However, I once knew a lot about using 
> computers to engrave music, as I was the principal investigator for the 
> MusiCopy Project at Ohio State University in the 1980s. I’m sure that much 
> has changed since then, but I’m pleased to say that LilyDev looks to be very 
> much like what MusiCopy might have been if we’d had an opportunity to 
> complete it. I’d like to help further the LilyPond project in some way.
> 
> John Gourlay
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

RE: Beginning contributor needs mentor

[Mike Solomon]

Wait wait wait, are you THE John Gourlay?As in "Spacing a Line of Music" 1987 
John Gourlay? If so, you should be mentoring us, not the other way around! I 
think I've cited you in every paper I've ever written about notation.
I'd love to help you get started. It is your algorithm at the heart of 
LilyPond's horizontal spacing engine, so that can be a place to start if you're 
up for it!
Cheers,~Mike
PS If you're not the John Gourlay of which I speak, my offer for help still 
stands!


Sent from my Samsung device

 Original message 
From: John Gourlay  
Date: 10/11/2015  5:36 PM  (GMT+02:00) 
To: lilypond-devel@gnu.org 
Subject: Beginning contributor needs mentor 

I’m an aspiring LilyPond contributor who needs a mentor. How can I get one?

So far I can compile LilyDev itself and the documentation, and I’m becoming 
familiar with git. I’m looking at the LilyPond Contributor’s Guide, but I have 
to admit that it’s a bit overwhelming. I’m a recently retired software engineer 
highly experienced with C++, less with Unix and open-source development, and 
not at all with Scheme. I’m not a musician, and I’ve used LilyPond only for toy 
examples so far. However, I once knew a lot about using computers to engrave 
music, as I was the principal investigator for the MusiCopy Project at Ohio 
State University in the 1980s. I’m sure that much has changed since then, but 
I’m pleased to say that LilyDev looks to be very much like what MusiCopy might 
have been if we’d had an opportunity to complete it. I’d like to help further 
the LilyPond project in some way.

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

Re: Anybody invested in ly:make-simple-closure?

[Mike Solomon]

> On 24 Sep 2015, at 13:18, David Kastrup  wrote:
> 
> Han-Wen Nienhuys  writes:
> 
>> IIRC, it was introduced to compose offset callbacks,
> 
> Oh, it's still being used for that as far as I can tell.  Just not from
> Scheme.

I think before lambdas were widely used they made lots of sense.  I used to 
like these because they were easier (for me) to debug than lambda functions, 
where all heck could break loose on the inside.  But it is true that they are 
not used much anymore.  I’d vote for depreciating them.

The pure/unpure stuff has definitely needed reorganising for almost 9 years now 
- there must be a better way to do it.

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

Re: pure/impure?!?!

[Mike Solomon]

> On 24 May 2015, at 11:55, David Kastrup  wrote:
> 
> 
> Well, the current setup is too contorted to be maintainable and safely
> extensible.  Whenever somebody tries to improve spacing or cross-staff
> or whatever somewhere, we get a series of exploding things until stuff
> settles down again.  Basically, the inherent complexity of the task is
> spread too thin across the code.  It needs to get consolidated into one
> place if we want to get to a point where people specializing in
> typography rather than low-level code tweakery and debugging can hope to
> improve LilyPond's aesthetics.
> 
> Anyway: how do impure functions reference (and trigger?) line breaks?


Unpure functions don’t trigger line breaking. Line breaking is triggered in 
system.cc <http://system.cc/> and then unpure functions are called after that.
The difference between the two function categories are when they are used: pure 
is used during the preprocessing stage and unpure after line breaking.

There is definitely a lot of work that can be done to consolidate these 
decisions, like you’re saying: it’s been slowly spread across the code base for 
10ish years.
The complexity of the task is high, thought - it’d require a major rewrite of a 
lot of things.

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

Re: pure/impure?!?!

[Mike Solomon]

On 21 May 2015, at 11:01, David Kastrup  wrote:
> 
> 
> In the CG I read
> 
>For certain grobs, the @code{Y-extent} is based on the @code{stencil}
>property, overriding the stencil property of one of these will
>require an additional @code{Y-extent} override with an unpure-pure
>container.  When a function overrides a @code{Y-offset} and/or
>@code{Y-extent} it is assumed that this will trigger line breaking
>calculations too early during compilation.  So the function is not
>evaluated at all (usually returning a value of @samp{0} or
>@samp{'(0 . 0)}) which can result in collisions.  A @q{pure} function
>will not affect properties, objects or grob suicides and therefore will
>always have its Y-axis-related evaluated correctly.
> 
>Currently, there are about thirty functions that are already considered
>@q{pure} and Unpure-pure containers are a way to set functions not on
>this list as @q{pure}.  The @q{pure} function is evaluated @emph{before}
>any line-breaking and so the horizontal spacing can be adjusted
>@q{in time}.  The @q{unpure} function is then evaluated @emph{after}
>line breaking.
> 
> This is all very nice.  Except that it is the function calls labelled as
> *pure* that actually receive start/end values indicating particular
> breakpoints of the system that the respective grob is in.  What's the
> deal with that?

I’d have to dive back into it to remember correctly, but I’m pretty sure that 
these values are ignored.

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

Re: Added recorder diagram (issue 153380043 by pkx1...@gmail.com)

[Mike Solomon]

> On Nov 2, 2014, at 10:58 PM, pkx1...@gmail.com wrote:
> 
> i don't know scheme, so i was mainly pattern-matching from existing
> diagrams.  some issues i had while trying to figure this out:
> 
> - what is the purpose of the baked-in cc/lh/rh grouping?
> 

This was a feature of the original design based on the woodwind instruments I 
needed to implement at the time.
All of the woodwind instruments I have ever written for or studied have this as 
a feature.

> - i can't find doc for draw-instructions rules -- seems to determine
> whether keys are hidden unless specified -- i didn't want that
> behavior, but was stuck unexpectedly getting it for a while.
> 

That’s my fault - it was a late add-on that I still need to document.  I will 
propose a patch for documentation as soon as I get LilyDev running on OS X 
Yosemite.
Try something to the effect of:

(draw-instructions
  . ((,group-automate-rule
  ,(make-central-column-hole-addresses 
CENTRAL-COLUMN-HOLE-LIST

> - difference between identity and return-1 -- they sound identical to
> me (when xy-scaling), but gave different results.
> 

Identity returns the value passed in

(identity 3)
3

return-1 returns 1

(return-1 3)
1.0

> - the style used encourages a lot of duplicated code -- it needs to be
> refactored so that keys are defined as simple declarative structures
> (with properties like name, group, position, complexity, stencil,
> textual-representation) and graphical/textual-commands derived
> therefrom.
> 

Currently, there is a declarative structure used to define all keys.  The 
structure has properties like offset, stencil, text?, and complexity.
There is a lot of data, but I don’t see that much duplicated code.
Of course, I am for refactoring as much as possible - do you have a proposal 
for where that’d be useful?

> - similarly, key positions should be described in relative terms --
> most stuff is absolute w/brittle hardcoding.

What would the keys be relative to?  Currently, there is the possibility to do 
one absolute offset (in an offset property).  I think that the relative idea is 
interesting - perhaps the possibility to create groups of keys and to offset 
the groups?  Were this to be the case, it’d be important to consult with 
practitioners to make sure that the groups had anatomical sense with respect to 
the way the instrument is visualized in their mind’s eye.

> 
> - explicit support for when there is no text-override (key name
> instead of graphical stencil) available.  i tripped across a
> previously reported bug that doesn't seem to have made it to the issue
> list even though it's a crash:
> (http://lists.gnu.org/archive/html/lilypond-user/2014-09/msg00405.html):
> 
>  c^
>  \markup \override #'(graphical . #f) {
>  \woodwind-diagram
>#'tin-whistle
>#'()
>  }
> 
> C:/Program Files
> (x86)/LilyPond/usr/share/lilypond/current/scm/display-woodwind-
> diagrams.scm:1977:20: In procedure = in expression (= 0 (assoc-get node
> draw-ins
> tructions)):
> C:/Program Files
> (x86)/LilyPond/usr/share/lilypond/current/scm/display-woodwind-
> diagrams.scm:1977:20: Wrong type: #f
> 
> also broken for saxophone (a different error tho), but works for
> piccolo.
> for tin-whistle, seems to be from use of CENTRAL-COLUMN-HOLE-H-LIST
> instead of CENTRAL-COLUMN-HOLE-LIST.
> 

Can you propose a patch to fix this?
I’ll take a look to see if I can put better default behavior when values aren’t 
supplied.

> - when using \override #'(graphical . #f) (is there a way to call this
> "textual"?) with an empty keylist, should show all possible text
> stencils (as it currently does for graphical).  also, how are partial
> coverings/trills handled in this case?

There is currently no support for textual partial coverings - that would 
certainly be welcome.  I couldn’t find a good convention in the literature when 
I wrote the code.
For the graphical . #f, that is a great idea - hadn’t thought of it before.  
I’ll also look into that as soon as I get stuff up an running on Yosemite.

> 
> - would be nice if i didn't have to edit display-woodwind-diagrams.scm
> and instead could just \include my raw .scm file from a .ly file.
> 

You can load scm modules via the load command.

#(load foo.scm)

Otherwise, woodwind-instrument-list is publicly defined and can be changed at 
runtime.

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

Re: Added recorder diagram (issue 153380043 by pkx1...@gmail.com)

[Mike Solomon]

On Nov 2, 2014, at 10:58 PM, pkx1...@gmail.com wrote:
> 
> I'm not comfortable pushing this, there were some things on the original
> email
> 
> http://lists.gnu.org/archive/html/bug-lilypond/2014-10/msg00024.html
> 
> (after which I offered to help move a patch through the list) that I am
> simply not qualified to say if it is still OK to push or still needs
> some work (considering there are probably some other issues with
> Woodwind Diagrams in general that these may or may not relate too in the
> LilyPond Code).
> 
> From the original email by Erik:


This passed under my radar - I’ll have time to review it tomorrow.

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

Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by e...@ticalc.org)

[Mike Solomon]

On Sep 7, 2014, at 9:46 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> +1.  The only other solution I see is to check when the parental
>> relationship is being created, but this check results in a performance
>> hit.
> 
> There is no real point in checking for a bug which one does not know how
> to recover from sensibly.
> 
>> If someone cooked up a speedy algorithm, then I think it would be a
>> good idea to check at relationship-creation time.
> 
> When the typical error case is that of multiple identical engravers in
> the same context, it would seem that the place to check is when adding
> engravers.

This is definitely a possibility - we’d have to set a policy that engravers 
cannot be added
multiple times.  I’m not sure of a case where you’d want to have multiple 
instances of the
same engraver.  The only thing I can imagine is someone wanting to make a custom
Scheme engraver that is added multiple times, but I’ve never seen a use case 
like this.

Cheers,
MS


> 
>>> https://codereview.appspot.com/134600043/
> 
> -- 
> David Kastrup


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

Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by e...@ticalc.org)

[Mike Solomon]

On Sep 7, 2014, at 4:15 PM, e...@ticalc.org wrote:

> On 2014/09/07 06:20:59, dak wrote:
>> I don't like it.  The maximum range of a variable is an arbitrary
> value and this
>> "loop avoidance" will not do us much good on a 64-bit architecture.
> 
> Thanks for pointing that out.  I will make the limits template
> parameters and restrict them to the range of a 32-bit int when used in
> this method.  If someone with more knowledge of the internals can
> suggest saner limits, I will gladly use them instead.

I can’t think of a case where the depth of parenthood would go over a few grobs 
(5-6ish) in normal engraving.  Something like 1024 would be more than enough, 
after which a programming error could be issued.

> 
>> Or, much preferable, we should catch any such cases where the circular
> reference
>> is established.
> 
> I agree that fixing the root cause is the best thing to do.  I am not
> yet familiar enough with this stuff to do that, but this backstop is
> beneficial.  Termination is more user-friendly than endless looping.
> People tend to get angry when their time is wasted.
> 
> 

+1.  The only other solution I see is to check when the parental relationship 
is being created, but this check results in a performance hit.  If someone 
cooked up a speedy algorithm, then I think it would be a good idea to check at 
relationship-creation time.

Cheers,
MS

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


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

Re: Bug in Lookup::bezier_sandwich

[Mike Solomon]

On Sep 1, 2014, at 11:16 AM, James  wrote:

> On 31/08/14 08:22, Mike Solomon wrote:
>> On Aug 31, 2014, at 1:42 AM, Jürgen Reuter  wrote:
>> 
>>> Mike,
>>> 
>>> appearently, the following patch works fine for my purposes (i.e. for flexa 
>>> / porrectus shapes):
>>> 
>>> diff --git a/lily/lookup.cc b/lily/lookup.cc
>>> index 344d42c..306d04e 100644
>>> --- a/lily/lookup.cc
>>> +++ b/lily/lookup.cc
>>> @@ -466,6 +466,9 @@ Lookup::bezier_sandwich (Bezier top_curve, Bezier 
>>> bottom_curve, Real thickness)
>>>  scm_from_double 
>>> (top_curve.control_[2][Y_AXIS]),
>>>  scm_from_double 
>>> (top_curve.control_[3][X_AXIS]),
>>>  scm_from_double 
>>> (top_curve.control_[3][Y_AXIS]),
>>> + ly_symbol2scm ("lineto"),
>>> + scm_from_double 
>>> (bottom_curve.control_[3][X_AXIS]),
>>> + scm_from_double 
>>> (bottom_curve.control_[3][Y_AXIS]),
>>>  ly_symbol2scm ("curveto"),
>>>  scm_from_double 
>>> (bottom_curve.control_[2][X_AXIS]),
>>>  scm_from_double 
>>> (bottom_curve.control_[2][Y_AXIS]),
>>> 
>>> Could you eventually verify that this patch is also fine for the slur code 
>>> (afaics your commit aimed at the slur code)?  That would be great!
>>> 
>>> Thanks,
>>> Jürgen
>>> 
>>> 
>>> On Sat, Aug 30, 2014 at 6:24 PM, m...@mikesolomon.org 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 30 août 2014, at 18:54, "Jürgen Reuter"  wrote:
>>>> 
>>>>  Hi all,
>>>>  there is a bug in Lookup::bezier_sandwich that severely affects ancient
>>>>  notation.  This method was originally added to lookup.cc for
>>>>  flexa/porrectus support.
>>>> 
>>>>  In version 2.14, the bezier_sandwich curve still looks correctly, see
>>>>  here:
>>>>  http://lilypond.org/doc/v2.14/Documentation/a9/lily-551aed0c.png
>>>>  or (with more context) here:
>>>>  http://lilypond.org/doc/v2.14/Documentation/notation/ancient-notation
>>>> 
>>>>  In version 2.15 and later, the bezier_sandwich curve has zero height at
>>>>  its right end, which is bad; see here:
>>>>  http://lilypond.org/doc/v2.15/Documentation/bf/lily-ac979051.png
>>>>  or (with more context) here:
>>>>  http://lilypond.org/doc/v2.15/Documentation/notation/ancient-notation
>>>> 
>>>>  I tried to track down the problem and found the following suspicious
>>>>  commit:
>>>> 
>>>>  commit 35725a573e47be7c02c51964641ea534fb88be6b
>>>>  Author: Mike Solomon 
>>>>  Date:   Mon Feb 6 15:03:20 2012 +0100
>>>>  Gets rid of bezier-sandwich stencil
>>>>  diff --git a/lily/lookup.cc b/lily/lookup.cc
>>>>  index 3f393e0..7b63b83 100644
>>>>  --- a/lily/lookup.cc
>>>>  +++ b/lily/lookup.cc
>>>>  @@ -449,22 +449,32 @@ Lookup::slur (Bezier curve, Real curvethick, Real
>>>>  linethick,
>>>>   Stencil
>>>>   Lookup::bezier_sandwich (Bezier top_curve, Bezier bottom_curve, Real
>>>>  thickness)
>>>>   {
>>>>  -  /*
>>>>  -Need the weird order b.o. the way PS want its arguments
>>>>  -  */
>>>>  -  SCM list = SCM_EOL;
>>>>  -  list = scm_cons (ly_offset2scm (bottom_curve.control_[3]), list);
>>>>  -  list = scm_cons (ly_offset2scm (bottom_curve.control_[0]), list);
>>>>  -  list = scm_cons (ly_offset2scm (bottom_curve.control_[1]), list);
>>>>  -  list = scm_cons (ly_offset2scm (bottom_curve.control_[2]), list);
>>>>  -  list = scm_cons (ly_offset2scm (top_curve.control_[0]), list);
>>>>  -  list = scm_cons (ly_offset2scm (top_curve.control_[3]), list);
>>>>  -  list = scm_cons (ly_offset2scm (top_curve.control_[2]), list);
>>>>  -  list = scm_cons (ly_offset2scm (top_curve.control_[1]), list);
>>>>  -
>>>>  -  SCM horizontal_bend = scm_list_n (ly_symbol2scm ("bezier-sandwich"),
>>>>  -ly_quote_scm (list),
>>>>  +  SCM commands  = scm_list_n (ly_symbol2scm ("moveto&

Re: Bug in Lookup::bezier_sandwich

[Mike Solomon]

On Aug 31, 2014, at 1:42 AM, Jürgen Reuter  wrote:

> Mike,
>  
> appearently, the following patch works fine for my purposes (i.e. for flexa / 
> porrectus shapes):
>  
> diff --git a/lily/lookup.cc b/lily/lookup.cc
> index 344d42c..306d04e 100644
> --- a/lily/lookup.cc
> +++ b/lily/lookup.cc
> @@ -466,6 +466,9 @@ Lookup::bezier_sandwich (Bezier top_curve, Bezier 
> bottom_curve, Real thickness)
>   scm_from_double (top_curve.control_[2][Y_AXIS]),
>   scm_from_double (top_curve.control_[3][X_AXIS]),
>   scm_from_double (top_curve.control_[3][Y_AXIS]),
> + ly_symbol2scm ("lineto"),
> + scm_from_double 
> (bottom_curve.control_[3][X_AXIS]),
> + scm_from_double 
> (bottom_curve.control_[3][Y_AXIS]),
>   ly_symbol2scm ("curveto"),
>   scm_from_double 
> (bottom_curve.control_[2][X_AXIS]),
>   scm_from_double 
> (bottom_curve.control_[2][Y_AXIS]),
>  
> Could you eventually verify that this patch is also fine for the slur code 
> (afaics your commit aimed at the slur code)?  That would be great!
>  
> Thanks,
> Jürgen
>  
>  
> On Sat, Aug 30, 2014 at 6:24 PM, m...@mikesolomon.org  
> wrote:
> 
> 
> Sent from my iPhone
> 
> > On 30 août 2014, at 18:54, "Jürgen Reuter"  wrote:
> >
> >   Hi all,
> >   there is a bug in Lookup::bezier_sandwich that severely affects ancient
> >   notation.  This method was originally added to lookup.cc for
> >   flexa/porrectus support.
> >
> >   In version 2.14, the bezier_sandwich curve still looks correctly, see
> >   here:
> >   http://lilypond.org/doc/v2.14/Documentation/a9/lily-551aed0c.png
> >   or (with more context) here:
> >   http://lilypond.org/doc/v2.14/Documentation/notation/ancient-notation
> >
> >   In version 2.15 and later, the bezier_sandwich curve has zero height at
> >   its right end, which is bad; see here:
> >   http://lilypond.org/doc/v2.15/Documentation/bf/lily-ac979051.png
> >   or (with more context) here:
> >   http://lilypond.org/doc/v2.15/Documentation/notation/ancient-notation
> >
> >   I tried to track down the problem and found the following suspicious
> >   commit:
> >
> >   commit 35725a573e47be7c02c51964641ea534fb88be6b
> >   Author: Mike Solomon 
> >   Date:   Mon Feb 6 15:03:20 2012 +0100
> >   Gets rid of bezier-sandwich stencil
> >   diff --git a/lily/lookup.cc b/lily/lookup.cc
> >   index 3f393e0..7b63b83 100644
> >   --- a/lily/lookup.cc
> >   +++ b/lily/lookup.cc
> >   @@ -449,22 +449,32 @@ Lookup::slur (Bezier curve, Real curvethick, Real
> >   linethick,
> >Stencil
> >Lookup::bezier_sandwich (Bezier top_curve, Bezier bottom_curve, Real
> >   thickness)
> >{
> >   -  /*
> >   -Need the weird order b.o. the way PS want its arguments
> >   -  */
> >   -  SCM list = SCM_EOL;
> >   -  list = scm_cons (ly_offset2scm (bottom_curve.control_[3]), list);
> >   -  list = scm_cons (ly_offset2scm (bottom_curve.control_[0]), list);
> >   -  list = scm_cons (ly_offset2scm (bottom_curve.control_[1]), list);
> >   -  list = scm_cons (ly_offset2scm (bottom_curve.control_[2]), list);
> >   -  list = scm_cons (ly_offset2scm (top_curve.control_[0]), list);
> >   -  list = scm_cons (ly_offset2scm (top_curve.control_[3]), list);
> >   -  list = scm_cons (ly_offset2scm (top_curve.control_[2]), list);
> >   -  list = scm_cons (ly_offset2scm (top_curve.control_[1]), list);
> >   -
> >   -  SCM horizontal_bend = scm_list_n (ly_symbol2scm ("bezier-sandwich"),
> >   -ly_quote_scm (list),
> >   +  SCM commands  = scm_list_n (ly_symbol2scm ("moveto"),
> >   +  scm_from_double
> >   (top_curve.control_[0][X_AXIS]),
> >   +  scm_from_double
> >   (top_curve.control_[0][Y_AXIS]),
> >   +  ly_symbol2scm ("curveto"),
> >   +  scm_from_double
> >   (top_curve.control_[1][X_AXIS]),
> >   +  scm_from_double
> >   (top_curve.control_[1][Y_AXIS]),
> >   +  scm_from_double
> >   (top_curve.control_[2][X_AXIS]),
> >   +  scm_from_double
> >   (top_curve.control_[2][Y_AXIS]),
> >   +  scm_from_

Re: get_property vs internal_get_property (was: issue 127860043)

[Mike Solomon]

On Aug 18, 2014, at 9:39 AM, Janek Warchoł  wrote:

> Hi,
> 
> it's time to ask a n00b question and get the elephant (that was
> bothering me for a couple years) out of the room: why do we have - and
> use! - both get_property and internal_get_property?  We ought to use
> get_property everywhere, right?
> 
...
> 
> We are also converting property names from strings to symbols
> everywhere - for example
> 
> SCM meta = info.grob ()->internal_get_property (ly_symbol2scm ("meta"));
> 
> What's the reason for that?  And shouldn't we write all the C++ code
> so that it will automatically do the conversion, like get_property
> does?
> 

Entirely reasonable and good idea!
The only slight annoyance is that it is backwards from the logic of almost all 
other “internal_X" patterns in LilyPond, where the function X takes Scheme 
values and "internal_X" takes C++ values.

Cheers,
MS

> Whew.  I feel like an idiot now.
> 
> best,
> Janek
> 
> 
> 2014-08-18 8:09 GMT+02:00  :
>> 
>> https://codereview.appspot.com/127860043/diff/40001/lily/lily-guile.cc
>> File lily/lily-guile.cc (right):
>> 
>> https://codereview.appspot.com/127860043/diff/40001/lily/lily-guile.cc#newcode201
>> lily/lily-guile.cc:201: robust_scm2bool (SCM b, bool def)
>> On 2014/08/18 04:57:08, Keith wrote:
>>> 
>>> I am not sure, but I think this is a bad idea.
>>> to_boolean() is robust to undefined symbols, returning #f, and a lot
>> 
>> of
>>> 
>>> define-grobs.scm depends on that convention.
>>> If you add this variant, and people start writing C++ that treats
>> 
>> undefined
>>> 
>>> symbols as #t, we might get confused.
>> 
>> 
>> Hmm.  Good point.  However, to me the situation without robust_scm2bool
>> is also confusing: in fact, i was confused enough to write buggy code :(
>> As far as i can see, the code for getting non-boolean properties
>> follows the convention:
>> 
>> Type value = robust_scm2type (grob->get_property("prop-name"), default)
>> 
>> When writing code for issue 2245, I have initially tried to use
>> robust_scm2bool - which didn't exist.  As i was not aware of to_boolean,
>> i ended up with ly_scm2bool, which turned out to be a bad choice.
>> 
>> So, my question is: can we do something to make this more intuitive?
>> 
>> What about writing utility functions for getting and converting
>> properties in one step?  The current situation is not very elegant - the
>> code sometimes gets so long that it's hard to fit it in 80 chars limit.
>> 
>> https://codereview.appspot.com/127860043/
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel


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

Re: LilyPond meeting 2014?

[Mike Solomon]

On Jul 12, 2014, at 3:48 PM, Marc Hohl  wrote:

> Am 12.07.2014 14:44, schrieb Janek Warchoł:
>> Hi all,
>> [...]
>> 
>> Unfortunately i'm busy on that weekend :(
>> 
>> Is there noone else interested?
> 
> Basically, I am interested as well, but I have a concert on August 30th :-(
> 
> Marc
> 
>> Janek
>> 
>> ___
>> lilypond-devel mailing list
>> lilypond-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>> 
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

I’d love to meet up but I am in gig mode as well towards the end of the summer 
and we have a newborn in the house.
Hope you guys can work something out!  I’d definitely attend as much as I could 
over IRC.
~Mike
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Help needed to make LilyPond run better on Mediawiki

[Mike Solomon]

On May 12, 2014, at 5:20 PM, David Cuenca  wrote:

> As reported on a previous email [1], there is no function to work with
> independent/bundled pages, other than to resort to variables, which do not
> work in safe mode. Is there any way to solve that?
> 
> The wikimedia community is interested in using lilypond to start a score
> typesetting project [2]. However, without a way of combining several pages,
> it wouldn't be possible to generate a single file, which limits the
> usefulness of the contributors' work.
> 
> Is there anyone interested in taking a closer look into this? We could have
> a irc chat/Hangout next week to explore possible options.
> 
> Thanks & regards,
> Micru
> 
> 
> 
> [1] http://lists.gnu.org/archive/html/lilypond-user/2014-05/msg00156.html
> [2]
> https://meta.wikimedia.org/wiki/Requests_for_comment/Musical_score_transcription_project_proposal
> 

Dear Micru,

I am currently working on a research project in Finland and France for an 
typesetting server that is based around LilyPond and Guido for this exact 
purpose.  Some of the technology have already been realized and we’re looking 
to go public with a Beta in the beginning of 2015.

I browsed the website linked in [2] and while it encapsulates several problems 
well, there are others that need to be addressed before this can get off the 
ground.  The main one that my research project is trying to solve, which is a 
superset of the problem you’re talking about, is how to partition a score into 
units.  Contributors should be able to define the units on which they wish to 
work (a measure, a staff, a voice, etc.) and be able to write music into this 
unit that will automatically be integrated into the whole.

The bigger issue is one of content versus layout.  While the distinction is 
somewhat fuzzy insofar as scores are both containers of content and objects of 
beauty, the page (assuming you mean “page” as in “a page of A4 paper”) is most 
often a layout parameter.  The project I’m working on is focusing on how to 
automatically extract content in arbitrary units and to lay it out in arbitrary 
ways.  LilyPond is pretty good at the second but not so great at the first.

I’d be happy to irc about it next week if you’re around to discuss more the 
research project I’m working on as well as your ideas about the music wikipedia.

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

Scores in iBooks

[Mike k]

Hi
Thought this iBooks 'bug' might seed some ideas for developers. 
I recently bought a 
transcription by Hal Leonard publishers on iBooks. 
Unfortunately the score does not scale 
which renders in unreadable on any less than a 48" screen!
Would lily pond have the tools to repagenate the score as you zoomed in,
 but still retain some 
musical sense with respect to stave groups and bar lines etc.  
just a thought
Mike 


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

Re: how close are we to having an "addAt" or "insertAt" feature?

[Mike Solomon]

On Jan 14, 2014, at 1:03 AM, Kieren MacMillan  
wrote:

> Hello all,
> 
> What would be involved in developing a feature to add notes or tweaks at an 
> arbitrary moment within a music expression?
> 
> e.g.
> 
>global = \repeat unfold 100 s1
>music = \addAt (4 3/8) \global \once \override RehearsalMark.extra-offset 
> #’(-1 . 0)
> 
> where (4 3/8) means “in the fourth measure, at the moment of the 3rd eighth 
> note”
> 
> This would allow “perfect” separation of content from presentation — a very 
> welcome thing to my mind.
> 
> Thanks,
> Kieren.

I agree that this’d be great.

A Scheme function can unfold repeats (we’d need one for absolute mode and one 
for relative), and a Scheme function can comb through music of arbitrary length 
and attach things to it, so we’re about a half-day’s work away from a hack that 
doesn’t involve iterators.

If we’re gonna touch the C++ iterators, it’ll require more design strategy and 
will take more time.

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

Re: fixing German's Wikipedia entry of LilyPond

[Mike Solomon]

On Jan 13, 2014, at 11:04 AM, Werner LEMBERG  wrote:

>>> My Windows machine won't convert this to SVG.  Would someone else
>>> like to and to upload the SVG?
>> 
>> Hmm.  I tried
>> 
>>  lilypond -dbackend=svg stockhausen.ly
>> 
>> and get the error
>> 
>>  warning: cannot find SVG font #f
> 
> BTW, what about creating and installing SVG and WOFF fonts too for the
> `CenturySchL' family?
> 
> 
>Werner

Here’s a minimal example to get the same effect.

\version "2.19.0"

{
  \override Staff.TimeSignature.font-name = "New Century Schoolbook"
  a1
}

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

Re: 3.0?

[Mike Solomon]

On Jan 9, 2014, at 1:07 PM, Urs Liska  wrote:

> Am 09.01.2014 12:03, schrieb Jan Nieuwenhuizen:
>> Urs Liska writes:
>> 
>>> Is there _any_ notion what a LilyPond 3.0 may be?
>> 
>> I could imagine that if LilyPond were made into an engraving library,
>> and/or heavy rewiring to make it deeply integrated with a gui,
> 
> Hm, this is something I was also thinking about: Of course LilyPond itself 
> will never get graphical editing but remains a dedicated engraving tool.
> But it would probably make it more attractive for the consumer market if it 
> had a nice default GUI. I personally would be pleased to see Frescobaldi 
> become such a default GUI (of course not cutting out other options). 
> Particularly given the prospect of Frescobaldi providing graphical editing 
> capabilities soon (and provided we'll get the Mac OSX installation sorted 
> out).
> 
> Would such a step be _conceptually_ acceptable or should LilyPond remain 
> "GUI-agnostic”?


GUI agnostic - there should be a clear separation between front end and 
backend.  LilyPond is technically already GUI agnostic, as joe and vim (my two 
favorite GUIs) both act commendably as front ends to my LilyPond code.

The best thing, by far, would to make LilyPond a modular engraving library with 
public APIs for each module.  This way, building a GUI just means mapping 
visual symbols to API calls and displaying the result.

GUIDO (for which I’m a developer) already works like this and has been embedded 
in several commercial and open-source apps.

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

Re: Building Lilypond documentation

[Mike Solomon]

On Jan 2, 2014, at 1:29 PM, Sven Axelsson  wrote:

> I've decided to get at least a little active in Lilypond development, and 
> thought I should start with getting my development environment up and 
> running. I get some weird errors when building the different doc targets, 
> such as:
> 
> Please check the logfile suffix-tely.texilog.log for errors
> 
> And "suffix-tely.texilog.log" contains "*** out-www/ not writable". Not sure 
> which one of the many out-www folders that is referring to, but they are all 
> writable as far as I can see.
> 
> I am probably missing something simple here. I'd appreciate if someone can 
> give me a hint.

Try doing a recursive chmod (find . -name “a regular expression” | xargs chmod 
my-permissions-wishes) and/or running make in sudo.  I do the latter whenever I 
build out of laziness - works for me.

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

Re: Adds outside-staff-interface and outside-staff-axis-group-interface (issue 37950044)

[Mike Solomon]

On Dec 16, 2013, at 12:07 PM, d...@gnu.org wrote:

> On 2013/12/16 09:58:40, mike7 wrote:
>> On Dec 16, 2013, at 11:45 AM, mailto:d...@gnu.org wrote:
> 
>> > The summary seems incompatible with
>> > http://music.stackexchange.com/a/14160/8773>
>> >
>> > Once an interface is required for outside-staffing a grob, the set
> of
>> > grobs one can use in that manner is hardwired to the "intended"
> grobs.
> 
>> This is true.  The outside-staff-interface would need to be applied to
> every
>> grob that could, in theory, be shifted this way.  I’d need help in
> flagging
>> grobs I’ve missed - I’ve gotten everything that uses it in the
> regtests, but
>> there are others that are not tested.  The stackexchange example is
> one of
>> them.
> 
>> I think the hardwiring is good in that we should avoid letting grobs
> implement
>> interfaces with properties that could never, in any circumstance,
> apply to them.
> 
> [...]
> 
>> As a corollary, if it doesn’t exist already, we may want to create a
> mechanism
>> to add or subtract interfaces from grobs at runtime.
> 
> As a corollary, if it doesn't exist already, we may want to create a
> mechanism to add interfaces to grobs with properties that could never,
> in any circumstance, apply to them?
> 
> That does not look like a corollary.  More like an antithesis.
> 


never-in-any-circumstance is too strong: downgraded to 
only-in-circumstances-that-developers-can’t-anticipate.

Meaning that if users esteem that NoteSpacing needs bracket-flare, there should 
be a mechanism in place to add an interface implementing that.  However, in 
LilyPond proper, we should not make that a default because we as a community 
agree that NoteSpacings do not have bracket-flair.

Cheers,
MS


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

Re: Adds outside-staff-interface and outside-staff-axis-group-interface (issue 37950044)

[Mike Solomon]

On Dec 16, 2013, at 11:56 AM, tdanielsmu...@googlemail.com wrote:

> I applaud this!  Properties in an interface which
> were not honoured when processing certain grobs
> which purported to implement that interface really
> irritated me when trying to write documentation.
> 
> Trevor
> 
> 
> https://codereview.appspot.com/37950044/

Good deal - thanks!

Cheers,
MS

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

Re: Adds outside-staff-interface and outside-staff-axis-group-interface (issue 37950044)

[Mike Solomon]

On Dec 16, 2013, at 11:45 AM, d...@gnu.org wrote:

> The summary seems incompatible with
> http://music.stackexchange.com/a/14160/8773>
> 
> Once an interface is required for outside-staffing a grob, the set of
> grobs one can use in that manner is hardwired to the "intended" grobs.

This is true.  The outside-staff-interface would need to be applied to every 
grob that could, in theory, be shifted this way.  I’d need help in flagging 
grobs I’ve missed - I’ve gotten everything that uses it in the regtests, but 
there are others that are not tested.  The stackexchange example is one of them.

I think the hardwiring is good in that we should avoid letting grobs implement 
interfaces with properties that could never, in any circumstance, apply to 
them.  Setting:

NoteSpacing.outside-staff-priority

makes my brain go NaN/0.  I the same way that setting:

NoteSpacing.bracket-flare

makes my brain go NaN/0.  The difference is that the second triggers a 
programming error whereas the first doesn’t.

As a corollary, if it doesn’t exist already, we may want to create a mechanism 
to add or subtract interfaces from grobs at runtime.

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

Re: note-spacing: stretch somewhat uniformly; issue 3304 (issue 36830045)

[Mike Solomon]

On Dec 16, 2013, at 10:24 AM, k-ohara5...@oco.net wrote:

> Reviewers: MikeSol,
> 
> Message:
> On 2013/12/16 07:42:52, MikeSol wrote:
> 
>> If you understand this stuff, could you put a comment in
> lily/include/spring.hh
>> as to what inverse_compress_strength and inverse_stretch_strength are?
> 
> They are the stretchability and compressibility of the space.
> Next time I have linux up I'll put a comment, or just change the names.
> 

Ok - try to explain the relation between things (min distance, ideal distance, 
and these two constants).

> You should try the patch on your music.  You probably have a lot of
> staggered timing in the style of 3-against-2 hemiola, which should be
> aligned more evenly with the patch.
> 

I’d say Trevor Bača is an even better candidate (cc’d to this e-mail) - he has 
π on e hemiolas in his music.

Cheers,
MS

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 15, 2013, at 11:22 AM, Trevor Daniels  wrote:

> 
> Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM
>> 
>>> raw/final would be shorter than pure/unpure.
>> 
>> I like that.  At least for me this is easier to understand from a
>> conceptual point of view.
> 
> pencil/ink.

All of these are good - the use of “pure” (not sure who started it - maybe 
Joe?) comes from:

http://en.wikipedia.org/wiki/Pure_function

1. The function always evaluates the same result value given the same argument 
value(s). The function result value cannot depend on any hidden information or 
state that may change as program execution proceeds or between different 
executions of the program, nor can it depend on any external input from I/O 
devices.
2. Evaluation of the result does not cause any semantically observable side 
effect or output, such as mutation of mutable objects or output to I/O devices.

Currently, LilyPond’s pure functions do (2) but not (1).  I don’t even think 
it’s desirable that they do (1), as the approximation can get better over time. 
(2), however, is very important.  (2) would mean we’re inking things elsewhere.

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 15, 2013, at 10:46 AM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> 
> 
>>> The layout engine could use get_property_data() freely, but before it
>>> has set line-breaks the layout engine would refrain from calling any
>>> callback functions directly.  Instead of a callback for height',
>>> layout functions would look up the grob property
>>> tentative-height-estimator' where tentative-*-estimators are always
>>> functions that take the start-end columns as parameters.
>> 
>> This seems not too far from what we’re doing now, but it adds a lot
>> more properties.
> 
> I was of the opinion that the tentative estimators (pure) were for the
> situation _before_ the line breaking.

This is the case.

> 
>>> The tentative-height-estimator for something like a Slur or
>>> VerticalAxisGroup would return its best guess for the height, while
>>> the estimator for a Clef would simply get_property("height") causing
>>> its stencil to be formed and leaving the resulting data in the
>>> stencil' and 'height' properties for further use.
>> 
>> This seems to get the same result we have now while adding a lot of
>> extra properties.
> 
> Yup.  It would seem like we'd need more some nicer construct for
> providing a number of behaviors in a single callback/property, with
> caching for each set of _relevant_ preconditions.

Yup.

> 
>> I like the idea of their being a single property that is honed in on
>> with successive estimates until we get the perfect value.  This is how
>> I do a Sudoku - I pencil the guesses in the squares
> 
> Blasphemy!

Then LilyPond is a blasphemous piece of software...that has typeset thousands 
of pieces of liturgical music…

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 15, 2013, at 12:58 AM, Keith OHara  wrote:

> On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon  wrote:
> 
>> On Dec 14, 2013, at 9:35 AM, David Kastrup  wrote:
>> 
>>> Most of the contortions seem focused about when or when not and how to
>>> pass begin/end columns.  It would seem to make sense to turn them into
>>> dynamic parameters *begin* *end* that you can then query with (*begin*)
>>> and (*end*).  If (*begin*) returns ##f, we can assume being in a pure
>>> calculation.
>>> 
>>> That would seem to get rid of most of the current interface
>>> complications.
>> 
>> I can see the utility of having one function instead of two for these things.
>> 
>> The current pure and non-pure functions are often wrappers around a single 
>> internal function that has a bool parameter called “pure”, so this would 
>> eliminate the need for the wrapper functions.
>> 
> 
> The word 'pure' might have too much a connotation as 'good'.  Maybe we should 
> rename 'pure' -> 
> ‘shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'
> 

I prefer the second name, with the corollary that pure heights and pure 
anythings are the largest implementation of a basic strategy all over the code 
base, which is:
elaborate several options
score them
pick the one with the highest score

This happens for slurs, beams, ties, and line breaking.  In the case of line 
breaking, the elaboration of the options entails making estimates, which is why 
we calculate pure heights.

> --
> The most transparent reorganization might be to have all properties that can 
> hold data use the usual callback mechanism: where the callback function is 
> used just once, and the data it returns takes the place of the callback.

This is indeed transparent, but given that a single object can return many pure 
heights based on the begin/end values being used or based on how far downstream 
we are, it’s not clear what this property would look like.

> 
> The layout engine could use get_property_data() freely, but before it has set 
> line-breaks the layout engine would refrain from calling any callback 
> functions directly.  Instead of a callback for 'height', layout functions 
> would look up the grob property 'tentative-height-estimator' where 
> tentative-*-estimators are always functions that take the start-end columns 
> as parameters.

This seems not too far from what we’re doing now, but it adds a lot more 
properties.

> 
> The tentative-height-estimator for something like a Slur or VerticalAxisGroup 
> would return its best guess for the height, while the estimator for a Clef 
> would simply get_property("height") causing its stencil to be formed and 
> leaving the resulting data in the 'stencil' and 'height' properties for 
> further use.
> 

This seems to get the same result we have now while adding a lot of extra 
properties.

I like the idea of their being a single property that is honed in on with 
successive estimates until we get the perfect value.  This is how I do a Sudoku 
- I pencil the guesses in the squares until I get the actual value and then 
erase all the estimates and write the good value.  Something about using the 
container (the property) as a holder of the estimates and the final item itself 
feels sound design-wise.

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

Re: grob-property: if callback is independent of layout, call just once (issue 42190043)

[Mike Solomon]

On Dec 14, 2013, at 12:00 PM, d...@gnu.org wrote:

> 
> https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc
> File lily/unpure-pure-container.cc (right):
> 
> https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc#newcode45
> lily/unpure-pure-container.cc:45:
> On 2013/12/14 09:47:33, MikeSol wrote:
>> Looking good.
> 
>> The only thing is - how do we verify that this actually ignores start
> and end?
> 
> The function does not get passed start and end, so it has little choice
> but to ignore them.
> 
>> For example, let's say that there is a scheme function with optional
> arguments
>> for start and end that is used as the pure and unpure function.
> 
> You are confused.  If the second container element is _unbound_, which
> is what is being checked here, the function in the first container will
> _always_ be called without begin and end arguments.

Ah, ok, didn’t know that.

> 
>> It'll evaluate
>> just fine for unpure cuz begin and end are optional.  But begin and
> end may be
>> useful when it is pure.  If this is the only function passed to the
> constructor,
>> it will return true for the function above and yet perhaps be an
> operation that
>> we don't want to cache.
> 
>> Conversely, it is possible to do:
> 
>> (ly:make-unpure-pure-container foo foo)
> 
>> that should be cached but it would return false for this function.
> 
> Well, but in this case the function foo will be called without begin/end
> for the pure case and _with_ begin/end for the unpure case.  Different
> thing.
> 
>> So, my proposal would be:
> 
>> 1) if there is a single function, verify that it takes only one
>> argument
> 
> Doesn't matter.  It will always get only one argument.

Ok.

> 
>> 2) if there are two functions, verify that the second takes only one
> argument
> 
>> All of this is of course predicated, like I said above, on being able
> to check
>> the number of arguments a scheme function takes, which may or may not
> be
>> possible...
> 
> I would try to avoid this: the fine details here differ significantly
> between GUILEv1 and GUILEv2, and it does not appear that you can rely on
> this information being available at all or at least with the same
> mechanism for functions defined in C in GUILEv2.  So there is a large
> danger that we would be painting us into a corner here.
> 
> Once can, of course, call the function with three arguments and trap an
> error (if one occurs).  But error trapping is not likely efficient.
> 

Sounds like more trouble than it’s worth.
LGTM then.

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 14, 2013, at 9:35 AM, David Kastrup  wrote:

> "Keith OHara"  writes:
> 
>> On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup  wrote:
>> 
>>> That does not make sense.  If you want call-once behavior, you can just
>>> use a callback.
>> 
>> At the moment, the decision on whether to preserve the callback
>> pointer in the grob property, or fill the property with the returned
>> value, depends on the method used to request the property,
>> get_pure_property() versus get_property().  A callback would be called
>> multiple times (and it would have to support the unpure-pure calling
>> convention).
>> 
>> The information of whether the callback is providing a value that
>> /should/ be kept as final is better stored in the Grob itself, so I am
>> thinking of ways to reorganize.
>> 
>> The way stencil callbacks are evaluated now is interesting.  The
>> stencil callback itself is a simple callback, but when the layout
>> engine wants to know the size of a stencil it does
>> get_pure_property("Y-extent").  Y-extent property is set to either
>> execute the stencil callback, or estimate a height without building
>> the final stencil, as appropriate for each Grob.
> 
> If you are thinking of reorganizing: the current state is a mess.
> I still have not figured out what ly:make-simple-closure is supposed to
> do.

ly:make-simple-closure delays evaluation of its parts until looked up.
It is exactly the same as a lambda function.
I don’t think anyone actually uses them anymore - probably can be retired.

> 
> Most of the contortions seem focused about when or when not and how to
> pass begin/end columns.  It would seem to make sense to turn them into
> dynamic parameters *begin* *end* that you can then query with (*begin*)
> and (*end*).  If (*begin*) returns ##f, we can assume being in a pure
> calculation.
> 
> That would seem to get rid of most of the current interface
> complications.

I can see the utility of having one function instead of two for these things.

The current pure and non-pure functions are often wrappers around a single 
internal function that has a bool parameter called “pure”, so this would 
eliminate the need for the wrapper functions.

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 14, 2013, at 9:21 AM, Keith OHara  wrote:

> On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup  wrote:
> 
>> That does not make sense.  If you want call-once behavior, you can just
>> use a callback.
> 
> At the moment, the decision on whether to preserve the callback pointer in 
> the grob property, or fill the property with the returned value, depends on 
> the method used to request the property, get_pure_property() versus 
> get_property().   A callback would be called multiple times (and it would 
> have to support the unpure-pure calling convention).
> 
> The information of whether the callback is providing a value that /should/ be 
> kept as final is better stored in the Grob itself, so I am thinking of ways 
> to reorganize.
> 

Excellent observation.

Currently, unpure-pure-containers to which one passes one function/argument use 
that function/constant for both the pure and unpure parts.
What you want to do is cache the pure result, not unlike 
Item::cache_pure_height (Interval height) [line 247 of item.cc].  I’m a fan of:
doing caching for more grobs (not just items)
doing caching for more properties (not just heights)
doing conditional caching, meaning caching a result after having finished X or Y

It’d be nice to have a general mechanism for all this.

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 13, 2013, at 9:07 AM, Keith OHara  wrote:

> On Tue, 10 Dec 2013 22:44:18 -0800, Keith OHara  wrote:
> 
>> After a brief look at the code, it looked like for each glyph being laid out 
>> there is one extra call of Open_type_font:: or Pango_font::name_to_index(), 
>> which is the function called by find_by_name() that caused the extra time 
>> with issue 1926.
>> 
> 
> I am happy to say that I was wrong here.
> 
> Open_type_font:: and Pango_font::name_to_index() each call 
> FT_Get_Name_Index().  Inserting print statements to trace those calls I find 
> that FT_Get_Name_Index is called:
> 7 times for each character in a Tempo

My LilyPond is not working for some reason (see previous e-mail about 
debugging).  Once I get it up and running, I’ll have a go at this.

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

gdb and hanging lilypond

[Mike Solomon]

Hey all,

On my GCC-built-but-running-on-OSX lilypond, LilyPond has started to hang at 
the “Finding the ideal number of pages” stage.

I have compiled LilyPond with debugging and without optimization, but when I 
gdb it and kill the process, no meaningful stack trace is given:

My wild guess is that there’s some mix and match problem between dynamically 
linked libraries that have been compiled with clang and the executable, which 
is compiled with gcc.

In the meantime, I’m gonna try to get lilypond compiling with clang again.  I 
may just give up and get another VBox if it is too much of a hassle.

In the mean-meantime, I’ve put the cryptic gdb backtrace below.  Does anyone 
know how to try to get it to be more informative?

Cheers,
MS

MacBook-Pro-de-Mike:bidouillage mikesolomon$ sudo gdb lilypond
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin13.0.0".
For bug reporting instructions, please see:
...
Reading symbols from 
/Users/mikesolomon/devel/lilypond/build/lily/out/lilypond...done.
(gdb) run foo.ly
Starting program: /Users/mikesolomon/devel/lilypond/build/out/bin/lilypond 
foo.ly
GNU LilyPond 2.19.0
Processing `foo.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...[New Thread 0x1a0b of process 14992]

Program received signal SIGTERM, Terminated.
0x7fff930a90de in ?? ()
(gdb) backtrace
#0  0x7fff930a90de in ?? ()
#1  0x7fff5fbf98b0 in ?? ()
#2  0x000100dff36c in ?? ()
#3  0x00d444c0 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#4  0x in ?? ()
(gdb) 
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Website questions: GSoC

[Mike Solomon]

On Dec 12, 2013, at 3:06 PM, Urs Liska  wrote:

> The page "GSoC 2012" is obviously outdated.
> 
> What should be done with it?
> 
> Immediate reaction: "Put it on the attic".
> But: Would it be useful to write a summary of what of it actually happened?
> If yes: Is there something willing and able to do that?
> 
> Urs
> 

Janek participated in that - I was his mentor.
I’d recommend you ask him about that, perhaps in a personal mail, as he’s taken 
a leave of absence.

Cheers,
MS


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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 12, 2013, at 10:43 AM, David Kastrup  wrote:

> Werner LEMBERG  writes:
> 
 One extra lookup per glyph might be enough to explain the difference.
 We need to look up the glyph to get a skyline, but maybe could cache
 its index into the font in the stencil.
>>> 
>>> That does not sound very useful since we still would do the lookup
>>> once per stencil rather than once per m and once per f.
>>> 
>>> It _is_ annoying that this job is not done efficiently by the
>>> Freetype library.
>> 
>> I don't follow.  What exactly is annoying?  Please explain.
> 
> Caching of frequently accessed information if that information is
> expensive to access.
> 
>>> Is it possible that the Freetype library on Windows imprudently
>>> accesses (and possibly creates on the fly) some Truetype versions or
>>> conversions of the fonts for getting the outlines?
>> 
>> Nope.  FreeType uses exactly the same code on both platforms,
> 
> Unlikely as it is talking to different font servers and systems.
> 
>> and it never converts fonts on the fly.
> 
> But its request to the respective font subsystem might still result in
> stuff getting resolved via the Truetype path.
> 
>>> That might also explain
>>> http://code.google.com/p/lilypond/issues/detail?id=2657>, the
>>> still unresolved Issue 2657: font kerning on Windows is broken
>> 
>> Certainly not.  This is not a FreeType problem, since kerning and the
>> like is handled one level above FreeType.
> 
> Well, if Freetype talks to different levels above, it might have
> misunderstandings with the upper level on Windows.
> 

One possibility is to implement aux files for lilypond runs that do some form 
of caching. Reading the aux files and storing their data in caches may be less 
time consuming than the Freetype calls.

Cheers,
MS


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

Re: branching

[Mike Solomon]

On Dec 11, 2013, at 3:56 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> On Dec 11, 2013, at 11:36 AM, David Kastrup  wrote:
> 
> [...]
> 
>> But that’s no good - we have to find a solution.  Modularity, while
>> perhaps a good long term solution, is a long ways away.  How are we
>> going to deal with this in 2014?
> 
> By making headway and not be defeatist about it?  "is a long ways away"
> is terribly close to "somebody else's problem" and "let's think about
> this the year after next year".
> 
>>> And I see no-one in the current developer base who would work in that
>>> direction.
>> 
>> One of my major projects - eliminating calls to translate_axis, was
>> moving exactly towards this (https://codereview.appspot.com/7185044/).
> 
> It's called "Caches the interior skylines of vertical axis groups and
> systems." and there is no obvious reason why cached skylines would not
> be translatable.  Of course, there is the non-obvious reason that a
> translation might lead to a violation of skyline invariants due to
> numerical effects, but that's nothing that can't be caught in-place.
> 

The title for this is pretty terrible, I agree.  It was in sketch phase a few 
months ago before I stopped working on it.

> In other words: there are several different issues that are conflated
> here in a single patch.  There is no inherent reason why not being able
> to use translate_axis will lead to more modular code.  It seems actually
> more likely that having to track offsets separately is going to make
> stuff more complex.

In most of LilyPond, grob properties are calculated via callbacks, which 
themselves trigger the calculations of other properties they need a cascading 
sort of way.  This means that we can swap out the default function 
Script.Y-offset with another callback or a number.

When translate_axis is used in the code, it means that while looking up a 
property of grob A, the offsets of B, C, and D will be set internally.  This 
means that if a user sets the Y-offset of grob B to 2 and it is actually 4 
because translate_axis has been called somewhere deep in the code, it is 
counterintuitive how this happened and how to change it.  Furthermore, if the 
user overrides the callback that triggered translate axis, customary grob 
movements won’t happen anymore and the user won’t know why.  In this way, 
translate_axis impedes modularity: it makes us less able to plug in different 
callback functions for different grobs and get expected results.

My goal is to put all offset calculations in the callback function so that if I 
set TextScript.Y-offset to #0.1, I am positive that its Y offset with respect 
to its parent will be #0.1.  This is currently not the case.


> 
>> The less we’re calling translate_axis (the Defense Against the Dark
>> Arts function of LilyPond) in the backend, the more we can isolate
>> functionality to certain places and the less surprises there are.
> 
> I don't see the connection.
> 
> The net effect for the user, according to the Changes file, appears to
> be that outside-staff-priority stops working unless special callbacks or
> special commands (\tupletOutsideStaffPriority) are used, regardless of
> whether the grobs have the side-position-interface or not.
> 
> As a result, it is not all that surprising that there were several grobs
> overlooked.
> 
> Does this have anything to do with "caching the interior skylines of
> vertical axis groups and systems"?  Not apparently.  Does it have
> anything to do with "Removes the translate_axis call from
> axis-group-interface outside-staff positioning"? Not obviously.  There
> is no explanation in the review or patches for that.
> 
> I've taken a look at the current patch:
> https://codereview.appspot.com/7185044/#msg53> rather suggests that
> there is considerable work needed to get this into commit quality.
> 

There is a lot of work ahead of it, and if I get back to it, I’ll be splitting 
it up into smaller commits.

> There is also no explanation of the great plan behind this anywhere,

The great plan is:
Remove as many calls to translate_axis as possible.
Create pure versions of the offset callbacks, which now calculate actual 
offsets without translate_axis tacked on.
Now that these pure versions are used, pure estimates of staff height will be 
more accurate because they’ll finally take into consideration outside-staff 
grobs.
That means that spacing stubs for cross staff grobs that need to user pure 
staff height calculations will be closer to the actual spacing.
This means that scores with lots of cross-staff grobs will have better vertical 
spacing.  Currently, vertical spacing of these scores is too ai

Re: branching

[Mike Solomon]

On Dec 11, 2013, at 2:18 PM, Trevor Daniels  wrote:

> 
> Mike Solomon wrote Wednesday, December 11, 2013 10:22 AM
> 
>> On Dec 11, 2013, at 11:36 AM, David Kastrup  wrote:
>> 
>>> As opposed to me, Graham excelled at organizing
>>> and maintaining community efforts like this which makes his leaving an
>>> even larger loss.
>> 
>> His leaving is a huge loss, and as he has stated several times, one big 
>> reason is the lack of sense of community.  devel-list quarrels and the 
>> thaws that come from them have real impacts on LilyPond - I can’t 
>> emphasize enough that we need to stop marginalizing this issue and 
>> tackle it head on.  Modularity, while perhaps a good long term solution, 
>> is a long ways away.  How are we going to deal with this in 2014?
> 
> Actually, I think there is a great sense of community within the LilyPond
> project.  Why else would people comment so favourably on the responses
> they receive on the various mailing lists; why else would people on the
> bug squad, Phil on releases, James on managing reviews, etc devote their
> time to mundane tasks?  Why else would people, even those no longer
> active in LilyPond development, continue to read the lists?  No, we are
> a great community and it is greatly enjoyable to belong to it!  
> 

I agree that this part of the community is great.  Reading the communication 
between these people is a pleasure - it is professional, courteous and fun.

> Also we are extremely fortunate to have so many brilliant developers
> willing to spend their time augmenting, fixing and improving our baby.
> That differences arise from time-to-time is inevitable - from the nature of
> this project our community includes people covering a wide range of
> temperament.  Artists, artisans and engineers all figure prominently.  They
> have different viewpoints and approaches, but this is an advantage not
> a problem - providing we can find a way to live and work together without
> stress levels getting too high.

I agree.

> 
>> How are we going to deal with this in 2014?
> 
> I would recommend Mike and David both consider privately what they
> might have done differently to avoid this situation arising.  Not what the
> other should have done, but what they themselves might have done.
> If they'd like to share those thoughts with the list that would be good, but
> that is not essential.  But they must share them with each other and try
> to culture a mutual respect and understanding for the other's position.

David and I have already been back and forth privately a lot about these issues.

I value David’s criticisms and have learned a lot from his insistance on 
commenting, code quality, and design.  To address issues that David has brought 
up, I have read cover to cover two books on programming, one of which is on 
code refactoring and design.  I think these have led to tangible improvements 
in my work on LilyPond.  I look forward to learning more.

It’d be a great goal in 2014 to see people who left the project because of 
communication difficulties come back because of a sincere effort on the part of 
everyone to communicate with mutual respect, irrespective of what the 
differences are in their positions.

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

Re: branching

[Mike Solomon]

On Dec 11, 2013, at 11:36 AM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
> 
> We are currently taking a look at how to create regions of LilyPond that
> can be worked on independently and without affecting the overall quality
> of LilyPond.  If we manage to do this successfully, we'll be able to
> create a community work area where the quality of the individual project
> does not impact anybody but the active users of such a project.

I think this is an excellent goal.

> 
> I think that a buffer area between "core" or "nothing" will broaden the
> base of people casually working on or with LilyPond and exchanging their
> experiences.  It will also help with people who say "feature xxx has to
> be in LilyPond in order to let me work with application yyy": they or
> their tool provider can just drop appropriate files into appropriate
> parts of the user- or tool- designated search paths.

I agree.

> 
> If we can get to a consensus that it's best for the project if I'm
> thrown out, of course that is perfectly possible.  I would suggest the
> end of 2014 as a suitable date, simply because I received forward-going
> contributions that I'd prefer to spend as they were intended.  But if
> people wish for an earlier date, I'd just pay back a corresponding
> amount.

This seems like a rather extreme, all-or-nothing solution.

What I’d like is people reacting gracefully when they feel that their toes are 
stepped on.

There was one time when I started with the project where I blew up at Han Wen 
for pushing a major change with minimal review on a large scale beam collision 
project that I was working on.  I flipped out - it was 80ish hours of my work 
down the toilet.  I was not at all considerate in what I said and Han Wen 
dropped out of the project for a while.  I’m not sure if the two were linked, 
but I felt _terrible_ about this - I realized that this is _never_ appropriate 
or useful for LilyPond, or for anything, to have communication like this.

> 
> Now regardless of whether I continue participation with the LilyPond
> project or not, I definitely think that the code base needs to be
> changed to accommodate more independent work.

I completely agree.

> 
> While tools like git facilitate work based on separate branches and
> merges and rebasing, this is essentially negated by a code base where
> significant changes will tend to happen all over the place.  This causes
> merge conflicts, or even worse, produces inconsistent code since
> conflicting changes not touching the same text lines are "merged".
> 
> So while the fundamental problem with participating with LilyPond can be
> circumscribed as "David does not react gracefully when people step on
> his and LilyPond's toes", it does seem to make sense to work towards
> more generally available toe room anyway.

Stepping on LilyPond’s toes is in the eye of the developer - what you consider 
stepping on LilyPond’s toes may not be for someone else and vice-versa.  All of 
us are LilyPond’s toes.

I agree that it makes sens to work towards more toe room.  I don’t think this 
alone will make LilyPond viable in the long run.

> 
> In our current developer base, I don't see much more than a theoretical
> interest in modularity and usability: many of the developers have become
> settled in the status quo which works for them.  Most contributions are
> rather focused about creating new functionality rather than making
> existing functionality more accessible or even consolidate what we
> already have.
> 
> There are changes like
> 
> commit 38a4081efa4a8ee2f5da780ca0ed2991627afc46
> Author: David Kastrup 
> Date:   Sun Sep 30 02:21:00 2012 +0200
> 
>Issue 2869: Regularize lyrics lexer mode
> 
>That makes lyrics mode rather similar to markup mode regarding how
>words are formed.  {} are never considered part of words unless
>enclosed in quotes.  Unquoted words do not contain whitespace, braces,
>quotes, backslashes, numbers or Scheme expressions.  In addition, they
>cannot start with * . = and | since that would mess with duration,
>assignment and barcheck syntax.  This removes some remaining
>TeX-oriented cruft in the lexer.  The set of word-non-starters might
>need revisiting, but at least the regtests seem to pass.
> 
> where a similar change in syntax happened for markups in 2004 if I read
> this correctly:
> 
> commit 3d04206a83222e89d99ddf1a0766b6b74f158967
> Author: Nicolas Sceaux 
> Date:   Sun Nov 28 17:50:32 2004 +
> 
>* lily/parser.yy: get rid off < > in markups by treating { } as
>real lists.
> 
>* lily/lexer.ll: remove < > from markup lexer mode.
> 
> This change was cited

Re: branching

[Mike Solomon]

On Dec 11, 2013, at 11:36 AM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> I had coffee with a developer a year or so ago who told me that he
>> dropped out of the project because of commutation problems with David.
>> Last night I wrote to him to share some of these frustrations and he
>> wrote back: “as long as David is leading up the team, it’s a lost
>> cause, nothing has changed and his way of acting is too problematic,
>> independently of his technical excellence.”  I tend to conceive of
>> problems in terms of one, two, or many.  The problem here has reached
>> the “many" level and I think we need to find a solution that goes
>> beyond the individual.  List-etiquette policies, branching policies -
>> I’m open to trying anything.
> 
> [...]
> 
>> What I’d like to see is a situation where David can blow off steam
>> however he needs to, he doesn’t feel like people are ignoring him,
> 
> You are aware that the above are mutually exclusive?  If people consider
> any negative feedback as "blowing off steam", that exactly implies
> suggesting to ignore it.
> 
> If you take a look at the communications with you that escalated, the
> escalation happened _exactly_ because you did not take seriously what
> I said.  So I stated my point more strongly.

Your e-mail merits a thorough response, but I should state immediately a 
corollary to this.

I get negative feedback all the time from the community (we all do).  What I 
mean is that there is the component not to ignore (the content) and the 
component to ignore (any abrasiveness used in the transmission of the content). 
 Blowing off steam refers to the latter.  That said, the more abrasive 
communication gets, the more difficult it is to determine its content.

I always take what you say seriously - as seriously as any other developer.  I 
certainly don’t claim to always get it, and sometimes you may need to restate 
things because I don’t get them.  This restating may be frustrating for you, 
but it does not ever necessitate communication that would make people want to 
leave the project.

More to come after I read through your e-mail.

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

Re: centralization of lilypond development and forking (was: branching)

[Mike Solomon]

On Dec 11, 2013, at 9:18 AM, Graham Percival  wrote:

> On Wed, Dec 11, 2013 at 08:39:58AM +0200, Mike Solomon wrote:
>>   See:
>>   
>> http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870
>>   as one of several examples.  There is truth in anything David says,
>>   meaning that I (like him (and most of us on this list)) have caused bugs
>>   that I did not find or fix before someone else.  How, does this warrant
>>   this communication style?
> 
> Interesting.  I totally agree that lilypond has a problem (see
> below), but in that email chain I find myself nodding along with
> David.  I mean, he makes empirical claims (such as documentation
> about partial elliptic stencils) that I assume are accurate (since
> I doubt he would make empirical claims without checking that they
> are true).
> 

Anything empirical in there is accurate.

> 
> However, I am not blind to the end result of the communications.
> I mean, at the beginning of September 2012 (after the meeting at
> the ranch) I was more enthusiastic about LilyPond than I had been
> for the previous 5 years, but one month later I decided to pretty
> much quit the project.

This is bad.  If this were some ultimate, fatalistic consequence of 
participation in any open-source project, I’d shrug and move onto the next, but 
it is precisely because in every other project I participate in this _doesn’t_ 
exist that I’m going through pains to try to solve this here.

Cheers,
MS


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

Re: branching

[Mike Solomon]

On Dec 11, 2013, at 12:03 AM, David Nalesnik  wrote:

> 
> Hi,
> 
> On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson  
> wrote:
> On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon  wrote:
> 
> The only hassle for me, which I did not run up against when I started with 
> the project, is David’s way of communicating.  I’m not claiming this is all 
> on him, but I’m also pretty sure that I’m not the only one who has peaced out 
> because of this.  I am looking for ways for this to no longer be an issue.  I 
> was hoping that branches would go a way towards making this happen for myself 
> and hopefully other developers, but it’s clear that this is not a good idea.
> 
> In my two day jobs, director of the ensemble 101 and developer for the Guido 
> project, I work with two (very different) teams of people on projects that 
> require creativity, consistency, and tons of communication.  Neither of them 
> has any of this friction resulting from communication issues, both of them 
> enjoy a diversity in major contributions, and both are evolving rapidly and 
> stably in several interesting ways at the same time.  I truly hope that 
> LilyPond can be like that.
> 
> 
> I don't know how you communicate with your other two teams,

Face-to-face communication for one, e-mail for another.

> I always feel a bit silly writing emoticons and exclamation points, but they 
> are nice to see(!)
>  
> It is regrettable that you would let such things interfere with your 
> contributions to LilyPond.
> 
> Exactly.  Both you and David are invaluable to this project.  I watched the 
> paralysis set in, the deadlock, and wondered a bit about the future of the 
> project.  I think there has to be some compromise in this 
> Apollonian/Dionysian test of wills (to throw in a little pretentiousness).

See:
http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870
as one of several examples.  There is truth in anything David says, meaning 
that I (like him (and most of us on this list)) have caused bugs that I did not 
find or fix before someone else.  How, does this warrant this communication 
style?  This chain of e-mails was the single determinant that ruled LilyPond 
out of a government funded, multi-national European typesetting project I’m 
organizing in which the team will need to extend aspects of the software.  I 
imagined the score of man hours that goes into all the projects I do and how 
important team morale is over the long term.  I don’t want anyone on my team to 
lose time feeling bad from e-mail confrontations - it’s not worth it for many 
reasons.

>  
> Ultimately, it is about the project, not the people. Perhaps 
> counter-intuitively, the answer to the problem you perceive is not to reduce 
> participation, but to increase participation. In my own case, my interactions 
> with David had the effect of getting me more involved in the "behind the 
> scenes" workings of the code. Why? So that eventually, David won't be able to 
> criticize me for not being willing to "get my hands dirty."
> 
> Well, I ordinarily have a bit of a thin skin, and I remember reading 
> somewhere on the lists that you have to have some nerve to contribute.  My 
> personal response to the possibility of brutally honest criticism--which is a 
> necessary thing if this project isn't going to go to hell--is to make sure 
> I've got everything as polished as I can make it before I make it public.  
> And accepting that I've got a lot to learn,  (This is about me, and is in no 
> way directed at you, Mike.)

Of course I have a lot to learn, too.

I release things in various states of polished-ness to the list, often because 
its their unpolished-ness that I need comments or opinions on.  This in and of 
itself is valuable information.  Imagining a hypothetical scenario where I sent 
a patch that someone wants to see restructured into several commits before they 
can review it.  One developer responds:

It’s difficult for me to understand what you’re doing - please split it up.

and another responds:

Please act like a member of the community, start taking other people into 
consideration and split up your patches.

The information is the same, but (A) makes me want to stay in the project a lot 
more than (B).  A lot of (B) causes me to lose interest.  How does one proceed? 
 Should one gloss over the way (B) is written and get (A) out of it?  Should 
one respond to (B) on its own terms?  How does one let these things not 
interfere with one’s contributions?

I currently have a boss who is an industry-expert in typesetting that decided 
not to get involved with LilyPond development 3 or 4 years ago because of feuds 
he saw on the devel list.  This is not good.  By old developers not 
contri

Re: branching

[Mike Solomon]

On Dec 10, 2013, at 9:32 PM, Carl Sorensen  wrote:

> 
> 
> On 12/10/13 5:42 AM, "Mike Solomon"  wrote:
> 
>> Hey all,
>> 
>> As 2.18 draws near, I¹d like to work with everyone to establish a system
>> of branching for LilyPond development.  After several rounds of
>> discussing things with David K, this emerged as the best way to avoid
>> arguments about integrating work into the development branch that have
>> led several contributors, including myself, to significantly reduce time
>> on the project. 
> 
> This seems like a nightmare to me.  It is good for somebody who wants to
> get their features out the the user base.  But this just makes the
> decisions about what to include in the development branch more emotionally
> charged.

It seems like everyone agrees, so this is definitely not the way to go.

> I'll present a hypothetical exchange between two caricatures:
> the creative developer who is only concerned about adding a really neat
> feature, and doesn't care how it affects the code base; and the consistent
> developer who is only concerned about the consistency of the code base,
> and would rather have no new features added than have a new feature added
> that requires contortions in the syntax, the parser/lexer, or the code
> base.

This is a fantastic hypothetical exchange.

> 
> 
>> [1]  I feel that this reduction in commit diversity is the biggest
>> obstacle to LilyPond¹s future evolution, which is why I¹m calling on
>> everyone to make a concerted effort to think this through.
> 
> 
> I have made a concerted effort to think this through. I believe that a
> reduction in commit diversity is a serious problem.  I think the community
> was greatly weakened when Mike felt that it was no longer worth putting up
> with the hassles to make his contributions.
> 
> However, I think that a fractured development branch (up to 6 different
> branches) would be an even bigger obstacle to future evolution.  I think
> it would lead to a balkanization of LilyPond.
> 
> Of course, given my participation in development over the last couple of
> years, my input may not be worth much.

After seeing people’s responses, I agree.  It is obvious from everyone’s 
reflections (especially yours, which is very thorough) that if branches become 
an institutionalized feature of development, they will hurt LilyPond.  I 
rescind my idea.

The only hassle for me, which I did not run up against when I started with the 
project, is David’s way of communicating.  I’m not claiming this is all on him, 
but I’m also pretty sure that I’m not the only one who has peaced out because 
of this.  I am looking for ways for this to no longer be an issue.  I was 
hoping that branches would go a way towards making this happen for myself and 
hopefully other developers, but it’s clear that this is not a good idea.

In my two day jobs, director of the ensemble 101 and developer for the Guido 
project, I work with two (very different) teams of people on projects that 
require creativity, consistency, and tons of communication.  Neither of them 
has any of this friction resulting from communication issues, both of them 
enjoy a diversity in major contributions, and both are evolving rapidly and 
stably in several interesting ways at the same time.  I truly hope that 
LilyPond can be like that.

Thank you for taking the time to think this over and for your response.

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

Re: branching

[Mike Solomon]

On Dec 10, 2013, at 4:23 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> Hey all,
>> 
>> As 2.18 draws near, I’d like to work with everyone to establish a
>> system of branching for LilyPond development.  After several rounds of
>> discussing things with David K, this emerged as the best way to avoid
>> arguments about integrating work into the development branch that have
>> led several contributors, including myself, to significantly reduce
>> time on the project. [1]
> 
> It will take me considerable time to address this more thoroughly, but
> in the mean time I want to have on record that what Mike writes here
> under "this emerged as the best way" _not_ in _any_ way summarizing our
> discussion.  Instead it is his _personal_ idea how to address topics we
> covered.  Writing something like "this emerged as the best way" when we
> did not even talk about it wrongly insinuates that it presents a common
> understanding of how to address problems covered in the discussion.
> 

Sorry, I in no way mean to apply that this is a proposition on David’s behalf.  
This is a proposition from me that it is a response to our discussion, not a 
summary of it.

> Feel free to quote passages or complete mails from me in the course of
> that discussion: there is nothing in there that I would not have equally
> said in public.


(quotes from David)

The basic idea behind that is not to make confrontations nicer but
reduce the necessity for them by establishing playing fields with
different authorities.  So that people can get work done without
endangering the release, and I can get releases done without pissing
people off as a prerequisite.

We won't be able to completely separate the two, but both our current
code base and our current development model are quite bad for getting
this under control.

…

As I said: there are certainly decisions where a vote does make sense:
mostly when there is a choice between alternatives.  For "go ahead or
not" kind of decisions, the answer should likely be "go ahead in a
sandbox, and with enough exposure of the sandbox to testers and end
users, we'll be better equipped to make an informed decision".

That's how it tends to work with the Linux kernel, but both our code
base as well as our infrastructure is not really diverse enough to make
this easy.  It _would_ be easier in a Scheme universe, or with loadable
C++ modules.  But either case requires that enough of the internals are
implemented through exchangeable interfaces that swapping out key parts
for user-written code can be done without disrupting too many unrelated
parts in the process.

…

My proposal is a first-pass at starting a dialogue about this that people can 
respond to - I expect some or all of it to be rejected, but the important thing 
is to start talking about it now.

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

Re: branching

[Mike Solomon]

On Dec 10, 2013, at 2:58 PM, Graham Percival  wrote:

> On Tue, Dec 10, 2013 at 02:42:45PM +0200, Mike Solomon wrote:
>> On the website, we would offer _all_ of these development
>> branches, including the one built off of staging, as GUB builds.
> 
> A few years ago, we were asked to cut our downloads down to 5 GB.
> I deleted a bunch of devel stuff and got it down to 7 or 8, but
> we're probably back to 15 GB now.  I don't think we should fill up
> the server with that many builds, nor do I think we should ask
> James to do all that building.

I agree about the not asking James part - this should be split up (different 
gubs making different builds).
As for the filling the server part, this seems like something that can be 
solved with alternate hosting sites for the download links.

> 
>> We would also contain a tracker showing number of downloads and
>> encouraging users to download the branches that have been
>> downloaded the _least_.
> 
> I don't like the idea of treating users as guinea pigs.  If
> somebody wants to test out devel stuff, it's not unreasonable for
> them to compile it themselves (inside lilydev if necessary).

I don’t either, but I do like the idea of asking them to be guinea pigs.
To this end, I’ll send an e-mai to the users list about this.

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

branching

[Mike Solomon]

Hey all,

As 2.18 draws near, I’d like to work with everyone to establish a system of 
branching for LilyPond development.  After several rounds of discussing things 
with David K, this emerged as the best way to avoid arguments about integrating 
work into the development branch that have led several contributors, including 
myself, to significantly reduce time on the project. [1]  I feel that this 
reduction in commit diversity is the biggest obstacle to LilyPond’s future 
evolution, which is why I’m calling on everyone to make a concerted effort to 
think this through.

There seem to me to be two main issues to sort out in doing this:
** how to get developers into the habit of working on separate git branches
** how to get users using these branches

I have opinions about both, which I will state below.  After some go around, 
I’d like to see something written up as a community-endorsed proposal that 
would then be implemented by myself and whoever else wants to help me out.

** how to get developers into the habit of creating separate git branches

Several developers would create development branches, i.e. devel-dk, etc.. 
These branches have no theme other than their being the principal sandbox of a 
particular developer or group of developers.  There would also be a devel-jd 
for John Doe, meaning anyone who does not have their own branch.  All of these 
branches would track staging.  We would limit the number of these branches to 
around 5.  Work on staging would then consist _only_ in merging these branches 
(or cherry picking commits from them) to staging.  These merges would be 
regular, part of the countdown cycle and discussable.  Patch review would exist 
just as now, except that “push” means that things get pushed to one of these 
branches instead of to staging.  Developers who don’t know how to use git’s 
branch features would be given help by those who know how.

** how to get users using these branches

On the website, we would offer _all_ of these development branches, including 
the one built off of staging, as GUB builds.  We would also contain a tracker 
showing number of downloads and encouraging users to download the branches that 
have been downloaded the _least_.  This would allow us to ensure that all 
branches are being tried out.  On the website, developers could also request 
that certain users use certain branches.  For example, if I were doing a lot of 
lyric work, I would ask on the website for people frequently using lyrics to 
use my branch.

I’m looking forward to hearing everyone’s ideas on this.

Cheers,
MS

[1] Development branches should not be construed as a substitute for collegial 
communication in our community, irrespective of the degree of difference 
between any of its members.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 10, 2013, at 12:18 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> On Dec 10, 2013, at 11:47 AM, David Kastrup  wrote:
>> 
>>> Nope.  In this case, the answer is to cache frequently accessed
>>> information instead of requesting it again and again.
>>> 
>>> We don't want to give people a choice between different ways in which
>>> LilyPond will be bad.  We just don't want LilyPond to be bad.
>> 
>> In my initial patches, which involved caching everything, there was no
>> appreciable speed-up on Mac and Linux.
> 
> Maybe caching in unsuitable form?  Cached data should be in a form
> directly usable for processing (with some possible tradeoffs between
> memory impact and unpacking speed), not in the form that
> function/library/system calls will return it.

I had cached skylines, although it’s true that it is possible to cache results 
to function calls (i.e. calls to Skyline::distance for the exact same two 
skylines).

Or there may be a better way to cache the skylines.  But LilyPond takes a 
looot of time in Skyline distance calculations.

> 
>> I did not test it on Windows, but I don’t remember Windows users
>> (Janek) reporting back problems).
> 
> Well, sounds like hen-and-egg here: we need more serious users to give
> more definite feedback, so that we can make LilyPond more suitable for
> more serious users.
> 
>> I would be interested to do rigorous testing on Windows.  It is not
>> hard to do - it requires creating a Scheme hash linking glyph names to
>> skylines.
>> 
>> I still advocate allowing users to specify a speed/beauty tradeoff,
>> which can be done in concert with optimization to LilyPond’s core.
> 
> That makes only sense where there is an incurable reason for a large
> tradeoff.  "in concert with optimization to LilyPond's core" is, in my
> experience, a buzzphrase.  In particular the word "optimization" tends
> to be construed as "somewhat tune an unsuitable algorithm, making it
> inscrutable in the process".
> 
> I know that this use of "optimization" is widespread, but I have a
> thorough dislike for it.  Almost any task can be algorithmically cast
> into the n lg (n) category which, with modern processors, is usually
> doable without having to think about tradeoffs.
> 


I agree that the main goal should be speeding up the algorithm while 
maintaining, if not augmenting, its understandability.

Cheers,
MS


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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 10, 2013, at 11:47 AM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> On Dec 10, 2013, at 11:27 AM, David Kastrup  wrote:
>> 
>>> Mike Solomon  writes:
>>> 
>>>> On Dec 10, 2013, at 10:36 AM, Keith OHara  wrote:
>>>>> 
>>>>> I did speed-test that patch, but under Linux.  Maybe the system
>>>>> calls to the font server, to get outlines for the glyphs, take
>>>>> longer under Windows.
>>>> 
>>>> One easy way to avoid this is to turn off this feature with
>>>> vertical-skylines = ##f for lots of grobs - I do this often for big
>>>> scores when I want to compile them fast, but I reactivate the more
>>>> accurate vertical skylines for the final version.
>>> 
>>> Sigh.  It's stuff like that which really makes me pessimistic about the
>>> prospects of LilyPond as serious software.
>>> 
>>> If its developers consider it unusable for serious work out of the box
>> 
>> It’s the opposite - I use the out of the box settings for serious work
>> - it’s the unserious playing around that I try to speed up.
> 
> How is "unserious playing around" not part of a serious creative work
> flow?
> 

It is - I misunderstood what you said.

For years, starting with Graham Percival, we’ve been kicking the around the 
idea of invoking LilyPond at various speed/beauty tradeoffs.  I am for this, 
but to date there have been no propositions that gel with the entire community. 
 I have suggested turning off all my sideline work as a default, but people 
feel this would not be the best option, so for now, we have it all, which is 
also not the best option.  I stand by Graham’s idea.

>> I’ve said on several occasions that I’m indifferent deactivating some
>> or all of vertical skylines as a default.  Several people are against
>> this deactivation (notable Janek).
> 
> If we have more than a factor of 2 in timing involved between Linux and
> Windows, then we do too much repeated processing in the font server.
> 
>> I’d be interested in gradations of UI options called perhaps:
>> 
>> \faster-but-uglier
>> \a-lot-faster-but-a-lot-uglier
>> \ridiculously-fast-and-heinously-ugly
> 
> Nope.  In this case, the answer is to cache frequently accessed
> information instead of requesting it again and again.
> 
> We don't want to give people a choice between different ways in which
> LilyPond will be bad.  We just don't want LilyPond to be bad.
> 

In my initial patches, which involved caching everything, there was no 
appreciable speed-up on Mac and Linux.  I did not test it on Windows, but I 
don’t remember Windows users (Janek) reporting back problems).

I would be interested to do rigorous testing on Windows.  It is not hard to do 
- it requires creating a Scheme hash linking glyph names to skylines.

I still advocate allowing users to specify a speed/beauty tradeoff, which can 
be done in concert with optimization to LilyPond’s core.

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 10, 2013, at 11:27 AM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> On Dec 10, 2013, at 10:36 AM, Keith OHara  wrote:
>> 
>>> On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup  wrote:
>>> 
>>>> "Keith OHara"  writes:
>>>> 
>>>>> I timed one big score, Movement 1 of
>>>>> <http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793>
>>>>>2.16.2  2.17.95
>>>>> WinXP   2m 30s  5m 10s
>>>>> Fedora  1m 50s  1m 50s
>>> 
>>>> Have you used the GUB-compiled binary package, or Fedora's built-in or a
>>>> self-compiled package?  I think that you probably can only make
>>>> platform-specific comparisons if you use GUB for all.
>>> 
>>> GUB-compiled packages in all cases give the same results as above.
>>> 
>>> Most of the increase in time to set this score happened between 2.17.0 and 
>>> .1
>>> 2.16.2 2m 30s
>>> 2.17.0 2m 28s
>>> 2.17.1 4m 06s
>>> so it is probably the issue 2148 patch, use of outlines instead of
>>> boxes for layout.
>>> 
>>> I did speed-test that patch, but under Linux.  Maybe the system
>>> calls to the font server, to get outlines for the glyphs, take
>>> longer under Windows.
>> 
>> One easy way to avoid this is to turn off this feature with
>> vertical-skylines = ##f for lots of grobs - I do this often for big
>> scores when I want to compile them fast, but I reactivate the more
>> accurate vertical skylines for the final version.
> 
> Sigh.  It's stuff like that which really makes me pessimistic about the
> prospects of LilyPond as serious software.
> 
> If its developers consider it unusable for serious work out of the box

It’s the opposite - I use the out of the box settings for serious work - it’s 
the unserious playing around that I try to speed up.

I’ve said on several occasions that I’m indifferent deactivating some or all of 
vertical skylines as a default.  Several people are against this deactivation 
(notable Janek).  I’d be interested in gradations of UI options called perhaps:

\faster-but-uglier
\a-lot-faster-but-a-lot-uglier
\ridiculously-fast-and-heinously-ugly

that people can invoke at the top level to speed things up but get uglier 
results.  This is trivial to implement, but I’d be interested to hear what 
UI-savvy people think.

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

Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 10, 2013, at 10:36 AM, Keith OHara  wrote:

> On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup  wrote:
> 
>> "Keith OHara"  writes:
>> 
>>> I timed one big score, Movement 1 of 
>>> 
>>> 2.16.2  2.17.95
>>> WinXP   2m 30s  5m 10s
>>> Fedora  1m 50s  1m 50s
> 
>> Have you used the GUB-compiled binary package, or Fedora's built-in or a
>> self-compiled package?  I think that you probably can only make
>> platform-specific comparisons if you use GUB for all.
> 
> GUB-compiled packages in all cases give the same results as above.
> 
> Most of the increase in time to set this score happened between 2.17.0 and .1
> 2.16.2 2m 30s
> 2.17.0 2m 28s
> 2.17.1 4m 06s
> so it is probably the issue 2148 patch, use of outlines instead of boxes for 
> layout.
> 
> I did speed-test that patch, but under Linux.  Maybe the system calls to the 
> font server, to get outlines for the glyphs, take longer under Windows.
> 

One easy way to avoid this is to turn off this feature with vertical-skylines = 
##f for lots of grobs - I do this often for big scores when I want to compile 
them fast, but I reactivate the more accurate vertical skylines for the final 
version.

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

Re: Some audicious hand-engraved slurs compared to LilyPond

[Mike Solomon]

On Dec 3, 2013, at 4:51 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> On Dec 3, 2013, at 4:19 PM, David Kastrup  wrote:
>> 
>>> David Nalesnik  writes:
>>> 
>>> 
>>> So I wanted to share the slurs, and then LilyPond surprised me with
>>> awful tuplet numbers.
>> 
>> I’m guessing that there are a few things stopping the number from
>> lining up nicely, but the most glaring one is line 526 of
>> lily/tuplet-bracket.cc, which specifies that tuplet brackets should
>> not follow kneed beams.
> 
> I find the version cranked out when setting
> TupletBracket.bracket-visibility to ##t quite defensible.
> 
> I don't find it defensible that tuplet brackets interfere with tuplet
> number placement when there are no actual tuplet brackets being typeset.
> 

The logic inside LilyPond is that tuplet numbers should always occupy the same 
position, irrespective of the presence of a tuplet bracket.  When tuplet 
brackets are not visible, a phantom one is calculated that tuplet numbers are 
positioned off of.

The EP snippet you’ve found is a good example of a case where this rule breaks 
down.  My gut feeling is that tuplet numbers for kneed beams should follow the 
beam if the bracket is not visible and if there is no collision between a stem 
and the tuplet number.  Perhaps this is generalizable to a bigger class of 
tuplet numbers, but that’s what comes to mind for now.

To get placement of the tuplet number like the EP snippet, one can do \override 
TupletBracket.direction = #UP.  This results in ugly slurs and a collision 
between the septuplet figure and the B-flat…belch…

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

Re: Some audicious hand-engraved slurs compared to LilyPond

[Mike Solomon]

On Dec 3, 2013, at 4:19 PM, David Kastrup  wrote:

> David Nalesnik  writes:
> 
> 
> So I wanted to share the slurs, and then LilyPond surprised me with
> awful tuplet numbers.

I’m guessing that there are a few things stopping the number from lining up 
nicely, but the most glaring one is line 526 of lily/tuplet-bracket.cc, which 
specifies that tuplet brackets should not follow kneed beams.

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

Communication style on the devel list

[Mike Solomon]

On Nov 30, 2013, at 10:58 PM, Janek Warchoł  wrote:

> 2013/11/30 Mike Solomon :
>> I would argue that the point that Janek brings up above is not a healthy 
>> sign for LilyPond development.
>> Several developers, including myself, have lowered their participation 
>> considerably over the past two years.
> 
> Maybe i should ask the question "why are you less active?".  But i
> don't want to be overly inquiring; i assume that your job and family
> simply takes so much time that you cannot do LilyPond work.
> 
> Janek

Nothing to do with either of those - after a series of difficult conversations 
on the developer list, I informed the community that I’d be taking time off the 
project:

http://lilypond.1069038.n5.nabble.com/Re-stencil-integral-use-box-extents-specified-in-markup-issue-3255-issue-9295044-td149952.html

This was about a patch that ultimately made its way into the code base 
(a6efcfa82dae01859f0d6d3bbfbaaa6f2eeb8a9c, modified and pushed by Keith 
O’Hara).  I made this decision after having asked several times to keep the 
communication between developers cordial and collegial.

Insofar as I do not believe I am the only person who has run into this issue, I 
think this is a hindrance to LilyPond development that needs to be addressed by 
the community.

Cheers,
MS

P.S. I changed the subject of this thread because I am now addressing a 
different issue.  I do not want this message to be construed in any way as an 
advisement against supporting David being paid for his valuable and essential 
contributions to LilyPond.___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: v_size in lexer.cc

[Mike Solomon]

On Nov 13, 2013, at 12:11 AM, Keith OHara  wrote:

> Mike Solomon  mikesolomon.org> writes:
> 
>> out/lexer.cc:32:25: error: prototype for
>> 'size_t yyFlexLexer::LexerInput(char*, size_t)'
>> does not match any in class 'yyFlexLexer'
>> out/lexer.cc:6460:8: note: in expansion of macro 'yyFlexLexer'
>> size_t yyFlexLexer::LexerInput( char* buf, size_t max_size )
>^
>> /usr/local/opt/flex/include/FlexLexer.h:133:14: candidate is: 
>>  virtual int LexerInput( char* buf, int max_size );
> 
>> Could be a versioning problem with Flex?
> 
> Other groups have found this problem.  
> Could you see if their solutions work for you, and might be applied
> by LilyPond?  The first hit is :
> http://bugs.launchpad.net/zorba/+bug/1034582
> 

Works fine - I just have to build flex from scratch and use that. Many thanks!

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

v_size in lexer.cc

[Mike Solomon]

Hey all,

Compiling LilyPond with g++ on mac os x, I get the following errors:

out/lexer.cc: At global scope:
out/lexer.cc:32:25: error: prototype for 'size_t yyFlexLexer::LexerInput(char*, 
size_t)' does not match any in class 'yyFlexLexer'
 #define yyFlexLexer yyFlexLexer
 ^
out/lexer.cc:6460:8: note: in expansion of macro 'yyFlexLexer'
 size_t yyFlexLexer::LexerInput( char* buf, size_t max_size )
^
In file included from out/lexer.cc:383:0:
/usr/local/opt/flex/include/FlexLexer.h:133:14: error: candidate is: virtual 
int yyFlexLexer::LexerInput(char*, int)
  virtual int LexerInput( char* buf, int max_size );
  ^
out/lexer.cc:32:25: error: prototype for 'void yyFlexLexer::LexerOutput(const 
char*, size_t)' does not match any in class 'yyFlexLexer'
 #define yyFlexLexer yyFlexLexer
 ^
out/lexer.cc:6487:6: note: in expansion of macro 'yyFlexLexer'
 void yyFlexLexer::LexerOutput( const char* buf, size_t size )
  ^
In file included from out/lexer.cc:383:0:
/usr/local/opt/flex/include/FlexLexer.h:134:15: error: candidate is: virtual 
void yyFlexLexer::LexerOutput(const char*, int)
  virtual void LexerOutput( const char* buf, int size );
   ^


For the errors, the fix is easy - I just manually change everything to int.  
But I figured I’d signal this in case anyone knew how to fix it.  Could be a 
versioning problem with Flex?

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

Re: Continuing towards 2.18

[Mike Solomon]

On Nov 5, 2013, at 9:23 AM, David Kastrup  wrote:

>  So I'm
> more comfortable reverting it as well.
> 

Go for it, but could someone please remind me to push it to 2.19 if I forget?

Cheers,
MS


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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 2:20 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> On Nov 3, 2013, at 1:50 PM, David Kastrup  wrote:
>> 
>>> Shrug.  At any rate, it would be important to get some feedback
>>> regarding installation of the stock LilyPond binary distribution on the
>>> newest OSX.  It would be good if that worked before we put out 2.18.
>> 
>> http://lists.gnu.org/archive/html/lilypond-user/2013-10/msg00897.html
> 
> Sounds good.
> http://lists.gnu.org/archive/html/lilypond-user/2013-10/msg00890.html>
> sounds like something the average user might have problems discovering.
> Any second opinion on that?

I had the same problem when I installed InScore and had no clue what to do…a 
colleague had to point it out to me.
May be worth adding a note to the docs.

Cheers,
MS


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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 2:03 PM, Mike Solomon  wrote:

> 
> On Nov 3, 2013, at 2:00 PM, Joseph Rushton Wakeling 
>  wrote:
> 
>> On 03/11/13 13:36, Mike Solomon wrote:
>>> Doesn’t work, but all the files in flower compile fine with gcc, so I’m a 
>>> happy camper.
>>> Apple’s home cooked clang is not free software, so there’s no reason to 
>>> expect free software to compile with it.  I don’t mind giving up on it.
>> 
>> It's difficult to see how they could have cooked it to the point where what 
>> is AFAICS fairly standard C/C++ fails to compile with it.
>> 
>> Anyway, if you want to leave it here, no worries.  I just thought it might 
>> be useful for other people if we could tie down what the source of the 
>> problem is.
>> 
>> Just for reference, do you have a log of what happens when you try running 
>> ./configure with CC=clang and CXX=clang++?
>> 
> 
> Same exact problem with CC=clang and CXX=clang++.
> It’s not that I want to leave it here, but rather that I need to spend time 
> engraving. When I have time, I’ll try to make a minimal example and send it 
> to Apple.
> 
> Cheers,
> MS

Another thing (dunno if it’s relevant)…
The lily/out/lexer.cc generated by flex had the type size_t used in definitions 
of LexerInput and LexerOutput.  Something barfed during make and told me these 
had to be int, so I changed them by hand and everything kept chugging along.  
This seems kludgy, though…I’m guessing that multiple versions of flex may be 
being used, but I’m not sure.

Cheers,
MS


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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 2:00 PM, Joseph Rushton Wakeling 
 wrote:

> On 03/11/13 13:36, Mike Solomon wrote:
>> Doesn’t work, but all the files in flower compile fine with gcc, so I’m a 
>> happy camper.
>> Apple’s home cooked clang is not free software, so there’s no reason to 
>> expect free software to compile with it.  I don’t mind giving up on it.
> 
> It's difficult to see how they could have cooked it to the point where what 
> is AFAICS fairly standard C/C++ fails to compile with it.
> 
> Anyway, if you want to leave it here, no worries.  I just thought it might be 
> useful for other people if we could tie down what the source of the problem 
> is.
> 
> Just for reference, do you have a log of what happens when you try running 
> ./configure with CC=clang and CXX=clang++?
> 

Same exact problem with CC=clang and CXX=clang++.
It’s not that I want to leave it here, but rather that I need to spend time 
engraving. When I have time, I’ll try to make a minimal example and send it to 
Apple.

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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 1:50 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> Apple’s home cooked clang is not free software, so there’s no reason
>> to expect free software to compile with it.
> 
> Non sequitur.  There is nothing wrong with trying to bring some more
> taste of free software to people in the Apple jails.  Now there are
> alternative means, so it's not high urgency.  In particular, if you are
> the only person we've heard of so far and already moved to an
> alternative: we run into danger of putting in a lot of work for purely
> imaginary users.

It took me 15 minutes of work to compile with g++.  I can’t imagine that anyone 
who knows what they’re doing (TM) won’t be able to figure this out in a 
reasonable timeframe unless they have a seriously messed up computer.

> 
>> I don’t mind giving up on it.
> 
> Shrug.  At any rate, it would be important to get some feedback
> regarding installation of the stock LilyPond binary distribution on the
> newest OSX.  It would be good if that worked before we put out 2.18.

http://lists.gnu.org/archive/html/lilypond-user/2013-10/msg00897.html

Cheers,
MS

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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 1:15 PM, Joseph Rushton Wakeling 
 wrote:

> On 03/11/13 12:33, Mike Solomon wrote:
>> 
>> [ ... snip ... ]
>> 
>> …these fonts are always a pain, but I usually figure out some way to cheat 
>> and get them in there.  But that shouldn’t have anything to do with the 
>> compiler.
> 
> Well, what's odd is that your ./configure script says that it finds gcc:
> 
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
> 
> and g++:
> 
>> checking for g++... g++
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether g++ accepts -g... yes
>> checking how to run the C++ preprocessor... g++ -E
>> checking for grep that handles long lines and -e... /usr/bin/grep
>> checking for egrep... /usr/bin/grep -E
>> checking whether we are using the GNU C++ compiler... (cached) yes
> 
> Yet your compile-time errors suggest that it is in fact clang that's being 
> used.
> 
> So, I suggest instead of just running ./configure, try instead:
> 
>CC=clang CXX=clang++ ./configure
> 
> ... and then see if the build works.  (You can also add your custom CPPFLAGS 
> to that.)
> 

Doesn’t work, but all the files in flower compile fine with gcc, so I’m a happy 
camper.
Apple’s home cooked clang is not free software, so there’s no reason to expect 
free software to compile with it.  I don’t mind giving up on it.

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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 11:45 AM, Joseph Rushton Wakeling 
 wrote:

> On 03/11/13 11:18, Mike Solomon wrote:
>> Yeah, the output is fine (clean bill of health, all systems go). I had to 
>> specifically set CPPFLAGS to deal w/ some homebrew issues, but otherwise 
>> nothing out of the ordinary.
> 
> Ahh, OK.  That's odd; OK, I accept that the clang you have has been a little 
> Applified, but I can't see an obvious reason why it should be fine to compile 
> Lilypond with clang 3.3 on Ubuntu, and not on Mac OS.
> 
> Obviously, do whatever you need to get things working and compiling again, 
> but if you're so inclined I think it'd be worth trying to work out what the 
> problem is -- it's better for Lilypond if it works with default Xcode.
> 
> Could you try doing a fresh clone of the Lilypond git repo and build in 
> there, just to test?
> 
> Oh, and -- could you copy-paste the output of running ./configure, just so I 
> can see?

mbp-de-mike:devel mikesolomon$ git clone 
mike...@git.sv.gnu.org:/srv/git/lilypond.git lilypond-gcc
Cloning into 'lilypond-gcc'...
remote: Counting objects: 363841, done.
remote: Compressing objects: 100% (60265/60265), done.
remote: Total 363841 (delta 303842), reused 362630 (delta 302851)
Receiving objects: 100% (363841/363841), 91.82 MiB | 148 KiB/s, done.
Resolving deltas: 100% (303842/303842), done.
Checking out files: 100% (4786/4786), done.
mbp-de-mike:devel mikesolomon$ cd lilypond-gcc
mbp-de-mike:lilypond-gcc mikesolomon$ mkdir build
mbp-de-mike:lilypond-gcc mikesolomon$ ./autogen.sh --noconfigure
processing .
Running autoconf ...
Skipping configure process.
mbp-de-mike:lilypond-gcc mikesolomon$ cd build/
mbp-de-mike:build mikesolomon$ CPPFLAGS="${CPPFLAGS} -I/usr/local/include 
-L/usr/local/lib" ../configure
checking build system type... x86_64-apple-darwin13.0.0
checking host system type... x86_64-apple-darwin13.0.0
checking Package... LILYPOND
checking builddir... /Users/mikesolomon/devel/lilypond-gcc/build
checking for stepmake... ../stepmake  (${datarootdir}/stepmake not found)
checking for gmake... no
checking for make... make
checking for find... find
checking for tar... tar
checking for bash... /bin/sh
checking for python... python
checking python version... 2.7.5
checking for python... /usr/bin/python
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether compiler understands -pipe... yes
checking for IEEE-conformance compiler flags... none
checking for fc-list... fc-list
checking for New Century Schoolbook PFB files... no
checking for python... /usr/bin/python
checking /usr/bin/python version... 2.7.5
checking for /usr/bin/python... (cached) /usr/bin/python
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking options for known g++ bugs... none
checking whether explicit instantiation is needed... no
checking for stl.data () method... yes
checking for ar... ar
checking for ranlib... ranlib
checking for dlopen in -ldl... yes
checking for dlopen... yes
checking for bison... bison -y
checking for bison... bison
checking bison version... 2.3
checking for flex... flex
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking FlexLexer.h usability... yes
checking FlexLexer.h presence... yes
checking for FlexLexer.h... yes
checking for yyFlexLexer.yy_current_buffer... no
checking FlexLexer.h location... clang: warning: argument unused during 
compilation: '-L/usr/local/lib'
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/FlexLexer.h
checking language... English
checking for gettext in -lintl... yes
checking for gettext... yes
checking for msgfmt... msgfmt
checking for mf-nowin... mf-nowin
checking for mpost... mpost
checking for working metafont mode... ljfour
checking for kpsewhich... kpsewhich
checking for metapost required files... yes
checking for guile-config... guile-config
checking guile-config version... 1.8.8
checking guile compile flags... -I/usr/l

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 11:15 AM, Joseph Rushton Wakeling 
 wrote:

> On 03/11/13 11:00, Mike Solomon wrote:
>> That’s fine, I’ll download gcc.
> 
> From what I understand from friends who've experienced the same, you'll have 
> to manually remove/rewrite some of the symlinks.
> 
> Just to check -- before you rework everything -- did you manually re-run the 
> configure script before building?  If so, what does it output?

Yeah, the output is fine (clean bill of health, all systems go). I had to 
specifically set CPPFLAGS to deal w/ some homebrew issues, but otherwise 
nothing out of the ordinary.

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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 10:37 AM, David Kastrup  wrote:

> Joseph Rushton Wakeling  writes:
> 
>> On 03/11/13 10:09, Mike Solomon wrote:
>>> Looks like some files in flower don't play nice with the most recent
>>> version of the standard library bundled with Xcode…
>>> 
>>> Any ideas for how to proceed?
>> 
>> If I understand right (I'm not a Mac user), latest Xcode has clang as
>> default compiler, and symlinks the gcc/g++ commands to clang/clang++.
> 
> The error messages strongly suggest Clang, yes.
> 
>> So, these errors most likely arise because Lilypond compilation has
>> never been tested with clang (apologies if I'm wrong, but I imagine
>> Lilypond development has always assumed GCC).
> 
> We committed a few Clang-related fixes in the past, I think mostly due
> to Graham's insistence/testing, but I think at some point of time the
> "compile with Clang" ambition just faded.

That’s fine, I’ll download gcc.

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

Re: compilation errors from Xcode's new standard library

[Mike Solomon]

On Nov 3, 2013, at 10:50 AM, Joseph Rushton Wakeling 
 wrote:

> On 03/11/13 10:37, David Kastrup wrote:
>> We committed a few Clang-related fixes in the past, I think mostly due
>> to Graham's insistence/testing, but I think at some point of time the
>> "compile with Clang" ambition just faded.
> 
> I just tried a clang-based build on my Ubuntu 13.10 system, just to see what 
> would happen:
> 
>make clean
>CC=clang CXX=clang++ ./configure
>make -j2
> 
> It built fine, and also quite a bit faster than a GCC build.
> 
> Version info:
>  Ubuntu clang version 3.3-5ubuntu4 (branches/release_33) (based on LLVM 3.3)
>  Target: x86_64-pc-linux-gnu
>  Thread model: posix
> 
> FWIW I've found it a good idea to test C/C++ codebases against clang if 
> nothing else because clang is rather better at identifying ambiguities and 
> potential errors and providing instructions for how to fix them.
> 
> Mike, can you try typing on a terminal prompt both:
> 
>   g++ --version
>   clang++ —version

So g++ simlinks to clang, and it is a special apple-brewed clang based on 3.3

mbp-de-mike:SCRIPTS mikesolomon$   g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

mbp-de-mike:SCRIPTS mikesolomon$ clang --version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

Cheers,
MS


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

Re: mac os x 10.9 and libguile.h

[Mike Solomon]

On Nov 2, 2013, at 1:46 PM, Mike Solomon  wrote:

> 
> On Nov 2, 2013, at 1:17 PM, David Kastrup  wrote:
> 
>> Mike Solomon  writes:
>> 
>>> 
> 
> 
> So this definitely gives a directory with libguile.h in it.  But for some 
> reason it’s not found by the configure script.
> 

Some more digging.  When I add:

AC_MSG_NOTICE($CPPFLAGS)
AC_CHECK_HEADERS([libguile.h])

to aclocal.m4 around line 694, the printout is:

configure: -I/usr/local/Cellar/guile18/1.8.8/include  -D_THREAD_SAFE  
checking libguile.h usability... no
checking libguile.h presence... no
checking for libguile.h... no

but then…

mbp-de-mike:build mikesolomon$ ls /usr/local/Cellar/guile18/1.8.8/include
guile   libguilelibguile.h

I’m stumped.  It is obvious that CPPFLAGS is pointing to a directory with 
libguile.h, but AC_CHECK_HEADERS doesn’t find it there. Running as root doesn’t 
help.

Does anyone know of diagnostic tools (perhaps a level of verbosity) to help 
figure out why configure doesn’t find certain things?

Cheers,
MS

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

compilation errors from Xcode's new standard library

[Mike Solomon]

Looks like some files in flower don't play nice with the most recent version of 
the standard library bundled with Xcode…


clang: warning: argument unused during compilation: '-mno-fused-madd'
clang: warning: argument unused during compilation: '-L/usr/local/lib'
In file included from /Users/mikesolomon/devel/lilypond/flower/file-path.cc:21:
In file included from 
/Users/mikesolomon/devel/lilypond/flower/include/file-path.hh:23:
In file included from 
/Users/mikesolomon/devel/lilypond/flower/include/std-vector.hh:74:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/vector:1330:12:
 error: 
  calling a private constructor of class
  'std::__1::__wrap_iter *>'
return iterator(__p);
   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/vector:1367:12:
 note: 
  in instantiation of member function
  'std::__1::__flower_vector,
  std::__1::allocator > >::__make_iter'
  requested here
return __make_iter(this->__end_);
   ^
/Users/mikesolomon/devel/lilypond/flower/include/std-vector.hh:155:15: note: in
  instantiation of member function
  'std::__1::__flower_vector,
  std::__1::allocator > >::end' requested here
  v.insert (v.end (), w.begin (), w.end ());
  ^
/Users/mikesolomon/devel/lilypond/flower/file-path.cc:52:3: note: in
  instantiation of function template specialization
  'concat >' requested here
  concat (dirs_, string_split (p, PATHSEP));
  ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iterator:1187:31:
 note: 
  declared private here
_LIBCPP_INLINE_VISIBILITY __wrap_iter(iterator_type __x) _NOEXCEPT ...
  ^
In file included from /Users/mikesolomon/devel/lilypond/flower/file-path.cc:21:
In file included from 
/Users/mikesolomon/devel/lilypond/flower/include/file-path.hh:23:
In file included from 
/Users/mikesolomon/devel/lilypond/flower/include/std-vector.hh:74:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/vector:1342:12:
 error: 
  calling a private constructor of class 'std::__1::__wrap_iter *>'
return const_iterator(__p);
   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/vector:1359:12:
 note: 
  in instantiation of member function
  'std::__1::__flower_vector,
  std::__1::allocator > >::__make_iter'
  requested here
return __make_iter(this->__begin_);
   ^
/Users/mikesolomon/devel/lilypond/flower/include/std-vector.hh:155:25: note: in
  instantiation of member function
  'std::__1::__flower_vector,
  std::__1::allocator > >::begin' requested
  here
  v.insert (v.end (), w.begin (), w.end ());
^
/Users/mikesolomon/devel/lilypond/flower/file-path.cc:52:3: note: in
  instantiation of function template specialization
  'concat >' requested here
  concat (dirs_, string_split (p, PATHSEP));
  ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iterator:1187:31:
 note: 
  declared private here
_LIBCPP_INLINE_VISIBILITY __wrap_iter(iterator_type __x) _NOEXCEPT ...
  ^


Going through the standard library files in question, here are some snippets…
I’ve added comments next to the problematic lines

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/vector

template 
_LIBCPP_INLINE_VISIBILITY inline
typename vector<_Tp, _Allocator>::iterator
vector<_Tp, _Allocator>::__make_iter(pointer __p) _NOEXCEPT
{
#if _LIBCPP_DEBUG_LEVEL >= 2
return iterator(this, __p);
#else
return iterator(__p); // MS  - this is where g++ freaks out
#endif
}


and then…
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lib/c++/v1/iterator

private:
_LIBCPP_INLINE_VISIBILITY __wrap_iter(iterator_type __x) _NOEXCEPT : 
__i(__x) {} // MS  - this is where g++ freaks out
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY __wrap_iter(const void* __p, iterator_type __x) : 
__i(__x)
{
__get_db()->__insert_ic(this, __p);
}
#endif
 



Any ideas for how to proceed?

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

Re: mac os x 10.9 and libguile.h

[Mike Solomon]

On Nov 3, 2013, at 9:37 AM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> mbp-de-mike:build mikesolomon$ ls /usr/local/Cellar/guile18/1.8.8/include
>> guilelibguilelibguile.h
>> 
>> I’m stumped.  It is obvious that CPPFLAGS is pointing to a directory
>> with libguile.h, but AC_CHECK_HEADERS doesn’t find it there. Running
>> as root doesn’t help.
>> 
>> Does anyone know of diagnostic tools (perhaps a level of verbosity) to
>> help figure out why configure doesn’t find certain things?
> 
> Uh, you are aware of config.log?  That's lots more verbose than the
> console output.


Ah, OK, easy fix, thanks.

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

Re: [Lilypond-auto] Issue 3631 in lilypond: 2.17 does a worse job with vertical spacing and/or the page layout than 2.16

[Mike Solomon]

On Nov 2, 2013, at 3:32 PM, Joseph Rushton Wakeling 
 wrote:

> On 02/11/13 15:12, Mike Solomon wrote:
>> Not sure what a git formatted patch is…I can, however, download the Rietveld 
>> patch and send it to you if you want.
> 
> Git can extract text patch files from your version history, which can then be 
> sent by email.  It's a simpler way of getting patches to/from people than 
> needing to publish branches.
> 

Ah, OK.

The issue is that I don’t want to send anything from my computer for pushing, 
as my libguile is broken and I’m not comfortable sending a patch for pushing 
unless I’ve done a clean compile with it once just in case.  The Rietveld 
version is the last reviewed and OKd one, so I’d prefer that someone pushes 
that.

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

Re: [Lilypond-auto] Issue 3631 in lilypond: 2.17 does a worse job with vertical spacing and/or the page layout than 2.16

[Mike Solomon]

On Nov 2, 2013, at 3:03 PM, lilyp...@googlecode.com wrote:

> 
> Comment #45 on issue 3631 by d...@gnu.org: 2.17 does a worse job with 
> vertical spacing and/or the page layout than 2.16
> http://code.google.com/p/lilypond/issues/detail?id=3631
> 
> Can do.  Can you send a git-format-patch by mail, or should I scrape this 
> together via Rietveld?
> 
> -- 
> You received this message because this project is configured to send all 
> issue notifications to this address.
> You may adjust your notification preferences at:
> https://code.google.com/hosting/settings
> 

Not sure what a git formatted patch is…I can, however, download the Rietveld 
patch and send it to you if you want.

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

Re: mac os x 10.9 and libguile.h

[Mike Solomon]

On Nov 2, 2013, at 1:17 PM, David Kastrup  wrote:

> Mike Solomon  writes:
> 
>> Hey all,
>> 
>> In my update to OS X 10.9, I’ve had to uninstall and reinstall lots of
>> stuff.  In the LilyPond configure script, I get
>> 
>> 
>> checking for guile-config... guile-config
>> checking guile-config version... 1.8.8
>> checking guile compile
>> flags... -I/usr/local/Cellar/guile18/1.8.8/include -D_THREAD_SAFE
>> checking guile link flags...  -D_THREAD_SAFE
>> -L/usr/local/Cellar/guile18/1.8.8/lib -lguile -lltdl -lgmp -lm -lltdl
>> checking libguile.h usability... no
>> checking libguile.h presence... no
>> checking for libguile.h... no
>> checking for scm_boot_guile in -lguile... no
>> checking for scm_boot_guile... no
>> checking for scm_t_hash_fold_fn... no
>> checking for scm_t_hash_handle_fn... no
>> checking for scm_t_subr... no
>> 
>> 
>> I checked in my /usr/local/Cellar/guile18/1.8.8/include and libguile.h
>> is indeed there.  Does anyone know where the configure script is
>> looking for libguile.h?
> 
> It will call
> 
> guile-config compile
> 
> I would assume, if it goes to the pain of finding guile-config first.


Hmm…:

mbp-de-mike:build mikesolomon$ guile-config compile
-I/usr/local/Cellar/guile18/1.8.8/include  -D_THREAD_SAFE 
mbp-de-mike:build mikesolomon$ ls /usr/local/Cellar/guile18/1.8.8/include
guile   libguilelibguile.h

So this definitely gives a directory with libguile.h in it.  But for some 
reason it’s not found by the configure script.

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

mac os x 10.9 and libguile.h

[Mike Solomon]

Hey all,

In my update to OS X 10.9, I’ve had to uninstall and reinstall lots of stuff.  
In the LilyPond configure script, I get


checking for guile-config... guile-config
checking guile-config version... 1.8.8
checking guile compile flags... -I/usr/local/Cellar/guile18/1.8.8/include  
-D_THREAD_SAFE 
checking guile link flags...  -D_THREAD_SAFE  
-L/usr/local/Cellar/guile18/1.8.8/lib -lguile -lltdl -lgmp -lm -lltdl
checking libguile.h usability... no
checking libguile.h presence... no
checking for libguile.h... no
checking for scm_boot_guile in -lguile... no
checking for scm_boot_guile... no
checking for scm_t_hash_fold_fn... no
checking for scm_t_hash_handle_fn... no
checking for scm_t_subr... no


I checked in my /usr/local/Cellar/guile18/1.8.8/include and libguile.h is 
indeed there.  Does anyone know where the configure script is looking for 
libguile.h?  And is there anyway to tell it where to find it?

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

Re: Looks for prebroken pieces of dead items in the pure relevant function. (issue 18090043)

[Mike Solomon]

On Nov 1, 2013, at 8:31 AM, lemzw...@googlemail.com wrote:

> 
> https://codereview.appspot.com/18090043/diff/60001/lily/axis-group-interface.cc
> File lily/axis-group-interface.cc (right):
> 
> https://codereview.appspot.com/18090043/diff/60001/lily/axis-group-interface.cc#newcode507
> lily/axis-group-interface.cc:507: should probably not check for suidided
> items or NULL pointers
> s/suidided/suicided/

Done.

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

Re: Looks for prebroken pieces of dead items in the pure relevant function. (issue 18090043)

[Mike Solomon]

On Nov 1, 2013, at 7:49 AM, k-ohara5...@oco.net wrote:

> On 2013/10/30 08:09:53, mike7 wrote:
>> On Oct 30, 2013, at 8:32 AM, mailto:k-ohara5...@oco.net wrote:
> 
>> > I do not understand the Todo: comment; nothing should have been
> suicided
>> > at this stage.
> 
>> The original clef is suicided in the handle_prebroken_dependencies
> function,
>> which is the same place that the new begin and end of line grobs are
> created
>> (see break-substitution.cc).
> 
>> Conceptually, I don’t like the idea that a suicided grob contains
> useful
>> information.
> 
> I see now.
> It seems that !is_live() means that we are sure the Grob will never be
> printed, yet we need to keep the data structure around for some other
> reason.  You might put your name on the "Todo" comment so people know
> the point of view is from somebody other that the original author of the
> handle_prebroken_dependencies() function.
> 

Ok.

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

Re: Looks for prebroken pieces of dead items in the pure relevant function. (issue 18090043)

[Mike Solomon]

On Oct 30, 2013, at 8:32 AM, k-ohara5...@oco.net wrote:

> I do not understand the Todo: comment; nothing should have been suicided
> at this stage.  What is the life cycle of a Clef and the copies made for
> line-breaking possibilities?

The original clef is suicided in the handle_prebroken_dependencies function, 
which is the same place that the new begin and end of line grobs are created 
(see break-substitution.cc).

> Is the never-printed original Clef /ever/
> is_live(), or just its broken copies?
> 

It is live before handle_prebroken_copies.  In this function, the broken copies 
are created, and then it is suicided.

Conceptually, I don’t like the idea that a suicided grob contains useful 
information.  You’ll see in the suicide function that its entire cache is 
cleared out (Grob::suicide) save one or two things (Item::suicide).  I think 
everything should be cleared out.  Otherwise, the code is less maintainable - 
developers will have to remember what type of information suicided grobs hold 
and what type they don’t.  That’s why I created 
https://code.google.com/p/lilypond/issues/detail?id=3636.

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

Re: Remove DynamicText from script-interface (issue 14424044)

[mike]

Make sure to acknowledge dynamic text in slur-proto-engraver.cc and
tuplet-engraver.cc.

https://codereview.appspot.com/14424044/

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

Re: Checks to see if tuplet brackets have bounds (issue 13582046)

[Mike Solomon]

On 13 sept. 2013, at 11:00, d...@gnu.org wrote:

> On 2013/09/13 08:41:42, Trevor Daniels wrote:
>> On 2013/09/13 07:09:44, mike7 wrote:
> 
>> > With respect to your point about null pointers and the nature of the
> patch, I
>> > agree that there needs to be a better way to handle this.  To me,
> the general
>> > problem seems to be "what do we do when we assume a grob will have
> something
>> > (bound, object, etc.) and it doesn't?"  Is the solution to suicide
> the spanner
>> > if it doesn't have bounds?  Is the solution to raise a programming
> error like
>> we
>> > do now (I prefer that solution)?
> 
>> LilyPond should always try to continue when an error is detected.
>> If the error is thought to be a user error a warning should be
>> issued and an assumption made about what was intended.  If the
>> error is thought to be due to faulty or missing code (as here) the
>> erroneous operation should be abandoned and a programming error
>> issued.  Reported programming errors should always be recorded in
>> an issue tracker unless one already exists.  At least that, I
>> believe, was the general approach adopted in the past and it seems
>> sound to me.
> 
> Well, being defensive is always a good idea.  It's just that when we get
> to _know_ the defenses to be triggered without us expecting it, we
> should make use of the opportunity to analyze what is going wrong here.
> 
> Mike says that the change is due to more crossstaff checks happening
> now.  I have no better guess here, but the issue description of issue
> 3199 does not at all mention crossstaff, and the error does not occur in
> a context or in code mentioning crossstaff.

To be more specific, when the pure height of axis groups is being calculated, 
it iterates over all pure relevant grobs to find their heights, throwing out 
cross staff grobs because their heights cannot be calculated because they are 
by definition not part of the axis group.

Tuplet brackets used not to be tagged pure relevant because we had those huge 
lists of what was and wasn't.  Now, pure relevant is a much larger list of 
grobs because pure relationships are articulated via unpure-pure-containers and 
not lists.  So, we iterate over a larger set of grobs.  What this means is that 
certain grobs that never had their cross-staffitude checked now do.

I believe that the correct approach is to make sure that every grob has a 
cross-staff function that can be called at _any_ time after engraving is done.  
Here, perhaps we should add extra checks before parallel beam is called to weed 
out boundless spanners.

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

Re: Checks to see if tuplet brackets have bounds (issue 13582046)

[Mike Solomon]

On 13 sept. 2013, at 08:41, d...@gnu.org wrote:

> 
> https://codereview.appspot.com/13582046/diff/1/lily/tuplet-bracket.cc
> File lily/tuplet-bracket.cc (right):
> 
> https://codereview.appspot.com/13582046/diff/1/lily/tuplet-bracket.cc#newcode99
> lily/tuplet-bracket.cc:99: if (!left || !right)
> Too many combinatorics involved unnecessarily.  Just do
> if (!left || left->break_status_dir ())
> first, and then the same for right.  Then one does not need to track the
> combination of left/right states at the same time in order to figure out
> which cases are caught.

Ok

> 
> At any rate, this does not appear to give us a beam: it just avoids a
> crash.  And there is no explanation of why this code would be called now
> when it wasn't called before issue 3199.

We check cross staff for a lot more things now.

> 
> Not sure whether one would call this related to issue 3299: issue 3299
> is for the case where _no_ other rhythmic elements share the time of the
> spacer rest.  Which is the case in the minimal example of the bug report
> but possibly not the only situation triggering the bug.
> 
> At any rate, this appears to be a symptomatic patch replacing a crash
> with a programming error and/or a bad result.  Which is an improvement
> but still seems to fall short of useful behavior.

In general, there is a lot of old code in the code base that assumes a valid 
pointer will be returned and uses that pointer to get information without 
checking if it is a null pointer.  This is an example of that.  The reason it 
was never triggered before is because the cross-staffitude of these grobs was 
not checked before.

Here's the way I see the history:
-) We create a tuplet bracket engraver that can create a tuplet bracket without 
bounds.
-) We create function that checks these bounds (parallel_beam).
-) Before 2.17, this function is not called when there are no bounds.

To me, the bug is not the calling of the function but rather creating a 
behavior in this (or any) function that assumes a non-null pointer will be 
returned.  There is always the possibility that that will happen.  I am guilty 
of coding this way as well, but I've tried to limit these types of assumptions 
and always check for null pointers.

With respect to your point about null pointers and the nature of the patch, I 
agree that there needs to be a better way to handle this.  To me, the general 
problem seems to be "what do we do when we assume a grob will have something 
(bound, object, etc.) and it doesn't?"  Is the solution to suicide the spanner 
if it doesn't have bounds?  Is the solution to raise a programming error like 
we do now (I prefer that solution)?

Cheers,
MS

> 
> https://codereview.appspot.com/13582046/


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

Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)

[Mike Solomon]

On 30 août 2013, at 11:39, d...@gnu.org wrote:

> 
>> > I suggest that we refrain from embracing your somewhat optimistic
>> > estimates until after wrapping up a stable release.
> 
>> I don't see the relationship between the two.
> 
> Which makes it a good thing that you are not pursuing a career as
> project manager.
> 
> At any rate, we are trying to stabilize our code base in a timely
> manner suitably for a stable release, and the established track record
> of ingenious solutions solving all problems in one fell swoop does not
> suggest that this is the way to go.
> 

The sarcasm of your e-mails has gotten to the point where I need to limit my 
work on the project as a developer.  When I work on a team project, I need to 
be part of a community with a different style of communication than this.  I 
will still use LilyPond as a tool and and continue to help fix any bugs that 
have resulted from my work.

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

Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)

[Mike Solomon]

On 30 août 2013, at 10:11, d...@gnu.org wrote:

> On 2013/08/30 07:41:49, mike7 wrote:
> 
>> I'd still argue that (2) is the best way to go as it is a
> one-stop-shopping way
>> to clear all these bugs (and perhaps more) as they arise.
> 
> Since we are currently in the process of recovering from the last
> one-stop-shopping way to clear bugs galore which is where all those
> regressions are actually from,

The skyline code was not written to address bugs.  LilyPond's previous spacing 
algorithms weren't buggy - they were just less snug than they are now.

> I suggest that we refrain from
> embracing your somewhat optimistic estimates until after wrapping up a
> stable release.

I don't see the relationship between the two.  The skyline code was a major, 
over-a-thousand line overhaul of spacing.  This is much smaller in scale and 
addresses one specific aspect of the code.

I'm not claiming that any solution - Keith or mine - is bug proof, but rather 
that we should adopt the one that will get the most mileage against eventual 
spacing bugs with stencils.  The general category of problem we are trying to 
solve is "a shape around stencil X is not being represented in the skylines."  
My solution fixes problems in that general category, whereas Keith's addresses 
the more specific problem "a box around stencil X is not being represented in 
the skylines."

> 
> And frankly, I completely fail to see how this advertisement as a
> magic bullet for all the regressions is even remotely rooted in fact.
> The regressions will not in any way be automagically addressed by such
> sweeping changes.  The changes will offer different ways to address
> them and you like those better.  But that's not the same as actually
> getting them addressed.

We agree here.  In my previous e-mail, I make the case that this is a "way to 
clear all these bugs" and above you correctly identify that it offers "ways to 
address them."  I don't think it's a magic bullet, but rather a general 
framework that allows us to address this category of bugs without coming up 
with specific solutions for each bug.

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

Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)

[Mike Solomon]

On 30 août 2013, at 07:49, "Keith OHara"  wrote:

> On Thu, 29 Aug 2013 21:24:25 -0700,  wrote:
> 
>> Conceptually, I prefer (1), but this is based on your descriptions and
>> the previous discussion, not on understanding the code...
>> 
> 
> Then look at (2) and see if you think that would be good enough to clear the 
> last bugs before 2.18.
> 
> The uses of \transparent, \pad-to-box, etc., are rare.
> It hurts very little to find ourselves stuck with a second-choice 
> implementation in this case.
> We won't know what our first-choice implementation is unless we see some 
> application examples in this area.
> 

I'd still argue that (2) is the best way to go as it is a one-stop-shopping way 
to clear all these bugs (and perhaps more) as they arise.

To me, the question is "Is the implementation of (2) inferior to (1) to the 
point where we'd like to allow certain bugs to persist?"  My answer is no - 
LilyPond has already a practice of creating placeholder stencils whose sole 
purpose is to reserve space and (2) is in this vein.  (2) does for skylines 
what the empty-stencil does for dimensions.  Additionally, (2) clears all the 
stencil-related skyline bugs on the tracker, whereas (1) does not.

So my vote is for (2).

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

Re: Allows inner-markup spacing using skylines. (issue 13341044)

[Mike Solomon]

On 29 août 2013, at 10:25, d...@gnu.org wrote:

> On 2013/08/29 06:57:53, MikeSol wrote:
>> The point is to allow users to achieve the same snug skyline spacing
> between
>> stencils that is achieved between grobs.
> 
>> I agree that it is inefficient as skylines are never cached, but as it
> is not
>> default beahvior anywhere in the code base, it allows people to decide
> on the
>> efficiency versus snugness-of-placement trade-off.  For people
> creating complex
>> markups, this is useful.
> 
> Mike, the question is not whether or not it is useful to work with the
> distance of skylines.  The problem is that you just pile on complex
> derived functionality nilly-willy without stopping to think what the
> actually sensible building blocks would be.

What would they be?

> 
> 
> The solution is to add _proper_ interfaces to skylines.  Functions
> that can figure out distances and so on.  Between skylines.
> 

Doesn't that exist already with Skyline::distance ?

> And a function to query the skyline(s) of a stencil, yes.
> 

Doesn't this already exist with Stencil::skyline_pair_from_stencil and 
Stencil::skyline_from_stencil (proposed in this patch) or the function in 
current master Stencil::skylines_from_stencil ?

> Now querying skylines is expensive, so the question is how to cache
> them.

Agreed.

> The important thing to note is that skylines are not actually a
> property of stencils but rather of stencil expressions (combined
> stencils don't actually contain the original stencils but only their
> respective stencil expressions, so caching in the stencils themselves
> does not actually help at all).

If skylines rode around with stencils (like dimensions do), we'd have to do 
operations on the skylines when we do operations on the expression and 
dimension.

> The current form of stencil
> expressions does not make it easy to tack a skyline cache on without
> changing object identity, so it might be worth considering a different
> representation.

This is certainly a possibility.

> 
> Once that's sorted out satisfactorily and supported by primitives, one
> can stack on uses of skylines.
> 
> But increasing the number of functions that magically and
> intransparently somehow work with skylines not otherwise accessible is
> just a bad idea, and hiding this kind of thing in existing functions
> is even worse.

It would be a good idea to have Scheme bindings for skylines and to make them 
accessible, similarly to how dimensions are extensible and changeable.

What is your proposal for a good interface with Skylines?  This patch allows 
one to ask LilyPond "find the distance between two stencils' shapes along the 
horizontal or vertical axis and move shift a stencil by that amount" and 
LilyPond does that.  Where is there transparency needed?  In 
side-position-interface.cc and axis-group-interface.cc, the skyline operations 
are not transparent (meaning not visible to the user) but the end result (move 
object X above or below Y based on the shapes of the objects) is achieved.  It 
is also not transparent, but I wouldn't have thought it needed to be - I think 
people just want it to work and we should do a good job implementing it 
cleanly.  I'm of course open to proposals on how to implement it cleanl.y

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 28 août 2013, at 09:47, "Keith OHara"  wrote:

> On Tue, 27 Aug 2013 23:30:32 -0700, Mike Solomon  wrote:
> 
>> On 28 août 2013, at 05:28, "Keith OHara"  wrote:
>> 
>>> Of course I think it would be better to allow box dimensions in the stencil 
>>> expression.  Boxes are simple enough to enter as coordinates in markup 
>>> expressions like \pad-to-box, they are a useful building block for 
>>> arbitrary skylines, and the current code builds skylines from the stencil 
>>> expression.
>>> 
>> 
>> If we are willing to say that boxes should be an exception because of how 
>> primitive they are, then it makes more sense to make an exception for them, 
>> as they can be used in concord to create more complex structures.  In that 
>> case, we may want to accept a list of boxes (or a list of quadrilaterals) 
>> instead of just a box, as at that point we can approximate any shape.
>> 
> 
> Another reason for making an exception for boxes is the preexistence of  
> \pad-to-box  as a markup command, while we now base our padding on skylines 
> derived from the stencil expressions.
> 
> If we still think this way in a day, I'll repost the patch that adds the 
> stencil-primitive 'with-dimensions,  supports {cresc. \pad-around 0.5 "- - 
> -"}, and removes the faint box around harp-pedals.
> 
> A stencil-primitive 'with-dimension could be extended in a natural way to a 
> list of boxes, if we want that in the future.
> 

Just for kicks, I've proposed a new patch along with a new issue 3255.  It's 
worth mulling over - whatever solution we implement should fix this issue as 
well.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 28 août 2013, at 05:28, "Keith OHara"  wrote:

> On Mon, 26 Aug 2013 23:57:58 -0700, Mike Solomon  wrote:
> 
>> On 27 août 2013, at 09:01, "Keith OHara"  wrote:
>> 
>>> On Mon, 26 Aug 2013 22:37:17 -0700, Mike Solomon  
>>> wrote:
>>> 
>>>> I'd argue that (2) is better.
>>> 
>>> What, then, is your argument ?
>> 
>> What I put below - namely, that it is consistent with the previous practice 
>> of stencils separating layout information from graphical content.
>> 
> 
> That kind of separation is not always good.
> 
> We like having the 'staff-padding' between the staff and tempo mark separate 
> from the text "Adagio", because we usually want to control the padding 
> globally for all tempo marks.
> 
> We would like to keep the space request closely associated with the graphic in
> { d'2-\markup {\italic { c r e s c. } \pad-around #0.5 {- - -} } d' b b }
> so that as the font and inter-word space change, the space request follows.
> 
> 
>> It's true that a new primitive works.  But, it seems that, on a more 
>> systemic level, this is not a tenable solution as it would lead to the 
>> creation of many different stencil primitives for different types of padding.
>> 
> 
> The new stencil primitive in the patch set I have posted now does not assume 
> any kind of padding.  You said the stencil expression should not contain data 
> influencing layout, so I went back to the patch set that simply turns off 
> skylines for markup using \with-dimensions and similar.
> 
> I withdrew the patches that preserve the space around the "- - -" leader, 
> because they put data based on the #0.5 into the stencil expression.
> 
> Of course I think it would be better to allow box dimensions in the stencil 
> expression.  Boxes are simple enough to enter as coordinates in markup 
> expressions like \pad-to-box, they are a useful building block for arbitrary 
> skylines, and the current code builds skylines from the stencil expression.
> 

If we are willing to say that boxes should be an exception because of how 
primitive they are, then it makes more sense to make an exception for them, as 
they can be used in concord to create more complex structures.  In that case, 
we may want to accept a list of boxes (or a list of quadrilaterals) instead of 
just a box, as at that point we can approximate any shape.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 27 août 2013, at 11:09, d...@gnu.org wrote:

> On 2013/08/27 06:58:05, mike7 wrote:
>> On 27 août 2013, at 09:01, "Keith OHara" 
> wrote:
> 
>> > How are skylines asked-for, and is it possible to know if they were
> asked for
>> while interpreting the markup ?
>> > {c4-\markup \whiteout \pad-to-box #(-0.5 . 9) #(-0.5 . 1.5) \concat
> {"Clarinet
>> in B" \flat}}
>> >
> 
>> class Stencil {
>>   private :
>> Scheme expr_;
>> Box dim_;
>> Skyline_pair *vskys_; // set to 0 in the constructor
>> Skyline_pair *hskys_; // set to 0 in the constructor
> 
>>   public :
>> Skyline_pair* get_vskys () { if (!vskys_) create_vskys (); return
> vskys_; }
>> }
> 
>> So, the idea is that we only ever create the skylines if they are
> asked for or
>> if we use something like pad-to-box.  Then, if we are going to combine
> two
>> stencils and neither of them have skylines set already, we do not
> calculate
>> their skylines yet.
> 
> Either you don't listen or you don't think about your code.  Delaying
> skyline calculation until it is needed does _nothing_ whatsoever with
> regard to computational complexity if the skyline is needed eventually,
> which it will almost always be.

I don't see how this system precludes O(n log n) in the majority of cases.  
Take :

\header {
  title = "foo"
  composer "bar"
}

\markup { mit herzlichen foo }

\new Staff \relative c'' { a1^"und bar" }

The skylines for the title, composer, and top-level markup will never be 
calculated.  For everything in the staff, there are no stencil skyline 
overrides, which means a stencil's get_skyline method will not be called before 
it is fully formed, which means that the existing divide-and-conquer method 
will be used to traverse the stencils' expressions and create the skyline.  
This keeps the complexity at O(n log n) instead of O(n^2).

The only cases where O(n^2) behavior would be exhibited is if the stencil's 
skyline creation is triggered before a call to translate_axis, translate, 
rotate, rotate_degrees_absolute, rotate, scale, add_at_edge, etc. in which case 
we'd need to perform these operations on the skylines as well.  But the only 
time that we would trigger skyline creation is when we want the skyline to 
differ from the natural one of the stencil.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 27 août 2013, at 09:01, "Keith OHara"  wrote:

> On Mon, 26 Aug 2013 22:37:17 -0700, Mike Solomon  wrote:
> 
>> On 27 août 2013, at 07:18, "Keith OHara"  wrote:
>> 
>>> (1) At the moment, the stencil expressions are assembled first, when markup 
>>> is interpreted, and then stencil_traverser() reads the stencil expression 
>>> to figure the skylines.  So long as that approach remains in place we need 
>>> some sign in the stencil expression to be read by stencil_traverser() 
>>> telling it to omit the usual skyline around part of the stencil.  (I could 
>>> re-use 'delay-stencil-evaluation, but think a new primitive is wiser.)
>>> 
>>> 
>>> (2) If someday the skylines are assembled in parallel with 
>>> stencil-expressions when the markup is interpreted, then \with-dimensions 
>>> or \no-skyline could simply throw away the skyline it built for "text" (in 
>>> the examples above) and there is no need for a 'with-dimensions' primitive. 
>>>  (There would still be primitives that move markup like 'translate-stencil' 
>>> for things like \concat {B\flat}.)
>>> 
>>> Are systems organized as in (2) better systems than the one we have 
>>> organized as in (1) ?
>> 
>> Good summary of the current state of things.  I'd argue that (2) is better.
> 
> What, then, is your argument ?

What I put below - namely, that it is consistent with the previous practice of 
stencils separating layout information from graphical content.

> 
>> The original function definition for \with-dimension does not need a special 
>> primitive because dimension information is encoded in the stencil in 
>> parallel with stencil-expressions when the markup is interpreted.
> 
> The only problem that I have heard of a special primitive is that it would be 
> redundant, *if* we change a system of type (2) for building skylines.  In the 
> current system, the primitive seems fine.

It's true that a new primitive works.  But, it seems that, on a more systemic 
level, this is not a tenable solution as it would lead to the creation of many 
different stencil primitives for different types of padding.

> 
>> The same could be true of skylines, with the caveat that skylines should 
>> only be generated and used when asked for to save computation time, and 
>> otherwise dimensions should be used.
> 
> How are skylines asked-for, and is it possible to know if they were asked for 
> while interpreting the markup ?
> {c4-\markup \whiteout \pad-to-box #(-0.5 . 9) #(-0.5 . 1.5) \concat 
> {"Clarinet in B" \flat}}
> 

class Stencil {
  private :
Scheme expr_;
Box dim_;
Skyline_pair *vskys_; // set to 0 in the constructor
Skyline_pair *hskys_; // set to 0 in the constructor

  public :
Skyline_pair* get_vskys () { if (!vskys_) create_vskys (); return vskys_; }
}

So, the idea is that we only ever create the skylines if they are asked for or 
if we use something like pad-to-box.  Then, if we are going to combine two 
stencils and neither of them have skylines set already, we do not calculate 
their skylines yet.  If one of them has skylines set, then somebody must have 
set it with something like with-dimension and we calculate the skyline of the 
other to create a composite skyline.

pad-to-box would not require the finding of the skyline of Clarinet in Bb, 
since we already have its X and Y dimensions.  The skyline resulting from the 
pad-to-box call would be calculated off of that.

> The current system (1) seems more efficient at generating only the needed 
> skylines.  We only need the skyline if the markup ends up in a TextScript 
> with 'vertical-skylines set, as opposed to titling markup, and then 
> stencil_traverser() works through the stencil expression and sees that it 
> need not traverse through argument of \pad-to-box and need not trace the 
> letters in "Clarinet in B"
> 

In the pseudocode above, imagine that a call to create_vskys () would only 
happen in the stencil traverser and in certain padding or concatenating 
scenarios.  This would be less efficient than (1) but not by much.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 27 août 2013, at 07:18, "Keith OHara"  wrote:

> On Mon, 26 Aug 2013 02:11:28 -0700, Mike Solomon  wrote:
> 
>> 
>> I think that if we can devise a better system, the creation of a new stencil 
>> primitive is unnecessary.  If we agree that we should implement a system 
>> where stencils are carriers of their own skylines, then we should fix this 
>> bug using that system.
>> 
> 
> In any system of building skylines from markup, we want to regain the 
> spacing-control that we had with
>  \with-dimensions #(0 . 1) #(0 . 1) "text"
> and maybe we might have in the future
>  \with-shape {/* shape for purposes of spacing around music */} "text"
> 
> Maybe someday both of these will be implemented using a skyline-generator and 
> skyline-remover
>  \combine
>\transparent \make-shape {/* shape for spacing */}
>\no-skyline "text"
> 
> In any case we need a way to omit or ignore the usual skyline from some 
> markup.
> 
> 
> (1) At the moment, the stencil expressions are assembled first, when markup 
> is interpreted, and then stencil_traverser() reads the stencil expression to 
> figure the skylines.  So long as that approach remains in place we need some 
> sign in the stencil expression to be read by stencil_traverser() telling it 
> to omit the usual skyline around part of the stencil.  (I could re-use 
> 'delay-stencil-evaluation, but think a new primitive is wiser.)
> 
> 
> (2) If someday the skylines are assembled in parallel with 
> stencil-expressions when the markup is interpreted, then \with-dimensions or 
> \no-skyline could simply throw away the skyline it built for "text" (in the 
> examples above) and there is no need for a 'with-dimensions' primitive.  
> (There would still be primitives that move markup like 'translate-stencil' 
> for things like \concat {B\flat}.)
> 
> 
> Are systems organized as in (2) better systems than the one we have organized 
> as in (1) ?
> 

Good summary of the current state of things.  I'd argue that (2) is better.  
The original function definition for \with-dimension does not need a special 
primitive because dimension information is encoded in the stencil in parallel 
with stencil-expressions when the markup is interpreted.  The same could be 
true of skylines, with the caveat that skylines should only be generated and 
used when asked for to save computation time, and otherwise dimensions should 
be used.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 26 août 2013, at 13:31, d...@gnu.org wrote:

> On 2013/08/26 10:18:04, mike7 wrote:
> 
>> I think Harm is right that, irrespective of documentation, users use
> what's
>> available.
> 
> If people meddle with internals instead of using provided API functions,
> they deserve whatever they get.
> 
>> If we're going to add something, we want to be sure that it has a
>> certain degree of permanency.  I don't think we can treat it as an
>> implementation detail if it is publicly useable.
> 
> _Anything_ is "publicly useable".  If that's supposed to be a criterion,
> we may not change LilyPond ever again.  We try to support programming
> interfaces as long as it is feasible.  But the way those are internally
> implemented is _not_ _ever_ guaranteed to remain the same.  If you mess
> with internals, all bets are _off_.
> 

For me, the criterion is the use of "define-public" versus "define".  If a 
function is "define-public" (like the ones in lily-library.scm), then we are 
telling the user that it is useable.  Otherwise, it should not be public.

The same should be true of Scheme functions written in C++ - there should be a 
way to make them publicly not-useable but available from .scm files.

Then, we could make ly:make-stencil private so that users could never use it.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 26 août 2013, at 13:13, d...@gnu.org wrote:

> On 2013/08/26 10:05:25, mike7 wrote:
>> On 26 août 2013, at 13:00, mailto:d...@gnu.org wrote:
> 
>> > That's bullshit since nobody assembles stencil expressions manually.
> 
>> I assemble stencil expressions manually.
> 
> If you meddle with internals, that's your own business.
> 
>> > This is done using opaque functions like ly:stencil-translate.
> 
>> ly:make-stencil is all over the place in the code and is a public
> function which
>> accepts a user-made expression.
> 
> The only documented way to generate "user-made" expressions is to create
> a stencil with the normal ly:stencil-... or stencil-... API functions
> and extract its expression with ly:stencil-expr.  There is _no_
> guarantee that anything else will work, and there is no guarantee that
> the format of stencil expressions will be what it is now.
> 
> You of all people should know that since you juggled around quite a bit
> reorganizing stencil primitives used in the backend.

I was aware that the juggling would potential screw up scores (including my 
own) but proposed it because it was a move in the right direction, meaning that 
I knew we would never be adding these stencils back in again.

I think Harm is right that, irrespective of documentation, users use what's 
available.  If we're going to add something, we want to be sure that it has a 
certain degree of permanency.  I don't think we can treat it as an 
implementation detail if it is publicly useable.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 26 août 2013, at 13:00, d...@gnu.org wrote:

> That's bullshit since nobody assembles stencil expressions manually.

I assemble stencil expressions manually.

> This is done using opaque functions like ly:stencil-translate.

ly:make-stencil is all over the place in the code and is a public function 
which accepts a user-made expression. Are you saying this should not be a 
public function? If it is the case that users cannot access stencil primitives, 
then it is easier to swap things out.

Cheers,
MS


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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 26 août 2013, at 12:39, Werner LEMBERG  wrote:

> 
>> To summarize: stencil expressions (expr_) currently do not contain
>> information for how to place stencils with respect to others.  They
>> contain information passed to the backends on how to lay out
>> stencils.  If we adopt either Keith's patch or my first one (which I
>> created before I thought this fully over), we will create one
>> stencil primitive that uses the stencil's expression to influence
>> layout decisions.  This does not seem consistent with current
>> practice and I believe we should find a solution that avoids it.
> 
> I think that Keith's (or your) patch is small enough to allow an
> deviation from the `ideal' to fix a real bug.  Maybe it helps to add a
> remark to the source code that this stencil primitive is a temporary
> hack until a better, more generic solution gets implemented.
> 

In French there's a saying "Temporary solutions have a way of becoming 
permanent", which is why I'd like to avoid it if possible.  What we don't want 
is for people to start using the stencil primitive if we know it's temporary.  
But if we can somehow prevent that (a sort of internal-only primitive) plus add 
a big TODO somewhere, that'd be OK and would save time.

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

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 26 août 2013, at 11:41, d...@gnu.org wrote:

> On 2013/08/26 06:42:38, mike7 wrote:
>> On 26 août 2013, at 08:35, mailto:d...@gnu.org wrote:
> 
>> > So why do you talk about that in the first place?
> 
>> Because I'd rather spend more time implementing a solid system than
> less time
>> implementing a kludge.
> 
> In the context of this issue, we are currently talking about not doing
> anything at all.  It seems like the best course forward with regard to
> resolving the reported regression would be to just adapt Keith's
> patch.

I think that if we can devise a better system, the creation of a new stencil 
primitive is unnecessary.  If we agree that we should implement a system where 
stencils are carriers of their own skylines, then we should fix this bug using 
that system.

But if there is no better system, then we should go with Keith's patch.

> 
>> What I'm proposing (making skylines a stencil data
>> member) is more work but seems less kludgy than creating a stencil
> primitive
>> containing skylines.
> 
> Again: this is _totally_ orthogonal to the issue at hand.  If you want
> to talk about that, create a new issue rather than drive an existing
> issue into the ground.

You're right that this discussion would be better on the issue tracker than on 
a review of a patch - we can move it over there.

> 
>> >> It would be better and more consistent with currently practices in
>> >> the code base if stencils carried their own skyline information (as
>> >> they do their own dimensions), which would require a lot of
> juggling
>> >> code around.
>> >
>> > In the context of reviewing this patch, this is a straw man
> argument.
> 
>> In the context of figuring out the best way to do things, this is
> important.  It
>> would be better to decide what problem we're trying to solve and
> implement it
>> correctly now rather than creating a temporary solution that we do
> away with
>> later.
> 
> Ok, let's get to the gist of it: for arranging items inside of a
> markup, there are several concepts: stencil geometry, reference
> points, escapement values (after placing a glyph at the current
> reference point, move by the respective escapement for the current
> direction of alignmen).  For lining up stencils, _only_ escapement
> values and reference points are of interest.  The outlines come into
> play _between_ independent markups, when we create a graphical
> arrangement on the page.
> 
> So in general, we don't need outlines until the finished markup.
> \with-dimensions operates on the dimensions interesting for working
> within markups.  Unfortunately, we raised the expectation that those
> are the same that are valid outside and advertised \with-dimensions
> accordingly.  This is what this issue is about.
> 
> Generating a skyline from individual elements is a complex operation.
> When done all at once, we have a complexity of O(n lg n) for n
> elements.  When integrating a single element at a time, the complexity
> rises to O(n^2).  So we don't want to assemble skylines one by one if
> we can avoid it.  Markup functions assemble stencils to stencils.  If
> we can calculate the skyline (when needed) in one go from the complete
> stencil arrangement, we save a lot of effort, and that's the rule
> rather than the exception.
> 
> So we don't want to carry skylines along with stencils that will not
> be used individually on the page but will rather be integrated into a
> markup.
> 

I agree.  If stencils have both dimensions and skylines, we can use merging 
based on dimensions as the default and skylines only when asked.  This would 
avoid the time cost you talk about above while at the same time allowing one to 
use skyline placement in the interior of a stencil when needed, as currently 
skylines are only available for use between grobs.

>> It seems like stencil expressions should not contain dimensional
>> information.  Where it does (like, for example, the stencil command
>> 'translate-stencil defined in define-stencil-commands.scm), this
>> seems like legacy code that has not evolved with LilyPond and is
>> barely used.
> 
> The dimensional information is used for stencil-add-at-edge, and most
> certainly for all the various stencil stacking operations, forming
> lines and columns.  "barely used" is a mischaracterization if I ever
> saw one.

I believe you are talking about dimensional information in the stencil 
dimension cache (dim_ in C++).  Above, I'm talking about the "stencil 
expression" (expr_ in C++).  Currently, stencil dimension information contained 
in the expression is _only_ used to tell the backends where to place a stencil 
or how to make the stencil skyline.  It is not used to line things up: the dim_ 
cache is used for this.

> 
>> So, as long as we're going to solve this problem, we should have a
>> broader discussion about how stencils are put together.
> 
> In the course of this issue, we should fix the perceived regression.
> It seems like Keith's code does that just fine.

It 

Re: Adds dimension stencil command to correct with-dimension (issue 12957047)

[Mike Solomon]

On 26 août 2013, at 08:35, d...@gnu.org wrote:

> On 2013/08/26 05:25:42, mike7 wrote:
>> On 26 août 2013, at 08:20, mailto:d...@gnu.org wrote:
> 
>> > Indeed.  Instead of calling stencil-integrate on a "surrogate
> stencil"
>> > or whatever for deriving a skyline, the respective stencil operation
> in
>> > stencil-integrate will just plug in a a "surrogate skyline" directly
>> > specified in the stencil operation and be done.
>> >
>> > Which is less work.
> 
>> What is more work is what I talk about farther down in my previous
>> e-mail.
> 
> So why do you talk about that in the first place?

Because I'd rather spend more time implementing a solid system than less time 
implementing a kludge.  What I'm proposing (making skylines a stencil data 
member) is more work but seems less kludgy than creating a stencil primitive 
containing skylines.

> 
>> It is possible to create a stencil primitive that works something
> like:
> 
>> `(replacement-skylines ,left ,right, ,up ,down original-stencil)
> 
>> but that seems kludgy.
> 
> Less kludgy than the code we are currently reviewing, and that's what
> the current issue is.

Agreed.

> 
>> It would be better and more consistent with currently practices in
>> the code base if stencils carried their own skyline information (as
>> they do their own dimensions), which would require a lot of juggling
>> code around.
> 
> In the context of reviewing this patch, this is a straw man argument.

In the context of figuring out the best way to do things, this is important.  
It would be better to decide what problem we're trying to solve and implement 
it correctly now rather than creating a temporary solution that we do away with 
later.

It seems like stencil expressions should not contain dimensional information.  
Where it does (like, for example, the stencil command 'translate-stencil 
defined in define-stencil-commands.scm), this seems like legacy code that has 
not evolved with LilyPond and is barely used.

So, as long as we're going to solve this problem, we should have a broader 
discussion about how stencils are put together.  I argue that we should not be 
putting dimension information in the stencil expression itself.  If this is the 
case, then a replacement-skyline stencil primitive is not a good idea.  I am 
definitely not going to work on a patch implementing skylines as a stencil data 
member if people don't think it's a good idea, though, as it would take tons of 
time and would represent a major reorganization of things.  However, if this is 
the right way to go about solving the problem, it is better to spend the time 
than create a stencil primitive (replace-skylines) that we are not happy with.

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