Can you share the edn that is causing this issue?

That's metadata on the hash map

It's coming from https://github.com/seancorfield/next-jdbc/blob/develop/src/next/jdbc/result_set.clj#L584-L596

The metadata has an anonymous function as the key in the metadata. I bet it can't handle that as EDN?

I think it might be that next.jdbc.result-set/navize-row/fn--49358 is a valid symbol in clj but not cljs :thinking_face:

Ah, could be 🙂

(clojure.edn/read-string "next.jdbc.result-set/navize-row/fn--49358") works fine in clj

Execution error (ExceptionInfo) at (<cljs repl>:1).
Invalid symbol: next.jdbc.result-set/navize-row/fn--49358.

The same thing works in Portal-in-VS-Code so this is specific to how the notebook integration works?

Yeah, the default serialization is not edn. In the future, I'll probably change the serialization for notbooks, but that involves some coordination with the calva folks and setting up some nrepl middleware. The funny bit here is that (symbol "next.jdbc.result-set/navize-row/fn--49358") works fine in cljs so it's some specific about edn.

I guess it’s worth reporting to the CLJS dev team? They usually care for parity with CLJ

How did you start your REPL and what type of project is it?

It's probably caused by https://github.com/djblue/portal/blob/master/src/portal/nrepl.clj#L109 which is shadowing the var to capture test output on eval.

I think Leiningen messes with the test reporter, or at least some of it's plugins do?

> How did you start your REPL? I added an alias to deps.edn as listed at https://cljdoc.org/d/djblue/portal/0.35.0/doc/guides/nrepl#toolsdeps for using nrepl middleware. Then made a custom connect sequence that runs the code in https://cljdoc.org/d/djblue/portal/0.35.0/doc/guides/nrepl#customization after connecting, but with (portal.api/open {:launcher :vscode") added before calling add-tap.

It is a cljc project (aiming to work equally on bb/clj/cljs), but running repl as clj deps.edn. Requiring clojure.test does not trigger the warning, but requiring clojure.test.check.FOO does.

Interesting. We use test.check and I run the Portal middleware and haven't run into this...

Correction: Seems limited to clojure.test.check.clojure-test

I just eval'd every file at work that requires any clojure.test.check.* nses and they all load without error and the Portal middleware shows all the evals (`nil` for the ns form and then every function or test var). And we use c.t.c.c-t...

I am using .generators,`.properties`, and .clojure-test. The other 2 are fine, but .clojure-test invokes warning from any namespace. Using "RELEASE" build of nrepl, cider, and portal with latest Calva and Code.

Same setup here. Where exactly are you seeing that warning -- and does it seem to break any functionality?

Warning is in Portal window underneath the nil returned by calling ns function.

Is it actually the ns form eval causing the warning or is it some specific function from c.t.c.c-t that might be causing it? We use ct/defspec and test reports work for that (I see Portal reports each defspec run as a hash map -- which is fine for the low numbers of iterations we use but might be problematic for, say, 1000 iterations? @U1G869VNV)

Occurs when calling`(require '[clojure.test.check.clojure-test])`. or (ns my.ns (:require [clojure.test.check.clojure-test])) in a fresh repl.

Here's the c.t.c.c-t code that is performing that check:

