Log In  

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.


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

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?

P#111239 2022-05-03 13:35

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.

P#111240 2022-05-03 13:49
:: alexr

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

P#111241 2022-05-03 14:04
:: dw817

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

P#111244 2022-05-03 15:24

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

P#111247 2022-05-03 16:16
:: alexr

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

P#111263 2022-05-03 20:47 ( Edited 2022-05-03 20:52)

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

function _init()
 cos = custom
 i = 0

function _update()

Press escape to break to the console. You can inspect i, set it, and resume the program with the new value:

> ?i
> i=999
> ?i
> resume

As you noticed, you can't access the program's overridden definition of cos, but it stays in the program's environment:

> ?cos(1)
> ?custom(123)

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))
> print(cos(7))
> resume
P#111305 2022-05-04 23:59 ( Edited 2022-05-05 00:00)
:: alexr

Thanks for the clarifications, @dddaaannn.

P#111320 2022-05-05 12:20

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2022-09-30 18:21:24 | 0.028s | Q:24