Update concerning "softcode" ...
Revision 60f2b118fa66 holds a experimental restricted Python environment I've tentatively dubbed "Evlang" (mainly to be able to avoid confusion between "evlang scripts" and Evennia's normal "Scripts"). It's added as a "contrib", i.e. an optional addition to Evennia.
Now, I went through a few iterations on developing this. I first implemented a full custom parser similar to that used in the lockhandler as I originally suggested in this thread. It worked, but this is a considerably more complex problem than the simple syntax allowed for lock strings. In short, with the possibility of nested structures it becomes very error prone and probably also very expensive to make sure all individual tokens are accepted. And then one still hasn't started to deal with control structures (I thought about supplying a "safe" if-like function, but the function-argument parsing for that would have to have been a special case - and when a code becomes full of special cases one knows things are going awry).
So in the end I abandoned the custom-tokenization (aka lock-handler-similar) approach and looked around for something else. Of course Python's
ast module handles full tokenization (batteries included and all that), so that can in principle be used to sidestep much of the parsing trouble. Once you use the AST however, you are no longer reading a string from left to right but are interpreting real Python syntax structures (The AST can after all be compiled directly to Python code). It's like approaching the problem from the other direction - restricting what is already there rather than creating what is there from scratch.
I tried a few recipes off the web with various results until I eventually settled on a hybrid approach - this combines a blacklist+whitelist (to restrict dangerous builtins and other stuff), but also uses an AST-tree traversal check on the source code
before the code is executed. This is a lot more complex than simply executing in a limited context - the AST walker will catch and kill entire families of Python functionality in one broad swath.
Now, as mentioned earlier, blacklisting is a dangerous thing. The internet is full of warnings against relying on such techniques to "sandbox" Python. For an Evennia "softcode" language however, I believe we have an advantage in that we have a very small and specific purpose with our scripting. We are not looking for a sandbox - in fact we can impose severe restrictions to the language, hopefully beyond the level of easy exploits. We also have the further advantage of being able to supply "safe" methods into the language to befit our current, limited use-case.
So Evlang is a
severely stunted subset of Python. While loops are forbidden, so are Attribute access, function definitions and many other things. But it works, and it's pretty nifty.
One problem is the aspect of DOS attacks - a script locking up the server because it's too processor heavy. The evlang script is run in a separate thread, so it won't slow down the server while it runs. But it will also not be killed. It turns out to be very, very hard to kill subthreads safely in Python, and to do so from a position being embedded inside Twisted is, at least so far, not obvious. I looked into subprocesses, but doing that while having access to the current states of Evennia objects is an even bigger pain, so I dropped that route for now. Since Evlang simply deny the most common ways to create infinite run-times (while loops, huge numbers etc), I hope it shouldn't be very easy to DOS the server this way. But it's something to keep in mind.
Evlang comes with a huge "WARNING" and "EXPERIMENTAL" flag for now. Test it, try to break it and report what you find. In the commit I also include example Commands for coding an object as well as custom evlang-scriptable Typeclasses along with lots of documentation.
Anyway, to the original poster of this thread: Evennia now does support a "softcode" language of sorts, enjoy!
.
Griatch
On Tuesday, May 8, 2012 6:59:18 PM UTC+2, Kelketek Rritaa wrote: