Vadim Kantorov

icon indicating a website link https://linkedin.com/in/vadimkantorov icon indicating an email [email protected]

icon location Paris, France

Results 640 comments of Vadim Kantorov

[Help document bug] For bsdtar, --help options doesn't list some options

oh, `--strip-components` is super-useful, nice that it's actually supported!

Lot of functions ignored

Also stumbled on `std::shared_ptr` not suppported: - https://github.com/mono/CppSharp/issues/1860

Add a new `offset` field to `struct archive_entry` and calculate/fill it accordingly - to record a byte offset of the entry, making `mmap`-ing the entry bytes possible for accessing uncompressed entries (in TAR, ISO, ZIP, CPIO etc)

What would be very useful I think is some function that can tell for a given `archive_entry`: - if it is indeed uncompressed (and thus can indeed be `mmap` or...

Add a new `offset` field to `struct archive_entry` and calculate/fill it accordingly - to record a byte offset of the entry, making `mmap`-ing the entry bytes possible for accessing uncompressed entries (in TAR, ISO, ZIP, CPIO etc)

Also, a question on `seek` for random access to ZIP with compressed entries. If we preserve the offset, would it work if we do `->client.seek` to this offset and reset...

Add a new `offset` field to `struct archive_entry` and calculate/fill it accordingly - to record a byte offset of the entry, making `mmap`-ing the entry bytes possible for accessing uncompressed entries (in TAR, ISO, ZIP, CPIO etc)

@nigels-com Meanwhile this feature is not added yet in libarchive core, I (with crucial help of @kientzle) implemented it in my hack https://github.com/vadimkantorov/libarchivedd which demonstrates its feasibility

Add a new `offset` field to `struct archive_entry` and calculate/fill it accordingly - to record a byte offset of the entry, making `mmap`-ing the entry bytes possible for accessing uncompressed entries (in TAR, ISO, ZIP, CPIO etc)

To ease implementing indexing by the users, if there are dev resources I think first the intermediate infra steps should be the focus. (First is seeking to compressed entries in...

Add a new `offset` field to `struct archive_entry` and calculate/fill it accordingly - to record a byte offset of the entry, making `mmap`-ing the entry bytes possible for accessing uncompressed entries (in TAR, ISO, ZIP, CPIO etc)

Also, adding some flags/props field in archive_entry allowing to determine if an entry is uncompressed or compressed and if compressed with which compressor. It's useful also to be able to...

Add a new `offset` field to `struct archive_entry` and calculate/fill it accordingly - to record a byte offset of the entry, making `mmap`-ing the entry bytes possible for accessing uncompressed entries (in TAR, ISO, ZIP, CPIO etc)

@kientzle Yeah, I see what you mean. If I have the time, I'll try to get to hacking first: - https://github.com/libarchive/libarchive/issues/2295 - https://github.com/libarchive/libarchive/issues/2306 - figure out how to spawn a...

[feature request] C# / .NET bindings for in-proc C-API and in-proc wrapper's C++-API

If anyone's searching, this seems to work to produce C-API bindings with CppSharp (https://github.com/vadimkantorov/tritonservercppsharp/blob/master/.github/workflows/tritonservercppsharp.yml and generated bindings at https://github.com/vadimkantorov/tritonservercppsharp/releases/tag/release) So if anyone cares to try to actually test these generated...

[feature request] C# / .NET bindings for in-proc C-API and in-proc wrapper's C++-API

In https://github.com/mono/CppSharp/issues/1860#issuecomment-2322838240 is claimed that using `shared_ptr` in C++ API are not ABI-portable. Not sure what it implies for tritonserver, but maybe if the C++ wrapper is considered for simplifying...