This depends on what repl you use. For generic clojure.main repls, it will go to the STDOUT and your repl also prints to STDOUT. For a client/server like NRepl (which eg. cider uses) it will go to stdout of the server process, which your editor might be hiding in an unexpected place.

yeah Im using cider

I vaguely recall that this can mean an error in the ns form of some other ns required from that file - could be wrong though.

Why you bothering type hinting everything? It generally barely adds any overhead, unless in a loop

The warnings produced when loading the library are getting a bit overwhelming. I’d be interested in knowing how to selectively enable the warnings to cover only performance sensitive parts of the code base but didn’t think that was an option

Hum, you can set warn-on-reflection on for only a subset of the code

To reduce the number of warning

I'd also recommend profiling first.

What is the stacktrace of that exception?

If this helps, here it is. The original sequence is returned by a `for' 

#error {
 :cause "class clojure.lang.PersistentHashSet cannot be cast to class java.lang.Comparable (clojure.lang.PersistentHashSet is in unnamed module of loader 'app'; java.lang.Comparable is in module java.base of loader 'bootstrap')"
 :via
 [{:type clojure.lang.ExceptionInfo
   :message nil
   :data #:clojure.error{:phase :print-eval-result}
   :at [clojure.main$repl$read_eval_print__9086 invoke "main.clj" 442]}
  {:type java.lang.ClassCastException
   :message "class clojure.lang.PersistentHashSet cannot be cast to class java.lang.Comparable (clojure.lang.PersistentHashSet is in unnamed module of loader 'app'; java.lang.Comparable is in module java.base of loader 'bootstrap')"
   :at [clojure.lang.Util compare "Util.java" 153]}]
 :trace
 [[clojure.lang.Util compare "Util.java" 153]
  [clojure.lang.RT$DefaultComparator compare "RT.java" 283]
  [clojure.lang.PersistentTreeMap doCompare "PersistentTreeMap.java" 330]
  [clojure.lang.PersistentTreeMap entryAt "PersistentTreeMap.java" 317]
  [clojure.lang.PersistentTreeMap containsKey "PersistentTreeMap.java" 97]
  [clojure.lang.APersistentSet contains "APersistentSet.java" 34]
  [clojure.lang.PersistentTreeSet cons "PersistentTreeSet.java" 68]
  [clojure.lang.PersistentTreeSet cons "PersistentTreeSet.java" 17]
  [clojure.lang.RT conj "RT.java" 677]
  [clojure.core$conj__5390 invokeStatic "core.clj" 85]
  [clojure.core$conj__5390 invoke "core.clj" 82]
  [user$px_tran_set_merger invokeStatic "scratch.clj" 202]
  [user$px_tran_set_merger invoke "scratch.clj" 197]
  [clojure.core$update invokeStatic "core.clj" 6198]
  [clojure.core$update invoke "core.clj" 6188]
  [user$px_tran_netter invokeStatic "scratch.clj" 219]
  [user$px_tran_netter invoke "scratch.clj" 215]
  [clojure.core$merge_with$merge_entry__5962 invoke "core.clj" 3063]
  [clojure.core$reduce1 invokeStatic "core.clj" 944]
  [clojure.core$merge_with$merge2__5964 invoke "core.clj" 3066]
  [clojure.lang.ArrayChunk reduce "ArrayChunk.java" 58]
  [clojure.core$reduce1 invokeStatic "core.clj" 942]
  [clojure.core$reduce1 invokeStatic "core.clj" 934]
  [clojure.core$merge_with invokeStatic "core.clj" 3059]
  [clojure.core$merge_with doInvoke "core.clj" 3051]
  [clojure.lang.RestFn applyTo "RestFn.java" 139]
  [clojure.core$apply invokeStatic "core.clj" 667]
  [clojure.core$apply invoke "core.clj" 660]
  [user$eval61811$fn__61813 invoke "scratch.clj" 295]
  [clojure.core$keep_indexed$keepi_8568$fn_8569 invoke "core.clj" 7378]
  [clojure.lang.LazySeq sval "LazySeq.java" 42]
  [clojure.lang.LazySeq seq "LazySeq.java" 58]
  [clojure.lang.RT seq "RT.java" 535]
  [clojure.core$seq__5402 invokeStatic "core.clj" 137]
  [clojure.core$print_sequential invokeStatic "core_print.clj" 53]
  [clojure.core$fn__7310 invokeStatic "core_print.clj" 174]
  [clojure.core$fn__7310 invoke "core_print.clj" 174]
  [clojure.lang.MultiFn invoke "MultiFn.java" 234]
  [clojure.core$pr_on invokeStatic "core.clj" 3674]
  [clojure.core$pr invokeStatic "core.clj" 3677]
  [clojure.core$pr invoke "core.clj" 3677]
  [clojure.lang.AFn applyToHelper "AFn.java" 154]
  [clojure.lang.RestFn applyTo "RestFn.java" 132]
  [clojure.core$apply invokeStatic "core.clj" 665]
  [clojure.core$prn invokeStatic "core.clj" 3714]
  [clojure.core$prn doInvoke "core.clj" 3714]
  [clojure.lang.RestFn invoke "RestFn.java" 408]
  [clojure.main$repl$read_eval_print__9086 invoke "main.clj" 442]
  [clojure.main$repl$fn__9095 invoke "main.clj" 458]
  [clojure.main$repl invokeStatic "main.clj" 458]
  [clojure.main$repl_opt invokeStatic "main.clj" 522]
  [clojure.main$repl_opt invoke "main.clj" 518]
  [clojure.main$main invokeStatic "main.clj" 664]
  [clojure.main$main doInvoke "main.clj" 616]
  [clojure.lang.RestFn applyTo "RestFn.java" 137]
  [clojure.lang.Var applyTo "Var.java" 705]
  [clojure.main main "main.java" 40]]}

In px-tran-netter-ex, you're basically doing something like (conj #{:ax-m01} #{:ax-m01}). If that's indeed what you want (having a set of sets of sets of sets etc), it should work fine where the first set is a hash set. But somewhere along the way, you use a tree set. And that's where it fails.

A tree set tries to compare its items between each other. And sets cannot be compared, so a set cannot be a member of a tree set.

Thanks. The px-tran-netter-ex is a big reduction of the original. I wanted to reduce the problem to its simplest manifestation. (There's further processing that runs some checks/reductions on the sets of sets). I'll have to go looking for the tree set. I reckon it's got to be in the `for' somewhere. Let me do some digging.

