📃 Lua Alpha

While trying to stress test / benchmark a comparison for (string) list and llDumpList2String , I came across a register exhaustion for a script in lsl-luau that works in mono. I'm reporting both as one canny because I'm unsure if these are related. A) First, for the benchmark: In LSO: === list-to-string benchmark: 100 iterations x 300 items === (string)list total = 1040.432007 ms mean = 10.404320 ms llDumpList2String total = 1896.921143 ms mean = 18.969212 ms ratio (string/dump) = 0.548485x === DONE === In Mono: === list-to-string benchmark: 100 iterations x 300 items === (string)list total = 226.023000 ms mean = 2.260230 ms llDumpList2String total = 316.186000 ms mean = 3.161860 ms ratio (string/dump) = 0.714842x === DONE === In LSL-LUAU: === list-to-string benchmark: 100 iterations x 300 items === (string)list total = 2287.902000 ms mean = 22.879020 ms llDumpList2String total = 589.087000 ms mean = 5.890871 ms ratio (string/dump) = 3.883810x === DONE === === list-to-string benchmark: 100 reps x 500 items === (string)list total = 4536.675000 ms mean = 45.366750 ms llDumpList2String total = 1022.474000 ms mean = 10.224740 ms ratio (string/dump) = 4.436957x === DONE === Something about how casting a list to a string is way worse in lsl-luau. My thought was that it's likely something that could be optimized if llDumpList2String is about 4x faster already. B) Second, a test script of the discrepancy is the following default { state_entry() { integer i = 1; string s = (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i + (string)i ; llOwnerSay(s); } } It prints "1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" in mono, but in lsl-luau it fails to compile with "Out of registers when trying to allocate 1 registers: exceeded limit 255" I doubt there are many real use cases where this would have an impact after switching off mono, but it is still a notable difference.

Something about the way lsl-luau handles state changes differs from Mono. It appears like the state is changed immediately instead of after the whole event is handled. Take this test script: integer screwthisimout() { if (TRUE) state other; return 13; } default { state_entry() { integer r = screwthisimout(); llOwnerSay("after state change, r=" + (string)r); } } state other { state_entry() { llOwnerSay("entered state other"); } } In mono, you see both llOwnerSay printed, State_Entry fully finished, the output is: after state change, r=0 entered state other in lsl-luau, state_entry doesn't get to finish and only outputs: entered state other Tested on the latest 2026-07-24 luau channel

Here is a list of observed differences between Mono and LSL VM: float nan = (float)"nan"; llOwnerSay((string)(nan >= 1.0)); // Output: LSO=math error Mono=1 LSL-LUAU=0 llOwnerSay((string)(nan <= 1.0)); // Output: LSO=math error Mono=1 LSL-LUAU=0 And a test script: integer param(integer p) { return p++ + p; } default { state_entry() { integer a = 1; llOwnerSay("1 (Mono = 0): " + (string)((a = 2) == a)); // Output in lsl-luau: 1 a = 1; llOwnerSay("2 (Mono = 1): " + (string)(a++ == a)); // Output in lsl-luau: 0 llOwnerSay("3 (Mono = 2): " + (string)param(1)); // Output in lsl-luau: 3 // float->int cast float f = 0.7; llOwnerSay("4 (Mono = 7): " + (string)((integer)(f * 10.0))); // Output in lsl-luau: 6 integer i = 16777217; float z = 0.0; llOwnerSay("5 (Mono= 16777216): " + (string)((integer)(i + z))); // Output in lsl-luau: 16777217 // bit shifts integer s = 32; llOwnerSay("6 (Mono = 1): " + (string)(1 << s)); // Output in lsl-luau: 0 llOwnerSay("7 (Mono = -2147483648): " + (string)(1 << -1)); // Output in lsl-luau: 0 llOwnerSay("8 (Mono = 4): " + (string)(8 >> 33)); // Output in lsl-luau: 0 } }

String.gmatch can become stuck in use after an error. Take this example debug script: local it = string.gmatch("hello world", "(%a)%2") local ok1, err1 = pcall(it) print("call 1:", ok1, err1) local ok2, err2 = pcall(it) print("call 2:", ok2, err2) It outputs: call 1: false invalid capture index %2 call 2: false gmatch iterator is already in use While I would expect: call 1: false invalid capture index %2 call 2: false invalid capture index %2

I wrote a test script, and ll.DumpList2String is literally the only ll list function that rejects booleans in it's list, and gives the error "non-LSL value in list" instead: print(ll.DumpList2String({true, false}, ",")) [9:41 AM] Object: Object [script:New Script] Script run-time error [9:41 AM] Object: lua_script:1: non-LSL value in list [C] function DumpList2String lua_script:1 I expected it to print 1,0 instead, like ll.List2CSV does: print(`{ll.List2CSV({true, false})}`) --> 1, 0 I do not have a script that stores booleans in lists that would benefit from this, so, I removed my vote from this post. Mostly I just like that ll.DumpList2String is still a very useful function even in luau Verification script and it's output are attached, generated from https://github.com/secondlife/lsl-definitions/pull/199

After running continuously for several weeks, my emulator script halted with this error: A Simple Sun-Earth-Moon emulator.: 0.3 [script:Sun-Earth-Moon demo] Script run-time error Failed to perform mandatory yield lua_script:159 function emulation_step [C] function _tick [C] function timer_event_wrapper [C] function _handleEvent The script, or an earlier version thereof, has halted similarly on at least two previous occasions. This, however, is the first time I've been on Sim when the crash occurred to receive the error message. Full script @ https://pastebin.com/PAg61t1K The instance of the object that crashed is at https://maps.secondlife.com/secondlife/Builders%20Brewery%20Sandbox/36/69/498 Anyone may take a full perms copy. I have not reset the script.

