Re: guilev1/2 musing

[Jan-Peter Voigt]

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.

Jan-Peter 

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,
>including
>> 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 
>guile1.)
>
>Does anyone know where to locate them?  I did some searching and came
>up 
>short.  They are "Pattern Matching (ice-9 match)" and "SXML" modules in
>
>the current guile2: 
>https://www.gnu.org/software/guile/manual/html_node/Guile-Modules.html
>
>
>>> 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
>to
>> 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
>on 
>guile2.
>
>>> 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
>many
>> open ends, this is more or less the "who decides to invest
>significant
>> work gets to decide on the approach".  There is not much of a point
>in
>> 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.
>
>Cheers,
>-Paul
>
>
>_______________________________________________
>lilypond-devel mailing list
>address@hidden
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

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