-
-
Notifications
You must be signed in to change notification settings - Fork 21
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
Recursive atoms cause stackoverflow error #21
Comments
Hi! I'm not sure how |
You can customize how objects are formatted in repl output. |
The same is true for Reveal, you can redefine the print method of you don't want to see values inside reference types. I think current default (which is the same both in Reveal and Clojure printing) makes more sense because it's useful and common to look inside atoms, even though it will fail in some cases where atoms are put inside themselves. |
If the goal is to be a drop in replacement for clojure repl, then implementing point 1 would be better. |
I think I understand what you mean: tighter integration with (require '[vlaaad.reveal.ext :as rx])
(rx/defstream IRef [*ref]
(rx/horizontal
(rx/raw-string (str "#reveal/" (.toLowerCase (.getSimpleName (class *ref)))) {:fill :object})
rx/separator
(let [hash (System/identityHashCode *ref)]
(rx/as hash (rx/raw-string (format "0x%x" hash) {:fill :scalar}))))) |
This code will cause a stackoverflow error:
Possible solutions are:
print-method
multimethod can be used to fix this for clojure repl. Maybe use that if it's available (https://clojuredocs.org/clojure.core/get-method)Don't print atoms target value in defstream IRef. It makes sense because atoms are used to opt out of the value semantics of clojure, and making recursive structures is a common use case.
The text was updated successfully, but these errors were encountered: