Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[David Kastrup]

Don Armstrong <address@hidden> writes:

> On Sun, 21 Sep 2014, David Kastrup wrote:
>> Don Armstrong <address@hidden> writes:
>> 
>> > Could you point me at a list of guile 2.0 bugs which are affecting
>> > lilypond? Having that list handy would help me convince the guile
>> > maintainer (and also Debian's release managers and security) that
>> > there were valid reasons to keep guile 1.8 for another release of
>> > Debian.
>> 
>> At the current point of time I cannot point to anything that I
>> consider beyond workaround. There are a number of stunners (for a
>> recent one, check out
>> <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18495>) that make it
>> likely that no application really uses the C APIs for interfacing data
>> into GUILE all that much.
>
> Heh. Yeah... that's pretty bad.
>
> Probably following 
> http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guile;address@hidden
> is good enough, then.

No, that does not make clear which problems can be worked around
reasonably easily, or which are proposals or fixes unrelated to LilyPond
(I mean, when I read code or write test programs while searching for the
cause of a problem and hit on some unrelated bad stuff, that does not
mean that LilyPond is affected).

> Thanks for the additional information! (And sorry if my original
> e-mail sounded like I was pressuring y'all to do work; I'm just trying
> to keep lilypond in Debian.)

Yes, that would be very desirable.  It's also worth noting that the
current development model of GUILE seriously mislabels the "stable
branch".  Basically the "stable" branch is where the normal developers
work, while "master" is the experimental branch from Andy Wingo, the
lead developer, which he works on without communicating with anybody
else.

If you take a look at
<URL:http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=NEWS;hb=stable-2.0>
you'll find things like

 208 * New deprecations
209
210 ** General 'uniform-vector' interface
211
212 This interface lacked both generality and specificity.  The general
213 replacements are 'array-length', 'array-ref', and friends on the scheme
214 side, and the array handle interface on the C side.  On the specific
215 side of things, there are the specific bytevector, SRFI-4, and bitvector
216 interfaces.
217
218 ** Use of the vector interface on arrays
219 ** 'vector-length', 'vector-ref', and 'vector-set!' on weak vectors
220 ** 'vector-length', 'vector-ref', and 'vector-set!' as primitive-generics
221
222 Making the vector interface operate only on a single representation will
223 allow future versions of Guile to compile loops involving vectors to
224 more efficient native code.
225
226 ** 'htons', 'htonl', 'ntohs', 'ntohl'
227
228 These procedures, like their C counterpart, were used to convert numbers
229 to/from network byte order, typically in conjunction with the
230 now-deprecated uniform vector API.
231
232 This functionality is now covered by the bytevector and binary I/O APIs.
233 See "Interpreting Bytevector Contents as Integers" in the manual.
234
235 ** 'gc-live-object-stats'
236
237 It hasn't worked in the whole 2.0 series.  There is no replacement,
238 unfortunately.
239
240 ** 'scm_c_program_source'
241
242 This internal VM function was not meant to be public.  Use
243 'scm_procedure_source' instead.

Interesting bunch of changes in a stable release branch.

Stuff like


923 ** `define-public' is no a longer curried definition by default
924
925 The (ice-9 curried-definitions) should be used for such uses.  See the
926 manual for details.

has also lead to annoyances.  It is worth noting that the
(ice-9 curried-definitions) module still is incomplete, and it's just
with quite recent versions that the implemented functionality is not
just buggy.  I've replaced all of the places in LilyPond where the bugs
hit with hand-expanded macros.  That gets rid of a large number of
problems that Ian Hulin tried to work around with symptom-based
workarounds (that just repeated stuff in a different manner when it did
not work in the intended manner).

Note that at the current point of time I cannot name an absolute
roadblock that could not get worked around.  It's just that going
through all the problems and finding solutions is like wading through
molasses and is giving one headache after another.  And I have no idea
when things will be getting better.

I've made quite a bit of progress in the last week, but it's not like
I'm anywhere where I would say "ok, now only few obscure problems
remain".  Basically, I can exercise the regtests in order to get the
next 5 strange problems to work on, rinse and repeat.

-- 
David Kastrup