probably should ask this on he #CBE668G4R channel

Seems like the same thing has already been discussed in this thread: https://clojurians.slack.com/archives/CBE668G4R/p1712080447688969

Thank you guys I had no knowledge of this

Hi! There are several options: • Get used to it being a line comment and enjoy that it keeps the document structure safe from unbalance introduced by stdout things. • Switch to an output destination that does are not sensitive to unbalance, best option there is the Terminal output, me thinks • Opt in on accepting the risk of unbalance in the repl window with the calva.legacyPrintBareReplWindowOutput setting. See https://calva.io/output/ about your options for output destinations.

I am curious about: > makes inspecting objects frustrating Can you elaborate a bit? Let me also plug this new feature here: https://calva.io/inspector/

When I log I like to collapse and expand certain properties because I log large objects

so when its commented i have to scroll through a large object

I see. Then the repl window with the lagacy bare print may be your best option.

thank you

It would be nice to support logging those objects directly to the inspector. Since you have it in the repl window, you can do Add Current Form to Inspector, but it would be nice to be able to do it without printing it in the REPL window first. I’ll have to think about this a bit. 😃

Awesome thanks

If we can have a dev tools like way of inspecting objectes that would be great

What would a dev tools way of inspecting objects be like?

when you log an onject it starts out collapsed then you can expand and explore properties as you like, you can even select and copy some porperties, basically full control over the obejct

That’s not possible with VS Code files, unfortunately. That’s why we crated the inspector. But it is something to consider if we implement some other output option. cc @U9A1RLFNV

Ok got it 👍

@U01RVS03CAZ You also might want to check out Portal for structured output like that, if you haven't yet.

@U01RVS03CAZ I have logging wired up to tap> values -- and use #C0185BFLLSE for inspecting / visualizing my log data.

what else would you expect from a value that is not equal to itself?

good point!

