Skip to content

Full Implementation of RosBagWriter#8

Open
Carter12s wants to merge 2 commits intoRosLibRust:masterfrom
Carter12s:implement-rosbag-writer
Open

Full Implementation of RosBagWriter#8
Carter12s wants to merge 2 commits intoRosLibRust:masterfrom
Carter12s:implement-rosbag-writer

Conversation

@Carter12s
Copy link
Copy Markdown

Addresses #3

Took a full swing at it, and did pretty thorough testing so I think the implementation is sound. Not very familiar with bag file format before this and the documentation is a little barren, so I hope I didn't miss anything major.

@Carter12s Carter12s force-pushed the implement-rosbag-writer branch from 65e8821 to cdece3f Compare March 10, 2026 18:57
@Carter12s
Copy link
Copy Markdown
Author

I ended up doing a bunch of CI runs over here: Carter12s#1

And CI is currently passing on my Repo, but I did have to do some fairly gross gymnastics to work around the MSRV of this project. I'm inclined to increase the MSRV in the release that add the Writer, but open to thoughts.

This PR also adds a devcontainer setup to simplify local environment setup as well as a CI setup with a ROS noetic installation to enable some integration testing. Happy to remove those or move to separate PRs.

Copy link
Copy Markdown
Collaborator

@newpavlov newpavlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't reviewed the writer implementation itself. Just several minor suggestions.

Comment thread src/error.rs

// Write-specific errors
/// I/O error during write operations.
IoError(std::io::Error),
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it's better to introduce a separate error type for the writer.

Comment thread src/writer/mod.rs
pub use write_cursor::WriteCursor;

#[cfg(test)]
mod integration_tests {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I prefer to keep integration tests in the tests/ folder and use unit tests mostly for testing private APIs.

Same for other tests in the sub-modules.

profile: minimal
# Pin dependencies for MSRV compatibility (Rust 1.63)
# Order matters: pin high-level crates before their transitive dependencies
- name: Pin MSRV-compatible dependency versions
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to just bump MSRV, update edition to 2024, and rely on the MSRV-aware resolver going forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants