Re: Looking for help in configuring LilyDev in VirtualBox

[Michael Käppler]

Am 21.01.2020 um 20:44 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox
This time after the reboot I got the same result. No sharing of
clipboard, no more processes. Tried closing VBox and restarting it,
but same result.

Try to start the client manually and see what happens:
/usr/bin/VBoxClient --clipboard



There's one slight oddity: often (but not always) when booting the
LilyDev guest I get an error message - a bit too long to copy the text
so here's a screenshot:



I don't know if it's significant. It doesn't change the clipboard
behaviour.

From time to time, this happens on my machine, too.
I thought it would be a problem specific to my combination of VirtualBox
version / host os
and guest os, but if you encounter the same problem it could be a
general issue.

It's possible that my hamfisted attempts to install LilyDev as a guest
without all the instructions has screwed something up. I could start
again tomorrow using the instructions you sent me and see if it makes
any difference.

Yes, I would suggest that you start from scratch again.

Best regards,
Michael

Re: Context paths (and the Edition Engraver)

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: David Kastrup 
> To: Dan Eble 
> Cc: lilypond-devel@gnu.org
> Bcc:
> Date: Tue, 21 Jan 2020 22:51:29 +0100
> Subject: Re: Context paths (and the Edition Engraver)
> Dan Eble  writes:
>
> > On Jan 21, 2020, at 14:37, David Kastrup  wrote:
> >>
> >> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
> >
> > OK.  It would be an understandable growth on the current face of
> LilyPond. :)
> >
> > Questions follow, but I'm not asking you to spend time investigating.
> >
> > Do you think we could achieve making the quotes optional for some
> > simple IDs, and making the whitespace optional?
> >
> > StaffGroup=organ.Staff=upper.Voice.SubVoice=2
>
> It would all be optional (except in \lyricsmode or \markup) but I am
> skeptical that it would make for a great convention.
>
> > In a situation where the user didn't care to constrain the context
> > types, do you think could they be omitted, or would we have to invent
> > a placeholder?
> >
> > =organ.=upper..=2
> > X=organ.X=upper.X.X=2
>
> I don't think that this would be a reasonable syntax.
>

Just chiming in to agree that this syntax is not very clear.
At least, I find it confusing to see what looks like multiple assignments
(use of =) on the same line.
The = in this case is not being used in this case to define something, but
to identify something that presumably already exists.


Is there any hope of having syntax like one of the following?

StaffGroup("organ").Staff("upper").Voice.SubVoice("2")
StaffGroup["organ"].Staff["upper"].Voice.SubVoice["2"]


The square braces make it look like you're looking up an element in an
(associative) array, which is kind of what we're doing, if I understand
correctly.  That is, if StaffGroup (in a Context context) refers to all
StaffGroup contexts, and then we're narrowing this down by identifying one
by name, in this example, the one called "organ".

The parenthesis syntax makes it look more like a function call.   (So, it
might be clearer if it were called getStaffGroup)   However, the
parenthesis/function-call syntax makes it easier to identify multiple staff
groups by name, if it can take an array of names.  So, to identify all
voice contexts in all lower staves of three different staff groups:

StaffGroup("organ", "piano", "celeste").Staff("lower").Voice


I realize that the EE use case is more about identifying a very specific
context, in order to apply specific edits.

But, in general, from a context point of view, the general use case
involves identifying all or a subset of contexts.



Also, to comment on another previously suggested model for syntax,
the CSS selector approach is not a good one to model,
since its use of spaces and dots is not consistent with how they are used
here, to indicate sub-properties.

Which is to say, in CSS, dots between identifiers (with no spaces)
refer to multiple properties  of the same element,
and spaces are used to identify descendants.

For example:

confusion

.bar => matches both the outer DIV and inner SPAN
#foo .bar => matches the inner SPAN
#foo.bar => matches the outer DIV



Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails

[David Kastrup]

Thomas Morley  writes:

> Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>>
>>
>>  #(ly:set-option 'warning-as-error #t)
>>  %% not sure why these warnings appear twice [dfe]
>> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
>> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
>> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
>> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
>> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
>> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
>> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
>> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
>>
>>  \header {
>>texidoc = "A @code{\\defaultchild} cycle does not induce an endless loop.
>
> Got it, many thanks
>
>>
>> So why is that patch not in your
>> input/regression/context-defaultchild-cycle ?
>
> Obviously I patched this regtest (to reflect new guile-3 shortcut of
> gettext), _before_ Dan corrected it.
> And prefered my patch during solving the merge-conflict, without
> noticing the correction.

Ah right, that gettext thing.  Forgot about that.

-- 
David Kastrup

Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails

[Thomas Morley]

Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > some remarks:
> >
> > Guile-3.0
> > First I compiled successfully guile-master from their repo, giving GNU
> > Guile 3.0.0.6-f3298
> > Trying to compile LilyPond with that guile (ofcourse adding a bunch of
> > patches) I had some problems pointing configure to the correct guile
> > and guile-config to the correct places. This was due to my setup with
> > too many guile-versions around. So I did some clean up.
> >
> > LilyPond
> > Afterwards I've got a successful ´make´ with current LilyPond-master.
> > ´make LANGS='' doc´ failed, though.
> >
> > The problem is /input/regression/context-defaultchild-cycle.ly
> > I do not understand how this regtest survives any compilation.
> > It contains
> > #(ly:set-option 'warning-as-error #t)
> > and some
> > #(ly:expect-warning ...)
> > If I compile it, separetly I always get warnings (after disabling
> > 'warning-as-error )
> > warning: default child context begins a cycle: Score
> > warning: cannot find or create context: Bottom
> > warning: default child context begins a cycle: Score
> > warning: cannot find or create context: Bottom
> > warning: 4 expected warning(s) not encountered:
> > default child context begins a cycle: `Score'
> > cannot find or create new `Bottom'
> > default child context begins a cycle: `Score'
> > cannot find or create new `Bottom'
> >
> > As far as I understand it errors always.
>
> commit 51b6513eeeaea69293bd4f554f8021529ae85a49
> Author: Dan Eble 
> Date:   Mon Jul 2 13:36:48 2018 -0400
>
> Issue 5366: Move warnings out of find/create context functions
>
> The motivation for this is that Context::find_create_context () and
> find_context_near () should probably be merged for maintainability,
> but one of the differences between them that must be dealt with is
> that find_create_context () logs when it fails and find_context_near
> () does not.  Adding warnings to find_context_near () risks being too
> noisy, leaving the option taken here.
>
> The new method Context::diagnostic_id (name, id) returns a formatted
> string (e.g. "Voice" or "Voice = mel") for use in a log message.  It
> is used for the warnings that are being moved as well as a few other
> existing warnings to increase consistency.
>
> diff --git a/input/regression/context-defaultchild-cycle.ly 
> b/input/regression/context-defaultchild-cycle.ly
> index f62532f8bb..46de604dfd 100644
> --- a/input/regression/context-defaultchild-cycle.ly
> +++ b/input/regression/context-defaultchild-cycle.ly
> @@ -2,10 +2,10 @@
>
>  #(ly:set-option 'warning-as-error #t)
>  %% not sure why these warnings appear twice [dfe]
> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
> -#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
> +#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
> +#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
>
>  \header {
>texidoc = "A @code{\\defaultchild} cycle does not induce an endless loop.

Got it, many thanks

>
> So why is that patch not in your
> input/regression/context-defaultchild-cycle ?

Obviously I patched this regtest (to reflect new guile-3 shortcut of
gettext), _before_ Dan corrected it.
And prefered my patch during solving the merge-conflict, without
noticing the correction.

Thanks,
  Harm

Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails

[David Kastrup]

Thomas Morley  writes:

> Hi,
>
> some remarks:
>
> Guile-3.0
> First I compiled successfully guile-master from their repo, giving GNU
> Guile 3.0.0.6-f3298
> Trying to compile LilyPond with that guile (ofcourse adding a bunch of
> patches) I had some problems pointing configure to the correct guile
> and guile-config to the correct places. This was due to my setup with
> too many guile-versions around. So I did some clean up.
>
> LilyPond
> Afterwards I've got a successful ´make´ with current LilyPond-master.
> ´make LANGS='' doc´ failed, though.
>
> The problem is /input/regression/context-defaultchild-cycle.ly
> I do not understand how this regtest survives any compilation.
> It contains
> #(ly:set-option 'warning-as-error #t)
> and some
> #(ly:expect-warning ...)
> If I compile it, separetly I always get warnings (after disabling
> 'warning-as-error )
> warning: default child context begins a cycle: Score
> warning: cannot find or create context: Bottom
> warning: default child context begins a cycle: Score
> warning: cannot find or create context: Bottom
> warning: 4 expected warning(s) not encountered:
> default child context begins a cycle: `Score'
> cannot find or create new `Bottom'
> default child context begins a cycle: `Score'
> cannot find or create new `Bottom'
>
> As far as I understand it errors always.

commit 51b6513eeeaea69293bd4f554f8021529ae85a49
Author: Dan Eble 
Date:   Mon Jul 2 13:36:48 2018 -0400

Issue 5366: Move warnings out of find/create context functions

The motivation for this is that Context::find_create_context () and
find_context_near () should probably be merged for maintainability,
but one of the differences between them that must be dealt with is
that find_create_context () logs when it fails and find_context_near
() does not.  Adding warnings to find_context_near () risks being too
noisy, leaving the option taken here.

The new method Context::diagnostic_id (name, id) returns a formatted
string (e.g. "Voice" or "Voice = mel") for use in a log message.  It
is used for the warnings that are being moved as well as a few other
existing warnings to increase consistency.

diff --git a/input/regression/context-defaultchild-cycle.ly 
b/input/regression/context-defaultchild-cycle.ly
index f62532f8bb..46de604dfd 100644
--- a/input/regression/context-defaultchild-cycle.ly
+++ b/input/regression/context-defaultchild-cycle.ly
@@ -2,10 +2,10 @@
 
 #(ly:set-option 'warning-as-error #t)
 %% not sure why these warnings appear twice [dfe]
-#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
-#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
-#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
-#(ly:expect-warning (_ "cannot find or create new `~a'") 'Bottom)
+#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
+#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
+#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
+#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
 
 \header {
   texidoc = "A @code{\\defaultchild} cycle does not induce an endless loop.

So why is that patch not in your
input/regression/context-defaultchild-cycle ?

-- 
David Kastrup

Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails

[Thomas Morley]

Am Mi., 22. Jan. 2020 um 00:41 Uhr schrieb Karlin High :
>
> On 1/21/2020 5:10 PM, Thomas Morley wrote:
> > Afterwards I've got a successful ´make´ with current LilyPond-master.
>
> So it's a functional LilyPond with guile-3.0? How does it perform if fed
> something big? I'm thinking of the thread on benchmarking that used
> Vaughan McAlley's MDSM.ly, the Robert Carver "Missa Dum sacrum mysterium."
>
> 
> --
> Karlin High
> Missouri, USA

Hi Karlin,

no idea.
I'll first try to get a succesfull ´make doc´ and then try to get
´make test-baseline´ work, which failed for other recent
guile-versions.
Currently I commented the problematic code in the mentioned regtest,
continuing with ´make doc´. Testing how far I'll get.


Cheers,
  Harm

Re: guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails

[Karlin High]

On 1/21/2020 5:10 PM, Thomas Morley wrote:

Afterwards I've got a successful ´make´ with current LilyPond-master.


So it's a functional LilyPond with guile-3.0? How does it perform if fed 
something big? I'm thinking of the thread on benchmarking that used 
Vaughan McAlley's MDSM.ly, the Robert Carver "Missa Dum sacrum mysterium."



--
Karlin High
Missouri, USA

guile-3.0 and LilyPond - here: /input/regression/context-defaultchild-cycle.ly fails

[Thomas Morley]

Hi,

some remarks:

Guile-3.0
First I compiled successfully guile-master from their repo, giving GNU
Guile 3.0.0.6-f3298
Trying to compile LilyPond with that guile (ofcourse adding a bunch of
patches) I had some problems pointing configure to the correct guile
and guile-config to the correct places. This was due to my setup with
too many guile-versions around. So I did some clean up.

LilyPond
Afterwards I've got a successful ´make´ with current LilyPond-master.
´make LANGS='' doc´ failed, though.

The problem is /input/regression/context-defaultchild-cycle.ly
I do not understand how this regtest survives any compilation.
It contains
#(ly:set-option 'warning-as-error #t)
and some
#(ly:expect-warning ...)
If I compile it, separetly I always get warnings (after disabling
'warning-as-error )
warning: default child context begins a cycle: Score
warning: cannot find or create context: Bottom
warning: default child context begins a cycle: Score
warning: cannot find or create context: Bottom
warning: 4 expected warning(s) not encountered:
default child context begins a cycle: `Score'
cannot find or create new `Bottom'
default child context begins a cycle: `Score'
cannot find or create new `Bottom'

As far as I understand it errors always.

Currently I can't test with a guile-1-build of recent master (my
mentioned cleanup was a little to thorough it seems)

Hints?


Cheers,
  Harm

Re: Context paths (and the Edition Engraver)

[David Kastrup]

Dan Eble  writes:

> On Jan 21, 2020, at 14:37, David Kastrup  wrote:
>> 
>> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
>
> OK.  It would be an understandable growth on the current face of LilyPond. :)
>
> Questions follow, but I'm not asking you to spend time investigating.
>
> Do you think we could achieve making the quotes optional for some
> simple IDs, and making the whitespace optional?
>
> StaffGroup=organ.Staff=upper.Voice.SubVoice=2

It would all be optional (except in \lyricsmode or \markup) but I am
skeptical that it would make for a great convention.

> In a situation where the user didn't care to constrain the context
> types, do you think could they be omitted, or would we have to invent
> a placeholder?
>
> =organ.=upper..=2
> X=organ.X=upper.X.X=2

I don't think that this would be a reasonable syntax.

> Maybe--MAYBE--I'm not yet advocating it, but maybe we could allow some
> ambiguity when there is no equal sign, and define how LilyPond
> resolves it; like if it is a context type then it is used as the
> context type, otherwise it is used as an ID, which would allow things
> like this:
>
> organ.upper.Voice.2

Picking this apart correctly would require knowing from the layout
definition which identifiers correspond to contexts.  That's nothing you
can do at music function execution time.  So you could check this path
for reasonability only at a rather late point of time.

Really looks too wishywashy to me to constitute a good idea.

>> Does this give us a hook into making \set, \override and/or \tempo a
>> music function in the long run?  Less than sure about that.
>> Particularly \tempo appears rather tricky.
>
> If I ever knew enough about the implementation of those to answer,
> I've forgotten it.

Hardwired in the parser.

-- 
David Kastrup

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:37, David Kastrup  wrote:
> 
> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2

OK.  It would be an understandable growth on the current face of LilyPond. :)

Questions follow, but I'm not asking you to spend time investigating.

Do you think we could achieve making the quotes optional for some simple IDs, 
and making the whitespace optional?

StaffGroup=organ.Staff=upper.Voice.SubVoice=2

In a situation where the user didn't care to constrain the context types, do 
you think could they be omitted, or would we have to invent a placeholder?

=organ.=upper..=2
X=organ.X=upper.X.X=2

Maybe--MAYBE--I'm not yet advocating it, but maybe we could allow some 
ambiguity when there is no equal sign, and define how LilyPond resolves it; 
like if it is a context type then it is used as the context type, otherwise it 
is used as an ID, which would allow things like this:

organ.upper.Voice.2

> Does this give us a hook into making \set, \override and/or \tempo a
> music function in the long run?  Less than sure about that.
> Particularly \tempo appears rather tricky.

If I ever knew enough about the implementation of those to answer, I've 
forgotten it.
— 
Dan

Re: Context paths (and the Edition Engraver)

[Carl Sorensen]

On 1/21/20, 12:32 PM, "Dan Eble"  wrote:

On Jan 21, 2020, at 14:02, Carl Sorensen  wrote:
> It seems to me that 
> 
> \context StaffGroup ID1.ID2.ID3.ID4
...
> ID4 must be a bottom context

Please guide me step by step to this conclusion.  All this example speaks 
to me is that ID4 is a great-grandchild of ID1.

You are correct, of course.

Thanks,

Carl
 

Re: Looking for help in configuring LilyDev in VirtualBox

[Peter Toye]

Tuesday, January 21, 2020, 6:24:25 PM, Michael Käppler wrote:


Am 21.01.2020 um 11:13 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox
Monday, January 20, 2020, 10:24:13 PM, you wrote:


Am 20.01.2020 um 16:04 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox
Monday, January 20, 2020, 10:26:55 AM, you wrote:


Am 20.01.2020 um 11:08 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox

Hmm...weird. Could you please check if the virtual box modules are loaded
with
lsmod | grep vbox
Which VirtualBox version do you use? What is you host OS?

lsmod gives: vboxguest2949120
There should be some more kernel modules running.
Please try reinstalling the guest additions at first with:
sudo apt install --reinstall virtualbox-guest-dkms virtualbox-guest-x11 
virtualbox-guest-utils

That didn't work: got a message:

E: Command line option 'r' [from -reinstall] is not understood in combination 
with the other options.
Seems you accidentally omitted one dash (should be --reinstall, not -reinstall)

Oops - the problems of not being able to do cut-and-paste between machines. On 
my terminal the two '-'s merged into one.

That command produced a load of output. Maybe I should have redirected it to a 
file.


Then reboot your virtual machine. If that does not work, please
post the output of

ps aux | grep '/usr/bin/VBoxClient --clipboard'

This time after the reboot I got the same result. No sharing of clipboard, no 
more processes. Tried closing VBox and restarting it, but same result.

There's one slight oddity: often (but not always) when booting the LilyDev 
guest I get an error message - a bit too long to copy the text so here's a 
screenshot:



I don't know if it's significant. It doesn't change the clipboard behaviour.



Without rebooting (there didn't seem much point) I got:

dev7010.00.011108932pts/0   
 S+11:100:00 grep /usr/bin/VBoxClient --clipboard

which I guess is the process that I just ran.


so that we can see if the shared clipboard service is running

Best regards,
Michael

All the best,

Peter

It's possible that my hamfisted attempts to install LilyDev as a guest without 
all the instructions has screwed something up. I could start again tomorrow 
using the instructions you sent me and see if it makes any difference.

Best regards,

Peter

   

Re: Context paths (and the Edition Engraver)

[David Kastrup]

Dan Eble  writes:

> On Jan 21, 2020, at 14:20, David Kastrup  wrote:
>> 
>>> Notation borrowed directly from them will not integrate well
>>> into LilyPond, but it might be fruitful to ask how we could modify
>>> expressions like these to fit in.
> ...
>> The syntax appears not to be a good match to LilyPond even though the
>> concept may be considered fitting.
>
> I'm glad you agree.

StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
#'((StaffGroup . organ) (Staff . upper) Voice (SubVoice . 2))

Does this give us a hook into making \set, \override and/or \tempo a
music function in the long run?  Less than sure about that.
Particularly \tempo appears rather tricky.

-- 
David Kastrup

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:02, Carl Sorensen  wrote:
> It seems to me that 
> 
> \context StaffGroup ID1.ID2.ID3.ID4
...
> ID4 must be a bottom context

Please guide me step by step to this conclusion.  All this example speaks to me 
is that ID4 is a great-grandchild of ID1.

Thanks and regards,
— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:20, David Kastrup  wrote:
> 
>> Notation borrowed directly from them will not integrate well
>> into LilyPond, but it might be fruitful to ask how we could modify
>> expressions like these to fit in.
...
> The syntax appears not to be a good match to LilyPond even though the
> concept may be considered fitting.

I'm glad you agree.
— 
Dan

Re: Context paths (and the Edition Engraver)

[David Kastrup]

Dan Eble  writes:

> On Jan 21, 2020, at 11:31, Jan-Peter Voigt  wrote:
>> I'd like that, though it would be a quite invasive change.
>> And if we stay with the string for the context id and then use
>> lists/paths in the \context statement like
>> \new Staff = "choir" << \new Voice = "soprano" …
>> 
>> and then use
>> \context Voice = choir.soprano
>> 
>> it would be inconsistent with \new  = "…"
>> 
>> I will write down some more text about this topic later.
>
> I see similarities with languages like CSS and XPATH select nodes in a
> DOM.  Notation borrowed directly from them will not integrate well
> into LilyPond, but it might be fruitful to ask how we could modify
> expressions like these to fit in.
>
> %% find the voice in the example quoted above, very specifically
> \context Staff#choir > Voice#soprano { … } % CSS
> \context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH
>
> %% ditto, but using context type only
> \context Staff > Voice { … }   % CSS
> \context Staff/Voice { … } % XPATH
>
> %% ditto, but using ID only
> \context #choir > #soprano { … }   % CSS
> \context [@id=choir]/[@id=soprano] { … }   % XPATH
>
> %% find the context where the rehearsalMark property is defined
> \context [rehearsalMark] { … } % CSS
> \context [@rehearsalMark] { … }% XPATH
> — 
> Dan

The syntax appears not to be a good match to LilyPond even though the
concept may be considered fitting.

-- 
David Kastrup

Re: Context paths (and the Edition Engraver)

[Kieren MacMillan]

Hi all,

> I don't think anyone was suggesting that a context ID would include the IDs 
> of its parents as a substring. At least I wasn't trying to suggest that.  The 
> idea is that something like this:
> 
>\context foo.bar.baz { … }
> 
> Could be interpreted as shorthand for this:
> 
>\context %{ unspecified %} = foo {
>  \context %{ unspecified %} = bar {
>\context %{ unspecified %} = baz { … }
>  }
>}

Exactly.
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Context paths (and the Edition Engraver)

[Kieren MacMillan]

Hi all,

> \new ChoirStaff = choir  <<
>\new Staff = choir.upper  <<
>\new Voice = choir.upper.soprano
>\new Voice = choir.upper.alto
>   >>
>   \new Staff = choir.lower <<
>\new Voice = choir.lower.tenor
>\new Voice = choir.lower.bass
>   >>
> >>

To be honest, I’d prefer

\new ChoirStaff = choir  <<
   \new Staff = upper  <<
   \new Voice = soprano
   \new Voice = alto
  >>
  \new Staff = lower <<
   \new Voice = tenor
   \new Voice = bass
  >>
>>

though I understand that such a situation could introduce potential 
complexities (impossibilities?) once a score has more contexts [esp. of the 
same type] than what’s in that simple example.

> It seems to me that 
> \context StaffGroup ID1.ID2.ID3.ID4
> (where StaffGroup ID1 exists)
> Should find StaffGroup ID1, then find a child context ID2 of StaffGroup ID1,
> Then find a child context ID3 of ID2,
> Then find a child context ID4 of ID3.

Hmmm… I would have thought the opposite: that it would [try to] find the 
StaffGroup which has ID4 as its identifier and which is the child of the 
context [of unknown type?] which has ID1.ID2.ID3 as its identifier/path. Am I 
the only one who thinks that way?

For my information: Does the alternative form

\context "StaffGroup ID1".ID2.ID3.ID4

accurately/fairly represent how your suggestion is constructed?

> I think that we must consider all of the possibilities currently in lilypond 
> before changing to this form of notation. I personally find the lilypond 
> concept that voices exist independently of staves although they are always 
> expressed in a staff at any point in time to be far more powerful than the 
> MusicXML concept that voices exist in staves.

I totally agree.

Cheers,
Kieren.

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:02, Carl Sorensen  wrote:
> \new ChoirStaff = choir  <<
>\new Staff = choir.upper  <<
>\new Voice = choir.upper.soprano
>\new Voice = choir.upper.alto
>>> 
>   \new Staff = choir.lower <<
>\new Voice = choir.lower.tenor
>\new Voice = choir.lower.bass
>>> 
>>> 
> 
> Or would we prefer
> 
> \new ChoirStaff = choir  <<
>\new Staff = choir.upper  <<
>\new Voice = choir.soprano
>\new Voice = choir.alto
>>> 
>   \new Staff = choir.lower <<
>\new Voice = choir.tenor
>\new Voice = choir.bass
>>> 
>>> 
> 
> The first example is potentially problematic, because Voices can change 
> Staffs (and even StaffGroups), so it seems that having the Voice id include 
> the Staff is not desirable.

I don't think anyone was suggesting that a context ID would include the IDs of 
its parents as a substring.  At least I wasn't trying to suggest that.  The 
idea is that something like this:

\context foo.bar.baz { … }

Could be interpreted as shorthand for this:

\context %{ unspecified %} = foo {
  \context %{ unspecified %} = bar {
\context %{ unspecified %} = baz { … }
  }
}

— 
Dan

Re: Context paths (and the Edition Engraver)

[Carl Sorensen]

On 1/21/20, 11:19 AM, "lilypond-devel on behalf of Dan Eble" 
 wrote:

On Jan 21, 2020, at 11:31, Jan-Peter Voigt  wrote:
> 
> \context Voice = choir.soprano
> 
> it would be inconsistent with \new  = "…"

The implied example

   \new Voice = choir.soprano { … }

could be given a consistent interpretation.  For example, it could be 
interpreted as creating \new Voice = soprano { … } within an existing-or-new 
context of unspecified type and ID "choir".

If we decide what we want from \context first, it will probably be pretty 
obvious how \new should work.


\new ChoirStaff = choir  <<
\new Staff = choir.upper  <<
\new Voice = choir.upper.soprano
\new Voice = choir.upper.alto
>>
   \new Staff = choir.lower <<
\new Voice = choir.lower.tenor
\new Voice = choir.lower.bass
   >>
>>

Or would we prefer

\new ChoirStaff = choir  <<
\new Staff = choir.upper  <<
\new Voice = choir.soprano
\new Voice = choir.alto
>>
   \new Staff = choir.lower <<
\new Voice = choir.tenor
\new Voice = choir.bass
   >>
>>

The first example is potentially problematic, because Voices can change Staffs 
(and even StaffGroups), so it seems that having the Voice id include the Staff 
is not desirable.

Our current \change Staff command does a find such that it will find the staff 
in the current StaffGroup if it exists, and if not it will look in other 
StaffGroups.

\version "2.19.83"

\new StaffGroup <<
  \new ChoirStaff = "choir" <<
\new Staff = "ch_upper" <<
  \new Voice = "soprano" {
\voiceOne
a' b' c'' d''
  }
  \new Voice = "alto" {
\voiceTwo
f' g' \change Staff ="ch_lower" a' b'
   % f' g' \change Staff ="LH" a' b'
  }
>>
\new Staff = "ch_lower" <<
  \new Voice = "tenor" {
\voiceOne 
s1
  }
  \new Voice = "bass" {
\voiceTwo 
s1
  }
>>
  >>
  \new PianoStaff = "piano" <<
\new Staff = "ch_lower" <<
   \new Voice = "soprano" {
  c4 d e f
   }
>>
\new Staff = "LH" <<
  \new Voice = "bass" {
\voiceTwo
a4 b \change Staff = "ch_lower" c d
  }
>>
  >>
>>


It seems to me that 

\context StaffGroup ID1.ID2.ID3.ID4

(where StaffGroup ID1 exists)

Should find StaffGroup ID1, then find a child context ID2 of StaffGroup ID1,
Then find a child context ID3 of ID2,
Then find a child context ID4 of ID3.

In this particular example, ID2 must be some form of a StaffGroup, IIUC, 
because ID4 must be a bottom context, and ID3 must be a context that takes a 
bottom context (e.g. Staff or TabStaff), and ID2 must be a context that takes a 
Staff (e.g StaffGroup, ChoirStaff, PianoStaff).

I think that we must consider all of the possibilities currently in lilypond 
before changing to this form of notation.  I personally find the lilypond 
concept that voices exist independently of staves although they are always 
expressed in a staff at any point in time to be far more powerful than the 
MusicXML concept that voices exist in staves.

Thanks,

Carl
 

Re: Janek is coming back to LilyPond! :-)

[Kieren MacMillan]

Hi Janek,

1. Wonderful to have you back!
2. There’s this lyrics thing maybe you could take a look at…?  ;)

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Looking for help in configuring LilyDev in VirtualBox

[Michael Käppler]

Am 21.01.2020 um 11:13 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox Monday,
January 20, 2020, 10:24:13 PM, you wrote:


Am 20.01.2020 um 16:04 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox

Monday, January 20, 2020, 10:26:55 AM, you wrote:


Am 20.01.2020 um 11:08 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox


Hmm...weird. Could you please check if the virtual box modules are loaded
with
lsmod | grep vbox
Which VirtualBox version do you use? What is you host OS?

lsmod gives: vboxguest        294912        0
There should be some more kernel modules running.
Please try reinstalling the guest additions at first with:
sudo apt install --reinstall virtualbox-guest-dkms
virtualbox-guest-x11 virtualbox-guest-utils

That didn't work: got a message:

E: Command line option 'r' [from -reinstall] is not understood in
combination with the other options.

Seems you accidentally omitted one dash (should be --reinstall, not
-reinstall)


Then reboot your virtual machine. If that does not work, please
post the output of

ps aux | grep '/usr/bin/VBoxClient --clipboard'

Without rebooting (there didn't seem much point) I got:

dev        701        0.0        0.0        11108        932  pts/0  
     S+        11:10        0:00 grep /usr/bin/VBoxClient --clipboard

which I guess is the process that I just ran.


so that we can see if the shared clipboard service is running

Best regards,
Michael

All the best,

Peter

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 11:31, Jan-Peter Voigt  wrote:
> 
> \context Voice = choir.soprano
> 
> it would be inconsistent with \new  = "…"

The implied example

   \new Voice = choir.soprano { … }

could be given a consistent interpretation.  For example, it could be 
interpreted as creating \new Voice = soprano { … } within an existing-or-new 
context of unspecified type and ID "choir".

If we decide what we want from \context first, it will probably be pretty 
obvious how \new should work.
— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 11:31, Jan-Peter Voigt  wrote:
> I'd like that, though it would be a quite invasive change.
> And if we stay with the string for the context id and then use
> lists/paths in the \context statement like
> \new Staff = "choir" << \new Voice = "soprano" …
> 
> and then use
> \context Voice = choir.soprano
> 
> it would be inconsistent with \new  = "…"
> 
> I will write down some more text about this topic later.

I see similarities with languages like CSS and XPATH select nodes in a DOM.  
Notation borrowed directly from them will not integrate well into LilyPond, but 
it might be fruitful to ask how we could modify expressions like these to fit 
in.

%% find the voice in the example quoted above, very specifically
\context Staff#choir > Voice#soprano { … } % CSS
\context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH

%% ditto, but using context type only
\context Staff > Voice { … }   % CSS
\context Staff/Voice { … } % XPATH

%% ditto, but using ID only
\context #choir > #soprano { … }   % CSS
\context [@id=choir]/[@id=soprano] { … }   % XPATH

%% find the context where the rehearsalMark property is defined
\context [rehearsalMark] { … } % CSS
\context [@rehearsalMark] { … }% XPATH
— 
Dan

Re: Context paths (and the Edition Engraver)

[Kieren MacMillan]

Hi Carl,

> All of this discussion about including the edition engraver and packages in 
> LilyPond core is exciting to me.

+1

> I think that if we choose to do so, it should represent a major release for 
> LilyPond, i.e. it should become LilyPond 3.0

If we really get a great extension/package management system rolled in (even if 
the EE itself remains "outside" the core), I would definitely vote for 
incrementing the major version number.

> it's possible that we will have some NOT_SMART convert.ly rules connected to 
> the major release; users would potentially need to hand-code changes.

We should, of course, try to avoid that entirely where possible, and mitigate 
it otherwise.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Context paths (and the Edition Engraver)

[Kieren MacMillan]

Hi Jan-Peter,

>> Not sure how much of a "crowd" we are…  ;)
> at least we are 2 :)

Well, how many more until we gain official "crowd" status?  =)

