Adding OSSL opensim functions

Question

Adding OSSL opensim functions

Closed this issue a year ago · 7 comments

Any change to add opensim functions, variables and consts?

http://opensimulator.org/wiki/Category:OSSL_Functions

Answer 1 · 2022-04-05T17:11:22.000Z

I'm not an 'expert' using lslint, but it already provides a way to manually add extra functions/variables/constants/events for linting purposes.

When calling lslint --help there is an option:

-b <file>       Load builtin functions from file

From the source code, you can see that there is a supplied builtins file, named (you guessed it!) builtins.txt. In theory, if you (manually) add the OSSL functions/etc to this list, you'll be able to run lslint on OpenSim scripts.

I haven't done that :) but it seems simple enough :) (caveat: make sure the file doesn't have any comments in it, or lslint -b ... will complain)

If all else fails... download source code... change the builtins.txt by appending all OSSL functions you wish... recompile everything running make... and you should get a self-contained binary that lints OSSL functions as well.

Where do you get a full and updated list of all functions/constants/etc.? That's also easy: the same source as used by this project, namely, the KWDB project. It's been kept up to date with all known functions/consts/vars/events known to Humankind, across all platforms that are compatible with a SL Viewer. :) That project revolves around a meticulously maintained XML 'master' database with all information regarding LSL elements, and it supplies some tools to massage the data to export it to a few different formats (you can add your own plugins).

In particular, there is an export plugin to generate a fresh builtins.txt file that lslint can understand; all you need is to get the generator to spew out the extra elements for OpenSimulator (and, if you wish, you can add those from AuroraSim as well), and you're good to go!

It sounds simple when writing it down, but I haven't tested it myself. Not yet, at least...

Answer 2 · 2022-04-06T00:28:43.000Z

Yes, it should be possible to add an external builtins.txt file; if that isn't the case, please report it as a bug. lslint used to be up-to-date with current KWDB; now it seems to be lagging a bit behind, but note also that updates to LSL are very scarce nowadays, so it may be that it's not worth the trouble for the maintainers to perform an update. However, regarding the OP's request, I have to note the following: - Updates to the OSSL keywords are not being tracked by me, only LSL updates. Sadly, there's no one maintaining that part of KWDB at this moment, therefore it's not up to date with the latest additions to OSSL. Makopo was the last person who updated it, but it's been a while since the last time that happened. - OSSL has many unique quirks, bugs and lexical/syntactic/semantic deviations from LSL. Addressing the gotchas that may arise while using OSSL is a project in its own right. I'm not at all familiar with all these variations, as I only ran into a few of them while working on AVSitter for OpenSim, therefore I'm not in a position to develop a proper lint program for OSSL. - The syntactic differences will probably make OSSL need a different parser to that of LSL, because attempting to merge the parsers into one has a high chance of making the code unmaintainable. It's already marginally maintainable, due to all the LSL quirks and gotchas it needs to catch, error recovery, value tracking, etc. In short, the OSSL part of KWDB is not well maintained, but even if it were, there's more to it than just the keywords. I believe that an OSSL linter would need a different program written by someone with a deep knowledge of the script engine and the gotchas within. Just as an example, this used to be a gotcha, not sure if it already is: integer a=6; integer b=5; default { state_entry() { llOwnerSay(~a|b); llOwnerSay(b|~a); llOwnerSay(~a*b); llOwnerSay(b*~a); } } That used to return different results in SL and in OpenSim (maybe it still does, I haven't checked recently), due to a bug in the precedence of the ~ operator in OSSL, which is sometimes strong and sometimes weak depending on what follows it. A linter should catch that and warn the user to add parentheses around the operator, like this: llOwnerSay((~a)|b); - but such caveat does not apply to LSL. That's one I've run into; I don't remember more but I'm sure there are a bunch.

Answer 3 · 2022-09-02T17:59:16.000Z

Yes -b work fine with builtins.txt , All I need to remove first comment line, after I generate it the both sl/os by using kwdb (I used python3 that need to fix one line to work).

Thank you both

But I will keep this issue open

Answer 4 · 2023-05-21T14:06:12.000Z

I used -b lsl.keywords in my project
https://github.com/parmaja/miniedit/blob/master/bin/lsl.keywords

Answer 5 · 2023-05-22T17:41:02.000Z

The syntactic differences will probably make OSSL need a different parser to that of LSL, because attempting to merge the parsers into one has a high chance of making the code unmaintainable. It's already marginally maintainable, due to all the LSL quirks and gotchas it needs to catch, error recovery, value tracking, etc.

Hmm @Sei-Lisa all I can say is that I haven't noticed any 'quirks' so far — lslint works admirably well, even with OSSL :) Granted, I did not test those extreme edge cases you mention; on the other hand, OpenSim has more-or-less-recently received a brand-new scripting engine, courtesy of the unstoppable Ubit Umarov, and which provides outstanding performance & compatibility.

I'm sure there will be tricky exceptions, but for the time being, lslint catches all the bugs I introduce in my code :) which is exactly what I expect from such a tool...

Answer 6 · 2023-05-23T13:07:29.000Z

@GwynethLlewelyn if you write OSSL by restricting yourself to LSL-only syntax without using any OSSL-specific syntax, then of course you can use lslint (to some extent) to catch common mistakes, but there's always the danger of stepping on a mine where LSL and OSSL differ in a subtle detail that lslint does not catch, or to get an error from lslint which is not an error in OSSL.

Answer 7 · 2023-08-12T17:00:53.000Z

@Sei-Lisa Fair warning :-)

