Compiling Bonsai

Hi all, I’d like to try Bonsai to develop a web frontend, since I gave up hope of using Reason and related ecosystem.

The version present in opam (v0.14.0) has no examples, while the master on GitHub seems much more complete in that sense but I failed to compile the library because it relies on library not present in opam or versions not released yet.

So I created a new switch and pinned all the relevant dev-repo but still no success. For example I can’t find any “1.0.6+newsyntax” version of gen_js_api, required by the latest virtual_dom.

Any suggestions?

3 Likes

I usually create a new switch with the janestreet-bleeding repo and that should let you install the v0.15 preview of bonsai. Then the examples from the repo should work.

3 Likes

Out of curiosity, why not ReScript (i.e. what people used to call ReasonML)?

Precisely because “people used to call”. The API is changing too much to be used in production, at least for us.

In our use case we build web interface to control industrial plant and we have to provide updates, bug fixes, new features (read: entire new lines of production) over 20+ years.

We need “OCaml in the browser”, not “Javascript with fancy syntax and static typing”.

Don’t take my words the wrong way: I really appreciate the project, especially ReasonReact, but we need something we can live with for a long time, without worrying a lot about it.

6 Likes

Well, the ReasonReact API hasn’t really changed–only the rename from BuckleScript to ReScript (which has been done in a completely backward-compatible way, breaking nothing).

In any case, for a more OCaml-y (or Elm-y) style there is also the very stable GitHub - OvermindDL1/bucklescript-tea: TEA for Bucklescript

1 Like

I will give a look at it, thanks.

1 Like

I don’t think the janestreet-bleeding repo solves the problem in this case. The problem is that gen_js_api.1.0.6+newsyntax refers to some package that exists neither in that repo (gen_js_api is not a Jane Street package) nor in the main opam repo. So there’s no way to install the dependency that is needed by the latest version of Bonsai.

Here is what happens when I try to install Bonsai on a fresh switch with janestreet-bleeding:

$ opam install 'bonsai.v0.15~preview.124.13+29'
The following dependencies couldn't be met:
  - bonsai → virtual_dom >= v0.15~preview.124.13+29 → gen_js_api >= 1.0.6+newsyntax
      no matching version

No solution found, exiting
1 Like

Odd it seems opam wants to downgrade my version of bonsai now as well. I’m using ocaml-4.10.0+flambda with bonsai v0.15~preview.123.18+275 which should be close enough to the examples I believe. So hopefully the repo gets updated to include this new dependency.

Less elegant, but it seems that this should work:

git clone https://github.com/janestreet/bonsai.git
cd bonsai
git checkout b6c1a0e7a2f1e9df829383a3cd708c950502856e
opam install .

In this very same situation (4.10.0+flambda + checkout of b6c1a0e7a2f1e9df829383a3cd708c950502856e) it still does not compile but not Bonsai itself.

It’s async_js the problem:

#=== ERROR while compiling async_js.v0.15~preview.124.13+29 ===================#
# context     2.0.7 | linux/x86_64 | ocaml-variants.4.10.0+flambda | https://ocaml.janestreet.com/opam-repository
# path        ~/.opam/4.10.0+flambda-BONSAI/.opam-switch/build/async_js.v0.15~preview.124.13+29
# command     ~/.opam/opam-init/hooks/sandbox.sh build dune build -p async_js -j 25
# exit-code   1
# env-file    ~/.opam/log/async_js-115070-0dbe27.env
# output-file ~/.opam/log/async_js-115070-0dbe27.out
### output ###
# [...]
#       ocamlc src/.async_js.objs/byte/async_js__Async_js0.{cmo,cmt} (exit 2)
# (cd _build/default && /home/paolo/.opam/4.10.0+flambda-BONSAI/bin/ocamlc.opt -w -40 -g -bin-annot -I src/.async_js.objs/byte -I /home/paolo/.opam/4.10.0+flambda-BONSAI/lib/angstrom -I /ho
me/paolo/.opam/4.10.0+flambda-BONSAI/lib/async_kernel -I /home/paolo/.opam/4.10.0+flambda-BONSAI/lib/async_kernel/persistent_connection_kernel -I /home/paolo/.opam/4.10.0+flambda-BONSAI/lib
/async_rpc_kernel -[...]
# File "src/async_js0.ml", line 11, characters 20-38:
# 11 |   Js.Opt.to_option (Js.js_error_of_exn exn)
#                          ^^^^^^^^^^^^^^^^^^
# Error: Unbound value Js.js_error_of_exn
#     ocamlopt src/.async_js.objs/native/async_js__Async_js0.{cmx,o} (exit 2)
# (cd _build/default && /home/paolo/.opam/4.10.0+flambda-BONSAI/bin/ocamlopt.opt -w -40 -g -I src/.async_js.objs/byte -I src/.async_js.objs/native -I /home/paolo/.opam/4.10.0+flambda-BONSAI
/lib/angstrom -I /home/paolo/.opam/4.10.0+flambda-BONSAI/lib/async_kernel -I /home/paolo/.opam/4.10.0+flambda-BONSAI/lib/async_kernel/persistent_connection_kernel -I /home/paolo/.opam/4.10.
0+flambda-BONSAI/li[...]
# File "src/async_js0.ml", line 11, characters 20-38:
# 11 |   Js.Opt.to_option (Js.js_error_of_exn exn)
#                          ^^^^^^^^^^^^^^^^^^
# Error: Unbound value Js.js_error_of_exn

@OCamlUser I managed to compile everything, thanks.

Other than checking out bonsai at v0.15~preview.123.18+275 I had to pin async_js to v0.14.0.

1 Like

Oh, I just figured out how to do it without having to fuss around with pins or downgrades: there’s an external-packages branch of janestreet/opam-repository. So just do something like:

opam repo add janestreet-external https://github.com/janestreet/opam-repository.git#external-packages

and then you can just opam install bonsai.

5 Likes

@OCamlUser and @Levi_Roth thanks!

Thinking about the churn in web ui frameworks and methods of communicating with servers, I would give up on the web browser and use a desktop application using some framework that hasn’t changed too much (qt?) talking to graphql, in such a setting

1 Like

If desktop is an option, then FreePascal and Lazarus have been around for decades and will likely be for more: https://www.lazarus-ide.org/

2 Likes

If you need a virtual dom, I think it is worth trying out ocaml-vdom, a mature package from Lexifi. I am trying it out and I found them very welcoming. However installation is still a bit of a pain, here is how I installed it in case you want to give it a try:

# insatll gen_js_api-1.0.6
wget https://github.com/LexiFi/gen_js_api/archive/v1.0.6.tar.gz
tar xzvf v1.0.6.tar.gz
cd gen_js_api-1.0.6/
opam install opam-installer
make all
opam install .

cd ..

# install ocaml-vdom
git clone https://github.com/LexiFi/ocaml-vdom.git
cd ocaml-vdom
make all
opam install odoc
make doc
make examples
opam install .

(I am about to use it with eliom/ocsigen for the back-end, but any back-end is fine)
Best !

3 Likes

This should be much more straightforward now, as both gen_js_api.1.0.6 and ocaml-vdom.0.2 are available through opam. For me all that was needed was:

opam install ocaml-vdom

And for building the examples:

git clone https://github.com/LexiFi/ocaml-vdom.git
cd ocaml-vdom
make examples
6 Likes

Sadly I’m still having problems installing bonsai (bleeding edge version).

$ mkdir bonsai-switch; cd bonsai-switch
$ opam switch create . 4.11.2
$ opam repo add janestreet-bleeding-external https://github.com/janestreet/opam-repository.git#external-packages
$ opam repo add janestreet-bleeding https://ocaml.janestreet.com/opam-repository
$ opam update
$ opam install bonsai

(etc. etc)

#=== ERROR while compiling cohttp-async.4.0.0 =================================#
# context     2.1.0 | linux/x86_64 | ocaml-base-compiler.4.11.2 | https://opam.ocaml.org#f2f58c72
# path        ~/bonsai-switch/_opam/.opam-switch/build/cohttp-async.4.0.0
# command     ~/.opam/opam-init/hooks/sandbox.sh build dune build -p cohttp-async -j 7
# exit-code   1                                                   
# env-file    ~/.opam/log/cohttp-async-1115039-13ff06.env       
# output-file ~/.opam/log/cohttp-async-1115039-13ff06.out       
### output ###                                                    
# Error: This expression has type [ `Use_Command_unix ]         
# [...]                                                                                                                             
# (cd _build/default && /home/abcxyz/bonsai-switch/_opam/bin/ocamlc.opt -w -40 -g -bin-annot -I cohttp-async/bin/.cohttp_curl_async.eo
bjs/byte -I /home/abcxyz/bonsai-switch/_opam/lib/angstrom -I /home/abcxyz/bonsai-switch/_opam/lib/astring -I /home/abcxyz/bonsai-switch/_o
pam/lib/async -I /home/abcxyz/bonsai-switch/_opam/lib/async/async_command -I /home/abcxyz/bonsai-switch/_opam/lib/async/async_quickcheck
 [...]
# File "cohttp-async/bin/cohttp_server_async.ml", line 129, characters 2-5:
# 129 |   run
#         ^^^
# Alert deprecated: Async_command.run
# [since 2021-03] Use [Command_unix]
# File "cohttp-async/bin/cohttp_server_async.ml", line 129, characters 2-5:
# 129 |   run
#         ^^^
# Error: This expression has type [ `Use_Command_unix ]
#        but an expression was expected of type 'a -> 'b

Looks like a deprecation warning rather than something more fatal.

If you vendor cohttp-async into the project you’re trying to build with bonsai then you could disable the warnings as errors behaviour of dune. FAQ — dune documentation

@lambda_foo Appreciate your help. Your tip on converting all warnings-as-errors (which dune does) to just normal warnings is a useful one – though it didn’t seem to work for this issue.

I was able to get this compiling in way I found purely by luck.

Notice my error above complains about cohttp-async . If I explicitly type:

$ opam install cohttp-async
The following actions will be performed:
  - downgrade conduit       4.0.0 to 2.3.0 [required by conduit-async]
  - downgrade conduit-async 4.0.0 to 2.3.0 [required by cohttp-async]
  - install   cohttp-async  4.0.0+async
===== 1 to install | 2 to downgrade =====
Do you want to continue? [Y/n] Y
...
...

By this direct invocation, cohttp-async mysteriously compiles and then I’m able to proceed with the original $ opam install . --deps-only step. Note that some packages are downgraded. This seems to do the trick.

  • I’m using opam 2.1 so this could be some constraint solving issue (I haven’t tried with opam 2.0.x)
  • Its possible some of the contraints are wrong?

Anyways I now have bonsai bleeding edge compiled locally.

Out of curiosity, I looked into this for 5 minutes. I’m on opam 2.0 and got the same error as you did. It does seem like one of the constraints is too wide and including versions that’s aren’t compatible.

1 Like