Skip to content

this.fs.FS.genericErrors comes out to be undefined #23514

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

Closed
anutosh491 opened this issue Jan 28, 2025 · 8 comments
Closed

this.fs.FS.genericErrors comes out to be undefined #23514

anutosh491 opened this issue Jan 28, 2025 · 8 comments

Comments

@anutosh491
Copy link

anutosh491 commented Jan 28, 2025

Hey @sbc100

I would like some help from your side.

I might have opened issues about xeus-cpp-lite in the past. It is basically a jupyter kernel that helps you run clang-repl in the browser.

  1. For our initial use case, we built everything (all packages in the stack) using emsdk 3.1.45 including llvm and xeus-cpp
    This gives us a working wasm kernel that can be used through this static link (https://compiler-research.org/xeus-cpp/lab/index.html)

  2. But to make use of some features, we planned to migrate the whole stack to a later version of emsdk (emsdk 3.1.73) and build all pakcages with that. We are facing some errors while doing the same. Check issue Xeus-cpp-lite fails while including libraries after updating to emsdk 3.1.73 compiler-research/xeus-cpp#244

So if you go to the above and try including an external header like #include "nlohmann/json.hpp" everything would work smoothly but this is not the case after the migration. I see this error

Image

@anutosh491
Copy link
Author

While debugging this, both versions essentially are trying to do the same thing and are going through the same path. Basically through this block

                        lookup(e, t) {
                            const r = this.node(e)
                              , n = this.fs.PATH.join2(this.fs.realPath(r), t)
                              , o = this.fs.API.lookup(n);
                            if (!o.ok)
                                throw this.fs.FS.genericErrors[this.fs.ERRNO_CODES.ENOENT];
                            return this.fs.createNode(r, t, o.mode, 0)
                        }

This file name is 78.03ef1110600d818e8f4e.js?v=03ef1110600d818e8f4e if that helps as shown in the sources

Image

@anutosh491
Copy link
Author

Now both versions should operate similarly and throw an error through throw this.fs.FS.genericErrors[this.fs.ERRNO_CODES.ENOENT]; but setting a debugger on both and getting them to print out the values through the console. This is what I see

  1. 3.1.45

Image

  1. 3.1.73
Image

@anutosh491
Copy link
Author

anutosh491 commented Jan 28, 2025

Hence my thinking tells me that there is some flag business going on ? That leads to genericErrors being undefined ?

The flags for xeus-cpp-lite are present here (https://github.com/compiler-research/xeus-cpp/blob/ba37f4f0ff35eabe76b49902b67316cbd3f7202f/CMakeLists.txt#L442-L451)
and are defined here (https://github.com/jupyter-xeus/xeus/blob/main/cmake/WasmBuildOptions.cmake)

Hence currently both of these are being built with the same flags but there might be some reason as to why genericErrors is undefined for the 3.1.73 case.

The readme for building is also standard all throughout (https://github.com/compiler-research/xeus-cpp?tab=readme-ov-file#installation-within-a-mamba-environment-wasm-build-instructions)

@anutosh491
Copy link
Author

I think genericErrors was dropped before the release of 3.1.73
#22914
Not sure if this is somehow related here and if I should be seeing this being used in the above js file ?

@sbc100
Copy link
Collaborator

sbc100 commented Jan 28, 2025

Indeed, genericErrors, and all the places it is used were removed in #22914. Where is the code in question coming from? i.e. that lookup function that calls this.fs.API.lookup.. that doesn't look like code that comes from emscipten? Are you using some kind of external JS libraries perhaps?

@sbc100
Copy link
Collaborator

sbc100 commented Jan 28, 2025

Ah yes, it looks like its coming from https://github.com/jupyterlite/jupyterlite/blob/7c67c2e5c3f4734a897652ea18c35244baf30a0f/packages/contents/src/drivefs.ts#L329. It looks like that code has a lot of dependencies on emscripten-internals and needs an update.

@anutosh491
Copy link
Author

anutosh491 commented Jan 29, 2025

Ah yes, it looks like its coming from https://github.com/jupyterlite/jupyterlite/blob/7c67c2e5c3f4734a897652ea18c35244baf30a0f/packages/contents/src/drivefs.ts#L329.

Oops, looks like that's it ! Thanks for the help

It looks like that code has a lot of dependencies on emscripten-internals and needs an update.

Maybe you could point me to any other outdated/deprecated/dropped functions you see ? (I can probably make a PR to jupyterlite to get stuff fixed)

@anutosh491
Copy link
Author

anutosh491 commented Jan 29, 2025

Closing as fixed !

Try xeus-cpp-lite below ( the example notebook hosted is fun )
https://compiler-research.org/xeus-cpp/lab/index.html

That now works with emsdk 3.1.73

Thanks @sbc100 for the help :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants