This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # aws (4)
- # beginners (55)
- # calva (13)
- # cider (58)
- # clj-kondo (59)
- # cljs-dev (4)
- # clojure (21)
- # clojure-austin (1)
- # clojure-dev (2)
- # clojure-europe (4)
- # clojure-italy (9)
- # clojure-nl (13)
- # clojure-norway (4)
- # clojure-spec (12)
- # clojure-uk (15)
- # clojurescript (22)
- # cursive (11)
- # datomic (3)
- # duct (1)
- # events (1)
- # fulcro (6)
- # graalvm (28)
- # hoplon (9)
- # jobs (2)
- # jobs-discuss (21)
- # mount (14)
- # nrepl (4)
- # off-topic (38)
- # pathom (1)
- # perun (4)
- # re-frame (17)
- # reitit (32)
- # shadow-cljs (44)
- # testing (7)
- # tools-deps (62)
- # vim (10)
What's the point of
partition was introduced in 1.0;
partition-all in 1.2. It's a subset of the functionality of
partition, with the exception that it can create transducers. But transducers weren't introduced until 1.7(?). So why does it exist?
partition will drop the last x items if the number of items is fewer then the partition size
I would like to make an appeal to seasoned Clojurists: please help with the Clojure Track on Exercism. It lacks exercises and mentors. Currently it takes from weeks to months to get your code reviewed. It's a great tool with a gentle pace, easy installation instructions and a nice interface, but it can only go so far. https://exercism.io
Is there a convention/guideline on function parameter order? Say I have a function that takes some state and some other arguments, and returns an updated version of that state (based on the values of the arguments). Should I put the state first or last? I know that for threading it doesn’t matter (since we have both
->>). I’m wondering what the consequences are in terms of using that function for “higher order” purposes, recursion, reducing, etc etc.
@stefan.van.den.oord common state update like functions (assoc, dissoc etc) have state as first arguments. whereas collection related functions (map, reduce, etc) have the collection as the last arguments. there is no big issue whether you choose last or first. however, the convenience comes into picture when you chain it with other such functions.
yup. All the sequence operations take the seq as the last arg, whereas the others take it as the first.
Exactly, so for my example I can expect more convenience putting it first then, I guess?
If you're treating your state as a sequence in that operation, then I suggest the last arg, else the first.
My rule of thumb is to generally order my fn args from least likely to change to most likely to change
is this expected:
(map #(%1 %2) '(first second) '((1) (2 3)))
NOob question here: I run LittleSnitch and was just notified that the code signature for java.clojure.main had been modified (I was notified when it attempted to connect to our nexus installation to pull dependencies via lein) Is it expected that that code signature would change? If not is there something I can do to remedy the situation?
I don't know what LittleSnitch is doing there, and a quick scan of its docs (I didn't read thoroughly) showed a mention that the dynamic code signature of a running process changes when/if it loads a dynamic library. There may be other reasons that can happen, too: https://help.obdev.at/littlesnitch/adv-code-signature
I just un- and re-installed java -- same version newer patch (1.8.0_211), and now my i've had to increase the timeout much more so that
lein repl will start. It's definitely the project because removing the
user.clj makes it start swiftly (in particular not loading figwheel-sidecar.repl-api in user.clj makes it go faster). However before reinstalling java it was much faster. Any advice on how to debug?
hi everyone, I have a very noob question but, I’ve been on this for a couple of hours and still stuck. I’m using docker to deploy an app with an deps.edn/uberjar but everytime I run the java command I get
Error: Could not find or load main class clojure.main
do you have in project.clj (assuming you use lein) somethink like this?
@miguelb doesn't that
USER invocation in Dockerfile change your working directory? Maybe try explicitly putting your generated jar in a system-wide place (eg. /usr/lib/...) and running it from there?
I guess if it didn't find the jar at all that would be a different error message though
I think explicitly putting things to be run or used at runtime into global locations is a good practice anyway (or if you intend for everything to run from a local dir, ensuring you execute everything from that same dir)
tools.deps is all about using dependencies as values, and RELEASE is a mutable reference