I have a vector of vectors and I’m trying to only display unique elements

[ [{:name "hello"}] [{:name "world} {:name "hello"}] ]

(into #{} [ [{:name "hello"}] [{:name "world} {:name "hello"}] ])

(let [vectors [ [{:name "hello"}] [{:name "world"} {:name "hello"}] ]]
  (->> vectors
       (apply concat)
       distinct))
-> ({:name "hello"} {:name "world"})

ah nice, thank you! 🙂

I was trying to create a function that shows the difference in terms of order within 2 lists. so for example running these two vectors

(def a-list
  [{:id "29jd1001"
    :name "A project"}
   {:id "2013uj2"
    :name "B project"}
   {:id "1112398"
    :name "C project"}])

(def b-list
  [{:id "2013uj2"
    :name "B project"}
   {:id "29jd1001"
    :name "A project"}
   {:id "1112398"
    :name "C project"}])

(defn find-diffs
  [a b diff-fn]
  (remove nil? (map diff-fn a b)))

(->> (find-diffs a-list b-list #(when (not= (:id %1) (:id %2)) [%1 %2]))
    (apply concat)
    distinct)

I wanted to use keep but looks like it only takes 1 collection at a time

sorry but doesn't clojure.data/diff work for you?

cljs.user=> (clojure.data/diff a-list b-list)
[[{:name "A project", :id "29jd1001"}
  {:name "B project", :id "2013uj2"}]
 [{:name "B project", :id "2013uj2"}
  {:name "A project", :id "29jd1001"}]
 [nil nil {:id "1112398", :name "C project"}]]

but I want it the other way around. so it should give me the first 2, rather than the 3rd one

because their positions changed

right, that's what it's returning, take a closer look

it returns diff from the left side, diff from the right side, and things in common

"things-only-in-a things-only-in-b things-in-both"

see https://clojuredocs.org/clojure.data/diff

oh so the whole thing is a return value? damnit 😄

well it's a tuple, but yes

of course there’s a built - in thing in clojure..

the thing is, data/diff doesn't look for re-orderings, it just checks differences naiively element per element

but maybe that's good enough for you

yeah, that’s exactly what I was trying to achieve

by comparing ids in my case

ah this is very cool!

another reason to completely switch to clojure

i find it cute how modern languages are finally getting around to having relations as a standard 1st class part of the language

data nerds (SQL) have been onto relations for a while though and it's painful using client languages that have to build a bridge to deal with them

it's almost not painful in clojure

what does it mean to have first-class relations? foreign-key enforcement?

With lein 2.8.1, I'm getting this error:

Tried to use insecure HTTP repository without TLS.

I’m not sure if this will work, but you could try lein pom to generate a pom.xml, then mvn -X dependency:tree

I think you’ll see some logs like Using connector WagonRepositoryConnector with priority 0.0 for http://...

also having issues with security on ubuntu 18.04. Lein will complain about java certificates which i was only able to solve by completely purging all versions of java, reinstalling certificates and reinstalling java

What version of java? JDK9 lacks certificates at all in some packages

(jdk 8 and 10 are fine)

ryan@ryan-Serval-WS:/tmp» java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

I'm trying the mvn dependency:tree idea, but I had to add some plugins since I'm using an S3 wagon via https://github.com/s3-wagon-private/s3-wagon-private

(which could be the culprit, we'll see)

[DEBUG] Using transporter WagonTransporter with priority -1.0 for found it, thanks @alexmiller

it would be a very nice feature improvement if lein included which repo was the problem in it's error message 🙂

maybe I'll see if I can figure out how to add that and make a PR later

I have a PhD in obscure dependency debugging

yeah, that would be helpful

I have no idea what the root cause is, but I got errors early on with 'mvn install' on Clojure's source code itself with OpenJDK 8 and OpenJDK 10 on an Ubuntu 18.04 VM. Oracle JDKs worked better on the same OS in that regard.

nah, this is new stuff in lein that disallows http (not https) maven repos

which is nice, and I appreciate the feature

it's just really difficult to debug

that particular one is actually also available at https

@alexmiller yeah, I just had to add

["couchbase" {:url       ""
              :snapshots false}]

because whichever dependency was pulling in that repo had coded in the http version, so I have to hardcode an override in my project.clj

@ghadi I'm pretty sure 10. (openjdk from the ubuntu repos). Had to go back to 8, reinstall certificates and then go back to 10. Not sure what exactly caused the hiccup.

weird, 10 should be fine

anyone know if later jvms let you tune the method size limit. running into an issue where core.match expands into too large a method for the jvm to handle

I suspect those limits are actually backed in to the classfile format

@nickmbailey - one cause of this is mixing core.match with eg. core.async, and by using function calls you can pull it out so no one method contains code from both libs

hmm

i am using core.async but not within my match macro

other culprits include doseq or for

afaict its just a big match, if i comment out one or two clauses it compiles again

but not any specific clause

oh - worth mentioning the big macros in case that's the easy fix anyway :D

yeah i hunted around for some culprit like that 🙂

well i don’t think it’ll be too bad to split up into multiple functions

just figured i’d check if there was an ‘easy’ solution

depending how deep you want to go into this, there's also no.disassemble which will show you all the byte code emitted by a function - you might find a surprising thing you can make smaller

i am doing the match within a ‘loop’ block

maybe i can just pull that out to another function

that is an interesting little tidbit in the jvm spec

huh TIL

yeah moving the match block outside of the loop block fixed it for now. that match might grow so we’ll see how long it lasts haha

replacing destructuring with bindings to lookups can also help sometimes

ah thats good to know

doing a bit of destructuring in my match clauses

is there a function that I could use instead of conj here and that would give me the results you see in comments?

(conj [1 2 3] 4) ;; -> [1 2 3 4]
(conj [1 2 3] [4]) ;; -> [1 2 3 4]

(defn my-merge [item]
  (conj [1 2 3] item))

most of the time this means you could tighten up code elsewhere. ensure that code that uses this is aware that you prefer collections of things rather than an individual

so you’d recommend to stick to one type, right?

yes. you are dealing with individual things or collections of things. and make sure all producers/whatevers behave in that type

👍 thank you 🙂

sometimes I try to create a lot of unnecessary abstraction to save a few keystrokes but then I end up with these dilemmas. I should stop haha

i would make sure that you always know whether values are collections or individual values. otherwise there's lurking Don't know how to create ISeq from: clojure.lang.Keyword

i see a lot of that 😛

I have two projects using the same library, both using Clojure 1.9.0. One builds the library fine, the other throws "CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/ns did not conform to spec:" How is that possible?

Likely a dependency trying to use (require ...) instead of (:require ...) in the ns expression.

But which library...

one more question, if I may..

(def my-obj {:name {:first {:one "John"}}})

(defn get-obj
  [& args]
  (get-in my-obj (concat [:name] args)))

(get-obj [:first :one]) ;; nil
(get-obj [:name :first :one]) ;; John

can’t figure out why is that

even if I wrap that concat in vec, still doesn’t work

you're putting & args and then passing a single collection

choose if you want to (get-obj [:path :components]) or (get-obj :path :components)

if you put a (prn "args:" args) in your defn of get-obj you'll see what you are calling it with

@the2bears The require in the lib is definitely wrong, can't figure out why it doesn't fail in both cases.

Is the failing lib a dependency (with a newer, fixed version) of something else in the successfully compiling project? I'd check the deps with lein on each project. The failing lib is probably being brought in, up-to-date, by something else.

@dave.dixon Is it possible one of the projects is actually pulling in an earlier version of Clojure than you think?

@dpsutton sorry I mistyped there. I’m actually doing the latter (get-obj :path :components)

@dave.dixon Another possibility is that one project never causes the bad namespace to be required/loaded.

@seancorfield It definitely refers to 1.8. And both projects are loading the lib in question. Running both projects in the REPL, which reports Clojure 1.9.0.

Why my reversible collectin isn't faster then a non-reversible collection?

(let [p @sorted-set-with-1000-items]
  (prn (reversible? p))
  (time (dotimes [i 10000]
          (reverse p))))
true
"Elapsed time: 14603.556531 msecs"
=> nil
(let [p (seq @sorted-set-with-1000-items)]
  (prn (reversible? p))
  (time (dotimes [i 10000]
          (reverse p))))
false
"Elapsed time: 15057.406117 msecs"

can you throw a little context out?

@souenzzo I am pretty sure that if reversible? is true for a collection, it only means that it is likely to be able to do (rseq coll) faster than (seq (reverse coll)). reverse takes (at least) linear time and space for a collection regardless (see implementation of clojure.core/reverse function)

Yeah, doc string for 'rseq' promises constant time implementation for any collection where (reversible? coll) is true. reverse makes no such promises.

@the2bears The failing lib is the most recent version, and the only version referenced according to lein deps :tree

It depends on the underlying collection implementation righ? Got the following results comparing vecs vs lists:

(let [coll (into () (range 1e5))]
    (time (dotimes [_ 100] (reverse coll))))
"Elapsed time: 1329.904501 msecs"
=> nil
(let [coll (into [] (range 1e5))]
    (time (dotimes [_ 100] (reverse coll))))
"Elapsed time: 187.19594 msecs"
=> nil

I suspect that difference is not because one is O(n) time and one is O(n^2) time, but that reduce (used in implementation of reverse) is a significant constant times faster for vectors than for lists, perhaps because lists must follow an arbitrary 'next' pointer for each element, whereas the vector implementation is more cache-hit-friendly.

@dave.dixon weird, but having read @seancorfield's comments I think he's on the right path - something to do with 1.8 even though both REPLs show 1.9.

It would be awesomely nice if there were an easy way at a Clojure REPL to invoke 'time' or another macro like it, and get not only the time, but also the number of cache misses experienced during the execution of the expression given, and/or the IPC (Instruction Per Cycle, not Inter Process Communication)

Makes sense. And for reversing a reversible?, the rseq as constant time seems more appropriate performance-wise.

actually

it might be because (into () (range 1e5)) doesn't return a chunked seq

so it has to realize all 10,000 elements one by one

if you removed the into call the performance is similar to that of using a vector

I heard of this library criterium that improves on time approach. (http://clojure-goes-fast.com/blog/benchmarking-tool-criterium/)

yeah, criterium's awesome for real-world profiling

@the2bears Agreed. Not sure how that's possible, but it seems like the only explanation.

@dave.dixon If you have a :repl profile that is bringing in libraries, it could "correct" the 1.8 dependency.