:jvm-opts ["-Dglass.gtk.uiScale=200%"]

@cb.lists That was real gold, now my REBL is scaled and usable on Ubuntu HighDPI

made it in my deps.edn file 🙂

@seancorfield BTW, thanks a million for sharing your deps.edn file on GitHub. That's a really good template to start with. :-D

Helo folks, new clojurian here with a (probably simple) question: given two maps with identical keys, I want to update the first map with the other map, by iterating all the keys so something like this: m1 {:a "A" :b "B"} m2 {:a "c" :b "d"} -> m1 {:a "Ab" :b "Bc"} . what the approach here? for ?

I have a record which I've defined with (defrecord Dfa ...). In my program I create instances of this record two different ways. First, from scratch using (map->Dfa {:key value :key value ...}) and also using an existing object such as (map->Dfa (assoc old-dfa :key value :key value ...)) . Now, I'd like to enforce some consistency within the object to prevent me from creating objects which don't make semantic sense. I can easily write a verify function which checks the interrelation of all the key/value pairs. But how can I ensure that that verification function is run every time a Dfa object gets allocated? One thought is to write a factory function. How can I a function which does either of the constructions listed above depending on whether an initial object is given. Given such a factory function I can of course call any consistency checking code I want, spec or otherwise.

Does anyone know of an overview of the performance characteristics of clojure's persistent data structures?

I'm messing around converting interview-style whiteboard problems from JavaScript to Clojure, and there's a whole lot of guff in the JS versions I suspect isn't required at all in Clojure

Could this be of interest to you? https://hypirion.com/musings/understanding-persistent-vector-pt-1 It also has a link to the paper by Bagwell.

thanks, I'll take a look

what does lein test do? I mean does it assume I'm using a particular Clojure testing framework? or does it try to figure it out? Or is my testing framework registered somewhere to enable lein to configure itself?

I have some test cases which are known failures. Is there a way to tell the testing framework that they are expected failures? I.e., they are documented loopholes in my implementation, which need to be fixed someday, but fixing them is difficult and of dubious importance.

When I use (for ...) to specify concentric iteration loops, I can decorate each level of the loop with :when, :while, and :let , but for as I understand always computes some accumulated return value. On the other hand if I want to iterate centric loops simply for side effect, such as test assertion, I can use doseq but then I loose the :when, :while, and :let , capability. Is there someway to tell for not to accumulate any values, but rather iterate for side effect only?

Can someone help me understand collection types here? Expected: #{{:order_number 1, :id "1234"} {:order_number 2, :id "435"} {:order_number 3, :id "34894"}}      got: #{[[{:order_number 2, :id "435"}]] [[{:order_number 1, :id "1234"}]] [[{:order_number 3, :id "34894"}]]} (using = ) What collections do #{{ and #{[[{ represent?

does run-tests suppress the stdout of the tests? Is there a way to run the tests and look at the stdout, i.e., the output of all my calls to println in the testing functions? It's curious, because sometimes the print messages seem to appear, and sometimes they don't. I haven't figure out what's happening. maybe I'm just confused?

Ahhh, perhaps I understand. The following prints nothing, but if I change for to doseq it prints. I think that means with for it didn't make any assertions, related to the fact that for creates a lazy sequence. right?

(deftest t-acceptance
  (testing "acceptance"
    (for [exit-value [42 true -1]
            rte '((:* Long)
                  (:* Short)
                  (:or (:* (:cat String Long))
                       (:not (:+ (:cat String Short)))))
            :let [dfa (rte-to-dfa rte exit-value)
                  dfa-trim (trim dfa)
                  dfa-min (minimize dfa)
                  dfa-min-trim (trim dfa-min)]
            seq-root '([]
                       [1]
                       ["hello" 42 "world"])
            reps (range 5)
            :let [seq-long (reduce concat (repeat reps seq-root))
                  match? (boolean (rte-match dfa seq-long))]
            ]
      (do (println [:match seq-long match?])
          (is (= match?
                 (rte-match dfa-trim seq-long)))
          (is (= match?
                 (rte-match dfa-min seq-long)))
          (is (= match?
                 (rte-match dfa-min-trim seq-long)))))))

Right

Hi guys, I have a fairly big question. I hope it's alright to ask this here. So some days ago I found myself in a new project which seems to scratch all kinds of AI, Logic and Optimization problems. Now, I'm not an expert in any of these domains, but I strive to be someday. Also, this is my first real clojure project. My immediate problem is something like this: > "For a room of the type 4 person office, I need a minimum of X m² as determined by a list of factors Y. Also, if a particular factor Y is chosen, it may have further constraints on the possible values of Z". > > Y could be some room/building structure, where if a particular structure is chosen I can further only place a subset of Z in it. I will have a bunch of (semi-)structured data, that I would need to store and query somewhere. This data forms a graph with probably thousands of edges. A simple blob of data could look like this:

{ :id   1
  :type :roof
  ;;...
  :requires 2}

{ :id   2
  :type :heater
  ;;...
  :requires [3 4 5 ...] }

as an anecdote, a common problem which happens to me which I discover when debugging Clojure programs, is that there are multiple false values. In Common Lisp there is only one false value. Thus in CL any two values which are false, are also equal. In Clojure two false values may not be equal because one is nil and the other is false. This causes subtle bugs in my programs. not complaining, just noting...

case in point how can I best change the following expression (map (group-by :accepting (states-as-seq dfa)) [true false]) so that all false-ish values are mapped to valse. I'd like to write something like: (map (group-by (compose :accepting boolean) (states-as-seq dfa)) [true false]) (fn [x] (boolean (:accepting x)))

(comp boolean :accepting) should work. comp applies the functions from right to left. https://clojuredocs.org/clojure.core/comp

ahh so the arguments are in the opposite order of the order they are applied. that makes sense and is confusing at the same time. 😉

@jimka.issy my a-ha moment was realizing that comp just deletes parens (fn [x] (f (g (h x)))) is the same as (comp f g h)

same thing, just less nesting

once I realized that, comp became my favorite thing

its a bit surprising that the function is called comp rather than compose , as if it is to be considered a function you should use frequently. constantly is not called cons and I use that function pretty frequently. na ya

I think partial, comp, apply etc. would be even more useful if they had terser shorthands / symbols

and IMHO if you aren't using comp constantly, you're missing out

I had a bad experience with compose several years back. A coworker wrote a relational algebra engine using extreme-scheme-ish programming full of invert/compose. It was really difficult to understand and debug. Of course I understand the temptation, as it is mathematically elegant.

Hello, please remind me ho to stringify such [object Object] printout in ClojureScript I use prn .

(str object)?

in many cases (.stringify js/JSON o) is the best result

if in a browser (.log js/console thing) can give the best results as well

Fun fact, i tried some of the editors, it seems the only thing that works as advertised is emacs.

emacs, vim, atom, intellij/idea, vscode all work

emacs might have a better pre-packaged working instantly out of the box experience, that wouldn't suprise me

it would surprise me if its the most easy to set up for a beginner to emacs

there's zero friction stuff like spacemacs

sorta. even those require some manual reading to learn how to visit a file. what m-x means, etc

but I agree with what I think is the mainstream take: don't learn a new editor in order to use clojure

for most people clojure has enough new ideas, a new editor too is a bit much

especially one of the weird old ones

My advice: if your current editor has a Clojure integration, use that while you're learning the basics of the language and then explore other editors when you want to look at changing/improving your workflow.

The key thing is to find a REPL integration for your editor that allows you to just eval the current form (or top-level form) with a hot key so it becomes second nature to evaluate changes in a file as you make them, rather than making a bunch of changes, then shifting to some separate process for evaluating code or running tests.

