Generate Selene Yaml#43
Conversation
|
This commit needs clarifying by linden labs, 2e48833 The pure status of some of these methods is unknown and down to implementation, so no way for external users to know. |
| - name: difftime | ||
| comment: Returns the difference in seconds between two timestamps. | ||
| deprecated: true | ||
| comment: Returns the difference in seconds between two timestamps. Same as a - b. |
There was a problem hiding this comment.
I marked os.difftime as deprecated because of the documentation at https://luau.org/library/#os-library:
Calculates the difference in seconds between a and b; provided for compatibility only. Please use a - b instead.
| - name: decode | ||
| comment: Decodes a base64 string to a string, or buffer if asBuffer is true | ||
| comment: Decodes a base64 string to a string, or buffer if asBuffer is true. | ||
| Returns an empty string/buffer if input is invalid. |
There was a problem hiding this comment.
It truncates at first error:
print(#llbase64.decode("AAAAAAAAAA&AAAAAAA")) == 7
| def dump_syntax(definitions: LSLDefinitions, pretty: bool = False) -> bytes: | ||
| """Write a syntax file for use by viewers""" | ||
| # TODO: add comment about auto-generation time/version like gen_luau_lsp_defs does. | ||
| # Requires modifying python-llsd to not add the XML declaration at the start. |
There was a problem hiding this comment.
It's totally okay to just do format_xml(something).split(b'\n', 1) or something like that, that declaration is always going to be there on its own line for any successful output.
There was a problem hiding this comment.
|
May need some merging with |
HaroldCindy
left a comment
HaroldCindy
left a comment
There was a problem hiding this comment.
Generally looks good to me, thanks for sending this in! Just a couple questions, and needs merged.
| ll_module = [m for m in slua_definitions.modules if m.name == "ll"][0] | ||
| header_comment = b"""<!-- SLua (Server Lua) keywonds file for Second Life Viewer. | ||
| This file is auto-generated by https://github.com/secondlife/lsl-definitions. | ||
| Version: TODO: auto-generate |
There was a problem hiding this comment.
It's possible to do, but it's some arcane git describe incantation that figure out the current tag or current commit relative to an ancestor tag. Your call on whether you want to do that now or I can do it later, I don't feel strongly about it.
There was a problem hiding this comment.
the sim capabality already gives them a uuid. I thought it would be that or something like it. Just using Last Updated instead and not bothering making up a version schema is fine too.
There was a problem hiding this comment.
I'll leave it to you
There was a problem hiding this comment.
Hmm, maybe just put the current lsl-definitions commit SHA, which you can get from git rev-parse HEAD? Having a git SHA is probably more useful than having a version anyway.
There was a problem hiding this comment.
Or hmmm. That would be tricky since it would only work if you ran the commands within the repo. Maybe just time at generation is fine then. It's mostly going to be used to visually determine if previously generated data is "old".
| self.definitions.controls.update(def_dict["controls"]) | ||
| self.global_scope.update(self.definitions.controls.keys()) | ||
| # nil, true, false are also valid type literals | ||
| self.type_names.update(const["name"] for const in def_dict["builtinConstants"]) |
There was a problem hiding this comment.
This seems a little strange to me, what is this for? Is this meant to include all valid literals? Are bool literals and say, number literals treated differently in type expressions?
There was a problem hiding this comment.
are number literals valid in type expressions? my quick and dirty type validator (just tries to make sure types are defined elsewhere in the yaml file) wouldn't work with those right now:
It makes sure every part of a type expression is either:
- previously defined in the file (
type_names), or - matches a regex that matches the various operators that aren't types. This regex knows about string literals, but not bool literals or number literals.
It's mostly an aid to make sure I actually listed all the valid types within slua_definitions.yaml. I could have added bool literals to the regex, but I added them to known_types instead since they are in the file (keywords_lua.xml needs them). Number literals aren't known to the regex because I didn't think about them until now, and haven't used any. A lot of the lsl functions could be typed with number literals, actually
There was a problem hiding this comment.
It would probably make more sense to use a custom type function to type a lot of the lsl functions that take number arguments, like:
GetListEntryType: (src: list, index: number) -> range<0, 6>,
GetSimStats: (stat_type: range<0, 26>) -> number,
the syntax is probably wrong as I haven't yet played with type functions, and they might require --fflag LuauSolverV2=true, still in beta
There was a problem hiding this comment.
or, even better, auto-generate a bunch of type aliases by adding a family or group field to LSL constants that are part of a set
There was a problem hiding this comment.
Okay, I think putting that in self.type_names is fine for now then.
RE: grouping / enum concerns, there's a couple open issues about it, we'll need to come up with a spec to define certain constants in terms of enums and flags.
HaroldCindy
left a comment
HaroldCindy
left a comment
There was a problem hiding this comment.
Looks good to me, thanks! I'll handle the generated timestamp comment stuff.
3 participants
slua_default.d.luaufile #42Add a command to generate a selene yaml file for SLua:
See the generated file and (the diff against vscode plugin)
Part of a set:
slua_default.d.luaufile #42