@deactivateduser10790 thank you for sharing your process! @smith.adriane No worries, Aero is just a detail we can ignore that for now. The general question is: is there a downside to adding the root of ones project to the classpath? I have everything working, but i’m just curious at this point :thinking_face: The driver of the question: io/resource would need the root of the project that in order to find a file at the root.

@tkjone my only thought would be whether having two roots that overlap (`.` and ./src) might cause issues. I don’t think I’ve ever dug into what the Java classloader(s) do in that case, let alone the Clojure classloader(s).

It’s certainly not done much in Java (or, I suspect, Clojure), so I would be a bit hesitant to do it, albeit without any specific objections to cite…

Good point and yeah it’s not something I’ve see either.

I have a pattern of many functions like this where the first two args are always the same spec, but the third argument varies (always a seq of at least two items, the first always being a keyword). Thus, it's the very last item in my spec ::proj where the variation will happen. Can s/cat be composed in a way that I can DRY this up?

no? I don't see any R to D

Another spec question: I was hoping (s/spec? ::my-spec) would work, but I see there is also get-spec . Is there anything that combines the two (returns true if the argument is either a spec or keyword for a spec in the registry)?

most other calls in the library can take a spec-or-kw param. I just thought spec? would do the same.

Don’t think so

I want to implement a CRDT in Clojure, specifically a LWW Element-Set (which is more like a hashmap). I'd like to have core functions like merge work on it, but conj would need to take a time that the k/v is true as-of. Does anyone have some advice?

I’ve thought about this a bit. I think you could handle this using a dynamic var & binding

something like:

(crdt/as-of (now)
  (merge my-crdt {:foo "bar"}))

if they need to be run in some kind of context i'd probably eschew the standard abstractions

(having thought about it for all of 10 seconds but that's where i am)

@lilactown that was my goto as well, although dynamic vars are always suspect for this kind of thing. They're noticeably missing from any core data structures for example.

I suppose you could get a new data structure by doing (merge (updating-to my-crdt (now)) {:foo "bar"}). There's a risk of someone accidentally reusing an old time they didn't intend I suppose.

that might be a decent way of doing it, yeah

dynamic variables have tradeoffs. there are performance & complexity implications that can detract from it. the benefit is that you can easily reuse core fns, and also provide runtime verification. e.g. you can throw if it’s not inside an as-of

you can also throw if you nest as-of

One problem with building on core is that you might violate expectations:

(defn foo [doc a]
  (let [x (merge doc a)]
    (is (true? (= (get x :a) (get a :a))))))

i’m not sure what would be violated in this case?

seems like you would want to maintain that semantic of merge

clojure.core/merge never removes an entry

merging crdts can

clojure.core/merge is about merging values, merging crdts is about merging the casual history of the crdts and constructing a new value that is the result of the merged history

yeah if the semantics are different I wouldn’t reuse clojure.core then

It's very convenient to have access to the wide array of key renames and such that we have access to via clojure core though.

There's only a handful of functions which modify a map and then read it back with assumptions it can read it's changes.

there are operations on the point in time value of the crdt, and there are operations on the casual history, I think you can potentially use the clojure.core functions for operations on the current value, with the implicit time of now, and then another set of functions for operating on the history

so clojure.core/merge of crdt1 and crdt2 would act like merging maps, ignoring the history that crdt2 might have a history of some keys from crdt1 being deleted

and you would have a crdt/merge (I've used join as a name for this in the past) that would merge crdts respecting history

it seems like what you really want is to be able to easily go to and from a hash map and a CRDT

rather than operating on the CRDT itself

i dunno

haven’t thought enough about CRDTs specifically

(-> crdt
    (as-of (now)) ;; returns a map
    (merge {:foo-bar}) ;; returns a map
    (->> (crdt/update crdt (now))) ;; returns the new crdt with the new value updated as of time `(now)

I'm possibly looking at something closer to an ORDT it seems. I can prune history pretty aggressively. I'm not looking much at the causal history. All operations are about adding information and only having it update if it's newer than what is already there.

last write wins, where the time varies per-key for both source and merge.

the causal history is what tells you what is newer

I don't think I've seen crdt datastructures that aren't last write wins, the way they are categorized is how concurrent operations are resolved (add wins, remove wins etc)