Those are leinigen projects

So they don't have a deps.edn

{:paths ["src/clj" "src/cljs" "resources" "built-resources"]
 :deps {;; backend deps
        org.clojure/clojure {:mvn/version "1.10.3"}
        metosin/reitit {:mvn/version "0.5.16"}
        ring/ring-jetty-adapter {:mvn/version "1.9.5"}}
 :aliases {:shadow-cljs
           {;; The cljs path needs to be added here so that -T:shadow-cljs:build sees the frontend source
            :paths ["src/cljs"]
            :replace-deps {;; frontend deps
                           thheller/shadow-cljs {:mvn/version "2.17.8"}
                           org.clojure/clojurescript {:mvn/version "1.11.4"}
                           reagent/reagent {:mvn/version "1.1.0"}
                           lambdaisland/fetch {:mvn/version "1.0.41"}}
            :main-opts ["-m" "shadow.cljs.devtools.cli"]}
           ;; Usage: clj -T:shadow-cljs:build uberjar
           :build
           {:deps {io.github.clojure/tools.build {:git/tag "v0.8.1" :git/sha "7d40500"}}
            :ns-default build}}}

this is correct. clojurescript needs access to all your dependencies for compilation. so they need to be available in the build alias. or you shell out that also works.

Yeah, both work! I was more thinking about what's the right philosophy for build.clj. Using -T:build kinda points one at not having project sources & deps on the classpath.

PS. thanks for shadow-cljs, it's been a joy to work with. I'm never going back to cljsbuild 😁

I would recommend keeping the CLJS dependencies in a separate alias anyway since they are never required at runtime for the backend

so if they are separate anyways you can activate it for builds

Yeah that's what I'm doing. The separate alias is needed for running clj -M:shadow-cljs watch as well.

and since the uberjar is built using the root deps (or whatever you call them, anyway, no aliases applied), the frontend deps won't get bundled into the uberjar as jars

and that's exactly right

Hmm, looks like org.corfield.build/run-task would be the principled alternative to shelling out. Will try to remember that for future use.

Case is a different construct on the JVM. It's a jump table

yup you get constant time lookup

it compiles down directly to jvm bytecode dedicated to that (`tableswitch` iirc)

Thanks! This is for the Get started with Clojure Guide. If I'd like to both avoid lying, and getting to detailed with the poor beginner. How do you advice I should rephrase:

;; In fact, all conditional constructs (macros) are
 ;; (eventually) built using `if`. 

Hmmm, maybe I can just say, except case, which uses jump tables...

I am not sure I would mention if In theory you can do this stuff with and/or as well, maybe it's the case sometimes in core

> maybe it's the case 😃

🙂

Maybe something like: > There are only 13 builtin clojure constructs. All other constructs are defined in terms of the 13 builtin constructs. It turns out that even common constructs like and, or, when , cond, etc. aren't primitive, but are defined in terms of the more primitive builtin, if

and and or are built using if. You could technically use try and catch to make conditionals without if or case

Yes, that's what I am alluring to. I'm trying to explain that Clojure is built from these small building blocks. And this thing with if so beautifully illustrates it.

do not "try" this at home:

