Hi Mark,
As of tonight’s nightly build, there are some new functions in the mworkscore module:
# Return the code-to-name mapping for variables (as a dict)
getcodec()
# Return the name-to-code mapping for variables (as a dict)
get_reverse_codec()
# Register event callback for variable "name"
register_event_callback(name, callback)
# Register event callback for code "code"
register_event_callback(code, callback)
# Register callback for *all* events (use with care!)
register_event_callback(callback)
# Unregister all event callbacks previously registered from Python
unregister_event_callbacks()
# Event callback example
def my_callback(evt):
code = evt.code
time = evt.time
data = evt.data
It all should work very similarly to the conduit methods.
Note that, absent a call to unregister_event_callbacks, registered callbacks will remain registered until MWServer terminates. I debated automatically unregistering Python callbacks when the experiment stopped. However, I decided against it, on the grounds that it might be useful to register a callback on #state_system_mode that does something useful when the experiment stops. Do you have any thoughts on this?
__file__ appears not to be defined by run_python_file
I looked in to this. Normally, __file__ is set only in imported modules. However, the Python executable treats python my_file.py as a special case and sets __file__ to my_file.py when the file executes. Since run_python_file isn’t invoking the Python executable, it isn’t set.
That said, if you think it would be useful, I can modify run_python_file to set __file__.
Some exceptions generate a long traceback that is cut short, dropping the end >>which is often most important. It looks like only about 2000 characters get through.
That’s actually a limit in MWorksCore; the buffer for rendering messages is fixed at 2048 characters. It shouldn’t be too much work to remove that limit.
This limitation is gone in the current nightly build. All MWorks messages can now be of arbitrary length.
But why can’t you just run the file at the start of the protocol, before you get to the trials?
I did some basic testing and couldn’t figure out easily how to run at the
start of the protocol before trials started, but maybe this was my error.
I was thinking something like this:
protocol 'My Protocol' {
run_python_file ('startup_stuff.py')
block 'My Block' {
// All the trial stuff goes here
}
}
In other words, wrap your current protocol in a block, and execute any setup actions before it. Is there some reason this wouldn’t be sufficient?
Chris