Add Table flattening to ll.* functions that accept long lists. | Voters

Add Table flattening to ll.* functions that accept long lists.

WolfGang Senizen

SLua has no means of concatenating tables, this makes several functions designed for LSL incredibly unwieldy to use.
A common practice for instance is to to loop a function call and build up a list of parameters append them to an existing list, then once done send it all to SetLinkPrimitiveParamsFast.
SLua also struggles somewhat for memory and hits out of memory errors on lists that aren't incredibly long compared to LSL. Due to the table memory allocation doubling all of a sudden, which for many users is an enourmous footgun, as tabl[#tabl+1] = 1
 taking their script form 64k memory to OOM is incredibly counter intuative.
This leaves slua looking no better than LSL to many scripters for a very common task in SL.
Until either better more 'lua' api's exist, or table memory allocation can be changed, it would be nice if the functions could accept nested tables and flatten them.
Proposal
ll.SetLinkPrimitiveParamsFast( 1, {
    PRIM_COLOR, {1,vector(1,0,0),1.0},
    {PRIM_TEXT, "Text", {vector(1,1,1)},1.0},
    PRIM_SIZE, vector(1,1,1)
})
-- OR
ll.SetLinkPrimitiveParamsFast( 1, {
    {PRIM_COLOR, 1,vector(1,0,0),1.0},
    {PRIM_TEXT, "Text",vector(1,1,1),1.0},
    {PRIM_SIZE, vector(1,1,1)}
})
Would get flattened to
ll.SetLinkPrimitiveParamsFast( 1, {
    PRIM_COLOR, 1,vector(1,0,0),1.0,
    PRIM_TEXT, "Text",vector(1,1,1),1.0,
    PRIM_SIZE, vector(1,1,1)
})
This would make using SetLinkPrimitiveParams
 allot less painful, and also help with things like
- LinkParticleSystem
- RezObjectWithParams
- SetAgentEnvironment
- HTTPRequest
This would also help aleviate the memory impact of LONG tables for set linkprimitive params, by allowing a scripter to break up their long list into several smaller ones and send them together. Not always, but 10 tables of 8 keys are 2560 bytes compared to 80 keys taking 4096 with the memory doubling tables do as you expand them.
There is of course... one major caveat to this, the flattened table, while it exists needs to be be counted against the script that's running >.>

A week ago

Harold Linden

WolfGang Senizen In light of the

table

memory usage changes in https://github.com/secondlife/slua/commit/3cc3cff4b565a16ceff359545b8105e8d9326012 and https://github.com/secondlife/slua/commit/8325a268403c9ca4cdbc912815b7e4808bc7fe16, does it make sense to allow nested lists like this?

It doesn't improve API safety at all, and many small lists are higher-overhead than a large list once those changes are deployed.

Very Vanilla

Harold Linden Alternatively, relatedly- it feels like PrimParams at least, should be able to simply accept a nested list and parse it correctly? Most of the other functions listed simply have a flag and a single value after, but PrimParams especially has fairly long lists of values to go with its flags. From a user standpoint, it makes sense to make each one a small array.

SuzannaLinn Resident

Harold Linden What about a function of more general use, especially with long arrays, like this: https://feedback.secondlife.com/slua-alpha/p/tableextend-to-add-two-or-more-array-tables-without-requiring-extra-temporary-me

Frio Belmonte

Especially with the final caveat and the added management for potentially no extra safety, a more efficient method might be needed, preferably something entirely new but unsure what that could be. Function calls to ll. functions are already relatively slow enough that I avoid them in performance-maxed situations so some kind of a "prepare parameter chunk/commit parameters" thing doesn't sound ideal.
Also not the greatest idea, but my mind goes to buffers as an alternative input type.
Pros: memory efficient, fast, mutable content so you could do a template where you only change relevant values and then call again much like with tables.
Cons: can't be resized so max size must be known in advance, templating likely not useful for strings due to varying lengths, doesn't support vector/quaternion without manual componentwise writes, nitpicky bytewise addressing might be scary, would need to be able to gracefully handle extra zeros at the end from overlarge buffers.
Okay, really not the greatest, but still throwing it out there. I'd still use them myself.

WolfGang Senizen

As pointed out the very first line of this is wrong.

you can concat tables via copying the values

table.move(source, 1, #source, #dest + 1, dest)

Thanks to Kristy for reminding me.

But as its via copying it doesn't alleviate the sudden OOM issue, if anything exacerbates it some.

Very Vanilla

This REALLY feels like it would help.. except of course the bit at the bottom about the flattened list still counting. dfjklasj
It is painful that the memory problem is worse in some ways, despite the doubling to 128kb. The lower memory limit in LSL was an issue, but lists allocated it in small enough chunks that you could effectively ALWAYS see when memory is low, and manage your list before it ran out.
In Lua, you can go from 50kb remaining to an OOM crash with assigning a single extra thing to a table. It makes creating lists for large, efficient llSetLinkPrimitiveParams operations effectively impossible.
In converting some of my scripts over to SLua, I've had to totally forgo the batching and just spam llSetPrimParams instead.

Gabryel Nyoki

I was hoping the big lists/ memory issue would be improved with SLua, I have scripts that I have had to ask chatGPT to help me reduce memory cost and use only 'for' loops with variables, if memory is going to be an issue, SLua might face resistance, I can't be the only one using stranded lists in packed sims heh