>> I agree on both points. (Perhaps one of my first contributions in 2020 
>> should be a less-ambiguous set of documented examples for the EE?)
> that would of course be helpful, because my examples will always along
> my development ideas and not along a foreign users view ...

I’ll put it on my list. I’m wanting things to do with all this inspired energy, 
but real development should (I believe) wait until after any big "process" 
changes are complete… so I’m left with (1) learning Scheme, and (2) 
documentation and examples.

>>   \editionMod my-edition 10 1/4 id-to-a-staff.Score \override …
> this works? I thought you'D need
>   \editionMod my-edition 10 1/4 id-to-a-staff \override Score.…

You are correct — apologies for my jet-lag-brain noise.

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

PATCHES - Countdown for January 21st

[pkx166h]

Hello,

Here is the current patch countdown list. The next countdown will be on
January 23rd.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/




  Push:

5663 Encoding preparations for Python 3.5 - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5663
http://codereview.appspot.com/551340043

5660 Doc: Added documentation for fill-line line-width - davidsg
https://sourceforge.net/p/testlilyissues/issues/5660
http://codereview.appspot.com/583340043

5654 Cleanup initialization of configure process - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5654
http://codereview.appspot.com/549350043


  Countdown:

5665 Remove broken and undocumented tracing features - Jonas Hahnfeld
https://sourceforge.net/p/testlilyissues/issues/5665
http://codereview.appspot.com/577320043


  Review:

5676 remove obsolete lines from lily-guile-macros.hh - hanwen
https://sourceforge.net/p/testlilyissues/issues/5676
http://codereview.appspot.com/555170043

5675 Document C++ structs for slur scoring - hanwen
https://sourceforge.net/p/testlilyissues/issues/5675
http://codereview.appspot.com/571380043

5674 document and test slur score debugging - hanwen
https://sourceforge.net/p/testlilyissues/issues/5674
http://codereview.appspot.com/555160043

5673 Remove implicit evaluation of the ".twy" file - hanwen
https://sourceforge.net/p/testlilyissues/issues/5673
http://codereview.appspot.com/551380043

5672 Clean up and document include file searching - hanwen
https://sourceforge.net/p/testlilyissues/issues/5672
http://codereview.appspot.com/573400043

5671 lily/page-breaking: pass vector by reference - hanwen
https://sourceforge.net/p/testlilyissues/issues/5671
http://codereview.appspot.com/581510043

5670 lily: fix some type conversion warnings - hanwen
https://sourceforge.net/p/testlilyissues/issues/5670
http://codereview.appspot.com/557190043

5669 Document why System::rank_type is int16 - hanwen
https://sourceforge.net/p/testlilyissues/issues/5669
http://codereview.appspot.com/559370043

5668 Documentation: fix typo in German spacing.itely file - hanwen
https://sourceforge.net/p/testlilyissues/issues/5668
http://codereview.appspot.com/581490043

5667 Documentation: fix typos in tool naming - hanwen
https://sourceforge.net/p/testlilyissues/issues/5667
http://codereview.appspot.com/581480043

5666 ly_scm_write_string: call scm_write directly - hanwen
https://sourceforge.net/p/testlilyissues/issues/5666
http://codereview.appspot.com/545450043


  New:

No new patches at this time.



***


Regards,

James

Re: Context paths (and the Edition Engraver)

[Carl Sorensen]

On 1/19/20, 2:42 PM, "lilypond-devel on behalf of Dan Eble" 
 wrote:

One of the things in Kieren's intro to the Edition Engraver (EE) that 
resonated with me was the context paths.  His example was something like 
`singwithbach.along.Voice.B`, which was supposed to refer to something like 
this:

  \context Staff = "along" {
\context Voice = "B" {
  ...
}
  }

The ability to refer to contexts this way is a great idea, though IMHO it 
needs some work to reduce ambiguity.  But the point I came here to make is 
this: if an EE using a similar syntax is ever to be a part of LilyPond proper, 
the syntax ought to be consistently supported for other LilyPond commands that 
refer to contexts.  For example,

  \context along.Voice.B { ... }

  \set along.Voice.B.property = #...

  \change Voice = ChoirStaff.A.Staff.B

It would be wise to ask whether there are use cases for any "pronouns" 
(like `.` and `..` in file paths, and `this` in C++) to make it possible to 
root a search very specifically.  The existence of the `descend-only` music 
property suggests that there might be.  I also think I have a pretty good use 
case for finding "the closest enclosing context where a given property is 
defined," but I am not now prepared to elaborate.



