-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
RuntimeError: abort(CompileError: WebAssembly.instantiate(): #152
Comments
I haven't used Vue.js so I cannot say for sure what's wrong, but start by upgrading d3-graphviz to the latest version 3.0.5 and see if it helps. If it doesn't help, please specify how you start your application or even better provide a full test case, including how to build, and start it. |
BTW, I think you've accidentally destroyed parts of your comment above by deleting the word |
yes, I accidentally selected and replaced Here is the sample code I am trying to run, with instruction to deploy Component File -> https://github.com/avimehenwal/graphviz-dot/blob/master/src/components/HelloWorld.vue |
I don't know how to do it with the development server but this works for the production build:
I did some experimenting with the |
Thank you for your comment, surprisingly works for me too in production build 😄 |
FYI, in my React project, graphviz-visual-editor, I've managed to get it to work also with the development server, but it's really ugly. Maybe you have some use for it. See: |
Quick note on "wasmFolder" - The wasm file typically needs to be loaded at runtime (on demand) similar to workers. The wrapping JS generated by emscripten includes some logic which attempts to identify the location of the "wrapper JS" and will assume that the wasm file is located in the same folder as it. What happens is that the wrapper JS ends up getting moved and bundled by various tools (babel, typescript, webpack etc.), now the auto location code will still do its thing, but since its now in your dist folder, its going to assume the wasm file is in there also. Hence simply copying the wasm "resource" there is probably the simplest solution. The wasmFodler is a way to specify an alternative location for the wasm (from the requesting html pages point of view). IOW the following should work fine for most cases: wasmFolder("https://cdn.jsdelivr.net/npm/@hpcc-js/wasm@0.3.13/dist"); But you have to be carful that the wrapper version and wasm version match 100% |
@GordonSmith The problem we're having with the development servers for both React and Vue.js is that they don't seem to produce a build in the file system (at least I haven't been able to find it). I guess they are in memory somewhere. In order to get this to work, one needs to figure out where to put the wasm before starting the server so that it finds it and incorporates it into the build. You can try @avimehenwal's test case yourself if you want to have a stab at it. Your workaround of course works, but is very impractical for reasons you mention, but also since it requires Internet access which prohibits you to do development and testing offline. |
Is there a test repo I can look at (minimal?) |
|
That repo is missing source?
|
Try the commit before |
I "think" your dev dependency of If you change it to |
Remember folks who consume your library may end up using either of:
or
and with a dependency of:
|
Scratch that - I was fooled by Vue returning a "html" page in lieu of the missing wasm file - investigating more! |
For development (serve) the following works for me:
It might also work for production as well, but I was not sure how to test correctly... |
Yea that works for prod (since it simply copies the contents of "public" into "dist". At least it makes some sense - the vue generated JS essentially lives in "public/js" so when it goes to load the wasm it defaults to that folder. |
Preceded of course by:
Anyway, a really big thanks for finding this out 💪 |
Even better is to create a symbolic link which you can commit to git and then never worry about again:
|
I suspect if I "knew" vue then I would have been able to answer straight away... BTW my comments above are still true for your jsnext + main entry points in your package.json (and you should probably remove the "^" for the @hpcc-js/wasm dependency). The original error about the mis matched "magic word" is normally associated with mis matched wasm + JS wrapper - which is why I went off on that tangent - in this case it was mismatched because Vue was barfing back html instead of a 404. |
Also pinned to that exact version as adviced by @GordonSmith in #152 (comment)
@GordonSmith I've upgraded to @hpcc-js/wasm 0.3.13 and pinned it to that exact version (and discovered a bug in d3-graphviz in the making). When I have more time, I will try to understand what your comment about |
If your pinned then you don't have anything to do - but your essentially releasing two versions of your library - a bundled version (main) and an es6 version (jsnext). The bundled version "probably" contains my wrapper versioned as of the time you built the bundle. While the JSNext version only references a local copy of @hpcc-js/wasm - which may well be newer (when using the hat). So there is potential for them to be out of sync in a "consumers" development environment. (if you don't bundle my wrapper then your probably ok). Also I need to fix my auto versioning to be a bit stricter... |
Thanks @GordonSmith. I double-checked to see if I inadvertently bundled your wrapper and I don't (but found yet another d3-graphviz bug in the making 😳). A very educational exercise, this. Thanks @avimehenwal & @GordonSmith. |
Superthanks @magjac and @GordonSmith 👍 PS: not much but I would like to offer BAT as a token of appreciation to both, if you guys will accept it XD |
Everytime I try to load d3-graphviz in my vuejs, I get the following console error
and no graph is generated. Can someone please help. My fronted debugging skills are very poor.
d3-@3.0.5
Here is my vue component
The text was updated successfully, but these errors were encountered: