You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we register a new pybind11._class object in an external module, it will store its type_info / tinfo struct in its own copy of internal registered python types.
If an object created in this way is passed to another independently compiled library (in this case libsrf_pysrf), subsequent calls to get_internals().registered_types_py[ object type ptr ] won't find the expected type type_info structure.
Since we can't rely on this behavior, we need to attach the wrapped cpptype as an out of band attribute for the class object. This is necessary so that we can match the internal PortAdapter type_id with the type_id of the wrapped object.
The text was updated successfully, but these errors were encountered:
1. Adds a new API call to `LinearPipeline`, `add_segment_boundary([data_type], [is_shared_pointer])`, which will create an egress stage and connected to the most recent linear stage, and an ingress source stage in a new segment. At `build`, these stages will be connected.
Known issue here: nv-morpheus/MRC#176 : Currently specifying the data type has no effect and all underlying objects will utilize the default PythonObject path. This is due to the method we were using to match the `cpptype` of a wrapped python object to the cpptype of an Ingress/EgressPort adapter. Once we're able to add an out of band path for type detection/storage this will be resolve.
2. Updates `Pipeline` to be segment aware, and makes the necessary updates to Pipeline internals to handle the changes.
3. Updates the `visualize(..)`
Authors:
- Devin Robison (https://github.com/drobison00)
Approvers:
- David Gardner (https://github.com/dagardner-nv)
- Christopher Harris (https://github.com/cwharris)
URL: #374
Describe the bug
If we register a new pybind11._class object in an external module, it will store its
type_info
/tinfo
struct in its own copy of internal registered python types.If an object created in this way is passed to another independently compiled library (in this case libsrf_pysrf), subsequent calls to
get_internals().registered_types_py[ object type ptr ]
won't find the expected typetype_info
structure.Since we can't rely on this behavior, we need to attach the wrapped cpptype as an out of band attribute for the class object. This is necessary so that we can match the internal PortAdapter type_id with the type_id of the wrapped object.
The text was updated successfully, but these errors were encountered: