you can configure your exception handling so at dev time the unhandled exceptions end up in the response instead of the logs. I guess it depends on the stack, but can be accomplished by a ring middleware that you only add on the dev system

Alternatively, you can add an optional NREPL config to your server so you can REPL into it at dev time

This will depend on your setup, but if you use something like Component, you can call your server code from the REPL just like anything else: • start the system • call the http handler with the same request data that your client sends that throws the exception Or you can include exception info in the HTTP response - although that's not quite as interactive as the REPL-based approach

(Component is not strictly required, but it makes this approach a lot easier)

Interesting, i'm going to have to stew on this for a bit. I might be barking up the wrong tree a bit. I probably want to focus my efforts around being able to capture the state coming from the client, then just using that at points of interest in my application. The exceptions should get triggered if i do that. I think this is close to what Lukasz is suggesting.

@U0DJ4T5U1 I recentrly demoed how I do that kind of stuff with FlowStorm in a "Show me your repl" episode. The request exploration and handling is here https://youtu.be/2nH59edD5Uo?t=2288 maybe it helps you

There's many ways to capture incoming request - tap> def, an atom in your request handler namespace.

Ah, that YT video is basically how I work but much much much less fancy - just Monroe + nrepl

I do what @U0JEFEZH6 suggests: I start my server app from my REPL, and I use tap> very heavily with Portal. So I see all the server-side exceptions, and I can send requests and responses to Portal easily with a bit of middleware.

I concur with Sean, although I use Integrant rather than component (or mount / donut , etc) I have https://practical.li/clojure/data-inspector/portal/#repl-commands and it's a great experience. I also sent the mulog event logs to portal if I want more information

aggregating all strings is pretty easy to do with walk. I can post in a few minutes

(filter string? (tree-seq ... data)) should do it. Just gotta provide the right .... Probably (filter string? (tree-seq coll? identity data)).

nice tree-seq example, was just going to mention that

or use for

ok it works well thanks!

how would you use for ?

tree-seq but with more control

(fn f [m]
  (cond (string? m)
        [m]
        (coll? m)
        (for [i m
              ii (f i)]
          ii)))

i recently discovered https://github.com/redplanetlabs/specter and like it a lot so here you go...

(use '[com.rpl.specter :refer [select codewalker]])
(select (codewalker string?) {:hits {:hits {:_source {:name "John" :nickname "Also John"}}}})
; ["John" "Also John"]

very nice specter example, i didn't know that it had walking functions.

this is a walk version of what specter is doing

(let [data {:hits {:hits {:_source {:name "John"}}}}
      acc (volatile! [])]
  (->> data
    (clojure.walk/postwalk
      (fn [form]
        (when (string? form)
          (vswap! acc conj form))
        form)))
  @acc)

@U0LAJQLQ1 my apologies somehow i didn't see your question addressed to me when it was posted, and only see it today when i happened to scroll down on my slack threads. i am not sure what type of operation you want to perform, perhaps if you can provide some sample input and output data so that i can try to figure it out? (it had been a long time already, so feel free to ignore this message if it is no longer needed)

i don't know if a context based walk is something that can be done without a bit of a complicated walk, but it basically means that if you can identify a node, then you can tell when you enter and leave that node, so you can do 2 operations per walk. i use this a lot to build accumulators for things that i haven't built a proper graph out of (just regular clojure trees).

(defn- context-prewalk [before-f after-f form]
  (walk/walk (partial context-prewalk before-f after-f) after-f (before-f form)))

(defn materialize-type-hierarchy [o]
  (let [types (volatile! [])]
    (->> o
         (context-prewalk
           (fn [form]
             (match form
                    {:type ?type} (let [new-type (vswap! types conj ?type)]
                                    (assoc form :type new-type))
                    :else form))
           (fn [form]
             (match form
                    {:type ?type} (do
                                    (vswap! types pop) ;; assume that types are 1 arity
                                    form)
                    :else form))
           ))))

spectre walker/codewaker doesn't have context... to achieve what you described the spectre way, i think recursive navigator is the way to go https://github.com/redplanetlabs/specter/wiki/Using-Specter-Recursively

(ns rmain
  (:require [com.rpl.specter :refer [recursive-path collect-one keypath ALL if-path FIRST STAY if-path nthpath STOP transform]]))


(def TYPE-COLLECTOR
  (recursive-path [] p [(collect-one (keypath :type))
                        ALL (if-path [FIRST #(= :type %)] STAY
                                     [(if-path [(nthpath 1) #(map? %)] [(nthpath 1) p] STOP)])]))

(defn xform [& args]
  [:type (into [] (drop-last args))])

(transform [TYPE-COLLECTOR] xform {:type :a,
                                   :b :c,
                                   :d {:type :e,
                                       :f :g
                                       :g {:i {:j :k
                                               :type :l}}}})

; {:type [:a], :b :c, :d {:type [:a :e], :f :g, :g {:i {:j :k, :type [:a :e nil :l]}}}}

thanks! i'll try that out.

depends what your expectations are wrt concurrency

and ordering

right, that makes sense, since the result of the validate-fn would occur before the value is made available in the agent.

well, I think it's the opposite actually

iirc, the agent changes state and only after (outside that scope) notifies watches/validators

https://clojure.org/reference/agents covers the ordering

Thanks! I'll read over that.

it's been a while since last time

so validators are in the change scope so I think it would be generally bad for those to be effectful

makes sense. I'll go forward with not relying on a validator for reactivity then.

It's not wrong. At the very top, the page describes the terminology. Although it doesn't explicitly tell that "rf" stands for "reducing function".

ah okay. Good to know I haven't be passing off falsehoods on the interwebz

rf = reducing fn = the thing that transducers transform you'll also see xf for the transducer itself (in the signature of transducing contexts, like c.c/transduce)

It's reasonable to be confused by this because in many ways the terms are being overloaded with multiple meanings and reduction isn't in any way key to transducers. The 'reducing function' (also called a 'reducing step function' in other parts of the docs) isn't always what you'd think of as the normal arity-2 function passed to reduce itself. Take a look at the reducing functions in clojure.core - the 3-arity, innermost function returned inside all the transducers. They almost never do anything with result which would be the accumulator in a normal reduction - they just pass it on or return it. In fact, it wouldn't make much sense for transducers to do any sort of reduction because if they did, you'd no longer be doing a step-wise transform over a sequence, and you could just use normal function composition because you'd have a single value to pass forward. The reduced mechanism is only really used in transducers to short circuit, so even there the name clouds the meaning. The only time that something we'd recognise as reduction is happening is when you call transduce and specify a reducing function as its f argument. You'll have seen lots of examples with + as the reducing function because it handily returns 0 when called with no args, acts as identity with 1 arg, and reduces (actually reduces!) with two args. But instead look at sequence which can take an xform. It's implemented in Java code, but the inner reducing function it uses completely ignores the accumulator value! Everywhere you're using result inside a reducing function? It's just null and ignored. But sequence elsewhere stashes away the (transformed) output of the transducer stack and lets you have it back as a sequence. No reducing is happening, just transforming sequences. Elsewhere, into supports an xform argument - what's its reducing function? It's just conjing stuff back together! So to me, the interesting bits of transducers are that they give you an efficient and composable way of creating sequence-to-sequence transformations. Any and all mentions of reducers are necessary plumbing but slightly distracting from the core ideas.