<div dir="ltr">Absolutely, let's get this code upstream.  Just put it up on Phabricator and I'll be happy to review.<div><br></div><div>I recall that we wanted to split up the ghci lib into modules that are compiled with stage0 (the client) and modules compiled with stage1 (the server).  Is that a part of your plans?  I think it would be a good cleanup.<br><div><br></div><div>Cheers</div><div>Simon</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 January 2017 at 15:34, Shea Levy <span dir="ltr"><<a href="mailto:shea@shealevy.com" target="_blank">shea@shealevy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Simon, devs,<br>
<br>
As part of my work to get TH working when cross-compiling to iOS, I've<br>
developed remote-iserv [1] (not yet on hackage), a set of libraries for<br>
letting GHC communicate with an external interpreter that may be on<br>
another machine. So far, there are only three additions of note on top<br>
of what the ghci library offers:<br>
<br>
1. The remote-iserv protocol has facilities for the host sending<br>
   archives and object files the target doesn't have (dynlibs not yet<br>
   implemented but there's no reason they can't be). This works by<br>
   having the server send back a Bool after a loadObj or loadArchive<br>
   indicating whether it needs the object sent, and then just reading it<br>
   off the Pipe.<br>
2. The remote-iserv lib abstracts over how the Pipe it communicates over<br>
   is obtained. One could imagine e.g. an ssh-based implementation that<br>
   just uses stdin and stdout* for the communication, the implementation<br>
   I've actually tested on is a TCP server advertised over bonjour.<br>
3. There is a protocol version included to address forwards<br>
   compatibility concerns.<br>
<br>
As the library currently stands, it works for my use case. However,<br>
there would be a number of benefits if it were included with ghc (and<br>
used for local iserv as well):<br>
<br>
1. Reduced code duplication (the server side copies iserv/src/Main.hs<br>
   pretty heavily)<br>
2. Reduced overhead keeping up to date with iserv protocol changes<br>
3. No need for an extra client-side process, GHC can just open the Pipe<br>
   itself<br>
4. Proper library distribution in the cross-compiling case. The client<br>
   needs to be linked with the ghci lib built by the stage0 compiler, as<br>
   it runs on the build machine, while the server needs to be linked<br>
   with the ghci lib built by the stage1 compiler. With a distribution<br>
   created by 'make install', we only get the ghci lib for the<br>
   target. Currently, I'm working around this by just using the ghci lib<br>
   of the bootstrap compiler, which in my case is built from the same<br>
   source checkout, but of course this isn't correct. If these libs were<br>
   upstream, we'd only need one version of the client lib exposed and<br>
   one version of the server lib exposed and could have them be for the<br>
   build machine and the target, respectively<br>
5. Better haskell hackers than I invested in the code ;)<br>
<br>
Thoughts on this? Would this be welcome upstream in some form?<br>
<br>
Thanks,<br>
Shea<br>
<br>
* Note that, in the general case, having the server process's stdio be<br>
  the same as the compiler's (as we have in the local-iserv case) is not<br>
  possible. Future work includes adding something to the protocol to<br>
  allow forwarding stdio over the protocol pipe, to make GHCi usable<br>
  without watching the *server*'s console.<br>
<br>
[1]: <a href="https://github.com/obsidiansystems/remote-iserv" rel="noreferrer" target="_blank">https://github.com/<wbr>obsidiansystems/remote-iserv</a><br>
</blockquote></div><br></div>