Fork me on GitHub
Endre Bakken Stovner07:08:54

I have a question about this let:

(let [response (try
  (msg/save-message! ?data)
  (assoc ?data :timestamp (java.util.Date.))
  (catch Exception e
  (let [{id :guestbook/error-id errors :errors} (ex-data e)]
    (case id :validation {:errors errors} ;;else
          {:server-error ["Failed to save message!"]}}))))]
Isn't the third line (assoc data? :timestamp ...) effectively a no-op? It just associates the timestamp and then discards the map...


Whether data? is defined as an atom elsewhare?

Endre Bakken Stovner07:08:40

Good question! But then one would need to use swap!, no?

Endre Bakken Stovner07:08:57

(defmethod handle-message :message/create!
  [{:keys [?data uid] :as message}]
   ... here the let begins


Doesn't seem to be a noop:

(let [?data {}
      response (try
                 #_(msg/save-message! ?data)
                 (assoc ?data :timestamp (java.util.Date.))
                 (catch Exception e))]
;; => {:timestamp #inst "2020-08-27T08:03:11.462-00:00"}
Simplified the expression. But the assoc returns the map and it gets bound to the response symbol.

Endre Bakken Stovner08:08:27

You are correct. It first saves the message and then associates the timestamp in the map which becomes the response.


Riddle me this:

(apply + '(95 85 734.45 99.6 15 33.71))


common surprise when first seen. tl:dr; can't represent all base 10 values in base 2 exactly so sometimes you get these seemingly strange results


That makes sense, thanks

👍 1

i think floating point addition isn't commutative either although i can't remember the examples. !(a + b = b + a) for all a,b in the floating point reals)


Associativity isn't guaranteed for floating points (in IEEE754 representation):

(+ 3.14 (+ 10e20 -10e20) )

(+ (+ 3.14 10e20) -10e20)


Ah thank you!


Some more details on floating point number representation and their properties are here, including a link to a longer article "What every computer scientist should know about floating point point arithmetic" (although skimming that article now, I suspect not every computer scientist really needs to know everything in that article -- some don't use floating point arithmetic in their work much at all):


i presume you don't need any of the following, but i was helped recently by: i found the associated presentation / talk to be better than a number of other things i had come across.

👍 1

It might not be obvious from the clojure docs but BigDecimal suffers from the same issues as double when trying to represent certain numbers; it's just that the BigDecimal can use all available memory if needed. The gotcha (sort of implicitly mentioned in the docs) can be see here:

(bigdec 1/3)
Execution error (ArithmeticException) at java.math.BigDecimal/divide (
Non-terminating decimal expansion; no exact representable decimal result.


I'm a little stumped by reagent at the moment. Why doesn't the following snippet trigger an update of my component?

(def data (r/atom nil))

(dom/render [some-component @data] dom-node)

(reset! data "new data")


Because your component doesn’t deref the atom it just receives a value. If you pass it in and deref there it should work


If some-component is a form-3, then how would I accomplish that? For example,


(defn some-component [g]
     (fn [g] (js/console.log "rendered") [:div])

     (fn [this] (js/console.log "mounted"))

     #(js/console.log "updated")

     #(js/console.log "unmounting")}))


derefing g in the render and mount methods don't seem to work, and neither does swapping g into a component-local atom


Deref the argument of the render function


G is a ratom and deref in the render function


Sorry on phone and missed what you said. I’ll check when I’m home


WOW thank you so much. Could've sworn I had tried that early on but must not have. It works now. I really appreciate the help with this

👍 1