Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    Emily
    @emiflake

    Hiya friends, I've been taking a look at Asterius and am really amazed by how well everything already works! I'm currently trying to attach event listeners, but am running into some trouble:

    foreign import javascript "(${1}).addEventListener(${2}, ${3})" ffi_addEventListener :: JSVal -> JSString -> JSFunction -> IO ()

    This is my foreign import, and this is the wrapper I make around it:

    addEventListener :: DOMNode -> String -> (JSVal -> IO ()) -> IO ()
    addEventListener node eventName _callback = do
      -- Temporary, just trying to get *something* out of Haskell
      cb <- makeHaskellCallback (putStrLn "Got callback")
      ffi_addEventListener (coerce node) (toJSString eventName) cb

    Unfortunately, I never end up getting anything back...
    Whenever I change the ffi import to

    foreign import javascript "(${1}).addEventListener(${2}, () => { console.log((${3})()) } )" ffi_addEventListener :: JSVal -> JSString -> JSFunction -> IO ()

    I do in fact get a console message, but it's a Promise that has already resolved by then. Does this have something to do with laziness?

    Emily
    @emiflake
    It seems that GHC can’t figure out what to be lazy on when it comes to callback functions, modifyIORef', for example, works
    Shao Cheng
    @TerrorJack
    @emiflake Hi, thanks for reaching out. I tried locally, and if you don't use putStrLn and instead import console.log as a Haskell function and make it a callback, it'll work.
    This is not related to laziness, our implementation of "standard output and error" in the browser is buggy, after the main thread exits, later writes to stdout/stderr buffers won't be affected to the actual browser console..
    We'll fix this problem and make the stdout/stderr buffer writes go to the actual console as soon as a line delimiter is detected in the buffer.
    Emily
    @emiflake
    Ah, thank you for your answer! This is exactly what I was able to reproduce as well earlier. Interesting. How active is development on Asterius still? I am currently playing around with a small library for web apps and it’s working really well, is the project still taking contributions?
    Shao Cheng
    @TerrorJack
    It's still active, I'm working full time on it and would be glad to take contributions!