Adding OSSL opensim functions
Closed this issue · 7 comments
Any change to add opensim functions, variables and consts?
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...
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
I used -b lsl.keywords in my project
https://github.com/parmaja/miniedit/blob/master/bin/lsl.keywords
- 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...
@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...