It isn't clear to me that the stacktrace is actually containing useful information in such cases. That is, the stack will not tell you which macro introduced the free identifier, only the code that finds the identifier (that is, the code that detects free variables).
Robby On Tue, Nov 8, 2011 at 11:46 AM, Jon Rafkind <rafk...@cs.utah.edu> wrote: > Ok. Whats your (the) strategy for debugging these sorts of errors? Yesterday > I just stared at the macro debugger output for a while until I saw where an > identifier that ultimately raised a syntax error showed up. > > On 11/08/2011 10:41 AM, Robby Findler wrote: >> This is a change I made recently and I put a rationale and explanation >> in the commit message here: >> >> >> http://git.racket-lang.org/plt/commit/e1ce0a0d1e6120354ace65dc3fda76d0442fb3a1 >> >> Robby >> >> On Tue, Nov 8, 2011 at 11:30 AM, Jon Rafkind <rafk...@cs.utah.edu> wrote: >>> When this program is run in DrRacket the error is displayed in the >>> interactions pane with a backtrace icon next to it but if you click that >>> icon the backtrace window is blank. It would be nice to get some sort of >>> backtrace or I suppose in the worst case no backtrace icon should appear. >>> >>> #lang racket >>> >>> (define-syntax (foo stx) (raise-syntax-error 'foo "dont use foo")) >>> (define-syntax (bar stx) >>> #'(foo)) >>> >>> (bar) >>> >>> >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >>> > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
