Re: Next Version of Lua?

[Niklas Frykholm <niklas@...>]

Yes, that would work and wouldn't be too tricky. The drawback is that
you would have to increase the size of the Value union to have room
for the biggest value type you wanted to support. Support for Vector3
would triple the size of Value and double the size of TValue. Which
would mean close to doubling the memory footprint of a running lua
application.

I'm targetting game consoles, where increasing the script memory from
30 MB to 50 MB or even 40 MB is a big deal... so I can't really go
that path.

// Niklas

2009/6/10 Asko Kauppi <askok@dnainternet.net>:
> About the complex type, LNUM patch allows all Lua numbers to be complex
> (compile with LNUM_COMPLEX defined; C99 required for C complex support).
>
> The approach could of course be extended to making a native 3D vector
> datatype, as well.
>
> -asko
>
>
> Niklas Frykholm kirjoitti 10.6.2009 kello 17:42:
>
>> 2009/6/10 Duncan Cross <duncan.cross@gmail.com>:
>>>
>>> On Wed, Jun 10, 2009 at 2:55 PM, Niklas Frykholm<niklas@frykholm.se>
>>> wrote:
>>>>
>>>> 2009/6/10 Olivier Hamel <evilpineapple@cox.net>:
>>>> Currently, if you want to create Complex or Vector3 type you have to
>>>> do it as a table or a userdata. And if you do a serious ammount of
>>>> processing on them, the ammount of garbage generated by simple
>>>> arithmetic operations will soon put a significant strain on the
>>>> system. (You could use a pool of such objects, but that would mean
>>>> resorting to manual memory management with all its pains - especially
>>>> when you are using it for something as simple as numbers.)
>>>
>>> Perhaps I am misunderstanding, but if the pool is a table that has
>>> been set to have weak values (i.e. its metatable's __mode field is set
>>> to 'v'), you should not have to do any manual memory management -
>>> values that only exist in the pool will be eligible for garbage
>>> collection.
>>
>> My description was a bit short, but the whole point of having a pool
>> was to avoid generating garbage. (By using a free object from the
>> pool, rather than creating a new one, whenever a new object is
>> needed.) But this requires us to manually track which objects in the
>> pool are free or not (i.e., manual memory management).
>>
>> If the objects in the pool are eligible for garbage collection, then
>> the pool doesn't really buy us anything. We will generate the same
>> ammount of garbage with the pool as without it.
>>
>> // Niklas
>
>