-
-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
port-write-handler is not reset after a run #381
Comments
Each Is that correct? I'm not very familiar with it, but I notice that the documentation for Maybe you could research this (e.g. ask on Slack or mailing list) and report back? |
For that recipe Dr Racket prints I don't know whether Dr Racket explicitly resets this handler. Instead it might be recreating the port (a special port for its GUI REPL). Whereas Racket Mode is reusing stdout a.k.a. |
Like some other bugs you've filed recently, this seems to be an interesting edge case that seemingly no one else has encountered -- or at least reported -- in five years. As a result, although I guess I appreciate knowing about it, I'm not sure what action to take beyond the time already spent discussing this, because I'm not sure what is the cost:benefit ratio here. |
That way, a port-{read write display print}-handler set by a user program will not persist into the next racket-run. Another way to fix this might be to restore the original 4 handlers. However the dup-{input output}-port docs mention this specific case. Also it seems like duping the ports freshly for each run would address any other such per-port state, which I'm not aware of (or which might be added someday). So this seems like the best approach.
Well this stuck in my brain overnight. I pushed a commit to address this. I'm still not sure this is a great use of time, and, it's possible fixing this will cause some other, worse bug. But I pushed a commit to a topic branch. Maybe I will slow-roll actually merging it to master. |
The first attempt at fixing #381 using dup-{input output}-port caused a new issue #397. This commit seems to fix both. Will it introduce yet another, third issue? Maybe. I am determined to demonstrate the idea that all programs are perpetually in a state of waiting to be fixed. (Or not in that state: Let's remain open to advances like quantum computing.)
The first attempt at fixing #381 using dup-{input output}-port caused a new issue #397. This commit seems to fix both. Will it introduce yet another, third issue? Maybe. I am determined to demonstrate the idea that all programs are perpetually in a state of waiting to be fixed. (Or not in that state: Let's remain open to advances like quantum computing.)
Paste the following code in a buffer and run it.
This prints
"a"
as expected. Now, paste the following code and then run it.It still prints
"a"
!The text was updated successfully, but these errors were encountered: