📃 SLua Alpha

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 >.>

myRequestId = ll.HTTPRequest(myUrl, { HTTP_BODY_MAXLENGTH, 16384 }, "") Currently the maximum is 16384 in VM Mono and 4096 in VM LSO. In VM Luau, with more script memory, the maximum could be 32k or 64k.

The project/lua_editor viewer currently uses a bit of a hack to insert a default slua script. It would be good to clean this up along with the new script feature in the inventory. Proposal : Object content panel New script on an objects contents should default to a clean slua script THAT USES OWNERSAY not say, with an optional drop down next to the new script button to choose a new lsl script instead. While we are at it, it would be good if there was a config setting in the viewer to specify an alternate default script (from inventory?). Proposal : New script in inventory Either: - New script should default to creating a slua script - There could be 2 options New Slua Script / New LSL Script Related issues https://feedback.secondlife.com/slua-alpha/p/new-script-without-state-entry-and-hello-avatar-with-ownersay Though as Suzanna can likely no longer edit it LLEvents:on("touch_start", function(touches) ll.Say(0, "Touched.") end) ll.OwnerSay("Hello, Avatar!")

This seems to be some oversight that there is no way to actually a way to loop over the characters of a utf8 string. The roblox docs mention a utf8.graphemes but this doesn't seem to have been upstreamed into luau, so we would need our own utf8.graphemes in SLua to do the same. Graphemes make more sense into what a scripter would usually want to actually intuitively access or iterate over in a string. This is very important for any platform dealing with internationalisation and emojis. * See here for difference of the terms: https://stackoverflow.com/a/27331885 * Roblox's utf8.graphemes: https://create.roblox.com/docs/reference/engine/libraries/utf8#graphemes Per WolfGang: * https://codeberg.org/nazrin/grapheme * https://libs.suckless.org/libgrapheme/ I'm currently working on a mesh-based text renderer that needs to be able to iterate over graphemes for emojis and stuff correctly for example. But there are many other usecases like being able to properly utf8 substring without messing up graphemes such as combining characters etc.

The present system of limiting script memory on a per script basis gives scripters an incentive to create often incredibly inefficient workarounds when they want/need more memory than the limit allows, such as creating a large number of slave scripts and passing data back and forth via ll.MessageLinked. Simply increasing the limit to something more reasonable could alleviate this somewhat, but it doesn't really address the underlying problem, how to responsibly allocate memory per creation, whether that creation is a single prim, or a collection of linksets. I therefore propose the following alternative: Give each linkset a parameter adjustable by anyone with modify rights, Call it Linkset Memory Limit (LML). Default to a reasonable value, say 1 MB. Add this parameter to the collection of items that affect the linkset's LI, at a reasonable cost, say, 1 LI/MB. (I don't know if it's actually reasonable, but 1 LI/MB does make a mentally convenient conversion factor.) Per current practice let, the final LI be the max of the per item LIs. Then each script in the linkset draws memory from the common memory pool as defined by the LML. The simplest implementation of this feature at the script level would probably be to change ll.SetMemoryLimit to be limited to the currently available memory in the LML pool, with an argument of -1 meaning grab it all. This would allow the script to reserve needed memory and to free it when no longer needed. Adding ll.GetLML, llGetFreeLM, and possibly ll.SetLML (see discussion below), together with existing parcel prim count functions would constitute a sufficient set of functions. It might be possible to automate dynamically allocating memory to scripts from the common pool as needed, but I'm not prepared to say how desirable this might be. It would likely improve the use of the common memory pool, but it could greatly complicate impact and debugging of out-of-memory conditions and I'm not sure how it would work with attempts by a script to reserve needed memory in advance. This new feature would give scripting creators the ability to make efficient use of as much memory as they might need, with a clearly visible cost that prospective object owners can see and can budget against their available resources. It also give owners with linkset modify rights the ability to adjust this cost within the limits of the scripts' ability to adapt. It entirely eliminates the creator's incentive to use inefficient workarounds that are costly to sim resources and performance. It gives creators a reasonable incentive to limit their use of memory in order to improve the market appeal of their products and/or the land impact of creations they use themselves. It doesn't particularly affect the case for using HTML and external servers for very large or shared datasets when HTML delays are acceptable. Since the LI of worn objects is not currently counted against any budget, in order to keep worn object impact under control, it would be necessary to have a per agent LI limit as well. This limit would probably apply only to the LML LI, but grins one might possibly make the case for applying it to other LIs as well (no doubt with much cussing by our more elaborately decked out friends). A higher agent LML LI limit could become another perk of higher account levels. Since dividing and merging of linksets usually occurs at creation time, and we want creators to manage this process, I would not recommend elaborate algorithms for managing the allocation of LML on merge or divide. It probably suffices on merge to keep the LML of the root of the merged object. On division, it probably suffices to give objects with a new root the default LML. Allowing a script to change the LML of an object would mean that the script could be dynamically changing the LI of the object. This would have both pros and cons. Pros such as allowing a single script to adapt the object to present limits or to set the LML of a newly divided/merged/created object to reasonable values. Cons such as removing from the owner complete control over the LI of their rezzed out objects, and making marketplace data about LI less reliable. Perhaps a reasonable compromise would be to limit such functions to objects owned by the parcel owner per other parcel functions. The prospect and limitations of any ll.SetLML function definitely needs more discussion. It would be nice if this feature also applied to LSL scripts either when compiled to Mono and to the Lua VM, or possibly just when compiled to the Lua VM. If automatically applied to existing content, it would probably break a significant number of existing inefficient workarounds and other instances where the number of 64kb scripts in the object exceeds 16. (Beware of furniture with nPose and AvSitter systems and many seats.)

