It is answering partially for your question. It is possible to “manage” flyway from Clojure. deps {com.github.metaphor/lein-flyway {:mvn/version "6.0.0"}}

(ns db.flyway
  (:require [flyway.flyway :as fw]
            [api.db.postgres :as postgres]))

(def flyway-db (fw/flyway {:url postgres/db
                           :locations ["filesystem:dev-resources/db/migration"]}))

(defn restart-db []
  (fw/clean flyway-db)
  (fw/migrate flyway-db))

(defn wrap-test [tests]
  (restart-db)
  (tests))

(comment
  (restart-db))

ah, that's helpful, I think 'locations' could be a hook into it. I would need my own build/deploy scripts around this.

i’d suggest using https://github.com/yogthos/migratus. migratus migrations are just resources on the classpath

I have an example of using Flyway here:

ah I see, their docs didn't have it but the code can use classpath resources: https://github.com/yogthos/migratus/blob/master/src/migratus/migrations.clj#L106

fewer layers is nice

ya i think they’re assuming resources is already on your classpath (it’s a pretty standard top-level directory).

Did you profile it?

I just did a simple time with 2 reader func. How should I profile it?

Sorry, I don’t have time to analyse it deeper, but maybe one of this steps to improve performance https://clojure.wladyka.eu/posts/how-to-improve-algorithm-performance/ will be useful for you.

Time does not profile. A tool like clj-async-profiler will let you see where you spend CPU

There are things I can tell you to do which will make it faster but you won't know why

So profile first, understand what's going on, and then you'll be able to ask more relevant questions

unfortunately, I couldn’t profile because I’m using mac M1. Tried it with a Linux machine but hit some permission issues setting up clj-async-profiler Will try to find a linux machine tmr 😕

You can also try YourKit or Jprofiler

A few things to look at: Primitive type hints in the loop Avoid using r/map, you can map in place over the array Create a vector directly with vec and not into

So I tried with your suggestion: 1. Primitive type hints in the loop => this adds a bit of performance but not much (from 1564ms to 1445 ms) 2. Avoid using r/map, you can map in place over the array => I’m not sure what you mean by map inplace - is it? 3. Create a vector directly with vec and not into => So instead of doing r/map I used map and mapv . Pretty interesting mapv gives a 30% performance bump Here is analysis with time (still can’t run profiling 😞 )

Read an array of 47.040.000 elements
;; "Elapsed time: 1564.851583 msecs" (r/map without type hint)
;; "Elapsed time: 1475.194334 msecs" (r/map with type hint)
;; "Elapsed time: 1143.0205   msecs" (use mapv instead of r/map)
;; "Elapsed time: 6397.154542 msecs" (use map instead of mapv)

I'll profile it later today and upload the results here

And... mostly GC

what does that tell you? 🙂

Ah, seems like the data allocated is too large compared to the operation I do with it: which is only to-unsigned? This is one minor case where immutable is not shine?

It's okay but done pretty inefficiently, I'll profile allocation, too, see what's dominating it Also not sure if your test was reliable as partition is lazy, maybe doall should be called on it

yep, that partition is definitely lazy.

yes, it's bound during the load then that context is popped

thanks

I think I would normally turn it off. In normal Clojure programming, reflection is good for legibility & productivity at no cost to the results. Where reflection is a "legality" problem, Java will let me know.

> at no cost to the results The cost is performance and out of the box GraalVM compatibility

links to tickets? this is expected behavior, IMO

Yeah, I think it makes sense that if you have a sorted set, you must have only keys that are comparable to each other, and trying to dissoc something that isn't comparable with the keys erroring makes some sense.

other tickets related to sorted-map and exceptions: https://clojure.atlassian.net/jira/software/c/projects/CLJ/issues/?jql=project%20%3D%20%22CLJ%22%20AND%20text%20~%20%22sorted-map%20throws%22%20ORDER%20BY%20created%20DESC

sorted maps/sets are inherently limited to what their comparator can compare, and the default comparator is not a universal comparator.

I can understand after the fact why it would be throwing, based on an incompatible Comparator. But it surprised me that it breaks (in my opinion) the contract of dissoc. Also, there is no mention of this behavior in the docstring for either sorted-map or dissoc

I'm not sure that the door is fully closed on this, but in general we have not tried to "protect" users from exceptions arising from the use of key values not covered by the comparator

Yeah, I’m not claiming this is a bug, just asking. On the flip side, there is clearly no other option for assoc than to throw an exception. It would seem worse to silently not assoc in the case of a different key type

there's no way external to the comparator function to know what is allowed, so doing so would require try/catching around use of the comparator and falling back to some "not found" behavior

I think a note in sorted-set / sorted-map docstring would be justified

Yeah, I agree. Something like “Collection operations performed on the sorted map may throw exceptions if an incompatible key type is provided”.

or whatever 🙂

heh

thanks for clearing things up for me!

https://clojure.atlassian.net/browse/CLJ-2693

So you could do this by chunking a sequence and making a work queue with all the chunks in it, spinning up a thread pool to take chunks and chew through them with the predicate, and the first one to find something empties the work queue and returns the value to the original thread, but as far as I'm aware this has not yet been implemented and published anywhere.

Although personally I'd make this function return only true and false because multiple runs of it may return different values otherwise.

You could so something like this

you could turn that final loop into a go-loop in order to make this return asynchronously as well

if you want the impure "return a value that matches the pred" you could change the cond to save the result from some and return that after setting the work-queue to nil, change :else to return nil, and change the if at the end to be (if (some? res) res (recur ... instead

IDEA + Cursive currently, will probably switch to VSCode + Calva at some point.

https://www.surveymonkey.com/results/SM-S2L8NR6K9/ Question 16 of the state of clojure survey should offer some insight (Emacs, here)

Spacemacs (https://www.spacemacs.org) for me.

Emacs (+ Prelude) + CIDER + clj-kondo + clojure-lsp

I use doom emacs, which has cider, clojure-lsp, kondo, and the default way to do structural editing in doom is with lispy, but I really don't like lispy so I use evil-cleverparens.

neovim + conjure + coc

(and clojure-lsp)

I start with the latest git branch of emacs-28+native compilation+xwidgets with Mitsuharu Yamamoto’s patches for MacOS and then add CIDER, clj-refactor, smartparens (and an emacs config evolved over 30+ years). For those who are using clojure-lsp, what does it add over CIDER? how do you deal with overlapping features in CIDER?

these hands (and the same cider setup I had since 2014)

(x :k) - is it :k in map x or function x with parameter :k? (:k x) - it is :k in map x

instead of (k m) write (get m k) and everything is readable

for me personally readability is the priority

not number of chars

Yeah, so writing (map key) is fine. Writing (:key map) is fine. But in general if you're having generic keys I would prefer (get map key)

(def m nil)
(m :k) ;; java.lang.NullPointerException
(:k m) ;; nil

You could generalize this to a "safe invoke"

(defn call [f x] (if (ifn? f) (f x)))

@UEQPKG7HQ On your second point: all forms of map retrieval allow for a default value:

user=> (def m {:a 1})
#'user/m
user=> (m :b 2)
2
user=> (:b m 2)
2
user=> (get m :b 2)
2

Right, thanks for the correction (I updated my comment)! If m is a proper map but the key you're looking for is missing, my point is moot but if m is nil, you'd get a null pointer exception with (m :b 2) You're right though, in the core of it it's the same argument as nil punning, I just meant to illustrate a different aspect of it; the reader might expect that (m :b 2) and (:b m 2) are equivalent ("if :b is not found in m, return 2") when they're not.