Re: Modify Lua interpreter to implement a sandbox script language

["szbnwer@..." <szbnwer@...>]

hi all :)

Il giorno mar 4 set 2018 alle ore 08:21 Dirk Laurie
<dirk.laurie@gmail.com> ha scritto:
> select('#',...) can't be done in another way, but select(n,...) is
> equivalent to {...}[n]

select() and {...} are not really identical... i have a safe
environment to run strings via evaluating and pcall()'ing them, but
when ive set up buttons with onClick methods, then i had to face with
the fact that they are new calls out of the scope of the original
pcall even if theyve bornt inside that. so my app could crash during
experimenting ... this led to a handsome function wrapper as follows:

-- wrapper function that handles errors
-- ProtectFunction(fun)(...) -- flush output
-- protectFunction(fun)(...) -- don't flush output
-- invisible if all good
-- returns nil and error message on fail, and pretty prints it out via outErr
do
  local pf=function(flushOutput) -- internal setup only
    return function(f) -- the actual wrapper
      return function(...) -- the new function
        return (function(...) -- results from pcall below
          if ... then -- succ
            return select(2, ...)
          else -- err
            outErr(select(2, ...))
            if flushOutput then writeOutput(app) end
            return nil, select(2, ...) end end)(pcall(f, ...)) end end end
  ProtectFunction=pf(true)
  protectFunction=pf(false) end
-- test:
-- Out(ProtectFunction(function(...) return ... end)(nil, ' HAPPY ', nil))
-- Out(protectFunction(function() error'SAD' end)())

here, the additional complexity of the inner most function, and the
test cases are exists cuz the {...} (or whatever else ive tried)
cutted off the trailing nils when i wanted to use that solution
previously, but a vararg function doesnt :) so when ive printed out
the results from some random tests, then ive seen that trailing nils
are getting lost, but only this way not, and finally ive felt like i
must over-comment it for the late future instead of let it stay in the
"dont touch magic" state; and whenever my stuff gonna become public
and any brave volunteer will try to simplify it, the test cases will
tell them the truth :D i believe that overengineered mystical gems can
exists as long as they are finalized and well documented, so no1
should really touch them again that way :D if it would use {...} then
maybe 1 day someone will need to touch it again, or it could make
mystical errors... ive already hit the case that revealed the
difference, so its possible to meet with it again...

if any1 believes that their tools from a given sandbox is identical
with the original behavior, then such small differences can make them
really hate the creator ;) (fine ... except if they are well
documented)

ps: yep, i love factories! :D they are so much recreational ... and
useful as well :)

bests for all! :)