(js/isNaN ##NaN)

@U9MKYDN4Q Both Clojure and ClojureScript now have NaN? function.

I think not being equal to itself is a good thing, so you don't end up in weird situations like :

(defn foo [n]
  (let [a (+ n 1)
        b (+ n 5) ]
    (= a b)))

Note that there's #CBE668G4R.

ah yea, you are indeed correct. No clue why this posted here, could have sworn I was in Calva. Will move this there. Thanks for the headsup!

No worries.

you should post this to http://ask.clojure.org, that's the best place for such bug reports

alex miller will still probably see it here but he'll recommend the same lol

oh right, thank you so much @UEENNMX0T, this is really good advice!

Here is the link to the report on http://ask.clojure.org. Once again, big thanks! https://ask.clojure.org/index.php/13819/cannot-clojure-isbound-because-clojure-compiler-potential

maybe a combination ?

(defn some-svg-string-1 [{:keys [size type bells? whistles?] :as props}]
  (dd-string/render (some-svg props)))

I'd choose the latter and then alter its var metadata to have synthetic :arglists. I don't know if e.g. clojure-lsp would understand that pattern, but it should (and a hybrid editor like Calva is in a good technical position to bridge runtime insights with static analysis)

yeah, it would be nice if this could be done :

(defn ^{:arglists '([{:keys [size type bells? whistles?]}])} some-svg-string-1 [params]
  ...)

I like the combo, @U0739PUFQ. However, the linter doesn’t 😃 I can do it like so:

#_{:clj-kondo/ignore [:unused-binding]}
(defn some-svg-string-1 [{:keys [size type bells? whistles?] :as props}]
  (dd-string/render (some-svg props)))

But argslist was the way. This works great with clojure-lsp’s help,

(defn ^{:arglists '([{:keys [size type bells? whistles?]}])} some-svg-string-1 [params]
  ...)

And thanks @UKFSJSM38 and the #CPABC1H61 team! 🙏

How about naming the thing and creating a constructor for it? Maybe something like

(defn ->svg-props [size type & [bells? whistles?]]
  {:size size
   :type type
   :bells? (some? bells?)
   :whistles? (some? whistles?)})

(defn add-svg-style [{:keys [type bells? whistles?] :as svg-props}]
  (let [color (type->color type)]
    (assoc svg-props :style (merge {:fill color
                                :stroke :darkgrey}
                               (when-not bells? {:fill-opacity 0.25})
                               (when whistles? {::stroke-width 6})))))

(defn some-svg-string-3 [svg-props]
  (-> svg-props add-svg-style svg-hiccup dd-string-render))

(comment

  (some-svg-string-3 (->svg-props "size" "type"))

  )

I like, @U0P0TMEFJ! Will try to internalize that pattern.

Curiously, clojure-lsp is doing the wrong thing there as it doesn't comply with the runtime reality

user=> (defn ^{:arglists '([{:keys [size type bells? whistles?]}])} some-svg-string-1 [params])
#'user/some-svg-string-1
user=> (-> #'some-svg-string-1 meta :arglists)
([params])

I’m not quite following, but let me try.

but adding ^{:arglists ...} doesn't change the meta

it is overwriten

Yep. If clojure-lsp understands it, it might suffice to call it a day. But from a tooling maker's perspective, it's not optimal to foster things that work in some environments but not others IMO, clojure-lsp could optionally use runtime info to gather any metadata mutated from the outside.

Worth noting that one can use alter-meta for many other purposes, e.g. adding useful info to third-party functions

clojure-lsp uses static analysis, so if you are telling to consider those arglists via a meta, it will use it instead of params when providing its features

After evaluating the function definition I get

:arglists ([props])

Yes, since the repl itself, or cider, or arbitrary other tools will be unable to access the custom info

> clojure-lsp uses static analysis Yep, and that's great. I'd find it even greater if there was a (merge static dynamic) when available 😄

Calva does exactly that merge with quite a few things, actually. I wonder if it could/should do that here.

At least that’s the default. The user can make it be (merge dynamic static).

yah, that's the dream @U45T93RA6 but I can't see that happening easily unfortunately, (there is actually I implemented some time ago, stub, that spaws a runtime clojure to get info of code without sourcecode, but it's was pretty specific and has its performance issues), although I agree it would be the ideal, so for now it's easier if clients do their merge like Calva

Indeed it's the dream, and as an Emacs user i quite envy Calva for being in a position of mixing and matching at will besides simple (merge static dynamic) or (merge dynamic static) choices, probably I'd dig into heuristics ("which arglists look better"), or simple observations like "which of these systems is fresh, up and running"

We do the latter of these in one direction in a sense. If clojure-lsp is not running, the repl reigns supreme and vice versa if the repl is not connected but clojure-lsp is enabled. If the repl has evaluated something and “has an answer” the default is to let that be the truth. But, indeed, we could also let that be overruled if the user changes the code after it has been evaluated. Could be fun exploring this!

You can't use ^{} for putting metadata on a defn, I get confused with this sometimes:

(def ^{:arglists '([This puts metadata on the var])}
  foo identity)

(defn ^{:arglists '([But not with defn! You're putting metadata on the *symbol*, not var])}
  bar [x] x)

(defn baz
  {:arglists '([Gotta do it this way instead])}
  [x] x)

(into {} (for [v [#'foo #'bar #'baz] ]
            [v (:arglists (meta v))]))
;; => {#'repro/foo ([This puts metadata on the var]),
;;     #'repro/bar ([x]),
;;     #'repro/baz ([Gotta do it this way instead])}

I think you can put metadata like that, just not :arglists because they get overwritten

(defn ^:bla foo [])

(-> #'foo meta :bla) ; => true

Oh hmm, that seems like an oversight :thinking_face:

Nice writeup! One small thing to add - since it's All Data™, you can easily factor out any commonly repeated argument specs into a shared var, eg.

(def ^:private traffic-light-props
  '{:keys [size type bells? whistles?]})

(defn traffic-light-symbol-string-arglists
  {:arglists (list [traffic-light-props])}
  [props]
  (h/html (traffic-light-symbol-hiccup props)))

Thanks! That works for the repl, but clojure-lsp is less happy about it. 😃

ahh, that's unfortunate - I use this pattern sometimes when working with defrecord-like data with fixed keys, relying on Cider's (REPL-powered) tooltips

@U0ETXRFEW this is awesome! I've had this problem myself without having a good solution. I can't wait to see if this works as nicely for Emacs + CIDER as it does for Calva.

Oh, it will, it will.

Yes, CIDER is definitely happy to chug whatever metadata you provide to it I've been sort of abusing that in my current project, which is Rama-based - some things kind of escape the normal expectations as for what is a "def" and its metadata So you can make synthetic Vars, and make the :file / :line go to the right place.

Awesome, thanks for the clarification, vemv! (it's a total luxury for me to be able to just ask questions to the people who make the tools I use every day, you both rock)

@U0ETXRFEW good post! question: we don't support currently in clojure-lsp, but wouldn't this be even better?

(defn traffic-light-symbol-string-arglists-w-doc
  {:arglists (:arglists (meta #'traffic-light-symbol-hiccup))
   :doc (:doc (meta #'traffic-light-symbol-hiccup))}
  [props]
  (h/html (traffic-light-symbol-hiccup props)))

@UKFSJSM38 Sweet! I think that would be better. It makes the sharing clearer.

Cool, feel free to open a issue, it should not be hard to support that :)

Somehow this thread led to uncovering what I'm pretty sure is a compiler bug 😮 https://ask.clojure.org/index.php/13834/compiler-exception-dynamically-arglists-metadata-recursive

https://github.com/clojure-lsp/clojure-lsp/issues/1811

Does any underlying functionality use memoize or anything similar?

With the info you've given it's impossible to tell for certain, we can only speculate. Tests themselves are not cached in any way.

yeah, it's strange, i'm not sure

oh you know what, i believe there is memoization in one of the calls. i completely forgot about that

thank you for rubber ducking and giving me the necessary hint