Closed servoz closed 11 months ago
I'm OK to modify update_controller()
, no problem.
Are you doing it, or do you want me to do it ?
I can do it. But I've just tested the idea, there's no crash, but the value is modified in this case... that's not exactly what we want.
We want 1- to catch the exception, 2- inform the user (by printing in stdout the message sent by nipype for example), and 3- reset to the old value. Here, the third point doesn't work... I need to examine the codes. I'll have a look at V2 and V1.
This new issue is probably not linked to the graphical interface of Controller
but the way exclusive traits are handled in Controller
...?
The exception is raised from File "/data/Git_Projects/capsul/capsul/process/nipype_process.py", line 129, in sync_nypipe_traits
, which is a callback set on Capsul traits value changes, so if there is an exception there (in setting the nipype trait value), resetting the Capsul trait value should probably be done there before re-raising the exception.
Sorry I was on another project till now
This new issue is probably not linked to the graphical interface of Controller but the way exclusive traits are handled in Controller...?
Yes, that's right, it's more about how the controller handles the data than the GUI.
The exception is raised from File "/data/Git_Projects/capsul/capsul/process/nipype_process.py", line 129, in sync_nypipe_traits, which is a callback set on Capsul traits value changes, so if there is an exception there (in setting the nipype trait value), resetting the Capsul trait value should probably be done there before re-raising the exception.
You're right, the case is more complicated than simply adding the error class raised by nipype (which is what I thought at first) because there's a succession of callbacks (the capsul one you're talking about and the nipype one for managing mutually exclusive parameters). I confess I haven't yet found a way to correct the bug, as I didn't have much time this afternoon.
I have pushed an attempt to fix this, but I haven't tested it (I'm also on another job). Can you give it a try when you have a minute ?
Due to lack of time, I may have read what you wrote above a little too quickly... Indeed, we'll also have to reset the old value everywhere (controller and synchronization between values in the nipype and capsul processes!!!!). Your fix is effective @denisri , thank you! I'm pushing the change in soma and I think this ticket can now be closed.
Fixed for V1 and V2.
If the user makes a mistake and declares two mutually exclusive parameters, Mia crashes. We need to catch the exception and not crash.
To reproduce: -1 load a project with a ant.ni, deformation_file. 2- in Pipeline Manager, drag and drop the spm.Normalize12 brick in the nipype library (not the one coming from mia_processes). 3- right click on the brick then "Export all unconnected plugs" 4- click on the inputs brick then in the controller gui (right part of the PipelineManger) click Filter and define for image_to_align the anat.ni then for deformation_file the deformation_file.
Mia crash with the executions stack:
Maybe the best (simple) fix will be to catch (and just print the message exception in the stdout) ? Good candidate in update_plug_value_from_filter() for V1 controller (mia) and update_controller() for V2 (soma).
I'll do it as soon as possible for the V1 GUI.
@denisri for V2, I can see a solution. In update_controller() we only catch the traits.TraitError class. Would there be a issue catching
(traits.TraitError, OSError)
[l257 becomesexcept (traits.TraitError, OSError) as e:
] ??? because nipye raises anOSError
error if two mutually exclusive parameters are declared at the same time. If this causes a regression, we can see if we can catch the exception in populse_mia at the same time.