Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

[David Kastrup]

Leandro Doctors <address@hidden> writes:

> On Wed, 26 Feb 2020 at 18:56, Urs Liska <address@hidden> wrote:
>> I'd like to stress that the GSoC page lists
>> project *ideas*, and if you're specifically interested in Scheme stuff
>> you may as well suggest other topics than listed there.
>
> Sure, Urs :-)
>
> As I said before, I have only started reading the Ideas page.
> All I know right now is that I would like to work on a Scheme-related
> project :-)

Well, the relation to Scheme may be somewhat tenuous.  If you like
meddling with low-level stuff, though, there are several things.  The
Boehm-Demers-Weiser garbage collector used in Guilev2+ does not work
well with the amount of mark hooks LilyPond uses pervasively, and the
current master contains some fudging and secondguessing to ameliorate
the worst consequences.  Committing work upstream to the
Boehm-Demers-Weiser project that would be able to adapt to a high amount
of mark-hook-equipped data would certainly be a worthwhile and
Scheme-related project, but at a very, very low level.

Then there is the business of LilyPond startup times with Guilev2 due to
us not using byte-(pre)compiled files.  That is partly a matter of "just
doing it" but partly also of restructuring the way loading/compilation
works and/or redesigning the markup macro in LilyPond because it has
fundamental problems with separation of compile/eval passes.

Also very icky and involved, somehow related to or caused by a
particular Scheme implementation, but with limited expectation for
success within the scope of a GSoC project.

> I will clone Lilypond's repo, read the code and try building it, and
> get back with more specific details, if that's OK with you.

Have fun!

Another possibility would be to try one's hand at creating a pattern
matching engine akin to what is used in display-lily-music's internals,
but in LilyPond's note language (it would likely have to work with an
extension of the #{ ... #} construct).  That would allow for a kind of
pattern-based music manipulation that made music programming less
dependent on viewing everything through a Scheme lens.

Check out what is in scm/display-lily.scm and
scm/define-music-display-methods.scm and see whether this can inspire
you to imagine something more LilyPondish in syntax.  Of course, this is
more a project to get the user away from Scheme rather than to it, so it
might not fit your palate.

Just take a look at what you see LilyPond doing and whether you can
think of something, then ask on the list whether it is a good idea (most
ideas will likely have problems in design or execution that list people
can advise about).

-- 
David Kastrup