1. 08 Nov, 2007 1 commit
  2. 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
  3. 14 Nov, 2007 2 commits
  4. 13 Nov, 2007 1 commit
    • mnislaih's avatar
      GHCi debugger: added a new flag, -fno-print-binding-contents · 7bd518dd
      mnislaih authored
      The contents of bindings show at breakpoints and by :show bindings
      is rendered using the same printer that :print uses.
      But sometimes the output it gives spans over too many lines and the
      user may want to be able to disable it.
      7bd518dd
  5. 06 Oct, 2007 1 commit
  6. 07 Nov, 2007 5 commits
    • Simon Marlow's avatar
      FIX BUILD · 427f3443
      Simon Marlow authored
      Sorry, should have pushed with previous batch of changes.
      427f3443
    • Simon Marlow's avatar
      e82fcf24
    • Simon Marlow's avatar
      FIX #1765, #1766 · da4dda13
      Simon Marlow authored
      - :def! now overwrites a previous command with the same name
      - :def on its own lists the defined macros
      - ":undef f g" undefines both f and g
      da4dda13
    • Simon Marlow's avatar
      #1617: Add :browse! and various other additions to GHCi · 806ab633
      Simon Marlow authored
         
        - :browse!
          a variant of :browse that lists children separately,
          not in context, and gives import qualifiers in comments
      
      SimonM: I also added sorting by source location for interpreted
      modules in :browse, and alphabetic sorting by name otherwise.  For
      :browse *M, the locally-defined names come before the external ones.
      
        - :{ ..lines.. :} (multiline commands)
          allow existing commands to be spread over multiple lines
          to improve readability, both interactively and in .ghci
          (includes a refactoring that unifies the previous three
          command loops into one, runCommands, fed from cmdqueue,
          file, or readline)
      
        - :set
            now shows GHCi-specific flag settings (printing/
            debugger), as well as non-language dynamic flag 
            settings
          :show languages
            show active language flags
          :show packages
            show active package flags as well as implicitly 
            loaded packages
      806ab633
    • Simon Marlow's avatar
  7. 19 Oct, 2007 1 commit
  8. 17 Oct, 2007 1 commit
  9. 10 Oct, 2007 1 commit
  10. 03 Oct, 2007 2 commits
  11. 27 Sep, 2007 1 commit
  12. 26 Sep, 2007 1 commit
  13. 24 Sep, 2007 1 commit
  14. 18 Sep, 2007 1 commit
  15. 11 Sep, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Define and use PprTyThing.pprTypeForUser · 046feb1e
      simonpj@microsoft.com authored
      When printing types for the user, the interactive UI often wants to
      leave foralls implicit.  But then (as Claus points out) we need to be
      careful about name capture. For example with this source program
      
      	class C a b where
      	  op :: forall a. a -> b
      
      we were erroneously displaying the class in GHCi (with suppressed
      foralls) thus:
      
      	class C a b where
      	  op :: a -> b
      
      which is utterly wrong. 
      
      This patch fixes the problem, removes GHC.dropForAlls (which is dangerous),
      and instead supplies PprTyThing.pprTypeForUser, which does the right thing.
      
      046feb1e
  16. 10 Sep, 2007 2 commits
    • mnislaih's avatar
      Nicer GHCi debugger underlining · b59ce959
      mnislaih authored
      Improved the underlining of blocks.
      With this patch it does:
      
      Stopped at break020.hs:(6,20)-(7,29)
      _result :: t1 () = _
      5  
                           vv
      6  in_another_decl _ = do line1 0
      7                         line2 0
                                       ^^
      8  
      
      Instead of
      
      Stopped at break020.hs:(6,20)-(7,29)
      _result :: t1 () = _
      5  
      6  in_another_decl _ = do line1 0
                             ^^
      7                         line2 0
                                       ^^
      8  
      
      b59ce959
    • mnislaih's avatar
      FIX #1669 (GHCi debugger underlining is in the wrong place) · 5ac833ec
      mnislaih authored
      We weren't taking into account the offset added by the line numbers:
      
      Stopped at break020.hs:10:2-8
      _result :: IO () = _
      9  main = do
      10    line1 0
           ^^^^^^^
      11    line2 0
      
      
      This patch adjusts that 
      5ac833ec
  17. 06 Sep, 2007 1 commit
  18. 04 Sep, 2007 2 commits
  19. 03 Sep, 2007 1 commit
  20. 01 Sep, 2007 1 commit
  21. 29 Aug, 2007 1 commit
  22. 27 Aug, 2007 2 commits
    • mnislaih's avatar
      :stepover ---> :steplocal, :stepmodule · 3240dc3b
      mnislaih authored
       :stepover is declared a failed experiment. 
      :steplocal steps only on ticks contained in the current
      top level declaration. 
      :stepmodule steps only on ticks contained on the current
       module. 
      The current top level declaration and module are with
       respect to the breakpoint we are stopped on.
      
       The main reason for the failure of :stepover
      (apart from lacking a lexical call stack of course)
      is that it fails to detect when the expression being 
      evaluated is "complete", i.e. there are no ticks left in it.
      My assumption of the rightmost tick as the "last one",
      signaling that the expression is completely evaluated,
      is not true at all under laziness. 
      This assumption was key in the implementation of :stepover.
       
      3240dc3b
    • mnislaih's avatar
      Use a version of obtainTerm that takes a max depth bound · a27d12f0
      mnislaih authored
      when printing the contents of binding at a breakpoint
      a27d12f0
  23. 26 Aug, 2007 1 commit
  24. 24 Aug, 2007 1 commit
    • mnislaih's avatar
      A partial attempt to improve :stepover · 99794f66
      mnislaih authored
        
        With this patch, :stepover can effectively appear to step over recursive calls and 
        calls to locally bound functions (in a where clause).
        
        However, when we run out of ticks in the current expression, 
        the illusion vanishes and laziness brings us to the body of the last function 
        we "stepped over". 
        This is not desired at all, it is potentially very confusing.
        As a countermeasure, when this happens :stepover emits a warning
      
           "Warning: no more breakpoints in this function body, switching to :step"  
      99794f66
  25. 22 Aug, 2007 3 commits
    • mnislaih's avatar
      Better document :stepover and its limitations · f17c76a4
      mnislaih authored
      :stepover only works lexically locally, in the context of the 
      current expression. I have tried to make this point clear
      in the users guide with an example. 
      f17c76a4
    • mnislaih's avatar
      A partial attempt to improve :stepover · 24ee7541
      mnislaih authored
        
        With this patch, :stepover can effectively appear to step over recursive calls and 
        calls to locally bound functions (in a where clause).
        
        However, when we run out of ticks in the current expression, 
        the illusion vanishes and laziness brings us to the body of the last function 
        we "stepped over". 
        This is not desired at all, it is potentially very confusing.
        As a countermeasure, when this happens :stepover emits a warning
      
           "Warning: no more breakpoints in this function body, switching to :step"  
      24ee7541
    • mnislaih's avatar
      Better document :stepover and its limitations · 8fcfc8d6
      mnislaih authored
      :stepover only works lexically locally, in the context of the 
      current expression. I have tried to make this point clear
      in the users guide with an example. 
      8fcfc8d6
  26. 21 Aug, 2007 1 commit
  27. 20 Aug, 2007 1 commit
  28. 17 Aug, 2007 1 commit
  29. 16 Aug, 2007 1 commit