Isaac Dupree wrote:
Simon Marlow wrote:
Claus Reinke wrote:
Then how about my suggestion for selectively adding lexical scope to
breakpoints? I'd like to be able to say
:break {names}
and have GHCi make the necessary changes to keep {names} available
for inspection when it hits that break
Simon Marlow wrote:
Claus Reinke wrote:
Then how about my suggestion for selectively adding lexical scope to
breakpoints? I'd like to be able to say
:break {names}
and have GHCi make the necessary changes to keep {names} available
for inspection when it hits that breakpoint.
The only ea
Simon Marlow wrote:
Peter Hercek wrote:
Simon Marlow wrote:
A similar argument applies to keeping the dynamic stack. The problem
with the dynamic stack is that it doesn't look much like you expect,
due to tail-calls.
Do you think people expect the tail-calls to add a stack frame to the
dyn
Peter Hercek wrote:
Simon Marlow wrote:
A similar argument applies to keeping the dynamic stack. The problem
with the dynamic stack is that it doesn't look much like you expect,
due to tail-calls.
Do you think people expect the tail-calls to add a stack frame to the
dynamic stack or is ther
Claus Reinke wrote:
No, it's a real problem. If we retained all the variables in scope at
every breakpoint, GHCi would grow a whole bunch of space leaks. It's
pretty important that adding debugging shouldn't change the space
behaviour of the program. Of course, constant factors are fine, but
No, it's a real problem. If we retained all the variables in scope at
every breakpoint, GHCi would grow a whole bunch of space leaks. It's
pretty important that adding debugging shouldn't change the space behaviour
of the program. Of course, constant factors are fine, but we're talking
asymp
Simon Marlow wrote:
A similar argument applies to keeping the dynamic stack. The problem
with the dynamic stack is that it doesn't look much like you expect, due
to tail-calls.
Do you think people expect the tail-calls to add a stack frame to the
dynamic stack or is there something more comp
Claus Reinke wrote:
Consider this code and session:
f x y z | x
...
Things to note:
- when reaching the breakpoint "in" 'f', one isn't actually in 'f' yet -
nothing
about 'f' can be inspected
- at no point in the session was 'x' inspectable, even though it is
likely to
contain inf
Claus Reinke wrote:
fun x y =
let f1 = ... (f2 x) ... -- f1 calls f2
f2 x = x * 2
in case x of
1 -> f2 0
_ -> f2 (f1 y)
g x = let z = (some complex computation) in z `div` x
main = print (g (fun 1 2))
This is a classical example of why laziness gets in the way of
debugging. Now,
On Mon, Nov 24, 2008 at 5:28 PM, Daniil Elovkov
<[EMAIL PROTECTED]> wrote:
> Peter Hercek wrote:
>>
>> Daniil Elovkov wrote:
>>>
>>> A refinement of :tracelocal could be :tracedirect (or something) that
>>> would save the history not anywhere within the given function but only
>>> within parents, s
fun x y =
let f1 = ... (f2 x) ... -- f1 calls f2
f2 x = x * 2
in case x of
1 -> f2 0
_ -> f2 (f1 y)
g x = let z = (some complex computation) in z `div` x
main = print (g (fun 1 2))
This is a classical example of why laziness gets in the way of
debugging. Now, when (f2 0) gets fina
Peter Hercek wrote:
Daniil Elovkov wrote:
A refinement of :tracelocal could be :tracedirect (or something) that
would save the history not anywhere within the given function but only
within parents, so to say. For example,
This looks like what I thought of as searching for values in dynamic
Daniil Elovkov wrote:
A refinement of :tracelocal could be :tracedirect (or something) that
would save the history not anywhere within the given function but only
within parents, so to say. For example,
This looks like what I thought of as searching for values in dynamic
stack (explained in m
Pepe Iborra wrote:
On Mon, Nov 24, 2008 at 2:03 PM, Peter Hercek <[EMAIL PROTECTED]> wrote:
Maybe what Claus means is that he would like to see the dynamic
stack and be able to traverse it and at each location in the
dynamic stack he could investigate the free variables in the
expression (cor
Hello
I think apart from some other notes the concern here, as started by Peter when
he joined the thread, can be concisely summarised like this:
it would be good if the set of bound variables were equal to the set of
variables syntactically in scope
Apparently, Simon has already explained th
On Mon, Nov 24, 2008 at 2:03 PM, Peter Hercek <[EMAIL PROTECTED]> wrote:
> Simon Marlow wrote:
>>
>> Claus Reinke wrote:
>>>
>>> Perhaps someone could help me to understand how the debugger is supposed
>>> to be used, as I tend to have this problem, too:
>>>
>>> - when I'm at a break point, I'd rea
Claus Reinke wrote:
f x y z | x$ /cygdrive/d/fptools/ghc/ghc/stage2-inplace/ghc.exe --interactive
Debug.hs -ignore-dot-ghci
GHCi, version 6.11.20081122: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Load
- when I'm at a break point, I'd really like to see the current scope
or, if that is too expensive, the next enclosing scope, in full
(not only would that tell me what instantiation of my code I'm in,
it would also seem necessary if I want to reconstruct what the
current expression is)
Simon Marlow wrote:
Claus Reinke wrote:
Perhaps someone could help me to understand how the debugger is
supposed to be used, as I tend to have this problem, too:
- when I'm at a break point, I'd really like to see the current scope
or, if that is too expensive, the next enclosing scope, in
Claus Reinke wrote:
>> It is supposed to show only free variables in the selected expression.
I'm sure I had cases when I was able to access variables which were
not free in the selected expression but which would have been in
scope if used in the selected expression. The values available se
>> It is supposed to show only free variables in the selected expression.
I'm sure I had cases when I was able to access variables which were
not free in the selected expression but which would have been in
scope if used in the selected expression. The values available seemed
correct (contrar
Peter Hercek wrote:
Daniil Elovkov wrote:
I'd like to know, how do ghc developers and users feel about the
debugger?
Sometimes it is better/quicker than "printf debugging" :)
Now I see it mess up the list of bindings in a funny way. For example,
in a previous trace session I had a variable,
Daniil Elovkov wrote:
I'd like to know, how do ghc developers and users feel about the debugger?
Sometimes it is better/quicker than "printf debugging" :)
Now I see it mess up the list of bindings in a funny way. For example,
in a previous trace session I had a variable, say, prev. It was bou
Daniil Elovkov wrote:
I'd like to know, how do ghc developers and users feel about the debugger?
I'm using it to some extent on ghc 6.8.2 and find it useful. But I'm
getting an impression that it's not too stable. I'm not filing any bug
report yet, just want to know how it feels for others.
Hello folks
I'd like to know, how do ghc developers and users feel about the debugger?
I'm using it to some extent on ghc 6.8.2 and find it useful. But I'm getting an
impression that it's not too stable. I'm not filing any bug report yet, just
want to know how it feels for others.
I used to m
25 matches
Mail list logo
