Skip to content
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

Closed
sorawee opened this issue Jun 19, 2019 · 4 comments
Closed

port-write-handler is not reset after a run #381

sorawee opened this issue Jun 19, 2019 · 4 comments
Labels

Comments

@sorawee
Copy link
Contributor

sorawee commented Jun 19, 2019

Paste the following code in a buffer and run it.

#lang racket/base

(let ([write-handler (port-write-handler (current-output-port))])
  (port-write-handler (current-output-port)
                      (λ (val port)
                        (write-handler "a" port))))

(write 1)

This prints "a" as expected. Now, paste the following code and then run it.

#lang racket/base

(write 1)

It still prints "a"!


``` ((alist-get 'racket-mode package-alist) #s(package-desc racket-mode (20190612 1928) "Major mode for Racket language." ((emacs (24 3)) (faceup (0 0 2))) nil nil "/Users/sorawee/.emacs.d/elpa/26.2/develop/racket-mode-20190612.1928" ((:url . "https://www.racket-mode.com/") (:maintainer "Greg Hendershott") (:authors ("Greg Hendershott"))) nil)) ((emacs-version "26.2") (emacs-uptime "5 days, 6 hours, 44 minutes, 24 seconds") (system-type darwin) (major-mode racket-mode) (racket--el-source-dir "/Users/sorawee/.emacs.d/elpa/26.2/develop/racket-mode-20190612.1928/") (racket--rkt-source-dir "/Users/sorawee/.emacs.d/elpa/26.2/develop/racket-mode-20190612.1928/racket/") (racket-program "racket") (racket-command-port 55555) (racket-command-startup nil) (racket-command-timeout 10) (racket-memory-limit 2048) (racket-error-context medium) (racket-retry-as-skeleton t) (racket-error-context medium) (racket-history-filter-regexp "\\`\\s *\\S ?\\S ?\\s *\\'") (racket-images-inline t) (racket-images-keep-last 100) (racket-use-repl-submit-predicate nil) (racket-images-system-viewer "display") (racket-pretty-print t) (racket-indent-curly-as-sequence t) (racket-indent-sequence-depth 0) (racket-pretty-lambda nil) (racket-smart-open-bracket-enable nil) (racket-module-forms "\\s(\\(?:module[*+]?\\|library\\)") (racket-logger-config ((cm-accomplice . warning) (GC . info) (module-prefetch . warning) (optimizer . info) (racket/contract . error) (sequence-specialization . info) (* . fatal))))) ```
@sorawee sorawee added the bug label Jun 19, 2019
@greghendershott
Copy link
Owner

Each racket-run gets a fresh custodian including a fresh dedicated thread for the REPL. As a result, parameters are reset. Therefore you expect port-write-handler to be reset. But it is not.

Is that correct?

I'm not very familiar with it, but I notice that the documentation for port-write-handler and friends doesn't actually use the word "parameter". Is it possible that it's a function that has a parameter-like signature, but is not actually a parameter? Many "handlers" in Racket are parameters; maybe this isn't?

Maybe you could research this (e.g. ask on Slack or mailing list) and report back?

@greghendershott
Copy link
Owner

greghendershott commented Jun 19, 2019

For that recipe Dr Racket prints 1 not "a".

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. current-output-port here -- so if you stick some handler on that port, it remains in effect because it's still the same port.

@greghendershott
Copy link
Owner

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.

@sorawee sorawee closed this as completed Jun 19, 2019
greghendershott added a commit that referenced this issue Jun 20, 2019
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.
@greghendershott
Copy link
Owner

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.

greghendershott added a commit that referenced this issue Sep 24, 2019
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.)
greghendershott added a commit that referenced this issue Sep 24, 2019
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.)
greghendershott added a commit that referenced this issue Feb 25, 2020
Revert the change in commit 694f20d because that change actually
regresses issue #381. Instead just save the handlers in effect when we
start the entire back end, to restore as the baseline default to use
for each run.
greghendershott added a commit that referenced this issue Mar 23, 2020
Revert the change in commit 694f20d because that change actually
regresses issue #381. Instead just save the handlers in effect when we
start the entire back end, to restore as the baseline default to use
for each run.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants