date:20200120

On Mon, Jan 20, 2020 at 11:57 PM David Kastrup  wrote:

> > As far as I can see right now, the time it takes to complete a GUB
> > build is not that important.  But the complexity of the GUB build
> > system is hugely important.  It's a big obstacle to getting
> > contributors going.
>
> Contributors don't need to bother with GUB.  GUB is just used internally
> for cranking out releases.  Nobody uses GUB when testing: instead
> LilyDev is being used.  No crosscompilation, instead cross execution
>

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

I enjoy working on LilyPond a lot, but GUB is different. I want GUB to
disappear so I never have to look at it again.

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

Re: packaging lilypond as a docker container?

2020-01-20 Thread Karlin High


On 1/20/2020 4:05 PM, Carl Sorensen wrote:

If the process of making the Docker application would also allow a simple set 
up for a build environment in non-Linux machines, I think that would be a huge 
win.


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 due to having LilyDev environments running on 
various other VM things. (VirtualBox, Microsoft Hyper-V, Windows 
Subsystem for Linux, etc)

--
Karlin High
Missouri, USA

Re: Returns from Salzburg by train

Thomas Morley  writes:

> Ok, I'll give it a try.
> But don't forget I'm not a programmer ;)

No C++ programmer maybe.  But the "not a programmer" bit left the
station long ago.

> This will probably be out of my depth.

Could well be, if it turns out more than a good hunch is required.

> In any case, it will take some time before I even can start this work.
> Tomorrow my regular job will occupy most of my time...

Those things happen.

-- 
David Kastrup

Re: packaging lilypond as a docker container?

Carl Sorensen  writes:

> On 1/20/20, 2:38 PM, "lilypond-devel on behalf of Han-Wen Nienhuys"
>  hanw...@gmail.com> wrote:
>
> What is the state of our binary releases? We currently have to
> maintain GUB, and GUB builds are quite slow. Our apple story is even more
> complicated, because of the Apple hardware requirement.
>
> We currently have a user who has figured out how to take a MacPorts
> build and turn it into an application bundle.  I think that we are in
> the final stages of having that build ready to go.
> 
> 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.
> 
> Then we could just offer a single binary to download, which windows/mac
> users can run. We don't have to cross-compile the app which further 
> reduces
> build times. The containerized app is still hermetic, so we can be in full
> control of the dependency versions
>
> As far as I can see right now, the time it takes to complete a GUB
> build is not that important.  But the complexity of the GUB build
> system is hugely important.  It's a big obstacle to getting
> contributors going.

Contributors don't need to bother with GUB.  GUB is just used internally
for cranking out releases.  Nobody uses GUB when testing: instead
LilyDev is being used.  No crosscompilation, instead cross execution.

> How difficult would it be to set up a build environment for making the
> Docker application?  A second major obstacle to developing is the
> difficulty of setting up a build environment for lilypond, especially
> in Windows and MacOS.  The recommended way to build now is via a
> virtual machine, with the extra challenges of trying to maintain the
> VM image.  If the process of making the Docker application would also
> allow a simple set up for a build environment in non-Linux machines, I
> think that would be a huge win.

Not sure where this is getting, but it might just be a case of beer.
Actually, more like a bottle of beer.

-- 
David Kastrup

Re: Packages/modules

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) and overriding values set by an
earlier loading should flag an error.

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?