Just to make sure - are you sure you want to conj all those sets under the :src-ax-id key and not just combine them all with into or something like that?

Also, if you often find yourself processing deeply nested data structures, https://github.com/redplanetlabs/specter should make your life much easier.

Unfortunately, I do need the excessive conj'ing. There are downstream checks regarding whether the final set members are similar enough to be acceptable. I use specter in other places. I like it.

Just closing this out. There was a PersistentTreeSet way down in the values and a conj was complaining. However, is it just me, or is the behavior of HashSet and TreeSet a little bit inconsistent?

For example:

;; returns #{nil #{:a} :a} as clojure.lang.PersistentHashSet
(conj
  (clojure.lang.PersistentHashSet/create (list nil :a))
  (clojure.lang.PersistentHashSet/create (list :a)))

;; throws clojure.lang.PersistentTreeSet cannot be cast to class java.lang.Comparable
(conj
  (clojure.lang.PersistentTreeSet/create (list nil :a))
  (clojure.lang.PersistentTreeSet/create (list :a)))

;; returns #{nil :a #{:a}} as clojure.lang.PersistentTreeSet
(letfn
  [(Cfn [v1 v2](if (= v1 v2) 0 1))]
  (conj
    (clojure.lang.PersistentTreeSet/create
      Cfn (list nil :a))
    (clojure.lang.PersistentTreeSet/create
      Cfn (list :a))))

;; returns #{nil #{:a} :a} as clojure.lang.PersistentHashSet
(letfn
  [(Cfn [v1 v2](if (= v1 v2) 0 1))]
  (into
    #{}
    (conj
      (clojure.lang.PersistentTreeSet/create
        Cfn (list nil :a))
      (clojure.lang.PersistentTreeSet/create
        Cfn (list :a)))))

;; returns #{nil #{:a} :a} as clojure.lang.PersistentHashSet
(letfn
  [(Cfn [v1 v2](if (= v1 v2) 0 1))]
  (clojure.lang.PersistentHashSet/create
    (seq
      (conj
        (clojure.lang.PersistentTreeSet/create
          Cfn (list nil :a))
        (clojure.lang.PersistentTreeSet/create
          Cfn (list :a))))))

