1. 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
  2. 19 Apr, 2018 1 commit
  3. 20 Feb, 2018 1 commit
  4. 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
  5. 04 Dec, 2017 1 commit
  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
  9. 10 Mar, 2017 1 commit
  10. 09 Mar, 2017 2 commits
  11. 31 Aug, 2016 1 commit
  12. 27 Jan, 2016 1 commit
    • Tamar Christina's avatar
      Enable RemoteGHCi on Windows · 44a5d51a
      Tamar Christina authored
      Makes the needed changes to make RemoteGHCi work on Windows.
      The approach passes OS Handles areound instead of the Posix Fd
      as on Linux.
      
      The reason is that I could not find any real documentation about
      the behaviour of Windows w.r.t inheritance and Posix FDs.
      
      The implementation with Fd did not seem to be able to find the Fd
      in the child process. Instead I'm using the much better documented
      approach of passing inheriting handles.
      
      This requires a small modification to the `process` library.
      https://github.com/haskell/process/pull/52
      
      Test Plan: ./validate On Windows x86_64
      
      Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
      
      Reviewed By: simonmar
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1836
      
      GHC Trac Issues: #11100
      44a5d51a
  13. 30 Dec, 2015 2 commits
  14. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  15. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a