The bulk of the work in this will be in updating the persistence library.

I'll have to take a look how much changed in Lua's internals, in particular how the new integer type may affect persistence... no ETA on when I'll get tho that.

Assuming it gets done, I guess this could just as well be an alternative architecture.

@fnuecke I'd also keep Arguments.checkInteger/optInteger/checkDouble/optDouble generic, but have isInteger and isDouble specific to the new types (And maybe have a more generic isNumber)

I think a better idea would be switching to LuaJIT as opposed to Lua 5.3. There is a java binding to LuaJIT, plus a config option to support FFI would be awesome. The VM is fully resumable, so implementing persistence might not be that difficult.

LuaJIT persistence would be hard to make
right now it would be much much easier to port eris to 5.3

and hahahahahaha FFI? no.

Yeah, FFI is a really bad idea.

@Someguynamedpie - With FFI, you can probably break the entire computer the server's running on within seconds. Not a good idea.

With FFI you could crash Minecraft in seconds.
ffi.cast("unsigned char*",0)[0] = 0 has been proven very deadly. Just run it in something that lets you access ffi 😄
💯 failure!

I didn't say on by default rofl that's a massive security hole. Perhaps by a secondary enabling mod, regardless I think LuaJIT would be a massive speed boost(the interpreter by itself is faster than Luas)

@Someguynamedpie it you think that persistency module on LuaJIT will be simple, go for it, but it will be not. It is much easier to port Eris to Lua5.3 than rewrite system that just was stabilized.

Also IIRC LuaJIT has one problem. If JIT kicks in in case of tight loop it is impossible to debug.hook and also it might be impossible to peacefully stop the machine.

Also there wouldn't be a real performance gain since calls to components is
what makes OC feel slow. If the component call is not a direct call then it
yields the whole computer, synchronizes up the Minecraft thread, and
executes the final call during a game tick. It can easily be attempting to
sync with the Minecraft thread while it's mid-tick, and in that case it
would cost the rest of that tick to get the component call executed. The
worst that wait time could be is ~1.9 ticks, where the OC computer is the
first tile entity that gets invoked. tl;dr: It takes time to synchronize
calls with the Minecraft thread, which is why OC feels sluggish at times.

On Wed, Mar 11, 2015, 1:43 AM Jakub Sztandera notifications@github.com
wrote:

Also IIRC LuaJIT has one problem. If JIT kicks in in case of tight loop it
is impossible to debug.hook and also it might be impossible to peacefully
stop the machine.

—
Reply to this email directly or view it on GitHub
#811 (comment)
.

You can disable the jit, the interpreter itself is much faster than Luas. But I've never had that problem; debug.sethook has always worked fine for me. The main issue is admittedly resuming the state, but you could always copy the entire state(not sure if that's possible even without jit because allocating memory outside). I'll do some investigation about resumability and will post back here

Resumability is most likely possible with LuaJIT, it's the fact whether
someone ports Eris to JIT, and even then FFI wouldn't work with with it
since it relies on memory locations that cannot simply be copied back into
memory.

On Wed, Mar 11, 2015, 2:04 PM Someguynamedpie notifications@github.com
wrote:

You can disable the jit, the interpreter itself is much faster than Luas.
But I've never had that problem; debug.sethook has always worked fine for
me. The main issue is admittedly resuming the state, but you could always
copy the entire state(not sure if that's possible even without jit because
allocating memory outside). I'll do some investigation about resumability
and will post back here

—
Reply to this email directly or view it on GitHub
#811 (comment)
.

LuaJIT keeps all of the FFI allocations in its state so it can be handled by the GC later if needed, save for uses of m/c/alloc. But since OC uses TCP I can just make a Lua server and do stuff from there. When I boot back into Linux I'll try porting Eris to LuaJIT. Does OC have any other Lua extensions I should know about?

@Someguynamedpie it is just Eris but it is not just Eris. It is ERIS. Do you want to know why OC is not yet 5.3?
Eris was ported ty 5.3 by Sangar but is bugged in one place (upvalues are getting messed up) and noone yet found this bug.

Yeah, it's quite the annoying bug. I don't even have a minimal test-case, I'm afraid. From what I remember I mostly dug around with a debugger attached to Java to analyze the native lib, because I could only reproduce it within OC (because that use-case was complex enough).
Btw, If you'd like to discuss Eris related stuff, let's do that in the 5.3 issue on the Eris repo.

LuaJIT does not completely keep track of allocations from the actual C
libraries. So if a piece of C code calls malloc and make a reference to it
by id instead of pointer, you can't resume the computer safely since it
would rely on an internal library state, which is only resumable if you
actually threw the memory from the previous process in there, but that
would still lead to more problems.

On Thu, Mar 12, 2015, 2:42 AM fnuecke notifications@github.com wrote:

Yeah, it's quite the annoying bug. I don't even have a minimal test-case,
I'm afraid. From what I remember I mostly dug around with a debugger
attached to Java to analyze the native lib, because I could only reproduce
it within OC (because that use-case was complex enough).
Btw, If you'd like to discuss Eris related stuff, let's do that in the
5.3 issue on the Eris repo fnuecke/eris#12.

—
Reply to this email directly or view it on GitHub
#811 (comment)
.

Oh yeah I didnt even think of that. That part is true so persistance would have to be disabled to safely use it.

@Someguynamedpie to serialize LuaJIT you would have to exit JITed code and reverse JITed upvalues back to to interpreter mode. IMHO it will be very problematic. External coroutine yielding is not possible when code gets JITed. Also

while true do
end

would make it impossible to not only persist Lua state but also would make OC's time limit per computer ineffective as you are not able to, again, yield from JITed coroutine.

All right, finally got that upvalue bug fixed, so the new dev builds have the 5.3 arch in them. It's disabled by default, so you'll need to set enableLua53 to true in the config to mess with it (sneak-right-click a CPU while holding it in hand to cycle architectures).

Please let me know if you notice any bugs with the 5.3 arch, thanks!