>   * of no options are passed simply continue
>   * (exit)
> * look up the file (according to some logic (separate discussion)
> * if the file is found load the package/module
> * otherwise issue a warning, suggesting follow-up errors might come

I think the usual course should be an error.  Warning only if using a
special optional load (separate command or option for that).

>> 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, 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.

> 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 addressed like
>   \loadModule oll-misc.layout.horizontal-spacing
>
> Actually it would make transition smoother if we choose completely new
> names for the functions.
>
> So:
> * I suggest not to discern between "use/load" and "require",
>   just have one command that behaves like require.
> * (caveat: handling of config options when given to a
>   secondary call)
> * Is the "\load" prefix the best choice?
>   * \loadPackage
>   * \usepackage
>   * \use
>   * \package
>   ?

LaTeX has \usepackage and \RequirePackage either of which don't really
match LilyPond naming conventions.  A bit of a pity: I'd have opted for
\usepackage otherwise.

> * Do we need a word for the (current) "module" at all?
>   What about
>   \use scholarly.annotate
>   or
>   \use \with { subs = annotate.choice } scholarly
>   ?
>
>
>> With regard to namespaces, there may be
>> something to be said for requiring explicit export in the long run?
>> 
>
> Although I know this is important I don't feel comfortable having an
> opinion about this type of issue.

Ok.  One thing to think about is that we want package files to be
contributed by "ordinary" users.  But something like

\exportSymbols transposeSequence,instrumentGroup,scratchMyBack

would be perfectly feasible syntactical sugar.

-- 
David Kastrup

Re: Looking for help in configuring LilyDev in VirtualBox


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
Then reboot your virtual machine. If that does not work, please
post the output of

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

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

Best regards,
Michael

Re: packaging lilypond as a docker container?

2020-01-20 Thread Carl Sorensen



On 1/20/20, 2:38 PM, "lilypond-devel on behalf of Han-Wen Nienhuys" 
 wrote:

What is the state of our binary releases? We currently have to
maintain GUB, and GUB builds are quite slow. Our apple story is even more
complicated, because of the Apple hardware requirement.

We currently have a user who has figured out how to take a MacPorts build and 
turn it into an application bundle.  I think that we are in the final stages of 
having that build ready to go.

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.

Then we could just offer a single binary to download, which windows/mac
users can run. We don't have to cross-compile the app which further reduces
build times. The containerized app is still hermetic, so we can be in full
control of the dependency versions

As far as I can see right now, the time it takes to complete a GUB build is not 
that important.  But the complexity of the GUB build system is hugely 
important.  It's a big obstacle to getting contributors going.

How difficult would it be to set up a build environment for making the Docker 
application?  A second major obstacle to developing is the difficulty of 
setting up a build environment for lilypond, especially in Windows and MacOS.  
The recommended way to build now is via a virtual machine, with the extra 
challenges of trying to maintain the VM image.  If the process of making the 
Docker application would also allow a simple set up for a build environment in 
non-Linux machines, I think that would be a huge win.

Thanks,

Carl

Packages/modules (was: Extension management, first sketch)

Am Montag, den 20.01.2020, 14:14 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
> > > * A core extension library shipping with LilyPond will be
> > > initiated. 
> > >   Extensions that are considered core functionality (prime
> > > candidates:
> > >   edition-engraver, stylesheets) will eventually be moved here
> > > from
> > >   openLilyLib, additionally special functionality (e.g.
> > > gregorian.ly,
> > >   arabic.ly) may over time be moved there to expose the
> > > difference
> > >   between core functionality and use-case specific modules more 
> > >   clearly. These tools will then be called through `\loadModule`
> > >   instead of `\include`, which will be easy to handle with
> > >   convert-ly rules. Probably it would be a good idea to
> > > eventually 
> > >   expose *all* non-standard notation through explicit packages
> > >   and have that nicely describe in the LM. This too will not be
> > >   called openLilyLib.
> > 
> > Thinking about it I would go one step further:
> > 
> > Currently we have a /ly folder in the installation which contains
> > core
> > files like music-functions-init.ly on the one hand, and on the
> > other
> > hand optional files that users can \include for specific
> > functionality,
> > such as the ones I have given as examples above.
> > 
> > I think now that *all* the files that are not included
> > unconditionally
> > but only upon user request should be treated as packages. This will
> > make the code structure clearer, since there is a clear distinction
> > between the files LilyPond needs/uses for its startup (then *all*
> > files
> > in /ly) and optional files at the user's disposition.
> 
> Seconded.
> 
> Regarding \loadModule :  LaTeX has \documentclass for defining a
> document layout.  LilyPond does not have files dedicated to that
> purpose
> yet so that's something for later.

Yes, I think we can ignore that for now.
Everything a documentclass does I do with an initial include of the
infrastructure, and I think everybody else would do so as well. 

Conceptually I can see what a document class might be in notation, but
I don't see for what a separate construct would be necessary.

> 
> With regard to packages, LaTeX has \usepackage from user documents
> and
> the sort-of equivalent \RequirePackage from package code (not sure
> what
> the rationale for the difference is, there may be something related
> to
> when loading is allowed) and a counterpiece \ProvidePackage.

My impression is that - like with \newcommand, \renewcommand and
\providecommand they want to give control over the handling of
conflicts from already loaded packages.

> 
> Emacs has
> require is a built-in function in ‘C source code’.
> 
> (require FEATURE  FILENAME NOERROR)
> 
>   Probably introduced at or before Emacs version 15.
> 
> If feature FEATURE is not loaded, load it from FILENAME.
> If FEATURE is not a member of the list ‘features’, then the
> feature is
> not loaded; so load the file FILENAME.
> 
> If FILENAME is omitted, the printname of FEATURE is used as the
> file
> name, and ‘load’ will try to load this name appended with the
> suffix
> ‘.elc’, ‘.el’, or the system-dependent suffix for dynamic module
> files, in that order.  The name without appended suffix will not
> be
> used.  See ‘get-load-suffixes’ for the complete list of suffixes.
> 
> The directories in ‘load-path’ are searched when trying to find
> the
> file name.
> 
> If the optional third argument NOERROR is non-nil, then return
> nil if
> the file is not found instead of signaling an error.  Normally
> the
> return value is FEATURE.
> 
> The normal messages at start and end of loading FILENAME are
> suppressed.
> 
> [back]
> 
> and a matching
> 
> provide is a built-in function in ‘C source code’.
> 
> (provide FEATURE  SUBFEATURES)
> 
>   Probably introduced at or before Emacs version 15.
> 
> Announce that FEATURE is a feature of the current Emacs.
> The optional argument SUBFEATURES should be a list of symbols
> listing
> particular subfeatures supported in this version of FEATURE.
> 

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
  * of no options are passed simply continue
  * (exit)
* look up the file (according to some logic (separate discussion)
* if the file is found load the package/module
* otherwise issue a warning, suggesting follow-up errors might come

> 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.

In LilyPond

packaging lilypond as a docker container?

What is the state of our binary releases? We currently have to
maintain GUB, and GUB builds are quite slow. Our apple story is even more
complicated, because of the Apple hardware requirement.

Wouldn't it be much more simple to build lilypond as a Docker application?

Then we could just offer a single binary to download, which windows/mac
users can run. We don't have to cross-compile the app which further reduces
build times. The containerized app is still hermetic, so we can be in full
control of the dependency versions

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

Re: Returns from Salzburg by train (was: Inputting fingerings separate from melody?)

Am Mo., 20. Jan. 2020 um 22:23 Uhr schrieb Han-Wen Nienhuys :
>
>
>
> On Mon, Jan 20, 2020 at 10:06 PM Han-Wen Nienhuys  wrote:
>>>
>>>
>>> Furthermore in Salzburg we said to try "latin 1"- encoding everywhere
>>> (for newer guile-versions).
>>> I'd need some assistance about the how-to, then I could test it as well.
>>>
>>
>> I expect that actually nothing has to be done. I would assume that the C 
>> APIs we use are backward compatible. We should just avoid calling any 
>> functions that interpret a string as UTF-8 encoded Unicode.
>>
>
> that was too optimistic. I David's list is a good start, and you could 
> replace the calls with the latin1 equivalents,
>  scm_from_utf8_string ->  scm_from_latin1_string
>
> maybe it makes sense to introduce a
>
>   ly_string_from_cppstring
>
>   ly_symbol_from_cppstring
>
> so we can document this hack in one place centrally.

Ok, I'll give it a try.
But don't forget I'm not a programmer ;)
This will probably be out of my depth.

In any case, it will take some time before I even can start this work.
Tomorrow my regular job will occupy most of my time...

Cheers,
  Harm

Re: Returns from Salzburg by train (was: Inputting fingerings separate from melody?)

On Mon, Jan 20, 2020 at 10:06 PM Han-Wen Nienhuys  wrote:

>
>> Furthermore in Salzburg we said to try "latin 1"- encoding everywhere
>> (for newer guile-versions).
>> I'd need some assistance about the how-to, then I could test it as well.
>>
>>
> I expect that actually nothing has to be done. I would assume that the C
> APIs we use are backward compatible. We should just avoid calling any
> functions that interpret a string as UTF-8 encoded Unicode.
>
>
that was too optimistic. I David's list is a good start, and you could
replace the calls with the latin1 equivalents,
 scm_from_utf8_string ->  scm_from_latin1_string

maybe it makes sense to introduce a

  ly_string_from_cppstring

>   ly_symbol_from_cppstring

so we can document this hack in one place centrally.

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


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

Re: Returns from Salzburg by train (was: Inputting fingerings separate from melody?)

Am Mo., 20. Jan. 2020 um 22:17 Uhr schrieb Thomas Morley
:
>
> Am Mo., 20. Jan. 2020 um 22:07 Uhr schrieb Han-Wen Nienhuys 
> :
> >
> > On Mon, Jan 20, 2020 at 10:00 PM Thomas Morley  
> > wrote:
>
> >> Furthermore in Salzburg we said to try "latin 1"- encoding everywhere
> >> (for newer guile-versions).
> >> I'd need some assistance about the how-to, then I could test it as well.
> >>
> >
> > I expect that actually nothing has to be done. I would assume that the C 
> > APIs we use are backward compatible. We should just avoid calling any 
> > functions that interpret a string as UTF-8 encoded Unicode.
>
> Ok, so let me ask differently, how to "avoid calling any functions
> that interpret a string as UTF-8 encoded Unicode"?
> Which probably includes the need to know which functions currently do
> so. Those David listed?
>
> Cheers,
>   Harm

Thread is broken, I should have written a new mail. Sorry for that.

David's listing is here:
https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg00339.html

Cheers,
  Harm

Re: Returns from Salzburg by train (was: Inputting fingerings separate from melody?)

Am Mo., 20. Jan. 2020 um 22:07 Uhr schrieb Han-Wen Nienhuys :
>
> On Mon, Jan 20, 2020 at 10:00 PM Thomas Morley  
> wrote:

>> Furthermore in Salzburg we said to try "latin 1"- encoding everywhere
>> (for newer guile-versions).
>> I'd need some assistance about the how-to, then I could test it as well.
>>
>
> I expect that actually nothing has to be done. I would assume that the C APIs 
> we use are backward compatible. We should just avoid calling any functions 
> that interpret a string as UTF-8 encoded Unicode.

Ok, so let me ask differently, how to "avoid calling any functions
that interpret a string as UTF-8 encoded Unicode"?
Which probably includes the need to know which functions currently do
so. Those David listed?

Cheers,
  Harm

Re: Returns from Salzburg by train (was: Inputting fingerings separate from melody?)

On Mon, Jan 20, 2020 at 10:00 PM Thomas Morley 
wrote:

> Switching to devel,
>
> Am Mo., 20. Jan. 2020 um 21:30 Uhr schrieb David Kastrup :
> >
> > Thomas Morley  writes:
> > >
> > > Back at home now.
> > > My trail broke at Plochingen, which is close to the middle of nowhere
> ...
> >
> > s/trail/train/ ?
>
> train, ofcourse lol
>
> >
> > I got home on schedule eventless.  Well, broken WLAN, but I had booked a
> > day of WAN at the first leg of the trip anyway.
> >
> > --
> > David Kastrup
>
> No chance to work, any seat reservations were gone ...
> Once I had the luck to occupy one, I was too tired.
>
> Right now trying to compile guile-3.0. Will likely take a long time.
> Tomorrow evening I'll check whether LilyPond is compilable with this
> guile (ofcourse only if guile-building succeeds), as promised
>
> In case ´make-test-basline´ still fails, I plan to apply Han-Wen's patch
> https://codereview.appspot.com/545450043
> In order to test whether it makes a difference in this regard.
>
> Furthermore in Salzburg we said to try "latin 1"- encoding everywhere
> (for newer guile-versions).
> I'd need some assistance about the how-to, then I could test it as well.
>
>
I expect that actually nothing has to be done. I would assume that the C
APIs we use are backward compatible. We should just avoid calling any
functions that interpret a string as UTF-8 encoded Unicode.


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

Re: Returns from Salzburg by train

Thomas Morley  writes:

> Switching to devel,
>
> Am Mo., 20. Jan. 2020 um 21:30 Uhr schrieb David Kastrup :
>>
>> Thomas Morley  writes:
>> >
>> > Back at home now.
>> > My trail broke at Plochingen, which is close to the middle of nowhere ...
>>
>> s/trail/train/ ?
>
> train, ofcourse lol
>
>>
>> I got home on schedule eventless.  Well, broken WLAN, but I had booked a
>> day of WAN at the first leg of the trip anyway.
>>
>> --
>> David Kastrup
>
> No chance to work, any seat reservations were gone ...
> Once I had the luck to occupy one, I was too tired.
>
> Right now trying to compile guile-3.0. Will likely take a long time.
> Tomorrow evening I'll check whether LilyPond is compilable with this
> guile (ofcourse only if guile-building succeeds), as promised
>
> In case ´make-test-basline´ still fails, I plan to apply Han-Wen's patch
> https://codereview.appspot.com/545450043
> In order to test whether it makes a difference in this regard.
>
> Furthermore in Salzburg we said to try "latin 1"- encoding everywhere
> (for newer guile-versions).
> I'd need some assistance about the how-to, then I could test it as well.

I think that would require extensive changes in the C++ part of
LilyPond, so I doubt that "some assistance" would cut it.  I mean, all
of the following are certainly candidates:

dak@lola:/usr/local/tmp/lilypond$ git grep 'scm[_a-zA-Z]*utf8' lily
lily/engraver.cc:grob->self_scm (), scm_from_utf8_string (file),
lily/font-config-scheme.cc:scm_result = scm_from_utf8_string ((char const 
*)str);
lily/general-scheme.cc:  return scm_from_utf8_string (buf);
lily/grob-interface.cc:  SCM d = scm_from_utf8_string (descr);
lily/include/lily-guile-macros.hh:#define scm_from_utf8_string 
scm_from_locale_string
lily/include/lily-guile-macros.hh:#define scm_from_utf8_symbol 
scm_from_locale_symbol
lily/include/lily-guile-macros.hh:#define scm_to_utf8_string 
scm_to_locale_string
lily/include/lily-guile-macros.hh:scm_or_str2symbol (char const *c) { return 
scm_from_utf8_symbol (c); }
lily/include/lily-guile-macros.hh:inline SCM ly_symbol2scm (char const *x) { 
return scm_from_utf8_symbol ((x)); }
lily/lexer.ll:yylval = scm_cons (scm_from_utf8_string 
(YYText_utf8 ()),
lily/lily-guile.cc:  return scm_to_utf8_string (str);
lily/lily-lexer.cc:  *tail = scm_acons (scm_from_utf8_string 
(keytable_->table_[i].name_),
lily/open-type-font.cc:  tab = scm_eval_string (scm_from_utf8_string 
(contents.c_str ()));
lily/pango-font.cc:char_id = scm_from_utf8_string (glyph_name);
lily/translator.cc: scm_from_utf8_string 
(desc), static_properties);
lily/tweak-engraver.cc:grobname = scm_from_utf8_symbol


-- 
David Kastrup

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

2020-01-20 Thread hanwenn


On 2020/01/20 21:01:41, hanwenn wrote:

inspect-index


PTAL

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

Re: Returns from Salzburg by train (was: Inputting fingerings separate from melody?)

2020-01-20 Thread lemzwerg--- via Discussions on LilyPond development

Switching to devel,

Am Mo., 20. Jan. 2020 um 21:30 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
> >
> > Back at home now.
> > My trail broke at Plochingen, which is close to the middle of nowhere ...
>
> s/trail/train/ ?

train, ofcourse lol

>
> I got home on schedule eventless.  Well, broken WLAN, but I had booked a
> day of WAN at the first leg of the trip anyway.
>
> --
> David Kastrup

No chance to work, any seat reservations were gone ...
Once I had the luck to occupy one, I was too tired.

Right now trying to compile guile-3.0. Will likely take a long time.
Tomorrow evening I'll check whether LilyPond is compilable with this
guile (ofcourse only if guile-building succeeds), as promised

In case ´make-test-basline´ still fails, I plan to apply Han-Wen's patch
https://codereview.appspot.com/545450043
In order to test whether it makes a difference in this regard.

Furthermore in Salzburg we said to try "latin 1"- encoding everywhere
(for newer guile-versions).
I'd need some assistance about the how-to, then I could test it as well.

Cheers,
  Harm

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

2020-01-20 Thread David Nalesnik

On Mon, Jan 20, 2020 at 10:37 AM Janek Warchoł  wrote:
>
> Hi everyone,
>
> for those who don't know me: I was an active member of the community
> several years ago, contributed patches, co-authored LilyPond blog, and 
> together
> with Urs Liska 
> typeset
> an award-winning publication
> 
> with
> LilyPond. Since then I've pursued a career in software development.
>
> I just came back from music engraving conference organized by Werner and
> Urs (kudos to them!!), and - inspired by the people present there (most
> importantly Han-Wen, Mike Solomon and Kieren MacMillan) - I decided to get
> involved in the project again :-) I should be able to spend about 5-10
> hours a week on LilyPond.
>
> One of the topics discussed in Salzburg was making it easier to contribute
> to LilyPond. I have proposed to lead that effort, and the people present
> agreed to it. I would like to ask the full developer community for your
> trust*,* too. I will share my plans in a separate thread.
>
> cheers,
> Janek

Welcome back, Janek!

David

Plan for improving contribution process

2020-01-20 Thread Janek Warchoł

Hello,

Let's start with a high-level plan, and identify what are the biggest
problems. Here's a document where I started; I'll give edit access to each
of you upon request.

https://docs.google.com/document/d/1zYwygWEKJt21rl-bKL41IpjFmiBjlfob6eS63jd-62I/edit?usp=sharing

best,
Janek

PS I know that Google Docs are not free - but they are way more efficient
for this task than a mailing list. If anyone objects to using Google Docs,
please send your suggestion to me in an email, but *remember to keep
focused!* Also, feel free to suggest alternatives to Gdocs. To avoid
disorganization, *please send these suggestions privately* to me and I'll
aggregate them.

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

2020-01-20 Thread Trevor




Janek, you wrote 20/01/2020 16:34:15


I just came back from music engraving conference organized by Werner and
Urs (kudos to them!!), and - inspired by the people present there (most
importantly Han-Wen, Mike Solomon and Kieren MacMillan) - I decided to get
involved in the project again :-) I should be able to spend about 5-10
hours a week on LilyPond.

