lljson.sldecode can produce uncompressed uuids
complete
Tapple Gao
lljson has inconsistent behavior. I think these should all produce an error:
print(pcall(lljson.sldecode, '"!vOops"'))
print(pcall(lljson.sldecode, '"!qOops"'))
print(pcall(lljson.sldecode, '"!uOops"'))
The first 2 produce an error:
malformed tagged vector: !vOops
malformed tagged quaternion: !qOops
But the last one produces an uncompressed uuid:
local _, u = pcall(lljson.sldecode, '"!uOops"')
print(u, typeof(u), u.bytes) -- Oops uuid nil
This uuid cannot be re-encoded:
print(pcall(lljson.slencode, u))
invalid UUID format for JSON encoding
Instead,
sldecode
should produce an error:malformed tagged uuid: !uOops
And uncompressed uuid's should be removed from slua, it's documentation, and typechecker: https://github.com/secondlife/lsl-definitions/blob/23d46484888c1908545dc92db119613bb553af11/slua_definitions.yaml#L70
- name: bytes
comment: Returns the raw 16-byte binary string of the UUID, or nil if the UUID
is not in a compressed state
type: string?
Log In
H
Harold Linden
marked this post as
complete
This particular flavor of "uncompressed UUIDs" should be fixed on the beta grid now, thanks!
H
Harold Linden
marked this post as
in progress
Have a fix for this in dev, should go out with the next simulator roll https://github.com/secondlife/slua/commit/205972cb92cbb34c5f869ee98f27c8176779ee10
Tapple Gao
Harold Linden any comment on ll.List2Key? or should I file a new issue about that? I fixed the typechecker issues related to this issue: https://github.com/secondlife/lsl-definitions/pull/65
H
Harold Linden
Tapple Gao If you'd like, though I'll probably just fix it today anyway. Running down my backlog now that I'm out of the yieldability quagmire :)
H
Harold Linden
That one should be dealt with too https://github.com/secondlife/slua/commit/5dde8334d609e2f8e26c0ab7d398ec4ce1adcd10
Tapple Gao
Harold Linden I can't test this without a sim, but, in lsl mono, this prints "hello":
default { state_entry() {
llOwnerSay(llList2Key(["hello"], 0)); // "hello"
}}
It looks from reading your code that you changed it to print ""
H
Harold Linden
marked this post as
planned
Thanks! Yeah, this is left over from when before we took out all paths in SLua proper that could legitimately create non-normative UUIDs (
link_message
events, basically, since id
is now a string
).Tapple Gao
Another way to get an uncompressed uuid in slua:
local u = ll.List2Key({"Oops"}, 1)
print(u, typeof(u), u.bytes) -- Oops uuid nil
print(lljson.slencode(u)) -- invalid UUID
I'd be ok with deprecating or removing this function outside llcompat
Tapple Gao
If uncompressed uuid's need to be kept around for the lsl vm, I'd still prefer they were removed from documentation/typechecker, and consider it a bug if they ever get exposed in slua
WolfGang Senizen
Personally I'd prefer matching the casting behavior of the same as
tovector
touuid
toquaternion
functions, instead of an error for any of them.Vaguely along the principle of being forgiving with what input you accept but accurate with what you output produce.
Tapple Gao
I prefer fail early for lljson.sldecode rather than finding an unexpected nil in one of my arrays later. It already needs wrapping in pcall for other reasons
H
Harold Linden
WolfGang Senizen
> Vaguely along the principle of being forgiving with what input you accept but accurate with what you output produce.
Having dealt with a number of lower-level RFCs and their implementations, Postel's Law is something we're still desperately trying to recover from