[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guilev1/2 musing
Re: guilev1/2 musing
Sat, 26 Jan 2019 12:18:48 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
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
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:
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
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
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.
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, Thomas Morley, 2019/01/24
- Re: guilev1/2 musing, Karlin High, 2019/01/24
- 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