Currently to get the magnitude of a vector v we might code local v = vector(1,2,3) local m = vector.magnitude(v) One might reasonably expect local m = v:magnitde() to work, and similarly for other functions that might reasonably act like methods such as local dp = v1:dot(v2) and so on. It does not work because a vector instance's metatable is not set to the functions in vector . Seems to me that it should be, so that vectors can be treated like any other SLua object or smart table. I was somewhat surprised to find that vector is implemented as a native type rather than as an ordinary Lua table / object, with the functions in its metatable and so on. I would suppose that this might be because Luau already did it this way, or because of some performance concern. Curious. In any case, since, in my view, any competent Lua / SLua scripter is going to use objects and the : notation, vectors (and quaternions and any other built-in structured types) would be far better if they worked like objects with metatables. Thank you for your consideration and I'll be happy to assist with testing or Lua code if it would be useful.

Constants It might be good to have constants for the event names LLEvents:on(EVENT_TOUCH_START, handler) or LLEvents:on(TOUCH_START_EVENT, handler) Though the latter does break the general convention LSL has of prefixing constants, so may be less desirable. Aliases While at that, as mentioned here some aliases would be nice, to allow for nicer code read, constants could be used or true aliases could be provided, but that may not be worth it. LLEvents:on("on_rez", handler) -- to LLEvents:on("rez", handler) -- or LLEvents:on(EVENT_REZ, handler)

Currently there are surely a lot of little parity problems. These are just some that I've noticed so far- local a = {1, 2, 3, 4} local b = {1, 2, nil, 4} local c = {1, 2, d = 3, 4} ll.OwnerSay(`a {#a} `) ll.OwnerSay(`b {#b} `) ll.OwnerSay(`c {#c} `) A and B will return 4, but C will return 3. Getting the length of a table with dictionary elements requires looping thru the entire table with pairs() each time, requiring a cludgy metamethod to have it work how one would 'expect', when just a table.len() would be useful. local Tbl = {} Tbl.__index = Tbl Tbl.__len = function(len) local incr = 0 for _ in pairs(len) do incr = incr + 1 end return incr end Likewise, list concatenation is a major thing in SL, allowing one to build up lists for llSetLinkPrimitiveParams for instance to save on function calls. This is entirely impossible in Lua with merging even two tables requiring your own function, or another cludge, to say nothing of matching the functionality of SL where multiple lists can be strung together easily- Table. __concat = function(a, b) if type(b) == "table" then for _, v in ipairs(b) do a[#a+1]=v end else a[#a+1]=b end return a end } As these are probably minor, basic functions that would get a lot of use, I feel like small things like this should start being added to the language, to prevent them from needing to be created in every script itself. The performance would also be higher if implemented in C on top of that. Lua is advertised as being an extremely tiny language, but that can be a little detrimental when we have to make even basic helper functions ourselves in our limited 64kb memory.

