-
-
Notifications
You must be signed in to change notification settings - Fork 795
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
Use ESM import in module type webworker #2220
Conversation
Thanks @leopsidom. Maybe it would be better instead to test |
Do you mean test |
Added a check to narrow down the exception type to |
That is unfortunate... Is there any other direct means one can use to distinguish between a module worker and a classic worker? I looked through the whatwg worker spec and I think the answer is no. Hopefully this is the only reason that |
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.
Ideally we should add a test for importing Pyodide as a module, both in a module worker and on the main thread, or else it might get broken again.
Yeah, that makes sense. I'll take a look at adding tests for module import, though the tests won't work for module type worker in firefox yet as it's still catching up with the support at the moment. |
If you get stuck, let me know. You will probably want the
Sure. You can xfail it in firefox. |
Sure, just read a little about module and function scope, I'm not completely sure that I understands the difference. For the tests, I'm thinking we could add a type parameter to the |
Sounds like a good plan to me. There's a tradeoff we don't want to run the entire test suite in every combination of browser and webworker configuration since it would take too long. Just testing that we can successfully load Pyodide would catch the problem you reported. |
The issue with fixture scope is essentially how often we reload the browser tab. Refreshing the browser tab provides better isolation between tests but at the cost of taking much longer to run them. |
Cool. Got it. I think as long as we don't get issues on tests interacting with each other, we can definitely change the scope so it saves time on refreshing the context. |
@@ -104,6 +105,8 @@ src/js/pyproxy.gen.ts : src/core/pyproxy.* src/core/*.h | |||
build/test.html: src/templates/test.html | |||
cp $< $@ | |||
|
|||
build/module_test.html: src/templates/module_test.html |
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.
At some point we probably should try to combine some of these templates build rules (no action needed in this PR).
The |
Similar for this workflow from this commit. |
Yeah the test failure has nothing to do with this PR. |
In particular, that means the test failure won't prevent us from merging this. |
Yeah it seems to be failing inherently due to an unknown issue. So I guess we shouldn't let it block us from merging new changes. Wonder if it's a selenium issue or firefox issue. But considering it's even xfail chrome for recursion limit, it looks like it's trying to push the limit of the browser capability. |
xfailing chrome for the recursion limit must be out of date, we fixed that cf #2019 |
But yeah, perhaps just turning that benchmark off would be a good start. |
I am looking into it! sorry for the confusion :) (#2226) |
window.logs = []; | ||
console.log = function (message) { | ||
window.logs.push(message); | ||
}; | ||
console.warn = function (message) { | ||
window.logs.push(message); | ||
}; | ||
console.info = function (message) { | ||
window.logs.push(message); | ||
}; | ||
console.error = function (message) { | ||
window.logs.push(message); | ||
}; |
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.
Perhaps we should move this Javascript setup out of test.html
and module_test.html
into tools/testsetup.js
? This would reduce the duplication.
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.
Though maybe the issue is we specifically don't want it in node
? I can't remember. I feel like I tried to move this to testsetup.js
before and it didn't work. If we did move it into tools/testsetup.js
all window
would have to be replaced with self
.
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.
Oh sure, I think we could move the logic in a separate js file. I suspect node
should not use the test.html
file, though need to double check. I can try it at some point.
Thanks @leopsidom! |
</script> | ||
<script type="module"> | ||
import { loadPyodide } from "./pyodide.mjs"; | ||
window.loadPyodide = loadPyodidea; |
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.
I guess this must be a typo?
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.
huh I wonder why that wouldn't break the tests
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.
Hmm, that's interesting. Let me double check ~
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.
Okay I think the tests pass because we already attach loadPyodide
to globalThis
here, while this typoed line errors out due to undefined loadPyodidea
, so the line is not doing anything except throwing an error.
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 for the investigation. In that case we don't need to bind loadPyodide
to the global in the test.html file anymore, so we would better remove those.
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.
Oh I think I understand what you mean, when we call loadPyodide
multiple times, we are overwriting the same Module instance.
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.
Yeah exactly.
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.
I personally don't have much use case to load multiple pyodide instances yet. But I think it could definitely be something useful. Maybe we could wrap modules and loadPyodide
in a class Pyodide
and expose that class. Then every time we instantiate a new instance of Pyodide
, we create a new standalone module that does not interfere with other instances.
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.
Yeah maybe that would work.
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.
See #2255.
Description
The PR is to avoid
importScripts
error when loading pyodide in a module type worker. CurrentlyloadScripts
usesimportScripts
to import dependency which throws an error when the worker is of typemodule
.Checklists