[Top][All Lists]

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

Re: guilev1/2 musing

From: Jan-Peter Voigt
Subject: Re: guilev1/2 musing
Date: Sat, 26 Jan 2019 19:36:51 +0100
User-agent: K-9 Mail for Android

Hi Paul,

sorry for missing to mention your contribs! And thank you for the XML port.

I didn't look into the gsoc code lately, but perhaps the two projects dont need 
to compete?

I hope I can focus on my lily projects the next weeks.


Am 26. Januar 2019 18:18:48 MEZ schrieb Paul Morris <address@hidden>:
>On 1/25/19 10:43 AM, David Kastrup wrote:
>> Paul Morris <address@hidden> writes:
>>> One area where guile2 (and upcoming guile3) would be useful is for
>>> MusicXML export.  David Garfinkle's summer of code project (mentored
>>> by David Kastrup) made a start on using guile2's sxml and pattern
>>> matching procedures (which aren't in guile1)
>> They exist as Guile1 library, it's just that they are by default in
>> Guile2.  If we decided prepackaging Guile1 was the way to go,
>> the respective library version should be feasible as well.
>> No guarantees, but that was my impression.
>Ah, good to know they exist as guile1 libraries.  (I just assumed that 
>since guile2 was used for the gsoc project, that they didn't exist for 
>Does anyone know where to locate them?  I did some searching and came
>short.  They are "Pattern Matching (ice-9 match)" and "SXML" modules in
>the current guile2: 
>>> Since guile2 appears to work well enough at this point, aside from
>>> performance, would it be worth setting up a "guile2 and musicxml
>>> export" branch where we could land David Garfinkle's code and enable
>>> further work on MusicXML export?  It seems like a guile2 branch
>>> already exists to some extent?
>> Not really, and I don't think it makes sense to commit functionality
>> Guile2-only at this moment.
>Okay, and since the needed libraries exist for guile1, then work on 
>(that approach to) musicxml export doesn't need to be blocked waiting
>>> Then at some future point... either LilyPond moves to a future guile
>>> or we back-port the guile2 procedures to guile1.
>> "some future point" is just going to cause additional work.  We don't
>> really have the personnel to do non-essential/non-trivial work on two
>> separate implementations.
>Makes sense, and sounds like we don't need to wait for guile2 anyway.
>>> (Jan-Peter Voigt has also done separate work on MusicXML export, but
>>> my sense is that in the long run, the approach in the summer of code
>>> project would be preferable.)
>> I haven't looked at Jan-Peter's approach.  David Garfinkle's code is
>> mostly in the state of a solid first sketch, so a distribution-viable
>> production-ready code is still quite a bit of work away.  Without
>> anybody committed to take it considerably further, making decisions
>> based on its existence would seem to be a bit premature.  Like with
>> open ends, this is more or less the "who decides to invest
>> work gets to decide on the approach".  There is not much of a point
>> planning out in detail what nobody will pick up.
>Indeed, although, I've contributed a bit to Jan-Peter's code for this, 
>and would like to contribute more (as time allows) to see this feature 
>added to LilyPond.  But I've wondered which approach would make more 
>sense for eventual landing in LilyPond.  More consensus about the 
>approach, could encourage contributions by removing such questions.
>lilypond-devel mailing list

Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

reply via email to

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