[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Protocol Specification in Lua
- From: Matthew Wild <mwild1@...>
- Date: Sat, 2 Oct 2010 21:07:47 +0100
On 2 October 2010 20:54, Alexander Gladysh <firstname.lastname@example.org> wrote:
> On Sat, Oct 2, 2010 at 11:33, Petr Štetiar <email@example.com> wrote:
>> John Passaniti <firstname.lastname@example.org> [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 :)