[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guilev1/2 musing
Re: guilev1/2 musing
Sat, 26 Jan 2019 19:36:51 +0100
K-9 Mail for Android
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
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.
Re: guilev1/2 musing, Paul Morris, 2019/01/25
Re: guilev1/2 musing, Thomas Morley, 2019/01/25
- Re: guilev1/2 musing, (continued)
- Re: guilev1/2 musing, Valentin Villenave, 2019/01/25
- Re: guilev1/2 musing, David Kastrup, 2019/01/25
- Re: guilev1/2 musing, Thomas Morley, 2019/01/25
- Re: guilev1/2 musing, Valentin Villenave, 2019/01/28
- Re: guilev1/2 musing, Thomas Morley, 2019/01/28