"Stop trials" action?

Support
1

Hi Chris,

Is there a way to simulate pressing the Client stop button in the XML?
We talked about this in connection to Assert actions but I’m wondering if there is a freestanding action as well.
I can’t imitate this with “Exit state system”/yield transitions because I have the task_system surrounded in a block of trials.

Thank you
Mark

2

Hi Mark,

I’m not aware of any way to do this at present, but a stop_experiment action would be easy to implement and certainly could be useful. I’ve opened a ticket for this.

Chris

3

Hi Mark,

FYI, I added a stop_experiment action that has the same effect as the client’s stop button. The XML is what you’d expect:

<action tag="Stop Experiment" type="stop_experiment"/>

This will be in tonight’s nightly build.

Tonight’s nightly will also have another of your requested changes: The client now has a preference for saving and restoring open plugin windows between sessions (default is NO, to preserve existing behavior).

Cheers,
Chris

4

Hi Chris,
These work well, thank you! Both the stop_experiment action and reopening plugin windows are very helpful. I’ll test over the next few days and let you know if I hit any problems, but for now it looks good.

One more request, since it should be simple: can you add a parameter to the “assert” action that will stop the experiment? I’m thinking that there would be a tag “action” for assert with values “error” or “error_and_stop_experiment”, or somthing similar.

Are you still thinking of having a global ‘experiment’ document?

5

Hi Mark,

One more request, since it should be simple: can you add a parameter to the “assert” action that will stop the experiment?

This is done and should be in tonight’s nightly. Assertions have gained an optional parameter, “stop_on_failure”. If set to 1, then the experiment will automatically stop if the assertion fails.

Are you still thinking of having a global ‘experiment’ document?

I haven’t thought about it much since our discussion, but it still seems like a good idea. Since it’d be a significant change, Dave and other folks would need to be involved in its design. It’d definitely be a post-0.5 thing.

Cheers,
Chris

6

Thanks for the assert change!

The change to open previous windows on start is very nice. In the meantime before any document changes are made, I’d suggest one more - add a client pref to, on start - ‘Connect to last server, reload last experiment, and reload last python script if python bridge is being reopened’.

thanks!
Mark

7

Hi Chris,

I just pulled down yesterday’s nightly to test the assert change. It’s
dated Jun 8 00:38.
The assert change works, but this has broken the python client bridge. The
behavior is that

  • (1) if you don’t enforce a wait between client.initialize() and a set
    of calls to client.register_callback_for_code(), the first call to
    reg_callback works and the second one hangs and never returns.
  • (2) I put a time.sleep(1) call after client.initialize(). Then all
    the reg_callback calls complete, but no callback is ever called on variable
    change.

I’m assuming your’e working on this now. If not and I can do more useful
debugging let me know. For now I’ve reverted back to a nightly from around
May 25th.

Best
Mark

8

Hi Mark,

The assert change works, but this has broken the python client bridge.

Thanks for testing the assert change.

Last week, I made a bunch of changes to the code underlying the Python bridge, with the intent of fixing the other issues you’ve reported about it. It’s been working quite robustly for me since then, so I’m surprised and distressed to hear it’s stopped working for you.

I just did some testing using the latest nightly (which should be identical to the one you tried). My test experiment defines 500 variables and assigns random values to all of them 10 times at one second intervals. In the corresponding Python script, I register callbacks for all the variables (with no pause after client.initialize() or between callback registrations) and then report all changes to the console. Over multiple runs, I consistently get all 5000 callbacks.

I’ve attached my test experiment and Python script. Would you mind trying it out on your system and letting me know how it works?

One of my recent changes was to ensure that the Python bridge kills running scripts when the client shuts down. (Previously, if you closed the client without first clicking the Python bridge’s “terminate” button, the script just kept running.) If my experiment doesn’t work for you, you might want to open up Activity Monitor and see if you have old Python processes still running. These could interfere with newly-launched scripts.

Also, while testing my changes, I discovered that register_callback_for_code just doesn’t work (and hasn’t for some time, it appears). I’ve opened a ticket for this. In the mean time, you should stick with register_callback_for_name.

Thanks for your debugging efforts and patience!

Chris

9

Attachments:

10

Thanks. I’ll check this over the next few days. I believe I was using register_callback_for_code().

Mark

11

No, I’m using register_callback_for_name(). I’ll try your code but it will
take a few days; perhaps not till next week. Thanks!