Error: Bigstringaf_blit_from_bytes not implemented

I’m experiencing similar issues to that of this post while building my dune project that depends on the angstrom library.

node ./_build/default/bin/main.bc.wasm.js
/home/dan/Enzo/ZillyO/_build/default/bin/main.bc.wasm.js:450
          throw: e=>{throw e;},
                     ^

Error: bigstringaf_blit_from_bytes not implemented

Nevertheless, the post don’t seem to say what was the issue or how it was fixed. I’m pretty new to ocaml, so I’m not sure if the answer was just that simple.

This is my dune file for the bin:

(executable
 (name main)
 (libraries
   js_of_ocaml
   bigstringaf
   ZillyO)
 (modes wasm))
(install
   (section bin)
   (files (main.bc.wasm.js as ZillyO)))

I also list bigstringaf as a dependency in my dune-project file:

(depends ocaml angstrom bigstringaf)

Anybody knows a workaround this?

It seems bigstringaf has C primitives. These primitives are implemented for C and JavaScript. I suspect the story on how this should be done for WASM hasn’t been written so far (at least nothing here).

(modes js)

I suspect.

1 Like

Anybody knows a workaround this?

I can see @vouillon opened a PR back in December:

Have you tried pinning that branch of bigstringaf? :thinking:

2 Likes

ohh, this might work? sadly i have no idea how to do that, less in my nix flake which uses pkgs.ocamlPackages.angstrom instead of opam x.x

oh yes, on (modes js) it works fine, sadly i also need for it to work on (modes wasm)

It should suffice to override the src and digest of the bigstringaf package, but I don’t know the exact occult incantation to do this in a flake.

Is there any documentation about how to support primitives in wasm ?

There is this: Writing Wasm primitives.

Ah nice you have to guess the link :–) ? I think it would be nice to switch to .mld files at somepoint this ocsigen website remains totally unusable and unreadable.

So what is the ocamlfind story here ?

Thanks for the opinion; it strikes me as unnecessarily sarcastic and blunt but I’ll be sure to reflect on it anyway. The link in the side menu, we clarified the section name in a recent PR which should be up soon.

It’s not sarcastic, it’s a reality.

If you want to further reflect: I think that use of js_of_ocaml in general has been hindered by a terrible lack of documentation and usability thinking in every dimension of the project which is a shame given the excellent compiler (and here is my contribution to try to alleviate that).