ID:133362
 
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


Chowder wrote:
It has many uses like
Running code from files
and
Debugging during runtime

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?
In response to Jtgibson
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
In response to Chowder
It's also probably a rather time-consuming thing to implement.
In response to Stephen001
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)
In response to Chowder
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.
In response to Stephen001
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.
In response to Chowder
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.
In response to Stephen001
I wonder how hard it would be to create a library to utilize Lua.
In response to Stephen001
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.
In response to Tiberath
Tiberath wrote:
Well, DM already has an eval() proc.

Sure, but it barely does anything...
In response to Xooxer
Not very hard considering the library's are already available in the download section on that site
http://luaforge.net/frs/?group_id=110
In response to Chowder
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.
In response to Kaioken
It's good for basic math functions: +, -, *, /

And that is the extent of my use for eval().
In response to Xooxer
It's a lot of work, I'll tell you that!
In response to CaptFalcon33035
CaptFalcon33035 wrote:
It's good for basic math functions: +, -, *, /

And that is the extent of my use for eval().

I should note that eval() is not just limited, but possibly buggy. I found and fixed a bug in it for build 430. It's undocumented for a good reason.

Lummox JR