📃 SLua Alpha

// VM Luau default { state_entry() { float f = (float)1 / 0; llOwnerSay((string)f); // -- > Infinity vector v = <1, 1, 1> / 0; llOwnerSay((string)v); // -- > <Infinity, Infinity, Infinity> v = <0, 0, 0> / 0; llOwnerSay((string)v); // -- > <NaN, NaN, NaN> }} In VM Mono the 3 divisions are a Math Error run-time error.

I've been porting a set of three scripts to the LSL on luavm 2025 and have run into an unexpected memory limit issue. As the script has grown by my enabling more of it by integrating the three scripts into one, the USED memory size has crossed the 64k boundary. This includes code and data, and because of a different bug that Harold Linden is aware of (code size greater than 64k triggers a constructor fault), I've been working to keep the code under 64k (just barely at this point). Today I started getting these kinds of runtime errors: PRIMA Femme Elite v1.9 [script:body_lsl] Script run-time error not enough memory not enough memory [C] function ListInsertList [C] function ListReplaceList lsl_script function _fupdate_link_alpha lsl_script function _fchange_piece_shape lsl_script function _e0/state_entry By commenting out other code that is not used during the state_entry logic, the code runs. I'm guessing it's because there are checks in the list code called to make sure the lists are inside the 64k boundaries of days of yore. I have some skid marks in my code and what I see are these two messages before the script fault occurs: state_entry 0 used 61241 free 69831 state_entry2 1 used 66745 free 64327 The first one is the first statement in state_entry(). The second one is down a ways after I've initialized a bunch of my global variables. The third one I added to the code never runs because of the error shown above.

In beta grid, Luau 2026-03-24.23471922914, and in main grid, Luau 2026-01-30.21516666911 // VM Mono default { state_entry() { rotation r = (rotation)"hello"; llOwnerSay((string)r); }} // -- > <0.00000, 0.00000, 0.00000, 1.00000> // VM Luau default { state_entry() { rotation r = (rotation)"hello"; llOwnerSay((string)r); }} // -- > <0.00000, 0.00000, 0.00000, 0.00000>

In beta grid, Luau 2026-03-24.23471922914, and in main grid, Luau 2026-01-30.21516666911 local r = rotation(0,0,0,0) print(rotation.tofwd(r)) -- > <nan, nan, nan> print(ll.Rot2Fwd(r)) -- > <1, 0, 0> print(rotation.toleft(r)) -- > <nan, nan, nan> print(ll.Rot2Left(r)) -- > <0, 1, 0> print(rotation.toup(r)) -- > <nan, nan, nan> print(ll.Rot2Up(r)) -- > <0, 0, 1>

The compiler on agni is not doing as much constant-folding and dead-code elimination as the CLI tools. Take this script: print(gcinfo()) local a = "a" .."a".."a".."a".."a".."a".."a".."a".."a".."a" .."a".."a".."a".."a".."a".."a".."a".."a".."a".."a".."a" print(gcinfo()) Variable a should be constant-folded away, then eliminated as dead code, as it is unused On simulator version Luau 2026-01-30.21516666911 , this prints [4:29 PM] Object: 1.4892578125 [4:29 PM] Object: 1.525390625 The two numbers are different, so something entered memory in-between the two gcinfo calls However, when run locally, it prints: $ ./slua memtest.luau 38 38 The two numbers are the same, indicating nothing happened in memory in-between the two calls. Looking at the bytecode compiled locally: $ ./slua-compile memtest.luau Function 0 (??): 1: print(gcinfo()) GETIMPORT R0 1 [print] GETIMPORT R1 3 [gcinfo] CALL R1 0 -1 CALL R0 -1 0 4: print(gcinfo()) GETIMPORT R0 1 [print] GETIMPORT R1 3 [gcinfo] CALL R1 0 -1 CALL R0 -1 0 5: RETURN R0 0 nothing at all happens in between the two print statements. No allocation, no string concatenation, nothing I can't grab the bytecode for the simulator-compiled script, but it's clearly doing something differently

This script: u = ll.RezObjectWithParams("00", {}) print(`"{u}"`, typeof(u), u.bytes) prints [7:59 AM] Object: Could not find object '00'. [7:59 AM] Object: "" uuid nil

in slua: local t = {"a", "b", "c", "d"} local u = ll.ListReplaceList(t, {"x"}, 2, 2) print("t", lljson.encode(t)) -- t ["a","b","c","d"] print("u", lljson.encode(u)) -- u ["a","x","b","d"] -- expected ["a","x","c","d"] lsl is fine: default { state_entry() { list t = ["a", "b", "c", "d"]; list u = llListReplaceList(t, ["x"], 1, 1); llOwnerSay("t: " + llList2Json(JSON_ARRAY, t)); // t: ["a","b","c", "d"] llOwnerSay("u: " + llList2Json(JSON_ARRAY, u)); // u: ["a","x","c", "d"] // correct }} llcompat is fine: local t = {"a", "b", "c", "d"} local u = llcompat.ListReplaceList(t, {"x"}, 1, 1) print("t", lljson.encode(t)) -- t ["a","b","c", "d"] print("u", lljson.encode(u)) -- u ["a","x","c", "d"]

I would think these would always be equal in SLua: print(ll.GetMemoryLimit()) -- 130920 print(2^17) -- 131072 That's what it does in LSO; just returns a constant 2^14 default { state_entry() { llOwnerSay((string)llGetMemoryLimit()); // 16384 llOwnerSay((string)llPow(2, 14)); // 16384 }}

Using a notecard "test" with a line: Time flies like an arrow; fruit flies like a banana. -- one "Time": print(ll.FindNotecardTextSync("test","Time",0,0,{})[3]) -- 4 -- one "banana": print(ll.FindNotecardTextSync("test","banana",0,0,{})[3]) -- 6 -- two "like": print(ll.FindNotecardTextSync("test","like",0,0,{})[3]) -- 5 print(ll.FindNotecardTextSync("test","like",0,0,{})[6]) -- 5 -- two "flies": print(ll.FindNotecardTextSync("test","flies",0,0,{})[3]) -- 6 print(ll.FindNotecardTextSync("test","flies",0,0,{})[6]) -- 6 Could be related to this: https://feedback.secondlife.com/slua-alpha/p/the-length-returned-by-llfindnotecardtextsync-has-been-1-based previously to that canny all lengths were returned +1.

Unsure how important this is, but putting it out there: scalar doesn't work: > t = nil > print(t) nil > t = lljson.sldecode(lljson.slencode(t)) > print(t) lljson_constant: 0x0000000000000003 array doesn't work: > t = {nil, 2, nil, 4} > for i, v in t do print(i, v) end 2 2 4 4 > t = lljson.sldecode(lljson.slencode(t)) > for i, v in t do print(i, v) end 1 lljson_constant: 0x0000000000000003 2 2 3 lljson_constant: 0x0000000000000003 4 4 dict works: > t = {a=2, b=nil} > for i, v in t do print(i, v) end a 2 > t = lljson.sldecode(lljson.slencode(t)) > for i, v in t do print(i, v) end a 2 I don't anticipate running into this the way I plan to use slencode with LinksetData. There, I'll convert scalar nil to/from "" and never include nil in arrays. But, maybe someone else can think of a reason to do something different with one or more of these usecases