[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: lua-l Digest, Vol 3, Issue 7
- From: <jgiors@...>
- Date: Sat, 02 Oct 2010 12:19:32 -0700
> -------- Original Message --------
> Date: Sat, 2 Oct 2010 09:33:04 +0200
> From: Petr ?tetiar <firstname.lastname@example.org>
> Subject: Re: Protocol Specification in Lua
> To: Lua mailing list <email@example.com>
> Message-ID: <20101002073304.GC28423@ibawizard.net>
> Content-Type: text/plain; charset=us-ascii
> 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.
> Back to your subject. I would take a look at Metalua, using it, you can easily
> generate your C protocol parser code for the Coldfire just by parsing your
> protocol specification in Lua.
> -- ynezz
You might find the article "Lua as a Protocol Language" in Lua
Programming Gems useful, or at least interesting. It describes sending
Lua strings rather than compiled tables, but the basic idea is the same.
Three Eyes Software