Re: [racket-dev] no backtrace for error in macro
That syntax object is passed to raise-syntax-error; is that something that the macro stepper can find? Robby On Tue, Nov 8, 2011 at 12:25 PM, Jon Rafkind wrote: > On 11/08/2011 11:18 AM, Robby Findler wrote: >> On Tue, Nov 8, 2011 at 12:17 PM, Jon Rafkind wrote: >>> I guess runtime stack traces won't help. It would be nice to see all the >>> locations the syntax went through in its lifetime. Maybe it could be stored >>> as a syntax property? >> You mean you could, say, click on some subexpression in step N and >> then go back one step and find that expression (if it still exists) in >> the previous step in the stepper? > > I suppose that could be useful if that stepper showed me the last expression > that it tried to execute before the syntax error was raised. Then I would > have seen > > (... my-new-literal ...) > -> > dont use my-new-literal > > If I could click on 'my-new-literal' in the code above the arrow and keep > pressing back until I found its origin then I would be happy. Right now the > last step before the syntax error does not highlight 'my-new-literal' as the > syntax that is to be executed next. Actually even if I just saw that (the > next step to be executed with code highlighted) I could have found my issue > very quickly. > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] no backtrace for error in macro
On 11/08/2011 11:18 AM, Robby Findler wrote: > On Tue, Nov 8, 2011 at 12:17 PM, Jon Rafkind wrote: >> I guess runtime stack traces won't help. It would be nice to see all the >> locations the syntax went through in its lifetime. Maybe it could be stored >> as a syntax property? > You mean you could, say, click on some subexpression in step N and > then go back one step and find that expression (if it still exists) in > the previous step in the stepper? I suppose that could be useful if that stepper showed me the last expression that it tried to execute before the syntax error was raised. Then I would have seen (... my-new-literal ...) -> dont use my-new-literal If I could click on 'my-new-literal' in the code above the arrow and keep pressing back until I found its origin then I would be happy. Right now the last step before the syntax error does not highlight 'my-new-literal' as the syntax that is to be executed next. Actually even if I just saw that (the next step to be executed with code highlighted) I could have found my issue very quickly. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] no backtrace for error in macro
I guess runtime stack traces won't help. It would be nice to see all the locations the syntax went through in its lifetime. Maybe it could be stored as a syntax property? Although most likely this had been thought of before and rejected for whatever reason. On 11/08/2011 11:08 AM, Robby Findler wrote: > I'm sorry. Nothing is coming to mind (and just to be clear, turning on > stacktraces for the errors won't help, right?). > > Robby > > On Tue, Nov 8, 2011 at 11:57 AM, Jon Rafkind wrote: >> So is there a more efficient way to debug the issue than looking at the >> macro debugger that you know of? >> >> Also FWIW the error I meant arose from exactly the situation below. I >> created a new identifier meant to be used as a literal: >> >> (define-syntax my-new-literal (lambda (stx) (raise-syntax-error 'literal >> "this is a literal meant to be used inside a macro")) >> >> And the literal ended up in code outside the intended form that would have >> consumed it so the literal's syntax error was raised. >> >> On 11/08/2011 10:51 AM, Robby Findler wrote: >>> 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 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 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
Re: [racket-dev] no backtrace for error in macro
On Tue, Nov 8, 2011 at 12:17 PM, Jon Rafkind wrote: > I guess runtime stack traces won't help. It would be nice to see all the > locations the syntax went through in its lifetime. Maybe it could be stored > as a syntax property? You mean you could, say, click on some subexpression in step N and then go back one step and find that expression (if it still exists) in the previous step in the stepper? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] no backtrace for error in macro
I'm sorry. Nothing is coming to mind (and just to be clear, turning on stacktraces for the errors won't help, right?). Robby On Tue, Nov 8, 2011 at 11:57 AM, Jon Rafkind wrote: > So is there a more efficient way to debug the issue than looking at the macro > debugger that you know of? > > Also FWIW the error I meant arose from exactly the situation below. I created > a new identifier meant to be used as a literal: > > (define-syntax my-new-literal (lambda (stx) (raise-syntax-error 'literal > "this is a literal meant to be used inside a macro")) > > And the literal ended up in code outside the intended form that would have > consumed it so the literal's syntax error was raised. > > On 11/08/2011 10:51 AM, Robby Findler wrote: >> 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 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 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
Re: [racket-dev] no backtrace for error in macro
So is there a more efficient way to debug the issue than looking at the macro debugger that you know of? Also FWIW the error I meant arose from exactly the situation below. I created a new identifier meant to be used as a literal: (define-syntax my-new-literal (lambda (stx) (raise-syntax-error 'literal "this is a literal meant to be used inside a macro")) And the literal ended up in code outside the intended form that would have consumed it so the literal's syntax error was raised. On 11/08/2011 10:51 AM, Robby Findler wrote: > 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 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 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
Re: [racket-dev] no backtrace for error in macro
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 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 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
Re: [racket-dev] no backtrace for error in macro
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 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
Re: [racket-dev] no backtrace for error in macro
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 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
[racket-dev] no backtrace for error in macro
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
