Re: [racket-users] Stack trace

2019-05-06 Thread Sam Tobin-Hochstadt
If you record, say, the 100 most recent function calls and their arguments, then you should be able to maintain proper space use as well as provide as much information as needed. Sam On Sat, May 4, 2019 at 5:45 PM Matthias Felleisen wrote: > > > > On May 3, 2019, at 4:17 AM, Mark Engelberg wrot

Re: [racket-users] Stack trace

2019-05-04 Thread Matthias Felleisen
> On May 3, 2019, at 4:17 AM, Mark Engelberg wrote: > > f tracing is not easily available in BSL, my ideal would be that every error > prints out not only the function/line where the error occurred, but also the > input(s) to the function which triggered the error. (Example: a function > co

Re: [racket-users] Stack trace

2019-05-03 Thread Mark Engelberg
If you open up the details of BSL and select to enable tracing, and run my example, you do indeed see a stack trace in a panel on the right: (sub2 2) (reciprocal 0) However, there are clearly some limitations to this tracing mechanism, when my student tried to enable tracing on his big-bang prog

Re: [racket-users] Stack trace

2019-05-02 Thread 'John Clements' via Racket Users
Well, I see two things going on here. First, this example is an interesting one, because there’s no stack trace to display; the (/ 1 n) is the only “frame” left on the “stack”, because the call to sub2 has already returned, and the body of “reciprocal” is in tail position with respect to the ca

[racket-users] Stack trace

2019-05-02 Thread Mark Engelberg
Working with a student in DrRacket for the first time in a while. I notice that in BSL, an error in a function does not tell you what input to the function caused the error, nor does it show the stack trace by drawing arrows in the definitions window the way I remember. When did this behavior cha