Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Shao Cheng
    @TerrorJack
    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.
    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?
    Richard Szibele
    @rszibele
    @TerrorJack the wip-develop branch works :)
    Shao Cheng
    @TerrorJack
    @rszibele great to hear! btw is your project a public repo somewhere? i'd like to get a local repro and see if it can be fixed on the master branch as well
    Richard Szibele
    @rszibele
    @TerrorJack It isn't open source, but I will try to make a minimal example that reproduces the issue.
    Richard Szibele
    @rszibele
    So I did some profiling and it seems to me that the performance of Asterius is really good and it would be able to handle my game. The only thing that seems to be causing issues currently is the garbage collector.
    The gc spikes are noticeable and they are around 100-300ms, but it also seems like the gc times increase linearly over time.
    image.png
    x is total time and y is time taken for garbage collection.
    Richard Szibele
    @rszibele
    I assumed I had a space leak in my code somewhere but according to ghc's profiling tools I shouldn't have any noticeable space leaks:
    image.png
    I forgot to mention, but in the first graph the different colored points are for the gc threshold option. I also didn't run them for the same amount of time.
    Richard Szibele
    @rszibele
    I also left the game idle when recording that data.
    Shao Cheng
    @TerrorJack
    Thanks a lot for doing all the profiling and providing the graph above!

    gc times increase linearly over time

    It's somewhat expected behavior, since we don't do generational gc yet and is based on a naive copying gc implementation for now, so gc time (when it actually happens) is dependent on heap resident data size

    And we have a few loose ends to tighten up yet in the storage manager, e.g. we haven't done proper Weak support yet, so if they're used, the finalizers are never run and Weak refs are actually strong refs yet.
    Improving the gc situation is among our top priorities btw