(when #?(:clj true :cljs (not (and *ns* (re-matches #".*\$macros" (name (ns-name *ns*))))))
  ;; This check accomodates a number of tools that rebind ct/report
  ;; to be a regular function instead of a multimethod, and may do
  ;; so before this code is loaded (see TCHECK-125)
  (if-not (instance? #?(:clj clojure.lang.MultiFn :cljs MultiFn) ct/report)
    (binding [*out* #?(:clj *err* :cljs *out*)]
      (println "clojure.test/report is not a multimethod, some reporting functions have been disabled."))

Interesting. I wonder why I don't see the warning but you do, given we have the same versions of everything otherwise...

🤷

Just to double-check: is this in .clj or .cljs?

.cljc

But you're eval'ing it as Clojure? i.e., via the Clojure REPL, not the cljs REPL

correct

I have in cljc though, so I can also run tests in ClojureScript.

Have a few reader conditionals.

Ah! I am getting that but it only shows in Calva's REPL window which I never have open -- I don't see it in Portal!

; clojure.test/report is not a multimethod, some reporting functions have been disabled.

So we are seeing the exact same behavior 🙂

(and I didn't see it in Portal's log-like output because the nil from the ns eval looks "fine" but I just expanded it up and there's stderr in that log message too -- which does have the warning...

@U1G869VNV It might be nice if Portal indicated there was stdio to look at when it renders a log line?

Mystery solved. So left with whether or not there is anything to be done about it.

Expanded:

Collapsed:

How would I know to expand a log line to see stdio?

Hmm. What view are you using? I don't seem to have one that looks like that. The warning is pretty obvious in every view option I seem to have available.

@U90R0EPHA Well, c.t.c.c-t caters to the non-multimethod binding and Portal isn't the only tool to do that... This is the code that doesn't run:

(let [begin-test-var-method (get-method ct/report #?(:clj  :begin-test-var
                                                         :cljs [::ct/default :begin-test-var]))]
      (defmethod ct/report #?(:clj  :begin-test-var
                              :cljs [::ct/default :begin-test-var]) [m]
        (reset! last-trial-report (get-current-time-millis))
        (when begin-test-var-method (begin-test-var-method m)))

      (defmethod ct/report #?(:clj ::trial :cljs [::ct/default ::trial]) [m]
        (when-let [trial-report-fn (and *report-trials*
                                        (if (true? *report-trials*)
                                          trial-report-dots
                                          *report-trials*))]
          (trial-report-fn m)))

      (defmethod ct/report #?(:clj ::shrinking :cljs [::ct/default ::shrinking]) [m]
        (when *report-shrinking*
          (with-test-out*
            (fn []
              (println "Shrinking" (get-property-name m)
                "starting with parameters" (pr-str (::params m)))))))

      (defmethod ct/report #?(:clj ::complete :cljs [::ct/default ::complete]) [m]
        (when *report-completion*
          (prn (::complete m))))

      (defmethod ct/report #?(:clj ::shrunk :cljs [::ct/default ::shrunk]) [m]
        (when *report-completion*
          (with-test-out*
            (fn [] (prn m))))))))

That view is Portal inside VS Code with the nREPL middleware enabled so each evaluation looks like a log entry.

See the docs: https://cljdoc.org/d/djblue/portal/0.34.2/doc/guides/nrepl

What I see in Portal when I run tests:

That block of {}3 lines is the five hash map results from running defspec

(and you can see the pass below it, with the summary showing number of tests)

(I have customized that a little bit to separate things out a bit more)

I don't seem to have an option for the log view. :thinking_face:

Oh, I see, that is somehow a variation of the inspector view that looks different than mine.

Seems like it would be nice if Portal had some custom display options around test.check. It dumps 100+ maps into the inspector for every passing test. And for a failing test it takes 1 double-click to view the failing case, and back out for another 2 double-clicks to view the shrunken case.

Ah, I didn't think I'd messed with it too much -- but it is all very configurable 🙂

I hadn't noticed the lack of reporting so I didn't even know there was anything wrong. So I would consider it an annoyance to be ignored. I'm not sure it can be fixed fully. Even if Portal uses a multimethod to override clojure.test/report and provides all defmethod paths and delegates to the original, I don't know what would happen if middleware or other library code tried to override clojure.test/report -- as defspec does. I suspect Portal would not be able to capture those new paths and you might be worse off since Portal's report would be cut out of the loop.

I think it's an inherent problem with the way clojure.test is written -- or perhaps with multimethods themselves -- in that you can't replace the reporting mechanism completely...?