📃 Lua Alpha

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.

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.

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

Possibly related to [ https://feedback.secondlife.com/scripting-bugs/p/script-suddently-losing-connetion-with-the-server-on-save ] A few times I've gotten the above error. Fixing the syntax error does not eliminate the message — it's as if the script inventory instance is permanently disabled. My workaround has been to copy the script text to a new inventory instance. I was able to reproduce this on SLua Tombolo. 1) Create a block and add a new SLua script to it. 2) Change line 1 to: `` xxx ll.Say(0, "Hello, Avatar!") `` 3) Save. See an expected, normal error message. 4) Clone the object. Edit the script in the clone. 5) Notice the cloned script is marked not-running. 6) Use the external editor button to edit the cloned script. See the dreaded (0,0) error. (I am using BBEdit as my external editor: /usr/bin/open -a bbedit "%s" ) --- Second Life Project lua editor 7.1.12.13973830462 (64bit) Release Notes You are at 194.7, 250.2, 23.1 in SLua Tombolo located at simhost-0766603a88e3665d6.aditi SLURL: secondlife://Aditi/secondlife/SLua%20Tombolo/195/250/23 (global coordinates 41154.7, 23802.2, 23.1) Luau 2025-03-27.14115520293 Release Notes CPU: Apple M2 Max (2400 MHz) Memory: 32768 MB OS Version: macOS 15.3.2 Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6020 x86_64 Graphics Card Vendor: Apple Graphics Card: Apple M2 Max OpenGL Version: 4.1 Metal - 89.3 Window size: 2602x2102 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 512m Bandwidth: 3000kbit/s LOD factor: 1.25 Render quality: 2 Texture memory: 21845MB Disk cache: Max size 1638.4 MB (99.9% used) HiDPI display mode: true J2C Decoder Version: KDU v7.10.4 Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.23.1 / OpenAL Community / OpenAL Soft: OpenAL Soft Dullahan: 1.14.0.202408091638 CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54 Chromium: 118.0.5993.54 LibVLC Version: 3.0.21 Voice Server Version: Not Connected Packets Lost: 13/10384 (0.1%) March 30 2025 06:20:01

default { state_entry() { // editor line 0 integer i = 0.5; // line 1 }} -- > Line 2: 'integer i' assigned a float value. The editor could start with line 1 (like with SLua), or the messages return the error line - 1.

The rational is simple enough. Even though 128k is bigger than ever, it's not infinite. Optimization controls that are "standard" aren't as useful as optimization controls that fit the demands of second life. Optimizations that reduce code footprint (e.g. aggressive constant folding) should be usable without triggering optimizations that increase code size in the name of performance. I don't know what optimizations are available, and how you want to treat optimization control in scripts, but it seems that tailoring them to fit second life make sense.

local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83706 tab1 = nil print(ll.GetUsedMemory()) -- > 83706 for i = 1, 5000 do tab2[i] = i end -- > Script run-time error not enough memory sleeping doesn't work: local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83741 tab1 = nil ll.Sleep(3) print(ll.GetUsedMemory()) -- > 83741 for i = 1, 5000 do tab2[i] = i end -- > Script run-time error not enough memory we need to move to another event, this works: local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83845 tab1 = nil LLTimers:once(0, function() print(ll.GetUsedMemory()) -- > 2190 for i = 1, 5000 do tab2[i] = i end print("ok") end) -- > ok

Slua viewer has a linux build: https://github.com/secondlife/viewer/releases/tag/Second_Life_Project%231bcae36f-SLua But it isn't listed on the release page: https://releasenotes.secondlife.com/viewer/26.1.0.21525310258.html