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
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
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 co
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 Findle
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
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
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-erro
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
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
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 displ
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 ra
11 matches
Mail list logo
