ElvishJerricco, on 20 May 2013 - 11:36 PM, said:
Just FYI, when you loadstring() in Run.lua, you need to pass a second argument of fs.getName(inFile) so that error messages know the file name. Also, you can replace _G.loadfile with this version of loadfile and it works perfectly with both compiled code and uncompiled code. (yes I tested). The best part of that is that anything anywhere that loads code via os.run, shell.run, or anything else based on loadfile will run the compiled code just fine, so it even works from the shell without modifying the shell.
And finally, your os.queueEvent("") coroutine.yield() lines negate all the performance you're trying to save by running compiled code. Those two lines make the loading process very, very slow (again, tested). I had a three line program that when compiled and run with this, took like a half second to load (and that's not counting the compile time). I took those lines out and it was instant. You're probably not going to run into files so large that they reach that 5 second limit, so I'd say take the lines out.
Run.lua will only run one file at a time, if someone doesn't know what file they're trying to run when they've just typed it into the shell, I don't hold up much hope for their skills as a programmer. As for the function, yep, absolutely no error checking, but pcall can be used to handle that for now. It's early days yet, so a working function is all I can promise for now.
I would certainly expect swapping the loadfile functions to work. (The fact I named the function loadfile is no mere coincidence.) Up until now though I hadn't got round to testing, but as there is now confirmation, I can amend the documentation.
I could develop an option for size and all sorts of other enhancements, but frankly this code is barely 2 or 3 days old, so I'm not worried about optimising it yet. If you want to optimise it, feel free to, but otherwise I will optimise and improve it when I have the time.
(as it happens I do have a solution that will work without the need for any special command line options or testing the size of the file, but I will sort that when I get time)
Grim Reaper, on 21 May 2013 - 01:49 AM, said:
ElvishJerricco, on 20 May 2013 - 11:36 PM, said:
You're probably not going to run into files so large that they reach that 5 second limit, so I'd say take the lines out.
He's right there, but if you still wanted to implement this safety feature, you might have a flag which is set only if the file size is large enough to exceed the five second limit.
It's not quite as simple as testing file size because some things take longer for the lexical parser to handle than others, plus a file could be absolutely crammed full of whitespace, which shouldn't really effect the compile time massively.
Grim Reaper, on 21 May 2013 - 01:48 AM, said:
Nina, on 19 May 2013 - 04:52 PM, said:
- It is impossible to pass any arguments to programs executed with the supplied "Run" program.
I'm pretty sure his code is already passing any additional arguments received from the shell off to the loaded function which is returned by loadfile().
loadfile(args[1])(select(2,unpack(args)))
However, you can simply tweak the run program yourself to allow for passing arguments to a compiled program. Considering that loadstring() is simply taking your string data which is a dump of actual Lua code, you can pass augments to the function returned.
Like the following:
local compiledProgram = loadfile (args[1])
table.remove (args, 1) -- Remove file path from arguments.
-- Run with arguments.
compiledProgram (unpack (args))
I won't deny here, Nina's comment was made before I made that change.
I considered the table remove thing, but I thought the solution I used looked neater and fit on fewer lines.
Many people forget about the select function, I thought it deserved some attention.
2