Wow! Han-Wen and now Janek! Welcome back to both of you!


One of the topics discussed in Salzburg was making it easier to contribute
to LilyPond. I have proposed to lead that effort, and the people present
agreed to it. I would like to ask the full developer community for your
trust*,* too. I will share my plans in a separate thread.

Good luck!

Trevor

Re: github mirror of lilypond?

2020-01-20 Thread pkx166h

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'.

James

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

2020-01-20 Thread Carl Sorensen

Welcome back, Janek!  You certainly have my trust!

Carl

Re: github mirror of lilypond?

2020-01-20 Thread Carl Sorensen

On 1/20/20, 9:07 AM, "lilypond-devel on behalf of Urs Liska" 
 wrote:

Am Montag, den 20.01.2020, 16:53 +0100 schrieb David Kastrup:
> David Kastrup  writes:
> 
> > Werner LEMBERG  writes:
> > 
> > > > > Han-Wen has recently pushed a bunch of changes directly to
> > > > > Rietveld, most of them quite uncontroversial.  I assume that
> > > > > this
> > > > > is as good as an e-mail :-)
> > > > > 
> > > > > I thus suggest that after his patches have been reviewed,
> > > > 
> > > > How are they going to get reviewed when there is nothing
> > > > pointing to
> > > > them?  How would anyone including Han-Wen know when the review
> > > > phase
> > > > ends?
> > > 
> > > Well, as has been pointed out, pull requests at github don't have
> > > 'review phases', and what we have here is comparable IMHO.
> > > 
> > > One developer (or maybe two, just to be sure) acknowledges the
> > > patch,
> > > and that's it.  Kind of a highway solution for trivial things.
> > 
> > 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.
> 
> At any rate: we haven't had a protocol for patches not going through
> the
> regular process.  Maybe we should use the Signed-off-by: convention
> for
> such patches, including the original submitter and the LGTM
> votes?  It's
> probably mostly psychological, but it suggests a bit of
> accountability/responsibility.
> 

I would like to add to that. With my few contributions to the actual
LilyPond codebase I was several times hit hard by last-moment
objections in the countdown stage.

This is totally annoying and also frustrating - but what would be the
alternative? Obviously there was something that should not go into the
code base, and the fact that we're so few that not everyone has the
opportunity to look at all patches immediately should not be a
"justification" for letting stuff slip through.

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.

Thanks,

Carl

Janek is coming back to LilyPond! :-)

2020-01-20 Thread Janek Warchoł

Hi everyone,

for those who don't know me: I was an active member of the community
several years ago, contributed patches, co-authored LilyPond blog, and together
with Urs Liska 
typeset
an award-winning publication

with
LilyPond. Since then I've pursued a career in software development.

I just came back from music engraving conference organized by Werner and
Urs (kudos to them!!), and - inspired by the people present there (most
importantly Han-Wen, Mike Solomon and Kieren MacMillan) - I decided to get
involved in the project again :-) I should be able to spend about 5-10
hours a week on LilyPond.

One of the topics discussed in Salzburg was making it easier to contribute
to LilyPond. I have proposed to lead that effort, and the people present
agreed to it. I would like to ask the full developer community for your
trust*,* too. I will share my plans in a separate thread.

cheers,
Janek

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


From inspection only: LGTM, thanks!


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

https://codereview.appspot.com/557190043/diff/581490044/lily/lookup.cc#newcode314
lily/lookup.cc:314: int i0 = (int) i;
Maybe 'int(i)' instead?

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

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

2020-01-20 Thread lemzwerg--- via Discussions on LilyPond development


From inspection only: LGTM, thanks!


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

https://codereview.appspot.com/573400043/diff/549420043/lily/includable-lexer.cc#newcode74
lily/includable-lexer.cc:74: (current_dir.length () ? (current_dir +
PATHSEP) : "") + sources->search_path ().c_str ());
I'm Mister 'please use 78 chars per line' :-)

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

lily/page-breaking: pass vector by reference (issue 581510043 by hanw...@gmail.com)

2020-01-20 Thread lemzwerg--- via Discussions on LilyPond development


LGTM

https://codereview.appspot.com/581510043/

Re: github mirror of lilypond?



>> At any rate: we haven't had a protocol for patches not going
>> through the regular process.  Maybe we should use the
>> Signed-off-by: convention for such patches, including the original
>> submitter and the LGTM votes?  It's probably mostly psychological,
>> but it suggests a bit of accountability/responsibility.

This is OK with me.

> I would like to add to that. With my few contributions to the actual
> LilyPond codebase I was several times hit hard by last-moment
> objections in the countdown stage.
>
> This is totally annoying and also frustrating - but what would be
> the alternative? Obviously there was something that should not go
> into the code base, and the fact that we're so few that not everyone
> has the opportunity to look at all patches immediately should not be
> a "justification" for letting stuff slip through.

I think there is nothing we can do to prevent that.


Werner

Re: github mirror of lilypond?



> 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

Re: github mirror of lilypond?

Am Montag, den 20.01.2020, 16:53 +0100 schrieb David Kastrup:
> David Kastrup  writes:
> 
> > Werner LEMBERG  writes:
> > 
> > > > > Han-Wen has recently pushed a bunch of changes directly to
> > > > > Rietveld, most of them quite uncontroversial.  I assume that
> > > > > this
> > > > > is as good as an e-mail :-)
> > > > > 
> > > > > I thus suggest that after his patches have been reviewed,
> > > > 
> > > > How are they going to get reviewed when there is nothing
> > > > pointing to
> > > > them?  How would anyone including Han-Wen know when the review
> > > > phase
> > > > ends?
> > > 
> > > Well, as has been pointed out, pull requests at github don't have
> > > 'review phases', and what we have here is comparable IMHO.
> > > 
> > > One developer (or maybe two, just to be sure) acknowledges the
> > > patch,
> > > and that's it.  Kind of a highway solution for trivial things.
> > 
> > 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.
> 
> At any rate: we haven't had a protocol for patches not going through
> the
> regular process.  Maybe we should use the Signed-off-by: convention
> for
> such patches, including the original submitter and the LGTM
> votes?  It's
> probably mostly psychological, but it suggests a bit of
> accountability/responsibility.
> 

I would like to add to that. With my few contributions to the actual
LilyPond codebase I was several times hit hard by last-moment
objections in the countdown stage.

This is totally annoying and also frustrating - but what would be the
alternative? Obviously there was something that should not go into the
code base, and the fact that we're so few that not everyone has the
opportunity to look at all patches immediately should not be a
"justification" for letting stuff slip through.

