I am getting different results when invoking code in the console as opposed to calling it from inside a running program. The code overrides the default behaviour of the cos function.
pi=3.14159 two_pi=pi*2 -- override cos to work with radians p8cos = cos function cos(rad) return p8cos(rad/two_pi) end -- degrees to radians function d2r(d) return d*two_pi/360 end -- this test works (cos(45 deg) => 0.7071) function _draw() cls() print(cos(d2r(45))) end
I then run the code, observing correct results (0.7071).
Invoking this from the console however:
print(cos(d2r(45))) prints different results (0.2206).
Are function overrides ignored in the console?
Hmm, this makes sense. However, it also renders the console, as a tool to test code, much less reliable.
The cos and sin overrides, taken from the pico-8 docs, are used in many places in my project codebases. No big deal (undo overrides + batch replace client code) but still a worry (loss of a tool to test functions).
@dw817 The problem is that the commands need to be reverted at some point to make sure that subsequently run carts aren't effected. Remember that what can be changed in an active cart can also be changed in a cart loaded via splore. This would be particularly an issue if a cart in splore were to change the load() command to something malicious.
@kimiyoribaka I'm guessing that cart runtimes are insulated from each other by virtue of context to prevent cross-cart interference thorough API overrides such as the one @zep documents for cos and sin. So, I would think, tentatively, that the worst one can do with an overridden "load" would be to corrupt the one cart at the origin of the override, without damage to other carts, to the system, and to its commands.
But I am only 51% certain of that, which leaves the mice with 49%... so, this, with a grain of salt.
This is an intentional feature and not an error. When you escape the run of a program to get to the console, the console uses a child environment of the program's global environment. It resets the built-ins of its child environment at every prompt to keep you from locking yourself out of built-ins. Other than the built-ins, you can inspect and modify the globals of the program's environment, and resume the program with the updated globals.
Enter this in the program area, then run it. (It counts upward from 999.)
function custom(n) return n + 999 end function _init() cos = custom i = 0 end function _update() print(cos(i)) i=i+1 end
Press escape to break to the console. You can inspect
i, set it, and resume the program with the new value:
> ?i 123 > i=999 > ?i 999 > resume 1998 1999 ...
As you noticed, you can't access the program's overridden definition of
cos, but it stays in the program's environment:
> ?cos(1) 1 > ?custom(123) 1122
If you try to redefine a built-in from the command prompt, you can use it on the same prompt line, but you can't use it on the next one. When you resume, the program's own redefinition of the built-in is retained.
> cos=function(n) return n*5 end; print(cos(7)) 35 > print(cos(7)) 1 > resume 2012 2013 ...
[Please log in to post a comment]