Paul Morris <p...@paulwmorris.com> writes: > On 1/24/19 3:08 PM, Thomas Morley wrote: > >> From my point of view (and limited knowledge) other newly implemented >> guilev2-procedures are not _that_ important. > > 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. > to convert LilyPond's internal music data structures into MusicXML > output. > 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. > 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. > (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. > Thanks for the insights into the guile1/2 situation and what's causing > the performance hit. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
