[Top][All Lists]

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

Re: guile-2.0 and debian

From: Thomas Morley
Subject: Re: guile-2.0 and debian
Date: Sat, 12 Nov 2016 13:52:40 +0100

2016-11-12 13:39 GMT+01:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>> Then trying to build the docs:
>> make LANGS='' doc
>> I.e. a single core compilation for better tracking problems, only english 
>> docs.
>> It crashed because of string-filter and string-delete changed the
>> order of arguments in guile2, I patched it and tried again.
> Pffffft.  We can replace those occurences, either with something else or
> a conditional.  However, I read
> commit 9fe717e23c50680b77860dcb3e30b00184caba4f
> Author: Andy Wingo <address@hidden>
> Date:   Fri Nov 19 17:08:36 2010 +0100
>     fix string-filter and string-delete argument order
>     * libguile/srfi-13.h:
>     * libguile/srfi-13.c (scm_string_filter, scm_string_delete): Swap
>       char_pred and s argument order, to comply with SRFI-13. There is a
>       back-compat shim that will detect programs that used the old,
>       erroneous interface, while giving a warning.
>     * doc/ref/api-data.texi: Update docs.
> So what's up with the "back-compat shim" ?
>> Summary:
>> Ofcourse this is a very naive approach, using guile 2.0.11 not the
>> most current release.
>> Nevertheless I did not found any mentioning of string-delete and
>> string-filter being changed in previous discussions.
> Should just cause a warning though.


address@hidden ~/lilypondH/user/hilflos$ lilypond-git scheme-sandbox
GNU LilyPond 2.19.51
`scm-style-repl' in the default environment is deprecated.
Find it in the `(ice-9 scm-style-repl)' module instead, or
better yet, use the repl from `(system repl repl)'.
guile> (version)
guile> (string-delete "x y" char-whitespace?)
Guile used to use the wrong argument order for string-delete.
This call to string-filter had the arguments in the wrong order.
See SRFI-13 for more details. At some point we will remove this hack.

There _is_ a warning and the final result _is_ correct.

But while compiling the docs it returned an error, which did not occur
anymore after patching it.
Admittedly this was during a previous multi-core attempt, though this
should not make a difference.

>> Apart from the regtests compile (I did not
>> proof the output, though)
>> Any pointers how to continue?
> The main problem I remember was a coding problem.  It did not like
> working with UTF-8 characters.

Do you mean the encoding-problem is responsible for the failed
Or for the stuck while doc-building?


reply via email to

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