Viewing call stack in eclipsefp

Help
asop
2012-10-17
2012-12-06
  • asop
    asop
    2012-10-17

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-18

    Where do you want to see that call stack? During debugging? On error messages?

     
  • asop
    asop
    2012-10-20

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-20

    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.

     
  • asop
    asop
    2012-10-20

    Thank you.

     
  • JP Moresmau
    JP Moresmau
    2012-10-22

    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…

     
  • JP Moresmau
    JP Moresmau
    2012-10-24

    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

     
  • asop
    asop
    2012-10-24

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-25

    This is already the case.

     
  • asop
    asop
    2012-10-26

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-26

    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…

     
  • asop
    asop
    2012-10-27

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-27

    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.

     
  • asop
    asop
    2012-10-27

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-27

    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.

     
  • asop
    asop
    2012-10-27

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-27

    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…

     
  • asop
    asop
    2012-10-27

    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.

     
  • asop
    asop
    2012-10-27

    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

     
  • JP Moresmau
    JP Moresmau
    2012-10-27

    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