(defmacro try-if [test then else]
  `(try
     (throw
      (get {true (IllegalArgumentException.)
            false (NullPointerException.)}
           (boolean ~test)))
     (catch IllegalArgumentException e#
       ~then)
     (catch NullPointerException e#
       ~else)))

(try-if (even? 0) :true :false) ;; => :true
(try-if (even? 1) :true :false) ;; => :false

OMG. When new at the job at a Python house (long time ago) I found something ver similar to that in the code. When asking why (the hell), I got the answer that it was faster. Turned out it was true for some earlier version of Python, but utterly untrue for the version we were using...

Clojure exposes all the control flow primitives on the JVM - if, case, and exceptions. Most (all?) control flow macros on Clojure are implemented using if

Another if -less conditional

(defmacro fn-if [test then else]
  `(([#(do ~then)
      #(do ~else)]
     (compare true (boolean ~test)))))

(fn-if (even? 0) :true :false) ;; :true
(fn-if (even? 1) :true :false) ;; :false

@UK0810AQ2, was that a suggestion for how to phrase it? What's the distinction between conditionals and flow control here? I worded it like so.

;; Fun fact: Most conditional constructs (macros) are
  ;; (eventually) built using `if`.

@U0ETXRFEW not necessarily, more oriented towards elaborating and framing the discussion. In the end everything translates to jump instructions on the CPU, yet the JVM supports several constructs "natively" so Clojure supports all of them, too. I imagine if it targeted another platform to begin with it might not have had case. Regarding phrasing, you can take even a stronger stance: "besides case, all conditional and control flow constructs in Clojure are build using if"

not saying my phrasing is what you should end up with, but the idea is if builds everything besides case which is its own thing, and that's the entire world of control flow, unless you count exceptions and continuations in the mix

Thanks! I love your phrasing. Updated the dram now.

Solved. I wanted to say (-> 'foo resolve)

Right, of course, they offer atomicity. Will even enforce simple constraints

forgive me for thinking out loud here

I’m saying if I want to do (swap! db fn) and have fn throw an error if the state of things is not what the caller expected,

atomically

the normal thing to do here would be use a sql library to make sure this happens atomically

Please avoid crossposting. #beginners has more than 14000 members, it's more than enough for someone to give you an answer.

Thanks, will keep that in mind going forward

Not sure what you mean by 'everything-so-far, but maybe this is something close?

(require '[clojure.walk :as walk])

(defn preprocess [m]
  (let [m (walk/postwalk #(if (and (symbol? %) (m (keyword %)))
                            (list 'clip/ref (keyword %))
                            %)
                         m)]
    (into (empty m)
          (map (fn [[k v]]
                 [(keyword k) v]))
          m)))

(println (preprocess '{:comp-a (expr-1)
                       :comp-b (expr-2)
                       :comp-c (expr-3 {:comp-a comp-a
                                        :comp-b comp-b})
                       :comp-d (expr-4 {:comp-a comp-a
                                        :comp-b comp-b
                                        :comp-c comp-c})}))

I mean like - I want something like this

{:comp-a (expr-1)
 :comp-b (expr-2)
 :comp-c (expr-3 (EVERYTHING))
 :comp-d (expr-4 (EVERYTHING :after [:comp-c]))}

so in the first version this is the graph that is explicit with the refs

-------------
   /            |
A -             v
    | - > C - > D
B -             ^
   \            |
    ------------|

A 

B

(everything we can make) - > C

(everything we can make after C) -> D

It can't be just a function/macro because maps are unordered. You'd have to read the definition of that map, be it EDN or CLJ code, and then do something with it.

Or, if you're willing to get rid of the map and embrace e.g. kv-pairs, then it should be relatively trivial to implement with e.g. reduce.

well there is the notion that by putting it there it is by default "ahead" of the graph that doesn't participate in the system. I am willing to have a preprocess function crawl the values before passing to clip

I don't understand what you mean by your first sentence.

Unless you yourself control the config reading process, what you want cannot be done, that's it. That's exactly why it's bad practice to destructure within map destructuring while relying on previous destructure results.

like say A depends on B, C depends on A and B D depends on "everything before" so the question that is asked is "how many things can we make without involving D or anything that depends on D" and those become D's dependencies

So in

{:a 1
 :b (EVERYTHING)
 :c 2}

yes

I see. Sounds like this process should do it: 1. Set up a dependency graph with invariants based just on those :after keys 2. Do a second pass over the config and add all possible edges that won't create cycles 3. Topologically sort the graph

I made an issue on the clip repo - might be easier to do all that inside clip than outside (and its not a hugely pressing concern for me right now, just something that would be nice)

Thanks for the mention 🙂 Another thing you can pull apart is all the F/B transformations, i.e.

(defn fuzzer
  [n s]
  (fn [x]
    (if (and (number? x) (divisible n x))
      s
      x)))

(comp
 (map (fuzzer 15 "FizzBuzz"))
 (map (fuzzer 5 "Fizz"))
 (map (fuzzer 3 "Buzz")))

Or if you carry around the numbers and the "displayed" value, you can do something like:

(defn fuzzer
  [n s]
  (fn [[k display]]
    (if (and (number? x) (divisible n x))
      [k (str display s)]
      [k display])))

(comp
 (map (fuzzer 5 "Fizz"))
 (map (fuzzer 3 "Buzz")))

looks good, touches a lot of terms, hope audience will be able to keep track. If you find they're grappling with it, throw "operators fusion" at them

Thanks for the review! I'm going to keep most of it in the back pocket. The deck will have very little jargon and very much le codeauxes.

> Another thing you can pull apart is all the F/B transformations I was considering doing so, https://www.evalapply.org/posts/n-ways-to-fizzbuzz-in-clojure/#domain-driven-design-fizzbuzz, but the nil-punning was better for the or and juxt / some. Makes sense to bring it back in a transducer context. > carry around the numbers and the "displayed" value The https://www.evalapply.org/posts/n-ways-to-fizzbuzz-in-clojure/#peano-fizzbuzz works like that! Right now I've just pulled the professor card. Transduction of all the other fizz-buzz variants up-text is left as an exercise for the reader :)

The joy of public speaking adi! I like your writing :)

> The joy of public speaking adi! Mos def. Remote can be even more fun ... I had network outages in two different providers at two different locations. One in the AM at my place, which caused me to go to my friend's place. The second at my friend's place 5 minutes into my 20 minute demo. 🥲 But Plan B was already live (the blog post), and plan C was always on, viz. to do an in-depth recording anyway.

The prayer I said to the Demogods at the start didn't help :p

** Appease Demo Gods
   O Lambda the Ultimate,
   bless we who are in this demo.

   That our core be functional,
   and our functions be pure.

   That our data be immutable,
   so we may know the value of values.

   That our systems be composable,
   so they may grow and scale with grace.

   That their States only mutate
   in pleasantly surprising ways.

   That our networks & computers work,
   at least for 20 more minutes.

   For otherwise nothing lives.
   Nothing evolves.

   In the name of the alpha,
   the beta, and the eta...

   (λx.x x) (λx.x x)

Should have prayed to the omnissiah

different sense of "target" than a separate implementation, but if you haven't seen it, you should take a look at libpython-clj, a great project that offers, on top of all the great libraries in the python ecosystem, zero-copy interop with NumPy arrays. https://github.com/clj-python/libpython-clj The #data-science channel hosts a lot of discussions about the data science ecosystem in Clojure, including python (and R!) interop

Was looking at this project, it looks like you end up running a python process and a jvm process at the same time?

wow! thank you 🙂 I didn’t even think to search for something like this..

There's also the Clojure-inspired Hy: https://github.com/hylang/hy

I'm 12 years into using Clojure and didn't know you could put type hints on the parameters vector. And there it is, right in the docs.

Yeah, I definitely have the strong muscle memory to put it on the var still

Related https://gist.github.com/pjstadig/6fa4ebf465f6d438b4dcc2a5bfbb3db6