This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-01
Channels
- # babashka (2)
- # beginners (45)
- # calva (2)
- # cider (20)
- # clj-kondo (9)
- # cljsrn (1)
- # clojure (25)
- # clojure-europe (7)
- # clojure-nl (24)
- # clojure-spec (4)
- # clojure-uk (3)
- # clojurescript (16)
- # datahike (6)
- # datalevin (6)
- # emacs (35)
- # fulcro (3)
- # holy-lambda (1)
- # lsp (55)
- # nrepl (2)
- # off-topic (17)
- # spacemacs (11)
- # specter (1)
- # xtdb (3)
I'll admit, i have no idea what i'm looking at here seltzer. I do a lot of cljs work so i have likely forgotten some of the java~clj build story options. > It's a Maven archetype designed to put you in control. > > just project stereotypes > > developers to create a new projects, patterned for a specific purpose. > > just a maven pom that fits neatly within a current Maven DevOps pipeline system. Why do we need a maven file to, among other things, list a build directory when we already have deps.edn? So that build tools that expect maven poms dont get confused i suppose.
One of the big "pluses" for me about Clojure, right from the get go, was "no more Maven". Even Leiningen was a breath of fresh air in that regard and the CLI with deps.edn is even better. But if you live and work in a Maven-driven world -- and a lot of enterprises are like that -- and you're trying to introduce Clojure to a stuffy corporate Java world, having a full-featured Maven bridge to basic Clojure stuff is gold 🙂
I was more vauge on what it would mean before i learned more about how deps.edn projects work in practice, but now i am actually almost certain - deps.edn would be a better way to manage java projects
Why is specter giving me the reverse order of the collection in this snippet?
(specter/transform specter/ALL identity "123")
=> (\3 \2 \1)(specter/select specter/ALL "123")
=> [\1 \2 \3]it's not the reason for the underlying data structure choice but one is working on a vec and one on a list and conj does different things to each
(conj (conj [] 1) 2) vs (conj (conj () \1) \2)
conj on a list sticks it in the front, conj on a vec sticks it on the back
and so in both cases the values were conj'd onto their data structure in the same sequence it's just that the list one ends up being in reverse order because each entry is added to the front
if I'm in a situation where I have an agent nested inside of another agent, I should probably take a step back and rethink how state is organized in my application, right? am I correct in assuming it's a huge antipattern/source of ambiguity to have asynchronous state nested like this?
It is kinda weird but doesn't have to be a bad idea. See all of Erlang for counter example
if I had a supervisor tree like erlang's I could probably get a better handle on this tbh
to be a bit more specific, the thing that's making me nervous is that I have an agent in the interior state that is calling send-off to modify the exterior state of the agent that contains it, which seems bad and potentially extremely confusing to debug
Agents are called as such cause you can think of them as Agents that do things one after the other. You know for sure the Agent will execute all tasks in order they are received and you can await for them to be completed. So you could say have an agent that has a list of agents, and one of those agents could send a takes to the outer agent to remove itself or to add a new agent. I think such thing would be fine.
I ask because of a conversation in r/rust that makes me think about a package repository that enforces some minimum degree of what you want your versioning scheme to be and makes that visible.
what do you mean by "maven protocol"?