Including remote-iserv upstream?
shea at shealevy.com
Sat Jan 14 15:34:50 UTC 2017
Hi Simon, devs,
As part of my work to get TH working when cross-compiling to iOS, I've
developed remote-iserv  (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
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
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
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?
* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the ghc-devs