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
> 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
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
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
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
5 matches
Mail list logo