Re: Extending Lua for multiple light userdata types

[liam mail <liam.list@...>]

On 13 November 2012 20:35, Coda Highland <chighland@gmail.com> wrote:
> On Tue, Nov 13, 2012 at 12:29 PM, Rena <hyperhacker@gmail.com> wrote:
>> On Tue, Nov 13, 2012 at 3:05 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>> 2012/11/13 Rena <hyperhacker@gmail.com>:
>>>> On Tue, Nov 13, 2012 at 10:42 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>>>> 2012/11/13 Rena <hyperhacker@gmail.com>:
>>>>>
>>>>>> Recently I was thinking about how you might add a 64-bit integer type to Lua.
>>>>>
>>>>> This is only a pressing question if you need IEEE floats and 64-bit integers
>>>>> in the same program, otherwise you can build Lua with 64-bit integers
>>>>> as your `number`.
>>>>>
>>>>
>>>> True, but I really prefer to leave recompiling Lua as a last resort.
>>>
>>> How do you envisage accommodating new types without patching
>>> and recompiling Lua?
>>>
>>
>> ...that was kind of the point of the original post. Already you have
>> lua_pushlightuserdata(L, p); this could be as simple as
>> lua_pushcustomuserdata(L, p, n), which functions the same as
>> lua_pushlightuserdata except for adding n to the "type" value
>> (LUA_TLIGHTUSERDATA + n + 1, for n = 0 to some appropriate upper
>> bound), and having those types be something like union { uint64_t int;
>> uint8_t byte[8]; } instead of void*. You'd only need the initial
>> change to add this capability, instead of hardcoding new types into
>> Lua directly.
>>
>> --
>> Sent from my Game Boy.
>>
>
> As I said, if this is something you really want, LuaJIT already does
> almost exactly that with its cdata type. If you care about low-level
> data types, you're PROBABLY also interested in everything else LuaJIT
> has to offer.
>
> /s/ Adam
>

Yes yes, I think we all know where you stand in trying to tell people
that they need LuaJIT.

This conversation started in IRC and I fully agree with Rena which
will come as no surprise as I have said this before. It is 2012 and
yet Lua has no access to a 64 bit int(in fact from the C API point of
view it was even considered to remove the default lua_Integer as a
typedef for ptrdiff_t ), before too long the majority of people will
not care about 32 bit systems and even arm is getting a 64 bit
version, when will Rio Lua have a 64 bit int? When will we be able to
sanely do bit operations on 64bit types without resorting using
strings *?


--Liam

* As a side note bit operations in Lua using functions makes me eyes
bleed, it really needs the power patch applied or something else
considered because as it is the situation is awful.