In other words: no, of course I won't blame lslint if it doesn't catch an error from OpenSimulator (I don't even complain if it doesn't catch errors from LSL, either!).

Reading back on this thread — I seriously doubt (and I'd welcome to be proven wrong!) — that such a person ("with profound knowledge of the OSSL scripting engine and its quirks") even exists. Perhaps not unlike LSL (who knows how LL maintains their code internally...), there have been so many people over so many years tinkering with the code that it's hardly to have a superficial knowledge of OSSL, much less a deep one. The best one can accomplish is to understand LSL as best as possible, and use as little of those OSSL functions as possible :)

The truth is that they have just limited usage, and it's also the kind of usage that you cannot 'backport' anyway. There is the whole issue about remotely controlled NPCs (= bots made easy), which of course is OSSL-specific and LL will never create an equivalent solution — much less embedded into LSL. These are truly OSSL-specific.

Then there are a few scattered ones that are, indeed, useful, and we have been asking them to be implemented in LSL for ages, but LL has no time for that. One (very obvious one) is writing to a Notecard. I suppose there is some mythological reason for LL's denying us that useful functionality, which would have easily avoided the many generations of "memory backup" systems, finally culminating in the KV Store (well, two of them — one for Experiences, one for anything else, and, of course, both are mutually incompatible — what else is to be expected from LL? 😛 ). Why the whole fuss? Are they afraid of people getting automatically spammed by notecard-generating scripts? I'm pretty sure that they could implement some limits on that, very easily so; also, such notecards are always written to an object's inventory, not to an avatar's inventory, so the worst that can happen is the object to blow up with too many notecards...

Last but not least, OSSL includes certain "shortcuts" for things that made sense 20 years ago with slow servers, such as the many database requests for all sorts of things; and then, parallel to that, you have far better (modern) functions that sidestep the database requests entirely but weirdly give exactly the same result — instantly, without additional code, and a simple function call. Going back to the notecards again... why, oh why, do we have to retrieve one line at the time from the asset server? Whoever came up with that stupid decision should be sent to the Cornfield with a legless avatar for punishment. Even if it made sense (why?) eons ago, nowadays it doesn't, period. A notecard is surely stored in a way that it can be retrieved with a single call (anything else would be a maintenance nightmare), since that's what you get anyway when requesting a notecard from the asset server (via the LL comms protocol). And in 99% of the time, people will read in a notecard into memory and perform whatever operations there — the only purpose of a 'line by line' approach would be to read a line and send it to chat (also a line at the time), and even that is not so efficient as simply pre-loading the notecard and then sending it to chat from memory.

My point is that there are some nifty functions (not many!) that avoid all that mess and give us much more reasonable alternatives instead. But do OSSL scripters actually use them?... well, some will, for sure, namely, those that came up wth their original implementation :) For the rest of us, however, these are just syntactic sugar — much better to work with but next-to-impossible to port back to LSL if the need arises...