-
Notifications
You must be signed in to change notification settings - Fork 13
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
add files from jupyterlite-xeus #4
Conversation
in the working repo #2 we have some special step for the webpack / worker https://github.com/DerThorsten/jupyterlite-xeus/blob/main/package.json#L34 and some special webpack config https://github.com/DerThorsten/jupyterlite-xeus/blob/main/worker.webpack.config.js This is not yet present in this repo and gives strange issues when trying to start the kernel (compiled without webpack modification to see whats going on)
we get a lot of webpack code appended to the worker.js which is causing the error above ************************************************************************/
/******/ // The module cache
/******/ var __webpack_module_cache__ = {};
/******/
/******/ // The require function
/******/ function __webpack_require__(moduleId) {
/******/ // Check if module is in cache
/******/ var cachedModule = __webpack_module_cache__[moduleId];
/******/ if (cachedModule !== undefined) {
/******/ return cachedModule.exports;
/******/ }
/******/ // Create a new module (and put it into the cache)
/******/ var module = __webpack_module_cache__[moduleId] = {
/******/ // no module.id needed
/******/ // no module.loaded needed
/******/ exports: {}
/******/ };
/******/
/******/ // Execute the module function
/******/ __webpack_modules__[moduleId](module, module.exports, __webpack_require__);
/******/
/******/ // Return the exports of the module
/******/ return module.exports;
/******/ }
/******/
/******/ // expose the modules object (__webpack_modules__)
/******/ __webpack_require__.m = __webpack_modules__;
/******/
/******/ // expose the module cache
/******/ __webpack_require__.c = __webpack_module_cache__;
/******/
/******/ // the startup function
/******/ __webpack_require__.x = () => {
/******/ // Load entry module and return exports
/******/ var __webpack_exports__ = __webpack_require__.O(undefined, [424], () => (__webpack_require__(213)))
/******/ __webpack_exports__ = __webpack_require__.O(__webpack_exports__);
/******/ return __webpack_exports__;
/******/ };
/******/
/************************************************************************/ |
To try to debug this you need to build jupyterlite like this, where <REPO_DIR> is the dir of this repo
|
Co-authored-by: Duc Trung Le <[email protected]>
Co-authored-by: Duc Trung Le <[email protected]>
…-loader into xeus-loader
@trungleduc still the same :/ |
if you use the worker.ts file. You need to add the typescript loader. For example here is what we did https://github.com/jupytercad/jupytercad/blob/v0.3.3/packages/jupytercad-extension/worker.webpack.config.js |
Or you can try the second solution renaming the output of Webpack to another name #4 (comment) |
So just to clarify. The webworker code is picked up by webpack and processed.
I assume this is when it tries to load the dependencies we use inside the worker, ie that stuff import { expose } from 'comlink';
import {
DriveFS,
DriveFSEmscriptenNodeOps,
IEmscriptenFSNode,
IStats
} from '@jupyterlite/contents'; |
your |
I played around with that as we used to have a dedicated step for this in the other repos. But the reason to have this as a separate step was that |
@trungleduc ah ok, so I start to understand. The |
No, you can not drop that, you want to build |
Ok, now things start to make sense again. (assume maximum stupidity here...I don't know what I am doing here most the time ;) ) |
@jtpio we could merge this now. (maybe not in main?) as it is in a working state again. |
Sure, if it helps iterating on it. Just left a few minor inline comments. Also wondering if we could improve the initial blocking HTTP request for fetching the json file. Network (or the static HTTP server) can be slow, and this could increase the time it takes for the application to start. |
Co-authored-by: Jeremy Tuloup <[email protected]>
I agree that its unsexy, but the json files are all so tiny that this will not be a big issue (the kernel.json for each kernel are ~200 bytes) |
Maybe there is a way to inline the kernels at |
Yeah they are all known at |
OK so I guess we can look into this separately. And also fix the remaining CI failure in the next iteration. |
…-loader into xeus-loader
this is building ontop of the PR #2