Maximilian Knespel

This is currently not possible and might require some refactoring to do right. Is it important that threads are closed? If this is just about producer/consumer matching, then rapidgzip should...

> Is there a way to check the number of active rapidgzip threads? Not yet. You can add it, e.g., like this: ```diff diff --git a/src/core/BlockFetcher.hpp b/src/core/BlockFetcher.hpp index 448b1cca..0f4c0bed 100644...

Which version? Could you provide a minimal gzip file with non-private data that reproduces the error? How do you call rapidgzip exactly, with what arguments? Searching through the code, I...

How exactly are you calling gztool? and, wouldn't ratarmount solve your feature request? It has rapidgzip as a backend and exposes a view to the decompressed file via FUSE. You...

Ah ok, I was only thinking about byte offset. Lines are another matter altogether. And currently, the index does not store any line indexing information. However, I am working on...

> In the meantime I made some interesting observation, I wonder weather you could comment on them (or even include them into your benchmark). Even though, I did not turned...

Regarding the issue title, I see the following steps: - [x] Add read support for gztool indexes - [x] Add write support for gztool indexes - [x] Gather line information...

This took a bit longer and more code lines than I thought, especially the newline logic. And it still could benefit from many more unit tests, but at least there...

> 1. When a user wants to decompress from, lets say line 4000 to the very end of a file, currently one has to do something like > `--ranges 999T@4000L`...

I have pushed a fix for the stdin problem and will release 0.14.1 after the CI has finished. Thank you for noticing the bug! I have also added a test,...