Closed PMunch closed 4 years ago
registerAdditionalOps
is a problem for sandboxing. The REPL doesn't even try sandboxing so it's a bad example. You probably only need a subset of these ops so that tables work, PRs are welcome.
I see. What kind of sandboxing do you mean? As far as I can tell there isn't anything too scary in there (apart from file management things, but those are all behind the nimcore
switch or the vmopsDanger
flag). The setupVM
procedure has a couple more file related options, but also a couple useful things like getEnv
and cmpIgnoreStyle
.
Ah, I didn't consider when defined(nimcore)
, you're right, it seems harmless now.
It seems like setupVM
does create some of those procedures though. And some other stuff as well. So maybe stick to calling registerAdditionalOps
at least for the time being?
I consider this closed by https://github.com/nim-lang/Nim/pull/14351
I'm working on integrating NimScript as a configuration language in my project. While doing this I tried to use the
tables
module in my script. This raised an error about stuff not being implemented in the VM. The fix for this turns out to be to runregisterAdditionalOps
increateInterpreter
. This is parts of whatsetupVM
does, along with registering a whole bunch of other stuff. Is there any particular reason whycreateInterpreter
doesn't callsetupVM
? Looking in the same filerunRepl
does run this procedure to set up its VM, so I'm thinking this might just be an oversight?