Just started #community-projects to curate projects that some of us from this group have going. I have been looking for projects to collaborate on so this would be cool for others on the same boat. 🚀

Anyone currently looking for collaborators on their project?

@sveri have you seen https://github.com/ajoberstar/ike.cljj? It has some stuff around Path

What is the simplest way to run f, n (100) times parallel? The f is making HTTP request and I want to test server response in easy way. I don’t want to spend to much time on that now to research some tools.

Since installing OpenJDK14 (was using JDK8) I now have to use LEIN_USE_BOOTCLASSPATH=no lein repl or I get an exception that I can't decipher (https://gist.githubusercontent.com/mmower/a01d6803eeb429c05676e2339676cada/raw/062e7b675d3a52f6e457d9781b939a4f66fd410c/gistfile1.txt) which seems to occur in Fipp but, from my searching, does not implicate Fipp. Is this normal? Should I expect to use this from now on? I confess I couldn't follow the discussion about what's changed/broken.

yes, you should expect this from now on. imho, lein should never have been using bootclasspath in the first place, and the ground is shifting in the jdk

this was always just an abuse of bootclasspath solely to shave a few ms off startup time

https://dev.clojure.org/jira/browse/CLJ-2426 is an occasional pain point for me, especially when interacting with 3rd party libraries that don't particularly use / are aware of metadata-based protocol extension It seems a quite simple bug to tackle, and also a frustrating one because it means that a newer, useful feature will be sort of a "second-class citizen". One would expect clojure.core features to play well with each other, offering a consistent experience It doesn't seem consistent to offer a feature but not to support it in some places?

this is not a simple bug and not even something that we're sure we want to do

