Re: [RFC] switch to GitLab / gitlab.com

[Urs Liska]

Am 7. Februar 2020 09:48:30 MEZ schrieb Kevin Barry :
>> (CC to Kevin Barry, who mentioned GitLab experience in a separate
>> thread. My info here is more based on research than experience, so
>> please call out any misunderstandings I have.)
>
>Thank you for the CC. I have read through the messages, and the
>previous
>discussion from 2018.
>
>My two cents are:
>- I think if we want to integrate issue tracking, code review, and
>source code
>  hosting in one place, then Gitlab is the best option
>- I do not have the experience of working with SF/Allura, Rietveld, and
> Savannah to get code into LilyPond, but, judging from appearances, the
>flow for contributions will be smoother for existing developers and
>less
>off-putting for new or occasional developers (I think, outside projects
>like
>the Linux kernel, drive-by pull/merge requests are more common than
>drive-
>  by patches)
>- I agree that using gitlab.com is better than self-hosting, but
>depending on the
>technical challenges involved it may be necessary to host a dedicated
>Gitlab
>  runner (i.e. a server for doing CI/CD builds/tests).
>- I think it's possible James Lowe's workflow might be be different
>under Gitlab.
>Re the concerns he raised in the old thread, I believe he would be able
>to
>mostly replicate what he does now with labels (and sorting by priority
>label).
>(I can see that this flow, including the "countdown" is under
>discussion
>  elsewhere.)
>- I don't know who tests that every patch successfully builds and
>passes basic
>tests, but in my experience, having Gitlab do that for me every time
>someone
>  opens a merge request (on one of my own projects at work) has been a
>  godsend (before that, I had to do it myself every time).

To add: tests are also triggered when additional commits are pushed to an open 
MT.


>
>> Additionally I'm not (yet) proposing to use MRs to actually
>> merge the change, that still happens via staging -> master. I only
>> propose that we use the UI to review the patches, instead of
>Rietveld.
>I think this is a good approach. Gitlab allows, for example, to have a
>number of
>protected branches (master + staging), and to default merge requests to
>any one.
>You can also set it to do different CI/CD on a branch by branch basis
>(for example
>you may want to run more stringent or longer tests on the staging
>branch than on
>others).

I think this is an extremely good point. Being able to squash upon merge, with 
or without merge commit, in combination with being able to automate that as a 
staging branch with final test, seems a very good idea to me.

This integration of tools can be handled completely independently from any 
policies about the review process or countdown etc.

To recap at this point: the worry about gitlab.com is similar to that wrt 
guthub: their TOS won't give us a substantial amount of trust in continuity of 
service.

Urs
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Add Code of Conduct

[Urs Liska]

Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
> Thomas Morley  writes:
> 
> > P.S. that 'make test-baseline' failed, I'll need to investigate
> > after
> > sending this.
> > 
> > 
> 
> input/regression/display-lily-tests.ly:230:1: fatal error: Test
> unequal: BUG.
> in  = \applyOutput Foo #(lambda (arg) (list))
> out = \applyOutput Foo ##f
> 
> 
> \test ##[ \applyOutput Foo #(lambda (arg) (list)) #]
> 
> 
> Not much of a surprise here: Guile-2 does not keep the source of
> functions around in general.  And Urs 

? (is there another one around here?)

> turned warnings in that file into
> errors so that they would not get overlooked.  Which certainly is
> sensible, but it means we need to think about what to do here.
> 

Re: Add Code of Conduct

[Urs Liska]

Am Samstag, den 08.02.2020, 17:52 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
> > > Thomas Morley  writes:
> > > 
> > > > P.S. that 'make test-baseline' failed, I'll need to investigate
> > > > after
> > > > sending this.
> > > > 
> > > > 
> > > 
> > > input/regression/display-lily-tests.ly:230:1: fatal error: Test
> > > unequal: BUG.
> > > in  = \applyOutput Foo #(lambda (arg) (list))
> > > out = \applyOutput Foo ##f
> > > 
> > > 
> > > \test ##[ \applyOutput Foo #(lambda (arg) (list)) #]
> > > 
> > > 
> > > Not much of a surprise here: Guile-2 does not keep the source of
> > > functions around in general.  And Urs 
> > 
> > ? (is there another one around here?)
> 
> Dan.  Knowing my luck, now both will be offended.  Sorry.

No, I'm not offended ;-)

Urs
> 
> > > turned warnings in that file into
> > > errors so that they would not get overlooked.  Which certainly is
> > > sensible, but it means we need to think about what to do here.

Re: Add Code of Conduct [Another RFC or not now?]

[Urs Liska]

Am 8. Februar 2020 19:23:34 MEZ schrieb Karlin High :
>On 2/8/2020 11:24 AM, Phil Holmes wrote:
>> I remain strongly opposed to a CoC.
>
>Clearly noted; thanks for responding. I have nothing further to say on 
>this topic just now; it's pretty much all been covered in prior
>messages.
>
>I'm sorry if I got your name wrong. I know "Phil Holmes" and "James 
>Lowe" are names associated with great service to the project in
>managing 
>patches and builds, but I have trouble remembering who's who for them.

No, you remembered right, James voiced his opposition in even stronger, 
borderline inappropriate ä, words.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [Jose E. Marchesi] [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020

[Urs Liska]

I just told them to copy last year's proposal, which basically links to *our* 
GSoC page.

Urs

Am 12. Februar 2020 20:03:49 MEZ schrieb David Kastrup :
>
>Someone with a good idea?
>
> Start of forwarded message 
>From: jema...@gnu.org (Jose E. Marchesi)
>To: gnu-prog-disc...@gnu.org
>Date: Wed, 12 Feb 2020 19:50:06 +0100
>Subject: [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020
>
>
>Hi people!
>
>Once again, we are applying as a mentoring organization for GSOC 2020.
>At this point, we need to populate our ideas page with projects [1].
>
>This should be done before this Thursday (yes tomorrow).  So, if you
>want your GNU package to participate in GSOC, please send us your ideas
>to summer-of-c...@gnu.org ASAP!
>
>For each project idea, we need:
>
>- Name of the GNU program.
>  Example: GNU poke.
>
>- Summary of the project/idea.
>  Example: DWARF to Poke translator
>
>- Little paragraph explaining the project/idea.
>
>- Skills required.
>  Example: Good knowledge of DWARF, C programming.
>
>- Contact address for interested students.
>  Example: poke-de...@gnu.org
>
>If you have an external page where you are documenting your ideas, then
>please send us the URL so we can list it in the main page.
>
>Sorry for the late notice!
>And thanks! :)
>
>[1] https://www.gnu.org/software/soc-projects/ideas.html
>
>
>
> End of forwarded message 
>
>-- 
>David Kastrup

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: 2.20 and 2.21 release plans

[Urs Liska]

Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> Ok, I think 2.20 is basically done and we should push it out by the
> end
> of this week.  

This is really great news!
I'm somewhat undecided whether it is a cause for celebration or not to
finally release a "stable" version after six years. But at the end of
the day I think we should praise those who have actually worked so hard
to make it happen. And all of us who benefit from that work might think
about what we can do to help bringing the *next* stable release over
the goal line in less than six years.

I have one side remark to that, although I'm not sure if it's
appropriate to inject it into this thread.

I haven't commented on the issue of a package loading mechanism
recently, for two reasons: I don't have any time right now, and I
thought it would be a distraction from the more pressing issues around
the build system, contribution workflow/tooling and finalizing a
release.
While it has been clear from the start that integrating a package
loading mechanism was not in question for 2.20.0, I would like to ask
if it can be considered making this go into a 2.20.x release and not
keep it on the 2.21 track as would be the natural itinerary. Doing so
(the latter) would force openLilyLib and - more importantly -
interfaces like Frescobaldi to support two alternative syntaxes of
loading packages until a 2.22 release.
So I would be glad if we could spend sufficient effort after 2.20.0 and
2.21.0 releases to discussing, implementing, and testing a package
loading mechansim sufficiently that we can integrate it not only in the
2.21.x but also a 2.20.x release.

Urs

> This leaves a few days for the translation team to catch
> up with the current state.
> 
> In particular HINT HINT HINT it gives the opportunity to native
> speakers
> of languages not as meticulously maintained as the currently most
> active
> translations to at least tackle the Changes document and maybe check
> a
> few other points of the web presence.  This is more addressed to
> people
> reading this announcement on the lilypond-devel list than to lurkers
> on
> the translations list, though of course the latter would be equally
> welcome.
> 
> What does this mean for 2.21.0?  I think we should aim to push it out
> fast afterwards, basically a few days later at most, just to get
> kinks
> with webpage/versioning from 2.20 ironed out.
> 
> I am not sure it is realistic to expect to get the translations
> merged
> into 2.21.0 already: because of the significant divergence
> experienced
> so far, I expect this to be a significant merging headache.  It would
> be
> nice to have, but not essential: this is the unstable branch after
> all.
> 
> For more extensive changes of internals and/or syntax, I would
> recommend
> to let them sit till 2.21.1 before committing, assuming that we _do_
> manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
> significantly diverged from 2.20.0.  If something does not quite
> work,
> it would be nice to have a _released_ version to compare to, and
> nothing
> but 2.21.0 would really serve that role satisfactorily.  Particularly
> where problems are detected a long time after getting introduced,
> having
> an installable version as a reference is nice, and "it stopped
> working
> in 2.21.0" is enough of a quagmire already that we do not really want
> to
> add a lot more here.
> 
> The size of the headache basically is commensurate with how long the
> stable branch has diverged.  Hopefully we manage to find some
> combination of process and responsible persons next time around that
> delivers faster.
> 
> Nevertheless, I am glad we are getting there.
> 

Re: music-cause

[Urs Liska]

Am Donnerstag, den 20.02.2020, 17:12 +0100 schrieb David Kastrup:
> David Kastrup  writes:
> 
> > Graham Percival  writes:
> > 
> > > On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
> > > > Anybody actually using the "music-cause"?  Inside of LilyPond,
> > > > the only
> > > > appearance (apart from its declaration) would be
> > > > 
> > > >   /*
> > > > ES TODO: This is a temporary fix. Stream_events should not
> > > > be
> > > > aware of music.
> > > >   */
> > > >   e->set_property ("music-cause", self_scm ());
> > > 
> > > If it's used anywhere, it would be here:
> > > http://lilypond.org/website/pdf/thesis-erik-sandberg
> > > 
> > > It may have been added just so he could produce some graphs or
> > > tables or something?  I know that I have a ton of "graph-
> > > producing
> > > code" in Artifastring and Vivi like that.
> > 
> > Seems somewhat pointless since events take the whole mutable
> > property
> > list of their originating music event anyway.  If you need more for
> > tracking, you could just do
> > 
> > maketrackable =
> > #(define-music-function (parser location m)
> >   (music-map
> > (lambda (m)
> >(set! ly:music-property 'music-cause m)
> >m)
> > m))
> > 
> > and call that on your music before processing.
> 
> I lean towards going through with my threat here and removing
> music-cause which seems like a weird punch-through kind of property.
> Any objections here?  Anybody actually using it anywhere?
> 

It is used in openLilyLib a few times, I assume by Jan-Peter:

$ grep -rnw . -e 'music-cause'
./snippets/editorial-tools/auto-
transpose/module.ily:79:   ;  (ly:make-stream-event 'key-
change-event `((music-cause . ,key-sig)) ))
./snippets/editorial-tools/auto-transpose/module.ily:92:(cond-
transp engraver (ly:event-property event 'music-cause)))
./snippets/editorial-tools/auto-transpose/module.ily:95:(cond-
transp engraver (ly:event-property event 'music-cause)))
./edition-
engraver/engine.scm:944:  (music-
cause . mod)
./lilypond-export/api.scm:147:  ; search for music-cause of grob
./lilypond-export/api.scm:152: ((ly:stream-event? grob) (grob-
cause (ly:event-property grob 'music-cause)))
./lilypond-export/api.scm:205:(music (ly:event-property 
event 'music-cause))
./lilypond-export/api.scm:468:   (music (ly:event-property
event 'music-cause))
./oll-misc/pitch/auto-
transpose/module.ily:79:   ;  (ly:make-stream-event 'key-
change-event `((music-cause . ,key-sig)) ))
./oll-misc/pitch/auto-transpose/module.ily:92:(cond-transp
engraver (ly:event-property event 'music-cause)))
./oll-misc/pitch/auto-transpose/module.ily:95:(cond-transp
engraver (ly:event-property event 'music-cause)))

GSoC

[Urs Liska]

Just to let you know: GNU has been accepted as a GSoC mentoring
organization.

a)
This means that now people may visit 
https://lilypond.org/google-summer-of-code.html and look at our GSoC
project ideas. So if anythingg could be added (or fixed or removed)
there now would be the (latest) time to do so.

b)
If you know of any distribution channels for this information please
share https://summerofcode.withgoogle.com/ 
https://www.gnu.org/software/soc-projects/ideas-2020.html and the link
from a)

Urs

Re: lilypond.org now serving HTTPS

[Urs Liska]

Am Donnerstag, den 13.02.2020, 18:48 +0100 schrieb Jean-Charles
Malahieude:
> Le 13/02/2020 à 15:10, Han-Wen Nienhuys a écrit :
> > FYI, lilypond.org is now serving on HTTPS
> > 
> > See here https://codereview.appspot.com/559470043/ for background.
> > 
> 
> This should be applied on stable/2.20 as well.
> 
> Cheers,
> --
> Jean-Charles
> 

My browser complains about mixed content, i.e. http-linked media on the
page.

Urs

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

[Urs Liska]

Am Mittwoch, den 26.02.2020, 15:46 -0600 schrieb Karlin High:
> On 2/26/2020 3:28 PM, Leandro Doctors wrote:
> > Could you please point me in the right direction?
> 
> Thanks for your interest! In the past, Urs Liska has been leading
> GSOC 
> efforts. He's indicated that this list is his preferred way to begin 
> GSOC discussions, so I think you're at the right place.

That's correct, although I'd claim that this is a "natural" solution
and not my preference ;-)

But more importantly I'd like to stress that the GSoC page lists
project *ideas*, and if you're specifically interested in Scheme stuff
you may as well suggest other topics than listed there.

Urs

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

[Urs Liska]

Am Donnerstag, den 27.02.2020, 08:57 -0300 schrieb Leandro Doctors:
> On Wed, 26 Feb 2020 at 18:56, Urs Liska 
> wrote:
> > I'd like to stress that the GSoC page lists
> > project *ideas*, and if you're specifically interested in Scheme
> > stuff
> > you may as well suggest other topics than listed there.
> 
> Sure, Urs :-)
> 
> As I said before, I have only started reading the Ideas page.
> All I know right now is that I would like to work on a Scheme-related
> project :-)
> 
> I will clone Lilypond's repo, read the code and try building it, and
> get
> back with more specific details, if that's OK with you.

Of course.

