-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MlContext improvements #310
Conversation
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
…ate the createContext() steps. Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
@anssiko @huningxin @wchao1115 PTAL - thanks. After review, commits can be squashed into one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! One suggestion.
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
… 'create context' steps Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
523e793
to
5961fd8
Compare
Note: for some reason the last commit (createContextSync) didn't appear in the PR, even though it was present on my branch. github didn't find that commit when clicking on its link, giving a 404 - so something went wrong. |
I'm sorry @zolkis what problem we're trying to address here? The issue #308 doesn't have any detail on it. I also forgot about the agreement around |
The sync version of create context method was there since it was introduced by #149 before. Later #274 introduced the async create context method and the sync version was restricted to be exposed to dedicated worker. According to the TAG's feedback, the sync version was appended with the "Sync" postfix as |
Thank you for taking a look (looks like I can only mention people in PRs, and could not assign reviewers myself). These are still just editorial changes, since the steps leave the details to implementations completely. To be checked later if that needs improvement - until then, this is just a formal placeholder, marking the places implementations should do a check. |
Accidentally removed @huningxin from reviewers, but can't add back. |
Ping me here when you've addressed the review comments and I'll add the reviewers back. |
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. This editorial change looks good to me. Thanks for all the iteration to establish the conventions :-)
@huningxin @wchao1115 this editorial update is now ready for your review. You may find the visual PR Preview and Diff helpful: |
…tion section. Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
Thank you for the review/comments, they have been addressed, and it's better. :) |
index.bs
Outdated
### Permissions Policy Integration ### {#permissions-policy-integration} | ||
|
||
This specification defines a <a>policy-controlled feature</a> identified by the | ||
string "<code><dfn data-lt="webnn-feature">webnn</dfn></code>". | ||
Its <a>default allowlist</a> is <code>'self'</code>. | ||
|
||
### The {{ML/createContext()}} method ### {#api-ml-createcontext} | ||
The {{ML/createContext()}} method steps are: | ||
1. If [=this=]'s [=relevant global object=]'s [=associated Document=] is not [=allowed to use=] the [=webnn-feature|webnn=] feature, return [=a new promise=] [=rejected=] with a "{{SecurityError}}" and abort these steps. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another convention round.
SecurityError is a DOMException by definition.
So, using the linked form
{{SecurityError}}
without the quotes and without DOMException it would unambiguously refer to a "SecurityError" DOMException :)
However, even if not the shortest, we should stick to the Web IDL convention:
Simple exceptions can be created by providing their error name. A DOMException can be created by providing its error name followed by DOMException. Exceptions can also be thrown, by providing the same details required to create one.
These rules are not used uniformly throughout the spec.
The question is whether to fix that in this PR, or should it be a separate one, plus document the reasoning in an issue that links this discussion?
index.bs
Outdated
1. Set |context|.{{[[contextType]]}} to "[=default-context|default=]". | ||
1. If |options|["{{deviceType}}"] [=map/exists=], then set |context|.{{[[deviceType]]}} to |options|["{{deviceType}}"]. Otherwise, set |context|.{{[[deviceType]]}} to "[=device-type-cpu|cpu=]". | ||
1. If |options|["{{powerPreference}}"] [=map/exists=], then set |context|.{{[[powerPreference]]}} to |options|["{{powerPreference}}"]. Otherwise, set |context|.{{[[powerPreference]]}} to "[=power-preference-default|default=]". | ||
1. If the <a>validate MLContext</a> steps given |context| return `false`, [=reject=] |promise| with a {{NotSupportedError}} and abort these steps. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
index.bs
Outdated
1. If [=this=]'s [=relevant global object=]'s [=associated Document=] is not [=allowed to use=] the [=webnn-feature|webnn=] feature, throw a {{SecurityError}} and abort these steps. | ||
1. Let |options| be the first argument. | ||
1. Let |context| be the result of running the <a>create context</a> steps given |options|. | ||
1. If the <a>validate MLContext</a> steps given |context| return `false`, throw a {{NotSupportedError}} and abort these steps. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zolkis we want to add the missing |
I created #314 to document the rule, but I can fix it in this PR as it's quite short, and overlaps with this PR. In the end, the separate commits should be visible, i.e. the commit fixing the issue should not be squashed. |
The change is done, should I commit it here, or stash it and use it in another PR after this one is merged (as it is for now)? |
I suggest commit changes to the lines touched by this PR and leave the full spec error conventions update for another PR. |
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
Ah, the most complex way. It's too late to do that cleanly, I will have a merge commit on the new PR. But it's done now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're almost done here :-) My proposal is to fix the error usage in createContext()
and createContextSync()
in this PR so we can land this.
It looks like other review feedback has been addressed, so I'll try to commit the remaining fixes to this branch and merge this PR so we can save precious Editors' review time for the upcoming PRs.
Thanks for your review @huningxin @wchao1115 and @zolkis for crafting this PR!
'Always favor the "SyntaxError" DOMException notation over just using SyntaxError to refer to the DOMException.' This notation applies to the following error names: https://webidl.spec.whatwg.org/#idl-DOMException-error-names
SHA: 1a8de89 Reason: push, by anssiko Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Thanks! |
In some other projects, before merging, the smaller related commits are squashed together, to result in more meaningful history. However, we can also keep full commit history. |
Several small commits to improve the createContext() steps, and add the validate MLContext steps.
Fixes #308.
Preview | Diff