Re: status and perceptions of luaproc

[Rena <hyperhacker@...>]

On Sat, Aug 8, 2015 at 2:26 PM, Patrick Donnelly <batrick@batbytes.com> wrote:
> On Sat, Aug 8, 2015 at 12:42 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
>> Am 08.08.2015 um 18:02 schröbte Patrick Donnelly:
>>>
>>> On Fri, Aug 7, 2015 at 5:00 PM, Rena <hyperhacker@gmail.com> wrote:
>>>>
>>>>
>>>> On Aug 7, 2015 3:42 PM, "William Ahern" <william@25thandclement.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>    If you were to design a new language today, he said, you would make
>>>>> it
>>>>>    without mutable (changeable) objects, or with limited mutability.
>>>>>
>>>>>    -- Guido on Python, discussing the GIL. See
>>>>> https://lwn.net/Articles/651967/
>>>>>
>>>>
>>>> Well, that's pretty convincing. Though I still feel like Lua could
>>>> benefit from a "copy string from other state" function that can avoid the
>>>> duplication and rehashing. (Does POSIX provide a thread-safe
>>>> reference-counted memory block API?) Same for tables and functions, assuming
>>>> it could be done any more efficiently on the "inside" compared to using the
>>>> public APIs. Faster/less wasteful passing of objects (especially strings)
>>>> between independent states within a process would be quite helpful for
>>>> message passing.
>>>
>>>
>>> <tangent>
>>> Something I'd like to see is the ability to represent memory mappings
>>> as strings in a Lua state. Obviously creating a mapping is possible
>>> with libraries like luaposix or LuaJIT's FFI, but what is really
>>> missing is a way to *use* those mappings as regular Lua strings. And
>>> when I say "as regular Lua strings", I mean from a library perspective
>>> (like the string library). [After all, Lua strings are just blobs of
>>> data you can create via literals and/or concat operations. Without
>>> libraries like io/string, they have have no real function or utility.]
>>>
>>> Using memory mappings like strings in Python (for some APIs) is one of
>>> the few things I like about that language. If we could provide a
>>> similar API (read: metamethod) for converting an object to a <light
>>> userdata pointer, length> tuple usable wherever a string is desired,
>>> then we could see the same thing in Lua. [Of course, note that
>>> lua_touserdata is not what we need since a memory mapping is not
>>> managed by the Lua allocator.] I see lua_tostring as the right API to
>>> abstract the conversion.
>>> </tangent>
>>
>>
>> Lua strings are immutable, a memory mapping can change behind your back, so
>> you can't use those "strings" as table keys, you can't cache hash values,
>> any you might get inconsistent data if you process those "strings"
>> piece-wise.
>
> You're quite right but I don't see that as a problem. The memory
> mappings are still userdata (and can be used in tables normally) but
> are convertible to Lua strings in C library code.
>
> --
> Patrick Donnelly
>

Seems like you could even implement a mutable string type this way,
though I wonder how difficult it would be to get things to treat it
like a regular string.

-- 
Sent from my Game Boy.