Re: [ANN] Lua 5.3.0 (work2) now available

[Coroutines <coroutines@...>]

On Sun, Mar 23, 2014 at 6:50 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> This is sort of the reason why I wish Lua's core had a library
>> specifically for buffers, something where you can create userdata
>> buffers and fill it with lua values rawly, and then convert it into a
>> immutable, pooled Lua string if you wish.
>
> The traditional method is this:
>
>   local buffer = {}  -- create a buffer
>
>   buffer[#buffer + 1] = x    -- add values
>
>   s = table.concat(buffer)    -- convert it into a immutable Lua string
>
> Yes, I know, it would be faster with specific support. Mostly everything
> in Lua (or any other interpreter) would be faster with specific support.
>
> -- Roberto
>

I know what you're getting at, Mr. Roberto. :-)  It just seems like a
fair number of people do implement a buffer object type in third-party
projects.  What gets me is how many people forgo using the perfectly
adequate luaL_Buffer (maybe it gets overlooked?).  I thought luasocket
had a need to roll its own because it needed a persistent buffer
between recv()'s, but it looks a bit sketchy-large.  Furthermore
having a standard buffer library would remove the large possibility of
people creating incorrect/leaky buffer libraries.  Really you only
need a library that can create luaL_Buffer and has these functions
exposed (in a friendlier form): luaL_buffinit*(), luaL_add*(),
luaL_prep*(), luaL_push*().  To Lua it'd just be userdata (as always).
 It would also need support for iterating over buffers byte-by-byte
(pushing lua_Number's like string.byte()).  You could also iterate in
lua_Integer strides up to the remaining bytes (and then copy the
fragment into the final luaL_Number) for a faster form.  I really
don't think this would be asking for a lot the facility is there, but
i'm a loon so ~

(I'll give you a puppy?  His name is Benedict Cumberbatch and he likes
to lick faces.)