RE: Mochalua - Lua for J2ME

["Patrick Meehan" <patrick@...>]

Thanks, Kristofer, that seems like a good distinction to me.  :)

Re #5 below, this is accomplished through a simple reference counter attached to userdata.  When the counter reaches zero, the __gc metamethod gets called.

A lot of the size of Mochalua comes from the library implementations - math, string, debug, etc.  But I do like the distinction of fully featured vs. lean and mean.  People should use Mochalua if they are targeting devices that can handle a larger footprint.

Cheers,
P

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Kristofer Karlsson
Sent: Tuesday, November 18, 2008 12:06 AM
To: Lua list
Subject: Re: Mochalua - Lua for J2ME

Hi, I am the author or Kahlua.
This is a very interesting project, and I will take a deeper look at it later (I am at work right now).
>From what I can tell, the main differences between Kahlua and Mochalua are:

1) Mochalua is intended to be a full port of Lua, as close to the original as possible, whereas Kahlua is intended to be a minimal reimplementation of the Lua Virtual Machine. Kahlua also tries to emulate all the base library as much as is reasonable without adding too much bloat.

2) Kahlua is intended to be as small as possible, for distribution on mobile devices. The jar file produced by Kahlua is 50KB and the one you can download from Mochalua is 287KB. A more interesting figure might be how large they are after obfuscation, but I haven't done that comparison yet.

3) Kahlua has a goal of keeping the source code light. Total lines of code is 4805 in Kahlua and 16951 in Mochalua.

4) Kahlua has a goal of keeping the number of classes light. I used this simple tool to measure it: rgrep " class " *|grep -v svn|wc Kahlua has 15 and Mochalua has 208.

5) Kahlua has a goal of reusing as much as possible from the Java world - for instance, Kahlua doesn't implement any garbage collection of its own, which means it can't provide utility hooks such as __gc. I have not delved into the details of Mochalua, but if it provides __gc, it seems like it should have to perform some garbage collection manually. Is this a reasonable guess? :-)

6) Integration with Kahlua is different compared to how you do it from C. I personally think it's easier in Kahlua, since you get immediate access to all objects in Lua space. In fact, the distinction between Lua space and C/Java space is barely there at all in Kahlua. Mochalua has probably the benefit of being easier to work with for people who are used to the behaviour of using Lua with C.

As a note, Kahlua does have support for Coroutines these days, and they seem to work quite well, I'm happy to say! :-)

As I said, I'll take a closer look later, but Mochalua indeed looks interesting!

/Kristofer

On Tue, Nov 18, 2008 at 3:58 AM, Patrick Meehan <patrick@groundspeak.com> wrote:
> There's a .jar up now for anyone interested.
>
> Re differences from the current version of Kahlua, I couldn't say.  When we first looked at what was out there it seemed like the implementation of Kahlua was pretty preliminary - the author was still thinking about how to do things like coroutines.  It looked like (as I recall) just the basic LVM.  I don't think it implemented much of the Lua API.
>
> We commissioned Mochalua so we could port a mature C language code base we use internally, so the focus was on being fully featured.  It is intended to be an exhaustive port of everything but the compiler.  It's (slavishly) true to the C API - you should be able to just cut and paste your C language glue code, prefix it with the API classname and have it work.  We've ported (almost) the entire API, Lua libraries, debug libraries and LVM functionality (coroutines, etc.).  We even trap userdata going out of scope and call the __gc metamethod.  Mochalua also reports the standard Lua runtime errors with file name and line number in the same format as the C version.
>
> Kahlua may have come a long way since we looked at earlier this year; once we committed to doing our own port, we didn't look back.
>
> Anyway, at the very least Mochalua is another Lua implementation for people to consider.  I should also mention that it includes a J2ME port of a lot of the C standard libraries to support the Lua libraries - math.h, printf, etc.  It was written for J2ME, but can certainly be retargetted for any Java project - there should be nothing inside of the Mochalua source that requires or expects a Midlet to run.
>
> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br 
> [mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of David Manura
> Sent: Monday, November 17, 2008 5:48 PM
> To: lua@bazar2.conectiva.com.br
> Subject: Re: Mochalua - Lua for J2ME
>
>> On Mon, Nov 17, 2008 at 4:42 PM, Patrick Meehan wrote:
>> > I'd like to announce the release of Mochalua, a J2ME port of the 
>> > Lua runtime and API, as open source under the MIT license.
>
> This is now on the Lua Implementations page[1], but could you elaborate on the differences between Mochalua[2] and Kahlua[3]?
>
> [1] http://lua-users.org/wiki/LuaImplementations
> [2] http://code.google.com/p/mochalua/
> [3] http://code.google.com/p/kahlua/
>
>
>
>
>