1. 19 Apr, 2007 1 commit
  2. 18 Apr, 2007 1 commit
  3. 19 Apr, 2007 2 commits
  4. 14 Apr, 2007 1 commit
  5. 30 Mar, 2007 1 commit
  6. 18 Apr, 2007 12 commits
  7. 17 Apr, 2007 1 commit
  8. 10 Apr, 2007 1 commit
  9. 17 Apr, 2007 2 commits
    • Simon Marlow's avatar
      Re-working of the breakpoint support · cdce6477
      Simon Marlow authored
      This is the result of Bernie Pope's internship work at MSR Cambridge,
      with some subsequent improvements by me.  The main plan was to
      
       (a) Reduce the overhead for breakpoints, so we could enable 
           the feature by default without incurrent a significant penalty
       (b) Scatter more breakpoint sites throughout the code
      
      Currently we can set a breakpoint on almost any subexpression, and the
      overhead is around 1.5x slower than normal GHCi.  I hope to be able to
      get this down further and/or allow breakpoints to be turned off.
      
      This patch also fixes up :print following the recent changes to
      constructor info tables.  (most of the :print tests now pass)
      
      We now support single-stepping, which just enables all breakpoints.
      
        :step <expr>     executes <expr> with single-stepping turned on
        :step            single-steps from the current breakpoint
      
      The mechanism is quite different to the previous implementation.  We
      share code with the HPC (haskell program coverage) implementation now.
      The coverage pass annotates source code with "tick" locations which
      are tracked by the coverage tool.  In GHCi, each "tick" becomes a
      potential breakpoint location.
      
      Previously breakpoints were compiled into code that magically invoked
      a nested instance of GHCi.  Now, a breakpoint causes the current
      thread to block and control is returned to GHCi.
      
      See the wiki page for more details and the current ToDo list:
      
        http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
      cdce6477
    • Simon Marlow's avatar
  10. 16 Apr, 2007 6 commits
  11. 14 Apr, 2007 1 commit
  12. 12 Apr, 2007 2 commits
  13. 11 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Rationalise GhcMode, HscTarget and GhcLink · 3c22606b
      Simon Marlow authored
      This patch cleans up the GHC API, and adds some functionality: we can
      now compile to object code inside GHCi.
      
      Previously we had:
      
        data GhcMode
          = BatchCompile
          | Interactive
          | OneShot
          | JustTypecheck
          | MkDepend
        
        data HscTarget
          = HscC
          | HscAsm
          | HscJava
          | HscInterpreted
          | HscNothing
      
      There was redundancy here; if GhcMode is Interactive, then only
      HscInterpreted makes sense, and JustTypecheck required HscNothing.
      Now we have:
      
        data GhcMode
          = CompManager       -- ^ --make, GHCi, etc.
          | OneShot           -- ^ ghc -c Foo.hs
          | MkDepend          -- ^ ghc -M, see Finder for why we need this
      
      and HscTarget remains as before.
      
      Previously GhcLink looked like this:
      
        data GhcLink = NoLink | StaticLink
      
      Now we have:
      
        data GhcLink = NoLink | LinkBinary | LinkInMemory
      
      The idea being that you can have an HscTarget of HscAsm (for example)
      and still link in memory.
      
      There are two new flags:
      
        -fobject-code selects object code as the target (selects
                      either -fasm or -fvia-C, whichever is the default)
                      This can be usd with ':set' in GHCi, or on the command line.
      
        -fbyte-code   sets byte-code as the target.  Only works in GHCi.
                      One day maybe this could save the byte code in a file
                      when used outside GHCi.
      
        (names chosen for consistency with -fno-code).
      
      Changes to the GHC API: newSession no longer takes the GhcMode
      argument.  The GhcMode defaults to CompManager, which is usually what
      you want.  To do JustTypecheck now, just set hscTarget to HscNothing.
      3c22606b
  14. 10 Apr, 2007 1 commit
    • Ian Lynagh's avatar
      Don't use regexps in the GHC sources · 6c53f40f
      Ian Lynagh authored
      3 small regexps were responsible for pulling 3 packages into core-packages.
      
      The new code should also do a better job of hiding
      "call-clobbered register used" warnings.
      6c53f40f
  15. 13 Nov, 2006 1 commit
    • Aaron Tomb's avatar
      Fix external core syntax (though not full compilation) · de777ba4
      Aaron Tomb authored
      This patch updates the External Core creator, pretty-printer, and parser to
      agree on a concrete syntax for External Core, including the constructs
      required by the change to System FC. Code to create valid ASTs from External
      Core files will come later, as will bits for renaming, typechecking, and
      desugaring.
      de777ba4
  16. 06 Apr, 2007 1 commit
  17. 04 Apr, 2007 3 commits
  18. 03 Apr, 2007 1 commit
  19. 02 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Make type-tidying work for coercion variables · f2b02ce8
      simonpj@microsoft.com authored
      When tidying a TyVar binder, we must tidy its kind if it's a coercion
      variable!  I had forgotten to do this, which is a serious bug.  As a
      result some more complicated programs were getting a Lint error when
      reading in interface files.  Score one for Core Lint!
      
      f2b02ce8