Call for minimal HTML example

[ivanperez-keera]

GHC now includes a Webassembly backend. GHCJS has also changed.

Would anyone be able to put together an up-to-date example (ideally with a docker image so we can run it anywhere) that uses Yampa for a frontend web app? It can use HTML widgets or drawings, it doesn't matter.

Thanks!

[ivanperez-keera]

Related issue #34 :) Would anyone like to volunteer to start working on this so we can tackle this for the next release?

[AntanasKal]

I could try to work on this in the coming couple of weeks, will try to spend some time this weekend. I might not want to make a strong promise, as some issues may arise and there are a bunch things that I am unfamiliar with, but it should be doable to make some example project using GHC wasm backend.

I was able to compile to wasm and run a simple Yampa program following ghc-wasm-meta. A thing to note: you need to choose 9.6 flavour (or all_9_6 flake output) otherwise you may get a cabal error as there is some version clash between Yampa's deepseq dependency and base library for GHC 9.8 or newer version.

On Haskell Gamedev discord somebody posted an example of calling Javascript functions from Haskell and the other way round. Rendering is done using a section of Raylib which is compiled to wasm using Emscripten. I could not find any other examples for games using GHC wasm backend.
https://github.com/Anut-py/ghc-web-test

Other resource that could be helpful (to look at the setup of a simple example, not particular details) is Rust wasm tutorial on creating Conway's Game of Life:
https://rustwasm.github.io/docs/book/game-of-life/testing.html

[ivanperez-keera]

This would be great, @AntanasKal . Any progress in this direction would be awesome. Let me know how it goes.

[AntanasKal]

Here is what I managed to get over the weekend: https://github.com/AntanasKal/yampa-wasm-example

Here mouse position is collected on Javascript side, and there is Yampa signal function applied to it to get the position of rotating circle.

Drawing is done on JS side using canvas (render function simply takes the position of the rotating circle). Drawing functions could also be called from Haskell, but for that some wrapper code would have to be written.

In the example, the state management in Haskell and communications between Javascript and Haskell WASI reactor feels a bit hacky and I would like to think more carefully on how to structure that. But it seems that some hackiness and manual memory management might be unavoidable for more complex comms between JS and Wasm. A relevant Reddit thread . Also ghc-wasm-meta guide instructs to use manual memory management to send large data between JS and WASI reactor modules before GHC adds first-class JavaScript interop features.

[ivanperez-keera]

This is fantastic! My experience with other platforms (and the first time via GHCJS) is that getting the first bit running is the hardest. Once that's done, the rest is much easier. So this is very, very good!

[AntanasKal]

Did not get much time to work on this the last few weeks, but I could return to this soon, hopefully will have some time this weekend. The current code has examples of:

1. Calling Haskell functions from Javascript. Yampa iteration steps are called this way.
2. Calling Javascript functions from Haskell. There are a couple of wrapped JS Canvas routines that are called from Haskell to perform drawing.
3. Using Wasm linear memory to communicate between JS and Haskell (might be relevant to communicate larger chunks of memory or with serialisation/deserialisation to communicate more complex data than basic C types, but this not necessary for simple examples).

If somebody would like to start working with Wasm and Haskell, they could already start with this example. There are some rough edges, but this might be the overall state of ecosystem around GHC Wasm backend. I could spend time cleaning up and documenting the code and also on:

1. Dockerising the example or seeing if I could deploy it to github pages.
2. Making some simple but a bit more impressive game or reactive animation with slightly more complicated use of Yampa.
3. Perhaps expanding the set of wrapped JS functions to allow loading and drawing images.

Is there anything in particular that you would like to see before the next Yampa release?

[AntanasKal]

Sounds reasonable, I'll add the changes to the repo.

Compile an existing, very simple game.

It might be doable, but the amount of work would depend on how rendering or other non-pure parts of the game are performed. E. g. for rendering routines, potentially new wrapped JS functions might have to be created. Also, keyboard inputs might need to be implemented (right now only mouse is supported). This is not complicated, but might take some time.

