Hello!
Do we really want to keep:
1. The notion of a “binary-friendly” ISO-8859-1 encoding? It’s
actually mostly gone with the iconv change, since every textual
access goes through iconv. For binary accesses, the right API is
(rnrs io ports) or similar.
2. The #f <=> "ISO-88
> From:Ludovic Courtès
> To:guile-devel@gnu.org
> Cc:
> Sent:Monday, January 24, 2011 2:26 PM
> Subject:The “binary-friendly” Latin-1
>
> Hello!
>
> Do we really want to keep:
>
> 1. The notion of a “binary-friendly” ISO-8859-1 encoding? It’s
> actually mostly gone with the iconv chang
On 25 Jan 2011, at 00:21, Mike Gran wrote:
2. The #f <=> "ISO-8859-1" equivalence for ‘port-encoding’ and
‘set-port-encoding!’. Likewise, commit
d9544bf012b6e343c80b76bd5761b1583cc106a3 makes ‘port-encoding’
always return a string and pt->encoding always be non-NULL.
Is the cost
Hello!
>> 1. The notion of a “binary-friendly” ISO-8859-1 encoding? It’s
>> actually mostly gone with the iconv change, since every textual
>> access goes through iconv. For binary accesses, the right API is
>> (rnrs io ports) or similar.
>
> An equivalent question is if you care a
> From:Ludovic Courtès
> Hello!
>
> >> 1. The notion of a “binary-friendly” ISO-8859-1 encoding? It’s
> >> actually mostly gone with the iconv change, since every textual
> >> access goes through iconv. For binary accesses, the right API is
> >> (rnrs io ports) or similar.
> >
>
Hi!
Mike Gran writes:
>> From:Ludovic Courtès
>
>> Hello!
>>
>> >> 1. The notion of a “binary-friendly” ISO-8859-1 encoding? It’s
>> >> actually mostly gone with the iconv change, since every textual
>> >> access goes through iconv. For binary accesses, the right API is
>> >> (
is the wrong one. Either
be bold and get rid of strings for 2.0, or let them be both bytevector
and string functions for the foreseeable future.
If strings remain an option, there will have to be some mention of the
"binary-friendly" Latin-1 encoding. ;-)
Also, if bytevectors are go
rid of strings for 2.0, or let them be both bytevector
> and string functions for the foreseeable future.
>
> If strings remain an option, there will have to be some mention of the
> "binary-friendly" Latin-1 encoding. ;-)
I think recv and send should operate on byteve
se of strings is the wrong one. Either
>> be bold and get rid of strings for 2.0, or let them be both bytevector
>> and string functions for the foreseeable future.
>>
>> If strings remain an option, there will have to be some mention of the
>> "binary-friendly&qu
