headers
Benjamin Tolputt | 1 Sep 2008 01:13
Picon
Gravatar

Re: LuaJIT + Pluto

Duncan Cross wrote:
> Yes, that's right. Since the whole point of LuaJIT is that it's
> converting Lua code to native machine code internally, when it is
> executed it is not running inside a Lua "thread" object that Pluto can
> inspect and serialize
Hmmm, that's a pickle. I was hoping the combination of both would give
me a serializable green-threaded environment with semi-native speed. So,
if I am correct in my understanding, LuaJIT discards the lua bytecode
and position information replacing it with a C-stack that we cannot
serialize using pluto (as it is no longer a Lua frame).

I wonder how much effort would be involved to move from one to the other
(i.e. from a LuaJIT runtime representation to a Lua runtime
representation) or if LuaJIT's transformation optimises the machine code
in such a way as to make this impossible. Perhaps Mike Pall could fill
us in on this (please?).

Regards,
B.J.Tolputt
Permalink | Reply | 4 comments |
headers
Benjamin Tolputt | 1 Sep 2008 01:19
Picon
Gravatar

Re: LuaJIT + Pluto

Duncan Cross wrote:
> Yes, that's right. Since the whole point of LuaJIT is that it's
> converting Lua code to native machine code internally, when it is
> executed it is not running inside a Lua "thread" object that Pluto can
> inspect and serialize.
>   
Or to continue on the same line of thought, perhaps this would not be
necessary given the new architecture of the LuaJIT 2.x (as outlined in
February's roadmap). Again, something only Mike Pall could answer I guess.

Regards,
B.J.Tolputt
Permalink | Reply | 0 comments |
headers
Mike Pall | 1 Sep 2008 02:14
Picon

Re: LuaJIT + Pluto

Benjamin Tolputt wrote:
> Hmmm, that's a pickle. I was hoping the combination of both would give
> me a serializable green-threaded environment with semi-native speed. So,
> if I am correct in my understanding, LuaJIT discards the lua bytecode
> and position information replacing it with a C-stack that we cannot
> serialize using pluto (as it is no longer a Lua frame).

The C stack frames created by the machine code from LuaJIT 1.x
actually mirror the frames in the Lua stack. But there may be some
intervening frames from C functions which cannot be reconstructed
easily. And persisting only the C stack of an arbitrary C program
is intractable. The stack may contain pointers to heap-allocated
objects which can end up at different addresses for different runs.

> Or to continue on the same line of thought, perhaps this would not be
> necessary given the new architecture of the LuaJIT 2.x (as outlined in
> February's roadmap).

Yes, LuaJIT 2.x doesn't switch between different C stacks for
coroutines anymore. A suspended coroutine could be serialized with
some effort. But the internal data formats are not compatible with
standard Lua, so you won't be able to use Pluto at all. I probably
need to add a native serialization module at a later time ...

--Mike
Permalink | Reply | 3 comments |
headers
Benjamin Tolputt | 1 Sep 2008 04:18
Picon
Gravatar

Re: LuaJIT + Pluto

Mike Pall wrote:
> The C stack frames created by the machine code from LuaJIT 1.x
> actually mirror the frames in the Lua stack. But there may be some
> intervening frames from C functions which cannot be reconstructed
> easily. And persisting only the C stack of an arbitrary C program
> is intractable. The stack may contain pointers to heap-allocated
> objects which can end up at different addresses for different runs.
>   
I had forgotten about the native stacks being interspersed in their.
Quite correctly, this would stuff things up.
> Yes, LuaJIT 2.x doesn't switch between different C stacks for
> coroutines anymore. A suspended coroutine could be serialized with
> some effort. But the internal data formats are not compatible with
> standard Lua, so you won't be able to use Pluto at all. I probably
> need to add a native serialization module at a later time ...
>   
Is "2008" still a viable target for releasing LuaJIT 2.x? Not after a
hard date, of course, just trying to ascertain an approximate time-frame
for being able to use this. Basically, I am looking for a fast
green-thread solution that can be saved to disk for resuming later. Lua
has almost everything it needs for this with the exception that the JIT
compilation prevents the serialization. If LuaJIT 2.x can do this in the
next, say, three to six months - it would be the solution I am looking for.

Thanks for the prompt feedback so far, Mike. Much appreciated :)

--Ben
Permalink | Reply | 2 comments |
headers
Mark Meijer | 1 Sep 2008 11:38
Picon

Re: LuaRocks with Windows/Visual Studio

Thanks!

2008/8/31 Hisham <hisham.hm <at> gmail.com>:
> On Sun, Aug 31, 2008 at 10:54 AM, Mark Meijer <meijer78 <at> gmail.com> wrote:
>> Thanks all for your replies.
>>
>>
>> 2008/8/28 Ralph Hempel <rhempel <at> hempeldesigngroup.com>:
>>> This is why I've been trying to update rockspecs for module builds that
>>> only specify the source required to build the rocks. So far I've got
>>> the three rocks I use the most - lfs, luasocket, and luasql - built
>>> using the updated rockspec.
>>
>> I didn't find LuaSQL in the default luarocks repository, but
>> LuaFileSystem and LuaSocket installed smoothly. If that is thanks to
>> you, then thanks a bunch :-) I use those a lot as well.
>
> The latest version of LuaSQL is still in release candidate status, and
> its rocks are in the "rocks-cvs" repository. You can try this:
>
> luarocks search luasql --from=http://luarocks.luaforge.net/rocks-cvs/
>
> -- Hisham
>
Permalink | Reply | 0 comments |
headers
Peter Cawley | 1 Sep 2008 16:15
Favicon

