lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 2 October 2010 20:54, Alexander Gladysh <agladysh@gmail.com> wrote:
> On Sat, Oct 2, 2010 at 11:33, Petr Štetiar <ynezz@true.cz> wrote:
>> John Passaniti <john@japanisshinto.com> [2010-10-01 14:53:18]:
>
>>> The generation of code from the protocol description isn't driven by a
>>> fear of the efficiency of Lua.  It's driven by the fact that I don't
>>> think Lua is going to be running on a 8-bit Freescale HCS08
>>> microcontroller running at 24MHz anytime soon.  And the larger
>>> platform the C code targets is a ColdFire that has about 16k of RAM
>>> left over and about twice that in ROM.  Yes, I'm one of those embedded
>>> systems guys who hangs out in this mailing list to remind everyone
>>> that while Lua can go lots of places, it can't go everywhere.
>
>> It's a shame, you couldn't use Lua directly. Otherwise is quite easy and
>> comfortable to send just compiled Lua table along with checksum over the UDP.
>> In the short something like <size><bytecode><crc> in the packet. Imagine, that
>> the Lua tables can contain functions, so the possibilities of such protocol
>> are endless.
>
> It is unsafe to receive and load raw bytecode.
>

I shouldn't think aloud, it usually comes back to bite me. But I
wonder how hard it would be to make a library by stripping down Lua so
that it only implements enough to compile and load table constructors.
Then you get a nice way to save/load arbitrary structures, an API to
iterate and manipulate them, and compatibility with normal Lua. No?

I'm fairly sure it would be possible to write a bytecode verifier for
this small subset, also, to make loading into normal Lua safe within
scripts. Perhaps even an in-Lua interpreter for it for the paranoid :)

Matthew