Re: [racket-users] file/gzip trouble reading

2021-02-16 Thread Ben Greenman
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

Re: [racket-users] file/gzip trouble reading

2021-02-16 Thread Dominik Pantůček
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

Re: [racket-users] file/gzip trouble reading

2021-02-16 Thread Matthew Flatt
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

Re: [racket-users] file/gzip trouble reading

2021-02-16 Thread Ben Greenman
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

Re: [racket-users] file/gzip trouble reading

2021-02-16 Thread Matthew Flatt
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