[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
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 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
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 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
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 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
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 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
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 rafk...@cs.utah.edu 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 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
Re: [racket-dev] no backtrace for error in macro
On Tue, Nov 8, 2011 at 12:17 PM, Jon Rafkind rafk...@cs.utah.edu 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
On 11/08/2011 11:18 AM, Robby Findler wrote: On Tue, Nov 8, 2011 at 12:17 PM, Jon Rafkind rafk...@cs.utah.edu 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
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 rafk...@cs.utah.edu wrote: On 11/08/2011 11:18 AM, Robby Findler wrote: On Tue, Nov 8, 2011 at 12:17 PM, Jon Rafkind rafk...@cs.utah.edu 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] [racket] match and debug in Advanced Student
I have no idea what the Debug button does... I call it the Crash DrRacket button, because that's what it did in the early 2000s when I started with Racket. I'm not sure I'm the best person to debug this (despite otherwise being responsible for match in ASL.) Anyone else have ideas what this could mean? Jay On Tue, Nov 8, 2011 at 9:17 PM, Prabhakar Ragde plra...@uwaterloo.ca wrote: I never use the Debug button, but I let my students start using Advanced Student today, and of course they tried it out. The following program induces a strange error when the Debug button is pressed. (match 3 [`(,x) 3] [x 3]) The error is: internal error: skipped binding is used after which the program hangs, though it can be stopped with the Stop button. --PR _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