And a different `pr-str' representation to differentiate the two. I wonder is there a reason there isn't. Doesn't that break the pr-str / read-string 'loop'.

> is the behavior of HashSet and TreeSet a little bit inconsistent? Their behavior should not be consistent - they are different data structures. They are consistent w.r.t. operations on sets. > a different `pr-str' representation It is expected as well. > Doesn't that break the pr-str / read-string 'loop'. The loop has never been not broken. You can print lots of stuff that's not possible to read at all.

good point. 😀

But, it does seem odd that by defining a yes/no comparator rather that the equal/less/more one it allows the conj operation to proceed. Isn't the comparator properly part of the type?

Data types have a domain of definition. By tweaking a type, you're also tweaking its domain of definition.

I don't know a great deal about type systems I'm afraid (that's one of the reason I love Clojure). I'll have to think about this a bit, and the probably a bit more. I don't know why, but it just makes me feel "uneasy". Thanks for the help. Much appreciated.

No problem. Another example - primitive arrays. An array is an array. However, once you create an array of a specific primitive type, you cannot put anything in there but the values of that type.

I think my unease comes down to this

(conj
  (clojure.lang.PersistentTreeSet/create
    (fn[v1 v2](if (= v1 v2) 0 1))
    (list nil :a))
  (clojure.lang.PersistentTreeSet/create compare (list :a)))

BTW: do you know the best way to cast a tree set to a has set? Or is my seq with create the way to go?

hash set (typo)

You can create tree sets more easily with sorted-set and sorted-set-by. Probably the easiest way to convert any sort of collection to a hash set is to (into #{} coll).

Or (apply hash-set coll).

Thanks

I doubt that this is because of K and V, because generics literally only exist in javac, and are only present as metadata by the time you are emitting clojure bytecode

there is evil/bad code that inspects the metadata of generics, but that error wouldn't happen here, via the clojure compiler

Looking at the constructors, they all take a K and V, I think hinting the other (statically known per constructor) args would suffice to eliminate this warning

because the root issue here is that clojure's compiler wants to pick which constructor method to emit bytecode for, knowing K and V doesn't actually help there

Ah cool. I’ll try just adding hints for the known types then. Thanks 🙏

It isn't.

Good luck!

thanks!

Sounds very powerful! I'm guessing you could do this on a form by form basis given a certain context (available vars etc). I would love to use htat

yes the extension point is the fully qualified symbol for the current macro being expanded.

some obvious ones that really need this: async/go, core/doseq, core/for, core/ns

Cool!

@ambrosebs Do you have something for companies? Something like opencollective?

hmm I do have an LLC fwiw... what's special about opencollective?

It's the only one I know that allows a company to give giftcards to their employees for them to spend

Patron is nice, but it relies on individuals and it's (more) cumbersome for companies

OpenCollective also has a nice system that gives exposure to companies. Who sponsored what

I'll make sure you get some funding on OpenCollective 🙂

I would like to give Giftcards to all employees and let them decide what and where to spend. This is possible via OpenCollective. It just needs a bit more interesting Clojure projects

It's still experimental, but boot-clj has it like this https://github.com/boot-clj/boot#sponsors

I don't know why Github Sponsors doesn't have something like this

Do you happen to know if there are any proven results on "time complexity' of datalog? I can look for such results myself, but if you know of them. e.g. is it provable that every datalog query can be executed in at most polynomial time in the "size of the database", or "size of the query"?

Or a separate but maybe related question: There are regular languages, context-free languages, context-sensitive languages, and "the languages recognizable by Turing machines" (recursively enumerable might be a correct term, but I'm on thin ice there). Is there a similar kind of know sets of "query power", like "SQL queries", "datalog queries", "Turing machine queries", probably in that order of "everything an earlier one can do, a later one can also do, but the later one can do more, too"? If so, are there other well known "query powers" in between those?

I looked through some of the research on Datalog (there is quite a lot) but it's old enough that I think the proofs of that guarantee given a finite set will take more sleuthing. All the academic papers I read (lightly) started with that as a presumption or discussed other matters (such as boundedness). The largest difference between Datalog and SQL is that Datalog is recursive, if you remove that they should be equivalent (although SQL99 was inspired to attempt to add recursion). It's the recursion that gives it more expressive power ... and yes, I think you could use expressiveness as a metric there.