Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

builder-generated scripts should not /initialise/ components with thisTrial['blah'] #29

Closed
peircej opened this issue Jun 12, 2011 · 4 comments

Comments

@peircej
Copy link
Member

peircej commented Jun 12, 2011

When a component is going to use a parameter that gets set every trial then it needn't be initialised to that value. Just initialise with default and set later to the necessary value. This has the advantage that we can create the parameter variables (e.g. thisTrial['ori']) just before the loops, rather than at the start of the script.

Not sure though. Is it worth the effort for some slightly better code? Does it /matter/ if the TrialHandler is created at the start of the experiment rather then just before it runs?

@peircej
Copy link
Member Author

peircej commented Jun 12, 2011

I didn't explain my concern about this very well - the downside is the code for working out how to write the script will get rather more confusing (even though it should be reasonably easy to write first time) and maybe it isn't worth having confusing internal code for a non-critical feature like this.

@jeremygray
Copy link
Contributor

I am not completely sure if its related, but it might be useful in this situation (which came up for me and also someone else at the workshop): if you set a component's value (via a code snippet in a field in a builder window) to $value at the start of a routine, you get an error at initialization time (because the variable is unknown at that point). the non-obvious work around I used was to set value=None at the start of the experiment via a code component (so that variable "value" would be defined, even if its value was meaningless). so it sounds like only expecting things to be defined at the start of the routine would be good?

@peircej
Copy link
Member Author

peircej commented Jul 26, 2011

Yes, this is the same issue, and I've also been seeing it more and more as an issue. You got the correct workaround too, but it's kind of ugly. I've promoted the issue to 3 ticks.

@peircej
Copy link
Member Author

peircej commented Jul 26, 2011

Done (commit fe253ea)

@peircej peircej closed this as completed Jul 26, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants