Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Luis Copetti
    @lhcopetti
    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.
    Richard Szibele
    @rszibele
    I'm now hitting the following error in the GC:
    error_1.png
    res_c is a really large number and the issue can be solved by changing offset to BigInt(offset), but I do not know if res_c should be such a large number.
    I assume it should be a large number due to 64bit address space, but I'll take a look at it tomorrow in detail.
    Shao Cheng
    @TerrorJack
    @rszibele Yes, it's reasonable for it to be a big number because of the 64-bit virtual address space
    Thanks for finding the bug. Mind filing a PR for it? :)
    Richard Szibele
    @rszibele
    Richard Szibele
    @rszibele
    I'm getting a differentRuntimeError now which is being thrown here: https://github.com/tweag/asterius/blob/master/asterius/rts/rts.gc.mjs#L882 because the switch statement doesn't handle indirection with the case ClosureTypes.IND.
    I'm not sure what is supposed to happen there. If I set a breakpoint and check the value of this.memory.i64Load(c + rtsConstants.offset_StgInd_indirectee)then it's 0n.
    Shao Cheng
    @TerrorJack
    @rszibele Can you give the wip-develop branch a try? On that branch I reversed a recent relevant patch. Does the same problem occur?