Hi Chris,
As promised, I’ve attached the report from the crash that occurred yesterday while changing the RF finder stimulus’ center y coordinate. I hope this helps, and let me know if you’d like me to send the code that we were running.
Thank you!
Jack
Hi Jack,
This is another instance of a legitimate error in the experiment not being handled properly by MWorks.
The error is in the crash log:
Vertex coordinate grid does not contain all points in the shape: coordinate grid covers (-1.85, -1.85) to (1.85, 1.85), but shape points range from (-1.67976, -1.6914) to (1.67976, 1.99863)
In other words, the grid you’ve defined via vertex_coord_center_x/y and vertex_coord_range doesn’t cover all the points in the shape. I thought refusing to load the stimulus was the right call in this situation, since I couldn’t think of why you wouldn’t want the full shape to be visible. However, if you think a warning would be more appropriate, we can do that instead. (FYI, it might be easier just to set vertex_coord_center_x/y and omit vertex_coord_range, in which case MWorks will compute the appropriate range that fits all the shape’s points with the given center.)
Unfortunately, MWorks isn’t handling the error properly, which leads to the crash. I will fix that ASAP.
Cheers,
Chris
Hi Chris,
Thank you for looking into this! It’s strange that the range was the issue,
considering that I’d been able to easily change the ranges in response to
previous errors, so I’d originally thought it was specifically related to
the central coordinates alone. Maybe you’re right that a warning would be
better, and having an automatically computed range also seems fine to me,
as long as none of the shape is cut off.
Thanks again,
Jack
Hi Jack,
It’s strange that the range was the issue, considering that I’d been able to easily change the ranges in response to previous errors
Yeah, the specific situation was that the stimulus was being loaded via a variable-attached action, the variable was being assigned as the result of a keyboard input, and the thread where all that happened wasn’t catching the exception that the error raised. In other places (e.g. in a task state), the load failure would raise an error and stop the experiment, but it wouldn’t cause a crash. Like I said, I’ll add some code to guard against such crashes.
Chris
Hi Jack,
There are a few changes of interest to you in the current nightly build:
The parametric shape stimulus now warns (instead of raising an error) if the user-specified vertex coordinate grid doesn’t cover all the shape’s points.
The load_stimulus action now catches exceptions caused by loading failure and converts them in to error messages, which prevents them from causing MWServer crashes in places that aren’t expecting exceptions.
Unrelatedly, MWorks now embeds Python 3.10 (instead of 3.9). This means, e.g., that you’ll need to install a Python 3.10 build of pyserial whenever you upgrade to a new nightly.
Cheers,
Chris
Hi Chris,
Thank you for taking care of these issues! I’ve been testing everything out
today, and it all seems to be working, but I’ll notify you if we run into
any issues.
Best,
Jack