[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile foreign object interface

From: David Kastrup
Subject: Re: Guile foreign object interface
Date: Thu, 09 Mar 2017 22:59:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Thien-Thi Nguyen <address@hidden> writes:

> () David Kastrup <address@hidden>
> () Thu, 09 Mar 2017 00:00:48 +0100
>    [...] rather than [...] fork Guile 1.8 in order to actually
>    have some dependable functionality to base other work on.
> I intend to maintain 1.8 for the time being.  More precisely, i
> seek to apply bug fixes, improve documentation (both method and
> content), modernize the build system (tracking gnulib, autotools
> evolution), and (time and gumption permitting) refactor some
> internals.  If the gods smile, maybe a feature or two (always w/
> an eye on upward compatibility).
> If the changes to 1.8 that Lilypond requires fall into the above
> categories, perhaps we can avoid a fork.  Do you have a summary
> of those changes handy?

The changes to 1.8 that LilyPond requires is that Guile-1.8 needs to be
compilable with newer compiler versions and standards and that
distributions are confident enough about it to keep distributing it.

That's all: LilyPond works fine with Guile-1.8 as it is.

Yes, migrating to some sort of UTF-8 capable string scheme transcending
the "byte array" approach of Guile-1 would be nice but the Guile-2
approach would likely be a major performance hog and it does not make
sense for a Guile-1.8 fork to develop a different approach: any such
"different approach" fork should, if at all, focus on the Guile-2 code
base as a starting point.

Unless there is an approach that is so lightweight that it just fits
better when starting with the Guile-1.8 code base.

But all in all the most important thing LilyPond would want from
Guile-1.8 is not to die.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]