🐛 generated quiddities from switcher are not handled by pyquid
Summary
The !409 (merged) merge request introduced some pythonic structures on top of the pyquid object and these structures are used deeply in swIO in order to facilitate the introspection of the quiddities wrapped as pyquid objects. As I enforced the adoption of these changes because I wanted to unlock the advances on swIO for the sake of Scenic 4.1, these changes are issuing bugs when a quiddity creation is triggered by internal processes. It implies:
- the loading of a session
- the reception and the wrapping of SIP sources
- maybe other generated quiddities I am not able to list here...
This bug is highlighted by the session test suite I am currently writing here !467 (merged) and this swIO feature is blocked by this one.
How to reproduce ?
From the session perspective: just loading a session will lead to missing pyquid information here because the pyswitch.get_quid
method is finding a corresponding pyquid
structure in the pyswitch.quiddities
list and it doesn't exist because it wasn't created by the pyquiddity
constructor. A lot of internal mechanism is missing but the main point of failure is here.
In addition, this constructor is using the quiddity::Container::quiet_create
that is preventing the signal quiddity.created
, the method body can be consulted here. The signal is launched by manually when the pyquid
structure is well initialised. This method is not used by the switcher internals when a session is loaded or a SIP source is wrapped: consequently, a quiddity.created
is triggered and is handled by swIO without implying the pyquid
sugar around them.
So, swIO
will fail because it won't be able to retrieve the pquid structure as it wasn't created before.
@djiamnot has hit this bug during the haptic floor residency when he tested the SIP reception, it prevented him using the quiddity.created
signal in order to handle a SIP source and send its shmdata to dboxer. You can check its workaround there.
Expected behavior
All quiddities should be available when the quiddity.created
signal is triggered whatever the way to handle it, I don't think enforcing the pyquid initialisation is the good way to handle this but it seems implying a lot of work I cannot do if I want to respect my ambition about the Scenic 4.1 milestone.
What is the frequency of occurrence of this behavior ?
100%
Other comment
As the pythonic sugar seems to be incompatible with the switcher internals, I see two ways to resolve this issue:
- removing the pythonic structures on top of pyswitch in order to reduce the
pyquid
custom structures: the major drawback is that these structures are making the use of switch with python better as it provides a pythonic introspection on quiddities. Also, this is significant amount of work and I don't think I can do it quickly. - enforcing the pythonisation of the quiddities when they are created, it implies using specific practices in order to patch the current behaviour. I think it will lead us to other issues as it will restrict the user to use specific methods. This is the more practical way to handle this bug without making a significant refactoring.
As I am choosing the option 2, my work lead me to purpose this mechanism:
-
refactoring the pySwitch.create
and the pyquiddity constructor in order to isolate the pythonic improvements. -
Add pythonize
method on to of pyswitch in order to apply these changes in an independent way. It should use this during the quiddity creation from pyquid as before so it shouldn't break the current test suite. -
Enfore the pythonization
of the generated quiddities when they are handled from thequiddity.created
signal, I purpose using thepythonize
method intopyswitch.get_quid
. Consequently, it should force the user to use this method when he handles created quiddity. This should be documented.
I should provide a merge request that reflects this strategy quickly, if you are opposing to this I am open for suggestions but you should help me for this implementation by indicating me where I should make the changes.