This was fixed in commit 4a81f5b, which will be in Guile 2.0.12:
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=4a81f5b5d3800aafbc25452e50459c1ba6e29fea
In the meantime you’ll have to fix the installed ‘guild’ script by hand.
Thanks,
Ludo’.
Andreas Enge skribis:
> guile-2.0.11 fails to build on Redhat 6.5 with the following error message:
>
> CC libguile_2.0_la-fports.lo
> fports.c: In function 'fport_input_waiting':
> fports.c:612: error: variable 'pollfd' has initializer but incomplete type
> fports.c:612: warning: excess
This has been addressed in two ways:
1. In 2.0, (srfi srfi-6) uses Unicode-capable string ports (commit
ecb48dc.)
2. In 2.2, string ports are always Unicode-capable, and
‘%default-port-encoding’ is ignored (commit 6dce942.)
So for 2.0, the workaround is to either use (srfi srfi-6),
I see my reply failed to address some of the points raised.
David Kastrup skribis:
> Guile-2.2 does not consult %default-port-encoding but uses UTF-8
> consistently (I guess, overriding set-port-encoding! will again change
> that).
>
> That still is not satisfactory. For example, using ftell on
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> Guile-2.2 does not consult %default-port-encoding but uses UTF-8
>> consistently (I guess, overriding set-port-encoding! will again change
>> that).
>>
>> That still is not satisfactory. For example, using ftell on the input
>>
l...@gnu.org (Ludovic Courtès) writes:
> This has been addressed in two ways:
No, it hasn't.
> 1. In 2.0, (srfi srfi-6) uses Unicode-capable string ports (commit
> ecb48dc.)
This issue report is not about adding more optional functionality on
top. It is about _removing_ unwarranted redi
David Kastrup skribis:
> I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its
> own UTF-8 verification, error flagging, processing and indexing.
Do I understand correctly that LilyPond expects Guile strings to be byte
vectors, which it can feed with UTF-8 byte sequences that it
David Kastrup writes:
> Mark H Weaver writes:
>
>> I can take care of doing this myself, and will of course still credit
>> you in whatever manner you prefer, but I've run into a legal problem: we
>> don't currently have copyright papers for you on file. Are you willing
>> to file copyright pap
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>
>> I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its
>> own UTF-8 verification, error flagging, processing and indexing.
>
> Do I understand correctly that LilyPond expects Guile strings to be byte
> vectors, wh
Mark H Weaver writes:
> The fact that the SRFI-1 reference implementation of 'length+' is lax
> very nearly swayed me over to your position, but there's a problem:
> Guile's 'length+' has (always?) returned #f for dotted lists. It would
> be dangerous to silently change the behavior of this case
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> I can take care of doing this myself, and will of course still credit
>>> you in whatever manner you prefer, but I've run into a legal problem: we
>>> don't currently have copyright papers for you on file. Are you
David Kastrup skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> David Kastrup skribis:
>>
>>> I'm currently migrating LilyPond over to GUILE 2.0. LilyPond has its
>>> own UTF-8 verification, error flagging, processing and indexing.
>>
>> Do I understand correctly that LilyPond expects Guil
l...@gnu.org (Ludovic Courtès) writes:
> David Kastrup skribis:
>>
>> For error messages, yes. For associating a position in a string with a
>> previously parsed closure, no.
>
> But wouldn’t a line/column pair be as suitable as a unique identifier as
> the position in the file?
As long as the
13 matches
Mail list logo
