You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have a single proposal to set JS runtime options, and all options must be provided. I think it would be simpler if this took a partial object, and only updated the fields it was provided. On the C++ side, this would mean setting default values at struct construction time, so that we have sane defaults whether-or-not there is a governance-controlled value in the KV.
Motivation is from adding another option here (max_cached_interpreters), and realising how much code is involved in configuring that, even to restore it to a default.
The text was updated successfully, but these errors were encountered:
For the current use case, we may just set it in a separate proposal. Not written above but I meant to:
There's also some duplication of default values. I think that could be minimised by pushing stuff through C++, materialising default values, and similar. It's all in my head, and unimportant, and I'm sure I won't forget it...
+1 for materialising default values in the KV, which I think can be done as a standalone change before adding a patch mechanism to governance (which may be of interest to applications too, in fact).
We currently have a single proposal to set JS runtime options, and all options must be provided. I think it would be simpler if this took a partial object, and only updated the fields it was provided. On the C++ side, this would mean setting default values at struct construction time, so that we have sane defaults whether-or-not there is a governance-controlled value in the KV.
Motivation is from adding another option here (
max_cached_interpreters
), and realising how much code is involved in configuring that, even to restore it to a default.The text was updated successfully, but these errors were encountered: