philipstarkey
commented
5 years ago Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
I see - it sounds like what's going on might be something like the following. There are two globals with the same name. Runmanager sees that one of them is iterable, but when it gets the actual value, it obtains the value associated with the other one, which is not iterable. There are probably order-dependent effects since runmanager stores the globals and their details in dictionaries.
The solution would be for runmanager to check for duplicate names before evaluating anything. It shouldn't proceed if there are duplicate names. It does this check at some point but evidently not early enough. I'll investigate.
Original report (archived issue) by Lars Kohfahl (Bitbucket: lkohfahl, GitHub: lakodarmstadt).
We have encountered a bug when having two groups with conflicting globals. To reproduce the error seems a bit tricky. This is the way it should work: Our example is that we have two groups named "testing" and "testing_2" with the same named globals (e.g. "pb_time") in it. Runmanager detects this error correctly. But when changing the global in both groups to a list and activating them, at some point an error is thrown (maybe try several times):
This is the errorcode originally thrown in the main experiment Start code: 2019-03-20 17:36:51,668 ERROR runmanager: Got an exception: Traceback (most recent call last): File "C:\labscript_suite\runmanager__main.py", line 2725, in preparse_globa ls_loop self.preparse_globals() File "C:\labscript_suite\runmanager__main__.py", line 2706, in preparse_globa ls results = self.parse_globals(active_groups, raise_exceptions=False, expand_g lobals=True, return_dimensions = True) File "C:\labscript_suite\runmanager\main.py", line 3386, in parse_globals shots, dimensions = runmanager.expand_globals(sequence_globals, evaled_globa ls, expansion_order, return_dimensions=return_dimensions) File "C:\labscript_suite\runmanager\init__.py", line 552, in expand_globals axis = list(zip(*axis)) TypeError: zip argument #1 must support iteration
End Code
This is the error code thrown with a test setup (error is always coming up again!): Start Code: Traceback (most recent call last): File "C:\ProgramData\Anaconda3\lib\threading.py", line 864, in run self._target(*self._args, *self._kwargs) File "C:\ProgramData\Anaconda3\lib\site-packages\zprocess\utils.py", line 25, in _reraise raise value.with_traceback(traceback) File "C:\labscript_suite\runmanager__main.py", line 2726, in preparse_globals_loop self.preparse_globals() File "C:\labscript_suite\runmanager__main__.py", line 2707, in preparse_globals results = self.parse_globals(active_groups, raise_exceptions=False, expand_globals=True, return_dimensions = True) File "C:\labscript_suite\runmanager\main.py", line 3387, in parse_globals shots, dimensions = runmanager.expand_globals(sequence_globals, evaled_globals, expansion_order, return_dimensions=return_dimensions) File "C:\labscript_suite\runmanager\init__.py", line 552, in expand_globals axis = list(zip(axis)) TypeError: zip argument #1 must support iteration
End Code
It seems that after the error has been thrown once, it is thrown even if no conflict between the globals is present anymore.
We have had a look at the "axis"-element in expand_globals and it is always a list of one-element-lists: [[0],[1],[2]] Let me know if more information is needed.