[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC in contemporary notations

From: Urs Liska
Subject: Re: GSoC in contemporary notations
Date: Thu, 4 Apr 2019 11:05:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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
        b) the code in that repository
        c) looking at how other openLilyLib packages are built within that
      * Form an idea how a contemporary notation package could be
        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.

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


Kind regards,
Tsz Kiu


    > Kind regards,
    > Tsz-Kiu
    > _______________________________________________
    > lilypond-devel mailing list
    > address@hidden <mailto:address@hidden>
    lilypond-devel mailing list
    address@hidden <mailto:address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]