1. 27 Jan, 2009 1 commit
  2. 06 Oct, 2008 1 commit
  3. 15 Sep, 2008 1 commit
  4. 31 Jul, 2008 1 commit
  5. 30 Jul, 2008 1 commit
  6. 20 Jul, 2008 1 commit
  7. 11 Jul, 2008 1 commit
  8. 28 May, 2008 1 commit
  9. 03 May, 2008 2 commits
  10. 29 Apr, 2008 1 commit
  11. 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
  12. 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...
  13. 09 Jan, 2008 1 commit
  14. 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.
  15. 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}.
  16. 14 Nov, 2007 1 commit
  17. 04 Sep, 2007 1 commit
  18. 03 Sep, 2007 1 commit
  19. 01 Sep, 2007 1 commit
  20. 09 Aug, 2007 1 commit
  21. 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.
  22. 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
  23. 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.
  24. 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.
  25. 27 Apr, 2007 1 commit
  26. 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.
  27. 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
  28. 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:
  29. 27 Mar, 2007 1 commit
    • Simon Marlow's avatar
      more improvements for #1119 · 075a7bad
      Simon Marlow authored
      When GHCi compiles its code framgents for setting buffering, it wants
      to refer to base:System.IO rather than whatever System.IO is on the
      search path, unfortunately there's no way to do this in source code,
      so to hack around it we set the search path to empty before compiling
      these expressions (not forgetting to flush the finder cache
  30. 14 Jan, 2007 1 commit
  31. 11 Jan, 2007 1 commit
    • mnislaih's avatar
      Added the new :breakpoint continue option · 025733b8
      mnislaih authored
      Previously, when in a breakpoint, :quit was used to continue execution.
      This is not the right thing to do, so this patch restores :quit to its
      original meaning whether or not ghci is in an inferior session.
      The continue behavior is now provided by ":breakpoint continue".
      I added a synonim command in :continue because it is much shorter,
      but this is optional
  32. 08 Jan, 2007 1 commit
  33. 06 Jan, 2007 1 commit
    • mnislaih's avatar
      Reload modules after ':break stop' · c7872114
      mnislaih authored
      This is necessary to revert CAFs. Previously to this patch the user would get a msg "You may need to reload your modules". This patch takes care of that
  34. 11 Dec, 2006 1 commit
  35. 10 Dec, 2006 2 commits
    • mnislaih's avatar
      Dynamic breakpoints in GHCi · 8bc615fd
      mnislaih authored
      This patch adds dynamic breakpoints to GHCi
      There is a new ':breakpoint' command to manage breakpoints.
      GHCi simply uses the breakpoint api functions in ghc-api to install itself as a client.
      The mechanism used by GHCi to keep track of enabled breakpoints is a simple table.
      When a breakpoint is hit, a new interactive session is launched and the bindings in the breakpoint are injected. Some commands are disabled in this sub session
    • mnislaih's avatar
      Split the GHCi monad apart from InteractiveUI, together with some related functions · 8099fc7e
      mnislaih authored
      I found this convenient while I was extending ghci with the debugger. I wanted to put all the debugger stuff in a separate module, but I would need a huge hs-boot file to break the circular dependencies. This option seemed better