Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    Wojciech Daniło
    @wdanilo
    @TerrorJack ping :)
    Shao Cheng
    @TerrorJack
    @wdanilo Sorry for the super late reply; I've been occupied by a lot of personal affairs on my end for the past month. Regarding the mime type problem, see https://bugs.python.org/issue35403. You need python 3.8 or later which properly provides mime types for the .wasm and .mjs extensions
    @lhcopetti I've been wondering about the ADT translation between JS/HS as well; for now, serialization via JSON and ArrayBuffers should work, albeit there may exist faster solutions. Will discuss with ghcjs folks about this
    To link libraries, use ahc-cabal. It's a wrapper to cabal-install, so you should just do ahc-cabal new-update, ahc-cabal new-build, etc, and use 3rd party libraries just like a regular cabal package. It's possible to use new-install --installdir . to create a symlink of the pseudo-executable, and then later use ahc-dist to extract the wasm/mjs artifacts from the pseudo-executable. I haven't written this in the documentation yet, will do later.
    Shao Cheng
    @TerrorJack
    We already test building and running hello from hackage on our CI now; more complex examples will follow later. Also, documenting all the JS/HS interop details is also on our radar. It just takes..time.
    Shao Cheng
    @TerrorJack
    Quick update in case anyone's still here: we now ship ~2k packages in a recent stackage lts snapshot in our docker images, and they work either via ahc-link or ahc-cabal. The "pure haskell" packages should just work fine, like aeson or lens, but there also exist packages which compile but won't work at the moment due to cbits (like cryptonite). Good timing to give it another try :)
    Yuriy Lazarev
    @Unisay
    @TerrorJack thanks for the great work you've done! I was playing with todomvc, figured out that simple http servers don't support wasm mime type, used express server where I specified mime time explicitly and it worked. One thing that I can't understand yet - why todomvc.wasm here https://www.tweag.io/wasm-todomvc/todomvc.wasm is only 81.3 KB, but when I compile it with ahc-link .. --browser --bundle -> its 2.1 MB? what am I doing differently?
    Yuriy Lazarev
    @Unisay
    Ok, 81.3 KB is "Transferred" size (after compression), source is 920.24 Kb - which is still less than 2.1 MB when compiled locally.
    Shao Cheng
    @TerrorJack
    @Unisay The todomvc we have on tweag.io was compiled from an earlier version of asterius; so code sizes may have changed since then.
    If you give the latest docker image a try, it uses the binaryen backend and performs shrinking, so you may get smaller wasm binary again
    Shao Cheng
    @TerrorJack
    Run diagrams in your browser!
    Sam Nolan
    @Hazelfire
    Diagrams! It must by Christmas 😂
    Shao Cheng
    @TerrorJack
    Does anyone use the prebuilt docker images here and rely on ghc-8.6.5? FYI our work of upgrading asterius to ghc-8.8.2 is near complete, and the images will be updated accordingly
    Richard Szibele
    @rszibele
    Hi, is there a way I can debug the wasm that asterius generates? I currently built my program with ahc-cabal and then run ahc-dist on it. I tried disabling optimizations and shrinking but I still get a StackOverflow exception even though I believe I shouldn't be getting it.
    a little more context: I'm trying to port a Haskell game that I've written in the past two months to asterius. It's uses a pure stateful engine and only has a bit of SDL at the edges, which is why it only took me about a day to replace the SDL packages with a custom javascript renderer.
    Richard Szibele
    @rszibele
    I forgot to mention that the game compiled with GHC does not throw a StackOverflow exception.
    Shao Cheng
    @TerrorJack
    @rszibele Hi, it's a current limit with the asterius runtime, our stack size is fixed and doesn't implement the segmented stack as in ghc rts yet, so it's possible to encounter StackOverflow errors which doesn't occur in native ghc
    Fixing the stack stuff is on our tables though. We'll implement segmented stacks in Q1, and before that we may add a mitigation which allows using a ahc-link option to adjust the stack size
    Richard Szibele
    @rszibele
    @TerrorJack Thanks for the quick response! Is there a way to find out where it is being triggered? I've read that it's possible to pass in a --debug flag to ahc-link but I don't use it directly and passing it to ahc-dist doesn't seem to do anything.
    I assume that ahc-cabal calls ahc-link under the hood so I'll just try aliasing it for now.
    Shao Cheng
    @TerrorJack
    ahc-cabal builds pseudo-executable files and doesn't call ahc-link. You need to use ahc-dist to extract the wasm/js artifacts from the pseudo-exe file, and ahc-dist shares almost all flags with ahc-link, except it uses --input-exe instead of --input-hs
    You can add --verbose-err option to ahc-dist, so when wasm crashes, the resulting js stack trace contains the wasm function names, so we can at least locate the exact crash site
    Richard Szibele
    @rszibele
    2020-02-01_02-29.png
    hmm I don't know what I should be looking for. this is with the --verbose-err. it gives me the same exception as before.
    Shao Cheng
    @TerrorJack
    @rszibele We solved the stack overflow problem in tweag/asterius#448. If no regressions, this will soon get merged and the docker images will be updated accordingly
    Richard Szibele
    @rszibele
    @TerrorJack thanks, that was really fast! I built the docker image and can confirm that it now no longer gets the stack overflow probem. the errors now also contain a stack trace with --verbose-err like you mentioned so that's nice.