Possible to remove dependency on ghcjs-base to compile on GHC?

[erikkaplun]

Is it feasible to remove the dependency on ghcjs-base, or make it optional? So that diagrams-ghcjs could also compile natively on GHC, to be used with e.g. webkitgtk.

[bergey]

It is likely possible to use ghcjs-dom to abstract over GHCJS / webkit. I haven't looked at the canvas modules of ghcjs-dom closely, though. I'd be happy to get a PR.

[mgsloan]

Seems feasible to implement such a thing based on diagrams-canvas

[bergey]

@mgsloan How would that work? Are there libraries that provide access to DOM APIs that abstract over kansas-comet and GHCJS? CPP to switch between Diagrams Backends is easy, but I assume people want to combine diagrams-ghcjs with other libraries for interactivity.

[mgsloan]

Hmm, good point!

[erikkaplun]

What exactly in diagrams-ghcjs depends on ghcjs-base/GHCJS that it cannot be made optional? It can be on by default but there could be a flag that, via CPP, eliminates the dependency on GHCJS, if it's still possible to make diagrams-ghcjs do what it does without GHCJS, at least to a useful extent.

[bergey]

diagrams-ghcjs renders to an HTML canvas. ghcjs-base provides the the Canvas interface, via the JS FFI. Any alternative would need to provide a compatible Canvas interface.

Can you explain what you are trying to do? Maybe I can suggest a way to do it with the existing Diagrams Backends.

[erikkaplun]

I think these should explain what I'm trying to achieve:

• http://stackoverflow.com/questions/34267599/accessing-the-webkit-api-from-haskell-via-something-other-than-webkitgtk
• https://bugs.webkit.org/show_bug.cgi?id=152250

I guess these also explain why it's not possible to compile diagrams-ghcjs on GHC currently — there simply is no obvious means to access the WebKit API other than via WebKitGTK, which however doesn't expose the HTML5 Canvas API.

As a work around, I guess I could just use diagrams-canvas to generate a sequece of JavaScript "commands" to pipe into the canvas inside a WebKitGTK instance, but I think that will need to involve CPP.

[erikkaplun]

I wondering about the feasibility of writing a dummy fork of diagrams-ghcjs where all GHCJS based functions were replaced with identical looking stubs. Or, better yet, a version of ghcjs-base itself for GHC, with possibly undefined stubs left in. Like how ghcjs-dom compiles on both and just links against webclient3 on native GHC.

Without this, any users of e.g. ghc-mod with diagrams-ghcjs won't be able to benefit from e.g. typechecking in the editor.

[bergey]

I think the stub library you describe is feasible. It seems annoying to maintain, and likely to confuse people, but that's just my opinion.

A typical Diagrams program has lots of code that uses Diagrams, and only a little that uses the particular Backend. The easiest way to let the whole program typecheck with GHC is probably to CPP-guard the diagrams-ghcjs bits. Something like:

dia :: Diagram B V2 Double
dia = circle 1 # fc blue

renderCanvas :: IO ()
#ifdef GHCJS
renderCanvas = do
  c <- getCanvasContext -- not a real function
  renderDia D.Canvas (CanvasOptions (dims2D 200 200) c)
#else
renderCanvas = return ()

type B = NullBackend 
-- diagrams-ghcjs provides type B = D.Canvas
#endif

The `Diagram B V2 Double` can be typechecked with just `diagrams-lib`.

[hamishmack]

@eallik the last few weekends I have been working on a code generator for jsaddle-dom that will hopefully plug a lot of the gaps in the native version of ghcjs-dom. Instead of using the webkitgtk dom C functions it calls the JavaScriptCore C functions via jsaddle and webkitgtk3-javascriptcore. I am trying to keep the interface the same as ghcjs-dom. It also should make it easier to use JavaScript libraries in native apps.

If it performs well enough we can make it the default implementation for ghcjs-dom on ghc.

[erikkaplun]

That's awesome! Where would it render though? Still webkitgtk? Or headless?
Would it make diagrams-ghcjs not only compile on GHC but also run on GHC?
I'm very curious now...
On Tue, 15 Dec 2015 at 02:36, Hamish Mackenzie [email protected]
wrote:

@eallik https://github.com/eallik the last few weekends I have been
working on a code generator for jsaddle-dom that will hopefully plug a lot
of the gaps in the native version of ghcjs-dom. Instead of using the
webkitgtk dom C functions it calls the JavaScriptCore C functions via
jsaddle and webkitgtk3-javascriptcore. I am trying to keep the interface
the same as ghcjs-dom. It also should make it easier to use JavaScript
libraries in native apps.

If it performs well enough we can make it the default implementation for
ghcjs-dom on ghc.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[hamishmack]

It will render using webkitgtk so we should be able to get diagrams-ghcjs fully working in ghc with webkitgtk rendering.

diagrams-ghcjs uses ghcjs-base JavaScript.Web.Canvas and not ghcjs-dom CanvasRenderingContext2D. So we will need to resolve that somehow (perhaps a JavaScript.Web.Canvas compatibility layer).

[erikkaplun]

Sounds exactly perfect.

Currently, that type in ghcjs-dom maps to nothing on GHC, because for some
reason WebKitGTK does not expose the full Canvas API of WebKit.

Do you intend to reproduce the full Canvas API via javascriptcore, so that
instead of going via the C API, you make the calls via JavaScript sent into
the WebKit instance, so you liberate yourself from whatever the WebKitGTK
folks have decided to expose or not?
On Tue, 15 Dec 2015 at 04:38, Hamish Mackenzie [email protected]
wrote:

It will render using webkitgtk so we should be able to get diagrams-ghcjs
fully working in ghc with webkitgtk rendering.

diagrams-ghcjs uses ghcjs-base JavaScript.Web.Canvas
https://github.com/ghcjs/ghcjs-base/tree/master/JavaScript/Web/Canvas
and not ghcjs-dom CanvasRenderingContext2D
https://github.com/ghcjs/ghcjs-dom/blob/master/src/GHCJS/DOM/JSFFI/Generated/CanvasRenderingContext2D.hs.
So we will need to resolve that somehow (perhaps a JavaScript.Web.Canvas
compatibility layer).

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[hamishmack]

That is the plan. The interface will be complete, but some stuff may not work at run time (for instance I do not think webkitgtk comes with WebDB support).

[bergey]

@hamishmack This sounds great. I'm happy to port diagrams-ghcjs over to ghcjs-dom if you think that's the way to go.

[erikkaplun]

@hamishmack: I'm thinking could it make sense to simply port parts of ghcjs-base itself instead of adding a "switching" layer into ghcjs-dom? Ideally all GHCJS code could run identically on WebKitGTK and JavaScriptCore when compiled with GHC, unless I'm missing something crucial.

Currently GHCJS is really transmogrification plus libraries, but it could be just transmogrification, and the libraries could be cross platform and usable for any HTML/DOM/JS/WebKit/whatnot project, GHC or GHCJS. All this would also make sense even more should GHCJS be merged into GHC.

[erikkaplun]

If ghcjs-base were to be ported (and if it's feasible at all), things like ghcjs-jquery could also be run on GHC. Or any other JS library GHCJS bindings, I guess, assuming they all depend on ghcjs-base.