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 <p...@paulwmorris.com>: >On 1/25/19 10:43 AM, David Kastrup wrote: > >> Paul Morris <p...@paulwmorris.com> 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 >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
