Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Shao Cheng
    @TerrorJack
    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 :)
    Wojciech Daniło
    @wdanilo
    @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)
    Shao Cheng
    @TerrorJack
    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
    Wojciech Daniło
    @wdanilo
    @TerrorJack Interesting, would you mind sharing information on the differences of the JSFFI? Regarding WebGL, we're fine with writing everything from scratch
    Shao Cheng
    @TerrorJack
    Sure. There's a section in docs about jsffi, but it's a bit outdated since async jsffi is shipped. I'll update the docs today and ping you when done
    Shao Cheng
    @TerrorJack
    @wdanilo I updated the JSFFI docs section here: https://asterius.netlify.com/jsffi.html
    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
    Luis Copetti
    @lhcopetti
    Hello guys, I got really instered in asterius and I have been playing with Haskell in and out for a while now and would love to get a project like this running to get my hands dirty. Can any of you guys help me out?
    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
    Luis Copetti
    @lhcopetti
    Just to shed some light on this, here are some additional information:
    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
    Luis Copetti
    @lhcopetti
    I am also trying to compile the project locally, by running the commands from the dockerfile. But I am getting "Not is scope" errors when compiling the /src/Language/Haskell/GHC/Toolkit/Hooks.hs:35:9: Not in scope: ‘GHC.stgCmmHook’
    Does anyone know how to prevent this from happening?
    Shao Cheng
    @TerrorJack
    @lhcopetti Hi, I fixed the broken --browser --bundle flag combination for the docker image; if you use the updated image now, ahc-link --input-hs hello.hs --browser --bundle should produce the valid .html, .js and .wasm files
    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
    Wojciech Daniło
    @wdanilo
    @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. :)
    Shao Cheng
    @TerrorJack
    @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
    Wojciech Daniło
    @wdanilo
    @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)
    Shao Cheng
    @TerrorJack
    @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 :)
    Wojciech Daniło
    @wdanilo
    @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 :)
    Shao Cheng
    @TerrorJack

    computing memory layout on typefamilies + custom memory manager for that

    I'm interested. And especially if it works well for native but not for ghcjs; can you throw a quick github link?

    Wojciech Daniło
    @wdanilo
    Ok, to be more precise - it works amazingly good for nartive, we did not compile this part to web. But what we compiled had pretty big overheads
    Shao Cheng
    @TerrorJack
    @wdanilo More on memory management. I'm not sure if your memory manager is based on malloc, or something lower level like mmap, or higher level like MutableByteArray# primitives; in asterius we have our block allocator backed by the wasm linear memory and imo it should be near native performance
    Wojciech Daniło
    @wdanilo
    If youre interested in the coe, here is a typelevel layout definition for our nodes (in other files there are precise definitions of the structure): https://github.com/luna/luna/blob/master/core/src/OCI/IR/Term/Layout.hs
    @TerrorJack I would rather not try to re-implement custom meory manager in web-targetting things. Our GUI is of higher complexity than makepad, and we were facing the same performance problems (like for example Macs heating too much when running it). Thats why now were looking for WASM target to implement GUI 2.0
    Luis Copetti
    @lhcopetti
    Thanks @TerrorJack, I am now able to use the --bundle and --browser flags succesfully now. This project is awesome!
    Luis Copetti
    @lhcopetti
    Although the docker image has been working wonders for me, I would still love to compile the project locally. I'm not really familiar with GHC bindists, as you may tell, but as far as I know it is something that stack provides so that custom ghc may be used instead of the official one. More objectively, how can I tell if stack picked up the correct GHC build? (In this case, your fork) I tried deleting everything from ~/.stack/programs/`, I removed everything haskell related from my path but I still get the same error with the hooks. I also reinstalled stack completely, but no luck yet. Any ideas? Thanks.
    Shao Cheng
    @TerrorJack
    @lhcopetti Reinstalling stack is not enough; you need to wipe ~/.stack completely, and build asterius first; then the custom bindist of 8.6.5 will get picked up. This also means that any other local stack projects will need rebuilding, so it's a very big hammer and should be used with care!
    Luis Copetti
    @lhcopetti
    @TerrorJack Thanks for the reply. It should work ubuntu, right? I tried running on a ubuntu:18.04 container
    and I get the same compilation error
    Version 2.1.3, Git revision 0fa51b9925decd937e4a993ad90cb686f88fa282 (7739 commits) x86_64 hpack-0.31.2
    This is the stack version that gets installed, I will try the same with a debian image, the same one that is used for the .circleci build
    Luis Copetti
    @lhcopetti

    I think I found something. This is what I get when I run stack build -v on a debian:unstable image:

    2019-09-04 02:04:12.833011: [debug] Process finished in 1ms: /sbin/ldconfig -p
    2019-09-04 02:04:12.833621: [debug] Did not find shared library libtinfo.so.5
    2019-09-04 02:04:12.833690: [debug] Found shared library libtinfo.so.6 in 'ldconfig -p' output
    2019-09-04 02:04:12.833775: [debug] Found shared library libncursesw.so.6 in 'ldconfig -p' output
    2019-09-04 02:04:12.833875: [debug] Found shared library libgmp.so.10 in 'ldconfig -p' output
    2019-09-04 02:04:12.833981: [debug] Did not find shared library libgmp.so.3
    2019-09-04 02:04:12.834051: [debug] *Potential GHC builds: tinfo6, ncurses6*
    2019-09-04 02:04:12.834146: [debug] Found already installed GHC builds: 
    2019-09-04 02:04:13.203637: [debug] Trying to setup GHC build: tinfo6
    2019-09-04 02:04:13.203874: [info] Preparing to install GHC (tinfo6) to an isolated location.

    whereas for ubuntu:18.04 image, I get the following:

    2019-09-04 02:05:52.970346: [debug] Process finished in 5ms: /sbin/ldconfig -p
    2019-09-04 02:05:52.970489: [debug] Found shared library libtinfo.so.5 in 'ldconfig -p' output
    2019-09-04 02:05:52.970735: [debug] Did not find shared library libtinfo.so.6
    2019-09-04 02:05:52.970830: [debug] Did not find shared library libncursesw.so.6
    2019-09-04 02:05:52.970906: [debug] Found shared library libgmp.so.10 in 'ldconfig -p' output
    2019-09-04 02:05:52.970996: [debug] Did not find shared library libgmp.so.3
    2019-09-04 02:05:52.971534: [debug] *Potential GHC builds: standard*
    2019-09-04 02:05:52.971624: [debug] Found already installed GHC builds: 
    2019-09-04 02:05:53.234965: [debug] Trying to setup GHC build: standard
    2019-09-04 02:05:53.235086: [info] Preparing to install GHC to an isolated location.
    So it seems stack is not being able to resolve the libtinfo.6 and libncurses.6 on ubuntu 18.04 and is consequently picking up the standard ghc build instead of the custom one
    Shao Cheng
    @TerrorJack
    @lhcopetti That makes sense then! The CI script to build our custom ghc bindists currently only provide tinfo6 versions. I'll build standard versions for people's convenience in the next build
    Luis Copetti
    @lhcopetti
    @TerrorJack Great, I will wait for the updated versions then. Thanks
    Shao Cheng
    @TerrorJack
    @lhcopetti I pushed the update to master. The stack.yaml now includes ghc bindists for tinfo5, tinfo6 and musl variants of linux64, so if your distro relies on libtinfo5 then it should work now.
    Luis Copetti
    @lhcopetti
    @TerrorJack Thanks!! You are right, It works on my Ubuntu 18.04 now
    Luis Copetti
    @lhcopetti
    @TerrorJack Hello, guys. Here is another thing I am trying to figure out: Is there any way for me send simple ADTs such as: data Object = Object String Int Int to javascript? The other way around also puzzles me, such as when handling DOM callbacks, is there a way for me to capture (maybe even the partial event) object from the registered callback handler?
    Luis Copetti
    @lhcopetti
    Hello again guys, I have another question concerning the use of Asterius with haskell libraries. I am looking at the code for the todomvc and it uses the bytestring library, which is not part of the base, I believe. I am wondering if this works for other libraries as well, such as random. Is there any way to link libraries in the current implementation? Thanks
    Wojciech Daniło
    @wdanilo
    @TerrorJack I'm trying to run hello world in Asterious in a browser. I've created a file and successfully compiled it with
    ahc-link --input-hs Main.hs --browser --bundle
    I also run python SimpleHTTPServer to serve it
    however, when openning Main.html in the browser I see the error in console:
    Main.html:1 Uncaught (in promise) TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
    @TerrorJack do you know how to solve that? I was trying different ways of generating things and nothing worked