Closed codefromthecrypt closed 11 months ago
/hold
In theory, yes, we have no idea how people design their plugins. Although after normalizing, they will be in the range of [0, 100]
ok I will put the note in that normalizing means [0, 100] so basically regardless of number above 100 it normalizes to 100.
So, next steps for me are:
Will push a commit to include this!
ok spent another hour plus on docs. I think that's way over budget for me and unparalleled in practice.
Next is test.
ok addressed all the TODO I'm aware of, PTAL!
once last feedback is in, I will squash so that the commit history isn't junked up
thanks for the looks folks!
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: anuraaga, codefromthecrypt, kerthcet, sanposhiho
The full list of commands accepted by this bot can be found here.
The pull request process is described here
What type of PR is this?
/kind feature
What this PR does / why we need it:
This implements ScorePlugin. Notably, this reduces the size of the score returnable by wasm to int32 from int64 for reasons elaborated in the RATIONALE.md.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Thanks a lot to @anuraaga and @ncruces for helping with the wasm aspects of the rationale.
Thanks a lot to @kerthcet and @sanposhiho for helping with the value space aspects of the score plugin.
Does this PR introduce a user-facing change?
Only notable behavior is reducing the value range of score produced by wasm plugins to max int32.
What are the benchmark results of this change?