Re: github mirror of lilypond?

David Kastrup  writes:

> Werner LEMBERG  writes:
>
 Han-Wen has recently pushed a bunch of changes directly to
 Rietveld, most of them quite uncontroversial.  I assume that this
 is as good as an e-mail :-)

 I thus suggest that after his patches have been reviewed,
>>> 
>>> How are they going to get reviewed when there is nothing pointing to
>>> them?  How would anyone including Han-Wen know when the review phase
>>> ends?
>>
>> Well, as has been pointed out, pull requests at github don't have
>> 'review phases', and what we have here is comparable IMHO.
>>
>> One developer (or maybe two, just to be sure) acknowledges the patch,
>> and that's it.  Kind of a highway solution for trivial things.
>
> 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.

At any rate: we haven't had a protocol for patches not going through the
regular process.  Maybe we should use the Signed-off-by: convention for
such patches, including the original submitter and the LGTM votes?  It's
probably mostly psychological, but it suggests a bit of
accountability/responsibility.

-- 
David Kastrup

Re: github mirror of lilypond?

Werner LEMBERG  writes:

>>> Han-Wen has recently pushed a bunch of changes directly to
>>> Rietveld, most of them quite uncontroversial.  I assume that this
>>> is as good as an e-mail :-)
>>>
>>> I thus suggest that after his patches have been reviewed,
>> 
>> How are they going to get reviewed when there is nothing pointing to
>> them?  How would anyone including Han-Wen know when the review phase
>> ends?
>
> Well, as has been pointed out, pull requests at github don't have
> 'review phases', and what we have here is comparable IMHO.
>
> One developer (or maybe two, just to be sure) acknowledges the patch,
> and that's it.  Kind of a highway solution for trivial things.

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.

-- 
David Kastrup

Re: github mirror of lilypond?



>> Han-Wen has recently pushed a bunch of changes directly to
>> Rietveld, most of them quite uncontroversial.  I assume that this
>> is as good as an e-mail :-)
>>
>> I thus suggest that after his patches have been reviewed,
> 
> How are they going to get reviewed when there is nothing pointing to
> them?  How would anyone including Han-Wen know when the review phase
> ends?

Well, as has been pointed out, pull requests at github don't have
'review phases', and what we have here is comparable IMHO.

One developer (or maybe two, just to be sure) acknowledges the patch,
and that's it.  Kind of a highway solution for trivial things.


Werner

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

VirtualBox 6.1
Windows 10 Home update 1903

Hope this helps.



As it seems that you are keeping the CG up to date there's no point in my 
trying to help. We'll just get in each other's way.
No, definitely not! Your help is very much appreciated! 
When LilyDev v2 will be out and the CG patch is in review (in a few days, 
maybe), it would be great if you could 
walk your way through the install steps again and comment on every ambiguity 
you noticed.
And after that there will be >many< further sections in the CG that would 
deserve further clarification / extension.

Cheers,
Michael


Thanks,

Peter

Re: github mirror of lilypond?

Werner LEMBERG  writes:

>>Send an email (must be less than 64 KB) to
>>  briefly explaining your work, with the
>> patch files attached.  Translators should send patches to
>> .  After your patches are reviewed, the
>> developers may push one or more of them to the main repository or
>> discuss them with you.
>
> Han-Wen has recently pushed a bunch of changes directly to Rietveld,
> most of them quite uncontroversial.  I assume that this is as good as
> an e-mail :-)
>
> I thus suggest that after his patches have been reviewed,

How are they going to get reviewed when there is nothing pointing to
them?  How would anyone including Han-Wen know when the review phase
ends?

> he should simply commit to `staging`.  If a developer has doubts, we
> can create an SourceForge issue to do it the normal way.
>
> Of course, this is a temporary measure until Janek finds and
>implements something better (see the Salzburg googledoc file posted
>recently for more).

-- 
David Kastrup

Re: github mirror of lilypond?



>Send an email (must be less than 64 KB) to
>  briefly explaining your work, with the
> patch files attached.  Translators should send patches to
> .  After your patches are reviewed, the
> developers may push one or more of them to the main repository or
> discuss them with you.

Han-Wen has recently pushed a bunch of changes directly to Rietveld,
most of them quite uncontroversial.  I assume that this is as good as
an e-mail :-)

I thus suggest that after his patches have been reviewed, he should
simply commit to `staging`.  If a developer has doubts, we can create
an SourceForge issue to do it the normal way.

Of course, this is a temporary measure until Janek finds and
implements something better (see the Salzburg googledoc file posted
recently for more).


Werner

Re: Extension management, first sketch

Urs Liska  writes:

> Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
>> * A core extension library shipping with LilyPond will be initiated. 
>>   Extensions that are considered core functionality (prime
>> candidates:
>>   edition-engraver, stylesheets) will eventually be moved here from
>>   openLilyLib, additionally special functionality (e.g. gregorian.ly,
>>   arabic.ly) may over time be moved there to expose the difference
>>   between core functionality and use-case specific modules more 
>>   clearly. These tools will then be called through `\loadModule`
>>   instead of `\include`, which will be easy to handle with
>>   convert-ly rules. Probably it would be a good idea to eventually 
>>   expose *all* non-standard notation through explicit packages
>>   and have that nicely describe in the LM. This too will not be
>>   called openLilyLib.
>
> Thinking about it I would go one step further:
>
> Currently we have a /ly folder in the installation which contains core
> files like music-functions-init.ly on the one hand, and on the other
> hand optional files that users can \include for specific functionality,
> such as the ones I have given as examples above.
>
> I think now that *all* the files that are not included unconditionally
> but only upon user request should be treated as packages. This will
> make the code structure clearer, since there is a clear distinction
> between the files LilyPond needs/uses for its startup (then *all* files
> in /ly) and optional files at the user's disposition.

Seconded.

Regarding \loadModule :  LaTeX has \documentclass for defining a
document layout.  LilyPond does not have files dedicated to that purpose
yet so that's something for later.

With regard to packages, LaTeX has \usepackage from user documents and
the sort-of equivalent \RequirePackage from package code (not sure what
the rationale for the difference is, there may be something related to
when loading is allowed) and a counterpiece \ProvidePackage.

Emacs has
require is a built-in function in ‘C source code’.

(require FEATURE  FILENAME NOERROR)

  Probably introduced at or before Emacs version 15.

If feature FEATURE is not loaded, load it from FILENAME.
If FEATURE is not a member of the list ‘features’, then the feature is
not loaded; so load the file FILENAME.

If FILENAME is omitted, the printname of FEATURE is used as the file
name, and ‘load’ will try to load this name appended with the suffix
‘.elc’, ‘.el’, or the system-dependent suffix for dynamic module
files, in that order.  The name without appended suffix will not be
used.  See ‘get-load-suffixes’ for the complete list of suffixes.

The directories in ‘load-path’ are searched when trying to find the
file name.

If the optional third argument NOERROR is non-nil, then return nil if
the file is not found instead of signaling an error.  Normally the
return value is FEATURE.

The normal messages at start and end of loading FILENAME are
suppressed.

[back]

and a matching

provide is a built-in function in ‘C source code’.

(provide FEATURE  SUBFEATURES)

  Probably introduced at or before Emacs version 15.

