 |
lua-l archive |
|
|
||
|
On Jun 2, 2011 9:52 AM, "Florian Weimer" <fw@deneb.enyo.de> wrote:
>
> * Reuben Thomas:
>
> > I would ask, could one reimplement the C to _javascript_ translator
> > Emscripten with a Lua backend using this library?
>
> That depends on what optimizations Emscripten needs from the
> _javascript_ environment to achieve good performance. If it's just
> compact, mutable byte arrays, then the proposed library should be good
> enough.
>
> > And see _javascript_ typed arrays. That seems a good model.
>
> Including aliasing between different representations and strided
> arrays? It would certainly complicate the C API and add another
> indirection.
>
> Perhaps adding functions such as {get,put}{16,32}{le,be} enough which
> access the byte array at specified positions, using a specified width
> and endianness. A DNS header could be parsed like this:
>
> local txnid, flags, qcount, ancount, nscount, adcount =
> bytes.get16be(b, 1, 6)
>
> This seems more attractive to me in Lua than _javascript_ because there
> are multiple return values.
>
You might be interested in my Blob library ( http://segment6.blogspot.com ); it doesn't have all the nice features you describe, but it is a mutable byte array. For the most part it works transparently like a table. I coded it primarily to hold image data.
There is one potential caveat: the library lets you access any offset in the array (with bounds checking) as byte, short (2 bytes), int etc. On some platforms, accessing larger types unaligned (e.g. reading an int from offset 3) throws an exception. Thus it's possible for a script to crash your program this way.
I designed the library to be as fast and efficient as possible, with the idea that if these potential crashes are a problem, you can wrap the array in a metatable which forbids unaligned access at the cost of some performance. I've since wondered if it should do this by default, but that would mean changing the API...
--
Sent from my toaster.