sl-service-account
commented
1 year ago JIRAUSER341305 commented at 2023-08-07T09:12:16Z, updated at 2023-08-09T08:43:43Z
You seem to be talking about several different things… This also happens to be a topic quite near and dear to me, so let me apologise in advance for the long rambling post.
Firstly, though, I don't think I want an official LL editor. LL are not editor writers, they will never be able to write an editor better than many of the existing ones (short of pivoting their entire business and giving up SL, which kind of defeats the point). I really miss VS Codes multi-cursor editing, for example, but VS Code was built with Eclipse as it's foundation, and the express intention of addressing many of Eclipses mistakes and limitations. LL built a simple editor to provide in-world text editing, and I would rather LL didn't pivot out of the SL business, just to built a top-class editor for SL — that seems a little counter-productive.
With that in mind…
1) For adding LSL support to external editors, an official list of the functions, events, and constants, with concise descriptions, on a well known location on LL's web site, would be a really good start. This is already a thing to a degree — a list exists that I think was started by Sei Lisa (and co-maintained with someone else, or something?) — and being used by several extensions already to provide syntax highlighting, tooltips, and the likes. The other part of such extensions, is parsing, that too is sufficiently covered by existing parse files — that's why there's several of them about at any given time, for most of the major editors, and that should continue to be a thing (they could avoid falling behind due to not being maintained, by downloading and caching the list rather than requiring an update to the extension). Though LL putting out an official list would still be beneficial — I, and I suspect plenty other people, are rightfully dubious about relying on someone else's unofficial list. Though Sei's has become popular enough (especially if I correctly remember about it being co-maintained), that it probably won't just up and die one day (hopefully) even if it's creator moves on. Still, I did one time observe Sei being informed there were new functions… So an officially maintained (and presumably at least semi-automatically generated) one would be both more prompt and up-to-date — and LL themselves could readily maintain a "general availability" version, as well as limited availability versions by simulator version (for the new functions not yet fully deployed).
Where there begins to be a problem however, is in providing the next step; linting, and the BIG bugbear, interactive debugging… (With very little movement of the language itself, linting at least has remained a pretty stable target, and hasn't needed much in the way of maintenance.) Interactive debugging however is a MAJOR project just to build initially, but then additional significant ongoing effort to maintain and keep up to date — and that is why the handful of LSL debugging editors get kept up to date for a while, but then inevitably just stop at some point. Also unlike viewers which get to copy huge slabs of code wholesale from the official viewer (or at least, get to read the official viewers implementation as a reference), and similar for the simple parsing required for syntax highlighting in non-debugging extensions, IDE debuggers by comparison have to do it all themselves, with very little help (and in fact, some measure of hindrance) from LL.
2) Project management. This is a small step back, but was brought up in a recent SL meeting… It'd be nice to have a function of the viewer (or even a separate "official development bot") that takes a project folder, and syncs it up into the SL world. Could extend to not just scripts, but mesh, textures, sounds, notecards, etc., with a sub-folder per object, and a sub-sub-folder per prim, with configuration to build that prim, and all the items to be put into it's inventory, and then watch it all for changes, and keep it all synced into the world (along with an export function going the other way). As a viewer feature, could utilise local textures and mesh to let you interact with it, while avoiding having to upload every single little minute change, and then taking care of all the L$ stuff when you decide it's time to do a bulk upload for actual live testing and/or distribution. This could also be seen as just be "the next step" version of it's existing "open script in external editor", by maintaining a more static link — you tell it where to put the local file(s), and give it an actually useful name, and then the viewer remembers that link and automatically syncs it whenever you're on the sim with that object (or asks if you want to resume syncing when it notices a difference).
3) In-World debugging. This gets very tricky, not the least of which being there's a bunch of time limits and stuff that mess with live debugging, and the question of what to do with the clock — anyone who's ever tried debugging a running game knows how this goes. Though being able to receive a dump of the scripts current variable space and execution point after each timeslice would itself be a huge benefit (even if, say, the sim were to steal its next timeslice to do so). There's a bunch of ugly issues here, and weaknesses with this approach — we obviously can't just stop the entire sim while you single-step through your script. Additionally, the time you spend single-stepping through your code, means it's probably not going to hit any of those nasty throttles LL like to shove in all over the place. That said, it also shouldn't be tooo hard for LL to add support for attaching an external editor to a running script, and this is really the only debugging option for actually complete live and up-to-date debugging. Basically, LL adding to the script engine the ability to set and watch breakpoints, provide stepping, and then export that through a reasonably standard interface, such as the Debugger Adaptor Protocol (what IMHO most decent IDE's around support some degree of). But doing it in a way that didn't negatively impact every other script on the sim, is a different matter. Could potentially be done through bytecode instrumentation at save time (probably a special edit mode, rather than just a flag you can forget to turn off), at the cost of a notable performance hit against the script, without much actual impact on the rest of the simulator.
4) Off-world debugging. There's been a couple, I'm using one right now, there was one for Eclipse. But as I said above, these are MAJOR projects in their own right, and come with major ongoing work to keep then up to date, and hence why every single one of them eventually dies. LL providing and maintaining a debug core themselves, would most certainly resolve that, so long as they can split their script engine into publically accessible and secret-sauce sections. If they can do that, it shouldn't be too hard for them to wrap it in a DAP-compatible module, and leave it to other people to bind to individual IDE's. In this situation, similar to what I said about the commands list at the top, even if those extensions fall into being unmaintained, as long as they automatically update the DAP module from it's official source (similar to what I said about the functions list up above), they'll mostly keep running and up to date just fine for quite a long time. Anyone else trying to do this, however, is the situation that we have right now with a bunch of outdated and unmaintained ones, because it seriously IS a heck of a lot of work to make and maintain one of those!!! Work that LL has already done in building the simulators to begin with. (And especially trying to follow the bits and pieces LL intentionally don't tell us, and/or are just vague on themselves, etc.)
Off-World debugging will also by necessity, never be "complete" — unless you're actually running a simulator or two on your home computer (therefore actually making it "in-world debugging on your own local testing grid"). The one I use (and I'm pretty sure the Eclipse one before it), make no effort to do physics, ignores a bunch of those things LL like to be vague about, stuff like external HTTP and especially email are problematic, and they usually have their "world" specified in some kind of configuration file (which itself tends to be big, unweildly, and hard to get your head around).
Where this method really shines, though, is it CAN stop the world while you single-step your code, and other very handy things like the one I'm using does external HTTP through a special trap event that lets you modify the outbound request, and/or just reflect back a canned response. These are features you just could never get with an in-world live debugger — for the same reason MMO's don't give you a pause option. Also, since it has all the expression evaluation stuff for simulation, the extension I'm using allows me to preview expression results during editing. It also lets me perform scripted testing (perform this touch at time X, send this chat message at time Y, etc.), unit testing, and I've even managed to do a little TDD style development with it (can't yet validate whether an event was generated or not), which is way nice. It's currently allowing me to simulate and debug a little 3-object project (each intended to be on a different sim), two scripts per object, communicating by chat, email, and http. (And it's still only super-early-pre-alpha level incompleteness and general jankiness).
To give you some idea of the complexity of off-world debugging, it only presently supports some 90-ish LSL functions, and those already take up one third of the overall extension code, beside the half that is the script parsing, linting, and simulation core itself, with the last little bit being the glue extension stuff (the part that would be needed to make an extension wrapper for an official DAP module, to bind to an in-world debugger using the same protocol). I dread to think how it'll look with more compete linting and optimisation piled in as well (being able to evaluate a function call and drop the result directly into the script at "compile" time, is a very nice side effect of having the simulation stuff in there).
Which is all to say, both debugging cases have distinct uses, and address points the other can't hope to achieve. However unless LL provide the core debugger from their own source (they already have almost all of it already, after all), I'm afraid that will always be stuck in the realms of short-lived enjoy it while it lasts — in-world debugging capability would probably be the only one that actually has a decent life expectancy. (Something hacked together out of OpenGrid not withstanding — it could, theoretically, be adapted to be pausable for single-stepping).
(Yes, substantially re-written {}again{}, because I really didn't like how I'd written a lot of that. Still don't, and it's still too long, but, such is life.)
How would you like the feature to work?
Have an RL version of the LSL editor. I know that there are many third party editors that one could install. However, these then require additional third party plugins to work. They are not updated either to work with the latest LSL updates. I would like to see Linden Labs create their own RL LSL editor for one to install and work with scripts. This could be something that one "could" log in or run without logging in (if using more than one avatar). They could then save their scripts to their computer until ready to bring in-world. A nice addon to this would be able to test it out in a virtual sandbox. Similar to the "Unreal Engine" or something similar to that.
Why is this feature important to you? How would it benefit the community?
Sometimes one might have an idea for a script but no way to test it out. This would give them that ability. For instance, they are somewhere where there is no wifi. Or maybe they are on a laptop that cannot handle the SL load but no access to a viewer. This way they could put down their ideas in form of a script and later implement it.
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-234227 | | Summary | LSL Editor Linden Style | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Created at | 2023-08-06T18:16:36Z | | Updated at | 2023-08-16T18:40:28Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-08-07T04:12:15.771-0500', 'How would you like the feature to work?': 'Have an RL version of the LSL editor. I know that there are many third party editors that one could install. However, these then require additional third party plugins to work. They are not updated either to work with the latest LSL updates. I would like to see Linden Labs create their own RL LSL editor for one to install and work with scripts. This could be something that one "could" log in or run without logging in (if using more than one avatar). They could then save their scripts to their computer until ready to bring in-world. A nice addon to this would be able to test it out in a virtual sandbox. Similar to the "Unreal Engine" or something similar to that.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'Sometimes one might have an idea for a script but no way to test it out. This would give them that ability. For instance, they are somewhere where there is no wifi. Or maybe they are on a laptop that cannot handle the SL load but no access to a viewer. This way they could put down their ideas in form of a script and later implement it.', } ```