Announce that FEATURE is a feature of the current Emacs.
The optional argument SUBFEATURES should be a list of symbols listing
particular subfeatures supported in this version of FEATURE.

And of course Guile has modules.  Do we already have a thought about how
to relate to the module system?  With regard to namespaces, there may be
something to be said for requiring explicit export in the long run?

-- 
David Kastrup

Re: Extension management, first sketch

2020-01-20 Thread lemzwerg--- via Discussions on LilyPond development

Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
> * A core extension library shipping with LilyPond will be initiated. 
>   Extensions that are considered core functionality (prime
> candidates:
>   edition-engraver, stylesheets) will eventually be moved here from
>   openLilyLib, additionally special functionality (e.g. gregorian.ly,
>   arabic.ly) may over time be moved there to expose the difference
>   between core functionality and use-case specific modules more 
>   clearly. These tools will then be called through `\loadModule`
>   instead of `\include`, which will be easy to handle with
>   convert-ly rules. Probably it would be a good idea to eventually 
>   expose *all* non-standard notation through explicit packages
>   and have that nicely describe in the LM. This too will not be
>   called openLilyLib.

Thinking about it I would go one step further:

Currently we have a /ly folder in the installation which contains core
files like music-functions-init.ly on the one hand, and on the other
hand optional files that users can \include for specific functionality,
such as the ones I have given as examples above.

I think now that *all* the files that are not included unconditionally
but only upon user request should be treated as packages. This will
make the code structure clearer, since there is a clear distinction
between the files LilyPond needs/uses for its startup (then *all* files
in /ly) and optional files at the user's disposition.

Urs

Remove implicit evaluation of the ".twy" file (issue 551380043 by hanw...@gmail.com)


LGTM, thanks.

https://codereview.appspot.com/551380043/

Re: mirroring lilypond on github

2020-01-20 Thread lemzwerg--- via Discussions on LilyPond development

>> To github.com:lilypond/lilypond.git
>>  - [deleted]   stable/2.18
>>  * [new branch]origin/stable/0.0 -> origin/stable/0.0
> 
> It looks like you are trying to push a normal clone of the savannah
> repo, where as you should be pushing from something that was cloned
> as
> 
>   git clone --mirror ...savnnah...

Aaah, thanks!


Werner

Documentation: fix typos in tool naming (issue 581480043 by hanw...@gmail.com)


LGTM, of course.  Please commit such simple, trivial, and
uncontroversial changes directly to the git repository.

https://codereview.appspot.com/581480043/

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

2020-01-20 Thread dak




https://codereview.appspot.com/555160043/diff/569260043/lily/slur.cc
File lily/slur.cc (left):

https://codereview.appspot.com/555160043/diff/569260043/lily/slur.cc#oldcode576
lily/slur.cc:576: "inspect-index "
Is the removal of the inspect-index property intentional?  It appears
unused, but at the same time this patch seems to augment its
documentation?

https://codereview.appspot.com/555160043/diff/569260043/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

https://codereview.appspot.com/555160043/diff/569260043/scm/define-grob-properties.scm#newcode546
scm/define-grob-properties.scm:546: (inspect-index ,integer? "If
debugging is set, set beam
inspect-index is removed but its documentation changed rather than
removed?

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

Re: grand-replace



> So go wild.

Thanks.  Copyright years are now updated in staging.


Werner

Re: Looking for help in configuring LilyDev in VirtualBox

Michael,

I have to go out now - will reply this afternoon (UK time).

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Monday, January 20, 2020, 10:26:55 AM, Michael Käppler wrote:

> Am 20.01.2020 um 11:08 schrieb Peter Toye:
>> Re: Looking for help in configuring LilyDev in VirtualBox
>> No, I didn't receive it. And it's not in my junk mailbox either, so it
>> must have disappeared entirely. That's a nuisance.

>> Clipboard was already activated as bidirectional. But it's not
>> working. I copied text from Lilydev but there was nothing in the host
>> (Windows) clipboard. I copied text from the host, and the Lilydev
>> clipboard had what I just copied from Lilydev. So it seems that the
>> clipboards aren't integrating. Or am I doing something wrong?
> 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?


>> As it seems that you are keeping the CG up to date there's no point in
>> my trying to help. We'll just get in each other's way.
> No, definitely not! Your help is very much appreciated!
> When LilyDev v2 will be out and the CG patch is in review (in a few
> days, maybe), it would be great if you could
> walk your way through the install steps again and comment on every
> ambiguity you noticed.
> And after that there will be >many< further sections in the CG that
> would deserve further clarification / extension.

> Cheers,
> Michael

Re: github mirror of lilypond?

"Jürgen Reuter"  writes:

>Hi all,
>
>+1 (at least) from me for for:
>
>* Having a smooth integration of git repository, review process and
>verify build.  If this is (as I conclude from the discussions) not
>possible with hosting the git repository on savannah, then please
>consider hosting the repository on a different platform.
>
>* Using Gerrit as review system (maybe unless you know of another
>system with equally smooth integration with git; but I do not know of
>any such system).  I am using Gerrit (the "old" version) at work and I
>am fully satisfied with its integration with git and Jenkins.
>I still have here ~12 mostly small commits (tiny fixes / features,
>clean-ups, code doc clarifications, etc.) lying around locally on my
>machine for several years.  I did not push them so far as I was (and
>still am) really scared about the time that I have to invest to get
>these commits through this complex process, especially as I expect at
>least some of the commits not to pass in the first go, but expecting
>possibly controversial reviews.
>Maybe the current process feels not that complex if you are committing
>regularly.  But I perceive it as complex, especially with respect to
>the time that I fear to have to put into the process rather than being
>productive, given my very limited time budget.  And I think, other
>people perceive it similarly.

File: lilypond-contributor.info,  Node: How to make a patch,  Next: Emailing 
patches,  Up: Patches

How to make a patch
...

If you want to share your changes with other contributors and
developers, you need to generate _patches_ from your commits.  We prefer
it if you follow the instructions in *note Uploading a patch for
review::.  However, we present an alternate method here.

   You should always run ‘git pull -r’ (translators should leave off the
‘-r’) before doing this to ensure that your patches are as current as
possible.

   Once you have made one or more commits in your local repository, and
pulled the most recent commits from the remote branch, you can generate
patches from your local commits with the command:

 git format-patch origin

   The ‘origin’ argument refers to the remote tracking branch at
‘git.sv.gnu.org’.  This command generates a separate patch for each
commit that’s in the current branch but not in the remote branch.
Patches are placed in the current working directory and will have names
that look something like this:

 0001-Doc-Fix-typos.patch
 0002-Web-Remove-dead-links.patch
 ⋮

   Send an email (must be less than 64 KB) to 
briefly explaining your work, with the patch files attached.
Translators should send patches to .  After
your patches are reviewed, the developers may push one or more of them
to the main repository or discuss them with you.

>And of course, a big thank you to all of you that do all the great
>work, that I really appreciate!  But to attract more developers and /
>or re-animate retired developers, I am pretty sure that the process has
>to be simplified for potential "casual" committers like me that will
>contribute only now and then.

The above does not look all that complex to me.

-- 
David Kastrup

Re: Looking for help in configuring LilyDev in VirtualBox


Am 20.01.2020 um 11:08 schrieb Peter Toye:

Re: Looking for help in configuring LilyDev in VirtualBox
No, I didn't receive it. And it's not in my junk mailbox either, so it
must have disappeared entirely. That's a nuisance.

Clipboard was already activated as bidirectional. But it's not
working. I copied text from Lilydev but there was nothing in the host
(Windows) clipboard. I copied text from the host, and the Lilydev
clipboard had what I just copied from Lilydev. So it seems that the
clipboards aren't integrating. Or am I doing something wrong?

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?



As it seems that you are keeping the CG up to date there's no point in
my trying to help. We'll just get in each other's way.

No, definitely not! Your help is very much appreciated!
When LilyDev v2 will be out and the CG patch is in review (in a few
days, maybe), it would be great if you could
walk your way through the install steps again and comment on every
ambiguity you noticed.
And after that there will be >many< further sections in the CG that
would deserve further clarification / extension.

Cheers,
Michael

Re: Is the CG out of date?


Am 20.01.2020 um 11:04 schrieb Michael Käppler:


Attached is an extract of the CG pages we're discussing, with my recent
(yet only local) changes.


Urgh, sorry. Really(tm) attached now.











contributor_LilyDev_mk.pdf
Description: Adobe PDF document

Re: Looking for help in configuring LilyDev in VirtualBox

Monday, January 20, 2020, 9:46:58 AM, Michael Käppler wrote:



Am 20.01.2020 um 10:34 schrieb Peter Toye:

Reposted with additions:


I'm slowly working my way through CG Section 2.1, but have reached an impasse. 
In "Configuring LilyDev in VirtualBox". Step 1 tells me to "install Guest 
Addition...". That's been changed to "Insert..." but that's obvious. The 
VBoxGuestAdditions.iso CD is in the virtual drive, but it seems but there's no 
autorun, and clicking on it merely asks if I want to eject it.

I've now worked out how to mount the CD, and I followed the instructions in the 
VirtualBox FAQ page to install the missing bits. But when I try to install the 
Guest Additions it says they're already installed. has the LilyDev distro 
changed to include the Guest Additions? Because, if so, I can't get the shared 
clipboard to work, and that's rather necessary for my setup.



Hi Peter, I did answer almost immediately: 


Am 18.01.2020 um 13:40 schrieb Peter Toye: 

I'm slowly working my way through CG Section 2.1, but have reached an impasse. 
In "Configuring LilyDev in VirtualBox". Step 1 tells me to "install Guest 
Addition...". That's been changed to "Insert..." but that's obvious. The 
VBoxGuestAdditions.iso CD is in the virtual drive, but it seems but there's no 
autorun, and clicking on it merely asks if I want to eject it. 

It looks as if there's a step missing, as the CD doesn't seem to be mounted in 
the file system, which would explain everything. But I'm not sure (as a Linux 
newbie) where to look for it. 
You won't need that. The guest additions have been incorporated into 
LilyDev. 
My patch for the CG will reflect this change. 
If you have problems resizing the VM window to full size, try to change 
the Display->Graphics controller to VBoxVGA in VirtualBox settings. 
You can activate clipboard sharing in General->Advanced->Bidirectional. 

