[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Jill - Java Implementation of Lua Language.
- From: Kristofer Karlsson <kristofer.karlsson@...>
- Date: Thu, 10 Dec 2009 16:43:41 +0100
Also, your "next" implementation seems rather slow, iterating through a table would take O(n^2) time it seems.
I noticed it because I also considered using Hashtables as a base for LuaTable when writing Kahlua, but implementing an efficient next was made very hard.
On Thu, Dec 10, 2009 at 4:40 PM, David Jones <email@example.com>
2009/12/10 Kristofer Karlsson <firstname.lastname@example.org>:
> Cool, it would be interesting to know how this differs from MochaLua, LuaJ[this is the same David Jones, just in my pobox.com disguise]
> or Kahlua (did I miss any other pure Java implementations of Lua?)
> I looked through the code briefly and found this interesting piece of code:
> private static final Slot SPARE_SLOT = new Slot();
> which is later on mutated in the code.
> It seems like this implies that you can not run more than one Lua state at
> once, is that correct?
Ooh, you're good. I hadn't thought of that. Off the top of my head,
I think it may well mean that running more than one Lua state at once
(meaning concurrently, in separate JVM threads) is a bad idea / will
not work / will get corrupt results. That particular use is rather
embarrassingly clunky and hacky, but it should be straightforward
enough to change if it does turn out to be a problem.
Thanks for very speedily finding a bug, or at least an embarrassment
that I should tidy up. I will think on it.