All of this discussion about including the edition engraver and packages in 
LilyPond core is exciting to me.

I think that if we choose to do so, it should represent a major release for 
LilyPond, i.e. it should become LilyPond 3.0.  And it's possible that we will 
have some NOT_SMART convert.ly rules connected to the major release; users 
would potentially need to hand-code changes.

Thanks,

Carl
 

Re: Context paths (and the Edition Engraver)

[Jan-Peter Voigt]

Hi there,

> [Single-level quotes are David Kastrup’s; double-level quotes are Dan Eble’s.]
>
>> Comments from the EE crowd?
>
> Not sure how much of a "crowd" we are…  ;)
at least we are 2 :)


>>> One of the things in Kieren's intro to the Edition Engraver (EE) that 
>>> resonated with me was the context paths.
> […]
>>> The ability to refer to contexts this way is a great idea, though IMHO it 
>>> needs some work to reduce ambiguity.
>
> I agree on both points. (Perhaps one of my first contributions in 2020 should 
> be a less-ambiguous set of documented examples for the EE?)
that would of course be helpful, because my examples will always along
my development ideas and not along a foreign users view ...

>>>  \context along.Voice.B { ... }
>>>  \set along.Voice.B.property = #...
>>>  \change Voice = ChoirStaff.A.Staff.B
>
> An interesting proposal.
I'd like that, though it would be a quite invasive change.
And if we stay with the string for the context id and then use
lists/paths in the \context statement like
\new Staff = "choir" << \new Voice = "soprano" …

and then use
\context Voice = choir.soprano

it would be inconsistent with \new  = "…"

I will write down some more text about this topic later.

>> I think that this would warrant closely analysing what the EE does and
>> checking whether its way of specifying things is a natural match to what
>> might be useful with LilyPond, or at least can be made so without
>> impacting its usefulness.
>
> Agreed.
>
> Perhaps instead of the current
>
>\new Staff = "piano_upper"
>
> mechanism, we could have a
>
>\new Staff piano.upper
Though I'd like such a scheme, I'd not recommend it, because I see
breaking changes coming up ;)


> "id" that could be used for addressing by both Lilypond proper *and* the EE 
> [or any other extension/addon]? Other than the obvious coding requirement to 
> make the switch, is there any real impact on Lilypond itself switching from 
> '= "name"' syntax to 'name' syntax? Even if Lilypond didn’t yet 
> recognize/react to a path like "score.ps.piano.upper.Voice.A" (the way the EE 
> already does), such a change would at least align the two 
> labelling/addressing methods.
>
> Alternatively, we could consider changing the EE to do addressing the way 
> it’s done in Lilypond proper… but I feel like that would be a step backwards.
>
>>> It would be wise to ask whether there are use cases
>>> for any "pronouns" (like `.` and `..` in file paths, and `this`
The dots are from the dot-notation of lists. If you type

lst = "..".hui.buh
#(display lst)

you can see that `lst` is a list with symbols #'(.. hui buh)

In my templates package I have function to canonicalize such paths. I
will import that to the EE.

> Interesting… Because of the way timing works (or, in this case, doesn’t!) in 
> the EE, I sometimes have to write (e.g.)
>
>\editionMod my-edition 10 1/4 id-to-a-staff.Score \override …
this works? I thought you'D need
   \editionMod my-edition 10 1/4 id-to-a-staff \override Score.…


I hope to work on the discussed topics soon, but my desktop is stuffed ...

It was an amzing weekend! Thank you all :)

Jan-Peter

Re: packaging lilypond as a docker container?

[Michael Käppler]

Would be happy to try the Dockerfile, since I've never used Docker
before and find
the concept interesting.
Could you push your changes to your LilyDev fork and/or file a pull
request against
Federico's repo?

Cheers,
Michael

Am 21.01.2020 um 16:47 schrieb Dan Eble:

On Jan 20, 2020, at 18:21, Karlin High  wrote:

There already is a LilyDev Docker image.



I tried it once, but was unable to get it working. It was my first and only 
experience with Docker, so that's probably my fault. I was also unmotivated to 
persevere . . .

I'm the original author and de-facto maintainer of that Dockerfile.  I assume 
I'm also the sole user, based on the lack of questions about it.

My experience is that it's more stable than VirtualBox, and I can more easily 
keep my source backed up (because it's in my host filesystem, not the VM 
filesystem), but the performance of accessing the host filesystem is mightily 
disappointing (unlike on Linux hosts).

If anyone is reading this and thinking of trying it, you might be better off 
encouraging me to publish some of the private changes I've been testing, rather 
than trying what's in Federico's repo.  I tend to slack off in that regard 
because no one is asking.
—
Dan

Re: packaging lilypond as a docker container?

[Dan Eble]

On Jan 20, 2020, at 18:21, Karlin High  wrote:
> 
> There already is a LilyDev Docker image.
> 
> 
> 
> I tried it once, but was unable to get it working. It was my first and only 
> experience with Docker, so that's probably my fault. I was also unmotivated 
> to persevere . . .

I'm the original author and de-facto maintainer of that Dockerfile.  I assume 
I'm also the sole user, based on the lack of questions about it.

My experience is that it's more stable than VirtualBox, and I can more easily 
keep my source backed up (because it's in my host filesystem, not the VM 
filesystem), but the performance of accessing the host filesystem is mightily 
disappointing (unlike on Linux hosts).

If anyone is reading this and thinking of trying it, you might be better off 
encouraging me to publish some of the private changes I've been testing, rather 
than trying what's in Federico's repo.  I tend to slack off in that regard 
because no one is asking.
— 
Dan

Re: github mirror of lilypond?

[Werner LEMBERG]

> A problem with the policy "trivial things can just be pushed" is
> that "trivial" is open for interpretation.

Of course, but this shouldn't be a hindrance.

> Even a change that was intended to affect only comments could have a
> bad impact if, say, it inserts an accidental stray character and is
> not tested sufficiently.

I think that the benefit of having the stuff immediately in the
repository outweights the potential danger of breaking compilation.
Usually, a hotfix is a matter of seconds.

> James' report demonstrates that even if multiple devs agree that a
> change is trivial, it should still be tested before being pushed.

Well, this particular issue was *not* tagged as trivial, since it adds
a new regtest.


Werner

Re: github mirror of lilypond?

[David Kastrup]

Dan Eble  writes:

> On Jan 20, 2020, at 11:51, pkx1...@posteo.net wrote:
>> 
>> On 20/01/2020 16:16, Werner LEMBERG wrote:
 Trivial things from a developer with push access can be just pushed.
 Complex or otherwise contential things warrant a chance for
 developers to take a look at it.  "Half a chance" seems an
 unnecessary complication.
>>> Anyway, I was misled.  Han-Wen actually *did* create proper SF issues,
>>> which I seem to have missed because the gnu.org mailer had again
>>> delays, delivering messages in time-reversed order.
>>> 
>>> 
>>>Werner
>>> 
>> and on of them doesn't 'make/make test-baseline'.
>
>
> A problem with the policy "trivial things can just be pushed" is that
> "trivial" is open for interpretation.  Even a change that was intended
> to affect only comments could have a bad impact if, say, it inserts an
> accidental stray character and is not tested sufficiently.
>
> James' report demonstrates that even if multiple devs agree that a
> change is trivial, it should still be tested before being pushed.

It's worth noting that our staging/master setup means that changes _are_
tested before being ultimately pushed to the major work resource for
developers.  If this blows up, it blocks the staging pipeline.  With our
current rate of commits and staging tests, disentangling this tends to
be comparatively benign.

As long as nothing, however trivial, gets pushed to master without
testing, the consequences are at least kept in check mostly.

-- 
David Kastrup

Re: Document C++ structs for slur scoring (issue 571380043 by hanw...@gmail.com)

[nine . fierce . ballads]

LGTM.  Thanks.

https://codereview.appspot.com/571380043/

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/557190043/diff/581490044/lily/pointer-group-interface.cc
File lily/pointer-group-interface.cc (right):

https://codereview.appspot.com/557190043/diff/581490044/lily/pointer-group-interface.cc#newcode30
lily/pointer-group-interface.cc:30: return arr ? int (arr->size ()) : 0;
MHO: Return a vsize.  Somewhere, sometime, someone will probably say,

my_things_.size () < pgi.count ()

and the compiler will warn about comparing int to size_t.

I don't suggest that you switch to vsize and ferret out all the
consequences at this time if you don't want to invest your time in that,
but that it's better to leave this line alone and live with the warning
until there is time to take a proper look.

https://codereview.appspot.com/557190043/diff/581490044/lily/quote-iterator.cc
File lily/quote-iterator.cc (right):

https://codereview.appspot.com/557190043/diff/581490044/lily/quote-iterator.cc#newcode104
lily/quote-iterator.cc:104: int hi = int (scm_c_vector_length (vec));
If scm_c_vector_length () is returning size_t, then why don't we work in
terms of size_t?  Any place I see a cast, especially a C-style cast, I
feel the urge to stop and ask, "Why is this OK?"  So I'd rather not see
them where they can be avoided.

https://codereview.appspot.com/557190043/diff/581490044/lily/stem.cc
File lily/stem.cc (right):