Why does LoadString return NULL for zero-length strings?

LoadString from lundump.c in Lua 5.1.4 is defined as:
static TString* LoadString(LoadState* S)
{
 size_t size;
 LoadVar(S,size);
 if (size==0)
  return NULL;
 else
 {
  char* s=luaZ_openspace(S->L,S->b,size);
  LoadBlock(S,s,size);
  return luaS_newlstr(S->L,s,size-1);		/* remove trailing '\0' */
 }
}

Obviously, the only time there should be a string constant in a binary
chunk of length 0 is when someone is being malicious, as the constant
should include the trailing \0 and therefore be at least length 1. I
believe that the if statement in the above code should be:
IF (size==0, "bad string");

As it stands, putting a zero length string constant into a binary
chunk causes a segfault: (http://codepad.org/N9ecIeIB)
loadstring(('').dump(function()X''end):gsub('\2%z%z%zX','\0\0\0'))()
Permalink | Reply | 4 comments |
headers
Luiz Henrique de Figueiredo | 1 Sep 2008 16:48
Picon

Re: Why does LoadString return NULL for zero-length strings?

> Obviously, the only time there should be a string constant in a binary
> chunk of length 0 is when someone is being malicious.

ldump.c outputs NULL for source strings when stripping debug info or
when it's the same as that of its parent function.

> As it stands, putting a zero length string constant into a binary
> chunk causes a segfault: (http://codepad.org/N9ecIeIB)
> loadstring(('').dump(function()X''end):gsub('\2%z%z%zX','\0\0\0'))()

Oh, thanks for spotting this.
Permalink | Reply | 2 comments |
headers
Peter Cawley | 1 Sep 2008 17:00
Favicon

Re: Why does LoadString return NULL for zero-length strings?

2008/9/1 Luiz Henrique de Figueiredo <lhf <at> tecgraf.puc-rio.br>:
>> Obviously, the only time there should be a string constant in a binary
>> chunk of length 0 is when someone is being malicious.
>
> ldump.c outputs NULL for source strings when stripping debug info or
> when it's the same as that of its parent function.
>
Ah yes; it's only strings from the constant table which should have
zeros on the end (I think?). Thus the check for NULL should be in the
constant loading code rather than the string loading code as I
suggested.
Permalink | Reply | 1 comment |
headers
Ralph Hempel | 1 Sep 2008 17:01

Re: LuaRocks with Windows/Visual Studio

Mark Meijer wrote:

> I didn't find LuaSQL in the default luarocks repository, but
> LuaFileSystem and LuaSocket installed smoothly. If that is thanks to
> you, then thanks a bunch :-) I use those a lot as well.

No, my changes are internal for now, but I will feed them back
to the LuaRocks group later.

Ralph
Permalink | Reply | 0 comments |
headers
Luiz Henrique de Figueiredo | 1 Sep 2008 18:23
Picon

Re: Why does LoadString return NULL for zero-length strings?

> Ah yes; it's only strings from the constant table which should have
> zeros on the end (I think?).

No, LoadString is called in LoadConstants and in LoadDebug.
Permalink | Reply | 0 comments |

Gmane