Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clp-s: Delete clp_s::FileReader #664

Open
gibber9809 opened this issue Jan 15, 2025 · 4 comments
Open

clp-s: Delete clp_s::FileReader #664

gibber9809 opened this issue Jan 15, 2025 · 4 comments
Labels
enhancement New feature or request

Comments

@gibber9809
Copy link
Contributor

Request

There are not many uses of clp_s::FileReader left in our codebase, and clp-s is increasingly using readers from clp, so it would be beneficial to remove clp_s::FileReader as a step towards consolidating the reader classes for clp and clp_s.

Possible implementation

  • Remove remaining references to clp_s::FileReader or replace with clp::FileReader where required
  • Delete clp_s::FileReader
@gibber9809 gibber9809 added the enhancement New feature or request label Jan 15, 2025
aestriplex added a commit to aestriplex/clp that referenced this issue Jan 29, 2025
@aestriplex
Copy link

aestriplex commented Jan 29, 2025

@gibber9809 While I was familiarizing with the structure of the codebase, I came across this issue. I thought it was a good way to get an in-dept overview of the various modules. I made a commit with my changes, although it is probably too big to be put directly into a pull request. That is why I am starting to write comments here.

I followed this methodology:

  1. I deleted the clp_s::FileReader class in the clp_s module;
  2. I tried to compile the code progressively, fixing it whenever it did not compile;
    Quickly I realized that most of the changes involved error codes. The clip::FileReader class, in fact, returns the error codes defined in clp::ErrorCode, while the clp_s::FileReader, those defined in clp_s::ErrorCode. it seemed reasonable to me that by using clp::FileReader, it should also use clp::ErrorCode, because otherwise you would have to make clp::FileReader depend on clp_s::ErrorCode, which seems inconvenient to me;
  3. I ran all the unit tests to make sure they all passed.

I would like to specify that I did not replace all occurrences of clp_s::ErrorCode with clp::ErrorCode, but only those that did not compile as they were directly affected by the removal of clp_s::FileReader.

@gibber9809
Copy link
Contributor Author

Sorry @aestriplex, but changing instances of clp_s::ErrorCode to clp::ErrorCode is definitely not required to fix this issue. The current main users of clp::FileReader in clp_s already convert clp::ErrorCode to clp_s::ErrorCode when returning/handle clp::ErrorCode locally without propagating it in some way. Some of that translation between clp::ErrorCode and clp_s::ErrorCode could be better, but it's not an immediate concern.

The only real remaining user of clp_s::FileReader is the open(clp_s::FileReader&...) usage in clp_s::ZstdDecompressor + associated code, which can be safely deleted since it is unused. Besides that all you should have to do is delete includes for FileReader.hpp which were missed in previous commits, and add includes for "ErrorCode.hpp" where we had been depending on it being included indirectly via FileReader.hpp.

@aestriplex
Copy link

@gibber9809 Ok, thank you for your comment. I had misinterpreted the task. Tomorrow I'll focus on this

The only real remaining user of clp_s::FileReader is the open(clp_s::FileReader&...) usage in clp_s::ZstdDecompressor + associated code, which can be safely deleted since it is unused. Besides that all you should have to do is delete includes for FileReader.hpp which were missed in previous commits, and add includes for "ErrorCode.hpp" where we had been depending on it being included indirectly via FileReader.hpp.

aestriplex added a commit to aestriplex/clp that referenced this issue Jan 30, 2025
aestriplex added a commit to aestriplex/clp that referenced this issue Jan 30, 2025
@aestriplex
Copy link

@gibber9809 With this new commit, I deleted FileReader.hpp and FileReader.cpp from clp_s. I double-checked, and there is no reference left to FileReader.hpp. As for the open method of ZstdDecompressor, I noticed that it is an implementation of a virtual method of the parent class Decompressor, so at the moment I have not removed it. For now I have simply changed the method signature to

void open(clp::FileReader& file_reader, size_t file_read_buffer_capacity);

Last but not least, in `` I found a piece of code like

FileReader reader;
auto error_code = reader.try_open(input_path_list_file_path);
if (ErrorCodeFileNotFound == error_code) {
    SPDLOG_ERROR(
            "Failed to open input path list file {} - file not found", input_path_list_file_path
    );
    return false;
} else if (ErrorCodeSuccess != error_code) {
    SPDLOG_ERROR("Error opening input path list file {}", input_path_list_file_path);
    return false;
}

Since in cap::FileReader you have to pass the path to the constructor (that will eventually raise an exception, if the path you specified does not exist), I changed this code to

 try {
    clp::FileReader reader(input_path_list_file_path);
    ...
} catch (clp::FileReader::OperationFailed const& e) {
    SPDLOG_ERROR(
            "Failed to open file for reading - {} - {}",
            input_path_list_file_path,
            e.what()
    );
    return false;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants