-
Notifications
You must be signed in to change notification settings - Fork 57
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
[WIP] Continue development and upstream #94
[WIP] Continue development and upstream #94
Conversation
a4621c7
to
feb56f9
Compare
feb56f9
to
866834a
Compare
Hello. What is the state of this development now? |
This is work in progress, though we use this internally for our products as we need the features right now. @esteve stated some days ago that he wants to look at my other PRs (that this is based on) and likely merge them to main: #90 (comment) |
0a16152
to
6292527
Compare
6292527
to
75806e6
Compare
75806e6
to
712a7e0
Compare
…per types" With "action wrapper types" this means the ROS messages and services that add the `GoalId`, `TimeStamp` or other fields on top of the user defined types for the action. The introduced methods in `IRosActionDefinition` are needed to work around the missing existential type support in C# (dotnet/csharplang#5556).
…apper types" This uses the base type `IMessage` to get around the cyclic references.
The field access after Interlocked.CompareExchange might not reflect the updated value. Or does it? Anyways this makes it more clear.
This does not change the C# side of the generated messages to avoid even more complexity in the templates. As bools in C# pInvokes get marshalled as 32 bit integer by default there is no strictly need to change the code for bool fields.
Most of the documentation was taken from ros2_rust. https://github.com/ros2-rust/ros2_rust/blob/main/rclrs/src/qos.rs
712a7e0
to
677aa1a
Compare
Closing this PR as all parts where now extracted into seperate PRs and only one PR is missing to be merged. So this PR dosn't provide any more use (for now it was the PR with all not merged changes integrated), but as only one is left to merge #108 can be used instead. This is the list of all PRs that came out of this: |
from #49 (comment):
Now we are at the state where we need action support next.
As described above we would like to contribute to the open and avoid doing a hard fork.
This PR is a grab bag of what is comming next on our development roadmap for this library.
I avoid to do multiple PRs that depend on each other for now, those will be done one the main branch moves forward. I will be using prefixes in the commit messages how those would be grouped to seperate PRs so this should be easyer later on.
Current roadmap:
GuardConditions
.SynchronizationContext
to make async code easier. -> Add support for SynchronizationContext #112cc @esteve @ooeygui @shschaefer