Again related to haskell-servant/servant#1018, the upper bound on base-compat for the current latest version of jsaddle-dom is preventing Cabal from finding a suitable build plan.

I see there are many types of arrays (Float32Array, ArrayBuffer, Int32Array, ...), and many type classes that these array objects belong to (IsFloat32Array, IsGObject, IsJSVal, PToJSVal, ...) but it isn't immediately clear how to construct one of these arrays (perhaps with 1, 2, 3, etc, values) without using FFI - which seems to break the goal of jsaddle. Any tips?

In jsaddle-dom there are two createAnswer functions one is generated and does return a RTCSessionDescriptionInit, the other is custom and does a conversion to RTCSessionDescription. The custom one is exported. This is unfortunate for two reasons:

1. the return value of createAnswer is used in setLocalDescription which expects a RTCSessionDescriptionInit.
2. ghcjs-dom only has the generated one, which returns a RTCSessionDescriptionInit. Thus it seems to be incompatible with jsaddle-dom.

I can file a PR for exporting the generated function and maybe even dropping the custom one if this is the way to go. Am I missing something?

On my machine jsaddle-dom takes quite a lot of time to compile.

It usually hangs after this step the most:

Configuring jsaddle-dom-0.9.2.0...
Building jsaddle-dom-0.9.2.0...
Preprocessing library jsaddle-dom-0.9.2.0...
[  1 of 599] Compiling JSDOM.Types      ( src/JSDOM/Types.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/JSDOM/Types.o )

Then the RAM consumption just keeps rising, till around a 2-5GB peak before the modules continue building.

• Any idea what could be the culprit?
• Could it be the case that GHC is having a hard time processing a package with 599 modules?
• Or do other packages with similar module counts compile quicker?
• Is there something relatively fundamental at play here?
• Or could there be some low hanging fruit to speed this up?
• Has there been any efforts to reduce or profile build times so far?

I just ran into an issue where readystatechange being async caused some trouble. Specifically:

1. The XHR changed to readystate 2, then 3, then 4.
2. As a result, 3 callbacks got enqueued
3. Then, all 3 callbacks got processed
4. Since the readystate had already changed to 4, all 3 callbacks saw readystate 4, and all 4 reported that the XHR had just finished.

This behavior doesn't seem right, but I'm not clear on how the decision ought to be made between sync and async for this sort of thing.

Sorry for complaining about old compiler versions… but I get

[  2 of 599] Compiling JSDOM.Types      ( src/JSDOM/Types.hs, dist/build/JSDOM/Types.js_o )

src/JSDOM/Types.hs:1037:9: error:
    • Variable not in scope: (<>) :: t0 -> String -> t1
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Prelude.Compat),
        ‘*>’ (imported from Prelude.Compat),
        ‘<$’ (imported from Prelude.Compat)
     |
1037 |         <> T.unpack destType <> " requested."
     |         ^^

src/JSDOM/Types.hs:1037:30: error:
    • Variable not in scope: (<>) :: t1 -> [Char] -> IO obj'
    • Perhaps you meant one of these:
        ‘<$>’ (imported from Prelude.Compat),
        ‘*>’ (imported from Prelude.Compat),
        ‘<$’ (imported from Prelude.Compat)
     |
1037 |         <> T.unpack destType <> " requested."
     |                              ^^
cabal: Failed to build jsaddle-dom-0.9.3.1 (which is required by
exe:kaleidogen from kaleidogen-0.1). See the build log above for details.

with ghcjs-8.2.

This was broken with #11, which made it work with GHC-8.4, but not GHC-8.2. Maybe you don’t care about GHC-8.2 (fair enough), in that case you could edit the metadata on hackage to tighten the bounds.

Just tested this for nixpkgs.

A build of my project fails now, it seems that jsaddle-dom either needs tighter bounds or (preferably) hide (<>) from Data.Monoid:

src/JSDOM/Types.hs:1038:9: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.Compat.<>’,
                             imported from ‘Prelude.Compat’ at src/JSDOM/Types.hs:956:1-34
                             (and originally defined in ‘Data.Semigroup’)
                          or ‘Data.Monoid.<>’,
                             imported from ‘Data.Monoid’ at src/JSDOM/Types.hs:961:21-24
     |
1038 |         <> T.unpack destType <> " requested."
     |         ^^

https://travis-ci.org/nomeata/kaleidogen/builds/489287621

I just discovered the Web Share API (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share), but it seems it’s not yet covered by jsaddle-dom.

Is this something that jsaddle-dom should, could and maybe will provide ?

There a many examples (most Callbacks and other things) of the following differences between:

jsaddle-dom version:

instance ToJSVal VoidCallback where toJSVal (VoidCallback (Callback r)) = toJSVal r

ghcjs-dom-jsffi version:

instance PToJSVal VoidCallback where pToJSVal (VoidCallback (Callback r)) = r

together with the missing in ghcjs-base

instance ToJsVal PToJSval where toJsVal = return . pToJsVal

this breaks code compatibility between GHC and GHCJS.

I am not sure which parts of the ecosystem should be fixed.

1. Should the above instance added to ghcjs-base?

2. Should one of ghcjs-dom-jsffi and jsaddle-dom be changed to make VoidCallback have the same instances in both?

When I build jsaddle-dom I get the following error:

[  1 of 600] Compiling JSDOM.Types      ( src/JSDOM/Types.hs, dist/build/JSDOM/Types.p_o )
clang-3.7: error: unable to execute command: Killed: 9
clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
clang-3.7: note: diagnostic msg: PLEASE submit a bug report to  and include the crash backtrace, preprocessed source, and associated run script.
clang-3.7: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.7: note: diagnostic msg: /private/var/folders/yw/4lyc2l_n51z601wqjnyc9vvr0000gn/T/nix-build-jsaddle-dom-0.9.1.0.drv-0/ghc_14-d6f02a.c
clang-3.7: note: diagnostic msg: /private/var/folders/yw/4lyc2l_n51z601wqjnyc9vvr0000gn/T/nix-build-jsaddle-dom-0.9.1.0.drv-0/ghc_14-d6f02a.sh
clang-3.7: note: diagnostic msg:

********************

<no location info>: error:
    `cc' failed in phase `C Compiler'. (Exit code: 254)

It sits on the JSDOM.Types module for tens of minutes, possibly more than an hour before failing. I'm running macOS on a machine with 16 gigs of RAM. The fact that I can't build jsaddle-dom on a machine this big seems like a problem. Is it possible to break this module up to make it buildable on normal size systems?

Element.scrollTop is given a 'long' type in the webIDL, but in actuality it can become fractional when display scaling comes into play, according to https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop & in practice, & then it's rounded

This comes up in the generated Haskell code as a rounded Int