Re: GSoC in contemporary notations

[Urs Liska]

Hi Tsz Kiu,

Am 03.04.19 um 13:48 schrieb Tsz Kiu Pang:
> Hi Urs,
>
> Whether or not I'll be suitable to participate in GSoC, I am keen to 
> dive into openlilylib.


That would be great!


> On Thu, 21 Mar 2019 at 17:58, Urs Liska <address@hidden 
> <mailto:address@hidden>> wrote:
>
>
>     What you should do now is:
>
>       * [of course dive more into Scheme]
>       * get an understanding of openLilyLib with
>         a) https://github.com/openlilylib/oll-core/wiki
>         b) the code in that repository
>         c) looking at how other openLilyLib packages are built within that
>         infrastructure
>       * Form an idea how a contemporary notation package could be
>     approached
>         and discuss that with us
>       * Find some small things you could do to openLilyLib package(s)
>     to a)
>         practice and b) give us an opportunity to assess your work. If we
>         have some idea about your current familiarity with the matter
>     we can
>         find some suggestions for that.
>
> I was looking at the issues page on oll-core and there were a couple 
> that you opened two weeks ago.
> Also, it seems like there is quite a number of TODOs in the codes (in 
> oll-core/scheme, oll-core/util, and oll-core/internal).
> I am just wondering would these be "some small things" that I can do 
> to the oll package?


Most of the items on the issue tracker don't look like suitable 
first-time tasks. But there are actually two issues you could have a 
look at, both having to do with module loading. This may not be as 
attractive as adding shiny new features, but I think it is a good way to 
get a better understanding of how things are working in there.

https://github.com/openlilylib/oll-core/issues/43
https://github.com/openlilylib/oll-core/issues/39

43 is actually a "current" idea, but 39 is a limitation that really 
should be removed - especially since just last week someone else 
stumbled over the problem.

Both issues could be tackled by looking at the module handling code.

Handling metadata (issue 43) is done within \loadPackage, so you can 
follow the procedure calls to see how that package.cnf file is processed 
and metadata registered. \loadModule would then have to check not only 
(as it currently does) whether the entry file is found on disk but also 
(and before) whether the requested module is registered in the package's 
metadata.

Preloading package/module options would basically work by integrating a 
workaround. Currently options are set after a package or module has been 
successfully loaded. This means that *while loading* the package or 
module the user option is not available yet. Essentially using the \with 
{} clause to set options is currently only a nice way to do the 
package/module configuration for a user file, but user-provided options 
can't be used to control the way the package/module is *loaded*. I see 
two appraoches on how to solve the problem, and both are described in 
the issue on Github. [Edit: Actually I think the approach I just thought 
of and added as a comment there is the way to go]

Having thought of all this and doing some investigation *while* writing 
this email I came to the conclusion that looking into issue 39 with the 
approach described in 
https://github.com/openlilylib/oll-core/issues/39#issuecomment-479813636 
should be a good idea to start with, both getting a good idea how things 
work in oll-core and providing some very valuable improvement.

Best
Urs

> Kind regards,
> Tsz Kiu
>
>
>     HTH
>     Urs
>
>     >
>     > Kind regards,
>     > Tsz-Kiu
>     > _______________________________________________
>     > lilypond-devel mailing list
>     > address@hidden <mailto:address@hidden>
>     > https://lists.gnu.org/mailman/listinfo/lilypond-devel
>     _______________________________________________
>     lilypond-devel mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/lilypond-devel