You have to start your loop in another thread. The easiest way is to do (future (my-background-code ...))

Wait, I'm not sure I understood this part > so I can eval functions called in the loop You want to be able to interact with CIDER while your rendering code runs in the background, right?

Correct.

Here's a simple example

(def state (atom true))

(defn do-stuff [a b ]
  (+ a b))

#_(defn do-stuff [a b ]
    (prn "doing stuff"))

(defn test-loop []
  (prn "started")
  (while @state
    (do-stuff 1 2))
  (prn "stopped"))

(comment
  (future (test-loop)) ; to start the loop
  (reset! state false) ; to stop the loop
  ;;
  )

I literally repeated what you did in the REPL and I see "doing stuff" being printed.

(of course I'm not printing things in a loop in the real code)

huh... I literally just ran the same 😕 but it didn't work

Try repeating this outside of CIDER, in a regular clj REPL

Maybe it's the printlns from the other threads that are being swallowed by CIDER, however I don't think it should happen

Did this in CIDER, works for me

(def state (atom true))

(defn do-stuff [a b]
  (+ a b))

(defn test-loop []
  (prn "started")
  (while @state
    (Thread/sleep 1000)
    (do-stuff 1 2))
  (prn "stopped"))

(future (test-loop))

(defn do-stuff [a b]
  (prn "doing stuff" a b)
  (+ a b))

When I do exactly that, the eval of the second do-stuff works and If i eval (do-stuff 10 10) I see the "doing stuff 10 10" output, but not the output that the loop should be generating

strange

This is on regular Clojure, right? Not babashka or something like that?

Try putting a println into the initial do-stuff, would you see the output?

i made a minimal deps.edn and tried it there, and it's working.. so something is wrong with my projects env I suppose

(it is regular clojure)

I bet that the output streams got messed up. That is the easier thing to break than the live recompilation functionality

You can replace printlns with another atom (say, a counter) that you would start incrementing in a redefined do-stuff . Just to reassure yourself

thanks for helping me trouble shoot this @U06PNK4HG I should have enough now to narrow down what the issue is.

Aha I was running the prod profile not the dev profile and prod has direct linking enabled.. that would do it :)

Hmmm, direct linking popped into my mind but I didn't voice it aloud. Good that you've found the culprit!

cider-debug can be a very useful tool to see what an iterative piece of code is doing. It automatically adds breakpoints and shows intermediate values as it evaluates each line of code.

I'm not sure if I'm understanding the question correctly, but you can compose transducers, so if you wanted to square each numbers before inc'ing it, for example:

