Project has nothing in it except:
parameter.boolean("doNotPrint", false, function()
print("oops")
end)
Outputs “oops” twice upon startup, as shown in attached image.
@UberGoober I think that’s just the way Codea works if you put something outside any function. If you just have a single print statement, it will print twice. There’s very few things I’ll put outside of a Codea function.
@dave1707 unexpected behavior is unexpected behavior. If “that’s just the way Codea works” there should be documentation of it.
Also
function enclosed()
parameter.boolean("doNotPrint", false, function()
print("oops")
end)
end
enclosed()
…same result
@UberGoober I’m sure there’s a lot of things that Codea does that isn’t documented. Apparently Codea makes two passes thru the code before it executes the functions setup and draw.
@dave1707 there are jillions of things Codea doesn’t document. I’m nonplussed at this. If you’re saying something other than “Codea has lots of bugs, big deal,” it’s not clear to me.
@dave1707 also are you really looking at what’s going on in that code?
What’s happening is not the result of Codea “going through the code twice” because the code never explicitly calls or changes the parameter.
The parameter is established, and the callback function of the parameter is called twice, without any of the rest of the code referencing it at all.
@Simeon - probably me not programming the parameter command properly, but - when I set up say parameter.integer(“test”, 1,50,35) and run the code I get an error for undefined integer ‘test’. I have seen this in a few versions of Codea, I get round it by defining test before the parameter setup.
It’s possible I asked @Simeon why Codea executes code the way it does probably 7 or 8 years ago when I noticed that. It doesn’t affect how Codea works or the way I code, so I probably just said OK and kept writing code. There’s just a few things that I code outside of any function so it’s taken care of before the regular code starts executing.
i suspect that parameters’ functions are called when they are set up. and free code outside functions getting executed as soon as compiled seems unsurprising. that’s kind of what one would expect, isn’t it?
it might be nice if everything were documented, but it would take more time than anyone has to read it.
since everything needs to be prioritized, i’d like to see things documented that are hard to figure out, or literally impossible to find, like the stuff inside craft.
and i’d help with that writing if there’s a livable way that i could.
@RonJeffries I once requested a tree type flowchart of all the Craft commands just so it would be easy to see how everything in Craft was connected.
yes. obvs there’s a lot to it. i would love to help if i could.
@RonJeffries I’m entirely an autodidact, so perhaps I ought to be expecting code to be run when it’s not explicitly called, but I never had the class on “when code runs without you telling it to.”
That said, working in both Xcode and Visual Studio gives me no reason to expect code to be run when I haven’t called it, so you saying it’s “what one would expect” is itself surprising to me.
As to things being hard to figure out, figuring out that this happens has taken me hours upon hours to track down, over the course of at least a week, and like I said maybe that’s on me for not having a formal programming education, but I will also point out that AFAIK Codea is not intended exclusively for people who took the class on when code runs without any apparent reason.
@UberGoober I’m not sure why you’re surprised by this. Anything that gets keyed in the editor will execute when the run icon is pressed. If it’s inside a function then the code will run when that function is called. If it’s not inside a function, it will get run when the run icon is pressed and before function code. Maybe that’s not intuitive, but I’m not sure when or how you thought code not inside a function would get executed. I don’t use Xcode or Visual Studio, so I don’t know how or when code gets executed. I’m sure any code that’s keyed in will run when executed.
@dave1707 I’m not sure why you aren’t getting this:
If it’s inside a function then the code will run when that function is called.
The function is never called. The containing function is called in the second example, but the parameter one isn’t. The parameter function is supposed to be called when the parameter is changed. The parameter is never changed in any of my examples.
Also neither of your dismissals explains why the function is called twice.
Expecting code that isn’t called to execute anyway is odd to me, but expecting it to execute twice is even odder.
@UberGoober Here’s the last thing you showed above. You’re calling the function enclosed(). In the post above that, the parameter is getting called because it’s not in a function.
function enclosed()
parameter.boolean("doNotPrint", false, function()
print("oops")
end)
end
enclosed() <<<—— You’re calling the function right here.
Okay but
ok, this is more odd than i thought. it prints hello twice. here’s the program
print("hello")
once i can get. but twice? why?
@dave1707 note twice. weird.
So @dave1707, I’ve done dumb things in my life, and Lord knows I could be doing something wrong, right here, too, but dangit I know when I’ve written a function call.
I think you guys think I’m saying something completely without merit, and so you’re making analyses of the situation that have no grasp of it.
The callback function defined by the parameter is never explicitly called.
Calling a function in which a parameter control is defined is not explicitly calling the callback function of that parameter.
A parameter definition made outside a function (at root level) is not explicitly calling any callback function defined by that parameter.
In both cases a parameter is being initialized, it’s not being called.
The function at the end of parameter definitions is explicitly named a callback, in other words it does something in response to being set. I am not setting the parameter anywhere, so the callback should not be called.
Let’s say you have a parameter that defines a button. When should the action associated with the button be called?
When and only when the button is pressed, right?
Should the action be automatically called at the place in the code where you define the button? Of course not.
The expected behavior of any control is that it only activates in response to user interaction.
This control is activating not only without any user interaction, it’s activating without explicit instructions in the code to do so.