Closed shhyou closed 3 years ago
Also looks related to #421?
Yes! Looks like they are the same bug. Turning off background expansion does side-step this and fixes the voldemort problem.
It looks like this is fixed along with #421, so I'll close (but reopen if I have it wrong).
Let me reopen this since there's one more case that differs: unsaved editor.
In DrRacketCS:
#lang racket/base
(syntax-source (quote-syntax here))
outputs "unsaved editor"
. In DrRacketBC, it outputs 'unsaved-editor
.
The difference seems to cause the voldemort example to fail.
looks like an easily fix here or in the gui library
racket/share/pkgs/drracket/drracket $
private/expanding-place.rkt:118: (define the-source (or path "unsaved editor"))
racket/share/pkgs/gui-lib $
framework/private/text-basic.rkt:527: (define port-name-unsaved-name "unsaved-editor")
Why are BC and CS evaluate differently though? It looks like there's a larger problem behind this bug.
I tested 8.0.0.3 [cs] and 7.9 [3m] with background expansion enabled and errortrace disabled. The results are both "unsaved editor". With errortrace, the outputs both become 'unsaved-editor. Either case, voldemort
is highlighted with the above patch.
Is this what you see too?
It's complicated. I can see the behavior that you described, but also don't see the behavior that you described under some circumstance.
'unsaved-editor
. Sometimes it's "unsaved editor"
right away. In any case, after one more run, they both produce "unsaved editor"
.voldemort
, I can see the behavior that you described (that it works when errortrace is off in DrRacketCS) only once. After that, it consistently fails to highlight, regardless of many times I run the program.Based on my experiments, I'm pretty sure voldermort
works if and only if it outputs 'unsaved-editor
.
I can now consistently reproduce the problem:
"unsaved editor"
.'unsaved-editor
.'unsaved-editor
."unsaved editor"
. Any subsequent run will produce "unsaved editor"
. Even if you switch errortrace on and then off again, it will still produce "unsaved editor"
. This current buffer is doomed. Open a new tab will let you repeat from step 0 again.Aha! The fact that voldemort
doesn't work is a bug in Racket BC as well!
Somehow this bug seems to manifest more in Racket CS, though.
@sowaree If you're running AArch64 BC, then you're running without places. That may have more to do with things than CS vs. BC, although I'm not certain. You could use x86_64 BC to avoid that difference.
Also, I'm not sure it's clear (because I may have overlooked some discussion): when you have a star-ish dot in the bottom right in DrRacket, that means you're running the result of background expansion directly. A smooth-circle dot means that "Run" starts over independent of background expasion (e.g., to add debugging information). So, you might be getting different results depending on whether the dot has gone green and star-ish.
Yep, I'm running AArch64 BC. I can try x86_64 BC when I get a chance to install it.
Re background expansion: you are totally right about it. That's the cause of difference.
Those two commits seem to fix the volemort program in the spiky ball state.
Yes, it works now. Thanks! :)
I am not sure if this is a DrRacket issue or a Racket issue.
Version: (Dr)Racket 7.9.0.22 [cs]
Example program:
When running from the command line, the result is an absolute path:
When running inside DrRacket [cs] without errortrace but with background expansion, the result is a relative path:
This difference does not show up in Racket v7.9 [bc]. Subsequently, the path difference affects error location highlighting because
set-error-ranges
relies onport-name-matches?
. (related to https://github.com/racket/racket/issues/3325#issuecomment-752354258) https://github.com/racket/drracket/blob/6cda6a7b1738b0be624f96aba10c48b1e5adbe4d/drracket/drracket/private/rep.rkt#L637-L644.