This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (124)
- # beginners (98)
- # calva (54)
- # cider (32)
- # cljdoc (5)
- # cljs-dev (131)
- # cljsrn (1)
- # clojure (107)
- # clojure-australia (2)
- # clojure-europe (2)
- # clojure-losangeles (1)
- # clojure-norway (3)
- # clojure-uk (28)
- # clojurescript (21)
- # conjure (86)
- # core-async (7)
- # cursive (2)
- # datascript (5)
- # datomic (28)
- # defnpodcast (2)
- # devcards (1)
- # exercism (47)
- # fulcro (22)
- # graalvm (29)
- # graphql (1)
- # malli (5)
- # nrepl (31)
- # off-topic (111)
- # re-frame (23)
- # reitit (4)
- # spacemacs (6)
- # tools-deps (10)
- # tree-sitter (1)
- # xtdb (6)
If I place a breakpoint on line 8 here: https://github.com/PEZ/clojurecism/blob/master/meetup/src/meetup.clj#L8 things lock up when I evaluate something that should hit it.
@pez Seems like a pretty ordinary function to me. Do you want me to test it in CIDER?
Actually, on second thought I think the problem is pretty simple. I assume you don’t set any print lenth limit, but
(range) is infinite and and when you try to realize it in the debugger nothing good can come out of this.
I’m wondering if it doesn’t make sense to add some special handling for
range and other forms like it that we know are going to cause a lockup without some additional configuration.
Ah, I see. The thing is that the problem seemed a bit intermittent , so I never suspected the
range thing, which we have discussed recently somewhere.
Maybe the default should be that the implementing side sets some non-locking print length?
Well, that’s certainly an option, although I think it’s better for editor clients to set some default, as this is more visible to the end users. Otherwise they might wonder where some limit is coming from.
What happens when you step over it and it doesn’t blow up? Without some print limit I can’t expect how this can work in some cases. 🙂
CIDER used to have separate print options configs for regular evaluation and for the debugger but at some point we folded those together .
(defcustom cider-print-options nil "A map of options that will be passed to `cider-print-fn'. Here's an example for `pprint': '((\"length\" 50) (\"right-margin\" 70))" :type 'list :group 'cider :package-version '(cider . "0.21.0"))
Funny enough, when those options had defaults people were complaining there were defaults, and when we removed them - people were complaining there were no defaults. 😄
But generally, Calva comes with a lot of defaults, so people are more used to it there. 😃
The intermittent thing might have been my testing. Probably was my testing. There were a lot of branches and versions involved... I easily get confused.
@brandon.ringe maybe we should consider debug defaults like ^ that ^? I might not be the only one not realizing the implications of attempting to realize and infinite sequence. 😃
Yeah, or even a default that is used everywhere, like Bozhidar said. This is related to the large result set issue I think. So a fix there could fix the debug issue perhaps
I think I saw this same issue being discussed elsewhere just the other day, in this slack workspace, but I don't remember where.
But it makes sense to me to have a default of
infinite generally, but for debug, something finite, and to have settings where both can be changed by the user.