https://codereview.appspot.com/557190043/diff/581490044/lily/stem.cc#newcode94
lily/stem.cc:94: int len = int (scm_ilength (lst)); // -1 for dotted
lists!
ditto

https://codereview.appspot.com/557190043/

Re: document and test slur score debugging (issue 555160043 by hanw...@gmail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/555160043/diff/577340043/input/regression/slur-inspect-quants.ly
File input/regression/slur-inspect-quants.ly (right):

https://codereview.appspot.com/555160043/diff/577340043/input/regression/slur-inspect-quants.ly#newcode3
input/regression/slur-inspect-quants.ly:3: texidoc = "This file
demonstrates the slur scoring debug functionality"
What is the expected result?  Is the visual output important?  Is it
enough that this doesn't crash?  These are questions I would ask if this
case appeared in my regtest diffs.

https://codereview.appspot.com/555160043/

Re: packaging lilypond as a docker container?

[Kevin Barry]

On Mon, Jan 20, 2020 at 10:05:23PM +, Carl Sorensen wrote:
> 
> Wouldn't it be much more simple to build lilypond as a Docker application?
> 
> I don't know anything about building lilypond as a Docker application.  If it 
> were possible to execute a docker application from the command line in MacOS, 
> then I think that would meet my requirements.  I need to be able to have 
> multiple binaries installed so that I can run multiple versions from 
> Frescobaldi.

Running docker on MacOS requires a virtual machine running Linux. The
Docker for desktop app for MacOS hides that detail away from the user
for the most part.

It is technically possible to do what you want (make it so Frescobaldi
can call multiple versions of LilyPond) with docker, but there would be
some work involved: you'd probably need to have one-liner shell scripts
for each version of LilyPond that execute the relevant container.

Re: github mirror of lilypond?

[Dan Eble]

On Jan 20, 2020, at 11:51, pkx1...@posteo.net wrote:
> 
> On 20/01/2020 16:16, Werner LEMBERG wrote:
>>> Trivial things from a developer with push access can be just pushed.
>>> Complex or otherwise contential things warrant a chance for
>>> developers to take a look at it.  "Half a chance" seems an
>>> unnecessary complication.
>> Anyway, I was misled.  Han-Wen actually *did* create proper SF issues,
>> which I seem to have missed because the gnu.org mailer had again
>> delays, delivering messages in time-reversed order.
>> 
>> 
>>Werner
>> 
> and on of them doesn't 'make/make test-baseline'.


A problem with the policy "trivial things can just be pushed" is that "trivial" 
is open for interpretation.  Even a change that was intended to affect only 
comments could have a bad impact if, say, it inserts an accidental stray 
character and is not tested sufficiently.

James' report demonstrates that even if multiple devs agree that a change is 
trivial, it should still be tested before being pushed.
— 
Dan

Re: Clean up and document include file searching (issue 573400043 by hanw...@gmail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/573400043/diff/549420043/lily/sources.cc
File lily/sources.cc (right):

https://codereview.appspot.com/573400043/diff/549420043/lily/sources.cc#newcode60
lily/sources.cc:60: Sources::find_full_path(string file_string, string
const _dir)
Is there any reason not to make this const?

https://codereview.appspot.com/573400043/

Re: github mirror of lilypond?

[Dan Eble]

On Jan 20, 2020, at 11:40, Carl Sorensen  wrote:
> I agree.  And while comments during countdown are annoying and frustrating, 
> it's even more annoying and frustrating to have a commit reverted.  So I 
> prefer countdown to reversion.

+1
— 
Dan

Re: Context paths (and the Edition Engraver)

[Kieren MacMillan]

Hi all,

[Single-level quotes are David Kastrup’s; double-level quotes are Dan Eble’s.]

> Comments from the EE crowd?

Not sure how much of a "crowd" we are…  ;)

>> One of the things in Kieren's intro to the Edition Engraver (EE) that 
>> resonated with me was the context paths.
[…]
>> The ability to refer to contexts this way is a great idea, though IMHO it 
>> needs some work to reduce ambiguity.

I agree on both points. (Perhaps one of my first contributions in 2020 should 
be a less-ambiguous set of documented examples for the EE?)

>>  \context along.Voice.B { ... }
>>  \set along.Voice.B.property = #...
>>  \change Voice = ChoirStaff.A.Staff.B

An interesting proposal. 

> I think that this would warrant closely analysing what the EE does and
> checking whether its way of specifying things is a natural match to what
> might be useful with LilyPond, or at least can be made so without
> impacting its usefulness.

Agreed.

Perhaps instead of the current 

   \new Staff = "piano_upper"

mechanism, we could have a

   \new Staff piano.upper

"id" that could be used for addressing by both Lilypond proper *and* the EE [or 
any other extension/addon]? Other than the obvious coding requirement to make 
the switch, is there any real impact on Lilypond itself switching from '= 
"name"' syntax to 'name' syntax? Even if Lilypond didn’t yet recognize/react to 
a path like "score.ps.piano.upper.Voice.A" (the way the EE already does), such 
a change would at least align the two labelling/addressing methods.

Alternatively, we could consider changing the EE to do addressing the way it’s 
done in Lilypond proper… but I feel like that would be a step backwards.

>> It would be wise to ask whether there are use cases
>> for any "pronouns" (like `.` and `..` in file paths, and `this`

Interesting… Because of the way timing works (or, in this case, doesn’t!) in 
the EE, I sometimes have to write (e.g.)

   \editionMod my-edition 10 1/4 id-to-a-staff.Score \override …

because addressing the Score directly doesn’t work at that moment. I suppose 
this would be a possible place for "addressing pronouns" and the like.

> we don't want subtly different and/or less than useful semantics.

Agreed.

>> I also think I have a pretty good use case for finding "the closest
>> enclosing context where a given property is defined,"

I believe I could imagine a lot of such use cases.  =)

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Option handling

[Urs Liska]

We have discussed options already on a conceptual level as "package
options", but technically it should be dealt with separately.

Options are not functionally required for the package loading to work,
but they are an integral part of the functionality, and I have found
that their availability has increased my ability to create
infrastructures and "user interfaces" fundamentally/exponentially.
Options are also useful as a low level building block, and I often load
oll-core just for having them available. So I suggest implementing the
option handling as the first step of the extension mechanism so it's in
place when starting on the packages.

The current implementation in oll-core is pretty powerful but it also
has fundamental flaws. Therefore you *can* look up the implementation
at 
https://github.com/openlilylib/oll-core/blob/master/internal/options.ily
but I suggest not to do so and keep the conversation on the conceptual
level like we have so far done with the package mechanism itself.
Eventually it should be coded newly from scratch.


## Interface

The basic interface is to specify an option with

  \registerOption package.component.some.path 

then retrieve the value with

  \getOption package.component.some.path

or change it with

  \setOption package.component.some.path 

Today I'm missing one feature: specifying (and enforcing) an optional
type to the value. This is not something I considered undoable, I just
haven't got around giving it a serious shot. An issue with that is that
I'm pretty sure that the underlying data structure is not ideal and
should be redesigned from scratch (see below), which made me less eager
to patch around with the typing.

There are convenience functions to set and get child options, useful
for iterating over a list of (generated) properties (e.g a list of
provided colors or all files in a directory).

There are also variants of the getter functions ...WithFallback in case
an option is "empty". But I think now this would better be handled with
an optional "default" argument to the normal function.

In the current implementation a package has to make sure itself that
the \registerOption is done before possibly given options are
evaluated. There should be a mechanism/interface to make that
straightforward for package authors.


## Command line options

Option should also be settable through the command line invocation so
it is possible to make use of them from outside (i.e. in invocation
scripts or the Frescobaldi/Emacs).

What I have done so far in projects is simply use a -d option, ignore
the warning about the unknown option and look for that option within,
and look for the option when needed. Actually we do this with
Frescobaldi's Layout Control Options as well, and I'm surprised that
noone has complained about the "warning: no such internal option: ..."
yet.

Of course when reading the command line there is no notion of loaded
packages, so what I think would be necessary is a new command line
option that takes a key=value argument and stores it in an independent
flat alist. That might then look like

  #'((scholarly.annotate.use-colors . #t)
 (stylesheets.base . "my-house-style"))

\usepackage (or whatever) will then check whether options for the given
package are present in the command line *and* registered in the
package.

I'm not sure if there are security issues to be considered beyond
executing LilyPond in the first place.


## Option definition

oll-core abuses the ly:context-mod? implementation for its option
interface. For example critical remarks can be entered with
scholarly.annotate like this:

  \criticalRemark "e' in manuscript" es'

or

  \criticalRemark \with {
message = "e' in manuscript"
item = Accidental
  } es'

I like this very much as a user interface because it is both powerful
and expressive. However it is clearly an abuse:

 * the predicate ly:context-mod? clearly refers to something
   fundamentally different
 * message = "e' in manuscript" is not represented as a pair but rather
   as '(assign item Accidental)

I have written convenience functions to create an alist from the
expression, and Stefano Troncaro has done an amazing job making the
configuration flexible and robust, for example with enforcing types and
providing defaults. However, when included in LilyPond itself it would
clearly be good to have a native implementation.

>From what I can see this should be a new predicate, say ly:options? and
a parser item that works like the above but with a different keyword.
If this suggestion is agreed upon we should discuss the details
separately.


