Fork me on GitHub

@scott.silver why do you need to call instrument again? I have forgotten how that works.


@scott.silver that's how I do it and I agree it's frustrating. @drewverlee the problem is that after you eval the buffer all your instrumentation is gone for those functions and does no fdef spec errors will be catched. Apart from having a custom "eval buffer" function which would call stest/instrument under the hood I'm not aware of any other solution. I might ask in #clojure-spec since it's not necessarily specific to cider

đź‘Ť 3
Scott Silver04:06:32

thanks @jumar; is it possible to define a custom “eval buffer” function?


Can you replicate this in just a bare clj repl? It’s not clear to me if CIDER is doing something bad or if just instrumentation is a bit sensitive


I don't think it's an issue with cider it's just about improving the workflow when using cider - see follow-up in #clojure-spec :


It's how it works in any repl/tool I believe - the functions you re-evaluate aren't instrumented anymore and you need to call stest/instrument manually


I don’t use spec, so I can’t provide much input on the subject. I guess the simplest solution would be to avoid eval-buffer after the first time and just re-eval updated expressions. We can also have some eva-buffer-hook where you can trigger some additional evaluations if needed.


I think problem remains even when you eval a single defn - the instrumented version os gone. But it’s for sure a smaller problem


So, this instrumentation adds some metadata and the metadata gets reset, right?


I think it replaces the function with a wrapper which checks the spec and then calls the original fn

Scott Silver17:06:16

@U051BLM8F I think adding an eval-buffer-hook would solve this issue; I personally would find it extremely useful. would that be a difficult feature to add?


It’s pretty simple to add the hook. Please, file some ticket on GitHub so I wouldn’t forget about this.


@jumar I define a collection of all the functions to be instrumented and pass them to the spec instrument function using a helper function. Then if I evaluate any function definitions I call the helper function and all the functions are instrumented again. If there was a post-eval hook that calls the helper function, then that could be convenient. For example


That's interesting but that won't work for me. It's a tedious work to keep this up-to-date and other devs aren't gonna do it 🙂


Oh, sorry to hear about that. Maybe one day you will find a more collaborative dev team to work with :white_frowning_face:


an alternative solution, outside cider, that might be more in keeping with how the creators imagined spec would get it's main utality is you do generative testing of your application. It seems unlikely that clojure wil merge with typed clojure anytime soon so i expect there always to be a friction in doing these sorts of things. If you want to jump that fence part way you can try orchestra though.

Scott Silver17:06:03

@drewverlee what do you mean when you say that Orchestra can get you there part-way?


Has anyone ever wanted to be able to use C-M-x or C-c C-f (in other words, the eval defun-at-point functions) inside a (comment ...) block? What I'd like is to keep their normal behavior (evaluating the top-level form you're currently in), but having a exception when the top-form is a comment, and evaluating the one-before-top-level form. It's probably a peculiar need.


... as I was looking through cider code to see if I could do it myself, I found a variable that already does it, clojure-toplevel-inside-comment-form. Not so peculiar after all


yup! couldn't live without it


time to read through all the cider options again ahah


the last time I did it, I didn't knew enough clojure to know what could interest me


I find instrumenting fdef specifications convenient during development, to help me if I am calling custom functions with incorrect arguments. Switching instrumentation on an off with a helper has been okay for now. I do want to look at using koacha for testing these before pushing code to a shared repo. looks interesting, but want to get more comfortable with spec before adopting it.

Scott Silver17:06:15

Orchestra is great, but I don’t believe it would alter the requirement that you run (instrument) after re-evaluating a buffer in the repl. i think the primary advantage of using Orchestra is that it will check your :ret and :fn specs, whereas clojure.spec.test/instrument will only check the :args


Yes, that makes sense, thank you.


I just noticed Cider is returning Java member docs and eldoc for unresolved symbols without a period, eg. (shift |) being interpreted as java.lang.StringBuffer/shift


It might be, there was a recent bug fix in the info op and it might have cause that. It is a very balance, do you mind opening in a bug report in orchard?


I agree we should be prioritizing Clojure vars in the resolution logic. As for the period - keep in mind that references to methods can appear outside the context (.methodName) - e.g. in (. foo bar) and (.. foo bar baz).


Clojure vars are currently prioritized over Java members, this only seems to happn for unresolved names


I'll open an issue on Orchard later, was just curious if this was something new or I simply hadn't noticed before


Is this a recent regression? I don't recall this happening before


@thheller tells me that shadow-cljs auto-completion is broken in the repl, is there an issue for this I can follow for updates?