Allows to create owned samples when the publisher is reference-counted.

Note: This is only a first draft to request feedback. I'm happy to polish this PR if this change is desired.

Pre-Review Checklist for the PR Author

1. [x] Code follows the Rust coding style and is formatted with rustfmt
2. [ ] Branch follows the naming format (iox-123-this-is-a-branch)
3. [ ] Commits messages are according to this guideline
   • [ ] Commit messages have the issue ID (iox-#42 commit text)
   • [ ] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [ ] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [ ] Relevant issues are linked
6. [ ] Add sensible notes for the reviewer
7. [ ] All checks have passed (except task-list-completed)
8. [ ] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes TBD

Fixes #17

The build issue is not related to libacl1-dev.

The problem actually seems to be that the current make_and_install() function is not dealing with the cpptoml dependency of iceoryx_posh correctly.

This in turn leads to a failure with the cmake configuration of iceoryx_posh. You can check this by inspecting the ./target/iceoryx-install/include/* folders. Basically the iceoryx_posh include folder is missing, leading to the error message referenced in the issue.

The PR essentially just mimics the recommended way to build iceoryx itself. Admittedly this is not ideal in terms of minimal compilation. On the other hand, it seems to work reliably. Please, feel free to optimize!

I have also taken the liberty to bump ICEORYX_VERSION to v2.0.2.

Pre-Review Checklist for the PR Author

1. [x ] Code follows the Rust coding style and is formatted with rustfmt
2. [x ] Branch follows the naming format (iox-#123-this-is-a-branch)
3. [ ] Commits messages are according to this guideline
   • [ ] Commit messages have the issue ID (iox-#42 commit text)
   • [ ] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [x ] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [x ] Relevant issues are linked
6. [x ] Add sensible notes for the reviewer
7. [x ] All checks have passed (except task-list-completed)
8. [ x] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes TBD

Since the data of the samples is not initialized, this should be reflected by the type system with MaybeUninit. The user then either has to use assume_init before sending the sample or it might be done under the hood. Alternatively MaybeUninit<T> could be transmuted to T.

Pre-Review Checklist for the PR Author

1. [x] Code follows the Rust coding style and is formatted with rustfmt
2. [x] Branch follows the naming format (iox-#123-this-is-a-branch)
3. [x] Commits messages are according to this guideline
   • [x] Commit messages have the issue ID (iox-#42 commit text)
   • [x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [x] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [x] Relevant issues are linked
6. [x] Add sensible notes for the reviewer
7. [x] All checks have passed (except task-list-completed)
8. [x] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• [x] Commits are properly organized and messages are according to the guideline
• [x] Code according to our coding style and naming conventions
• [x] PR title describes the changes

Post-review Checklist for the PR Author

1. [x] All open points are addressed and tracked via issues

References

• Closes #17

Brief feature description

Our service uses iox-roudi when communicating with cyclonedds shm.

Since cyclonedds depends on the iox-roudi service, we have to start the iox-roudi service before running our own C++ service.

Is there any sdk way to integrate iox-roudi in our C++ system?

Pre-Review Checklist for the PR Author

1. [x] Code follows the Rust coding style and is formatted with rustfmt
2. [x] Branch follows the naming format (iox-123-this-is-a-branch)
3. [x] Commits messages are according to this guideline
   • [x] Commit messages have the issue ID (iox-#42 commit text)
   • [x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [x] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [x] Relevant issues are linked
6. [x] Add sensible notes for the reviewer
7. [x] All checks have passed (except task-list-completed)
8. [x] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes #36

Pre-Review Checklist for the PR Author

1. [x] Code follows the Rust coding style and is formatted with rustfmt
2. [x] Branch follows the naming format (iox-123-this-is-a-branch)
3. [x] Commits messages are according to this guideline
   • [x] Commit messages have the issue ID (iox-#42 commit text)
   • [x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [x] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [x] Relevant issues are linked
6. [x] Add sensible notes for the reviewer
7. [x] All checks have passed (except task-list-completed)
8. [x] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Relates to #10

Pre-Review Checklist for the PR Author

1. [x] Code follows the Rust coding style and is formatted with rustfmt
2. [x] Branch follows the naming format (iox-123-this-is-a-branch)
3. [x] Commits messages are according to this guideline
   • [x] Commit messages have the issue ID (iox-#42 commit text)
   • [x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [x] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [x] Relevant issues are linked
6. [x] Add sensible notes for the reviewer
7. [x] All checks have passed (except task-list-completed)
8. [x] Assign PR to reviewer

This PR renames the POD marker trait to ShmSend since it fulfills a similar purpose to Send but instead to mark data types to be transferred across thread boundaries it marks data types to be transferred across process boundaries.

Furthermore, there are additional impls for ShmSend.

Notes for Reviewer

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes #27

Pre-Review Checklist for the PR Author

1. [x] Code follows the Rust coding style and is formatted with rustfmt
2. [x] Branch follows the naming format (iox-#123-this-is-a-branch)
3. [x] Commits messages are according to this guideline
   • [x] Commit messages have the issue ID (iox-#42 commit text)
   • [x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [x] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [x] Relevant issues are linked
6. [x] Add sensible notes for the reviewer
7. [x] All checks have passed (except task-list-completed)
8. [x] Assign PR to reviewer

Notes for Reviewer

This PR refines and updates the API to match the iceoryx v2 functionality.

The PR should be merged after #22

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes #23

Pre-Review Checklist for the PR Author

1. [x] Code follows the Rust coding style and is formatted with rustfmt
2. [x] Branch follows the naming format (iox-123-this-is-a-branch)
3. [x] Commits messages are according to this guideline
   • [x] Commit messages have the issue ID (iox-#42 commit text)
   • [x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [x] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [x] Relevant issues are linked
6. [x] Add sensible notes for the reviewer
7. [x] All checks have passed (except task-list-completed)
8. [ ] Assign PR to reviewer

Notes for Reviewer

This is based on #36 which needs to be merged first.

All the public API should now be documented and the documentation is enforced for writing new public API.

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes #4

Pre-Review Checklist for the PR Author

1. [ ] Code follows the Rust coding style and is formatted with rustfmt
2. [ ] Branch follows the naming format (iox-123-this-is-a-branch)
3. [ ] Commits messages are according to this guideline
   • [ ] Commit messages have the issue ID (iox-#42 commit text)
   • [ ] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [ ] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [ ] Relevant issues are linked
6. [ ] Add sensible notes for the reviewer
7. [ ] All checks have passed (except task-list-completed)
8. [ ] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes TBD

Required information

According to: https://doc.rust-lang.org/nomicon/repr-rust.html

There is no indirection for these types; all data is stored within the struct, as you would expect in C. 
However with the exception of arrays (which are densely packed and in-order), the layout of data is 
not specified by default.

Translated it means, when I have a struct:

struct A {
    a: u8,
    b: u32,
    c: u16,
}

The memory representation can look like:

struct A { // version 1 
    a: u8,
    _pad1: [u8; 3], // to align `b`
    b: u32,
    c: u16,
    _pad2: [u8; 2], // to make overall size multiple of 4
}

or for instance like this:

struct A { // version 2
    b: u32,
    c: u16,
    a: u8,
    _pad: u8,
}

Therefore, we require #[repr(C)] for interoperability with C - which is already done in the Counter type in the example.

But I think this is also a hard requirement for communication between rust only apps. Otherwise it is possible that one app uses version 1 of A and the other one is using version 2?!

Could a possible solution to this problem be a custom trait (which already exists under the name ShmSend) in combination with a custom derive? This also could be a very ugly problem for the untyped rust api when one acquires memory and writes the custom type later in it.

Pre-Review Checklist for the PR Author

1. [ ] Code follows the Rust coding style and is formatted with rustfmt
2. [ ] Branch follows the naming format (iox-123-this-is-a-branch)
3. [ ] Commits messages are according to this guideline
   • [ ] Commit messages have the issue ID (iox-#42 commit text)
   • [ ] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
4. [ ] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
5. [ ] Relevant issues are linked
6. [ ] Add sensible notes for the reviewer
7. [ ] All checks have passed (except task-list-completed)
8. [ ] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Relates to #64

Right now the only way to initialize a Runtime is through the init function. This function blocks until it establishes a connection to the RouDi daemon, or terminates the whole process on a timeout. This is not desired for robust applications, so it would be good to also have a try_init(app_name) -> Result function that just returns an error in this case. Ideally, the wait timeout would also be configurable.

would be nice if you guys could publish a new release crate with a version bump. i tried running the examples in the dir and they don't compile on 0.1.0, i had to check out the version from latest master branch. thanks

Brief feature description

iceoryx builtin types like iox::cxx::string and iox::cxx::vector should be supported

Detailed information

The idea is to have something similar to this https://docs.rs/cxx/latest/cxx/#builtin-types

So there would be a CxxString, IoxString or IoxCxxString which would have the same layout as the C++ counterpart. What makes things interesting is the template argument but that should also be solvable.

We would have to be really carefully with this and need to adapt the types when the ABI of the C++ counterpart changes.