1. 09 Jul, 2010 1 commit
  2. 05 Jul, 2010 1 commit
  3. 25 Jun, 2010 1 commit
  4. 21 Oct, 2009 1 commit
  5. 18 Sep, 2009 1 commit
  6. 06 Jul, 2009 1 commit
  7. 01 Jul, 2009 1 commit
  8. 29 May, 2009 1 commit
  9. 29 Apr, 2009 1 commit
  10. 22 Feb, 2009 1 commit
  11. 27 Jan, 2009 1 commit
  12. 06 Oct, 2008 1 commit
  13. 15 Sep, 2008 1 commit
  14. 31 Jul, 2008 1 commit
  15. 30 Jul, 2008 1 commit
  16. 20 Jul, 2008 1 commit
  17. 11 Jul, 2008 1 commit
  18. 28 May, 2008 1 commit
  19. 03 May, 2008 2 commits
  20. 29 Apr, 2008 1 commit
  21. 05 Apr, 2008 1 commit
    • mnislaih's avatar
      Virtualize the cwd in GHCi · 24f608a8
      mnislaih authored
      This fixes the issue where :list would stop working if the
      program being debugged side-effected the working directory,
      and should prevent other similar issues
      24f608a8
  22. 21 Jan, 2008 1 commit
    • Simon Marlow's avatar
      FIX #2049, another problem with the module context on :reload · eea143f8
      Simon Marlow authored
      The previous attempt to fix this (#1873, #1360) left a problem that
      occurred when the first :load of the program failed (#2049).  
      
      Now I've implemented a different strategy: between :loads, we remember
      all the :module commands, and just replay them after a :reload.  This
      is in addition to remembering all the package modules added with
      :module, which is orthogonal.
      
      This approach is simpler than the previous one, and seems to do the
      right thing in all the cases I could think of.  Let's hope this is the
      last bug in this series...
      eea143f8
  23. 09 Jan, 2008 1 commit
  24. 25 Nov, 2007 1 commit
    • Ian Lynagh's avatar
      MERGED: Make ":" in GHCi repeat the last command · d2b3daa3
      Ian Lynagh authored
      Ian Lynagh <igloo@earth.li>**20071124231857
       It used to be a synonym for ":r" in 6.6.1, but this wasn't documented or
       known about by the developers. In 6.8.1 it was accidentally broken.
       This patch brings it back, but as "repeat the last command", similar to
       pressing enter in gdb. This is almost as good for people who want it to
       reload, and means that it can also be used to repeat commands like :step.
      d2b3daa3
  25. 16 Nov, 2007 1 commit
    • Simon Marlow's avatar
      Attempt at fixing #1873, #1360 · 037aa382
      Simon Marlow authored
      I think I figured out a reasonable way to manage the GHCi context,
      comments welcome.
      
      Rule 1: external package modules in the context are persistent.  That
      is, when you say 'import Data.Maybe' it survives over :load, :add,
      :reload and :cd.
      
      Rule 2: :load and :add remove all home-package modules from the
      context and add the rightmost target, as a *-module if possible.  This
      is as before, and makes sense for :load because we're starting a new
      program; the old home-package modules don't make sense any more.  For
      :add, it usually does what you want, because the new target will
      become the context.
      
      Rule 3: any modules from the context that fail to load during a
      :reload are remembered, and re-added to the context at the next
      successful :reload.
      
      Claus' suggestion about adding the "remembered" modules to the prompt
      prefixed with a ! is implemented but commented out.  I couldn't
      decide whether it was useful or confusing.
      
      One difference that people might notice is that after a :reload where
      there were errors, GHCi would previously dump you in the most recent
      module that it loaded.  Now it dumps you in whatever subset of the
      current context still makes sense, and in the common case that will
      probably be {Prelude}.
      037aa382
  26. 14 Nov, 2007 1 commit
  27. 04 Sep, 2007 1 commit
  28. 03 Sep, 2007 1 commit
  29. 01 Sep, 2007 1 commit
  30. 09 Aug, 2007 1 commit
  31. 11 May, 2007 1 commit
    • Simon Marlow's avatar
      Support for adding custom commands to an individual breakpoint · ae2b9180
      Simon Marlow authored
        :set stop N <cmd>
      
      runs <cmd> when breakpoint N is hit.  Note that the command to run
      might be a macro (defined with :def), and the macro can invoke
      :continue, so it is now possible to do clever things like conditional
      breakpoints, or ignoring the next K hits of a breakpoint.
      ae2b9180
  32. 10 May, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1321: problems with accessing the interpreter's Handles · 3211a6a0
      Simon Marlow authored
      I've had to redo the way we turn off buffering and flush the
      stdin/stdout/stderr Handles in the dynamically-loaded base package.
      Compiling the expression "hSetBuffering stdout NoBuffering" and then
      re-using the compiled expression didn't work sometimes (see comments
      for details).  Now, I'm explicitly looking up the address the stdout
      closure and re-using that.  It should be more robust, if somewhat
      unclean.
      3211a6a0
  33. 03 May, 2007 1 commit
    • Simon Marlow's avatar
      Add history/trace functionality to the GHCi debugger · e1b89960
      Simon Marlow authored
      The debugger can now log each step of the evaluation without actually
      stopping, keeping a history of the recent steps (currently 50).  When
      a (real) breakpoint is hit, you can examine previous steps in the
      history (and their free variables) using the :history, :back and
      :forward commands.
      e1b89960
  34. 02 May, 2007 1 commit
    • Simon Marlow's avatar
      Refactoring, tidyup and improve layering · 86bec429
      Simon Marlow authored
      The stack of breakpoint resume contexts is now part of the
      InteractiveContext and managed by the GHC API.  This prevents misuse
      of the resume context by the client (e.g. resuming a breakpoint that
      isn't the topmost, which would lead to a confused IC at the least).
      
      I changed the TypeEnv in the IC to a [Id].  It only contained Ids
      anyway, and this allows us to have shadowing, which removes an ugly
      and annoying restriction.
      
      The parts of the GHC API which deal with interactive evaluation are
      now in a module of their own, InteractiveEval.
      86bec429
  35. 27 Apr, 2007 1 commit
  36. 19 Apr, 2007 1 commit
    • Simon Marlow's avatar
      More debugger improvements · ed1f16f4
      Simon Marlow authored
      ":list" shows the code around the current breakpoint.  Also it
      highlights the current expression in bold (the bold/unbold codes are
      hardwired to the ANSI codes right now, I'll provide a way to change
      them later).
      
      ":set stop <cmd>" causes <cmd> to be run each time we stop at a
      breakpoint.  In particular, ":set stop :list" is particularly useful.
      ed1f16f4
  37. 18 Apr, 2007 2 commits
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      Various cleanups and improvements to the breakpoint support · 38e7ac3f
      Simon Marlow authored
        - move parts of the debugger implementation below the GHC API where
          they belong.  There is still more in Debugger that violates the
          layering, hopefully I'll get to that later.
      
        - instead of returning an IO action from runStmt for resuming,
          return a ResumeHandle that is passed to GHC.resume.
      
        - breakpoints now return [Name] which is displayed in the same
          way as when a binding statement is executed.
      
        - :load, :add, :reload now clear the active breakpoints and context
      
        - :break gives a sensible error when used on a non-interpreted module
      
        - export breakpoint-related types from GHC
      
        - remove a bunch of layer-violating imports from InteractiveUI
      
        - remove some more vestiges of the old breakpoint code (topLevel in
          the GHCi state).
      
        - remove TickTree and use a simple array instead, cached per module
      38e7ac3f
  38. 17 Apr, 2007 1 commit
    • 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