(let [inc-xf (map inc)
      square-xf (map #(* % %))]
  (transduce (comp square-xf inc-xf) conj [1 2 3]))
=> [2 5 10]

i think it’s changing the shape of what’s going through. the classic refactor from a single arg to a map so you can pass more things through

i read it as starting here

(let [x1 (map inc)
      x2 (map inc)]
  (transduce (comp x1 x2) conj [] (range 3)))
[2 3 4]

(let [x1 (map inc)
      x2 (map inc)]
         (transduce (comp x1 x2) conj [] [{:x 1} {:x 2} {:x 3}]))

OK, let's have a look at this:

;; basic transducers
  (def transducers-1
    [(map #(+ % 1))
     (map #(- % 1))])

  (into []
        (apply comp transducers-1)
        [1 2 3])

  (def add-span
    (map (fn [x]
           {:span "some-span"
            :args x})))

  (def init-span (map (fn [x] {:span "some-span" :args x})))
  (def close-span (map (fn [x] (:args x))))

  ;; explicit case
  (defn wrap-span [f]
    (fn [{:keys [span args]}]
      (log/info args)
      {:span span
       :args (f args)}))

  (def transducers-2
    [(map (wrap-span #(+ % 1)))
     (map (wrap-span #(- % 1)))])

  (into []
        (apply comp (concat [init-span]
                            transducers-2
                            [close-span]))
        [1 2 3])

  ;; What I'm looking for is function `wrap-with-spans` to :
  (into []
        (apply comp (concat [init-span]
                            (wrap-with-spans transducers-1)
                            [close-span])))

I'm looking if wrap-with-spans function is possible that unwraps arguments for transducer from map, applies it to transducer and packs it back.

But actually that's only part of the story, since that's for https://github.com/alvinfrancis/opentracing-clj

so, I think (not a transducer expert) that it'd be necessary to turn wrap-span into a transducer so it can be comped onto another transducer

So it's more like

(defn wrap-span [f]
    (fn [{:keys [span args]}]
      (log/info args)
      (tracing/with-span [_ {:from span}]
        {:span span
         :args (f args)})))

so each transducer does not have a way of inspecting transducers which occur before it. Once you combine transducers with comp they become fully opaque. That said, it would be entirely possible to make a function which takes a transducer and applies it only to a wrapped element in a map.

I think it's not possible, especially with tracing/with-span.

(defn under-key
  [k xf]
  (let [inner-rf (xf #(assoc %1 k %2))]
    (fn [rf]
      (completing
       (fn [acc elt]
         (rf acc (inner-rf elt (get elt k))))))))

(sequence
 (comp (map #(-> {:hello %})) 
       (map #(assoc % :buz :quux))
       (under-key :hello (comp (map inc)
                               (map -)))
       (map #(assoc % :bar :baz)))
 (range 3))
;; => ({:hello -1, :buz :quux, :bar :baz}
       {:hello -2, :buz :quux, :bar :baz}
       {:hello -3, :buz :quux, :bar :baz})

For your example case of wrapping a span, you could also add logging or similar to the under-key transducer, although if you wanted logging for each individual step you would need to use it multiple times, as again, you can't peek into what's happened once comp is called. You could introduce your own comp function that would add in special things around each transducer though, much like what I have listed here.

With my under-key from above you could implement your wrap something like this:

(defn wrapping-comp
  [span-name & funs]
  (comp (map #(-> {:args % :span span-name}))
        (reduce comp (map (partial under-key :args) funs))
        (map #(-> % :args))))

you'd want to apply some function over funs before the under-key in order to add your logging and such

but this would do it

Hmm, let me have a look at this. Thanks! 🙂

the macro expander unconditionally rewrites (py. ...) to (new py ...)

same for any symbol that ends with .

Seems bad

Ah indeed:

bar=> (def py.)
#'bar/py.
bar=> (macroexpand '(bar/py.))
(new py)

https://github.com/clj-python/libpython-clj/blob/b25f3669095ca71008fe0d73455b1213d73fe001/src/libpython_clj2/python.clj#L651-L664

and getting around that is very challenging

user=> (let [f. (fn [x] x)] (apply f. [1]))
Syntax error (ClassFormatError) compiling fn* at (REPL:1:1).
Illegal field name "f." in class user$eval149
user=> (def f. (fn [x] x))
#'user/f.
user=> (apply f. [1])
Syntax error (ClassNotFoundException) compiling at (REPL:1:1).
f.
user=>

so you can indeed def a function with a name like f. but you cannot let bind such a name, and calling the function is tricky

Ah, fascinating

it is itself a macro

life finds a way

And they say Lisps have no syntax:)

This is a some code undergoing further change in 1.12 with qualified instance member symbols, although I’m not sure that makes it worse

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6977 does the macro expansion before the dot form rewrites

hm indeed:

bar=> (defmacro py. [])
#'bar/py.
bar=> (macroexpand '(bar/py.))
nil

still, don't know if clj-kondo should support (encourage) this

I guess "Symbols beginning or ending with '.' are reserved by Clojure." from the Reader spec is enough to say: just don't do it

The reader page says “Symbols beginning or ending with '.' are reserved by Clojure.”

Jinx

🥤

I guess clj-kondo could lint that ;)

And indeed we are expanding both of those cases in 1.12 :)

https://github.com/clj-kondo/clj-kondo/issues/2199

Looks like something that the Clojure compiler can itself warn about since leading and trailing . are unequivocally part of Clojure's syntax.

that would be too convenient

A man can dream 😄

For example, the compiler warns about non-dynamic earmuffed vars, so warning about the var name in def is not even new categorically.