-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
autopybind: Should test current workflows for automated bindings #14827
Comments
FYI @josephsnyder |
My plan is to make the PR, but will strive to record what was necessary to go from generated bindings to my own liking as well as reviewer acceptance. |
For @jamiesnape and @josephsnyder I've added opinionated steps that I took here to make initial state of #14828: Can both of you please review my steps here and let me know if there is anything better that I could have done? Given current workflow for a simple case, I would still like to wait until certain parts of the denoising happen before asking anyone else to run this. |
Tried |
I'm pausing any more of my effort on this until denoising lands. |
Closing out as "unlikely to reach an actionable state within a reasonable timeframe". |
As part of #7889, using #14265 (now #15205)
I've chosen the following symbols to genuinely try this workflow out on:
drake::geometry::render::RenderEngineGlParams
This has weird API (returns type fromdrake::multibody::StaticEquilibriumConstraint
internal::
namespace)drake::systems::sensors::Accelerometer
drake::systems::PortSwitch
drake::solvers::MixedIntegerBranchAndBound
drake::systems::SurfaceMesh
drake::multibody::MultibodyPlant
The text was updated successfully, but these errors were encountered: