btw, the link to weekly status reports on github main page is broken
There isn't a milestone for cutting an alpha yet, but do tell us what feature/library you'd like to see in an alpha release, also you can check the report to see our status :)
@TerrorJack thanks for the answer! Basically I'm choosing a technology for our new GUI. It's need to be blazing fast and run on WebGL. I'm long term Haskeller and our team loves Haskell, but current state of Haskell in the browser is very poor (we tried it in a serious project). We've got several possible options, including Rust -> wasm, or Asterious. We will be starting the project next week, so its important for us to have a "working" solution. By working, I'd need to be able to connect to webgl libraries and be able to produce fast, strict, webassembly output. I could live without TH - sure, lenses would be cool, but in the first release we can "generate" them by hand. Im reading your weekly reports regulary (when they appear), however, I dont have feeling yet when Asterious could be ready for creating a serious project like a whole GUI system and if we can try using it right now for that (or it is missing some serious components I dont know about)
We don't support popular GUI solutions like
reflex or miso out of the box yet, since the syntax/semantics of JSFFI still somewhat differs from ghcjs. At least for calling to WebGL libs and generating shader code on the fly in Haskell, asterius is already capable of that; although there isn't a WebIDL processor yet so bindings need to be hand written
But maybe people prefer something like
asterius-examples instead of lengthy docs. If you think a self-contained example smaller than todomvc which still calls web api is more favorable, do let me know and I can add one later
I'm starting out with the fib example, but I can't figure out how to run it, after it compiling it on the docker image. It doesn't seem to generate the .js file like it says on the blog post in the repository's readme
I am trying to instantiate the simples of the haskell modules after compilation, using the following JS code (I put this in a HTML and serve it using express from node):
var importObject = { imports: { imported_func: arg => console.log(arg) } };
WebAssembly.instantiateStreaming( fetch ('/mirror/simplest-hello-world.wasm'), importObject ).then ( wasm => {
console.log('Wasm read')
window.wasm = wasm;
})
The simplest-hello-world.wasm is the result of running
ahc-link --input-hs simplest-hello-world.hs
The code is simply:
main = putStrLn "Hello World"
And this is the error that I get from the browser:
Uncaught (in promise) TypeError: WebAssembly.instantiate(): Import #0 module="WasmMemory" error: module is not an object or function
Does anyone know how to prevent this from happening?
Also, re your compilation error; we rely on custom ghc bindists specified in our
stack.yaml, and if a ghc-8.6.5 installation already exists in your ~/.stack/programs then our custom version won't be installed, resulting in the error. I'll add the reminder in the docs later
@TerrorJack first of all thank you for your help above (regarding the JSFFI docs). I've got one question for you. I need to create a big WASM system and the perofmrance is critical here. I know Haskell really well, so its typelevel programming abilities would help me much squize the best things out there. OF course everything here would be strict by default. My question is what performance can I get from asterious? Is it possible to write code which will compile to something running so fast as Rust -> WASM? I know its hard to answer this question, because it depends on many aspects, but I m asking about your assumptions / maybe some tests that you did. :)
@wdanilo No concrete benchmarks yet; I think the performance is somewhere between ghcjs and native as of now. iirc you mentioned you're creating something related to webgl? So isn't the real bottleneck lying in the shader code? I know little about your project so I might be wrong though
@TerrorJack We need to squize the performance from all possible parts of the system. Updating GL buffers, managing them etc is a critical part here, so we need the highest perfomrance possible. For a reference, look ath this project : https://github.com/makepad/makepad . They've been writing it firs in somthing that compiles to JS, then rewritten to JS and after rwritting to Rust they got the performance they needed. We're doing a similar effort here of creating a very complex webgl gui
@TerrorJack to make the information complete - we are working on Luna 2.0 (http://luna-lang.org)
@wdanilo I see. If you need to squeeze out all potential of performance then rust is still a better bet; haskell (regardless of ghcjs and asterius) has extra overhead related to the heavy runtime, but implementing DSLs in haskell is surely much more pleasant. So..the choice is yours :)
@TerrorJack Ive been implementin some really heavily optimized haskell code in the past, i ncluding computing memory layout on typefamilies + custom memory manager for that. It performed as well as handwritten optimized C code, while keeping all of the benefits of amaizng Haskell DSLs possibilities. However, in our experience GHCJS was alwasy so big perofmrance bottleneck that before trying another transcompilation technology Im trying to check everything and ask about possible performance related problems :)