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?

Just tested myself, and it would appear to be the case. I suspect it's a safety precaution so that a cart can't replace vital functions.

As an example, I just tried overriding reboot(), which would be dangerous.

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).

@alexr, you know they shouldn't be. I would think if you damn or improve an original command or function then you should be served whatever you've put into it.

I would mark this as an error for almighty @zep to repair.

@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
...

Thanks for the clarifications, @dddaaannn.