Currently in eclipsefp you can't view a proper call stack (that is you cannot see the series of functions which led you to a particular point in the code). Is it possible to have this implemented in Eclipsefp, please?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ideally in the "Debug" window (which comes visible when one chooses Debug perspective). Right now it only shows the Module (and line number) where the breakpoint was. Ideally it would show the function name, and also all the functions which led to the call of this particular function, in the manner that is done in Visual studio :
In this diagram Method3 is called by Method2 which is called by Method1. Then by clicking on the appropriate call stack line the ide takes you the relevant file (and relevant line number) of that particular function call.
p.s. Does the points mentioned in the following slide make such a task very difficult ? :
OK, that's what I thought you wanted. But as you see for yourself, in a lazy language it's not always easy/relevant, but GHC I think is improving in that regard. Researching this has been on the todo for a while but nobody asked for it specifically before you… So no promises, but I may have a look.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the state of the art is:
- you can get a stacktrace on errors if you compile with -prof
- however -prof is not supported in GHCi
So you cannot use both stacktraces for errors and GHCi.
What we could do is use :trace and :hist to display the history of evolution, which is not a stack trace but can give you an idea of where in your code you are…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Support for :hist added. So just call your function from GHci with :trace (:trace main) and on a breakpoint you'll see as stack trace the last evaluations in history, which hopefully give you an idea where you are… In the development version will be part of 2.3.2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's awesome. I would also like to make another feature request. Namely when you click on a particular line of the history, that the cursor is taken to the appropriate part of the source code. For example in the diagram :
Ah just saw the picture on your blog. I was just wondering if I could make another feature request. Would it be possible to collapse all calls to a given function under a "+", and it would expand upon clicking on the plus sign. Therefore referring to the picture on your :
The Eclipse debugger model doesn't support nested stackframes, no. So we can't do it. We could just put one line if several line are exactly the same, but this is probably due to recursion, so you may want to see it…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, thanks. "but this is probably due to recursion, so you may want to see it" - yes I totally agree. I think even things like Microsoft visual studio would do the same, but I was just trying to push my luck and see if one could achieve additional "compactification":)
However I cannot replicate what you got in your screenshot. Unfortunately I cannot upload a screenshot on this forum, and so I am going to have to describe in words.
Let us suppose I have the following program :
****************
module Main where
res = myadd 2 4
main = print (myadd 2 4)
myadd :: Int -> Int -> Int
myadd a b = a + b
****************
Then "module Main where" is line 1
and "myadd a b = a + b" is line 7
When I put a breakpoint on line 7, and then
go to "Run->Debug As->GHCi Session", and then
go to the "Console" window and type "(main)",
the code stops at the breakpoint.
However I get (the haskell project is called "HaskellTest1"):
Main (HaskellTest1 src)
(main)
HaskellTest1/src/Main.hs:7:1-17
in the "Debug" window.
What might I be doing wrong (there is no mention of the function name)? Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
to get the "stack trace", we use :hist, which is only populated on first breakpoint if you launch your function with :trace. So type in :trace main.
If hist returns nothing we go back to the default behavior on a breakpoint, which gives you only the location.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I just noticed another thing. In the debug perspective the "Debug", "Variables" and "Breakpoint" windows are all grouped as one (in my setup). Now if I have the "Variables" window activated (i.e. the "Debug" and "Breakpoint" windows in background"), then if I do as above, the code does not even stop at the breakpoint. I think ghci stops at the breakpoint, but I dont see the blue arrow in the Main.hs at the breakpoint location.
Are you able to replicate this on your side? Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd say the blue arrow only appears if the breakpoint location got selected. Anyway, we don't control that at all, that's all part of Eclipse's standard framework. The "normal" appearance of the debug perspective is the debug view on one side, and the variables/breakpoints/expressions on the other.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the video the first time round the debugger stops at the breakpoint. The second time round it does not stop at the breakpoint, and this has something to do with clicking in the Main.hs window before running the debugger the second time round. I know this because if I do not click on Main.hs before launching the debugger the second time round, then the debugger stops at the breakpoint. Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see your video, but I cannot reproduce on my machine with your code. GHCi has stopped at the breakpoint, but EclipseFP somehow failed to recognize it. But since I can't reproduce on my machine… Are you sure you can always reproduce the behavior? I tried 10 times in a row on my machine and it worked.
Anyway, that's unrelated to stack traces, you should create a new ticket for your issue…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you click the cursor into the Main.hs window before running the debugger the second time? This is the crucial bit and yes I can reproduce it over an over again.
I will create a seperate ticket for this. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK just one other thing in regards to stack tracing. I am getting some extra characters appearing in the function names when I use the :trace command. For example in the video :
Hi,
Currently in eclipsefp you can't view a proper call stack (that is you cannot see the series of functions which led you to a particular point in the code). Is it possible to have this implemented in Eclipsefp, please?
Thanks
p.s.I came across this link recently by Simon Marlow :
https://plus.google.com/107890464054636586545/posts/EPnW2WvDrWt
Where do you want to see that call stack? During debugging? On error messages?
Ideally in the "Debug" window (which comes visible when one chooses Debug perspective). Right now it only shows the Module (and line number) where the breakpoint was. Ideally it would show the function name, and also all the functions which led to the call of this particular function, in the manner that is done in Visual studio :
http://www.codeproject.com/KB/cs/MasteringInDebugging/debug38_small.png
In this diagram Method3 is called by Method2 which is called by Method1. Then by clicking on the appropriate call stack line the ide takes you the relevant file (and relevant line number) of that particular function call.
p.s. Does the points mentioned in the following slide make such a task very difficult ? :
http://www.berniepope.id.au/docs/stack_tracing.pdf
Thanks
OK, that's what I thought you wanted. But as you see for yourself, in a lazy language it's not always easy/relevant, but GHC I think is improving in that regard. Researching this has been on the todo for a while but nobody asked for it specifically before you… So no promises, but I may have a look.
Thank you.
New video (by Simon Marlow) on status of stack trace in haskell :
http://www.youtube.com/watch?v=J0c4L-AURDQ&feature=g-user-u
Well, the state of the art is:
- you can get a stacktrace on errors if you compile with -prof
- however -prof is not supported in GHCi
So you cannot use both stacktraces for errors and GHCi.
What we could do is use :trace and :hist to display the history of evolution, which is not a stack trace but can give you an idea of where in your code you are…
Support for :hist added. So just call your function from GHci with :trace (:trace main) and on a breakpoint you'll see as stack trace the last evaluations in history, which hopefully give you an idea where you are… In the development version will be part of 2.3.2
That's awesome. I would also like to make another feature request. Namely when you click on a particular line of the history, that the cursor is taken to the appropriate part of the source code. For example in the diagram :
http://www.codeproject.com/KB/cs/MasteringInDebugging/debug38_small.png
If one clicks ExploringDebugging.exe!ExploringDebugging.Program.Method2()
then the cursor is automatically placed on line 23.
Thank you
This is already the case.
Ah just saw the picture on your blog. I was just wondering if I could make another feature request. Would it be possible to collapse all calls to a given function under a "+", and it would expand upon clicking on the plus sign. Therefore referring to the picture on your :
http://jpmoresmau.blogspot.co.uk/2012/10/using-ghci-history-in-eclipsefp-debugger.html
There would be only one "searchTerm" with a plus sign next to it, and upon clicking the + sign it would expand into 3 "searchTerm".
Thanks
The Eclipse debugger model doesn't support nested stackframes, no. So we can't do it. We could just put one line if several line are exactly the same, but this is probably due to recursion, so you may want to see it…
Hi, thanks. "but this is probably due to recursion, so you may want to see it" - yes I totally agree. I think even things like Microsoft visual studio would do the same, but I was just trying to push my luck and see if one could achieve additional "compactification":)
I have tested the new version in http://jpmoresmau.blogspot.co.uk/2012/10/eclipsefp-232-released.html
However I cannot replicate what you got in your screenshot. Unfortunately I cannot upload a screenshot on this forum, and so I am going to have to describe in words.
Let us suppose I have the following program :
****************
module Main where
res = myadd 2 4
main = print (myadd 2 4)
myadd :: Int -> Int -> Int
myadd a b = a + b
****************
Then "module Main where" is line 1
and "myadd a b = a + b" is line 7
When I put a breakpoint on line 7, and then
go to "Run->Debug As->GHCi Session", and then
go to the "Console" window and type "(main)",
the code stops at the breakpoint.
However I get (the haskell project is called "HaskellTest1"):
Main (HaskellTest1 src)
(main)
HaskellTest1/src/Main.hs:7:1-17
in the "Debug" window.
What might I be doing wrong (there is no mention of the function name)? Thanks
to get the "stack trace", we use :hist, which is only populated on first breakpoint if you launch your function with :trace. So type in :trace main.
If hist returns nothing we go back to the default behavior on a breakpoint, which gives you only the location.
Hi, I just noticed another thing. In the debug perspective the "Debug", "Variables" and "Breakpoint" windows are all grouped as one (in my setup). Now if I have the "Variables" window activated (i.e. the "Debug" and "Breakpoint" windows in background"), then if I do as above, the code does not even stop at the breakpoint. I think ghci stops at the breakpoint, but I dont see the blue arrow in the Main.hs at the breakpoint location.
Are you able to replicate this on your side? Thanks
I'd say the blue arrow only appears if the breakpoint location got selected. Anyway, we don't control that at all, that's all part of Eclipse's standard framework. The "normal" appearance of the debug perspective is the debug view on one side, and the variables/breakpoints/expressions on the other.
Hi, I had problems even with the default debug perspective. I thought it would be easiest to illustrate via a video :
http://www.youtube.com/watch?v=Vs6Tqerevts
In the video the first time round the debugger stops at the breakpoint. The second time round it does not stop at the breakpoint, and this has something to do with clicking in the Main.hs window before running the debugger the second time round. I know this because if I do not click on Main.hs before launching the debugger the second time round, then the debugger stops at the breakpoint. Thanks
I see your video, but I cannot reproduce on my machine with your code. GHCi has stopped at the breakpoint, but EclipseFP somehow failed to recognize it. But since I can't reproduce on my machine… Are you sure you can always reproduce the behavior? I tried 10 times in a row on my machine and it worked.
Anyway, that's unrelated to stack traces, you should create a new ticket for your issue…
Did you click the cursor into the Main.hs window before running the debugger the second time? This is the crucial bit and yes I can reproduce it over an over again.
I will create a seperate ticket for this. Thanks.
OK just one other thing in regards to stack tracing. I am getting some extra characters appearing in the function names when I use the :trace command. For example in the video :
http://www.youtube.com/watch?v=tiFtp6TZxkI&feature=youtu.be
the functions are appearing as "1mmyadd…" instead of myadd etc.
However in your original screenshot your functions appeared fine. Do you have any idea why this might be? Thanks
No idea, you need to look at the full GHc output so I can figure out if the EclipseFP parser does not handle all the possibilities