Corollary: avoid typing directly into the REPL -- put exploratory code in a file, inside a (comment ..) form for example, and evaluate from the file, "always".

Eg. You follow the advice at http://clojurescript.com and go ahead and install proto repl, only to find that it only works with shadow

Stu Halloway's talks on REPL-Driven Development and Running With Scissors are good examples of REPL workflows. Eric Normand's REPL-Driven Development is an excellent course if you're willing to spend some money.

Well i just followed the official docs, and it says proto repl there lol

@cancandan Can you provide a link? I was just looking at the ClojureScript getting started and I don't see it mentioned.

If I know which page it is on, I can submit a PR to fix it.

Sure https://clojurescript.org/tools/atom

I learned emacs with Clojure. I agree it was a steep hill to climb but I think it eventually paid off.

Anyone using Sublime Text? That’s my current (non-Clojure) editor, and I think I’m gonna have to switch.

@micah688 I can't vouch for it personally, but coworkers have used sublime-repl

I have a hunch that sublime might be behind the state of the art with tooling, but as a beginner and if you stick to lein at first, it should work as described

I’ve got a newbie question about holding onto your head - here’s the situation: I have a 900MB CSV file with a little over 3 million records. This file isn’t valid CSV because it’s coming from a mainframe report that’s sending a header and footer, a la ************ START ************ and so on. Also, the CSV file has headers, but they repeat in the file at the places it needs to be split. I managed to get it to work with data.csv, but I had to set my max heap size to 10GB, which makes me wonder if I’m holding onto a reference. This is the most recent thing I’ve tried:

(def comm-count
  (atom 0))

(defn group-id
  [row]
  (second row))

(defn commission-count
  [row]
  (if (= (group-id row) "GROUP") ; this is a header row, so it starts a new commissions report
    (swap! comm-count inc)
    @comm-count))

(defn by-agent
  [coll]
  (partition-by commission-count coll))

(defn write-file
  "Using the group ID as the filename, write out a commissions report as CSV"
  [coll]
  (let [[header & data :as table] coll
        group (-> data first group-id)]
    (with-open [w (io/writer (str group ".csv"))]
      (csv/write-csv w table))))

(defn process-file
  "Take a file, remove the first and last lines, group by agent, then write out a file for each agent"
  [file]
  (with-open [r (io/reader file)]
    (let [agents (->> r csv/read-csv butlast rest by-agent)]
      (dorun (map write-file agents)))))

small thing, you can replace (dorun (map write-file agents)) with (run! write-file agents) - doesn't address your issue though

I'm not seeing any obvious places where you are holding onto the head - btw. this might be a good thing to move over to #code-reviews

Thanks! I didn’t know there was a code reviews channel - I’ll put that in my channels list.

When should you use partial as opposed to a function that takes in arg and returns a new function using that arg?

For example:

(defn parse-term [index term-name value]
  (str term-name value index))

;; Using function above
(map-indexed (fn [index coll]
               (map (partial parse-term index) (keys coll) (vals coll))) coll)


(defn parse-term [index]
  (fn [term-name value]
    (str term-name value index)))

;; using function above
(map-indexed (fn [index coll]
               (map (parse-term index) (keys coll) (vals coll))) coll)

I have seen the second version, but never seen evidence it's useful

the exception to this is if you can pre-calculate something the fn would have to calculate twice - clojure doesn't do that partial evaluation for you, so it makes sense there

eg.

(defn parse-terms [index]
  (let [offset (expensive-calculation index)]
     (fn [term-name value]
       (str offset term-name value index))))

hmm so generally speaking using partial is the way to go?

using the anonymous function syntax is also common:

