Clojurians Log v2

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?

That’s what I did.

Calva is bug compatible. 😃

Should I file this as an issue?

@pez Yep, you should.

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.

> The thing is that the problem seemed a bit intermittent

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. 🙂

With implementing side, I meant editor clients. 😃

😄

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"))

You can add something like this.

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. 😄

I have had many moments like that with Calva!

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.

Related to infinite sequences and print length

Same here. I know we discussed it somewhere, but where... a slack syndrome.

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.

Yeah, more settings with reasonable defaults is usually better, imo

Less settings is my usual goto. 😃

But this does come to mind. https://youtu.be/QHZ48AE3TOI