You may also be interested in openLilyLib (https://openlilylib.org for
a very-WIP introdcution and https://github.com/openlilylib for the
development space. There is much room for Scheme work in there, if it
looks interesting to start with I suggest you clone and look into the
oll-core repository (first) edition-engraver  and/or scholarly (order
irrelevant).

Urs

> 
> Best,
> Leandro
> 

Re: Lilypond API

[Urs Liska]

Hello Brahim,

Am Montag, den 16.03.2020, 10:31 + schrieb brahim.pro via
Discussions on LilyPond development:
> Hello,
> 
> I would like to use lilypond parser in my own application.
> I can't find any API or external library to do that.

There is no such thing.

> What is the correct approach you would advice me to follow?

That very much depends on what you are actually trying to achieve. The
typical way to use LilyPond from the outside is generate some input for
it (or have users write that) and than pass it to LilyPond for
compilation. This can be either by writing a file and give that to
LilyPond or by directly passing it the content in a string through the
shell.

For some applications it may also be a way to use the python-ly library
that powers the Frescobaldi (text) editor (
https://python-ly.readthedocs.io/en/latest/).

But you should really clarify what you're after.

Urs

> 
> Thanks
> Brahim
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: 2.21.0 and announcements

[Urs Liska]

Am 26. März 2020 17:11:36 MEZ schrieb David Kastrup :
>
>So it's time to roll out 2.21.0 and I think the build instructions are
>ok-ish for that.  We don't clarify the relations/recommendations for
>Guile-1.8/2.x but that relation/recommendation is currently in flux and
>this is an unstable release.
>
>We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
>would make the web page consistent with regard to stable/unstable, so
>that would seem like a good opportunity.
>
>Except that the web page currently is broken with some Python2/3
>problems, and that people are hitting a roadblock with MacOSX.  I think
>we should point out on our download page that the GUB-provided
>installers are _only_ for 32bit MacOSX, and that separate downloads may
>be provided elsewhere (possibly linking to Marnen's page in the hope
>that it does not get overloaded?).
>
>Because once the big announcements are made, we want people to actually
>be able to work with what they find on the web page.
>
>We can release 2.21.0 prior to that, of course, since the web page
>updates are (I think) independent from releases.
>
>Thoughts?

Sounds all reasonable to me.
Just wanted to state that I'm sorry I can't be involved more these days but 
that I'm happy to see that consistently high level of activity.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: 2.21.0 and announcements

[Urs Liska]

Am 26. März 2020 17:46:07 MEZ schrieb Carl Sorensen :
>
>
>On 3/26/20, 10:12 AM, "lilypond-devel on behalf of David Kastrup"
>d...@gnu.org> wrote:
>
>
> So it's time to roll out 2.21.0 and I think the build instructions are
>   ok-ish for that.  We don't clarify the relations/recommendations for
>Guile-1.8/2.x but that relation/recommendation is currently in flux and
>this is an unstable release.
>
>We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
>  would make the web page consistent with regard to stable/unstable, so
>that would seem like a good opportunity.
>
>Except that the web page currently is broken with some Python2/3
>problems, and that people are hitting a roadblock with MacOSX.  I think
>we should point out on our download page that the GUB-provided
>installers are _only_ for 32bit MacOSX, and that separate downloads may
>   be provided elsewhere (possibly linking to Marnen's page in the hope
>that it does not get overloaded?).
>
>I can provide a pretty robust mirror of Marnen's page if need be.  It
>would be on my university server with lots of bandwidth.

Could we do that too, Ralf, Moritz?
>
>Thanks,
>
>Carl
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

GSoC applications

[Urs Liska]

Hi all,

an hour ago this year's GSoC student application deadline has been
completed, and it seems I'm currently the only registered mentor having
access to that.

Of course we can't discuss application(s) on public lists. So please
reply to me privately so I can share the application(s) with you and
discuss further process. This involves evaluation of proposal(s) and
considering mentorship.

Best
Urs

Re: stale git branches

[Urs Liska]

Am 11. April 2020 15:33:06 MESZ schrieb David Kastrup :
>Jonas Hahnfeld  writes:
>
>> Hi all,
>>
>> following removal of dev/translation-* branches, I took a closer look
>> at stale branches. I think it would make sense to keep unscoped
>> branches (outside of dev/user/) to a minimum. This should also avoid
>> overlooking old changes that have not been merged yet.
>> The following list is by no means complete, but maybe a good start:
>>
>> dev/pango contains commits:
>> 53ed2b55e2 Add a RAII wrapper for extracting FT_Face from PangoFcFont
>> c93c477180 Make Pango >= 1.36 mandatory.
>> in master:
>> 9cf8d35e8c Add a RAII wrapper for extracting FT_Face from PangoFcFont
>> 15b7118410 Make Pango >= 1.36 mandatory.
>> I'm fairly certain the branch can be removed.
>
>git rebase origin origin/dev/pango
>
>ends up with no commit on top.  So yes.
>
>> Branches dev/issue3300,
>
>Mine, but actually issue 3330.  Removed.
>
>> dev/issue3330, dev/issue3648 are likely related
>> to the named issues which have status 'Verified'. AFAICS there are
>some
>> additional commits in the branches, could be due to review comments?
>> David, you are probably the best to judge if they are fully merged or
>> some changes could still be relevant, could you take a look?
>>
>> As far as I understand, master now also has the relevant commits from
>> dev/guile-v2-work, dev/guilev2, and dev/guilev21? Can those branches
>be
>> dropped to avoid possible confusion about the current status?
>
>Will followup on all those later.
>
>> Then there are some dev/user/ branches. I consider these relatively
>> "private" to that person and would not propose to delete them on a
>> global basis. Still maybe everyone can take a look and delete unused
>> personal branches on their own?
>
>origin/dev/rune may be considered an epitaph.  I don't think anybody
>ever attempted merging what this was about: maybe it's in the interest
>area of Hans Aberg.  Whether or not somebody does an assessment of it
>at
>one point of time, I think it appropriate to leave it as-is, including
>not rebasing/rewriting any of it in-place.
>
>I'll readily agree that there is a disconcerting large set of other
>apparently semi-dead branches by living people, most of them likely
>unaware of what they left lying there.  There may be some point in
>going
>through and mailing them about what they think best to do here.

I will look into what I have lying around.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: repository at GitLab

[Urs Liska]

Am Montag, den 11.05.2020, 11:52 +0200 schrieb Jonas Hahnfeld:
> Am Montag, den 11.05.2020, 11:39 +0200 schrieb Werner LEMBERG:
> > > I granted everybody access to the group 
> > > https://gitlab.com/lilypond who
> > > sent requests so far.
> > 
> > Please give me access too; my username on GitLab is 'lemzwerg'.
> 
> Done.
> 
> > Another question is what to do with the lilypond git mirror on
> > github...
> 
> If we want to keep the mirror, we can make GitLab push updates
> automatically as potentially discussed for Savannah.

Sorry if I'm asking things I might have read if I had been able to pay
closer attention recently.

With the repository on Gitlab.com anybody who has an account can freely
fork the repository and interact with that fork. (And from there then
create Pull Requests to interact with the official repository.)

If that's the case I don't think there's an actual need for a mirror on
Github anymore. The original intention to set this up has been to
enable people to work with the code without having to ask for
permissions on the Savannah repository.

My suggestion would be to disable that mirror by updating the README.md
and archiving it (i.e. making it read-only).

Urs

> 
> Jonas

Re: Obstacles for using GitLab CI

[Urs Liska]

Am Mittwoch, den 13.05.2020, 22:33 -0400 schrieb Dan Eble:
> On May 13, 2020, at 17:13, David Kastrup  wrote:
> > > > At the current point of time, our pipeline does not tend to be
> > > > all that
> > > > full I think.  We are not at Linux kernel levels of
> > > > participation...
> > > 
> > > No, you're probably right. It's only a bit more bothersome if you
> > > have
> > > multiple changes to submit from the same countdown.
> > 
> > The real problem starts when people don't manage to get their patch
> > in
> > because the pipeline is always busy.  But if we are there, the free
> > CI
> > plan will most certainly not do the trick anymore.
> 
> One thing is clear: we need to make sure we don't abuse James'
> generosity, so I'm willing to try whatever system you think will be
> the fairest all around, even if it might be a bit "bothersome" as an
> individual submitter from time to time.
> 

That's true.
But I'd like to disencourage (can you say that?) using our small
contribution frequency as an argument here. Making it easier to
contribute and as a consequence have more contribution was a major
motivation behind all this. So while we'll surely never get to a Linux
kernel situation having a solution that scales to some activity
substantially increased from what we have now should be a requirement.

Urs

> — 
> Dan
> 
> 

README.md (was: migrating to GitLab)

[Urs Liska]

Hello all,

although I have admittedly been pretty much silent about all this I
would like to ask about getting access to the LilyPond repository in
the new place as well. My user name there is urs.liska.

One thing I noted while setting up my account is that we don't have a
README.md in the root directory. Is this by any conscious decision or
simply because nobody has done it or started a discussion yet?

I think having such a file as a first - auto-formatted - introduction
on a repository's entry page is a common expectation for any visitor of
this kind of platform. Not finding general information on the front
page would be irritating for most visitors (and potential
contributors).

This is to start a discussion of what should be on that page before
writing one and starting a Merge Request.

I think a README.md should include:

 * A general description of what LilyPond is, with a reference to the
   website and a direct link to the manuals
 * An initial overview of how to become a contributor with
* a description of the used programming languages
* a list of included support tools with their programming languages
  (e.g. musicxml2ly)
* a link to the CG
* maybe a quick reference about what we expect Merge Requests to
  look like

Best
Urs

Am Freitag, den 08.05.2020, 08:57 +0200 schrieb Jonas Hahnfeld:
> I haven't heard further objections which, for me, means we are going
> with GitLab. If you don't agree, now's your final time to speak up.
> Otherwise I would like to tackle the migration rather soon to take
> advantage of the new opportunities :-)
> 
> This leads me to some final considerations:
> 1) I'm going to disable write access to SourceForge when starting the
> migration. Otherwise the two copies will diverge over time, leading
> to
> confusion for everyone. As all old issues are retained, including
> their
> ticket numbers, this shouldn't be a problem: We can just continue
> working on them and preferably close the issues over time ;-)
> 
> 2) I'm not attempting to migrate outstanding patches from Rietveld.
> As
> we'll most probably have some during the switch, they need to be
> resubmitted. This shouldn't be a major deal as everybody should be
> working with branches already. Right?
> 
> 3) The idea is to have the "main" repository at GitLab, next to the
> issues and merge requests. This leads to the question what to do with
> Savannah because git is distributed anyway. I first thought about
> only
> pushing "important" branches and tags to GitLab (master, stable/*,
> release/*). Switching platforms would actually be one of the few
> opportunities to do so - in particular tags are hard to get rid of.
> However most of us are probably going to reuse their local
> repository,
> just updating the URL. While GitLab has options to prevent pushing
> certain refs, that's probably not a great idea. So I guess I'll just
> push an identical copy to GitLab unless somebody has a better
> proposal.
> 
> Ultimately we can talk about cleaning up the Savannah repo and only
> keeping the "important" branches there. This could for example be
> coupled with automated mirroring, which GitLab supports out-of-the-
> box. 
> I won't look into this for the initial switch though, so just make
> sure
> you're not pushing conflicting commits there...
> 
> 4) I expect the script to take 9-10 hours for the issue migration
> which
> I plan to run over night (European time). This is primarily for post-
> processing tasks at the end which are better done when fully awake.
> So
> no issue tracker during this time, but that's probably justifiable.
> 
> ---
> 
> And now to the most important task: picking a date when I'm
> available.
> I could do: Sunday evening & Monday; Tuesday & Wednesday; or
> Wednesday
> & Thursday.
> 
> Cheers
> Jonas

Re: README.md (was: migrating to GitLab)

[Urs Liska]

Am Sonntag, den 17.05.2020, 10:01 +0200 schrieb Han-Wen Nienhuys:
> On Sun, May 17, 2020 at 9:55 AM Urs Liska 
> wrote:
> > Hello all,
> > 
> > although I have admittedly been pretty much silent about all this I
> > would like to ask about getting access to the LilyPond repository
> > in
> > the new place as well. My user name there is urs.liska.
> > 
> > One thing I noted while setting up my account is that we don't have
> > a
> > README.md in the root directory. Is this by any conscious decision
> > or
> > simply because nobody has done it or started a discussion yet?
> 
> We have README.txt (generated from a .texi in Documentation/topdocs),
> and ROADMAP. I think it would be a great idea if someone would
> reformat the contents into a README.md file in the root of the tree.

My offer was to write a README.md after some discussions, but of course
reworking an existing resource is an even better approach.

Do I understand you correctly that README.txt is generated upon
compiling LilyPond? So where does it end up, I couldn't find a
README.txt neither in the source repository nor in the installation
directory. Does it only end up in the documentation (which I haven't
built locally)?

Urs

> 

Re: [RFC] Enabling GitLab CI

[Urs Liska]

Am Montag, den 18.05.2020, 11:15 +0100 schrieb Kevin Barry:
> On Mon, May 18, 2020 at 10:48:55AM +0100, James Lowe wrote:
> > but how do I know? That is the nub of what I am asking. If a patch
> > is 'new'
> > how do I know that an automated make doc is 'in progress, has
> > completed with
> > errors, has completed without errors' as I am not going to bother
> > to do any
> > work on it if it is the first two cases. What is the point?
> 
> The merge request list has an icon next to every merge request
> showing
> the current pipline status. There are different icons for passed,
> failed and in-progress. Is that what you want? See the merge request
> page for inkscape:
> https://gitlab.com/groups/inkscape/-/merge_requests
> 
> Is the information you would like to be able to see visible there?

No, at least not at the time I looked.
What James needs is additionally an icon that states that MR is
*currently* being tested.

But that will also be visible in the interface (which Jonas addressed
with his comment that in this case you can simply skip the MR and have
a look later when it can be assumed finished.

HTH
Urs

> 
> It will only show a pass if all stages pass, as far as I know.
> 
> Kevin
> 

Re: LilyPond GSoC logistics

[Urs Liska]

Am 21. Mai 2020 19:21:27 MESZ schrieb Owen Lamb :
>>
>> To preserve your code within LilyPond it probably makes sense if you
>put
>> your code into a private (but public) branch of the upstream lilypond
>> repository (i.e., not a gitlab clone of it), for example
>> 'dev/lamb/GSoC-2020'.
>>
>
>I'm a bit confused here, so let me just make sure I understand what
>you're
>saying
>
>I'll be making a new branch titled "dev/lamb/GSoC-2020" in the GitLab
>repository, based off the current master. It will be "private" in the
>sense
>that it's my personal workspace (hence the "lamb" namespace), but it
>will
>be "public" in the sense that it will be visible to the public. It will
>not
>be merely "a gitlab clone" of the master branch, since it is a new
>branch
>entirely. Did I interpret that correctly?

Yes, that should be how it is.

I think the message should read "not a fork". A fork is a personal copy that 
you need when you don't have push access to a repository.

A "clone" in Git-speak is the local copy you are actually working in. Of course 
you will have such a clone. 

HTH 
Urs


>
>I'm pretty new to git, so please excuse my lack of expertise!

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Access to push new branch to origin

[Urs Liska]

Am 23. Mai 2020 15:01:11 MESZ schrieb Werner LEMBERG :
>
>> I can grant you access to the repository later today if needed.
>> However I'd first like to understand (probably from Werner) what
>> makes a branch in the upstream repository more "preserving" than a
>> public clone.  Being distributed it really doesn't make much
>> difference from the git perspective.
>
>IMO, code for a LilyPond GSoC project should become an integral part
>of the master git repository.  I think it should be freezed in its
>final form (this is, right after GSoC ends) for documentation
>purposes.  If the stuff gets merged, the branch should still stay and
>not be deleted.
>
>Note that this is my personal point of view, and I don't insist on it.
>On the other hand: if you see problems with that approach please
>elaborate.

I would second that a student who has been accepted to GSoC should be 
considered part of the team and grantwd push access, as long as there are 
regulations preventing them from accidentally pushing to master.

Urs

>
>
>Werner

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Access to push new branch to origin

[Urs Liska]

Am Montag, den 25.05.2020, 20:30 +0200 schrieb Jonas Hahnfeld:
> Am Samstag, den 23.05.2020, 16:38 +0200 schrieb Urs Liska:
> > Am 23. Mai 2020 15:01:11 MESZ schrieb Werner LEMBERG :
> > > > I can grant you access to the repository later today if needed.
> > > > However I'd first like to understand (probably from Werner)
> > > > what
> > > > makes a branch in the upstream repository more "preserving"
> > > > than a
> > > > public clone.  Being distributed it really doesn't make much
> > > > difference from the git perspective.
> > > 
> > > IMO, code for a LilyPond GSoC project should become an integral
> > > part
> > > of the master git repository.  I think it should be freezed in
> > > its
> > > final form (this is, right after GSoC ends) for documentation
> > > purposes.  If the stuff gets merged, the branch should still stay
> > > and
> > > not be deleted.
> > > 
> > > Note that this is my personal point of view, and I don't insist
> > > on it.
> > > On the other hand: if you see problems with that approach please
> > > elaborate.
> > 
> > I would second that a student who has been accepted to GSoC should
> > be considered part of the team and grantwd push access, as long as
> > there are regulations preventing them from accidentally pushing to
> > master.
> 
> Invited @WolfGangsta to the lilypond group.

While we're at it, I'd be happy to be part of the group too.

Urs

Re: GSoC 2020 update

[Urs Liska]

Hi Owen!

Am 27. Mai 2020 22:58:19 MESZ schrieb Owen Lamb :
>Hi all!
>
>I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it
>appears to be visible on GitLab. I haven't committed anything new yet,
>but
>I will soon. I'll push any commits I make at the end of each work day.
>
>I plan to give updates regularly every Friday. So far I have been
>investigating open-type-font.cc as an entrypoint for changing the
>encoding,
>but I'll have a more detailed report then.
>
>I have a couple questions in the meantime:
>
>I plan to temporarily add the Bravura font to my lilypond branch for
>testing SMuFL throughout the summer. Is there any legal reason not to

No. Bravura has very avöctively been developed and promoted to be an open font.

It may be shared along with the usual license stuff, but ...

>(or
>at least to .gitignore it so it only appears on my machine)? 

... as long as we don't intend to ship Bravura along with LilyPond I'd say it 
shouldn't be added to the repository. Except if it's necessary to get your work 
tested (maybe one day you'll habe a merge request that won't work without a 
real SMuFL font ...).

To keep something local to your computer it's better not to use the .gitignore 
file but .git/info/exclude - which does the same but without itself being 
committed.

Best
Urs

It appears
>to
>be licensed under OFL 1.1, just like Feta, but I'd just like to make
>sure
>I'm not accidentally breaking any laws as I work publicly.
>
>This next one is a minor annoyance and probably a C++ newbie question,
>but
>my IDE (VS Code, chosen for comfort) is reporting "a
>dynamically-initialized local static variable is not allowed inside of
>a
>statement expression" about a million times throughout the .cc files,
>whenever particular #define'd macros, e.g. ly_symbol2scm or
>get_property,
>are referenced. From what I know, macros aren't dynamically
>initialized,
>are they? Does anyone know why this might be happening? This doesn't
>seem
>to affect compilation, so I can easily ignore the red squiggly lines,
>but
>if there's a way to get rid of them, I'm all ears.
>
>And, of course, if you have any comments or suggestions about anything
>else, please let me know!
>
>Thanks,
>Owen

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Remove lily-git?

[Urs Liska]

Am Donnerstag, den 04.06.2020, 13:36 +0200 schrieb Jean Abou Samra:
> Hi,
> Le 04/06/2020 à 08:31, James Lowe a écrit :
> > On 03/06/2020 21:25, Karlin High wrote:
> > > On 6/3/2020 3:14 PM, Jean Abou Samra wrote:
> > > > There is a discussion at 
> > > > https://gitlab.com/lilypond/lilypond/-/issues/1012
> > > > about the future of lily-git.Basically, I think that it no
> > > > longer 
> > > > makes sense to keep it now that we switched to GitLab.
> > > 
> > > I remember seeing this thing bring in over 500MB of dependencies
> > > on a 
> > > Debian Linux system. And I was thinking, "If that's the only
> > > piece of 
> > > TCL in the whole LilyPond ecosystem, there has GOT to be a way
> > > to 
> > > avoid having this."
> > 
> > I am not sure that is correct, lily-git is just a set of python 
> > commands with a Front End GUI (for the likes of me) that made sure 
> > that you had set your git repo correctly and could easily download 
> > $LILYPOND_GIT. It also forced you to set your git user and email.
> > 
> > Lily-git in and of itself was tiny and needed hardly anything to
> > run 
> > (wish lily-git.tcl).
> > 
> > The 500MB of dependencies was, I expect, for dblatex et al. That
> > we 
> > needed for doc building at the time but lily-git only cloned the
> > repo 
> > (and allowed a button to hard reset - again for idiots like me).
> > 
> > I am a bit older and wiser now, but even so git is still a
> > terrible 
> > 'ecosystem' not made much better by the gitlabs and githubs of the 
> > world (I have the joy of having to interface with both as a 
> > non-developer). That said, yes we don't 'need' lily-git, however
> > I'd 
> > like to give a hat-tip to the few devs that kept it going so I
> > could 
> > do my work. If it weren't for lily-git (and at the start 'lily-dev' 
> > - 
> > still less faff than containers and jails BTW for non-devs) I'd
> > have 
> > not been able to easily contribute to this project and may have
> > simply 
> > given up having to learn the terrible interface that is git cli
> > with 
> > all the breakages of master we had at the start of when I joined.
> > 
> > James
> I do agree with you that Git can be a bit of a trick to learn (at
> least,
> there is a long path before you fully master it). What if right now
> we
> just added a link to some Git graphical client like 
> https://www.syntevo.com/smartgit/?

SmartGit is a great Git client, but it is proprietary, so we can't link
to it (even provided they have a free (lowercase 'f') license for non-
commercial work).
Unfortunately I haven't yet found a Free GUI tool that made me feel
comfortable, so I've always got back to it.

> It doesn't remove the complexity of Git (obviously that's quite more
> involved than lily-git, the target not being the same), but at the
> very
> least, you don't need to bother with a command-line interface.
> 
> lily-git is not going to be usable in an immediate future.
> Anyway, if I had to write something, I would do it in Python as per
> the abovementioned issue (now that recent versions of Python ship
> with tkinter). And as we're still trying to figure out how exactly
> we are going to work with GitLab, starting a new tool right now
> doesn't look like a good idea. So, what I would propose at this point
> is
> to drop lily-git.tcl, as it doesn't provide a value neither for a
> user
> these days, nor for the people that could develop a new tool in
> Python
> in the future; then, depending on how things go on, and if we feel
> the
> need for it, write lily-git.py or whatever. Maybe we could open an
> issue
> to track that. Makes sense?

To me, yes. But I don't think that is too relevant here.

Best
Urs

> 
> Best,
> Jean Abou Samra
> 
> 

Re: GSoC 2020 update, June 15

[Urs Liska]

Am Dienstag, den 16.06.2020, 09:16 +0200 schrieb Han-Wen Nienhuys:
> Isn't Smufl a standard proposed by the Dorico folks? 

Yes and no. Daniel Spreadbury spearheaded the effort while Dorico was
developed. But it was originally conceived as an open standard.

> We could try to
> 
> agree on a mechanism with them?

If it fits into what they (this is also the www music notation
community group (https://www.w3.org/community/music-notation/)) see fit
for the way forward it is certainly possible to talk with them.

Urs

Re: Accidentals' font

[Urs Liska]

Am Samstag, den 04.07.2020, 10:06 -0500 schrieb Karlin High:
> On 7/4/2020 5:55 AM, Paolo Prete wrote:
> > Just leave Feta as a native font and insert a dummy
> > wrapper for Gonville in the ./configure. This does not require any
> > development, nor uniformity in the coding standard and can be
> > easily added
> > to the source tree.
> 
> This discussion is reminding me of the Google Summer of Code project 
> proposal, "Support for Style Sheets."
> 
> "
> LilyPond’s engraving output can be tweaked to the least detail, and
> one 
> important addition in recent years was the ability to use
> alternative 
> notation fonts. It is possible to create reusable modules for “house 
> styles”, but this project aims at bringing this to a new level by 
> creating a convenient extension package with support for creating, 
> applying, and sharing modular style sheets.
> "
> 
> 
> That looks to me like there IS community support for having ways to 
> change the look-and-feel of LilyPond's output, depending how the 
> development goals are defined and presented.

I just want to point out that there's an openLilyLib package 
https://github.com/openlilylib/notation-fonts which allows you to use
any installed (i.e. compatible) notation font as easily as

\include "oll-core/package.ily"
\loadPackage notation-fonts
\useNotationFont lilyjazz

This loads a default stylesheet provided for lilyjazz, but you can also
specify custom styles with

\useNotationFont \with {
  stylesheet = #'my-custom-style.ily
} haydn

The repository with the old OFL versions of Abraham Lee's work (which
includes Gonville BTW) has been mentioned, and Frescobaldi provides a
easy-to-use dialog to install and choose notation fonts with built-in
preview function.

Urs

Re: Accidentals' font

[Urs Liska]

Am Donnerstag, den 09.07.2020, 21:40 +0200 schrieb Paolo Prete:
> On Thu, Jul 9, 2020 at 8:35 PM Jean Abou Samra 
> wrote:
> 
> > Le 08/07/2020 à 15:31, Paolo Prete a écrit :
> > 
> > 
> > 
> > On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra  > >
> > wrote:
> > 
> > > I would like to emphasize that this is not at all simple. I agree
> > > that
> > > the technical part is reachable. Yet, this has consequences on
> > > the
> > > organization of the LilyPond ecosystem that have to be considered
> > > with care.
> > > 
> > > Fonts external to LilyPond also have development cycles that are
> > > different from LilyPond’s. If Gonville or other fonts were
> > > integrated as
> > > built-in options, we would end up receiving bug reports or
> > > feature requests
> > > from fellow users about fonts which we are incompetent about. It
> > > would
> > > force the authors of these fonts to follow LilyPond issues and
> > > make changes
> > > in parallel with Feta, for example, make it SMuFL-compliant by
> > > the end of
> > > the summer, which is very demanding. When the original author
> > > will not be
> > > available or no longer willing to support it, users will complain
> > > about the
> > > font not working and other LilyPond developers will need to fix
> > > it, and
> > > first learn its generation system, which is a custom one entirely
> > > different
> > > from Feta’s.
> > > 
> > 
> > Hello Jean,
> > 
> > I think the problem you emphasize is automatically solved with the
> > ./configure flag. Let me show a practical example.
> > ffMPEG has a native aac codec and a configure flag (--enable-
> > libfdk-aac)
> > which adds a third-party aac encoder (Fraunhofer FDK AAC).
> > 
> > Hi Paolo,
> > 
> > If I'm not mistaken, the use case for configure flags like
> > --enable-guilev2 is to influence compilation. By contrast, fonts
> > are loaded
> > dynamically at runtime. Hence, a configure flag would essentially
> > do
> > nothing but move a few files (except if it changed the default, but
> > we
> > don't want that).
> > 
> 
> Hi Jean,
> 
> I intended it exactly in the way you described. That flag would not
> influence compilation but only *linking*, preventing compatibility
> issues
> (mismatch of versions)
> 
> 
> > In fact, it's already possible and very simple to build LilyPond
> > with
> > Gonville support: just follow the usual build procedure, then copy
> > the
> > Gonville OTF files into
> > build/out/share/lilypond/current/fonts/otf/. That's
> > simple enough that I don't believe it deserves a special flag.
> > 
> 
> Yes, but this would make a *patched* build, and not a clean build.
> Note too
> that the flag should be more general than --with-gonville-font (for
> example, just an extemporary idea: --with-font=gonville,foobarfont
> etc.)
> 
> 
> 
> > Doing that, every maintainer of a *distro* (I highlight the word
> > *distro*,
> > and not the src one) can choose to create the binary with or
> > without third
> > party pieces.
> > Note that, for example, ffMPEG. There are some distros of ffMPEG
> > with
> > x264, and some distros without.
> > 
> > This nuance is not possible with LilyPond since, to my knowledge,
> > the vast
> > majority of users downloads binaries from lilypond.org.
> > 
> 
> This is true. But what if, in the future, someone wants to create,
> for
> example, a Linux Distro called LilyBuntu ? ;-)
> 
> 
> 
> > That said, I really think we ought to pause this discussion until
> > the
> > details of SMuFL support get clear.
> > 
> > 
> I agree. I pause it as well.
> 

But I'd like to repeat that the fonts created by Abraham (including
Gonville) are at least partially available as free fonts, and they
already *can* be used in a regular LilyPond installation without any
hassles.

All you need to do is copy (or better link) the font files in the fonts
directory (Frescobaldi even offers a nice interface for handling that
for arbitrary new LilyPond installations) and add some code to the
paper block of your document. 
If you use openLilyLib this is as easy as \useNotationFont Gonville.
The notation-fonts package even provides (optional) default stylesheets
for all supported fonts (to provide a good starting point regarding
e.g. line thicknesses).

So I really don't see the need for a patched compilation of LilyPond.
Urs

>  Best,
> P

Re: Accidentals' font

[Urs Liska]

Am Freitag, den 10.07.2020, 10:34 +0200 schrieb Jean-Julien Fleck:
> Hello Urs,
> 
> Le ven. 10 juil. 2020 à 09:03, Urs Liska  a
> écrit :
> > 
> > But I'd like to repeat that the fonts created by Abraham (including
> > 
> > Gonville) are at least partially available as free fonts, and they
> > 
> > already *can* be used in a regular LilyPond installation without
> > any
> > 
> > hassles.
> > 
> > 
> > 
> > All you need to do is copy (or better link) the font files in the
> > fonts
> > 
> > directory (Frescobaldi even offers a nice interface for handling
> > that
> > 
> > for arbitrary new LilyPond installations) and add some code to the
> > 
> > paper block of your document. 
> > 
> > If you use openLilyLib this is as easy as \useNotationFont
> > Gonville.
> > 
> > The notation-fonts package even provides (optional) default
> > stylesheets
> > 
> > for all supported fonts (to provide a good starting point regarding
> > 
> > e.g. line thicknesses).
> 
> Could you please give us a link that explains how to do that
> installation ?
> 
> 
> I've been searching (a bit) ever since the page 
> https://github.com/OpenLilyPondFonts appeared in this thread but
> couldn't find a tutorial to explain step by step what to do. I would
> have expected that such an explanation to be placed in the README.md
> file at the top of each font repository, at least pointing to a place
> explaining the generic way to do it but I couldn't find any.
> 
> Is there such a step-by-step tutorial and where can I find it ?

Unfortunately not comprehensively.
There's  https://github.com/openlilylib/oll-core/wikiwhich explains how
to obtain openLilyLib
  https://github.com/openlilylib/notation-fonts/gives a short overview
on how the notation-fonts package is used.
  
https://github.com/openlilylib/notation-fonts/tree/master/usage-examples/fontsincludes
several usage examples (along with compiled PDF files).
I'm not sure where installing additional fonts in LilyPond is
explained, but in a nutshell: you have to identify
the  /usr/share/lilypond/current/fonts/directory within a given
LilyPond installation, and drop the OTF and SVG font files in the
corresponding subdirectory (.woff files go into SVG).Best practice for
this is storing all your fonts in one central location and place links
into the LilyPond directory.
If you use a current Frescobaldi the tool Tools=>Document fonts
provides a convenient interface for manging fonts (installation and
creating the input code).
HTH
Urs
> Thanks,
> 
> --
> JJ Fleck
> Physique et Informatique
> PCSI1 Lycée Kléber

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 06:59:16 MESZ schrieb Werner LEMBERG :
>
>> In the meantime, I've gotten Bravura glyphs to appear on the page!
>
>Congrats!
>
>A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
>you change from the (IMHO preferable) `-` to `_` in the file name?  I
>consider `_` an abomination that is only necessary because `-` is not
>a valid character in identifiers of many programming languages.
>
>Another issue: Maybe it makes sense if you try to rebase your branch
>from time to time.

Really rebase?
This would be a case where "general wisdom" argues against modifying pushed 
commits.
Typically you'd rather merge master into your working branch here.

I can see use in both ways, but I strongly suggest making an explicit decision 
with feedback from those who might occasuonally want to look at your code.

But trying not to let master get too far from your branch is surely a good 
suggestion.

Urs

>
>
>Werner

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
>>> Another issue: Maybe it makes sense if you try to rebase your
>>> branch from time to time.
>> 
>> Really rebase?
>
>Yes, I favour rebasing over merging since the former causes a
>`prettier' git commit tree.
>
>> This would be a case where "general wisdom" argues against modifying
>> pushed commits.  Typically you'd rather merge master into your
>> working branch here.
>
>Well, there's a good reason that gitlab has a big, fat 'rebase'
>button...

Yes, but that is meant to deal with integrating the final result into master.
Rebasing during work means that Owen's commits don't match those pulled by 
others.

I don't have a strong opinion here but it should be an agreed-upon procefure 
for all.

Urs

>
>
>Werner

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 23:31:32 MESZ schrieb Jean Abou Samra :
>Hi everyone,
>
>Le 01/08/2020 à 18:19, Urs Liska a écrit :
>> Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
>>>>> Another issue: Maybe it makes sense if you try to rebase your 
>>>>> branch from time to time. 
>>>> Really rebase? 
>>> Yes, I favour rebasing over merging since the former causes a 
>>> `prettier' git commit tree.
>>>> This would be a case where "general wisdom" argues against
>modifying 
>>>> pushed commits. Typically you'd rather merge master into your 
>>>> working branch here. 
>>> Well, there's a good reason that gitlab has a big, fat 'rebase' 
>>> button... 
>
>Not sure about the meaning of your message: this button shows up
>because 
>we enabled it as a project-wide setting. To my knowledge, the default 
>and most common strategy is merging.
>
>> Yes, but that is meant to deal with integrating the final result into
>
>> master. Rebasing during work means that Owen's commits don't match 
>> those pulled by others. I don't have a strong opinion here but it 
>> should be an agreed-upon procefure for all.
>
>While I generally prefer merging over rebasing, since we enforce an 
>all-fast-forward policy for merging to master, I think we should rebase
>
>here. My reasoning is that you put in more information when resolving 
>conflicts during a rebase: merging means you unify two diverging 
>histories, thus you get prompted once and for all, but rebasing forces 
>you to resolve conflicts for each intermediary commit. As far as my 
>understanding extends, if Owen merges now, there will still be work
>left 
>for rebasing at the end of the project, part of which will be 
>duplicated. By contrast, rebasing now means less error-prone work in
>the 
>future.

That sounds reasonable.

However, it means everybody should expect commits to change after having looked 
at rhem. So: always pull again (well, that's clear) and never add commits to 
Owen's branch wirhout clarifying the state directly with him.

Urs
>
>Best,
>Jean

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GSoC 2020 update: Aug 7

[Urs Liska]

Hi Owen,

it's always a pleasure seeing your project evolve and proceed. I'd like
to throw in a comment, although I'm rather sure it isn't actually
needed.

Am Freitag, den 07.08.2020, 21:49 -0700 schrieb Owen Lamb:
> Hi all!
> 
> ...
>
> --turned out to be a major point of difference between
> LilyPond's and SMuFL's treatment of flags.
> 
> I've slightly modified my general project approach, 
>
> ...
>
> The school year is almost upon us here in AZ, and, as I mentioned at
> the
> beginning of summer, there'll be some overlap with GSoC. I'll be out
> for
> the count for a couple weekdays next week, so I'll pick up Saturday
> to make
> up for it. After that, I expect to be doing more night/weekend hours
> as
> classes start up the following week on the 20th.
> 
> My plan is largely the same as it was last week. If you have any
> questions/concerns, as always, feel free to ask away!

I don't recall reading anything about it but probably you have thought
about it right from the start, so please take this as just a friendly
reminder.

Now that the deadline of the project starts coming into view you should
keep in mind that the priority is to have your work properly tested,
cleaned-up and merged. This is much more important than getting one or
more further features implemented - even if they should be your pet
features or seem crucial.
As far as I can see your work so far has been extremely useful, and it
will remain so even if at the end of GSoC it's not in a state that
every user can use it out-of-the-box.
OTOH if I understood the recent discussion about merging and rebasing
correctly your code itself has not been reviewed at all so far? In that
case you should definitely expect the review process to take longer
than you initially expect... Even without serious issues the review
process for getting anything into LilyPond is somewhat time-consuming.

So I encourage you to plan from the end backwards and don't push the
possibly tedious and boring tasks of finalizing your work too much away
.

Best
Urs

> 
> Thanks,
> Owen

Re: LilyPond 2.21.5 release

[Urs Liska]

Am 18. August 2020 01:01:20 MESZ schrieb Andrew Bernard 
:
>Please pardon me for asking this once again... but where does one find 
>the set of changes just for this release, not that long accumulated
>list 
>in the documentation? I have forgotten where this info is.

I don't know whether this is noted explicitly anywhere, but you can list the 
commits between the previous and the latest tag (can't try out the command on 
my mobile right now)

Urs
>
>
>Andrew
>
>
>On 18/08/2020 2:30 am, Shane Brandes wrote:
>> Looks like a lot of neat new stuff implemented!
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: LilyPond 2.21.5 release

[Urs Liska]

Am Dienstag, den 18.08.2020, 02:44 +0200 schrieb Urs Liska:
> 
> Am 18. August 2020 01:01:20 MESZ schrieb Andrew Bernard <
> andrew.bern...@gmail.com>:
> > Please pardon me for asking this once again... but where does one
> > find 
> > the set of changes just for this release, not that long accumulated
> > list 
> > in the documentation? I have forgotten where this info is.
> 
> I don't know whether this is noted explicitly anywhere, but you can
> list the commits between the previous and the latest tag (can't try
> out the command on my mobile right now)

git log release/2.21.4-1..release/2.21.5-1

should give you a start, or more concisely:

git log --pretty=oneline release/2.21.4-1..release/2.21.5-1

HTH
Urs

> 
> Urs
> > 
> > Andrew
> > 
> > 
> > On 18/08/2020 2:30 am, Shane Brandes wrote:
> > > Looks like a lot of neat new stuff implemented!
> > > 

Re: maintaining lilypond git repository on github

[Urs Liska]

Am Mittwoch, den 19.08.2020, 09:24 +0200 schrieb Werner LEMBERG:
> >>   git remote update
> >>   git push --mirror g...@github.com:lilypond/lilypond.git
> > 
> > Definitely add --prune to "git remote update" to remove branches
> > that ceased to exist on the remote.
> 
> OK, done.
> 
> > In general, I would not run the mirroring from a real working copy
> > of the repository because AFAICT git push --mirror will also push
> > local branches.
> 
> I don't do that.  I have a separate clone for that (created with `git
> clone --mirror`).
> 
> > But it doesn't really matter if everybody is ok with me removing
> > them once I get access.

What's your Github user name?
I can give you access but couldn't find your account.

Urs

> 
> This is fine with me.
> 
> 
>Werner
> 

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Urs Liska]

Am Montag, den 24.08.2020, 09:06 +0200 schrieb Werner LEMBERG:
> > I've reordered and rebased my code, and it is now up to date with
> > the current master.  I've just published the new branch to GitLab
> as
> > dev/lamb/GSoC-2020-final if you'd like to give it a look.  It's
> only
> > nine commits now, instead of over a hundred, and they're ordered in
> > a way that's hopefully easy to follow.
> 
> Thanks!
> 
> > At the same time, I'll write docs for my work.  I figure I'll make
> > nine documentation commits, one for each code change commit.  (Of
> > course, I may not need one for every commit, but we'll see.)  Does
> > that sound all right?  Would it be better to make yet another
> branch
> > with the documentation integrated into the main commits?
> 
> I don't see any reason to synchronize the documentation with commits;
> it looks like unnecessary work.  Maybe others disagree, but I think
> you should simply add all of the documentation in a single, separate
> commit.
> 

+1

But probably regtests should match the state of their commits. Except
if you can add all regtests at the end.

Urs
> 
> Werner
> 

Re: Scheme in LilyPond

[Urs Liska]

Am 01.06.2017 um 17:41 schrieb Paul:
> On 06/01/2017 11:03 AM, Charles Winston wrote:
>
>> And I get an error saying that make-note-ev is an unbound variable. I
>> thought that we could call Scheme procedures from the source in
>> lilypond files. What am I missing here?
>
> I'll just add that generally you can call scheme procedures defined in
> source files when they are defined with 'define-public'.  If they are
> defined with 'define' then they probably won't be callable.  In the
> latter case you can often just copy/paste them into your .ly file
> (adding # at the beginning of the opening paren(s)) and use them that
> way.

One more addition: This limitation to define-public is only true for
Scheme files (.scm) that are included with use-modules. All definitions
within LilyPond files are public automatically. So when you write

#(define my-variable "something")

in an included LilyPond file you can always access it directly.

HTH
Urs

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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: Some questions related to score video generation

[Urs Liska]

Hi Knut,

very interesting project (which should be included in my plan for an
additional "interesting uses" page on lilypond.org). Some comments (but
explicitly without any warranty):


Am 07.07.2017 um 09:55 schrieb Knut Petersen:
> Hi everybody!
>
> I extended my video generation script to allow coloring notes as they
> are played.
> Currently that works for noteheads and rests, see this example I
> uploaded to youtube .
>
> Question 1: I use an after-line-breaking override for NoteHead, Rest
> and MultiMeasureRest
> events to encode the moment and the duration in the color fields of
> the notehead
> grobs, translate to postscript and postprocess the postscript files to
> tell ghostscript
> to generate images for every moment that has one of those events. Does
> anybody
> know a less hackish way to generate  multiple copies of the systems of
> a score
> with changes to only the color of some grobs?

What about generating the score as SVG and coloring the objects with CSS
? you could store a consecutive *index* in the grobs (rather than actual
moments) and create a list with all moments when the coloring should change.

In a post-processing step you could iterate over the list, color the
elements with the corresponding index and produce an image from that.
In a second post-processing step you could iterate over the list to
compile the generated images according to the moments in the list.

>
> Question 2: I also would like to change the color of the stems, flags
> and dots that
> belong to a notehead, but those have no 'duration. Does anybody have
> an idea
> how to give a certain color to those grobs from inside the code called
> by the
> notehead after-line-breaking override?

If nh is the name of your grob in the callback then

  (ly:grob-object nh 'stem)
will give you the stem.

AFAIK the Flag etc. are not all accessible this way but you can do (in a
(let)):
  (nc (ly:item-get-column nh)) ; get the note column for the note head
  (elements (ly:grob-array->list (ly:grob-object nc 'elements)))
which gives you a list of all items in the note column to iterate over.

HTH
Urs

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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: Some questions related to score video generation

[Urs Liska]

Am 07.07.2017 um 15:00 schrieb Knut Petersen:
> Am 07.07.2017 um 12:04 schrieb Knut Petersen:
>
> There is a new version of the demonstration video online: I
> Fyrreskoven. 
> Coloring of stems / flags /dots works now.

Great!
I'll have to see whom I can show this - as people think there's no way
to do things like this with LilyPond.

Do you think your approach would be helpful for doing something like
this "live" in the browser, with an SVG score and a MIDI file?

Urs

PS: I fondly recally playing some songs by Peterson-Berger with the
fabulous Swedish Maria Bengtsson, way back decades ago ...

>
> Knut
>

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Fwd: Possible opportunity for GNU contributions by FSF intern this fall

[Urs Liska]

 Ursprüngliche Nachricht 
Von: Andrew Engelbrecht 
Gesendet: 5. September 2017 19:40:38 MESZ
An: summer-of-c...@gnu.org
Betreff: Possible opportunity for GNU contributions by FSF intern this fall

Hello GNU maintainers,

The FSF tech team may take on a full or part time intern this fall. They
have experience writing programs in C and would like to use their time
to contribute to a GNU project. I'm wondering whether any of you would
be interested in mentoring and receiving contributions from the applicant.

The applicant has the following skills:

- C (and C++) programmer; basic experience with HTML and PHP (favorite
language is C)

- Started coding about four years ago, starting with Python, then C

- Has been using only GNU/Linux for five years, supports and promotes
the free software movement

- Self-hosts personal net infrastructure

- Wrote and is maintaining a command line client written in C for use
with a social network

- Involved in adding features to their version of a small educational
operating system

- Uses GPL licenses and thinks software should use copyleft


Please let us know via this list or  this week if you
are interested in mentoring and receiving contributions from the
applicant this fall.

Thank you, :)
Andrew

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

LilyPond in Debian

[Urs Liska]

Hi all,

I'm investigating Debian again, looking for a new system for me. So far
I've done a pretty minimal installation of Debian Buster (current
"Testing"), looked for LilyPond and Guile - and was somewhat surprised.

Last time I looked I found that the "lilypond" package had been removed
from Debian Stretch (which has become the current stable release in the
meantime), along with the removal of Guile 1.8.

So I was surprised to see that a lilypond package is again available for
Buster, albeit only 2.18.2. Further investigation turned out that
obviously LilyPond has been reintroduced with Buster, and is also
available in Stretch as a backport (see
https://packages.debian.org/search?keywords=lilypond&searchon=names&suite=all§ion=all)

Guile 1.8 on the other hand is not available in Stretch nor Buster - but
in Sid (unstable branch), with the label "debports".

If I'm not mistaken Debian only provides packages that are compiled by
them, so LilyPond can only be included when Guile 1.8 is also present.
So I'm actually wondering how the "lilypond" package could get into
Stretch and Buster.

Could someone with more knowledge update me on this?

Thanks
Urs


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

Re: LilyPond in Debian

[Urs Liska]

Am 11.09.2017 um 10:41 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Hi all,
>>
>> I'm investigating Debian again, looking for a new system for me. So far
>> I've done a pretty minimal installation of Debian Buster (current
>> "Testing"), looked for LilyPond and Guile - and was somewhat surprised.
>>
>> Last time I looked I found that the "lilypond" package had been removed
>> from Debian Stretch (which has become the current stable release in the
>> meantime), along with the removal of Guile 1.8.
>>
>> So I was surprised to see that a lilypond package is again available for
>> Buster, albeit only 2.18.2. Further investigation turned out that
>> obviously LilyPond has been reintroduced with Buster, and is also
>> available in Stretch as a backport (see
>> https://packages.debian.org/search?keywords=lilypond&searchon=names&suite=all§ion=all)
>>
>> Guile 1.8 on the other hand is not available in Stretch nor Buster - but
>> in Sid (unstable branch), with the label "debports".
>>
>> If I'm not mistaken Debian only provides packages that are compiled by
>> them, so LilyPond can only be included when Guile 1.8 is also present.
>> So I'm actually wondering how the "lilypond" package could get into
>> Stretch and Buster.
>>
>> Could someone with more knowledge update me on this?
> It has its own prepackaged Guile-1.8 shared libraries in a private
> directory.  Its executable has been replaced by a shell script that adds
> this directory to the loadpath and then calls the real executable.
>
> Hats off, I guess.  Probably not a perfect fit as a development
> platform, but at least good for running.
>

Yes, indeed better than nothing (sudo apt install lilypond => "package
lilypond has no release candidate").
OTOH it may take some pressure off the need for a "proper" solution ...

Hm, will I be able to get a system where I can build LilyPond again? I'm
really not fluent enough with package management, but could I install
Guile 1.8 from sid and use that for setting up my LilyPond environment?
I really don't want to use an extra virtual machine just for that.
(I don't need step-by-step instructions here, just a confirmation if it
is possible (and maybe a general pointer on how to proceed)

Urs


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

Re: LilyPond in Debian

[Urs Liska]

Am 11.09.2017 um 11:23 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Yes, indeed better than nothing (sudo apt install lilypond => "package
>> lilypond has no release candidate").
>> OTOH it may take some pressure off the need for a "proper" solution ...
>>
>> Hm, will I be able to get a system where I can build LilyPond again? I'm
>> really not fluent enough with package management, but could I install
>> Guile 1.8 from sid and use that for setting up my LilyPond environment?
>> I really don't want to use an extra virtual machine just for that.
>> (I don't need step-by-step instructions here, just a confirmation if it
>> is possible (and maybe a general pointer on how to proceed)
> You just take the Guile 1.8.8 distribution (Git or tarball) to some
> suitable directory and do
> ./autogen.sh  # I think
> ./configure --disable-error-on-warning --prefix=/opt/guile-1.8

This worked quite well, except I had to compile GNU MP along the way,
which made me stumble over this little gem of web publishing:

This site does notuse cookies
I agree! 


:-)

> make

This aborts with errors related to .texi files and ...

> sudo make install

... this too.
However, before it reports

Libraries have been installed in:
   /opt/guile-1.8/lib
After that it enters and leaves the srfi subdirectory and starts
complaining inside doc.

So I *think* Guile itself is compiled and installed correctly, but the
docs are not.
How can I easily check if the library is available? ldconfig -p | grep
guile only returns entries for Guile 2 in /lib/x86_64-linux-gnu (but
maybe ldconfig doesn't know about self-compiled libraries?)

>
> and then you have to use something like
> CONFIG_GUILE=/opt/guile-1.8/bin/config-guile ./autogen.sh
>
> in order to configure LilyPond.

I think I should not start trying this before having confirmed the
previous step.

Urs

>
> Compiling LilyPond will produce an inordinate amount of warnings on
> current GCC.
>

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

Re: LilyPond in Debian

[Urs Liska]

Am 11.09.2017 um 12:10 schrieb Federico Bruni:
> Il giorno lun 11 set 2017 alle 10:53, Urs Liska
>  ha scritto:
>> could I install Guile 1.8 from sid and use that for setting up my
>> LilyPond environment? I really don't want to use an extra virtual
>> machine just for that.
>
> Urs, in case you missed it, recently I've built a container based on
> Fedora:
> https://github.com/fedelibre/LilyDevOS#container

I still don't read the lists (I have a filter in place that copies
threads I start to my regular inbox).

>
> Once you've built the binary in the container, it's available also to
> the host without any further configuration (i.e. no need of shared
> folders).

OK, this seems like progress, although I'd much prefer having the build
environment on my actual regular OS.

But will a LilyPond build created on this LilyDev also run outside of
the VM? It seems to me I would also have to use the VM for *working*
with the self-compiled LilyPond?

Best
Urs

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

Re: LilyPond in Debian

[Urs Liska]

Am 11.09.2017 um 14:47 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Am 11.09.2017 um 11:23 schrieb David Kastrup:
>>> Urs Liska  writes:
>>>
>>>> Yes, indeed better than nothing (sudo apt install lilypond => "package
>>>> lilypond has no release candidate").
>>>> OTOH it may take some pressure off the need for a "proper" solution ...
>>>>
>>>> Hm, will I be able to get a system where I can build LilyPond again? I'm
>>>> really not fluent enough with package management, but could I install
>>>> Guile 1.8 from sid and use that for setting up my LilyPond environment?
>>>> I really don't want to use an extra virtual machine just for that.
>>>> (I don't need step-by-step instructions here, just a confirmation if it
>>>> is possible (and maybe a general pointer on how to proceed)
>>> You just take the Guile 1.8.8 distribution (Git or tarball) to some
>>> suitable directory and do
>>> ./autogen.sh  # I think
>>> ./configure --disable-error-on-warning --prefix=/opt/guile-1.8
>> This worked quite well, except I had to compile GNU MP along the way,
>> which made me stumble over this little gem of web publishing:
>>
>> This site does notuse cookies
>> I agree! 
>>
>>
>> :-)
>>
>>> make
>> This aborts with errors related to .texi files and ...
> Oh right.  Should not have gone from memory.

Thanks, but:

$ git apply 0001-Fix-Texinfo-sectioning.patch
uliska@elitebook-debian:~/git/software/guile$ make
make  all-recursive
make[1]: Verzeichnis „/home/uliska/git/software/guile“ wird betreten
Making all in oop
make[2]: Verzeichnis „/home/uliska/git/software/guile/oop“ wird betreten
Making all in goops
make[3]: Verzeichnis „/home/uliska/git/software/guile/oop/goops“ wird
betreten
make[3]: Für das Ziel „all“ ist nichts zu tun.
make[3]: Verzeichnis „/home/uliska/git/software/guile/oop/goops“ wird
verlassen
make[3]: Verzeichnis „/home/uliska/git/software/guile/oop“ wird betreten
make[3]: Für das Ziel „all-am“ ist nichts zu tun.
make[3]: Verzeichnis „/home/uliska/git/software/guile/oop“ wird verlassen
make[2]: Verzeichnis „/home/uliska/git/software/guile/oop“ wird verlassen
Making all in libguile
make[2]: Verzeichnis „/home/uliska/git/software/guile/libguile“ wird
betreten
make  all-am
make[3]: Verzeichnis „/home/uliska/git/software/guile/libguile“ wird
betreten
make[3]: Für das Ziel „all-am“ ist nichts zu tun.
make[3]: Verzeichnis „/home/uliska/git/software/guile/libguile“ wird
verlassen
make[2]: Verzeichnis „/home/uliska/git/software/guile/libguile“ wird
verlassen
Making all in ice-9
make[2]: Verzeichnis „/home/uliska/git/software/guile/ice-9“ wird betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/uliska/git/software/guile/ice-9“ wird verlassen
Making all in guile-config
make[2]: Verzeichnis „/home/uliska/git/software/guile/guile-config“ wird
betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/uliska/git/software/guile/guile-config“ wird
verlassen
Making all in guile-readline
make[2]: Verzeichnis „/home/uliska/git/software/guile/guile-readline“
wird betreten
make  all-recursive
make[3]: Verzeichnis „/home/uliska/git/software/guile/guile-readline“
wird betreten
Making all in ice-9
make[4]: Verzeichnis
„/home/uliska/git/software/guile/guile-readline/ice-9“ wird betreten
make[4]: Für das Ziel „all“ ist nichts zu tun.
make[4]: Verzeichnis
„/home/uliska/git/software/guile/guile-readline/ice-9“ wird verlassen
make[4]: Verzeichnis „/home/uliska/git/software/guile/guile-readline“
wird betreten
make[4]: Verzeichnis „/home/uliska/git/software/guile/guile-readline“
wird verlassen
make[3]: Verzeichnis „/home/uliska/git/software/guile/guile-readline“
wird verlassen
make[2]: Verzeichnis „/home/uliska/git/software/guile/guile-readline“
wird verlassen
Making all in emacs
make[2]: Verzeichnis „/home/uliska/git/software/guile/emacs“ wird betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/uliska/git/software/guile/emacs“ wird verlassen
Making all in scripts
make[2]: Verzeichnis „/home/uliska/git/software/guile/scripts“ wird betreten
make[2]: Für das Ziel „all“ ist nichts zu tun.
make[2]: Verzeichnis „/home/uliska/git/software/guile/scripts“ wird
verlassen
Making all in srfi
make[2]: Verzeichnis „/home/uliska/git/software/guile/srfi“ wird betreten
make  all-am
make[3]: Verzeichnis „/home/uliska/git/software/guile/srfi“ wird betreten
make[3]: Für das Ziel „all-am“ ist nichts zu tun.
make[3]: Verzeichnis „/home/uliska/git/software/guile/srfi“ wird verlassen
make[2]: Verzeichnis „/home/uliska/git/software/guile/srfi“ wird verlassen
Making all in doc
make[2]: Verzeichnis „/home/uliska/git/software/guile/doc“ wird betreten
Making all in ref
make[3]: Verzeic

Re: LilyPond in Debian

[Urs Liska]

Hi Knut,

thank you for the script.


Am 12.09.2017 um 09:34 schrieb Knut Petersen:
>
>> Hm, will I be able to get a system where I can build LilyPond again?
>
> Urs, building guile 1.8 is a pretty trivial and fast process. Just do
> it and don't care about debian

OK, I see how you build Guile directly into the LilyPond build
directory, and building Guile worked on first attempt.

I notice that upon each execution of the script Guile will be erased and
rebuilt from scratch. Am I right to assume that I could skip this step
for following builds?
And more, can't I build Guile once, into some other directory and rather
than rebuilding it each time place a symlink into the LilyPond
installation directory? This would be very useful as I tend to have
multiple builds in parallel.

>
>> I'm really not fluent enough with package management, but could I
>> install
>> Guile 1.8 from sid and use that for setting up my LilyPond environment?
>> I really don't want to use an extra virtual machine just for that.
>> (I don't need step-by-step instructions here, just a confirmation if it
>> is possible (and maybe a general pointer on how to proceed)
>
> Attached you'll find a script that builds guile and lilypond from
> local copies of their git repositories.
> Obviously you'll have to adapt some paths defined and and used in the
> script (LILYSOURCE, GUILESOURCE, LILYROOT) first.
>

I did so (and commented out make doc for now). First compilation failed
due to missing dblatex, but the second one failed with an error I didn't
really understand. Attached you'll find the tail of the build log - any
ideas what is wrong and what I can do?

Best
Urs

> Knut

echo /home/urs/git/lilypond/source/build/scripts/build/out/help2man
/home/urs/git/lilypond/source/build/scripts/build/out/help2man
/home/urs/git/lilypond/source/build/scripts/build/out/help2man out/abc2ly > 
out/abc2ly.1
cat /home/urs/git/lilypond/source/scripts/etf2ly.py | sed -e '#'  -e 
'/@relocate-preamble@/r 
/home/urs/git/lilypond/source/build/python/./out/relocate-preamble.py' -e 
's%@relocate-preamble@%%g' | sed -e '#'  -e 's!@BASH@!/bin/bash!g'  -e 
's!@BUILD_VERSION@!1!g'  -e 's!@DATE@!12SEP17!g'  -e 
's!@FONTFORGE@!/usr/bin/fontforge!g'  -e 
's!@GUILE@!/home/uliska/software/lilypond/builds/current/share/lilypond/bin/guile!g'
  -e 's!@MICRO_VERSION@!0!g'  -e 's!@MAJOR_VERSION@!2!g'  -e 
's!@MINOR_VERSION@!21!g'  -e 's!@NCSB_DIR@!!g'  -e 's!@PACKAGE@!LILYPOND!g'  -e 
's!@PATCH_LEVEL@!0!g'  -e 's!@PATHSEP@!:!g'  -e 's!@PERL@!/usr/bin/perl!g'  -e 
's!@PYTHON@!/usr/bin/python -tt!g'  -e 's!@SHELL@!/bin/sh!g'  -e 
's!@TARGET_PYTHON@!/usr/bin/python -tt!g'  -e 's!@TOPLEVEL_VERSION@!2.21.0!g'  
-e 's!@bindir@!/home/uliska/software/lilypond/builds/current/bin!g'  -e 
's!@datadir@!/home/uliska/software/lilypond/builds/current/share!g'  -e 
's!@date@!12SEP17!g'  -e 
's!@lilypond_datadir@!/home/uliska/software/lilypond/builds/current/share/lilypond/2.21.0!g'
  -e 
's!@lilypond_docdir@!/home/uliska/software/lilypond/builds/current/share/doc/lilypond!g'
  -e 
's!@lilypond_libdir@!/home/uliska/software/lilypond/builds/current/lib/lilypond/2.21.0!g'
  -e 
's!@local_lilypond_datadir@!/home/uliska/software/lilypond/builds/current/share/lilypond/2.21.0!g'
  -e 
's!@local_lilypond_libdir@!/home/uliska/software/lilypond/builds/current/lib/lilypond/2.21.0!g'
  -e 
's!@localedir@!/home/uliska/software/lilypond/builds/current/share/locale!g'  
-e 's!@outdir@!./out!g'  -e 's!@package@!lilypond!g'  -e 
's!@prefix@!/home/uliska/software/lilypond/builds/current!g'  -e 
's!@program_prefix@!!g'  -e 's!@program_suffix@!!g'  -e 
's!@sharedstatedir@!/home/uliska/software/lilypond/builds/current/com!g'  -e 
's!@src-dir@!/home/urs/git/lilypond/source/scripts!g'  -e 
's!@top-src-dir@!/home/urs/git/lilypond/source!g' > out/etf2ly
chmod 755 out/etf2ly
echo /home/urs/git/lilypond/source/build/scripts/build/out/help2man
/home/urs/git/lilypond/source/build/scripts/build/out/help2man
/home/urs/git/lilypond/source/build/scripts/build/out/help2man out/etf2ly > 
out/etf2ly.1
cat /home/urs/git/lilypond/source/scripts/midi2ly.py | sed -e '#'  -e 
'/@relocate-preamble@/r 
/home/urs/git/lilypond/source/build/python/./out/relocate-preamble.py' -e 
's%@relocate-preamble@%%g' | sed -e '#'  -e 's!@BASH@!/bin/bash!g'  -e 
's!@BUILD_VERSION@!1!g'  -e 's!@DATE@!12SEP17!g'  -e 
's!@FONTFORGE@!/usr/bin/fontforge!g'  -e 
's!@GUILE@!/home/uliska/software/lilypond/builds/current/share/lilypond/bin/guile!g'
  -e 's!@MICRO_VERSION@!0!g'  -e 's!@MAJOR_VERSION@!2!g'  -e 
's!@MINOR_VERSION@!21!g'  -e 's!@NCSB_DIR@!!g'  -e 's!@PACKAGE@!LILYPOND!g'  -e 
's!@PATCH_LEVEL@!0!g'  -e 's!@PATHSEP@!:!g'  -e 's!@PERL@!/usr/bin/perl!g'  -e 
's!@PYTHON@!/usr/bin/python -tt!g'  -e 's!@SHELL@!/bin/sh!g'  -e 
's!@TARGET_PYTHON@!/usr/bin/python -tt!g'  -e 's!@TOPLEVEL_VERSION@!2.21.0!g'  
-e 's!@bindir@!/home/uliska/software/lilypond/builds/current/bin!g'  -e 
's!@datadir@!/home/uliska/software/lilypond/builds/current/share!g'  -e 
's!@date@!12

Re: LilyPond in Debian

[Urs Liska]

Am 12.09.2017 um 14:09 schrieb Knut Petersen:
> Am 12.09.2017 um 11:38 schrieb Urs Liska:
>> Hi Knut,
>>
>> thank you for the script.
>>
>>
>> Am 12.09.2017 um 09:34 schrieb Knut Petersen:
>>>> Hm, will I be able to get a system where I can build LilyPond again?
>>> Urs, building guile 1.8 is a pretty trivial and fast process. Just do
>>> it and don't care about debian
>> OK, I see how you build Guile directly into the LilyPond build
>> directory, and building Guile worked on first attempt.
>
> Fine
>> I notice that upon each execution of the script Guile will be erased and
>> rebuilt from scratch. Am I right to assume that I could skip this step
>> for following builds?
> Yes
>> And more, can't I build Guile once, into some other directory and rather
>> than rebuilding it each time place a symlink into the LilyPond
>> installation directory? This would be very useful as I tend to have
>> multiple builds in parallel.
> Multiple builds of lilypond at the same time?

Yes, definitely. I often (at least in times when I'm actually working on
stuff in LilyPond) have multiple builds side-by-side. For example one
from current master and others from different open branches or even from
earlier releases. Actually Frescobaldi even has got explicit support for
this upon Janek's request.

>>> Attached you'll find a script that builds guile and lilypond from
>>> local copies of their git repositories.
>>> Obviously you'll have to adapt some paths defined and and used in the
>>> script (LILYSOURCE, GUILESOURCE, LILYROOT) first.
>>>
>> I did so (and commented out make doc for now). First compilation failed
>> due to missing dblatex, but the second one failed with an error I didn't
>> really understand. Attached you'll find the tail of the build log - any
>> ideas what is wrong and what I can do?
>
> After the failed build:
>
> cd  /home/urs/git/lilypond/source/build/scripts
>
> Does out/lilypond-invoke-editor exist? Is it executable?
Yes.
If that is relevant there is also an out/lilypond-invoke-editor.1 which
is not executable and has size 0.

>
> Does /home/urs/git/lilypond/source/build/scripts/build/out/help2man
> exist?

Yes, and it's executable as well.

>
> If out/lilypond-invoke-editor exists and is marked to be executable:
> What does  'sudo strace out/lilypond-invoke-editor --help 2>&1 | grep
> guile | grep openat' tell you?

Nothing.
The output without the last grep is attached.

>From what I can guess and see in the build directory there is no
directory share/lilypond/share/guile/site, only
share/lilypond/share/guile/1.8. But I can't really make anything from that.
Also share/lilypond/lib64 is not present, only share/lilypond/lib.
I have the impression later errors are when looking for Guile files in
the default places.

Does this help any further?
Urs

>
> Knut
>
>
open("/home/uliska/software/lilypond/builds/current/share/lilypond/lib/tls/x86_64/libguile.so.17",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/uliska/software/lilypond/builds/current/share/lilypond/lib/tls/libguile.so.17",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/uliska/software/lilypond/builds/current/share/lilypond/lib/x86_64/libguile.so.17",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/uliska/software/lilypond/builds/current/share/lilypond/lib/libguile.so.17",
 O_RDONLY|O_CLOEXEC) = 3
stat("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/site/init.scm",
 0x7ffd670b3320) = -1 ENOENT (No such file or directory)
stat("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/1.8/init.scm",
 0x7ffd670b3320) = -1 ENOENT (No such file or directory)
stat("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/init.scm",
 0x7ffd670b3320) = -1 ENOENT (No such file or directory)
stat("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/site/ice-9/boot-9.scm",
 0x7ffd670b3310) = -1 ENOENT (No such file or directory)
stat("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/1.8/ice-9/boot-9.scm",
 {st_mode=S_IFREG|0644, st_size=104124, ...}) = 0
open("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/1.8/ice-9/boot-9.scm",
 O_RDONLY) = 5
stat("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/site/ice-9/r4rs.scm",
 0x7ffd670b3270) = -1 ENOENT (No such file or directory)
stat("/home/uliska/software/lilypond/builds/current/share/lilypond/share/guile/1.8/ice-9/r4rs.scm",
 {st_mode=S_IF

Re: LilyPond in Debian

[Urs Liska]

Am 12.09.2017 um 18:39 schrieb Knut Petersen:
> Am 12.09.2017 um 16:46 schrieb Urs Liska:
>>
>>>> And more, can't I build Guile once, into some other directory and
>>>> rather
>>>> than rebuilding it each time place a symlink into the LilyPond
>>>> installation directory? This would be very useful as I tend to have
>>>> multiple builds in parallel.
>>> Multiple builds of lilypond at the same time?
>> Yes, definitely. I often (at least in times when I'm actually working on
>> stuff in LilyPond) have multiple builds side-by-side. For example one
>> from current master and others from different open branches or even from
>> earlier releases. Actually Frescobaldi even has got explicit support for
>> this upon Janek's request.
>
> Now I understand. Yes, obviously you might put guile anywhere you want
> and reuse it.
>> Nothing.
>> The output without the last grep is attached.
>
> I think deleting every of the two occurrences of the string "64" in
> the build script has a good chance to cure the problem.

Thank you, this actually worked.
Now finally again I have a self-compiled LilyPond 2.21.0 again, on a
system that doesn't normally have Guile 1.8 anymore :-)

Of course I'll have to iron out some things and make it generally usable
for my purposes (namely the flexibility to repeatedly compile different
LilyPond versions with as little effort as possible), but I'm confident
it'll work.

So far I had used a script provided by Janek that is very flexible and
polished. I'll check whether it will work to update *this* script to use
this self-compiled Guile.

Best
Urs

>
> Knut


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

Re: LilyPond in Debian

[Urs Liska]

Am 13.09.2017 um 10:33 schrieb Knut Petersen:
> Am 12.09.2017 um 23:28 schrieb Urs Liska:
>>> I think deleting every of the two occurrences of the string "64" in
>>> the build script has a good chance to cure the problem.
>> Thank you, this actually worked.
>
> Fine. I simply forgot that there are still a lot of 32 bit systems
> around.

This is not the root of the issue, since:

$ uname -r
4.9.0-3-amd64

So my system *is* 64bit, but still the directory names are expected to
be without "64".

Urs

>
> Attached a corrected version of the build script. Someone else might
> want it. It uses "uname -m" to distinguish between 32 and 64 bit systems
> and adjusts the number of threads to the number of available cores + 3.
>
> Knut

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

Re: LilyPond in Debian

[Urs Liska]

Am 13.09.2017 um 11:21 schrieb Knut Petersen:
>
>> This is not the root of the issue, since:
>>
>> $ uname -r
>> 4.9.0-3-amd64
>
> But what's the output of "uname*-m*"?

x86_64

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

Terminology of baseMoment, beats, groups

[Urs Liska]

Hi all,

I'm writing an assessment how the beaming-pattern code could be redone 
properly, which is pretty much necessary. Apart from some minor problems 
at the surface at least the concept of (subdivide the) beaming of 
tuplets it completely messed up. In fact, beam subdivision is simply 
unusable as soon as tuplets are involved. About two years ago I tried to 
work on this but didn't complete the task, and re-reading the code and 
recalling what I have probably tried back then I realize that I had 
continued in the tradition of adding patches on top of patches. Whenever 
I noticed unintended behaviour I tried to find the cause and fix that.


Instead I think it's necessary to rethink the topic from the ground up. 
I suggest to rewrite beaming-pattern.cc from scratch and check at each 
step which existing code can be reused. In order to be able to do that 
I'm right now figuring out the mechanics of beam subdivisions and 
everything else related to beaming-pattern in order to come up with a 
strategy that will allow an implementation that starts from the best 
possible reference points and avoids special treatment of special cases 
as much as possible. I'm sure I will have a number of questions about 
this (and this post will be the first).


I'm not sure if I will ever manage to do that coding work. If I'll do I 
will definitely need help because I will fail if I have to find all the 
pieces of information I need through "git grep" on my own. Ideally this 
should be team/pair work from the start.
However, if I won't work on it myself I want to at least have this 
documentation ready, hoping for someone else to pick this up. It's not 
one of the most important aspects of engraving, but definitely one where 
LilylPond currently actually isn't usable. Actually the trigger for 
thinking about this was that I noticed that Dorico has one identical bug 
to LilyPond. When I reported that to Daniel Spreadbury I got the feeling 
that it would be really great if we would fix that before Dorico ;-) But 
while fixing this specific issue would probably be a breeze (as the 
wrong behaviour is introduced on purpose due to a misunderstanding) I 
think it really should be done properly this time.


So, now the first question ...

The terminology of baseMoment, beats and groups is inconsistent between 
the NR 
(http://lilypond.org/doc/v2.19/Documentation/notation/beams#setting-automatic-beam-behavior) 
and the code. The question is, what are the components of the following:


  \set baseMoment = #(ly:make-moment 1/8)
  \set beatStructure = 3,3,2

From the text in the NR this would be three beats, divided in three or 
two base moments each.
However, the C++ code (and the code comments) refer(s) to that as three 
groups with three beats each.


If my conclusion is correct I suggest to change the naming in the code 
because that reflects musical reality more naturally, IMHO.


In a way this is a superficial question, but I need to fully understand 
both the underlying concepts and the existing code:


- what is sloppy (may be the case here)
- what is conceptually wrong in the code
- what is correct and I just haven't understood yet

Best
Urs


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

Re: Terminology of baseMoment, beats, groups

[Urs Liska]

Am 11.11.2017 um 11:42 schrieb David Kastrup:

Urs Liska  writes:


So, now the first question ...

The terminology of baseMoment, beats and groups is inconsistent
between the NR
(http://lilypond.org/doc/v2.19/Documentation/notation/beams#setting-automatic-beam-behavior)
and the code. The question is, what are the components of the
following:

   \set baseMoment = #(ly:make-moment 1/8)
   \set beatStructure = 3,3,2

 From the text in the NR this would be three beats, divided in three or
two base moments each.
However, the C++ code (and the code comments) refer(s) to that as
three groups with three beats each.

Can you please come up with actual quotes/evidence for those statements?
Neither of those make much sense, so I'd guess you'd been
over-paraphrasing either.  Or alternatively, there are grave errors in
the respective description which warrant fixing rather than unifying
first.



a) from the NR section linked
"beatStructure is a scheme list that defines the length of each beat in 
the measure in units of baseMoment. "


I read this as: In the given example beatStructure is a list that 
defines the measure to consist of three beats. Beat one and two have the 
length of three baseMoments of 1/8, beat three is two baseMoments of 1/8 
long.


Actually this is consistent with how I would describe that measure in 
prose: we have an 8/8 measure with three beats, with lengths 3, 3, and 2 
quavers.



b) from beaming-pattern.cc

1) line 206ff., comment to find_location()
/*
   Get the group start position, the next group starting position, and the
   next beat starting position, given start_moment, base_moment,
   grouping, and factor
*/

2) line 265, comment right after find_location has been called:
// Mark the importance of stems that start at a beat or a beat group.

From the actual behaviour of the code (and other comments throughout 
the code) it is clear that "beat" refers to a baseMoment unit and 
"group" refers to the entity the NR calls "beat".
The context property "beatStructure" obviously corresponds to the C++ 
variable "grouping".


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

Re: Terminology of baseMoment, beats, groups

[Urs Liska]

Am 11.11.2017 um 12:30 schrieb David Kastrup:

I find "grouping" without "beat" fine.  I could have been responsible
for the terminology in the code (pretty sure I wasn't, but it matches
the terminology I use quite better).

Now I have certainly not gotten an English music education, so can
someone who did chime in?


I haven't either, but I can refer to Gould's terminology. While we all 
agree that no single engraving book provides "the truth", it is surely a 
good idea to match her terminology, if only to be able to communicate 
with users/developers of other programs.


She says: "Divisions of a beat are beamed together in all metres." and 
states 2/4, 6/8, and 2/2 as metres of 2 beats. (p. 153, "Beaming 
according to the metre")

3/2, and 9/16 are given as examples of metres of 3 beats.

So it's clear that her terminology matches that of beatStructure, "beat" 
= "beat" and "baseMoment" = "Division of a beat".


The example I gave is also present in her examples (p. 155), other 
examples of metres with beats of different lengths include 5/16 (2+3 or 
3+2) and 7/8.


So I think we can safely say the terminology of beatStructure is correct 
(or at least acceptable).


"Beat" also refers to what a conductor would do. the 3+3+2 from my 
example would be given as three "beats" by the conductor. Maybe your 
perception of "beat" as necessarily regular comes from the fact that in 
German we use "beat" too, but usually referring to specific styles that 
are limited to regular beats ...


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

Re: Terminology of baseMoment, beats, groups

[Urs Liska]

Am 11.11.2017 um 12:52 schrieb Urs Liska:
"Beat" also refers to what a conductor would do. the 3+3+2 from my 
example would be given as three "beats" by the conductor. Maybe your 
perception of "beat" as necessarily regular comes from the fact that 
in German we use "beat" too, but usually referring to specific styles 
that are limited to regular beats ...


Ah yes, and in contemporary music, where heavily irregular metres like 
3/8 + 2/16 + 3/16 + 4/8 + 1/12 are common we'd also always refer to that 
as a measure with 5 beats of different length.


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

Re: Terminology of baseMoment, beats, groups

[Urs Liska]

Am 11.11.2017 um 13:15 schrieb David Kastrup:

Urs Liska  writes:


Am 11.11.2017 um 12:30 schrieb David Kastrup:

I find "grouping" without "beat" fine.  I could have been responsible
for the terminology in the code (pretty sure I wasn't, but it matches
the terminology I use quite better).

Now I have certainly not gotten an English music education, so can
someone who did chime in?

I haven't either, but I can refer to Gould's terminology. While we all
agree that no single engraving book provides "the truth", it is surely
a good idea to match her terminology, if only to be able to
communicate with users/developers of other programs.

She says: "Divisions of a beat are beamed together in all metres." and
states 2/4, 6/8, and 2/2 as metres of 2 beats. (p. 153, "Beaming
according to the metre")

I'd be interested in her take on the terminology for uneven
subdivisions, like the 3+3+2 used these days in tango.


Unfortunately she doesn't explicitly uses *words* for this kind of 
metres ...





3/2, and 9/16 are given as examples of metres of 3 beats.

So it's clear that her terminology matches that of beatStructure,
"beat" = "beat" and "baseMoment" = "Division of a beat".

The example I gave is also present in her examples (p. 155), other
examples of metres with beats of different lengths include 5/16 (2+3
or 3+2) and 7/8.

Ah, ok.


... but this can implicitly be taken as a confirmation that she also 
considers irregular groupings as "beats".





So I think we can safely say the terminology of beatStructure is
correct (or at least acceptable).

"Beat" also refers to what a conductor would do. the 3+3+2 from my
example would be given as three "beats" by the conductor. Maybe your
perception of "beat" as necessarily regular comes from the fact that
in German we use "beat" too, but usually referring to specific styles
that are limited to regular beats ...

I actually perform quite a bit in 4/4 with a basic rhythm of { 4. 4. 4
}, but I've never heard anybody refer to the last quarter as the "third
beat" when directing musicians where to start.


Of course I don't really know what kind of music you are referring to, 
but I have the impression that you mean 2/2 music that is actually in 
two beats, and the grouping is not a metric, but a rhythmic issue.


If you have music like the examples given in 
http://lilypond.org/doc/v2.19/Documentation/notation/beams#index-measure-groupings 
I can tell you that orchestra musicians and conductors would refer to 
that as beats. E.g. "The a' on the fourth beat of the second 9/8 measure".


Here comes another inconsistency, now within one NR page. This section 
states that the measure_grouping_engraver creates signs for groups that 
are created from beatStructure, i.e. from the "beats" in the 
beatStructure ...


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

Re: Terminology of baseMoment, beats, groups

[Urs Liska]

Am 11.11.2017 um 13:25 schrieb Simon Albrecht:

On 11.11.2017 12:30, David Kastrup wrote:

I have a hard time seeing a "beat" as something that can have different
lengths.


Musical notation isn’t well-defined in a mathematical or programming 
sense, so there are no such strict rules as all beats of a measure 
having to be the same length.
If nobody would refer to the last quarter note of 3+3+2/8 as “the 
third beat” then that’s because it would tend to be confusing.


I disagree. There are two different musical situations where this can 
occur: 3+3+2 is a pretty common idiom of a three-part *rhythm* against a 
2-part *metre*, and here it would in fact be confusing to refer to the 
"2" as the third beat.
Other music may well treat this as beats in their own right, and then 
everybody would talk about it as three "beats".


It is probably clearer when shown with a less idiomatic example. 
Consider a 9/8 time signature with a 2,2,2,3 beatStructure. Here it is 
clear that you'd refer to the groups as four "beats".


Urs



Best, Simon



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

Re: Terminology of baseMoment, beats, groups

[Urs Liska]

Am 11.11.2017 um 21:23 schrieb David Kastrup:

Urs Liska  writes:


Am 11.11.2017 um 15:30 schrieb Carl Sorensen:

When I look at http://openmusictheory.com/meter.html , the thing that we
call a beat in the c++ code is what openmusictheory calls a pulse.  And
what we call a beat group is what they call a beat.  In this context,
baseMoment is the length of a pulse.  And beatStructure defines the
lengths of each beat in the measure in pulses.  It would be a
straightforward first step to replace "beat" with "pulse", and "beat
group" with "beat" in both the c++ and scm code.

While I've never heard that term in this context I agree that pulse
and beat are good names for the things in question, and I suggest to
rename them in the code (while it shouldn't change anything in the
user-facing syntax). However, I wouldn't actually do that as an
independent patch but in the context of a more general reworking.

We don't really want code documentation and user documentation
divergent.

That being said, I find "pulse" distinctly awkward, but my vote against
it (as common terminology for both programmers and users) is to be
considered a user vote, not a maintainer veto.



Just for the record: I wouldn't object to keeping baseMoment, simply 
because it's a quite technical term that doesn't imply too much of a 
musical meaning.


Urs


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

Re: Terminology of baseMoment, beats, groups

[Urs Liska]

Am 11.11.2017 um 15:07 schrieb Hans Åberg:



On 11 Nov 2017, at 12:52, Urs Liska  wrote:



Am 11.11.2017 um 12:30 schrieb David Kastrup:

I find "grouping" without "beat" fine.  I could have been responsible
for the terminology in the code (pretty sure I wasn't, but it matches
the terminology I use quite better).

Now I have certainly not gotten an English music education, so can
someone who did chime in?

I haven't either, but I can refer to Gould's terminology. While we all agree that no 
single engraving book provides "the truth", it is surely a good idea to match 
her terminology, if only to be able to communicate with users/developers of other 
programs.

She says: "Divisions of a beat are beamed together in all metres." and states 2/4, 6/8, 
and 2/2 as metres of 2 beats. (p. 153, "Beaming according to the metre")
3/2, and 9/16 are given as examples of metres of 3 beats.

So it's clear that her terminology matches that of beatStructure, "beat" = "beat" and 
"baseMoment" = "Division of a beat".

The example I gave is also present in her examples (p. 155), other examples of 
metres with beats of different lengths include 5/16 (2+3 or 3+2) and 7/8.

So I think we can safely say the terminology of beatStructure is correct (or at 
least acceptable).

"Beat" also refers to what a conductor would do. the 3+3+2 from my example would be given as three 
"beats" by the conductor. Maybe your perception of "beat" as necessarily regular comes from the 
fact that in German we use "beat" too, but usually referring to specific styles that are limited to regular 
beats ...

"Beat" is synonymous with metric accent, but in practise, one also has metric 
subaccents. The notation indicates at which times the accents should occur, but not the 
actual length, and does not fully indicate their relative strength: In 4/4, one knows 
that first beat should be strongest, but there are two common different interpretations 
for the others (see below).


As I wrote elsewhere 3+3+2 is maybe a special case because it's often 
used as a *rhythm* /as *accents* against a 4+4 or 2+2+2+2 metre.




It seemed easiest to me to define a formal (sub-)beat or metric (sub)-accent 
structure, which has a 1-1 correspondence with the beaming. Then the actual 
beaming used consists of a choice of such formal beat structures for different 
note patterns.


If you are referring to the baseMoment/beatStructure concept I think 
this is appropriate both technically and musically. What I initiall 
referred to is that the C++ code uses *different* terms for the entities.




So the 4 above could have the other beats about the same in strength, or alternatively, a 
2+2 pattern. There is also "in one" accent structure, whereby only the first 
beat is accented-whther to call the other unaccented time positions I leave up to you. 
This is normally not typeset, but one can choose it in Finale, I am told.

LilyPond fails in the subbeat structures: For example the common meter, 9/16, 9 
= (2+2)+(2+3), like in the Daichovo, is now typeset as 4+2+3, with a break in 
the beaming between the 2 and 3. It would be nice to be able having them beamed 
together at the top level, but broken on the second one.


I'm not sure I understand what you mean. A simple \time 9/16 will beam 
3+3+3, but when you set the beat structure to 2,2,2,3 it will do that.


Or are you talking about subdivisions, with a first beam over the whole 
measure and secondary beams grouped 2,2,2,3? If so, this would be 
possible with the changes I have in mind.



As for the tuplets, one needs to have them in a group for the subbeaming to 
come out right. The default is the above in one pattern, except for certain 
multiples of 2 and 3—Hindemith describes those. So there is a problem in 
LilyPond relative the beaming if one is allowed to just write tuplet values 
instead of a full tuplet group.


Actually I don't really understand what you mean here. But LilyPond's 
handling of tuplets (at least with regard to beam subdivisions, but 
maybe also for automatic beaming in general) is substantially broken anyway.


Urs

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

Re: New Status "Shelved" in LilyPond Bug Tracker

[Urs Liska]

Am 11. Dezember 2017 17:50:01 MEZ schrieb Trevor :
>
>Devs and Bug Trackers
>
>I have implemented a new Status field in the Issues Tracker at 
>SourceForge: Status:Shelved, with the meaning:
>
>"Probably desirable, but impractical to implement at present due to
>lack 
>of resources".
>
>There is also a new Search: Open (Shelved) to list them.
>

Thank you. I think this is a good idea.

I will create such an issue and upload my assessment when I'll be through wirh 
my beam subdivision investigation. (I was forced to take a break from this 
recently).

Urs

>ATM only one Issue has this Status, 
>https://sourceforge.net/p/testlilyissues/issues/5244/ but there are
>lots 
>of other existing issues that could be assigned to it, when someone has
>
>a few spare moments to go through the Issues to find them.
>
>Trevor
>
>
>
>---
>This email has been checked for viruses by AVG.
>http://www.avg.com
>
>
>___
>lilypond-devel mailing list
>lilypond-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Re: Issue #5246: Make empty scores abort engraving process (issue 332470043 by beauleetien...@gmail.com)

[Urs Liska]

Am 22. Dezember 2017 15:42:39 MEZ schrieb David Kastrup :
>Dan Eble  writes:
>
>> On Dec 21, 2017, at 23:06, beauleetien...@gmail.com wrote:
>>> 
>>> @@ -110,8 +110,7 @@ LY_DEFINE (ly_interpret_music_expression,
>"ly:interpret-music-expression",
>>> 
>>>   if (!iter->ok ())
>>> {
>>> -  warning (_ ("no music found in score"));
>>> -  /* todo: should throw exception. */
>>> +  error (_ ("no music found in score"));
>>>   return SCM_BOOL_F;
>>> }
>>
>> Looking at this in isolation, I wonder whether “no music found” is
>the
>> only reason that iter might not be OK; in other words, was the
>message
>> appropriate before you arrived?
>
>\new Voice { }
>
>_is_ arguably music.  The other error message before is actually just
>nonsensical since LY_ASSERT_SMOB already catches the respective
>condition.  I think we should just let this one complete properly (and
>thus also get an image/PDF) though with a warning.
>
>I actually thought I did change this at one time.  At any rate, a
>_fatal_ error at least seems silly.  There is no reason not to continue
>here.

Yes, there may be valid reasons to compile files with no music in them.

Urs

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

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Hi Trevor,

Could you please post the *full* log and the input file?
Then I can look into it. I recall having seen this error beforebut not what it 
was about.

Urs

Am 26. Dezember 2017 13:08:49 MEZ schrieb Jan-Peter Voigt :
>Hi Trevor,
>
>I am working on Linux and have no Windows 10 running. I will try on
>Win7 
>later. IIRC there was a problem with oll-core on Windows 10, but maybe 
>someone else can tell?
>The error message indicates a problem before EE is loaded.
>If oll-core is loaded successfully EE *should* work.
>
>Jan-Peter
>
>
>Am 26.12.2017 um 09:41 schrieb Trevor:
>> Hi EE-Users
>> 
>> I thought I'd try to bring the edition engraver into use over the 
>> holiday period, so I cloned edition-engraver and oll-core from
>git-hub 
>> into a local repository, placed that in Frescobaldi's include path
>and 
>> tried to compile the first example in edition-engraver.  It fails
>with 
>> the message:
>> 
>> C:/Users/tdani/openlilylib/oll-core/package.ily:57:2 <0>: error:
>GUILE 
>> signaled an error for the expression beginning here
>> 
>> #
>> 
>> (if (not (defined? 'openlilylib-root))
>> 
>> 
>>
>C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:35:1
>
>> <1>: error: unknown escaped string: `\loadPackage'
>> 
>> 
>> \loadPackage edition-engraver
>> 
>> Before I spend time investigating this further, I'm wondering if the 
>> edition-engraver is known to work within Frescobaldi on Windows 10
>with 
>> LilyPond 2.19.80.  Are there any such users?
>> 
>> Alternatively, any ideas what I might be doing wrong?
>> 
>> Trevor
>> 
>> -- Original Message --
>> From: "Jan-Peter Voigt" mailto:jp.vo...@gmx.de>>
>> To: lilypond-u...@gnu.org ; "Mason
>Hock" 
>> mailto:masonh...@gmail.com>>
>> Sent: 24/12/2017 10:19:48
>> Subject: Re: edition-editor usage
>> 
>>> Hello Mason,
>>>
>>> it is possible to use \shapeII with the edition-engraver :-)
>>> And it sounds like this is the use case the EE is originally meant
>for.
>>>
>>> Yes, the wording is a bit inconsistent and/or irritating. I will try
>
>>> to sum it up:
>>> In the recent versions I used the terms target and context to divide
>
>>> two dimensions. The target names the requested output like for
>example 
>>> 'fullscore' or 'violinI-part'. If you "activate" an edition-target 
>>> with \addEdition violinI-part it uses all modifications that look
>like
>>> \editionMod violinI-part{ 
>>> \shapeII ... }
>>>
>>> This is a real example I used inside the piano reduction:
>>> \editionMod klavier 38 0/8 chor.ten.TenorStaff \once \shapeII
>#'(()(0 
>>> . 1)()()) Slur
>>> It means:
>>> with edition-target 'klavier' (the piano reduction) in measure 38
>the 
>>> first eighth apply the shapeII-command inside the context identified
>
>>> by 'chor.ten.TenorStaff'.
>>> Moments are counted zero-based, so the first moment is zero. This 
>>> might irritating on first sight, but it is meaningful as the
>distance 
>>> from the beginning of the measure. The context in the example above
>is 
>>> the tenor staff inside the choir-staff.
>>>
>>> I think the main point is understanding the three dimensions:
>>> 1. the edition-target - that is the condition if to apply the 
>>> modification ... apply this modification for the score of type
>T(arget)
>>> 2. the edition-context - that is where to apply the modification ...
>
>>> the LilyPond context like Voice, Staff, Score etc.
>>> 3. the time - that is the musical timestamp when to apply the 
>>> modification ... moment X inside measure Y
>>>
>>> HTH
>>>
>>> I will send more details and information soon!
>>> But for today and tomorrow I wish you a merry Christmas and all the 
>>> best for 2018!
>>>
>>> Jan-Peter
>>>
>>>
>>> Am 23. Dezember 2017 20:09:29 MEZ schrieb Mason Hock 
>>> :
>>>
>>> I have a piece in which each performer reads from a version of
>the score
>>> with their staff full-sized with the other parts on small
>staves. This
>>> pieces also requires a lot of manual tweaking of slurs.
>>>
>>> I've been using \shapeII for the slurs, which works great,
>except that
>>> if I shape the slur correctly for the full-sized version of the
>part it
>>> is shaped incorrectly for the small version of the part and vice
>versa.
>>> In order for the slurs to look good in both situations I need
>two sets
>>> of \shapeII tweaks.
>>>
>>> edition-editor looks like a promising solution, but I'm having
>trouble
>>> learning how to use it. The only documentation I can find is the
>usage
>>> examples here.
>>>
>>>
>https://github.com/openlilylib/edition-engraver/tree/master/usage-examples
>>>
>>> Each example is very specific, which makes it difficult to
>decode how
>>> edition-engraver works in general. I guess my questions are
>>>
>>> (1) Will edition-engraver work for tweaking slurs with \shapeII?
>>>
>>> (2) If so, what should be my approach in terms of organization?
>My guess
>>> would be to have 8 editions

Re: Re[2]: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 26. Dezember 2017 20:17:33 MEZ schrieb Trevor :
>
>Hi Urs
>
>>Could you please post the *full* log and the input file?
>>Then I can look into it. I recall having seen this error before but
>not 
>>what it was about.
>Thanks for looking!  Source and log attached.  The source is 
>example-1.ly from edition-engraver/usage-examples.
>
>Trevor

OK, but I'm not at home right now, so it is somewhat hard to digest. Could you 
please send the log for a document that contains only 
  \include "oll-core/package.ily"
?

Urs

>
>>

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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 26.12.2017 um 23:15 schrieb Trevor:


Hi Urs

OK, but I'm not at home right now, so it is somewhat hard to digest. 
Could you please send the log for a document that contains only

 \include "oll-core/package.ily"
?


Sure; it's quite bit shorter, so here it is inline:

Starting lilypond-windows.exe 2.19.80 [Untitled]...
Processing 
`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly'

Parsing...
C:/Users/tdani/openlilylib/oll-core/package.ily:57:2: error: GUILE 
signaled an error for the expression beginning here

#
 (if (not (defined? 'openlilylib-root))

Value out of range 0 to 4294967295: -1
fatal error: failed files: 
"C:\\Users\\tdani\\AppData\\Local\\Temp\\frescobaldi-u9vnw1qc\\tmp4_jxjpvb\\document.ly"

Exited with return code 1.

Trevor


OK, at least now I know where (in the code) the problem is and recall 
that I fixed that once. Just to be sure: are you sure you you use the 
latest state of oll-core? OTOH, from the type of issue it may well be a 
Windows question.


I can't look into it right now (and don't know if I can for the next few 
days).


For debugging could you please locate the file 
oll-core/internal/os-path.ily and insert a ly:message after line 193 so 
that the "this-parent" function looks like this:


% Return the parent of (this-dir)
#(define-public (this-parent)
   (let ((file (this-file)))
 (ly:message "this file: ~a" file)
 (list-head file (- (length file) 2

The problem is in the list-head command. The thing is that "file" seems 
to be a list of length 1 (instead of anything above 2), which leads to 
the value-out-of-range error.


Additionally insert a message in line 184 so "this-file" looks like

% Return the normalized absolute path and file name of "this" file
#(define-public (this-file)
   (ly:message "location: ~a" (*location*))
   (ly:message "initial path: ~a" (car (ly:input-file-line-char-column 
(*location*

   (location->normalized-path (*location*)))

And send me the log output.

Best
Urs

PS: One thing Jan-Peter has assumed correctly: The problem is in 
oll-core, before edition-engraver is even loaded.


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

Re: Re[2]: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 27. Dezember 2017 13:27:09 MEZ schrieb Trevor :
>Hi Urs
>
>>
>>OK, at least now I know where (in the code) the problem is and recall 
>>that I fixed that once. Just to be sure: are you sure you you use the 
>>latest state of oll-core? OTOH, from the type of issue it may well be
>a 
>>Windows question.
>>
>>I can't look into it right now (and don't know if I can for the next 
>>few days).
>There's no particular urgency to this - I appreciate your time whenever
>
>you can spare it.
>
>>For debugging could you please locate the file 
>>oll-core/internal/os-path.ily and insert a ly:message after line 193
>so 
>>that the "this-parent" function looks like this:
>>
>>% Return the parent of (this-dir)
>>#(define-public (this-parent)
>>(let ((file (this-file)))
>>  (ly:message "this file: ~a" file)
>>  (list-head file (- (length file) 2
>>
>>The problem is in the list-head command. The thing is that "file"
>seems 
>>to be a list of length 1 (instead of anything above 2), which leads to
>
>>the value-out-of-range error.
>>
>>Additionally insert a message in line 184 so "this-file" looks like
>>
>>% Return the normalized absolute path and file name of "this" file
>>#(define-public (this-file)
>>(ly:message "location: ~a" (*location*))
>>(ly:message "initial path: ~a" (car
>(ly:input-file-line-char-column 
>>(*location*
>>(location->normalized-path (*location*)))
>>
>>And send me the log output.
>Done; here's the log output:
>
>Starting lilypond-windows.exe 2.19.80 [Untitled]...
>Processing 
>`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly'
>Parsing...
>location: #C:/Users/tdani/openlilylib/oll-core/package.ily:57:2>
>initial path: C:/Users/tdani/openlilylib/oll-core/package.ily
>this file: (C:/Users/tdani/openlilylib/oll-core/package.ily)

OK, here we are. This should be a list with the path elements, but it has the 
whole path in *one* list element. And throws an error when trying to access the 
second-to-last element. 

With this information I can debug the function. 

Best
Urs

>C:/Users/tdani/openlilylib/oll-core/package.ily:57:2: error: GUILE 
>signaled an error for the expression beginning here
>#
>  (if (not (defined? 'openlilylib-root))
>
>Value out of range 0 to 4294967295: -1
>fatal error: failed files: 
>"C:\\Users\\tdani\\AppData\\Local\\Temp\\frescobaldi-u9vnw1qc\\tmp4_jxjpvb\\document.ly"
>Exited with return code 1.
>
>
>Trevor

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

Re: Web: Update GSoC pages (issue 338320043 by g...@ursliska.de)

[Urs Liska]

Am 02.01.2018 um 12:34 schrieb lemzw...@googlemail.com:

BTW, I plan to still mentor the two projects that I was already

assigned to.



Great!
That was the idea behind moving forward in that drastic manner ;-)


Aah, with `attic' you mean moving down the page, right?  Then please
unearth my two projects, i.e., move them up again :-)



Actually that would be moving down the *file*, on the website they'd end 
up on a totally different page:

http://lilypond.org/attic.html#Inactive-Google-Summer-of-Code-project-suggestions

I'll move your projects back (after asking Abraham) and upload a new patch.

Urs

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

Re: Web: Update GSoC pages (issue 338320043 by g...@ursliska.de)

[Urs Liska]

Am 02.01.2018 um 17:23 schrieb pkx1...@gmail.com:


https://codereview.appspot.com/338320043/diff/40001/Documentation/included/gsoc.itexi 


File Documentation/included/gsoc.itexi (right):

https://codereview.appspot.com/338320043/diff/40001/Documentation/included/gsoc.itexi#newcode192 


Documentation/included/gsoc.itexi:192: \emph{variants} (alternative
readings, corrections, regularizations),
should be @emph

I believe this is what is breaking 'make'


It may or may not be the only thing but it is definitely an error that I 
have fixed with a new patch set.


Sorry for the hassle, the problem is that I currently don't have a 
working build environment, and I can't find the time to work on one 
"only" for website work.


Urs

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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Hi Trevor


Am 27.12.2017 um 14:33 schrieb Urs Liska:

Done; here's the log output:

Starting lilypond-windows.exe 2.19.80 [Untitled]...
Processing
`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly'
Parsing...
location: #
initial path: C:/Users/tdani/openlilylib/oll-core/package.ily
this file: (C:/Users/tdani/openlilylib/oll-core/package.ily)

OK, here we are. This should be a list with the path elements, but it has the 
whole path in*one*  list element. And throws an error when trying to access the 
second-to-last element.

With this information I can debug the function.


I've now had the chance to look into this issue, and it's clear what 
happens. I could easily fix that *for you*, but I'm not sure about the 
*proper* fix.


The path handling functions in oll-core work in an OS dependent way and 
define an OS path separator of "\" (Windows) or "/" (otherwise). But in 
your log "/" is used on Windows as well.


I know that by now Windows can handle both forward and backward slashed.

But it would be important for me to know if I can rely on (*location*) 
returning forward slashes in all Windows versions.


Could people on different Windows versions please compile the following 
file and tell me about the output?


\version "2.19.80"

loc =
#(define-void-function ()()
   (display (*location*)))

\loc

Thanks
Urs


Best
Urs



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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 08.01.2018 um 14:50 schrieb David Kastrup:

Urs Liska  writes:


Hi Trevor


Am 27.12.2017 um 14:33 schrieb Urs Liska:

Done; here's the log output:

Starting lilypond-windows.exe 2.19.80 [Untitled]...
Processing
`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly'
Parsing...
location: #
initial path: C:/Users/tdani/openlilylib/oll-core/package.ily
this file: (C:/Users/tdani/openlilylib/oll-core/package.ily)

OK, here we are. This should be a list with the path elements, but
it has the whole path in*one* list element. And throws an error when
trying to access the second-to-last element.

With this information I can debug the function.

I've now had the chance to look into this issue, and it's clear what
happens. I could easily fix that *for you*, but I'm not sure about the
*proper* fix.

The path handling functions in oll-core work in an OS dependent way
and define an OS path separator of "\" (Windows) or "/"
(otherwise). But in your log "/" is used on Windows as well.

I know that by now Windows can handle both forward and backward
slashed.

That's news to me.  Aren't you confusing this with the C library
commonly used on Windows?  And with particular shells?

And particular runtimes?  Like Cygwin/MinGW ?


Probably we're talking about different things. What I mean is that you 
can type both of these into a standard cmd.exe on Windows (7):


  cd c:\Windows
  cd c:/Windows

But actually that's not what's interesting to me. My question is what to 
expect on different systems when parsing the output of (*location*).


Best
Urs



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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 08.01.2018 um 14:49 schrieb Karlin High:

On 1/8/2018 7:16 AM, Urs Liska wrote:


Could people on different Windows versions please compile the 
following file and tell me about the output?


Windows 7 64-bit SP1:

C:\Users\karlin\Music\LilyPond>lilypond ursliska-pathtest.ly
GNU LilyPond 2.19.80
Processing `ursliska-pathtest.ly'
Parsing...#
Success: compilation successfully completed

C:\Users\karlin\Music\LilyPond>

Would you also like the verbose output? (From lilypond -V)


No, but from invoking the file with an absolute path (i.e. one with 
slashes in it).


Could you please check if
a) you can specify the path to the ly file with both forward and 
backward slashes

b) this makes a difference in the output
?

Thanks
Urs


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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 08.01.2018 um 15:46 schrieb Karlin High:

On 1/8/2018 8:25 AM, Urs Liska wrote:


Could you please check if
a) you can specify the path to the ly file with both forward and 
backward slashes

b) this makes a difference in the output


Windows 7 Pro 64-bit SP1

C:\Users\karlin\Music\LilyPond>lilypond 
C:\Users\karlin\Music\LilyPond\ursliska-pathtest.ly

GNU LilyPond 2.19.80
Processing `C:/Users/karlin/Music/LilyPond/ursliska-pathtest.ly'
Parsing...#C:/Users/karlin/Music/LilyPond/ursliska-pathtest.ly:7:1>

Success: compilation successfully completed

C:\Users\karlin\Music\LilyPond>lilypond 
C:/Users/karlin/Music/LilyPond/ursliska-pathtest.ly

GNU LilyPond 2.19.80
Processing `C:/Users/karlin/Music/LilyPond/ursliska-pathtest.ly'
Parsing...#C:/Users/karlin/Music/LilyPond/ursliska-pathtest.ly:7:1>

Success: compilation successfully completed


Thank you. Together with Trevor's initial report (from Win 10) this 
indicates that LilyPond always uses forward slashes internally. Of 
course that makes things easier for me (although it would be even 
simpler if I could just leave the code as it is ;-) )


I think I won't wait for feedback from users of Win 8, Vista or XP but 
simply fix it according to the current knowledge.




I am with David Kastrup on this one - I had no idea Windows learned to 
understand both back and forward slashes in file paths. But it seems 
to work; I can "cd" anywhere I want with either. Even with a mixture 
of the two! However, pressing the TAB key for auto-complete seems to 
only work properly with Windows-native backslashes.


This looks somewhat consistent to me with the fact that Windows paths 
ignore case.


Best
Urs


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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 08.01.2018 um 15:50 schrieb Urs Liska:
I think I won't wait for feedback from users of Win 8, Vista or XP but 
simply fix it according to the current knowledge.


I have now made some changes and pushed the to the "windows" branch of 
oll-core. I'm not 100% convinced this is really "it" because the cases 
where os dependent path separators are used are somewhat interspersed 
throughout.


It would be great if some Windows users with Git access could fetch that 
branch and check it out. Interesting would for example be the file 
util/usage/include-pattern.ly.


With no further objections I'll eventually merge the branch.

Best
Urs

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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 08.01.2018 um 17:30 schrieb Karlin High:

On 1/8/2018 10:11 AM, Urs Liska wrote:


It would be great if some Windows users with Git access could fetch 
that branch and check it out.


Which Git has this? GitHub? Savannah? Somewhere else?


https://github.com/openlilylib/oll-core

There are a number of other packages to look at too ;-)


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

Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 08.01.2018 um 18:11 schrieb Karlin High:

Urs, was there supposed to be a "Windows" branch?


Oops, obviously I only pushed the master branch again.
Now the windows branch is on Github, sorry.

Urs

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

Fwd: FSF spring internship applicant looking for a GNU project

[Urs Liska]

Is this something we would care about?


 Ursprüngliche Nachricht 
Von: Andrew Engelbrecht 
Gesendet: 26. Januar 2018 21:31:02 MEZ
An: summer-of-c...@gnu.org
Betreff: FSF spring internship applicant looking for a GNU project

Hello GNU maintainers,

The FSF tech team would like to offer Darshan Kadu, an FSF internship
applicant, an internship this spring. He has experience with the C
programming language and wrote patches for Blender via GSoC in 2017. He
would like to contribute to a GNU project in the February to April
session. I've attached his resume to this email.

Darshan is available to work about 30-40 hours per week, mostly on
weekends, as he is currently a student.

Is your GNU project interested in mentoring Darshan this spring? If so,
please email us via this list or  some time in the
next week.

Thank you, :)
Andrew

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

Re: GSoC 2018 Interest and Information Request

[Urs Liska]

Am 18. Februar 2018 20:46:37 MEZ schrieb Ed Harbison :
>Hey Kieren!  Thank you!
>
>Your background is very impressive.  I’m glad to be talking to someone
>as talented as you are.
>
>This project seems perfect to me to be honest.  As I said, I was trying
>to implement some of my own, so this is exactly what I want to work on.
>
>Can you possibly send me links to the samples you have listed?  I just
>want to make sure I look at the right things so I can know what’s in
>your mind.

what you should look at too (from the implementation side of things) is

https://github.com/openlilylib/oll-core and
https://github.com/openlilylib/notation-fonts

Best
Urs

>
>Thank you again!
>
>Sincerely,
>Ed Harbison
>
>> On Feb 17, 2018, at 3:32 PM, Kieren MacMillan
> wrote:
>> 
>> Hi Ed,
>> 
>> Thanks for contacting us! I am the Community Mentor for the
>"Stylesheets" GSoC project, so I'm probably the best person to tackle
>your query at this point.
>> 
>>> To introduce myself, my name is Edward Harbison.  I am about
>two-thirds through my third year of undergraduate studies at Moravian
>College in Bethlehem, PA, USA, where I am a dual-major in chemistry and
>computer science with minors in mathematics and music theory.  This
>past summer, I participated in a research project on campus involving
>LilyPond (which will be public soon).  I have knowledge of Python,
>Java, C, C++, Scheme, and MusicXML.  I've also been using LilyPond as
>my primary scorewriter for a few years now, and I have been venturing
>through its source code as well.
>> 
>> What a great background for this project!
>> 
>> [FYI, Here's mine: I did one year of the Pure Math program with a
>minor in Computer Science (University of Waterloo), then switched over
>to music and got a Bachelor of Music with a Concentration in Piano
>Performance (University of British Columbia) and Master of Music in
>Composition (Rice University). I have knowledge of Java and XML/XSLT
>(including MusicXML), but no real -fu in any of the other languages
>needed here. I've been using Lilypond since 2002, and would consider
>myself a power user.]
>> 
>>> Looking at the projects listed on LilyPond’s website, the project I
>am most interested in is “Support for Style Sheets”.  I’ve been trying
>to make this functionality for myself anyways, so I’d love to be able
>to partake in the project.  Is there any way I can get some more
>information on the project?  The GSoC page on the LilyPond website is
>helpful, but of course, I’d love to learn more about it.
>> 
>> Stated simply, our goal is to design and implement a mechanism by
>which a user can load one or more "stylesheets" to control the "look &
>feel" of the final compiled score (and, to a lesser degree, determine
>the functionality available to them in the code).
>> 
>> As one concrete example, it would be great to type something like
>> 
>>\useStylesheet "Henle solo piano 1952"
>> 
>> and have the resulting score look "just like" the (e.g.) Beethoven
>Sonata series published by Henle in the mid-20th Century. This
>stylesheet — either by itself or (more likely) in concert with a number
>of hierarchically-arranged stylesheets — would load the correct
>notation fonts, define titling fields and formats, set page geometry,
>etc.
>> 
>> The project will require the answering of a number of technical and
>design questions (e.g., What's the optimal granularity of the
>stylesheet hierarchy? What's the user interface for loading them? How
>will Lilypond determine if a stylesheet is loaded / has already been
>loaded / is not available? What's the graceful degradation plan? etc.).
>> 
>> I have a large number of stylesheets, and a fairly broad experience
>tinkering with them (see my Henle example online, my "Sound of Music"
>sample page, etc.), and so I believe I am well-positioned to help
>someone with real technical/programming skills achieve a great GSoC
>result. If you have more specific questions, let me know (cc'ing the
>list, of course).
>> 
>> Hope this helps!
>> Kieren.
>> 
>> 
>> Kieren MacMillan, composer
>> ‣ website: www.kierenmacmillan.info
>> ‣ email: i...@kierenmacmillan.info
>> 
>
>
>___
>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: Web/Easier editing update

[Urs Liska]

Am 28.02.2018 um 19:00 schrieb Simon Albrecht:

Hi everybody,

I noticed slight glitches when having a look at the ‘Easier editing’ 
page on the website. This is the text about Frescobaldi:


> Frescobaldi is a lightweight, yet powerful, music and text editor 
with many features added and enhanced particularly for LilyPond. Major 
features include point-and-click links between the code and music 
views, detailed score wizards, built in LilyPond documentation 
browser, syntax highlighting and automatic completion. Frescobaldi is 
written in Python, with PyQt4 for its user interface, and will run on 
all major operating systems (GNU/Linux, Mac OS X and Windows).


I’m not a native speaker, so help me out here: the two commas 
encompassing ‘yet powerful’ seem German to me. Is that idiomatic 
English? Also: built in or built-in?


I obviously can't comment on those.



Next, I’d suggest writing just PyQt instead of updating it to PyQt5, 
to avoid the necessity of further updates. Is that a good idea?




I'm not sure, but in any case it's inconsistent (now). It should either 
be "Python" and "PyQt" or "Python 3" and "PyQt5". Your reasoning is 
good, but since these versions are a matter for installing, so it might 
as well be a good idea to keep them (i.e. add the "3").



I’ll propose a patch when these are answered.



If you do you so you might consider also adding "an integrated 
manuscript viewer" to the list of features.


Best
Urs


Best, Simon


___
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: [GSoC 2018] Introduce myself

[Urs Liska]

Hello Wang,


Am 22.02.2018 um 12:39 schrieb Yijie Wang:

  Hi everyone,
My name is Yijie Wang, I'm a Computer Science sophomore from Beijing
Jiaotong University, China. I have knowledge of C++, Python and Java.
Lilypond is a very useful tool for me and I would love to be a part of
improving it.

After looking through this year's Lilypond idealist, I found the project
"Rewrite LibreOffice LilyPond Extension with Python" is quite interesting
and I'd like to work on it as a GSoC project. I've read some code of
Frescobaldi and made some small contribution. I'm going to learn more about
LilyPond, python-ly, PyQt and LibreOffice extension basics in next few
days. If you have some suggestions or more information, don't hesitate to
tell me.


The most "interesting" field to investigate before actually planning the 
project is how a Python extension in LibreOffice can integrate 
"third-party" code. That is: how can you include python-ly (does it have 
to be installed manually, can it be somehow fetched automatically 
through Git or pip)? how can that Python extension make use of PyQt for 
its GUI? (How) is it possible to load code from Frescobaldi, or is this 
not necessary (because the more basic and fundamental python-ly 
functionality is sufficient)?


Maybe it makes sense to find and register with a suitable LibreOffice 
mailing list too.


HTH
Urs



Thanks for reading this, I look forward to contributing to the
Lilypond community in this opportunity.

Best regards,
Wang
___
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: GSoC Follow-Up

[Urs Liska]

Hi Ed,


Am 01.03.2018 um 05:01 schrieb Kieren MacMillan:

Hi Ed,


I’d love to hear everyone’s opinions about doing a project with stylesheets, 
which seems to be the project I plan on applying with.  What would everyone 
want to see in the project?


I think I can piggy-back on Kieren's post to add some thoughts:


Here are some thoughts (stream-of-consciousness):

1. I want to be able to arbitrarily mix and match styles, in any order, without 
triggering conflicts and other problems. Currently in Lilypond, depending on 
which order you set the global font size versus load a stylesheet, initial 
settings can get overwritten/lost for what seems like no good reason. 
Obviously, there has to be some sort of determination of precedence — I'm 
assuming [like CSS] it would be cascading, and last-applied-wins.


One thing that may be challenging on a conceptual and implementational 
level is how to address and include style sheets.
I think we will want to have both public, shared, and local stylesheet 
"repositories".


A "style sheet repository" will have to have one fundamental property 
(presumably the "house" part of "house style"), with all the defining 
subcomponents (e.g. paper, score set-up, etc.) enclosed. I assume that 
the loading functions will look up that root directory and find their 
way down from there.
What I mean is, you could have local repositories (e.g. "client-1", 
"client-2"), then you could have repositories shared in a project and 
hosted on some Git servers, and finally I hope we'll have a 
community-maintained public library. Finally there may be components 
built into LilyPond itself.


We will need a reliable way to address any of these, "mixing and 
matching" without issues.



2. I would like graceful fallback options (cf. CSS font-family lists), so that 
sharing stylesheets isn't a nightmare (e.g., if the person you share with is 
lacking the font you call for). Currently in Lilypond, the fallback situation — 
especially font-related — borders on catastrophic.


I've once worked on font handling, back in 2015, after Abraham added the 
possibility to use alternative notation fonts. Unfortunately I tried to 
fix two things at once, and one of these didn't work (for external 
reasons), with the result that none of it was actually integrated. I 
have just pushed a few of my local branches from then: 
dev/urs/font-selection, dev/urs/font-exists, and dev/urs/font-handling. 
You may have a look at these, but it may not be too much fun. As said 
they are quite old, and it didn't work to simply rebase them on the 
current master, so I didn't bother making that work.


I'm telling this because it might be useful to reconsider these things 
or at least some of them and include them in a project.


The first thing I tried (and IIRC actually succeeded with) is making it 
possible to load notation and text fonts individually instead of all at 
once. So you could, for example in a base file of a style sheet, load a 
set of fonts, and later in a user document change, say, only the sans 
font, without resetting all the other, text and notation, fonts.
I think this worked out quite well, and this would probably be a huge 
step regarding Kieren's with 1) above.


The second thing, which I should really have tackled independently, was 
trying to enable LilyPond to use notation fonts that are installed as 
system fonts (rather than loading it from its own installation directory).
IIRC I actually made this work - but only "work for me", for an annoying 
reason I had no control over, namely fontconfig's failure to fail.
If you ask fontconfig for a certain font it will *always* return a font 
and won't notify you if it didn't find the requested font. At least this 
was the case in 2015, maybe (hopefully) this has changed by now. This 
means if you ask fontconfig for "Adobe Garamond Pro" and this isn't 
installed it might return Times New Roman instead, or whatever it 
consideres the best match. More inconveniently, the fallback font may be 
different on another user's installation.
So my approach was to ask for a given notation font and fall back to 
Emmentaler if it isn't found. But instead fontconfig *did* return a 
font, but if "LilyJAZZ" isn't installed it could return you Arial 
instead. So the idea of an automatic fallback may make some use in 
*text* fonts but definitely not with *notation* fonts.


Llooking into this matter (maybe also by asking fontconfig for 
improvements or workarounds) is probably optional but might be a really 
useful enhancement to the project idea.



3. Naturally, Lilypond should use the new system "100% natively" (which is why 
you’re on board), not as some sort of add-on that requires an additional library (e.g., 
OLL).


But if there's anything in OLL that may be useful or required (from 
oll-core or the notation-fonts package) this can very well be moved into 
LilyPond as part of the project - if it meets the expectations of the 
reviewers community, of course.


B

Re: Allura/SourceForge to Gitlab migration

[Urs Liska]

Am 9. April 2018 20:06:20 MESZ schrieb James Lowe :
>Hello,
>
>On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High 
>wrote:
>
>> On 4/9/2018 11:06 AM, Federico Bruni wrote:
>> > 
>> > I don't want to revamp this old discussion:
>> >
>http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00095.html
>> >
>http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00140.html
>> 
>> I should have read those BEFORE making my other post.
>> 
>> > Current obstacle is that there's no way to import
>Allura/SourceForge 
>> > issues into Gitlab. This is the issue to follow:
>> > https://gitlab.com/gitlab-org/gitlab-ce/issues/45007
>> > 
>> > If you have a Gitlab account, click on the thumb up icon, as
>popular 
>> > issues should have higher chances to be tackled sooner than later.
>> 
>> Created account, upvoted the issue. Thanks for pointing this out.
>
>Does Gitlab really only just have 2 status for an 'issue' (Open and
>Closed) or can this be refined/configured so I (as Patch Meister) can
>keep track of what is 'making its way through' the patch countdown and
>is at the one of the three basic states?
>
>For example how would one know of the ~1000 issues which ones need to
>be reviewed and which ones are ready to push?

Gitlab (like GitHub) uses Merge Requests for the process of patch review. The 
nice thing (compared to the current workflow) is that what is reviewed is what 
will eventually be merged, so it's not at the discretion of the contributor to 
recreate the patch on staging, rewriting the commits etc.

I think combining Merge Requests with the projects as shown by Carl would be a 
good match to the current strategy.

Urs

>
>Regards
>
>James
>
>
>
>
>
>___
>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: Allura/SourceForge to Gitlab migration

[Urs Liska]

Am 09.04.2018 um 22:57 schrieb Federico Bruni:



Il giorno lun 9 apr 2018 alle 22:23, Karlin High 
 ha scritto:

On 4/9/2018 3:05 PM, Karlin High wrote:
Whether terms of service and such are aligned with GNU standards is 
something I haven't checked.


...But if projects like Debian and GNOME are using GitLab, as 
Federico Bruni pointed out, the chances of a terms-of-service 
conflict with GNU and FSF seem rather small.

--



Well, of course they use the open source version, the community 
edition (gitlab-ce). See for example:
http://metadata.ftp-master.debian.org/changelogs/contrib/g/gitlab/gitlab_10.6.3+dfsg-1_copyright 



Enterprise Edition is a no-go, as we do not want to depend on a 
provider, right?
If gitlab.com changes the service terms, you can migrate your projects 
to a self-hosted gitlab-ce.





I must say that this doesn't look like an attractive option to me. I'm 
using a self-hosted version of gitlab-ce, and while it generally works 
it a) uses quite substantial resources and b) it really *is* a task to 
maintain. At least when you want it to be permanently avaiable. I think 
generally on every update I had unexplainable downtimes (HTTP 500 
erorrs) of the web interface (while the Git interface continued to work, 
thankfully).


What I want to say is that for working with Gitlab on a self hosted 
basis we'd need a powerful server available and sufficient people 
willing (and able) to take responsibility for its uptime.


OTOH an interesting aspect could be integration. It should be possible 
to set things up to automatically run the tests when a pull request is 
created or updated, and maybe run GUB upon certain events (e.g. adding a 
release tag).


I don't have a strong opinion about this but I think there should be 
some maintainability and longevity issues to be considered.


Urs


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

Re: Allura/SourceForge to Gitlab migration

[Urs Liska]

Am 09.04.2018 um 21:15 schrieb Carl Sorensen:

On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" 
 
wrote:

 
 
 Am 9. April 2018 20:06:20 MESZ schrieb James Lowe :

 >Hello,
 >
 >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High 
 >wrote:
 >
 >> On 4/9/2018 11:06 AM, Federico Bruni wrote:
 >> >
 >> > I don't want to revamp this old discussion:
 >> >
 >http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00095.html
 >> >
 >http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00140.html
 >>
 >> I should have read those BEFORE making my other post.
 >>
 >> > Current obstacle is that there's no way to import
 >Allura/SourceForge
 >> > issues into Gitlab. This is the issue to follow:
 >> > https://gitlab.com/gitlab-org/gitlab-ce/issues/45007
 >> >
 >> > If you have a Gitlab account, click on the thumb up icon, as
 >popular
 >> > issues should have higher chances to be tackled sooner than later.
 >>
 >> Created account, upvoted the issue. Thanks for pointing this out.
 >
 >Does Gitlab really only just have 2 status for an 'issue' (Open and
 >Closed) or can this be refined/configured so I (as Patch Meister) can
 >keep track of what is 'making its way through' the patch countdown and
 >is at the one of the three basic states?
 >
 >For example how would one know of the ~1000 issues which ones need to
 >be reviewed and which ones are ready to push?
 
 Gitlab (like GitHub) uses Merge Requests for the process of patch review. The nice thing (compared to the current workflow) is that what is reviewed is what will eventually be merged, so it's not at the discretion of the contributor to recreate the patch on staging, rewriting the commits etc.
 
 I think combining Merge Requests with the projects as shown by Carl would be a good match to the current strategy.
 
 Urs
 
I'm really concerned about using Merge Request rather than commits as a means of applying patches.


I'm not going to argue for the Merge Request approach since there are 
too many people in the boat with so much more experience than me. But I 
think that I should point out how most of the concerns you express in 
your reply stem from either comparing apples with oranges or from 
pointing out risks that we already have right now. Probably this won't 
introduce hard arguments *for* the MR approach but should at least 
disseminate your concerns *against* it.




Right now, our current process ensures that every commit on master builds 
properly -- master never gets broken.  The only branch that can get broken is 
staging.


This is not true. Currently we have an *agreement* that nobody pushes to 
master, but IIRC we actually did have issues occasionally when someone 
acidentally did so.
The idea behind the safeguard you mention is that everybody pushes to 
*staging*, and this is only merged (automatically) into master after a 
successful build. This strategy can equally be implemented with the 
Merge Request approach when the Merge Requests have to be created 
against staging ("user X wants to merge branch Y into staging"). It is 
also possible to "protect" branches (e.g. the master branch) against 
forced pushes or against *any* pushes.
So this part's safety is completely equal if not better (depending on 
whether 'master' is protected on the Savannah server or not (I don't 
want to try that out ...)).
Running a test and merging automatically should be possible to implement 
on Gitlab too, at least in the self-hosted version (i.e. scripting on 
the server).




If we use merges instead of single commits, we know that the final result (the 
merge commit) is OK, but we don't know anything about the underlying commits in 
the branch being merged.  Some of those commits may not build properly.  I 
guess those commits won't be on master, but all of the interesting history is 
in those commits, not in the merge commits.


Currently we don't have consistent rules about this either. Small 
patches are *usually* squashed to a single commit and directly applied 
to staging, but more complex patches often are applied as merge commits 
as well.


I admit there is (I think) no straightforward (i.e. intended) way to do 
fast-forward merges in the web interface, so that *would* probably make 
a difference in so far as the history would become more "real" and less 
"cleaned-up".


[Edit: Now that Karlin's research has clarified that Squash-and-merge is 
an option this isn't any downside anymore.]




Finally, it will require somebody to process the merge req

Re: Allura/SourceForge to Gitlab migration

[Urs Liska]

(CCing the list again)


Am 10.04.2018 um 01:07 schrieb Carl Sorensen:


On 4/9/18, 4:20 PM, "Urs Liska"  wrote:

 
 
 Am 09.04.2018 um 21:15 schrieb Carl Sorensen:

 > On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" 
 wrote:
 
 Currently we don't have consistent rules about this either. Small

 patches are *usually* squashed to a single commit and directly applied
 to staging, but more complex patches often are applied as merge commits
 as well.

The CG says we are to squash them; a brief search of the history at Savannah 
shows me no merge commits except translation and release/unstable (which is 
done as part of a release).  Are there more merges happening than I am aware of?


405cba59df2443b14cade4510ad140c77ca58807
0f3898aade7077c15adb2b457e6a5e1238939085
for example.

They are indeed very rare, but if you browse through the output of
git log --merges --pretty=oneline | grep -v translation | less
you'll see that there *are* some.

I recall a conversation where I was told to prefer fast-forward merges 
(or single commits on staging) over merging feature branches. However, 
depending on the situation it might be better to perform a merge if it 
seems useful to preserve the history of a complicated patch.


 
 I admit there is (I think) no straightforward (i.e. intended) way to do

 fast-forward merges in the web interface, so that *would* probably make
 a difference in so far as the history would become more "real" and less
 "cleaned-up".
 
Un-cleaned-up history messes up git-bisect, doesn't it?


I'm not fully clear about that, but I'd say as long as all commits that 
end up on master are clean it should be fine.




 [Edit: Now that Karlin's research has clarified that Squash-and-merge is
 an option this isn't any downside anymore.]
 
 >

 > Finally, it will require somebody to process the merge requests.  I 
guess that is nice from the point of uniformity, but it will require somebody 
other than the developer who created the patch to be responsible for ensuring that 
the tree is all OK.  I don't know who that person will be.
 
 Not necessarily.

 It could be set up that opening a merge request would trigger the test
 build, upon which the "issue" is moved to the corresponding column
 ("patch: new") in the review "project".

If we have a straightforward way of setting this up, it would be a big 
advantage.  We used to have scripts to do it, but they went away when we moved 
to SourceForge/Allura.  I spent some time trying to get them reimplemented, but 
didn't get it done.  So now James has to do it manually.


Triggering a test build should be straightforward with Gitlab's concept 
of continuous integration or by Git hooks. The Gitlab server can send 
out an HTTP request to some URL as a response to Git events like pushes. 
This can be configured to trigger a test build whenever a Merge Request 
is opened (either on the Gitlab server or on another server). Of course 
this has to be programmed by someone and I don't have a clear idea how 
complex it would become.


I *assume* it should be possible to use the Gitlab API to automatically 
move the MR/issue (internally a Merge Request *is* an Issue) to a "new" 
column in a "review" project, but I have never done anything in that area.


 
 How do patches *currently* flow through the review process? I.e. how are

 they changed from "new" to "review" to "countdown" to "push"? Probably
 this could also be automated, but if James currently does *any* manual
 step with this it should definitely not be more work to do that on Gitlab.

James does manual work for all of those transitions.  The extra work is not 
setting the flags, but in actually doing the merge.


Maybe also this could be automated using the API: move any issue that is 
in column A to column B etc. But again I have no clear idea about the 
effort, and moving stuff manually might be easier since handling 
corner/special cases is of course much easier when done by a human.


 
 Also merging doesn't have to be done by someone else, it can still be

 done by the contributor, that's just a matter of policy.
 Today as a contributor I have to clean up my branch and apply it to
 staging, either as a single commit, as a series of commits or as a merge
 commit. With the Merge Request I would instead simply be allowed to
 merge my own request.

If merging is something other than a fast-forward, it can get challenging 
really quickly for a new contributor.


Well, yes, of course.
But I don't see how this should make a difference:

I've tried to work through merging with several git novices, and all of them 
have had problems with i

Re: Release schedule for 2.20

[Urs Liska]

Am 9. Mai 2018 12:18:37 MESZ schrieb Aaron Hill :
>On 2018-05-09 02:49, Malte Meyn wrote:
>> But an increasing number of questions asked in forums or on the lists
>> can be answered by “compile current master or wait for 2.21.0”. And a
>> huge number of answers requires at least 2.19.xx but people
>> understandably don’t want to install an “unstable” version.
>> 
>> Since the first prerelease seven months have passed, people wonder
>> whether 2.20.0 will happen in a few weeks, a few months or even
>longer
>> in the future.
>
>I should have stated originally that I am not trying to force anything 
>here.  I totally understand that the developers on this project may be 
>most comfortable with the approach of "we'll release it when it's
>ready, 
>not a moment before".  Rather, I was curious if the team had a planned 
>roadmap they were currently targeting, and where one could easily track
>
>that information.  It sounds like nothing of that sort really exists.  
>This is not ideal but hardly something to stress about.
>
>What does have impact for me is whether the next release is still many 
>months out or longer.  Knowing a little bit about the schedule, I can 
>more easily justify the time expense of getting a build environment set
>
>up to be able to run from master or some other staging branch.  I have 
>no qualms of running "bleeding-edge" bits.  That said, it is always
>more 
>convenient to be able to work from pre-built binaries, although those 
>understandably take time to create and publish.
>

This very much looks to me that your best bet is to install the latest release 
from the 2.19 series.
The only reason to compile yourself would be to incorporate custom patches.

Urs

>So, I apologize if I have ruffled any feathers here.
>
>-- Aaron Hill
>
>___
>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

\class grob property

[Urs Liska]

Hi all,

I'm thinking about having a new grob property \class, but before digging 
deeper I'd like to put the idea up for discussion.


This would have two different goals:

1) for SVG output the objects would get the class assigned (along with 
an id). I don't have any idea yet how that is implemented, though. This 
will make it possible to work with CSS in a display environment.


2) (Formatting) functions can check for a grob's class to perform e.g. 
highlighting operations (=> color all NoteHeads with class "temporary" red)


In addition I would like to use that to export class information to 
MusicXML.


Any comments or objections?
Urs


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

Re: \class grob property

[Urs Liska]

Am 14.05.2018 um 00:02 schrieb David Kastrup:

Urs Liska  writes:


Hi all,

I'm thinking about having a new grob property \class, but before
digging deeper I'd like to put the idea up for discussion.

This would have two different goals:

1) for SVG output the objects would get the class assigned (along with
an id). I don't have any idea yet how that is implemented,
though. This will make it possible to work with CSS in a display
environment.

2) (Formatting) functions can check for a grob's class to perform
e.g. highlighting operations (=> color all NoteHeads with class
"temporary" red)

In addition I would like to use that to export class information to
MusicXML.

Any comments or objections?

The various semantics seem to be tied more to the word "class" than a
common concept underlying the proposed uses of this property.  Maybe
explain some more what the generic concept of class should be and why
the proposed backend semantics are in every case the proper match to the
concept?



The idea is to give various grobs a secondary name, making same-named 
grobs belong to a group of objects where the grouping is independent 
from groupings like grob type or voice/staff/measure/etc. context. To 
express what I mean other words would be appropriate as well, such as 
e.g. "type", but I would suggest to use the same word (and concept) as 
is used in CSS.


In scholarly editions you may have score items you want to mark up as 
"addition", "emendation", "deletion". It's already possible to define 
music functions that produce the highlighting you want to apply to these 
types of grobs, for example dash slurs added by the editor. With that 
you also have a way to centrally control the appearance, for example to 
also use colors while working on the edition and suppress that for the 
final publication.
However, the resulting grob will not "know" it is an addition but only 
that it is dashed and green, for example.


My suggestion is to have the possibility (which of course doesn't 
discourage the use of music functions as would be done currently) to 
instead set a grob's 'class' property to semantically mark up that grob 
instead of (directly) changing its appearance, deferring the styling to 
a later stage.
In LilyPond this can for example be an engraver that tests grobs for 
their class property and acts upon that.
If the class property is exported to SVG then the appearance of objects 
can be controlled interactively with CSS. The same should be possible 
when exporting to MusicXML.


Probably an engraver should be made available as well (but not consisted 
to any context by default), along with a means of defining "styles" 
(maybe an alist of property/value pairs) that will be applied to grobs 
with the given class. A style should be somewhat hierarchical, at least 
to allow generic property/value pairs and additional ones for specific 
grob types (for example note heads should probably not be dashed ...). I 
haven't thought about the idea of actually make styles cascading like in 
CSS, and I'm not sure there's an appropriate concept of nestedness that 
would make that a natural thing to pursue.


I think it would be nice to provide a command [\once] \class  
 which should also be usable as a \tweak on individual 
grobs. Very practical would also be to have a context property as well, so

    \set Voice.class = "unclear"
would attach the class to every grob within its scope.

Like with CSS multiple classes should be possible with
    \class Beam "unclear addition"

My examples so far all come from scholarly editing but I think this 
could open up a wide array of use cases. Think about classes like the 
following:

    \class LyricText "excited"
    \set Voice.class = "muted"
    \class Hairpin "grey1 dashed with-text"
    \class RehearsalMark "rehearsal-mark"
    \class RehearsalMark "section-mark"

Urs

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

Re: \class grob property

[Urs Liska]

Hi Harm,


Am 14.05.2018 um 10:36 schrieb Thomas Morley:

2018-05-14 8:50 GMT+02:00 Urs Liska :


Am 14.05.2018 um 00:02 schrieb David Kastrup:

Urs Liska  writes:


Hi all,

I'm thinking about having a new grob property \class, but before
digging deeper I'd like to put the idea up for discussion.

This would have two different goals:

1) for SVG output the objects would get the class assigned (along with
an id). I don't have any idea yet how that is implemented,
though. This will make it possible to work with CSS in a display
environment.

2) (Formatting) functions can check for a grob's class to perform
e.g. highlighting operations (=> color all NoteHeads with class
"temporary" red)

In addition I would like to use that to export class information to
MusicXML.

Any comments or objections?

The various semantics seem to be tied more to the word "class" than a
common concept underlying the proposed uses of this property.  Maybe
explain some more what the generic concept of class should be and why
the proposed backend semantics are in every case the proper match to the
concept?


The idea is to give various grobs a secondary name, making same-named grobs
belong to a group of objects where the grouping is independent from
groupings like grob type or voice/staff/measure/etc. context. To express
what I mean other words would be appropriate as well, such as e.g. "type",
but I would suggest to use the same word (and concept) as is used in CSS.

In scholarly editions you may have score items you want to mark up as
"addition", "emendation", "deletion". It's already possible to define music
functions that produce the highlighting you want to apply to these types of
grobs, for example dash slurs added by the editor. With that you also have a
way to centrally control the appearance, for example to also use colors
while working on the edition and suppress that for the final publication.
However, the resulting grob will not "know" it is an addition but only that
it is dashed and green, for example.

My suggestion is to have the possibility (which of course doesn't discourage
the use of music functions as would be done currently) to instead set a
grob's 'class' property to semantically mark up that grob instead of
(directly) changing its appearance, deferring the styling to a later stage.
In LilyPond this can for example be an engraver that tests grobs for their
class property and acts upon that.
If the class property is exported to SVG then the appearance of objects can
be controlled interactively with CSS. The same should be possible when
exporting to MusicXML.

Probably an engraver should be made available as well (but not consisted to
any context by default), along with a means of defining "styles" (maybe an
alist of property/value pairs) that will be applied to grobs with the given
class. A style should be somewhat hierarchical, at least to allow generic
property/value pairs and additional ones for specific grob types (for
example note heads should probably not be dashed ...). I haven't thought
about the idea of actually make styles cascading like in CSS, and I'm not
sure there's an appropriate concept of nestedness that would make that a
natural thing to pursue.

I think it would be nice to provide a command [\once] \class 
 which should also be usable as a \tweak on individual grobs.
Very practical would also be to have a context property as well, so
 \set Voice.class = "unclear"
would attach the class to every grob within its scope.

Like with CSS multiple classes should be possible with
 \class Beam "unclear addition"

My examples so far all come from scholarly editing but I think this could
open up a wide array of use cases. Think about classes like the following:
 \class LyricText "excited"
 \set Voice.class = "muted"
 \class Hairpin "grey1 dashed with-text"
 \class RehearsalMark "rehearsal-mark"
 \class RehearsalMark "section-mark"

Urs


Hi Urs,

it's still not very clear to me what you want.
This may be due to my limited knowledge of the english language: I
tend to skip detailed explanations.
Not always the right thing, I have to admit...

I'd prefer code.
You certainly know how to define custom context/grob-properties. But
even without doing so, below row implementation is possible. At least
for grobs.

TstEngraver =
#(lambda (context)
   (make-engraver
 (acknowledgers
   ((grob-interface engraver grob source-engraver)
 (let* ((details (ly:grob-property grob 'details '()))
(class (assoc-get 'class details)))
   (cond ((symbol-list? class)
(if (member 'deleted class)
(ly:grob-set-property! grob 'color grey)))
 ((symbol? class)
   

Re: \class grob property

[Urs Liska]

Hi Paul,

thanks for this information.

This is indeed exactly what I was looking for and will make life easier 
for several things.


I think we'll be investigating the options in this year's GSoC project, 
maybe that will be helpful thinking about hierarchical stylesheets 
another way.


Best
Urs


Am 17.05.2018 um 14:15 schrieb Paul Morris:

Hi Urs,

On 05/13/2018 02:02 PM, Urs Liska wrote:

1) for SVG output the objects would get the class assigned (along 
with an id). I don't have any idea yet how that is implemented, 
though. This will make it possible to work with CSS in a display 
environment.


You'll be glad to know this is already supported in 2.19.  Check out 
this grob property:


|output-attributes| (list)

   An alist of attributes for the grob, to be included in output files.
   When the SVG typesetting backend is used, the attributes are
   assigned to a group () containing all of the stencils that
   comprise a given grob. For example, |'((id . 123) (class . foo)
   (data-whatever . “bar”))| will produce | … |. In the Postscript backend, where there
   is no way to group items, the setting of the output-attributes
   property will have no effect.


It's only documented in the internals reference.  I think it probably 
gives you what you need to do what you want?


I added this functionality to LilyPond awhile back while working on 
'lilypond-html-live-score'.  (Would like to find more time to do more 
work with that, but...)  This code might be of interest: 
https://gitlab.com/sigmate/lilypond-html-live-score/blob/master/grob-inspector.ily


Cheers,
-Paul
___
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: \class grob property

[Urs Liska]

Am 17.05.2018 um 15:46 schrieb David Kastrup:

Paul Morris  writes:


On 05/17/2018 09:00 AM, David Kastrup wrote:


Man, I must have slept through this.  "this is already supported in
2.19" is misleading if it's actually only supported _outside_ of 2.19,
namely by chancing upon people in the know in the mailing lists.

The problem with that kind of support is that it's unreliable.  Stuff
might get reimplemented because people cannot find what they are looking
for, and the old code might get removed as bit rot at any point of time.

To actually move it to "supported" state inside of LilyPond, there need
to be regression tests (which also stop bit rot), user-level
documentation and a Changes entry.  That gives a new feature a
reasonable chance of getting tested and consolidated in order to be
useful for more than a single application (often by a single person) in
its region of interest.

Do you feel up to getting that kind of support into LilyPond?

Hi David,  I agree that this deserves to have regression tests,
user-level docs, and a changes entry (to go with its current
documentation in the internals reference).  I'll try to find time to
work on those things in the next weeks.

That would be very appreciated.  Just from the few bits I have read
right now, it appears to me like the purpose, scope, and behavior of
that extension is a whole lot more specific, prescriptive and
predictable in connection with various backends than Urs' proposal.


Not necessarily ;-)
I think the main difference between Paul's and my descriptions is that 
his basically does *not* talk about use cases and simply describes what 
is implemented, while I tried to tease out suggestions by giving rather 
vage descriptions.


However, the examples we've seen from Paul are better than what I had in 
mind in so far as this property is somewhat generic: it allows the user 
to generate arbitrary attributes in the XML elements, not only the 
standardized "id" and "class" ones.



Which does not preclude Urs building some higher-level functionality of
the kind he envisions based on this.


Exactly :-)

Best
Urs





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

Re: Doc: document grob metadata in SVG output in Notation Reference (issue 357720044 by paulwmor...@gmail.com)

[Urs Liska]

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

Re: #5355 Doc: document grob metadata in SVG output in Notation Reference

[Urs Liska]

Am 01.07.2018 um 09:55 schrieb James Lowe:

I don't know what the difference is between pull and fetch in terms of 'rights' 
but I'd have thought it would be the same right?



Yes, the difference comes only on your own computer.

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

Re: xml2ly, a new translator from MusicXML to LilyPond

[Urs Liska]

Am 1. September 2018 11:37:14 MESZ schrieb Victor Rouanet 
:
>Le 01/09/2018 à 10:25, Menu Jacques a écrit :
>> I only have read access to the github issue tracker yet. How can can
>I 
>> get working access to it?
>>
>I guess you have to ask the repository owner to grant you the 
>appropriate permission, but I don't know github very well. We can also 
>exchange by email (peut-être en français :-)) if it suits you better
>for 
>the moment.

It is correct that the owner of a GitHub repository can grant access to a 
repository. AFAIK the privilege to edit issues is the same as the one for 
pushing, though.

However, I'm somewhat confused: do you have a new tool in your own repository 
it were you only referencing Dominique Fober's library (I don't have access to 
a PC right now, so I couldn't check it out)?

>
>___
>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: xml2ly, a new translator from MusicXML to LilyPond

[Urs Liska]

Am 1. September 2018 17:09:23 MESZ schrieb Menu Jacques :
>Hello Urs,
>
>My work (MSR, LPSR and xml2ly) is contributed to Grame’s library as the
>‘lilypond’ branch of their github repository.
>
>The aim is to merge them with the ‘dev’ branch soon, in which case it
>will become part of the library itself.
>

Ah, that clarifies things.

>My OP’s aim is to see how they can be built automatically and made
>available together with LilyPond on the three main OSes, should they be
>felt as useful for a number of Lily users.

I'm sure that can be made possible. Maybe the best bet would be to create a 
small wrapper that uses the library and can be deployed with LilyPond.

The question is whether that will be an improvement over the current state that 
is worth the effort.
I can think of several reasons why this could be the case (better 
coverage/"knowledge" of MusicXML, joining a wider MusicXML community etc.), but 
as said I'm still not at home yet and didn't have any chance to look into it.

Best
Urs

>
>Quoted from Dominique Fober on this topic:
>
>   Binaries are not available from the git repository, they are
>distributed using sourceforge file release system.
>
>JM
>
>> Le 1 sept. 2018 à 11:50, Urs Liska  a écrit :
>> 
>> 
>> 
>> Am 1. September 2018 11:37:14 MESZ schrieb Victor Rouanet
>:
>>> Le 01/09/2018 à 10:25, Menu Jacques a écrit :
>>>> I only have read access to the github issue tracker yet. How can
>can
>>> I 
>>>> get working access to it?
>>>> 
>>> I guess you have to ask the repository owner to grant you the 
>>> appropriate permission, but I don't know github very well. We can
>also 
>>> exchange by email (peut-être en français :-)) if it suits you better
>>> for 
>>> the moment.
>> 
>> It is correct that the owner of a GitHub repository can grant access
>to a repository. AFAIK the privilege to edit issues is the same as the
>one for pushing, though.
>> 
>> However, I'm somewhat confused: do you have a new tool in your own
>repository it were you only referencing Dominique Fober's library (I
>don't have access to a PC right now, so I couldn't check it out)?
>> 
>>> 
>>> ___
>>> 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: xml2ly, a new translator from MusicXML to LilyPond

[Urs Liska]

Am 1. September 2018 19:57:29 MESZ schrieb Menu Jacques :
>Hello Urs,
>
>
>> Maybe the best bet would be to create a small wrapper that uses the
>library and can be deployed with LilyPond.
>
>Well, actually, xml2ly is such a wrapper.
>

Ah, I thought this could be the case immediately after I sent my message ;-)

I was misled by your reference of it being integrated as part of a library.

Looking forward to see more of it ...

>JM

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

Re: Non-quadratic form of whiteout

[Urs Liska]

Am 16.09.2018 um 15:19 schrieb Malte Meyn:



Am 16.09.18 um 15:16 schrieb Kieren MacMillan:
 3. at any other point on the grob, the whiteout should extend 
[horizontally and vertically] by an interpolated amount.


How to interpolate? Maybe in such a way that a point or circle gets an 
elliptical whiteout?


Am I getting something wrong here: why are you asking about intermediate 
points? Aren't we only interested in the whiteout around the outer edges?





___
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: Non-quadratic form of whiteout

[Urs Liska]

Am 16.09.2018 um 15:44 schrieb Kieren MacMillan:

Hi Urs,


Am I getting something wrong here: why are you asking about intermediate 
points? Aren't we only interested in the whiteout around the outer edges?

Consider the letter O, with 'outline #'(5 . 0). It’s easy to see that the thickness on top (at the 
"N" compass point) is 5 units, and the thickness on the right (at the "E" compass point). 
But we need to determine the thickness at the "NW" (45º) compass point — that requires 
interpolation between 5 and 0, right?


OK, I see.
But then you can't start from / think about an interpolation of the 
extreme points because that woudl require knowledge about the nature of 
the shape (what about the outline of an "F" or a note with a flag?). 
Instead one has to have some actual determination of the grob's outline.


Without having dug into the issue before I could see two approaches:
1) see how the skyline detection works and go from there
2) use a scaled version of the original glyph as the whiteout area:

Say you have a notehead with width 3 and height 1.5 (as measured by 
X-extent and Y-extent).

'outline #'(5 . 0) is desired.
That means:
- the total height of the whiteout is 1.5 (1.5 + 2x0)
- the total width of the whiteout is 13 (3 + 2x5)
- a note head vertically scaled by 1 (1.5/1.5) and horizontally scaled 
by 13/3 should have exactly the shape of the whiteout.


Does that make sense?
Would that work with non-solid shapes? If you have a letter "O" the 
whiteout would not be the scaled O but the area surrounded by the scaled O.
What about the whiteout for non-contigiuos things like markup 
(consecutive letters)?
How to determine the exact center of the shape to match the original and 
scaled shape?


Urs


Cheers,
Kieren.


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




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

Re: Negative page numbers

[Urs Liska]

Am 16. September 2018 21:28:26 MESZ schrieb Dan Eble :
>> Real
>> Page_breaking::page_height (int page_num, bool last) const
>> {
>>   // The caches allow us to store the page heights for any
>>   // non-negative page numbers.  We use a negative value in the
>>   // cache to signal that that position has not yet been initialized.
>>   // This means that we won't cache properly if page_num is negative
>or
>>   // if calc_height returns a negative number.  But that's likely to
>>   // be rare, so it shouldn't affect performance.
>
>This comment seems to imply that there are legitimate uses for negative
>page numbers.  Is anyone willing to agree that I am interpreting it
>correctly?

Literally, yes.
But someone like me might also write that comment to conceal that I don't know 
how to prove it *can't* happen ;-)

>
>Thanks,
>— 
>Dan
>
>
>___
>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

Limit the angle of broken hairpins

[Urs Liska]

Hi,

as brought up in 
http://lists.gnu.org/archive/html/lilypond-user/2018-09/msg00236.html 
broken hairpins look ugly when they are too short. This is (as pointed 
out by Harm) due to the fact that the heights at the broken edges are 
hardcoded in the C++ function printing the hairpin.


I suggest a two-fold remedy:

1) limit the heights at the broken edges so the height/width ratio of 
the sibling doesn't exceed a certain value (I'd start with 1/2)


2) make that ratio and the broken-heights values user-settable as grob 
properties.


I've given it a partial try that can be seen at 
https://github.com/lilypond/lilypond/pull/4. This commit (hopefully) 
implements part 1) of the above. I've also attached the patch. Since I 
don't have a working build environment right now I couldn't test this 
code, but it should be straightforward, I think.


I would be glad if someone could add the code to create the grob 
properties (should be little work but not if you have to first look 
everything up like me) in order to upload it for review later.


Urs

>From 500f284e6776eb90d389d378c0f92c7d02e5e9a0 Mon Sep 17 00:00:00 2001
From: Urs Liska 
Date: Tue, 18 Sep 2018 11:53:23 +0200
Subject: [PATCH] Limit angle of broken hairpins

Broken parts of hairpins don't look good when they are too short.
This is because their height at the broken side is hard-coded to
2/3 and 1/3 of the hairpin's height. So when the sibling's width is small
the ratio/angle is too high to be visually pleasing.

This commit (initial thoughts) limits the width/height ratio of broken
hairpins to 1/2.

It would be good to provide both the broken-heights and the ratio
as native grob properties for Hairpin, though.
---
 lily/hairpin.cc | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lily/hairpin.cc b/lily/hairpin.cc
index afd94f3ee0..5fe36a58ec 100644
--- a/lily/hairpin.cc
+++ b/lily/hairpin.cc
@@ -271,15 +271,18 @@ Hairpin::print (SCM smob)
 
   Real starth = 0;
   Real endh = 0;
+  Real max_ratio = width / 2
+  Real continued_height = height / 3
+  Real continuing_height = 2 * height / 3
   if (grow_dir < 0)
 {
-  starth = continuing ? 2 * height / 3 : height;
-  endh = continued ? height / 3 : 0.0;
+  starth = continuing ? std::min(continuing_height, max_ratio) : height;
+  endh = continued ? std::max(continued_height, height - max_ratio) : 0.0;
 }
   else
 {
-  starth = continued ? height / 3 : 0.0;
-  endh = continuing ? 2 * height / 3 : height;
+  starth = continued ? std::max(continued_height, height - max_ratio) : 0.0;
+  endh = continuing ? std::min(continuing_height, max_ratio) : height;
 }
 
   /*
-- 
2.18.0

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

Re: Problem with guile-2.9.1-prerelease

[Urs Liska]

Am 11. Oktober 2018 20:17:45 MESZ schrieb Karlin High :
>On 10/11/2018 12:59 PM, David Kastrup wrote:
>> we should be able to add code that will run under all versions.
>
>The guile-devel post linked in the OP indicates that Guile 3 should
>have 
>greatly improved performance over Guile 2. Maybe even better than 
>LilyPond's current Guile 1.8.
>
>What level of optimism is appropriate for that claim?

I don't think that tells us very much. From 1.8 to 2 they added "significant 
improvements" that caused massive performance problems for our specific use 
case. And I woulcn't bet too much money that the improvements you mention 
specifically address these issues ...

Urs

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