I encountered this Mono vs LSL VM discrepancy while trying to use AVSitter compiled to the LSL VM (offsets would fail to work due to how lists are handled in sitA) Here is a sample script that breaks on LSL VM but works on Mono: default { state_entry() { list vectors = [<1,0,1>,<0,-0.192,2.479>]; vectors = [(vector)llList2String(vectors, 0),(vector)llList2String(vectors, 1)]; // <--- does not work in lsl vm llSay(0,"LSL VM TEST VECTOR PARSE: " + (string)((vector)llList2String(vectors, 1))); } } This pattern breaks compatibility due to the self-referenced assignment, the vectors array becomes [<0,0,0>, <0,0,0>] instead of keeping the same values [<1,0,1>,<0,-0.192,2.479>]. The expected output of llSay here is <0,-0.192,2.479> like in Mono, but in lsl vm it outputs <0,0,0> Tested in Clawed region, current simulator: Luau 2026-06-09.27238848717 A simpler version that also breaks: default { state_entry() { list integers = [1,2,3]; integers = [llList2Integer(integers, 0)]; llSay(0, llList2String(integers, 0)); // Expected Output: 1, Actual: 0 } } Some further observations from Suzanna: Another example, tested on the Beta grid, Luau 2026-07-24.30110090421: default { state_entry() { list myList = ["test"]; myList = [myList == []]; // myList should be [0] llOwnerSay((string)myList); // --> 1 } } When the list being assigned to is also used inside the expression, its value is evaluated to an empty list. I think the bug comes from here: https://github.com/secondlife/slua/blob/ab883b7072887e73d5f962bd6d35467d098276d8/Compiler/src/LSLCompiler.cpp#L921-L964 where the destination list is assigned a new empty table before evaluating the expression.

When drag-copying an object containing a halted LSL-Mono script, the script in the new copy is also halted. This is the desired behavior. When drag-copying an object containing a halted SLua script the copied script may start running depending on A, the exact contents of the script, and B, whether one is copying a single instance or multiple instances. Procedure to reproduce: Step 1: Rez a block. Put the following script in the block, mark it Not Running, and save. local base = ll.GetPos() while true do ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(math.random()-0.5, 0, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, math.random()-0.5, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, 0, math.random()-0.5) + (base + ll.GetPos())/2 } ) ll.SetText( tostring(ll.GetPos()-base), vector(1,1,1), 1 ) end--while Drag-copy the object horizontally several times. Observe that the script remains halted. Select the newly created group of objects. Drag-copy the group vertically several times. Observe that some or all scripts in the new copies spontaneously start running. Step 2: Delete the first group. Rez a new block and put the following nearly identical script in it. (Difference is ll.SetText argument in line 6.) Again, mark it as not running and save. local base = ll.GetPos() while true do ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(math.random()-0.5, 0, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, math.random()-0.5, 0) + (base + ll.GetPos())/2 } ) ll.SetLinkPrimitiveParamsFast( LINK_THIS, {PRIM_POSITION, vector(0, 0, math.random()-0.5) + (base + ll.GetPos())/2 } ) ll.SetText( tostring(os.clock()), vector(1,1,1), 1 ) end--while Again, drag-copy the object. Observe that the new copy starts running immediately every time. As you can imagine, this bug defeats attempts to start a group of test scripts together, or to precisely place a group of objects containing scripts that will move the objects before starting.

When calling ll.GetUsedMemory() or ll.GetFreeMemory() immediately after some memory operation: -- memory miscount local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) print(ll.GetUsedMemory() - mem) -- > 560 -- should be 16 Adding something that yields works well (it seems that yielding cleans things): -- yielding local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) for _ = 1, 1 do end -- yielding print(ll.GetUsedMemory() - mem) -- > 16 Also calling the function twice (perhaps because they yield at the end): -- calling twice local tab = {} local mem = ll.GetUsedMemory() tab = table.create(32, true) print(ll.GetUsedMemory() - mem) -- > 512 tab = table.move(tab, 1, 1, 1, {}) local used, used = ll.GetUsedMemory(), ll.GetUsedMemory() print(used - mem) -- > 16 Could ll.GetUsedMemory() and ll.GetFreeMemory() yield at the start to update the memory?

While this caveat behavior is known and possibly relied upon by lsl scripts. Nobody should be writing a slua script expecting this security issue to exist. So if possible could a ll.HTTPRequest from slua, only trigger the http_response event in the slua script making the request. Or a dataserver request also respond only to the requesting script. Not in any other, script regardless of their platform runtime. This might be a slight pain to implement to keep the behavior for lsl on luau scripts, but I think worth it for slua Test Place 2 scripts in a prim save them with the following content ll.HTTPRequest("https://secondlife.com",{},"") function http_response(id,stat,meta,body) ll.OwnerSay(`{ll.GetScriptName()} = {stat}`) end Note that on saving of the second script you get 2 owner says, one from each script stating the response status. Ideally this behavior should be avoided for slua. Alternate suggestion It was suggested it may be possible to instead add a new HTTP_* flag Something like ll.HTTPRequest( "https://secondlife.com", { HTTP_PRIVATE_REQUEST, TRUE }, "" ) This would not work for dataserver events though