Closed YuMingLiao closed 3 years ago
Wow- I had never tried building project-m36 with ghcjs. Did it ever compile?
If this is important to you, I think we have a better chance of compiling to JavaScript now that we dropped the unmaintained distributed-haskell. I think this would be a cool project with a substantial amount of refactoring necessary- would you like to collaborate on this?
I guess nope. I just tried to compile project-m36-0.7 in ghcjs. It failed at finding GHC.Event in the network
package. There are some related issues here.
I am not sure how far I can go. I'll keep posting if there is some progress.
And yes, I agree with you, I think it would be cool if a ghcjs frontend can use project-m36 as a database client side to access a project-m36 database.
here says network-3.1.1.1 supports ghcjs. Interesting. (Just leave clues here)
Network-3.1.2.1 supports ghcjs. One step further. Now, it is stuck at distirbuted-process in ghcjs project-m36-0.7.Due to some nix problems that I don't understand, I cannot compiler it further.
I am not sure if I had succeed at ghcjs-compiling project-m36 before. I don't recall how I use it. So maybe in dreams...
In ghcjs-compiling project-m36-0.9, I tried not to use fast-building in curryer-rpc and then find out winery use it too. That's the process for now.
By the way, in case you missed it, Project:M36 includes a websocket client-server API, so it is already possible to access Project:M36 from a web page.
I definitely have heard requests for Project:M36 to run entirely inside a web browser, which is what I think you are trying to achieve. That will require a trimmed-down version of Project:M36 which does not require any filesystem IO, but it should definitely be possible. If there is some refactoring that I can do to make that easier, I am definitely open to it. I think a GHCJS port would be a great way to introduce people to the relational algebra/TutorialD without requiring a Project:M36 server running.
Thanks. I haven't tried websocket. I was trying if I can get type safety for free in the frontend.
Right now, I have changed fast-builder imports to bytestring in curryer-rpc and winery, not knowing what it effects, just to see what else will stuck in the middle. Now, the compilation stucks at "could not find module Streamly.Network.Socket" in curryer-rpc. ghcjs with streamly alone, some of the modules in Streamly couldn't be found. ghc8104 with streamly, Streamly.Network.Socket can be found. And I don't know why.
Project:M36 pegs the streamly version to a specific github commit of streamly because Project:M36 uses features of streamly which have not yet been released on hackage. Is it possible that GHCJS is choosing the wrong version of streamly?
By the way, if you want to get Project:M36 ADTs into the web browser (and not nodejs), I would drop curryer-rpc entirely because the web browser cannot initiate low-level TCP connections, so even if you get it to compile, the web browser won't be able to use curryer-rpc to connect to the backend.
Instead, we would need a Haskell version of the websocket client API to run in the browser. It should be pretty easy since it's all derived Aeson ADTs.
I see. Thx for the reminders! I guess you mean something like ghcjs-websockets (deprecated. now ghcjs-base has websokets interface.) I am afraid that it is out of my league for now. But good to know there is a way to achieve that.
Just a note about file IO on the client side: a-way-to-emulate-a-database-with-html5s-localstorage
project-m36 now uses winery and curryer-rpc, which uses fast-builder, which uses ghc-prim. Right now, ghcjs can't build fast-builder or ghc-prim. That means project-m36 or project-m36-typed cannot be used on ghcjs frontend. websocket may work, but it lose type-safety.