📃 SLua Alpha

Making this a Canny at Harold's request. The name "listeners" in this context is confusing because we already have "listen" events. "handlers" is a more accurate term that is unambiguous and already in general use when discussing the subject. I suppose that "listeners" could potentially be kept as an alias for backward compatibility, if deemed necessary, but I feel that its use should be deprecated to avoid future ambiguity. (Not sure of the appropriate category for things like this. Calling it a Bug since it entails a change in the source code.)

The syntax highlighter indicates that math.isnan should exist. However an attempt to use it results in an Attempt To Call A Nil Value error. Image showing error and highlighting compared to both valid and invalid math.xx expressions: https://imgur.com/3xX9lNe I lean toward fixing this by implementing math.isnan on principle of luau compatibility, but I don't have strong feelings about it either way. The number of likely users of math.isnan is incredibly small ( laughs one?) and I'm perfectly comfortable with using v~=v. (It's more succinct!)

lljson has inconsistent behavior. I think these should all produce an error: print(pcall(lljson.sldecode, '"!vOops"')) print(pcall(lljson.sldecode, '"!qOops"')) print(pcall(lljson.sldecode, '"!uOops"')) The first 2 produce an error: malformed tagged vector: !vOops malformed tagged quaternion: !qOops But the last one produces an uncompressed uuid: local _, u = pcall(lljson.sldecode, '"!uOops"') print(u, typeof(u), u.bytes) -- Oops uuid nil This uuid cannot be re-encoded: print(pcall(lljson.slencode, u)) invalid UUID format for JSON encoding Instead, sldecode should produce an error: malformed tagged uuid: !uOops And uncompressed uuid's should be removed from slua, it's documentation, and typechecker: https://github.com/secondlife/lsl-definitions/blob/23d46484888c1908545dc92db119613bb553af11/slua_definitions.yaml#L70 - name: bytes comment: Returns the raw 16-byte binary string of the UUID, or nil if the UUID is not in a compressed state type: string?

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

In the script editor, when I click "File > Load from File", the dialog box only allows me to select files who's name ends in .lsl. It should also allow me to select files who's name ends in .lua or .luau

tovector(nil) , toquaternion(nil) , and touuid(nil) should return nil , just like tonumber(nil) : > tonumber(nil) nil > tovector(nil) stdin:1: unable to cast! stack backtrace: [C] function tovector stdin:1 > toquaternion(nil) stdin:1: unable to cast! stack backtrace: [C] function toquaternion stdin:1 > touuid(nil) stdin:1: invalid argument #1 to 'touuid' (string expected, got nil) stack backtrace: [C] function touuid stdin:1

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.

LSL has these casting functions. They are not exposed directly in SLua. Here's what I've been replacing them with: (integer)x -> math.modf(tonumber(x) or 0) (float)x -> tonumber(x) or 0 (string)x -> tostring(x) (vector)x -> tovector(x) or ZERO_VECTOR (rotation)x -> toquaternion(x) or ZERO_ROTATION (key)x -> touuid(x) or NULL_KEY My (string) , (vector) , and (rotation) replacements seem to behave identically in all cases I've thought of. My (key) replacement behaves identically in all cases I actually care about. It's behavior doesn't match when the string is not a valid uuid, but, I actually prefer the new behavior, so I'm happy with the replacement. However, the (integer) replacement is a bit cumbersome. Additionally, (integer) and (float) have some very convenient behavior when you're parsing real notecards that aren't trivial to replicate using the luau standard library. My replacements get close, but don't behave the same in all cases: default { state_entry() { llOwnerSay((string)((integer)"0xf")); // 15 llOwnerSay((string)((integer)" 99.5 red baloons")); // 99 llOwnerSay((string)((float)" 99.5 red baloons")); // 99.500000 llOwnerSay((string)((float)" -99e2 red baloons")); // -9900.000000 }} In SLua, we still have indirect access to this behavior via ll.List2Integer and ll.List2Float : print(ll.List2Integer({"0xf"}, 1)) -- 15 print(ll.List2Integer({" 99.5 red baloons"}, 1)) -- 99 print(ll.List2Float({" 99.5 red baloons"}, 1)) -- 99.5 print(ll.List2Float({" -99.5e2 red baloons"}, 1)) -- -9950 print(tonumber("0xf")) -- 15 print(tonumber(" 99.5 red baloons")) -- nil print(tonumber(" -99.5e2 red baloons")) -- nil print(tonumber("-99.5e2")) -- -9950 But it would be nice to have a direct conversion, or even better, one that replicated all the oddities of the lsl casts, but returned nil rather than 0 on failure. Also, such functions might be necessary for the future LSL -> SLua transpiler

This appears to be related to highlighting. It is also influenced by the amount of code in the script and by the amount of comment text. However, commenting out all preceding code, or turning it all into a very long string, can make the problem vanish. The affected scripts compile and run without unexpected errors, but it becomes difficult to edit certain lines within the editor: Steps to reproduce: In an SLua Enabled Sim, rez a new prim. Create a new script, open it, and replace the contents with the attached script. Note that "LLEvents" in line 14 is highlighted in green. Attempt to select the line. Observe that only the word "function" is highlighted. Copy the line and paste at the bottom of the script. Observe that the whole line is pasted. Place the cursor at the left edge of the line and move right one character at a time with the arrow keys. Observe that the characters "s.touch_e" are skipped as a group. Attempt to select or erase "_end". Depending on your method, various failures will occur. Press End to move to the end of the line. Observe that the visible cursor is well past the end of the line, but that backspace deletes the last character. Note that when the line no longer represents a proper event that the line becomes normally editable. Comment out line 12. Observe that "LLEvents" becomes blue and the line is normally editable. Reenable line 12 and delete line 13. Observe the same. So far, I have only observed this with LLEvents.touch... All 3 are affected. In-Editor WORKAROUND: When editing an affected line, change the first keyword by adding an extra character at the beginning, such as making "LLEvents" into "xLLEvents". Edit the line as needed, then remove the extra character.

The following code snippet generates a one and a zero for my "vis" value shown in the DBG_MSG0 call (is_visible is an argument to the function declared as integer): // force into a boolean 0/1 value integer b4 = is_visible; is_visible = is_visible != 0; DBG_MSG0(["S1: change_piece_vis", full_piece_id, "vis", is_visible, b4, "link_num", link_num]); b4 is printing out as zero, while is_visible ends up being one. The "skid marks" that are the result of this action in my scripts look like this: set_body_flags 8 0 NEW body_vis_flags 7 S1: change_piece_vis 25 vis 1 0 link_num 57 The first skid mark is shows that body flags was indeed updated to have a zero at the relevant position confirming that the change_piece_vis code should be getting a zero value which is what b4 has stored. So the "is_visible != 0" clause is not generating the right value.