Put basic demo on a website (meaning show that you can just create your static web this way -- if that's possible).

I looked into Github pages a bit (haven't dealt with them before). It seems that if we have a Docker image (which could be added to Github container registry potentially?) to build the website, it should be straightforward to deploy.

[ivanperez-keera]

the amount of work would depend on how rendering or other non-pure parts of the game are performed. E. g. for rendering routines, potentially new wrapped JS functions might have to be created. Also, keyboard inputs might need to be implemented (right now only mouse is supported). This is not complicated, but might take some time.

Makes sense.

If we just want trivial, non-interactive animations, we could also start with these https://dl.acm.org/doi/10.1145/3609023.3609806 (mirror: https://ivanperez.io/#beautyfrp).

There exist some super simple Yampa games that shouldn't require extensive work in terms of rendering or input handling (in order of perceived difficulty):

• https://github.com/Poselsky/Yampa-Game-Of-Life (outputs: painting squares of different colors; inputs: mouse)
• https://github.com/ksaveljev/yampa-2048 (outputs: painting squares of different colors, drawing text; inputs: keyboard)
• https://github.com/ivanperez-keera/SpaceInvaders (output: drawing ellipse, polyline, polygons, circles, and squares / pixels; inputs: mouse)

[ivanperez-keera]

The following dockerfile installs GHC with the WASM backend using nixos. When the command docker run (with the necessary arguments) listed above is used with it, it compiles the example successfully:

FROM nixos/nix

RUN nix build \
      --extra-experimental-features nix-command \
      --extra-experimental-features flakes \
      "https://gitlab.haskell.org/ghc/ghc-wasm-meta/-/archive/master/ghc-wasm-meta-master.tar.gz#all_9_6"

[AntanasKal]

After messing around with github pages for a while (I am way more familiar with Gitlab CI) it seems that I managed to deploy a website:

https://antanaskal.github.io/yampa-wasm-example/

[ivanperez-keera]

Wow. This is amazing. Soo many possibilities now!!!

[AntanasKal]

The following dockerfile installs GHC with the WASM backend using nixos. When the command docker run (with the necessary arguments) listed above is used with it, it compiles the example successfully:

FROM nixos/nix

RUN nix build \
      --extra-experimental-features nix-command \
      --extra-experimental-features flakes \
      "https://gitlab.haskell.org/ghc/ghc-wasm-meta/-/archive/master/ghc-wasm-meta-master.tar.gz#all_9_6"

I have added this Dockerfile to the repo as well.

I will see if I get time to look into potentially porting one of the existing games to Wasm, it might be very tight to do it before a release. Most likely I will add at least a few wrapped JS functions for rendering (e. g. for rendering text), doing this today encountered some JS and Wasm issues, but there seems to exist workarounds (one issue I encountered is also discussed on stackoverflow: https://stackoverflow.com/a/76916494 ) .

[ivanperez-keera]

Awesome!

I will see if I get time to look into potentially porting one of the existing games to Wasm, it might be very tight to do it before a release.

No problem. If we get something, great, and if not, we have the benefit of high cadence (Yampa is released every 2 months).

This is outstanding progress already -- I'm very happy that you figured this out.

[AntanasKal]

If we just want trivial, non-interactive animations, we could also start with these https://dl.acm.org/doi/10.1145/3609023.3609806 (mirror: https://ivanperez.io/#beautyfrp).

There exist some super simple Yampa games that shouldn't require extensive work in terms of rendering or input handling (in order of perceived difficulty):

* https://github.com/Poselsky/Yampa-Game-Of-Life (outputs: painting squares of different colors; inputs: mouse)

* https://github.com/ksaveljev/yampa-2048 (outputs: painting squares of different colors, drawing text; inputs: keyboard)

* https://github.com/ivanperez-keera/SpaceInvaders (output: drawing ellipse, polyline, polygons, circles, and squares / pixels; inputs: mouse)

Out of these proposals, I might be interested in porting Space Invaders game as it is the result of Yampa Arcade paper, which serves as one of the tutorials for Yampa. The code changes in rendering logic might be a bit invasive (as you might need to remove HGL dependency completely), but I think should be possible with conditional compilation to have code that compiles for both HGL and Wasm+JS+Canvas. I could start with a fork of Space Invaders repo.

[ivanperez-keera]

That sounds great! I hope it doesn't require too much work, but I'm looking forward to seeing it :)

As a result of this exercise, we may be able to come up with a better architecture for the game that keeps rendering and input processing in separate modules, as opposed to mingled all over the place.

[AntanasKal]

Spent some time today, it took some effort but I managed to have it running with preprocessor flags (old target should also be buildable from the same branch). It is deployed to github pages here:
https://antanaskal.github.io/SpaceInvaders/

Here is the code:
https://github.com/AntanasKal/SpaceInvaders

I might return at some point later to this. Would need to tidy up a bit, and perhaps to think about where this Wasm version would live. I might work towards contributing to main repo, just there would be a few issues to address before that (refactoring code to clearly separate IO and pure parts, potential maintenance issues as ecosystem around GHC Wasm backend might be more volatile, packaging in some way JS code and Canvas bindings code to be conveniently reusable for other projects (this is not strictly related to Yampa, but I see that there is some potential for a library similar to blank-canvas that would to do html drawing from Haskell compiled to wasm), ...), but i will think about this later.