Perhaps this?

https://github.com/clojure/clojure/blob/master/changes.md#23-tap`tap>`, like, printf debugging done right? I’ve take it to be a thing you can do almost anywhere to inspect your values as the program runs. but also I’ve only used it with #C0185BFLLSE so far

Thanks guys. I suppose that's different from "step debugging"? I'm guessing this is the observation of live data while the program is really running?

yup, no interruptions from (tap> whatever)

Fascinating, I'm going to take a look at that

“no interruptions” was vague, sorry. from the docs: > The tap function may (briefly) block (e.g. for streams) and will never impede calls to tap>, but blocking indefinitely may cause tap values to be dropped.

The first time I tried tap> I was a bit surprised that (tap> whatever) doesn't return whatever. I was hoping I'd be able to apply it inline without modifying the behaviour of my program

(doto whatever tap>)

thanks @UK0810AQ2!

I'm late to the conversation, but I've found this invaluable for print debugging when it'd be awkward to wrap tap> or prn around forms https://github.com/weavejester/hashp

The nice thing about tap> (over any print debugging) is that it can send data to any tap listener, such as Portal, Morse, or Reveal so you can see that data as graphs or tables or structures or whatever -- and most of those will "watch" an atom too, I believe, so you can see it changing in real time. And you can have multiple tap listeners -- so you can add a print listener in addition to your graphical listener(s). I use VS Code with the Portal extension, so I have two "live" windows displaying tap>'d values: one displays all my program's logging (via clojure.tools.logging) as well as REPL evaluations, and the other displays any explicit tap> calls inside my program while it's running. I can even do that for remote processes too -- so I can use tap> on QA and production!

I've been keeping Cider's *inspect* buffer open for a cruder version of this (it auto-refreshes whenever I evaluatate something). But these suggestions here seem much higher powered

https://clojure.org/reference/datatypes#_java_annotation_support only deftype, defrecord and definterface support java annotations

defn defines anonymous class. AFAIK, there is no way to add annotations to it

yeah with new relic currently my options seem to be 1. defn the function with an apostrophe (eg my-function'), make one interface (with a method invoke matching the defn's arity) and one type implementing that invoke, which then calls my-function' and def my-function to call that invoke 2. deftype implementing IFn for the relevant arities then def my-function (new MyFunction) neither is exactly joyful 😞

https://github.com/quintype/clj-new-relic/blob/master/src/clj_new_relic/core.clj maybe there is an option 3

i guess yeah. their implementation is basically what i described with 1 just they're using one interface with a bunch of arities for invoke instead of one interface per function with just the relevant arities

I think you can also add a :gen-class to the namespace and attach metadata to the method generated during the aot process. I think you can do that without creating an interface/type first?

i don't think that's an option in this case. i can't expect every namespace defining a traced fn to gen-class

For New Relic specifically, we use https://github.com/RutledgePaulV/newrelic-clj which has a defn-traced macro, but I blogged about how we used to do that "manually" back in the day: https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/

Oh wow I didn't know about that library! I was considering rolling my own since both new-reliquary and clj-newrelic were dead. Good to know there's one maintained!

And Paul has been very receptive to feedback! We still have a few "native" New Relic bits in our code but have mostly switched out all our custom stuff to use his library instead.

Yeah I'll be switching over tomorrow if all goes well. Thanks for the intro! 👍

as-> could be used there - https://clojuredocs.org/clojure.core/as-%3E

Thanks! That looks perfect!

(let [new-db (-> db
                 (assoc :date date)
                 (assoc :location location)
                 (as-> db (assoc db :status (check-status db))))]
  ...)

(just to clarify what as-> would look like here)

Thanks @U04V70XH6!

if i add (.close doc) i never get this warning so i wonder what happens here

you can macroexpand the code to see what the end result is, but I think you need to move the doc (PDDocument/load in) into the with-open bindings.

with-open will only call .close on its bindings.

😇 you are absolutely right i need to put it inside with-open bindings, seems so obvious!

Thanks

protocol functions or multimethods would be a way to put a polymorphic step in there

Honestly, I would probably start with just doing multiple passes and see if it's actually a bottleneck. However, there are some libraries that can help here: • https://aphyr.com/posts/360-loopr-a-loop-reduction-macro-for-clojure (not necessarily transducer based, but still focused on a similar problem) • https://github.com/cgrand/xforms, usually, you can find any transducer related "missing pieces" here. Specifically, check out transjuxt.

this is a situation where doseq is more appropriate. map is lazy - the sequence of calls will not actually happen until the sequence is realized. frequently, when evaluating code in the REPL, people (myself included) forget that the "print" part of "read, eval, print, loop" is forcing the realization of a lazy sequence.

doseq is eager - it will start working "right away" and you'll see the intermediate results in the manner that I think you expect.

if you want something similar to map that's eager and returns the collection of results of the function calls, then mapv is an easy replacement.

That's good. Actually, I plan to use pmap to parallelize these calls. Is there any function I can use for pmap?

you'll see some extremely weird output if you try to use println with pmap, as multiple threads are pushing character streams to the default writer concurrently and their input will be interspersed. (try it with (doall (pmap (fn ...) ...) and see for yourself)

Also, I used mapvand realized that it would force the effect. Yet, it is unclear to me why the lazy mapwould not realize the printlncalls even these functions are being called.

Good... I will try (doall (pmap ...))and report back.

try doing (take 3 (map ...)) - it will show you that the lazy sequence is only evaluating as much of the sequence of calls as is needed, without evaluating the later calls.

https://clojure-doc.org/articles/language/laziness/

That's the part I don't understand. In my real example, these functions are processing files. Even these files are processed, aka, the functions are called, the println outputs are still not shown.

Funny things sometimes happen to println, especially in multi-threading situations or connected to an NREPL or both. Instead of println, you can try swapping an atom or using a Java logging library (e.g., via clojure.tools.logging).

Thanks the heads-up. It could well be the case. I will check out them.

@UFTRLDZEW I just tried (doall (pmap ...)) and it does not help. Still the intermediate output will only be shown after the whole evaluation is done.

> That's the part I don't understand. In my real example, these functions are processing files. Even these files are processed, aka, the functions are called, the println outputs are still not shown. > If you map over something lazy, then map's own laziness will prevent unnecessary underlying calculations. But if you map over something eager, it doesn't make that thing not eager any more. The eager evaluation will run first in full, and then map will lazily pick values from the result.