So it seems you did not receive my response?
I did only reply to the list, but you should have received it, anyway.

No, I didn't receive it. And it's not in my junk mailbox either, so it must 
have disappeared entirely. That's a nuisance.

Clipboard was already activated as bidirectional. But it's not working. I 
copied text from Lilydev but there was nothing in the host (Windows) clipboard. 
I copied text from the host, and the Lilydev clipboard had what I just copied 
from Lilydev. So it seems that the clipboards aren't integrating. Or am I doing 
something wrong?

As it seems that you are keeping the CG up to date there's no point in my 
trying to help. We'll just get in each other's way.


Cheers,
Michael



All the best,

Peter

Re: Is the CG out of date?


Am 20.01.2020 um 10:28 schrieb Peter Toye:

Thursday, January 16, 2020, 7:40:55 PM, you wrote:


Perhaps the best way would be to 'remove'
information from the CG and
replace it with reference/links to the github location rather than
duplicate instructions.

As I wrote on 16th of January:

Hi all,
the GitHub page has only little information that would be helpful for
newbies, IMHO.
I've already prepared a patch for the mentioned CG section but have not
posted it for review yet,
because it refers to some small changes I contributed to LilyDev in the
last days (two of them have already
been merged into master). I do not know, however, if Federico will make
a new release soon.



Attached is an extract of the CG pages we're discussing, with my recent
(yet only local) changes.
The section regarding the keyboard and locale setup will work in LilyDev
v2, in LilyDev v1 you would
need to install the mentioned tools.

Cheers,
Michael

Re: Looking for help in configuring LilyDev in VirtualBox

Am 20.01.2020 um 10:34 schrieb Peter Toye:

Reposted with additions:

I'm slowly working my way through CG Section 2.1, but have reached an impasse. In "Configuring LilyDev
in VirtualBox". Step 1 tells me to "install Guest Addition...". That's been changed to
"Insert..." but that's obvious. The VBoxGuestAdditions.iso CD is in the virtual drive, but it seems
but there's no autorun, and clicking on it merely asks if I want to eject it.

I've now worked out how to mount the CD, and I followed the instructions in the
VirtualBox FAQ page to install the missing bits. But when I try to install the
Guest Additions it says they're already installed. has the LilyDev distro
changed to include the Guest Additions? Because, if so, I can't get the shared
clipboard to work, and that's rather necessary for my setup.

Hi Peter, I did answer almost immediately:

Am 18.01.2020 um 13:40 schrieb Peter Toye:

I'm slowly working my way through CG Section 2.1, but have reached an
impasse. In "Configuring LilyDev in VirtualBox". Step 1 tells me to
"install Guest Addition...". That's been changed to "Insert..." but
that's obvious. The VBoxGuestAdditions.iso CD is in the virtual
drive, but it seems but there's no autorun, and clicking on it merely
asks if I want to eject it.

It looks as if there's a step missing, as the CD doesn't seem to be
mounted in the file system, which would explain everything. But I'm
not sure (as a Linux newbie) where to look for it.

You won't need that. The guest additions have been incorporated into
LilyDev.
My patch for the CG will reflect this change.
If you have problems resizing the VM window to full size, try to change
the Display->Graphics controller to VBoxVGA in VirtualBox settings.
You can activate clipboard sharing in General->Advanced->Bidirectional.

So it seems you did not receive my response?
I did only reply to the list, but you should have received it, anyway.

Cheers,
Michael

Re: Finding files in include paths

Am Montag, den 20.01.2020, 10:34 +0100 schrieb Han-Wen Nienhuys:
> I documented it in https://codereview.appspot.com/573400043/
> 
> you could add a scheme callback similar to ly:source-file, eg.
> ly:source-find to do the equivalent of kpsewhich

Thanks. I have to go to work now, but I'll have a look ASAP:

Urs

> 
> On Mon, Jan 20, 2020 at 9:22 AM Urs Liska 
> wrote:
> > Hi all,
> > 
> > how/where is the file searchign with LilyPond's search path is
> > implemented?
> > 
> > If I write 
> >   \include "a/relative/path"
> > the given path is searched for relative to all search paths known
> > to
> > LilyPond.
> > 
> > Is there a way to do the same in Scheme, say
> >   (file-visible-to-lilypond "a/relative/path")
> > to determine whether a target can be found within any LilyPond
> > search
> > path? Probably the function should return the absolut path, similar
> > to
> > what kpsewhich does.
> > 
> > I need that to check whether a certain file is present (and then
> > open
> > it) without knowing the absolute location.
> > 
> > Urs
> > 
> > 
> 
>

