Closed trentgill closed 4 years ago
fwiw, there's a bunch of conversation on the norns repo that might be relevant here.
the globals meta-issue is a good place to start (if you haven't perused it already): https://github.com/monome/norns/issues/557.
i'd be curious if the "readonly table" hack in https://github.com/monome/norns/pull/667 might be useful?
the readonly function is a good solution for this. it'd be trivial to add.
i'll get it into the core lib.
readonly approach seems good to me.
What are we thinking to protect? My first thoughts:
bootstrap.lua
. Can readonly be applied to a global function (ie print
)?_c
Input
, Output
, Asl
, Asllib
, Cal
Metro
/metro
& II
are different though as they have a lot of internal functionality that shouldn't changed, but they can be modified to setup event callbacks, so can't be totally protected. I'm guessing Midi
will be in this same category but we'll cross that bridge at the appropriate time.
Demoting to 1.1 as this feels like a problem we can solve when it arises?
sorry for the slow reply; i haven't dug deeply into the APIs yet but my gut says your candidates look right. the C-functions should get guarded somehow for sure. i think we can follow the lead of whatever we end up doing for norns...
anyway, agreed we can tackle all of this opportunistically!
A non issue in practice.
Need a solution to make sure the user can't create a script (saved in flash as the default) that makes the lua environment unresponsive, thus being unable to change the script.
Ideas:
These would include a small number of functions that would break script-updating (dostring(), usb2repl() etc).