## Data Structure

Currently oll-core maintains one single nested alist for storing
options which is accessed by the getter and setter functions. The
rationale was to pollute the namespace with only one single variable
oll-options that could be considered "pretty" safe by the prefix. Now I
think the data structure(s) holding the options would better be hidden
inside a Scheme module  

Re: Document C++ structs for slur scoring (issue 571380043 by hanw...@gmail.com)

[Urs Liska]

Am Dienstag, den 21.01.2020, 03:56 -0800 schrieb lemzwerg--- via
Discussions on LilyPond development:
> Very nice, thanks!
> 
> https://codereview.appspot.com/571380043/
> 

I've only looked at it cursorily, but I think this is really a step in
the right direction (even if it may feel like the drop in the desert).
Also, renaming cryptic variables to still-short-but-digestible names is
a valuable help when looking at these files.

Urs

Re: packaging lilypond as a docker container?

[Werner LEMBERG]

> Almost exactly a year ago, there was a sizable "Please test gub"
> effort initiated by Knut Petersen.

By the way: Any idea what has happened with Knut?  He doesn't respond
even to private e-mails since a few months...


Werner

Document C++ structs for slur scoring (issue 571380043 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

Very nice, thanks!

https://codereview.appspot.com/571380043/

Re: remove obsolete lines from lily-guile-macros.hh (issue 555170043 by hanw...@gmail.com)

[dak]

LGTM

https://codereview.appspot.com/555170043/

Re: packaging lilypond as a docker container?

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 21.01.2020, 11:28 +0100 schrieb David Kastrup:
>> 
>> Windows really is the elephant in the room.  MacOSX will cater with
>> native port systems like MacPorts etc and other UNIX-like systems
>> also have working packagers and package systems.
>
> So if I provided a working script to build a zip file for Windows,
> would you be ok with switching away from GUB?

We'd want an actual installer.  That's what the average user can work
with.  Alternatively, get the Frescobaldi people to take over
installation from a zip file and make Frescobaldi our "installer" (and
ask them to make the result useable also without Frescobaldi).  That
introduces a dependency I personally would consider a nuisance, but the
installer is intended for people with little comfort navigating command
lines and picking installation places and options, and most will end up
using Frescobaldi anyway.

> In that case I just noticed that I missed one character in my message:
>> I'm not going to tackle this until we've switched to Python *3*:
>> Then we can just use the embeddable zip file provided by the Python
>> project without bothering with cross-compilation for this beast.
>> Everything else (Guile etc.) worked without problems in my early tests.

If it ends up as "just install Python according to instructions", it's
sort of a real obstacle compared to an all-in-one installer.

-- 
David Kastrup

Re: packaging lilypond as a docker container?

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Dienstag, den 21.01.2020, 11:28 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Dienstag, den 21.01.2020, 02:38 -0600 schrieb Karlin High:
> > > On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote:
> > > > if GUB is used, who is maintaining and/or working on it?
> > > 
> > > Almost exactly a year ago, there was a sizable "Please test gub" effort 
> > > initiated by Knut Petersen.
> > > 
> > > <
> > > https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html
> > > 
> > > 
> > > Clear instructions were given for exactly how to test GUB, and just that 
> > > thread seems to have involved about 16 people.
> > > 
> > > More recently, it looks like Jonas Hahnfeld's work with Python 3 
> > > migration involved quite a number of changes to GUB.
> > 
> > Yep, and it's not been a very pleasant experience. To be precise here:
> > It's not about porting GUB to Python 3, it's just that porting LilyPond
> > will introduce a dependency on an updated package for the next release.
> > So while David is mostly correct that contributors don't need to bother
> > with GUB, that doesn't hold true once you want to bump one of its
> > dependencies...
> > 
> > Based on this experience, I've thought about how to improve the process
> > of building binary releases for LilyPond. What I have been
> > experimenting with is a set of portable shell scripts that build mostly
> > static executables. I've a prototype ready at 
> > https://github.com/hahnjo/lilypond-binaries
> >  which works for Linux and
> > FreeBSD. I don't see a reason it cannot work on macOS, but I don't have
> > the possibility to test...
> 
> The problem is "on macOS" since current macOSX library/toolbox licenses
> all prohibit use in cross-building environments.  It looks like a given
> that we will not be able to offer macOSX libraries in future as the
> result of a unified release process.  Our sources build reasonably well
> that macOSX integrators using some of the macOSX typical packaging
> systems are able to provide reasonable replacements.
> 
> But the elephant in the room is Windows.  Han-Wen says he never wants to
> touch GUB again (and he actually didn't as far as I remember) but I
> don't want to touch Windows again, and GUB provides them.  The
> dependency nightmare on a non-UNIX like platform was what brought GUB
> into being in the first place: native builds are much more of an ongoing
> problem.  Just look at the continuous effort the Git project has in
> keeping a Windows version available.
> 
> > >  From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with 
> > > something based on Guix.
> > > 
> > > <
> > > https://lists.gnu.org/archive/html/lilypond-user/2016-09/msg00690.html
> > > 
> > > 
> > > That idea was mentioned a few times since, but I can't recall if 
> > > GUB-replacement discussions have moved beyond that or not.
> > 
> > As far as I understand, Guix is a package manager in the first place.
> > In the thread Jan proposes to use it for cross-compilation, which I
> > think is the primary reason for the complexity in GUB. So why go that
> > route once more?
> > Instead I designed the mentioned scripts such that they produce native
> > executables. That's also how TeXlive builds their packages, for
> > example, and it works quite well if you compile on the oldest OS that
> > you intend to support (CentOS 7, FreeBSD 11).
> > 
> > I haven't decided yet how to compile for Windows. Maybe that's still a
> > valid use case for cross-compilation (but only with a very limited
> > scope).
> 
> Windows really is the elephant in the room.  MacOSX will cater with
> native port systems like MacPorts etc and other UNIX-like systems also
> have working packagers and package systems.

So if I provided a working script to build a zip file for Windows,
would you be ok with switching away from GUB?

In that case I just noticed that I missed one character in my message:
> I'm not going to tackle this until we've switched to Python *3*:
> Then we can just use the embeddable zip file provided by the Python
> project without bothering with cross-compilation for this beast.
> Everything else (Guile etc.) worked without problems in my early tests.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: packaging lilypond as a docker container?

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 21.01.2020, 02:38 -0600 schrieb Karlin High:
>> On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote:
>> > if GUB is used, who is maintaining and/or working on it?
>> 
>> Almost exactly a year ago, there was a sizable "Please test gub" effort 
>> initiated by Knut Petersen.
>> 
>> <
>> https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html
>> >
>> 
>> Clear instructions were given for exactly how to test GUB, and just that 
>> thread seems to have involved about 16 people.
>> 
>> More recently, it looks like Jonas Hahnfeld's work with Python 3 
>> migration involved quite a number of changes to GUB.
>
> Yep, and it's not been a very pleasant experience. To be precise here:
> It's not about porting GUB to Python 3, it's just that porting LilyPond
> will introduce a dependency on an updated package for the next release.
> So while David is mostly correct that contributors don't need to bother
> with GUB, that doesn't hold true once you want to bump one of its
> dependencies...
>
> Based on this experience, I've thought about how to improve the process
> of building binary releases for LilyPond. What I have been
> experimenting with is a set of portable shell scripts that build mostly
> static executables. I've a prototype ready at 
> https://github.com/hahnjo/lilypond-binaries which works for Linux and
> FreeBSD. I don't see a reason it cannot work on macOS, but I don't have
> the possibility to test...

The problem is "on macOS" since current macOSX library/toolbox licenses
all prohibit use in cross-building environments.  It looks like a given
that we will not be able to offer macOSX libraries in future as the
result of a unified release process.  Our sources build reasonably well
that macOSX integrators using some of the macOSX typical packaging
systems are able to provide reasonable replacements.

But the elephant in the room is Windows.  Han-Wen says he never wants to
touch GUB again (and he actually didn't as far as I remember) but I
don't want to touch Windows again, and GUB provides them.  The
dependency nightmare on a non-UNIX like platform was what brought GUB
into being in the first place: native builds are much more of an ongoing
problem.  Just look at the continuous effort the Git project has in
keeping a Windows version available.

>>  From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with 
>> something based on Guix.
>> 
>> <
>> https://lists.gnu.org/archive/html/lilypond-user/2016-09/msg00690.html
>> >
>> 
>> That idea was mentioned a few times since, but I can't recall if 
>> GUB-replacement discussions have moved beyond that or not.
>
> As far as I understand, Guix is a package manager in the first place.
> In the thread Jan proposes to use it for cross-compilation, which I
> think is the primary reason for the complexity in GUB. So why go that
> route once more?
> Instead I designed the mentioned scripts such that they produce native
> executables. That's also how TeXlive builds their packages, for
> example, and it works quite well if you compile on the oldest OS that
> you intend to support (CentOS 7, FreeBSD 11).
>
> I haven't decided yet how to compile for Windows. Maybe that's still a
> valid use case for cross-compilation (but only with a very limited
> scope).

Windows really is the elephant in the room.  MacOSX will cater with
native port systems like MacPorts etc and other UNIX-like systems also
have working packagers and package systems.

> If this attempt sounds interesting to the community, I would be happy
> to submit the scripts for inclusion into the LilyPond repository
> itself. That would also solve another issue with GUB: Currently it's a
> separate repository with no way to keep it in sync with changing
> dependencies for LilyPond...

Maybe we should entertain two branches of GUB matching current stable
and unstable release tracks?  Or otherwise deal with a difference in
dependencies for stable/unstable?

-- 
David Kastrup

Re: Packages/modules

[Urs Liska]

Am Montag, den 20.01.2020, 23:45 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > OK. The *current* behaviour of oll-core is:
> > 
> > * loaded packages and modules (let's for now keep the existing
> > names)
> >   are accounted for in an alist.
> > * if the requested package/module is already loaded:
> >   * if options are passed, try setting them (overriding defaults
> > and/or values set by an earlier loading)
> > => This behaviour has to be discussed
> 
> Sounds to me like overriding defaults is perfectly reasonable (else
> specifying options wouldn't work at all) 

Yes, of course that's the idea behind it.

> and overriding values set by an
> earlier loading should flag an error.

That's probably right. Sometimes giving users too much controls and to
many alternatives makes the interface convoluted and as a result
confusing.

> 
> Maybe packages should have two ways of overriding a default: set a
> default and require a value.
> 
> A request in a user document is always treated as a requirement, two
> packages setting defaults leads to an error (or a warning and a
> revert
> to the original default?) unless some package (or the user) requires
> a
> particular setting which takes priority.  And of course different
> requirements cause an error.
> 
> Or is this too contrived, and only requirements should be allowed?

I don't find this too contrived in general, but there's one thing where
you may be too generic in the description.

There are two basic use cases for overriding default values: Loading a
package with options and setting an option explicitly after loading the
package. The other complication is in packages implicitly loading other
packages.

The simple case is when a user explicitly sets an option with (current
syntax) \setOption package.module.some.option-leaf value. This can
happen to change the global behaviour or to change something at some
point in the score/music expression (depending on how the value is
used). This is what you called a requirement and should always be
respected. If *that* triggers an error or produces unwanted results
it's clearly the user's responsibility.

The other case is when a package depends on another one and loads it,
which may result in the depended-on package being loaded more than
once, possibly with conflicting options.

Say you have a helper package [A] providing a data structure for some
use case (for example there is the `breaks` package that provides some
alists and accessor functionality to maintain sets of line/page
breaks).
Such a package may expose an option with a default value (currently the
syntax is \registerOption package.option.path default-value (specifying
types is on my wish-list)).
A client package [B] may just load that while a client package [C]
might load it overriding the value, for example because it wants [A] to
work in a specific mode. Another client package [D] may override the
option with a different value or pass the choice along to the user.
This is where conflicts may occur, and where it is not in our reach to
know at design time (designing the system, i.e. now) whether these
conflicts will be harmless or not. So erroring may be the safest
choice. Actually that would be the situation in LaTeX when you have to
know that two packages "don't work well" together.

After having written this I have the impression that the spot to
address your distinction between "setting" defaults and "requiring"
values would be:

 * A package "knows" whether a current value is at its default value or
   not (either with a "changed" flag or by on-the-fly comparison)
 * When to the *loading* of a package an option is passed that has
   already been changed it is considered illegal, and a warning or
   error is raised (to be decided, probably an error).
 * When an option is modified explicitly from user code it is simply
   done.

I will raise the issue of how options are handled and stored in a
separate thread, we should keep that out of the current discussion.

> >>> ...
> 
> > > And of course Guile has modules.  Do we already have a thought
> > > about
> > > how
> > > to relate to the module system?  
> > 
> > Yes, that's right! \loadModule is definitely a bad name.
> 
> I was not as much worrying about the name, actually, 

OK, but still that name should be discarded.

> but about the
> semantics.  Seems to me like defaulting to a separate module might be
> a
> reasonable thing.  It would require exporting whatever you want to
> use
> from outside the module.

OK, I *think* I see. I'll comment on that together with the other stuff
at the end below.

> 
> > In LilyPond there's a fundamental difference between \include and 
> > #(use-modules, which is not the case in oll-core. There "modules"
> > are
> > essentially the same as packages, just used to organize packages in
> > a
> > hierarchical fashion:
> > 
> > * scholarLY includes modules:
> >   * annotate
> >   * choice
> >   * staff-cancellation
> >   * ...
> > * snippets can be 

Re: Looking for help in configuring LilyDev in VirtualBox

[Peter Toye]

Monday, January 20, 2020, 10:24:13 PM, you wrote:


Am 20.01.2020 um 16:04 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox
Monday, January 20, 2020, 10:26:55 AM, you wrote:


Am 20.01.2020 um 11:08 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox

Hmm...weird. Could you please check if the virtual box modules are loaded
with
lsmod | grep vbox
Which VirtualBox version do you use? What is you host OS?

lsmod gives: vboxguest2949120
There should be some more kernel modules running.
Please try reinstalling the guest additions at first with: 
sudo apt install --reinstall virtualbox-guest-dkms virtualbox-guest-x11 
virtualbox-guest-utils

That didn't work: got a message:

E: Command line option 'r' [from -reinstall] is not understood in combination 
with the other options.

Then reboot your virtual machine. If that does not work, please
post the output of

ps aux | grep '/usr/bin/VBoxClient --clipboard'

Without rebooting (there didn't seem much point) I got:

dev 701 0.0 0.0 11108   932 pts/0   S+  11:10   0:00 
grep /usr/bin/VBoxClient --clipboard

which I guess is the process that I just ran.


so that we can see if the shared clipboard service is running

Best regards,
Michael

All the best,

Peter

remove obsolete lines from lily-guile-macros.hh (issue 555170043 by hanw...@gmail.com)

[jonas . hahnfeld]

LGTM

https://codereview.appspot.com/555170043/

Re: packaging lilypond as a docker container?

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Dienstag, den 21.01.2020, 02:38 -0600 schrieb Karlin High:
> On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote:
> > if GUB is used, who is maintaining and/or working on it?
> 
> Almost exactly a year ago, there was a sizable "Please test gub" effort 
> initiated by Knut Petersen.
> 
> <
> https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html
> >
> 
> Clear instructions were given for exactly how to test GUB, and just that 
> thread seems to have involved about 16 people.
> 
> More recently, it looks like Jonas Hahnfeld's work with Python 3 
> migration involved quite a number of changes to GUB.

Yep, and it's not been a very pleasant experience. To be precise here:
It's not about porting GUB to Python 3, it's just that porting LilyPond
will introduce a dependency on an updated package for the next release.
So while David is mostly correct that contributors don't need to bother
with GUB, that doesn't hold true once you want to bump one of its
dependencies...

Based on this experience, I've thought about how to improve the process
of building binary releases for LilyPond. What I have been
experimenting with is a set of portable shell scripts that build mostly
static executables. I've a prototype ready at 
https://github.com/hahnjo/lilypond-binaries which works for Linux and
FreeBSD. I don't see a reason it cannot work on macOS, but I don't have
the possibility to test...

>  From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with 
> something based on Guix.
> 
> <
> https://lists.gnu.org/archive/html/lilypond-user/2016-09/msg00690.html
> >
> 
> That idea was mentioned a few times since, but I can't recall if 
> GUB-replacement discussions have moved beyond that or not.

As far as I understand, Guix is a package manager in the first place.
In the thread Jan proposes to use it for cross-compilation, which I
think is the primary reason for the complexity in GUB. So why go that
route once more?
Instead I designed the mentioned scripts such that they produce native
executables. That's also how TeXlive builds their packages, for
example, and it works quite well if you compile on the oldest OS that
you intend to support (CentOS 7, FreeBSD 11).

I haven't decided yet how to compile for Windows. Maybe that's still a
valid use case for cross-compilation (but only with a very limited
scope). I'm not going to tackle this until we've switched to Python:
Then we can just use the embeddable zip file provided by the Python
project without bothering with cross-compilation for this beast.
Everything else (Guile etc.) worked without problems in my early tests.

If this attempt sounds interesting to the community, I would be happy
to submit the scripts for inclusion into the LilyPond repository
itself. That would also solve another issue with GUB: Currently it's a
separate repository with no way to keep it in sync with changing
dependencies for LilyPond...

Regards,
Jonas

P.S.: to come back to the whole container idea: after you have the
binaries, you can of course build a docker container from them...


signature.asc
Description: This is a digitally signed message part

Re: packaging lilypond as a docker container?

[Karlin High]

On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote:

if GUB is used, who is maintaining and/or working on it?


Almost exactly a year ago, there was a sizable "Please test gub" effort 
initiated by Knut Petersen.




Clear instructions were given for exactly how to test GUB, and just that 
thread seems to have involved about 16 people.


More recently, it looks like Jonas Hahnfeld's work with Python 3 
migration involved quite a number of changes to GUB.


From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with 
something based on Guix.




That idea was mentioned a few times since, but I can't recall if 
GUB-replacement discussions have moved beyond that or not.

--
Karlin High
Missouri, USA

Re: document and test slur score debugging (issue 555160043 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

LGTM, thanks!

https://codereview.appspot.com/555160043/