it's possible that *ns* is different when run in the repl vs in the test

nay, likely

Oh, actually I'm wrong about it being eval, it's Compiler/analyze that fails in the test runner, but succeeds in the REPL

test-runner requires test namespaces but does not change ns

It tries to resolve a symbol in the form it's analyzing, and can't find it. I guess that's a more esoteric use case for someone to use Compiler/analyze

As mentioned it is because in the repl the compile time and runtime value of *ns* is the same, but in arbitrary execution contexts there is no guarantee of any relationship between the compile time and runtime values of *ns*

Use syntax quote so your symbols are namespace qualified at read time

Ya, looks like you're right, it's because Compiler/analyze is using the ns of where I have the function that calls it, not where I'm calling my function that ends up calling it

*ns* is compile time state, you shouldn't expect it to be any particular value at runtime unless you set it

Well, now I get a Var$Unbound, but it's progress

this library did it back in the day… https://github.com/clojure/test.generative

For generative tests, you can dynamically bind clojure.spec.alpha/*fspec-iterations* to a low number like 5.

is the question about how to bind the cardinality of test cases by time rather than number?

Yeah, I think they’re asking to “run for 5 seconds” vs run for n iterations

Maybe if you create a clock in your application, 5 seconds could be 5000 ticks depending on the granularity. Manifold repo has an example of such a clock.

you could create a lazy sequence of generative tests with fmap and consume from it until a timer indicates 5 seconds have elapsed

set an atom to true and have it expire in 5 seconds with (future (swap! *stopped?* (fn [_] (Thread/sleep 5000) false) and use take-while, or just use loop

I like that approach @UFTRLDZEW thanks.

Make both strings lower case?

(sort compare ["Hello" "hello" "ahoj"])
("Hello" "ahoj" "hello")

(require '[clojure.string :as str])
(sort #(compare (str/lower-case %1) (str/lower-case %2)) 
            ["Hello" "hello" "ahoj"])
("ahoj" "Hello" "hello")

(defn my-compare [a b]
  (if (and (string? a) (string? b))
    (.compareToIgnoreCase a b)
    (compare a b)))

Or use java's Collator: https://stackoverflow.com/questions/49821774/sorting-string-value-in-a-case-insensitive-manner-in-java-8

I've worked out more or less the same functions.. but these breakdown when combined with juxt for multi-field sorting. Hence the "in all situations".. For example:

(sort-by (juxt :name :phone)
         my-compare
         [{:name "aaron" :phone 0} {:name "Alice" :phone 1} {:name "Betty" :phone 2}])
;; => ({:name "Alice", :phone 1} {:name "Betty", :phone 2} {:name "aaron", :phone 0})

In this example, my-compare receives two vectors of values, so you have to change them somehow. A wild guess:

(defn lc [o]
  (if (string? o)
    (str/lower-case o)
    o))

(defn my-compare [a b]
  (cond (and (string? a) (string? b))
        (.compareToIgnoreCase a b)
        (and (vector? a) (vector? b))
        (compare (mapv lc a)
                 (mapv lc b))
        :else (compare a b)))

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/String.html#compareToIgnoreCase(java.lang.String)

@UK0810AQ2 That's exactly what I used in my first post in the thread. But it won't cut it because you can't make Clojure compare vectors of strings in a different manner without making your comparator vector-aware. Same goes for every other collection type that ends up comparing its elements pairwise.

ack, I see now

Seems like if you want a comprehensive solution you'll need to implement the entire tower with a protocol or multi method

What about something cruel like this?

(defn my-compare [a b]
  (.compareToIgnoreCase (pr-str a) (pr-str b)))

I've resorted to preprocessing the list of maps, by lowercasing strings

turn on reflection warnings

(set! *warn-on-reflection* true)

in the first and third examples, the compiler knows which overload method signature to target https://stleary.github.io/JSON-java/org/json/JSONArray.html

Thanks! I think I understand the problem now. The compiler doesn't know that the result of (identity ...) is a string. I fixed it with:

(new org.json.JSONArray ^String (identity "[{\"foo\":1}]"))

But I couldn't see the difference with (set! *warn-on-reflection* true), the output was the same.

the middle call should print a warning

I'm using Calva in VSCode. Should it appear in output.calva-repl?

I'm not familiar with where calva shows stuff, but yes it sounds like the REPL window should show that warning

unless maybe the compiler selected the "Object" signature

and didn't reflect at all

I tried it in repl and nothing:

Clojure 1.11.1
user=> (set! *warn-on-reflection* true)
true
user=> (new org.json.JSONArray (identity "[{\"foo\":1}]"))
Execution error (JSONException) at org.json.JSONArray/<init> (JSONArray.java:225).
JSONArray initial value should be a string or collection or array.

then it must be that the compiler matched the Object signature

and thus no warning

Ow, ok, I understand now. Makes sense, thanks!