Including remote-iserv upstream?

[Shea Levy]

Hi Simon, devs,

As part of my work to get TH working when cross-compiling to iOS, I've
developed remote-iserv [1] (not yet on hackage), a set of libraries for
letting GHC communicate with an external interpreter that may be on
another machine. So far, there are only three additions of note on top
of what the ghci library offers:

1. The remote-iserv protocol has facilities for the host sending
   archives and object files the target doesn't have (dynlibs not yet
   implemented but there's no reason they can't be). This works by
   having the server send back a Bool after a loadObj or loadArchive
   indicating whether it needs the object sent, and then just reading it
   off the Pipe.
2. The remote-iserv lib abstracts over how the Pipe it communicates over
   is obtained. One could imagine e.g. an ssh-based implementation that
   just uses stdin and stdout* for the communication, the implementation
   I've actually tested on is a TCP server advertised over bonjour.
3. There is a protocol version included to address forwards
   compatibility concerns.

As the library currently stands, it works for my use case. However,
there would be a number of benefits if it were included with ghc (and
used for local iserv as well):

1. Reduced code duplication (the server side copies iserv/src/Main.hs
   pretty heavily)
2. Reduced overhead keeping up to date with iserv protocol changes
3. No need for an extra client-side process, GHC can just open the Pipe
   itself
4. Proper library distribution in the cross-compiling case. The client
   needs to be linked with the ghci lib built by the stage0 compiler, as
   it runs on the build machine, while the server needs to be linked
   with the ghci lib built by the stage1 compiler. With a distribution
   created by 'make install', we only get the ghci lib for the
   target. Currently, I'm working around this by just using the ghci lib
   of the bootstrap compiler, which in my case is built from the same
   source checkout, but of course this isn't correct. If these libs were
   upstream, we'd only need one version of the client lib exposed and
   one version of the server lib exposed and could have them be for the
   build machine and the target, respectively
5. Better haskell hackers than I invested in the code ;)

Thoughts on this? Would this be welcome upstream in some form?

Thanks,
Shea

* Note that, in the general case, having the server process's stdio be
  the same as the compiler's (as we have in the local-iserv case) is not
  possible. Future work includes adding something to the protocol to
  allow forwarding stdio over the protocol pipe, to make GHCi usable
  without watching the *server*'s console.

[1]: https://github.com/obsidiansystems/remote-iserv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170114/e9338b1f/attachment.sig>