"H. S. Teoh" <hst...@quickfur.ath.cx> writes: > Of course, the best scenario is that we figure out how to fix the > current guile2-related issues before LP 2.20 is released...
A lot of them require fixing Guile2. Guile2 has a string API where it will not accept anything but Latin-1 strings in a native encoding. Everything else requires recoding: it cannot work with utf-8 strings even though its API offers only utf-8 as encoding to pass into Guile's native (but inaccessible) UCS-32 strings. It does not allow string ports in any encoding but utf-8. It cannot even pass its own native strings through string ports without reencoding. Its reencoding is not transparent for non-proper utf-8. The Guile developers are in complete denial about the unsuitability for an extension language about Guile's call gates requiring reencoding for every string parameter. They are also in complete denial about the importance of interpreter speed for an _extension_ language: for them, compiler performance is everything. They also consider it "somebody else's problem" to organize the compilation and storage of byte code for an application. There is a lot in there where a solution simply cannot be achieved by LilyPond on its own, and a lot where a LilyPond-only solution makes very little sense in the overall Guile universe. > but that might need a lot more time. And we might want to keep LP 2.18 > in the distros in the meantime, which would mean bundling guile1.8 > with LP 2.18. I think that the most promising way of attack is to make sure that Guile-2.0 and Guile-1.8 libraries can be installed in parallel, and with parallel architectures (most libraries can, Guile-1.8 was not multiarch-capable when it was removed). When Debian can include Guile-1.8 without significant cost, why wouldn't they? I think that there lies our most promising approach in the short term. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
