[Bug] 'variables' in 'set up' in block coding.
Robo-Hinataya opened this issue · comments
I cannot use 'variables' in 'set up' in block coding.
I'm getting the error below.
NameError: name 'gear_ratio' isn't defined
I think this is because when translated to Python, 'Initialize variables' comes after 'Set up all devices'.
Thank you for opening this issue!
Indeed, variables are currently listed separately. Maybe it is indeed better if we put them in the same order. Alternatively, we keep the order this way, but don't allow reading variables in the setup. But maybe this is too restrictive. What do you think?
For this issue specifically, I think we could add an optional specification for the gear ratio in the motor setup, just like we do in Python.
Thank you for your reply.
That gear ratio settings may be added to the motor setup is the good news for me.
As for the order of 'set up' and 'variables', I teach my students that 'Python is executed from top to bottom', so I think it might be a good idea to put them in the same order as block coding, although readability would be reduced.
One issue with changing the ordering behavior at this point is that it could break existing programs.
If we did that, we could display the error symbols with bubbles to request that the user re-order them.
Looking at it the other way --- besides gear ratio, are there good use cases for reading variables within the setup?
Looking at it the other way --- besides gear ratio, are there good use cases for reading variables within the setup?
So if we could live with the current behavior (to avoid breaking changes) but still want to make it clear that something is wrong, we could add this when you try it:
We could also start this way, and consider the bigger change for a future release, alongside some way to ensure that existing programs will not break.
Not being able to use variables in the setup seems like an unnecessary limitation that exists in blocks but not in python.
My group noticed it when we were trying to run testing on a single robot, trying out how different tires compared. It would have been nice to be able to drop a variable in for the drive base wheel diameter:
Maybe you could create an optional "initialize" block to go along with the "set up" block, to allow initializing some variables before the "set up" is run? I don't think this would break any existing programs, if the variables are allowed to be initialized in either place. It would give the flexibility in new programs on where the variables are initialized.
Another advantage of having an "initialize" block, would help reduce the size of the "set up" string. Once several variables are initialized the setup starts getting really long. It would be nice to breakup some of this code block into parts. Maybe you could even allow for multiple "initialize" blocks and accept some sort of parameter value that specifies which order these initializations are performed?
Thanks for your input @southlakefll !
If we're going to change it, I think it would be simplest (also for the user) to just have the order the same as in the blocks they've put it in.
Then if things are in the "wrong" order, such as a motor defined after the drive base, we could show one of those warning bubbles, instead of fixing this behind the scenes as we currently do.
I would still want to avoid breaking people's existing programs (like the official app does from time to time), but maybe there are ways to do that. The warning bubbles would be one way of doing that. Or, since the block programs are versioned, maybe we could automatically upgrade the older programs so they'd keep working. This could be difficult to get properly tested for all sort of edge cases though.
We can also add a comment block in the shape of the setup connectors, so you could still organize your code in sections as you currently get with separate variable initialization if you'd like to do it that way.