Ever since I have started participating in LilyPond development, I've known that Guile plays an integral role in LilyPond's overall "functioning". The Guile library, libguile, allows access to Scheme code from C (or C++) code (and vice versa). Guile lies at the heart of LilyPond's infrastructure, so it's critical that LilyPond integrates well with Guile.
Recently, there have some dramatic changes to the Guile code base; basically, Guile has been modernized and now rightfully belongs in the 21st century.
Since Guile has seen such sweeping changes, it's not surprising that there might be some compatibility problems between Guile 1.9 (latest development series) and Lilypond. And... there are many problems. :-)
Some have been fixed. Some might (and hopefully will) be fixed before Guile 2.0 is released. One of the most annoying ones that the Guile devs are aware of is the removal of "currying" define forms. My commit here shows how I'm temporary working around this problem.
So, on to the "bugfix for the bugfix". One of the Guile-compatibility issues is an improvement that LilyPond needs to adapt to. I'm currently have a patch (posted here), but I apparently didn't test it well enough.
For those interested, the "#if !HAVE_GUILE_HASH_FUNC ..." part of the patch is not working because I forgot to include the header "config.hh". Funny thing is, after trying to include config.hh, some previously non-functioning #ifdefs started working, and some of the conditionally compiled code does not compile! :-) Oh, the joys of conditional compilation. I haven't checked yet, but that code has probably been untouched for five years. Compilers have improved tremendously over the past five years, so it doesn't surprise me that previously (supposedly) working code no longer compiles.
In other words, I have to amend my patch by including "config.hh" in the appropriate place, AND by fixing non-compiling code that, before including "config.hh", never compiled and was therefore unnoticed.
Happy Monday night!
05 April 2010
The bugfix for the bugfix
23 March 2010
Updates
I haven't posted an update to this blog in a long time. Well, I've been very busy with school; last term, I accompanied approximately 20 people, so that occupied much of my time.
My work with LilyPond has slowed down a little bit, but there is still a lot to do. The release manager, Graham, wants to release a new stable release 2.14 ASAP, but I'm not quite sure when that will really happen. There are still many critical issues to resolve; I want to help out more with this, but most of them are "over my head". Time invested in discovering solutions to one of these bugs might take me 20 hours, whereas the person who originally introduced the bug might be able to fix it in a half hour. Oh well, we'll get them fixed eventually.
I'm happy to report that LilyPond's SVG output is "production ready". Actually, it has been for a few months, but I haven't discovered any bugs besides this one. Honestly though, it's not too critical of a bug. I have a feeling most people will be using the SVG output for snippets less than a page long, so those use cases are not affected.
For now, my plans are to leave the SVG backend as is, unless I find a fix for #971. After 2.14 is out, then I'll start thinking about it again.
Some of my more immediate LilyPond goals:
- Add a new markup command, "path", that uses SVG path primitives and works for both the PS and SVG backends.
- Fix slur ugliness. My previous attempt to fix these issues failed not because I was off-track, but because a proper solution needs to be more comprehensive. If I claim to have fixed slurs, LilyPond users will really want them to be fixed (and beautiful).
- Port LilyPond to Guile (soon to be) 2.0.
- Start fixing bugs in librsvg, and in the far-off future, consider becoming the maintainer of this project. The entire GNU/Linux community will benefit from improvements to librsvg. All of GNOME uses this library, as well as other important programs like ImageMagick. I am so confused why it is not currently being maintained. :-(
