1. 14 Mar, 2020 1 commit
  2. 28 Feb, 2019 1 commit
    • Moritz Angermann's avatar
      Cleanup iserv/iserv-proxy · f838809f
      Moritz Angermann authored
      This adds trace messages that include the processes name and as such
      make debugging and following the communication easier.
      
      It also adds a note regarding the fwd*Call proxy-communication logic
      between the proxy and the slave.
      
      The proxy will now also poll for 60s to wait for the remote iserv
      to come up. (Alternatively you can start the remote process
      beforehand; and just have iserv-proxy connect to it)
      f838809f
  3. 08 Jun, 2018 1 commit
    • Moritz Angermann's avatar
      Move `iserv` into `utils` and change package name from `iserv-bin` to `iserv` · 6fbe5f27
      Moritz Angermann authored
      This is done for consistency. We usually call the package file the same name the
      folder has.  The move into `utils` is done so that we can move the library into
      `libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
      `iserv.cabal` apart.  This will make building the cross compiler with TH
      simpler, because we can build the library and proxy as separate packages.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, goldfire, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4436
      6fbe5f27
  4. 20 Feb, 2018 1 commit
  5. 15 Feb, 2018 1 commit
    • Moritz Angermann's avatar
      Move `iserv` into `utils` and change package name from `iserv-bin` to `iserv` · 7c173b90
      Moritz Angermann authored
      This is done for consistency. We usually call the package file the same name the
      folder has.  The move into `utils` is done so that we can move the library into
      `libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
      `iserv.cabal` apart.  This will make building the cross compiler with TH
      simpler, because we can build the library and proxy as separate packages.
      
      Reviewers: bgamari, simonmar, goldfire, erikd
      
      Reviewed By: simonmar
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4377
      7c173b90
  6. 11 May, 2017 1 commit
    • Moritz Angermann's avatar
      [iserv] fix loadDLL · 83dcaa8c
      Moritz Angermann authored
      When we load non absolute pathed .so's this usually implies that we expect the
      system to have them in place already, and hence we should not need to ship them.
      Without the absolute path to the library, we are also unable to open and send
      said library.  Thus we'll do library shipping only for libraries with absolute
      paths.
      
      Reviewers: austin, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: simonmar, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3469
      83dcaa8c
  7. 18 Apr, 2017 1 commit
  8. 11 Apr, 2017 1 commit
    • Moritz Angermann's avatar
      Enter iserv-proxy · d4631078
      Moritz Angermann authored
      With the introduction of -fexternal-interpreter we are
      now able to compile template haskell via an extern iserv process.
      
      This however is restricted to the same host, and can therefore
      not be used with crosscompilers where the iserv slave process
      needs to run on a different machine than the cross compiling
      haskell compiler.
      
      This diff breaks up iserv into a library and the iserv-bin binary.
      It also introduces the iserv-proxy, a proxy instance that the
      haskell compiler can talk to, and which forwards the calls
      to the iserv slave on a different machine, as well as providing
      some extra functionarily (sending files that are not available
      on the machine the slave runs on), as well as forwarding from
      the slave to the haskell compiler, when the slave needs to
      interrogate the haskell compiler.
      
      The iserv library now also exports the startSlave function to be
      called by the application that implements the slave on the target.
      
      The simplest such app would probably look something like:
      
      ```
      extern void startServ(bool, const char *);
      
      int main(int argc, char * argv[]) {
        hs_init(NULL, NULL);
        startServ(false,"/tmp");
        while(1);
      }
      ```
      
      Special thanks to Shea Levy for the first draft of the iserv-remote,
      from which I took some inspiration.
      
      The `Buildable` flags are due to ghc-cabal not being able to build
      more than a single target.  Please note that only the stock iserv-bin
      is supposed to be built *with* ghc.  The library and proxy are supposed
      to be built outside of ghc.  Yet I believe that this code should live
      together with iserv.
      
      Reviewers: simonmar, ezyang, goldfire, austin, rwbarton, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: luite, ryantrinkle, shlevy, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3233
      d4631078