It would be cool if you added the feature to execute code at runtime
example:
mob/verb/Execute_Code()
var/a=input(usr,"What code would you like to run?")
Execute(a)
*clicks run*
*clicks Execute_Code*
What code would you like to run?
*types in "world<<123"*
*hits enter*
123
It has many uses like
Running code from files
and
Debugging during runtime
ID:133362
 Oct 25 2008, 11:54 pm
|
|
more reasons..
You can let people change it without giving out a source and you could give an outside program more control it also allows people without the source to find and fix problems and even add new things | |
not really it already compiles code although it wouldn't be able to check for errors so it could crash
cool theres a precompiled code thing its almost the same thing I mean something has to compile precompiled code at runtime and something has to call it It wouldn't be too slow if the compiling and running were kept seperate mob var/a verb compiler() a=compile(input(usr,"Code?")) runer() execute(a) | |
It would need to compile on the fly. I don't believe the compiler code is available to the runtime environment currently. Further to that, your example is static and doesn't demonstrate the problem with Just-in-Time compiling, which is the compiling is done on demand. If you read a text-file in and execute it as code, it'll exist as text at compile-time, and will need converting at runtime, which in short means the usual compile-time crunching of the CPU if you just retro-fit the current compiler code (which would still be effort). At best you are looking for some form of pre-compiled module system, which has certain benefits (not highlighted in the thread on the subject), but would still be time-consuming to make and rarely used.
| |
Sure it will be laggy but code generally only takes second to compile. It should compile even faster then the compiler because it has a lot less too do and once its compiled injected is all execute really does is move the pointer to the start of its contents data and jumps over execute when its done so its about as fast as a normal code after being compiled and if it has to compile every second thats just bad design.
| |
Well there are obvious design considerations. How does it react to procedure overriding? Does it even allow this? What kind of interactions are permitted? It's a good idea, but it would still require time for the BYOND people to implement and quite frankly, I only see a handful of people using it.
The long and short of the suggestion as I see it is, good but there are much more "useful" things they could be doing. Like adding features that much better serve BYOND as a gaming experience. You can still create a scripting engine to perform this task in the mean-time though. | |
I wonder how hard it would be to create a library to utilize Lua.
| |
Stephen001 wrote:
It's also probably a rather time-consuming thing to implement. Well, DM already has an eval() proc. But it's support is limited, and I'm fairly sure it's undocumented. | |
Not very hard considering the library's are already available in the download section on that site
http://luaforge.net/frs/?group_id=110 | |
I suspect Xooxer was aware of that. The problem is hooking that library up to BYOND's internal data-structures, if I understand what Xooxer is suggesting correctly.
| |
Those are okay "what"s, but where's the "why"? Why is it important to be able to run code from files? Why isn't it possible to debug your code using debug messages and testing code at compile time?