While I suspect allot of this is "to come" with the improved debugging features that have been "implied/promised" It would also be nice for scripts to be able to access some meta information about themselves. This in part came up during discussion of the new event system ( RFC ) on possible issues with os.clock() and ll.GetTIme() So I proposed a table with functions and or values for getting info about the script itself e.g type llscriptmeta = { compile : { time: number, -- Unix timestamp of script compile by: uuid, -- Who saved the script with: string -- Some version string of the compiler }, startTime: number, -- Unix Timestamp of script start (resets with ll.ResetScript) getUpTime: () -> number. -- Like ll.GetTime but with no luau caveats(resets with ll.ResetScript) bytecodeSize: number, --- Size of the bytecode in bytes ... }

You're already working on a major overhaul with Lua. NOW is the right time. It will NEVER, EVER be easier than RIGHT NOW. You will NEVER be able to reduce future capex on inefficient scripting overhead more easily than RIGHT NOW. Link messages: Good for broadcasting messages between scripts where it doesn't matter much if it takes a few milliseconds to arrive, and you don't mind scripting some asynchronous handler to respond if necessary. Doesn't do a good job at supporting proper organization of software in accordance with modern standards any developer expects. OK for the the Single Responsibility Principle and to some extent the Interface Segregation Principle. Does absolutely nothing to help with unit or integration tests. No serious programmer is looking at this and saying, "yes, this is good and cool." Direct, synchronous calls to public interfaces between objects: Java, TypeScript, C#, Lua (not mentioning this by accident), Python, and any other serious programming language you can mention, supports this natively. This was introduced in Simula 67 in 1967, and has been INDUSTRY-SANDARD ever since, because it's awesome and it rules. We get to call public methods on other objects (scripts) synchronously, just as fast, or nearly so, as we would call a function in the same script. You DON'T have to engineer a massive comprehensive interface mechanism between scripts, or build an include mechanism. You add ONE transmitting function to the LL library, back-end routing between Luau states in the back-end, and an in-script state handler which receives and responds to these messages. That's it! We don't have to engineer extremely hacky workarounds that force an asynchronous mechanism to serve for what would be VASTLY improved if it was synchronous. We get to write unit and integration tests without cramming them into the same file as production code, where they take up valuable RAM. We feel like we're using a real programming language, one which allows us to use the same patterns and techniques as ANY serious programming language from the last 58 years. Real Example (my aircraft physics system): A Weight & Balance script scans the linkset to determine where all the components are, their volumes and orientations. These are mapped to inertia proxies (cuboid, flat plate, thin hoop, etc) and used to calculate the inertia tensor. The airfoil prims are then split into segments (blade element theory) and have control surface information assigned. Linear force physics script has to obtain a full copy of all the airfoil parameters and segments from W&B. Moments (angular force) physics script has to do the same thing, and spend the same memory. Now the object has three independent copies of the same data. There are a ton of copy-pasted functions between these scripts because there is no #include method. This requires more storage for the script source, compiled bytecode, stack and heap segments as well. Not just for airfoil parameters, but for MANY, MANY other things that Linear and Moments both have to know about. If Linear and Moments both run timers, then LL pays for CPU for that. They are only in separate scripts to work around RAM limitations! If they could call a shared lib script in near-real-time, they could be in ONE script with ONE timer. LL is paying for all that overhead. I am losing huge amounts of time dealing with it. Everybody loses, and it sucks. Every other day I'm fighting stack-heap collisions, and wishing I had some way to effectively write unit tests. The constant discouragement is dragging me down unnecessarily. With direct inter-script calls: llInvoke(link, scriptKey, "method", args...) -> Luau back-end routes call from one Lua state (script) to the other, then returns whatever needs to be returned. (Just an example.) You can make this only work in the link set, or make it work sim-wide. (Sim-wide would enable a lot of cool stuff that relies on llRegionSay() now.) Transmitting script blocks until response received. If access control is desired on the receiving end, you can add a pin to the invoke message (a la the existing "remote load script PIN"), or whatever. In my project, Linear and Moments can just ask W&B for airfoil data in near-real time, and get an answer back in microseconds. Functions for calculating rho, tangential velocity, dozens of aeronautical equations, etc. can be in a standard library. Scripts can call that library, again, getting answers back in microseconds, instead of all that copy-pasted code gobbling up space on YOUR servers. You don't have to provide an #include mechanism, further conserving space. I can write UNIT AND INTEGRATION TESTS!!! and stop relying on horrid llOwnerSay() spam for everything. I can stop feeling so EXHAUSTED while trying to do serious innovation in SL. More efficient scripts from now on -> reduced capex for LL. LL wins, SL developers win, users win, EVERYBODY WINS. What's not to like?