Re: Looking for help in configuring LilyDev in VirtualBox

Reposted with additions:


I'm slowly working my way through CG Section 2.1, but have reached an impasse. 
In "Configuring LilyDev in VirtualBox". Step 1 tells me to "install Guest 
Addition...". That's been changed to "Insert..." but that's obvious. The 
VBoxGuestAdditions.iso CD is in the virtual drive, but it seems but there's no 
autorun, and clicking on it merely asks if I want to eject it.

I've now worked out how to mount the CD, and I followed the instructions in the 
VirtualBox FAQ page to install the missing bits. But when I try to install the 
Guest Additions it says they're already installed. has the LilyDev distro 
changed to include the Guest Additions? Because, if so, I can't get the shared 
clipboard to work, and that's rather necessary for my setup.



If someone could help I'd be most grateful. I realise that this mailing list 
isn't for support, but it seemed more relevant than the user mailing list.

Peter

Re: Finding files in include paths

I documented it in https://codereview.appspot.com/573400043/

you could add a scheme callback similar to ly:source-file, eg.
ly:source-find to do the equivalent of kpsewhich

On Mon, Jan 20, 2020 at 9:22 AM Urs Liska  wrote:

> Hi all,
>
> how/where is the file searchign with LilyPond's search path is
> implemented?
>
> If I write
>   \include "a/relative/path"
> the given path is searched for relative to all search paths known to
> LilyPond.
>
> Is there a way to do the same in Scheme, say
>   (file-visible-to-lilypond "a/relative/path")
> to determine whether a target can be found within any LilyPond search
> path? Probably the function should return the absolut path, similar to
> what kpsewhich does.
>
> I need that to check whether a certain file is present (and then open
> it) without knowing the absolute location.
>
> Urs
>
>
>

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

Re: github mirror of lilypond?

2020-01-20 Thread Jürgen Reuter

   Hi all,

   +1 (at least) from me for for:

   * Having a smooth integration of git repository, review process and
   verify build.  If this is (as I conclude from the discussions) not
   possible with hosting the git repository on savannah, then please
   consider hosting the repository on a different platform.

   * Using Gerrit as review system (maybe unless you know of another
   system with equally smooth integration with git; but I do not know of
   any such system).  I am using Gerrit (the "old" version) at work and I
   am fully satisfied with its integration with git and Jenkins.
   I still have here ~12 mostly small commits (tiny fixes / features,
   clean-ups, code doc clarifications, etc.) lying around locally on my
   machine for several years.  I did not push them so far as I was (and
   still am) really scared about the time that I have to invest to get
   these commits through this complex process, especially as I expect at
   least some of the commits not to pass in the first go, but expecting
   possibly controversial reviews.
   Maybe the current process feels not that complex if you are committing
   regularly.  But I perceive it as complex, especially with respect to
   the time that I fear to have to put into the process rather than being
   productive, given my very limited time budget.  And I think, other
   people perceive it similarly.

   And of course, a big thank you to all of you that do all the great
   work, that I really appreciate!  But to attract more developers and /
   or re-animate retired developers, I am pretty sure that the process has
   to be simplified for potential "casual" committers like me that will
   contribute only now and then.

   Best wishes,
   Jürgen

Re: Is the CG out of date?

Thursday, January 16, 2020, 7:40:55 PM, you wrote:

> Hello,

> On 16/01/2020 14:52, Peter Toye wrote:
>> Tuesday, January 14, 2020, 10:31:49 PM, you wrote:

>>
>> It looks as if one of my jobs is going to be bringing the CG up to date. But 
>> as I'm a total newbie here I'll need support in making sure that anything I 
>> write is accurate. Will the LilyDev system be likely to change in the near 
>> future? In that case there wouldn't be any point.

>>
> Perhaps the best way would be to 'remove'
> information from the CG and
> replace it with reference/links to the github location rather than
> duplicate instructions.

Good idea.. But until I can get an answer to the mail I posted on this list on 
18th I can't do anything at all :(

> James

Peter

Extension management, first sketch

Hi,

one of the results of yesterday's developer meeting in Salzburg
[someone™ should provide a more concise summary than the notes in the
GoogleDoc] was that I should go forward "integrating openLilyLib" as
LilyPond's official extension mechanism.

I spent my travel back home reading through the code and writing a few
summaries and drafts etc., and while doing so I came to the conclusion
that the actual task, i.e. what has to be done "now" is surprisingly
(not to say, disappointingly) small.

I think it is best to start a discussion without looking at the current
implementation at all, so any issues (architecture considerations or
coding critique) with the existing oll-core code base won't distract us
from the conceptual perspective. So I wrote up a very short summary of
how I think an extension system should look like and what initial steps
there are to be taken. If anything is unclear or needs more factual or
conceptual detail I'll of course happily expand on it.

For reading convenience I attach a PDF version, but for inline
commenting the text below should be better.

Best
Urs


## Current State

* openLilyLib is a set of extension packages, providing high-level
  functionality
* `oll-core` provides the basic interface and implements required and
  additional functionality.

## Overall Outline

* Relevant functionality will be moved from `oll-core`
  to LilyPond proper, providing the main extension mechanism
  as well as some of the additional functionality (option
  handling, logging ["oll:" function to report status and errors]).
* The extension mechanism provides the commands `\loadPackage` and
  `\loadModule`, and it allows configuration options to be passed to
  either. It also handles package dependencies and implicit loading.
  (one example for using options (just for getting an idea) would be
  \loadPackage \with { modules = annotate.choice } scholarly. )
* This will *not* be called openLilyLib anymore (but "is" LilyPond's
  unnamed extension mechanism).
* A core extension library shipping with LilyPond will be initiated. 
  Extensions that are considered core functionality (prime candidates:
  edition-engraver, stylesheets) will eventually be moved here from
  openLilyLib, additionally special functionality (e.g. gregorian.ly,
  arabic.ly) may over time be moved there to expose the difference
  between core functionality and use-case specific modules more 
  clearly. These tools will then be called through `\loadModule`
  instead of `\include`, which will be easy to handle with
  convert-ly rules. Probably it would be a good idea to eventually 
  expose *all* non-standard notation through explicit packages
  and have that nicely describe in the LM. This too will not be
  called openLilyLib.
* openLilyLib will remain similar to what it is now, a curated
  collection of standard packages that are not mature enough or too
  specific to be included in LilyPond itself. The extension mechanism
  will find openLilyLib packages through LilyPond's search path.
* Packages can be stored anywhere on disk (=> LilyPond search path),
  so on the long term it may be interesting to set up an uncurated 
  package manager like npm or CTAN/TeX Live.
* Frescobaldi will provide a user interface to manage extensions but
  also for using them in documents (e.g. it will know about available
  configuration options and provide an action (context menu/dialog)
  to use a given package).


roadmap.pdf
Description: Adobe PDF document

Re: Context paths (and the Edition Engraver)

Dan Eble  writes:

> 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 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.  It seems that the applicability inside of
LilyPond currently is sufficiently vague that merging EE and LilyPond
core usage in that manner makes sense only if the solution is not
awkward for either LilyPond or EE in some manner: we don't want subtly
different and/or less than useful semantics.

> 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.  — Dan

Comments from the EE crowd?

-- 
David Kastrup

Finding files in include paths