This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-07-04
Channels
- # announcements (6)
- # babashka (5)
- # beginners (57)
- # biff (6)
- # business (32)
- # clj-together (1)
- # clojars (10)
- # clojure (56)
- # clojure-europe (76)
- # clojure-nl (4)
- # clojure-norway (40)
- # clojure-serbia (1)
- # clojure-spec (5)
- # clojure-uk (10)
- # clojurescript (3)
- # cursive (12)
- # data-science (1)
- # datascript (4)
- # datomic (35)
- # docs (4)
- # emacs (28)
- # events (5)
- # hyperfiddle (9)
- # matrix (1)
- # off-topic (28)
- # practicalli (4)
- # re-frame (14)
- # shadow-cljs (2)
- # testing (5)
I am suddenly getting the following error with re-frame-10x. Has anyone else faced this before?
#error {:message "Set literal contains duplicate key: ["app-db-path" nil 0 0 0 ...]"
:data {:type :reader-exception
:ex-kind :reader-error}}
This happens when loading =frame-10x.preload
No stack trace, both 1.6.0 and 1.7.0. What's weird is that Chrome ran into this issue, so I switched to Firefox for dev, and now Firefox has this exact same issue
Huh? How come there's no stacktrace? Where exactly do you see that error? In the JS console of your browser it should be an expandable object with a stacktrace.
Ah, that's interesting. My crystal ball is sparkling. :)
Do you have *print-length*
set? To 5, perhaps.
That's the culprit.
That vector in the error is a path that gets written to local storage. re-frame-10x naively uses pr-str
which breaks when you specify print length.
A proper fix would be for re-frame-10x to use a more reliable serialization approach.
A local fix that you can do is to avoid setting *print-length*
globally. And to fix your browsers, you need to erase the local storage keys related to re-frame-10x.
Oh wow, I would’ve never guessed this. I will follow these suggestions “tomorrow” and report back. Thanks for the guidance
ok out of impatience I decided to try your suggestions right now, and they indeed fix the problem on my end. I can't reliably reproduce the bug though
I'm not sure what that path is so can't describe how the issue should be reproduced. Perhaps it's' to store which paths are expanded when viewing app-db in the re-frame-10x panel. If that's the case, you have to expand more than 3 separate paths and maybe close/open the panel and maybe refresh the page.
Hey, if anyone managed to reproduce this, I'd appreciate if you could test out my branch. https://github.com/day8/re-frame-10x/pull/396
I'm on the fence about it, so I'd like to know more. Is it just because you mutated *print-length*
globally? Is that a conventional thing to do? Seems like it risks breaking more than just re-frame-10x. For instance, both reagent and garden use pr-str in various places.
I don't use garden and I cant recall reagent breaking to this. The reason to set *print-length*
is quite simple: you're at a REPL dealing with large or infinite lazy sequences and dont want to flood your whole buffer. It's a very normal thing to do and the var exists precisely for this purpose