On 2/16/21, Dominik Pantůček wrote:
>
> On 16. 02. 21 22:27, Matthew Flatt wrote:
>> At Tue, 16 Feb 2021 16:03:29 -0500, Ben Greenman wrote:
>>> Sadly, I've already compressed a few files using
>>> `call-with-output-string` ... is there an easy way to decompress those
>>> / undo the UTF-8
On 16. 02. 21 22:27, Matthew Flatt wrote:
> At Tue, 16 Feb 2021 16:03:29 -0500, Ben Greenman wrote:
>> Sadly, I've already compressed a few files using
>> `call-with-output-string` ... is there an easy way to decompress those
>> / undo the UTF-8 encoding?
>
> Unfortunately, the underlying
At Tue, 16 Feb 2021 16:03:29 -0500, Ben Greenman wrote:
> Sadly, I've already compressed a few files using
> `call-with-output-string` ... is there an easy way to decompress those
> / undo the UTF-8 encoding?
Unfortunately, the underlying `get-output-string` conversion is lossy,
because bytes
On 2/16/21, Matthew Flatt wrote:
> At Tue, 16 Feb 2021 15:44:54 -0500, Ben Greenman wrote:
>> But in my compressed string, the second
>> byte is #o357 for some reason. I'm not sure how that could have
>> happened ... some kind of encoding issue with string ports?
>
> Yes.
>
> You want
At Tue, 16 Feb 2021 15:44:54 -0500, Ben Greenman wrote:
> But in my compressed string, the second
> byte is #o357 for some reason. I'm not sure how that could have
> happened ... some kind of encoding issue with string ports?
Yes.
You want `call-with-output-bytes` on the compress size and
5 matches
Mail list logo