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 <li...@openlilylib.org
<mailto:li...@openlilylib.org>> 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
> lilypond-devel@gnu.org <mailto:lilypond-devel@gnu.org>
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org <mailto:lilypond-devel@gnu.org>
https://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