I'd appreciate if these considerations were shared somewhere For example I take https://clojure.org/reference/protocols#_extend_via_metadata at face value - it offers me a feature, I use it. Maybe it's meant to be used very occasionally? Maybe it has some complexities that CLJ-2426 made evident? (So far I haven't come to actually think this. I have happily used both the feature and my own satisfies? with an extra check for IMetas. Sadly I cannot convince the world to use my own satisfies?)

in the case of external or direct extensions there are single categoric things we can check to answer the question of satisfies? (either an entry in the protocol data or instanceof Java checks). with metadata extension, you have to look up the protocol methods and check whether one? all? are present in the metadata, and you need to do this check before external extensions, so it has a potentially large performance cost to add this check (which is an existing separate issue)

in general, leaning on satisfies? too much is usually a smell - you should instead be leaning on protocol polymorphism to handle conditional cases

I added these comments to the ticket too

you can only use metadata extension if the protocol is declared to support it so this is not even an option in most cases

> so it has a potentially large performance cost to add this check (which is an existing separate issue) (what's the separate issue?) One can consider that satisfies? is an occasional tool and a pretty unlikely one to belong to high-performance code paths. If one was concerned with performance, I reckon one wouldn't use satisfies? to begin with? Favoring clojure's dispatch system instead

Is there a convenient way to get clojure.test to generate human-readable strings?

I wrote a (small) function to cache a function for a number of seconds (as defined by the function). Does Clojure (or a lib) already have this? Here is the code: https://gist.github.com/ivarref/a9592d3ef4b3fb6c03c6ca8cd2c3c210 Any thoughts or comments? Thanks.

let's say there is a package called x. now a process imports x and two other packages that depend on x (possibly different versions of x). will there be three separate instances of x running? will they be qualified through different namespaces/classpaths?

there’s some caveats here, but, essentially you can only have one version of a lib at one time

so which version is chosen if there is ambiguity? the latest one?

does it even choose? or does one mask the other?!

the job of your package manager is to pick one

that's the primary thing it does

lein, deps.edn, maven, etc. each have their own set of rules, and have ways of overriding those rules

outside of pathological conditions, or finicky special cases, there's no masking

they behave differently?

yeah

I googled around and I found this quote: > Leiningen and Maven, when there is a conflict always pick the version that is closest to the root of the dependency tree; where as `tools.deps` always picks the newest.

from https://github.com/RickMoynihan/lein-tools-deps

leiningen special cases clojure.core also

leiningen also lets plugins manipulate the dep tree (this can include overriding or removing deps)

tools.deps also allows exclusions etc.

deps.edn has profiles, but that only allows merge-over and accretion IIRC - you can't exclude in a profile something that was present in the base(?)

that might be true yeah

does it mean then that under the default behaviour of deps, a package might break if there is a newer version of its dependencies called by the neighbouring packages?

You mean if something else in your project is updated and now relies on a newer version of that shared dependency? Yes, that's possible. And it's possible with Maven-based resolution too.

If you have a top-level dependency on it, that version takes precedence in both Maven and t.d.a. resolution tho'.

(if I'm understanding your scenario correctly)

thanks

in practice this happens with the jackson library

often enough that I've in many cases migrated away from libraries because they use jackson

it's very rare in the clojure world to see this sort of breakage from anything outside jackson though

hello everyone, simple question: Im asserting stuff in test, basically comparing two maps, the on from sut and the other one is the expected value is there a idiomatic way of checking if on map contains the other? what I want to avoid is breaking that test when sut adds another key to the result

I have a submap? function I often use in tests

@plins, this recently came up. you may find the discussion useful, https://clojurians.slack.com/archives/C03S1KBA2/p1595479081182300

https://github.com/clojure/tools.deps.alpha/blob/master/src/test/clojure/clojure/tools/deps/alpha/script/test_make_classpath2.clj#L16

there's a lot of potential choices about how this works, and I'm not sure I've made the same identical ones every time I've used it, but maybe something that will ultimately end up in core or something

feel free to borrow and modify as you like

thanks everyone 😄 much appreciated

the version I usually use (in unit tests in particular) is (= (select-keys m2 (keys m1)) m1)

I usually wanted it for nested maps too though

oh - that's different, yeah

I'm working on an inherited codebase and I found some code for peeking/popping a Queue that is summarized in this StackOverflow answer: https://stackoverflow.com/a/29616612/4750575 Is this bad practice? It seems like totally incorrect usage of a ref -- there's only 1 identity at play, not multiple

(defn dequeue!
  "Given a ref of PersistentQueue, pop the queue and change the queue"
  [queue-ref]
  (dosync
    (let [val (peek @queue-ref)]
      (alter queue-ref pop)
      val)))

(let [q (ref clojure.lang.PersistentQueue/EMPTY)]
           (dosync (alter q conj 1 2 3)
                   (alter q conj 5))
           (fu/dequeue! q)
           => 1
           (seq @q)
           => (2 3 4 5))

@ccann Yeah, that seems excessive, but its not incorrect since changes to a ref are ordered

an atom would also work

but also so would just a regular java Queue

The code in question actually has an atom containing a map where the values are refs to PersistentQueues.

Every request thread dereferences the atom, finds the queue it wants to update, and then runs dequeue!

@emccue that code would be erroneous with an atom, a deref inside a function setting the value is a race condition

^(yeah, you would need to rewrite in terms of swap to use an atom)

I was thinking of modifying the code to just use swap-vals! on an atom containing a map with values of just PersistentQueues

eh, you probably still want a map of name -> stateful queue

but I'm not sure how to compare the performance of every thread swapping the same atom versus every thread dereferencing the same atom and then altering a queue ref

i'd say move all the queue ops to a single namespace as a start

make sure that noone is derefing the queue directly

then you can start to write an impl using an atom/arrayblockingqueue/whatever and do profiling

deref is cheap, swap and alter are slightly more expensive, especially if there is contention (multiple threads trying to set the same container)

IMHO the only reason to use refs (rather than an atom containing a map with all your values nested in it) is if there is too much contention / retry activity on the atom, refs allow coordination while reducing contention

but clojure apps typically don't demand that much of their mutable stores

I would definitely look at swapping out the usage of PersistentQueue for some java queue (linkedblockingqueue or whatever) if you don't need immutable queues

alright, will do

Not super familiar with the Java queue options and there seem to be quite a few

afaik the java queues are usually made for "multi write, multi read" stuff

linkedblockingqueue, dequeue! calls the poll method, and enqueue is the put method

done

I would even look at replacing the outer atom + map with a concurrenthashmap, if you are never using it as a value

when you nest mutable references (atoms, refs, agents, etc) like that, you mostly lose what is great about the clojure kind of identity model (mutable identities pointing to immutable values)

I made a comment on that stack overflow post with a pretty simple 1-1 with LinkedBlockingQueue