(map-indexed (fn [index coll]
               (map #(parse-term index %1 %2) (keys coll) (vals coll))) coll)

Thats what I had originally but wanted to avoid the anonymous fn and its % args so I figured to use partial. But I believe that partial returns an anonymous function as well so no real difference. Just style I guess

right - I always prefer partial over #(f x %1 %2) because that's what partial is for

it's the weaker tool, therefore better

weaker / more specialized

I'm inferring that the outer coll is a collection of maps. if that's the case, I would probably write something like:

(for [[i m] (map-indexed vector ms)]
  (for [[k v] m]
    (parse-term i k v)))

I always prefer (fn ...) or #() over partial :)

couldn't that be a single for?

actually, I don't know. I think I've confused myself

I tried that and it worked too

it should :)

I think the second iteration of the for loop actually works better in my case since it avoids a call to flatten

Thanks guys! :thumbsup:

@mario.cordova.862 a good rule of thumb is to always replace flatten with apply concat or use mapcat or for in the first place, I've never used flatten in a decade of using Clojure professionally

it's overly aggressive and leads to weird bugs if you change what's in your collection (which happens a lot)

What could be a good way to rewrite this code? The goal is to minimize compute(reuse data instead of computing it again) and to keep code as simple as possible. Ideally without examining very complex logic and proper sequence of computes and passing lots of arguments around. I was thinking of something like per-request core cache(some weird cache key names?) / memoization(doesn't seem to possible because compute result is cached infinitely).

(defn compute-metric1 []
  (Thread/sleep 1000)
  42)

(defn compute-metric2 [metric1]
  (Thread/sleep 1000)
  (+ metric1 24))

(defn compute-metric3 [metric1 metric2]
  (+ metric1 metric2 + 1))

(defn page [request]
  (let [metric1 (compute-metric1)
        metric2 (compute-metric2 metric1)]
    {:status 200
     :body {:metric1 metric1
            :metric2 metric2
            :metric3 (compute-metric3 metric1 metric2)
            ;; + a couple dozens more metrics like these
            }})

what decides the metric needs recalculation - is it a question of time?

yes, I can't cache it for long time, only per request

as far as i can tell you're only computing them once per request?

yes

and if you only want to cache it per request, and you're only computing it once, there's nothing to do

sorry, what I meant is that it needs to be computed only once but this function might be called 12 times in other metric functions

you can attach any key you like to a request

make a middleware that calculates the metrics (or better yet creates delays that are forcible but will cache), attach to the request object, and use them from the other functions

there's other middleware that does similar with eg. db connections

common pattern

that's interesting. Thank you. I'll try it

(defn wrap-metrics
  [handler]
  (fn [request]
    (handler (assoc request :metrics {:metric1 (delay (compute-metric-1))
                                      :metric2 (delay (compute-metric-2))
                                      ...}))))

(defn wrap-log-metric1
   [handler]
   (fn [request]
     (log :something @(get-in request [:metrics :metric1]))
     (handler request)))

if each request is only processed within a single thread, you could try something like:

(def ^:dynamic *compute-cache* nil)
(defn cached-fn
  [f]
  (fn [& args]
    (if-let [e (find *compute-cache* args)]
      (val e)
      (let [ret (apply f args)]
        (set! *compute-cache* (assoc *compute-cache* args ret))
        ret))))

(defmacro with-cache [& body]
  `(binding [*compute-cache* {}]
     ~@body))

(defn compute-metric1 []
  (Thread/sleep 1000)
  42)
(defn compute-metric2 [metric1]
  (Thread/sleep 1000)
  (+ metric1 24))
(defn compute-metric3 [metric1 metric2]
  (+ metric1 metric2 + 1))

(def compute-metric1-cached (cached-fn compute-metric1))
(def compute-metric2-cached (cached-fn compute-metric2))
(def compute-metric3-cached (cached-fn compute-metric3))

(defn page [request]
  (with-cache
    (let [metric1 (compute-metric1-cached)
          metric2 (compute-metric2-cached metric1)]
      {:status 200
       :body {:metric1 metric1
              :metric2 metric2
              :metric3 (compute-metric3-cached metric1 metric2)
              ;; + a couple dozens more metrics like these
              }})))

this could probably be turned into some kind of middleware