summaryrefslogtreecommitdiff
path: root/compiler/main/InteractiveEval.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
* comments onlySimon Marlow2007-08-311-1/+4
| | | | | I had planned to do findEnclosingDecl a different way, so add a ToDo as a reminder.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+7
|
* Warning policePepe Iborra2007-08-291-10/+2
|
* Use a version of obtainTerm that takes a max depth boundPepe Iborra2007-08-271-3/+8
| | | | when printing the contents of binding at a breakpoint
* Be more careful when calculating the enclosing top level declaration of a ↵Pepe Iborra2007-08-271-7/+10
| | | | srcspan
* Print contents of bindings when stopping at a breakpointPepe Iborra2007-08-261-1/+1
|
* A partial attempt to improve :stepoverPepe Iborra2007-08-241-15/+0
| | | | | | | | | | | | | | 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"
* Build fix: modBreaks -> modBreaks_decls modbreaksMichael D. Adams2007-08-221-1/+1
|
* A partial attempt to improve :stepoverPepe Iborra2007-08-221-0/+15
| | | | | | | | | | | | | | 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"
* Small rearrangementsPepe Iborra2007-08-211-2/+3
|
* Teach :history to show the name of the enclosing declaration Pepe Iborra2007-08-151-13/+42
| | | | | | together with src locs Purely for convenience and user friendliness
* A new :stepover command for the debuggerPepe Iborra2007-08-091-0/+4
| | | | | | | | | | | | | | | | | | | Step from statement to statement without leaving the block. Tries to do the sensible thing when used on expressions. The idea is to: 1 - Step to the next breakpoint and examine the srcloc 2 - If it is contained in the same statement block as we were, then stop and give control to the user, else continue to the next breakpoint 3 - Repeat from 1. If we reach the end of the statement block, i.e. no more ticks in this expression after the current one, then step normally. Replace statement block with 'declaration block' (of an expression) in the pseudo algo. above. Let's see how well this idea works in practice...
* :step does not delete the :history anymore, and now it logs like :tracePepe Iborra2007-08-091-4/+10
|
* In GHCi, filter instances by what is in scope, not just by what is in scope ↵simonpj@microsoft.com2007-08-041-1/+22
| | | | | | | | | | | | unqualified Trac #1581 was doing too much filtering; it even filtered out intances defined in this very module! The new rule shows more instances, but hopefully not to many. Furthermore I have moved the filtering out of TcRnDriver (where it does not belong) to InteractiveEval. And I've added a note to the documentation.
* Automatic RTTI for ghci bindings Pepe Iborra2007-07-141-14/+45
| | | | | | | | | | With this patch, ghci runs rtti (bounded in the term treewith a max. depth of 10) automatically after evaluating any expression in the interactive env. In addition, a rtti step is performed on the local bindings in a breakpoint, before returning control to the user Let's see how well this works in practice
* Ask for a HscEnv instead of a Session in InteractiveEval.obtainTermPepe Iborra2007-07-111-4/+4
| | | | This does a better job of showing that obtainTerm does not alter the Session
* FIX: break011. Simon Marlow2007-05-181-6/+14
| | | | | | Reset the exception flag before re-throwing the exception unless it was "Interrupted". This avoids needing the double :continue for ordinary exceptions, but still lets us break on ^C.
* rethrow exceptions in sandboxIOSimon Marlow2007-05-171-1/+9
| | | | This gives us a chance to catch asynchronous exceptions (e.g. ^C) and break.
* eliminate warningsSimon Marlow2007-05-171-2/+1
|
* GHCi debugger: new flag -fbreak-on-exceptionSimon Marlow2007-05-151-56/+78
| | | | | | | | | | When -fbreak-on-exception is set, an exception will cause GHCi to suspend the current computation and return to the prompt, where the history of the current evaluation can be inspected (if we are in :trace). This isn't on by default, because the behaviour could be confusing: for example, ^C will cause a breakpoint. It can be very useful for finding the cause of a "head []" or a "fromJust Nothing", though.
* result_id should be a GlobalIdSimon Marlow2007-05-141-1/+2
|
* Store a SrcSpan instead of a SrcLoc inside a NameSimon Marlow2007-05-111-2/+2
| | | | This has been a long-standing ToDo.
* improve :abandon, it wasn't properly terminating the computation (see comments)Simon Marlow2007-05-111-3/+19
|
* FIX: Linker.getHValue should be linking in any dependencies it requiresSimon Marlow2007-05-091-5/+3
| | | | | Otherwise :print only works for local identifiers, not global ones. In fact it was silently failing, so I fixed that too.
* Use a primop for getting the fields of the AP_STACK rather than an FFI callSimon Marlow2007-05-031-17/+24
| | | | | | This means we can avoid some StablePtrs, and also catch cases where the AP_STACK has been evaluated (this can happen with :history, see the hist001 test).
* Add history/trace functionality to the GHCi debuggerSimon Marlow2007-05-031-85/+168
| | | | | | | | 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.
* Refactoring, tidyup and improve layeringSimon Marlow2007-05-021-0/+688
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.
View Lorry Controller Status