Re: Conduit missing closing file handles
Henning Thielemann <[email protected]> Fri, 1 May 2026 21:56:29 +0200 (CEST)
| Newsgroups | gmane.comp.lang.haskell.cafe |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 1 May 2026, Tom Ellis wrote: > On Fri, May 01, 2026 at 07:42:00PM +0200, Henning Thielemann wrote: >> On Fri, 1 May 2026, Tom Ellis wrote: >>> Thanks, I fixed the bug. You can get the fixed version from: >>> >>> https://github.com/tomjaguarpaw/ad/blob/353fd275123a1ca50c7981349ec25c3997d4a18e/BluefinZipTar/BluefinZipTar.hs >>> >>> Please let me know if it works. (I included a main for testing >>> purposes, but you still just need convertZipToTar and its >>> dependencies.) >> >> It works indeed, now! > > Great. If you think this kind of thing is useful to you I can try and > make it suitable for publishing in a library. I'd say with the current excess of open file handles, zip2tar is pretty useless. >> That is, you are in a way able to convert Conduits to your Bluefin >> transformers? > > Yes, it's fairly easy to run a Conduit in a form compatible with > Bluefin, like fromConduit does here: > > https://github.com/tomjaguarpaw/ad/blob/a6a681587114af3c2210cee4b31d6f505a65ae1f/BluefinZipTar/BluefinZipTar.hs#L179-L190 > > But getEntrySource was written with the wrong primitives, blocking > prompt finalization, so I had to rewrite that. Instead of writing and maintaining two new libraries for ZIP and TAR handling, would it work to submit improved getEntrySource based on Conduit to the 'zip' package project and use Bluefin only in zip2tar? Or do I still need Bluefin at all, once getEntrySource is updated? _______________________________________________ Haskell-Cafe mailing list -- [email protected] To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.