|
|
|
|
[more from me in a follow-up, this is the "approved" announcement]
Ravenbrook Limited and Nokia Corporation are pleased to announce the
open source project Jill:
jillcode.googlecode.com
Jill (Java Implementation of Lua Language) is a complete
implementation of Lua 5.1 in pure Java. It is intended to be used on
mobile platforms, JME, but also runs on JSE. The source code is
owned by Nokia and made available under an open source licence (see
below). Jill was originally written by Ravenbrook (under contract to
a different company) and we will manage the open source project at
jillcode.googlecode.com.
Nokia's licence:
Copyright (c) 2006 Nokia Corporation and/or its subsidiary(-ies).
All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject
to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
Cool, it would be interesting to know how this differs from MochaLua, LuaJ 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? On Thu, Dec 10, 2009 at 3:04 PM, David Jones <[hidden email]> wrote:
[more from me in a follow-up, this is the "approved" announcement]
Ravenbrook Limited and Nokia Corporation are pleased to announce the open source project Jill:
jillcode.googlecode.com
Jill (Java Implementation of Lua Language) is a complete implementation of Lua 5.1 in pure Java. It is intended to be used on mobile platforms, JME, but also runs on JSE. The source code is owned by Nokia and made available under an open source licence (see below). Jill was originally written by Ravenbrook (under contract to a different company) and we will manage the open source project at jillcode.googlecode.com.
Nokia's licence:
Copyright (c) 2006 Nokia Corporation and/or its subsidiary(-ies).
All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject
to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
2009/12/10 Kristofer Karlsson < [hidden email]>:
> Cool, it would be interesting to know how this differs from MochaLua, LuaJ
> 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?
[this is the same David Jones, just in my pobox.com disguise]
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.
drj
|
|
|
On 10 Dec 2009, at 14:04, David Jones wrote:
> [more from me in a follow-up, this is the "approved" announcement]
>
> Ravenbrook Limited and Nokia Corporation are pleased to announce
> the open source project Jill:
>
> jillcode.googlecode.com
I have to say that personally I am very pleased that this has become
possible.
For those with long memories on the list, this is the project that
Paul Hudson (and me in my pobox.com disguise) has occasionally
mentioned over the past few years when someone asks "is there an
implementation of Lua that can run on pure JME". It became rather
frustrating to say "there is one that we wrote, but it got buried by
the collapse of a company".
It was written by me and Mark Tillotson at Ravenbrook, slightly more
than 3 years ago, for a commercial client. Who were quite happy with
it, until they went bust. At the time I think we tried to contact
the receivers to see if we could do anything with it, but no joy.
Then fast forward to 2009, and the rumour mill said that some of our
friends might own the code. They didn't, but they knew who did
(namely, Nokia). And with some help from some people inside Nokia we
were able to get Nokia to open source it.
>
> Jill (Java Implementation of Lua Language) is a complete
> implementation of Lua 5.1 in pure Java. It is intended to be used
> on mobile platforms, JME, but also runs on JSE. The source code is
> owned by Nokia and made available under an open source licence (see
> below). Jill was originally written by Ravenbrook (under contract
> to a different company) and we will manage the open source project
> at jillcode.googlecode.com.
I say "we will manage the open source project at
jillcode.googlecode.com" but that just means I'll keep an eye on the
googlecode project. We're fully open to community contributions and
warmly welcome everything you good people in the Lua community have
to offer. It's been 3 years since I've looked at this project (apart
from recent cleaning and slapping on of copyright notices). In
particular, I no longer have an active JME development environment
(the phone I used for testing 3 yeas ago was the property of the
client).
"complete" above means that Jill runs 5.1 lua code unmodified. It
includes its own compiler, and internally implements a VM identical
to the PUC-Rio Lua. You can, if you like, compile Lua scripts
offline and have Jill run the bytecodes on the phone (the original
client wasn't particularly interested in this, but it made the
development way easier).
Jill has an API so that Java programs can embed Jill, just like C
programs embed PUC-Rio Lua. It's basically the standard Lua API
"translated" into Java, and with the stack (almost) thrown away.
Java's GC (well, the JVM's really I guess) is used to GC the Lua
objects. One consequence of this, which isn't tested but should
work, is that "separate" Lua states (instances in Java) can share
objects and it all just works, no GC hassle.
David Jones
|
|
|
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.
/Kristofer On Thu, Dec 10, 2009 at 4:40 PM, David Jones <[hidden email]> wrote:
2009/12/10 Kristofer Karlsson <[hidden email]>:
> Cool, it would be interesting to know how this differs from MochaLua, LuaJ
> 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?
[this is the same David Jones, just in my pobox.com disguise]
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.
drj
|
|
|
2009/12/10 Kristofer Karlsson < [hidden email]>:
> Also, your "next" implementation seems rather slow, iterating through a
> table would take O(n^2) time it seems.
Indeed. So don't do that then (the doc says this too!).
The standard table iterator does not use next().
Personally I regard next() as bit of a hackily exposed internal
implementation detail. Jill isn't the only implementation to
"penalise" next(), right?
drj
|
|
|
2009/12/10 Kristofer Karlsson < [hidden email]>:
> Cool, it would be interesting to know how this differs from MochaLua, LuaJ
> or Kahlua (did I miss any other pure Java implementations of Lua?)
It would indeed. A brief look at
http://code.google.com/p/kahlua/wiki/KahluaManual tells me that many
of the "top level" design decisions are settled in very similar ways
in both Jill and Kahlua. A Java double (actually often Double in
Jill) is a Lua number. A Lua string is a Java String. The GC is the
JVM GC, and so on.
I forgot to mention that Jill doesn't implement io.* (that page
reminded me), and that's of course because it's more or less
meaningless of CLDC 1.1
If I have more time, I'd like to look at the other implementations too.
drj
|
|
|
2009/12/10 David Jones < [hidden email]>:
> 2009/12/10 Kristofer Karlsson < [hidden email]>:
>> Also, your "next" implementation seems rather slow, iterating through a
>> table would take O(n^2) time it seems.
>
> Indeed. So don't do that then (the doc says this too!).
>
> The standard table iterator does not use next().
Just to be clear: Doing this: "for k,v in pairs(sometable) do ... end"
is efficient in Jill, and not at all O(n^2). Well actually this
depends on the underlying implementation of java.util.Hashtable, but
throw away any phone that has an inefficient keys() implementation.
drj
|
|
|
2009/12/10 Kristofer Karlsson < [hidden email]>:
> 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.
You might be amused to know that one of the reasons we didn't
implement yet another class was size. 3 years ago 128 kb was big for
a delivered JME app. And everything I know about JME can be
summarised in this sentence: "Each extra class adds 400 bytes to your
JAR." (roughly).
Jill has 33 classes (I think).
drj
|
|
Locked
