Clojurians Log v2

Down the road we might do a version of this that prints to a buffer and allows you to drill selectively into the traced output (something like the inspector in a way). Still, I think the recent improvements are pretty great, and of course now that the tracing code lives in Orchard it's easier to improve it. (unlike with the contrib libraries)

Drilling sounds cool 👍

I also don't use the tracer as much as I would like. Mostly because of the wall of text when data structures get larger. SLY seems to have a trace dialog which is integrated with their inspector: https://joaotavora.github.io/sly/#Trace-Dialog

is the tracing functionality more-or-less sayid? (i haven't used it in a while but by the time i feel i need it i have usually muddied through without)

It’s not - sayid is a lot more sophisticated, but it’s basically abandonware at this point. I never had much time for it.

I like the idea of using the CIDER inspector for this with drilling into details, and then spending time improving the inspector more.

I'm able to produce a (possibly deeply nested) map of interesting data trivially in Clojure as a user. But then to be able to inspect it nicely is kind of the most important thing an "IDE" could do.

Here's some context in a screenshot. I'm inspecting the app DB here in two ways, but both have some rough edges.

In the inspector example, you are supposed to click the value to the right, and then it will be rendered nicely

Since it always renders a "preview" of what the contents are, and that can not usually be nicely formatted, I think it keeps being a little bit confusing in then too. A regular "tree component" usually doesn't spend so much effort in showing the insides but allows one to just keep opening levels as needed. Like in this screenshot you can see it doesn't make the inspector much clearer?

Maybe it's for another thread, but it would be really nice to see some examples of people who find the UX works for them well. Maybe I'm just not familiar with it or doing something suboptimal. I feel like a good "inspector component" would be worth its weight in gold.

You can press C (Shift-C) to set the desired nested level to be printed. So you can go from this to this to this to this. You can always customize cider-inspector-max-nested-depth to set the default value so that you don't have to change it every time you reinspect.

Cool, that's a worthwhile tip indeed! I was reading this https://docs.cider.mx/cider/debugging/inspector.html and didn't realize that it's useful for this. Maybe some of those keys things are also out of date (should 0 and 9 still work?)

I'm free to suggestions how to improve the inspector; in fact, we're in a constant process of improving it – there is always something to do better.

0 and 9 do work in linear collections. Try inspecting an individual number in (range 100) and then you can go through them by pressing 0 and 9

Yeah, I first wanted to just point out that it could be an important part of CIDER, to show trace, profiling results, inspecting random user data etc.

The nicely formatted trace is something that I would see as an upgrade of the inspector, and then all is just plain old data to be looked at in the inspector.

Integrating tracer with inspector is not so straightforward (even though it may be considered). For the inspector to work for this, the traced function arguments and return values have to be retained in memory. Given that those objects can be arbitrarily big, such a tracer risks running the process into OOM in a general case.

Again, it may be possible to use weak references or some other safety net for this. Just some careful design is necessary for such a feature.

I guess my data is small since it fits my memory, so I tend to just trace data into an atom and then use multiple tools to visualize what is going on (e.g. trace stack and record execution time to have a flow graph and output with Graphviz etc.)

Sure; I also do that often (save function args into an atom and inspect the atom later). But in that case, I know what I'm doing and what the implications are. I also have an explicit atom that I can clear. If this were possible as a CIDER feature, it may not be so obvious for the user what is the cost and what are the dangers.

Here is an old example of what I make possible with it. So I kind of would like to see a choice of "side channel" where stuff can be output. It could be just stdout (with nice print) but could be an atom. At least I feel like for CIDER it could be just a value in the REPL it's running in.

Nice viz! The side channel that you describe sounds like tap>. I don't use tap> much, so I'm not fully aware how well CIDER leverages it, but I've seen there are a couple of integration points.

I don't use tap> either but I can see there is some similarity. I'm happy to use whatever mechanism CIDER would adopt.

My workflow is most often though just saving a random sexp with a hotkey, and using another hotkey to evaluate that sexp whenever I do changes, from whichever buffer I'm at now. And use the cider--pprint-eval-form to other buffer so I can "keep watching" the same result. Using the inspector instead would be what I'm thinking of an upgrade as long as it can provide me that useful drilldown. I haven't touched my workflow for some years so I'll try using the inspector more. Thanks for the tips.

BTW, by default, if the inspector buffer stays visible, the inspector should re-inspect any value returned by any CIDER eval command.

Pretty printing is convenient for cases where the printed data is exactly between being too small to need pretty-printing to being too big for the pretty-printed output to be useful. This is why the inspector is much better as a generic solution for any case. But there are still ways to improve its output.

Nice ideas. I will play with some of these in https://github.com/flow-storm/cider-storm/ which is a Cider front-end for the recordings made by http://www.flow-storm.org/ which already does the tracing part. Tracing as retaining pointers without serializing them in any way (unless when you need to deal with mutable values). FlowStorm currently records function calls, return values and all intermediate expressions in a timeline which also can be navigated as a call tree, which gives this "digging" already. All this (and much more) is already possible with the FlowStorm UI, but it would be nice to also have it available on Cider

@bozhidar done https://github.com/clojure-emacs/cider/issues/3737

it may be possible to use weak references or some other safety net for this@alexyakushev I remember exploring this path (soft references) some time ago, but I couldn't make it work when tracing a call tree, since there is a structure and dependencies between each fn-call/fn-return trace and their childs, so I couldn't use soft references for the nodes themselves. I also tried to use soft references for the value references instead of the tracing nodes, but then you can still get OOM, and a soft reference for each value pointer also has a lot of overhead

I've used it only a few times, and not in recent memory. The new version is still CLJ-only, right? Regarding the look, I would prefer a more compact look, even in my 32" monitor I sometimes run out of vertical space, never mind when I work from my 13" laptop.

Yeah, I think it's CLJ-only, nothing has changed in that department. Fair point about the vertical space. Initially, I wanted to make this spacious configurable at some point, but maybe a compact look is better and all that's needed.

> whether you ever use CIDER tracer I find it could only be useful in a very reduced number of cases, like when functions deals with very simple values like numbers. As soon as your functions receive and return complex data structures is hard to read. And it also mixes with stuff begin written to *out* . It is also easy to freez my emacs if it prints a lot.

All valid points! With one difference now: the new tracer uses orchard.print for arguments and results, so it should no longer freeze on huge/infinite values.

nice, those freezings are quite annoying

This sounds right - give me the trace as Just Data (TM) and I can use the Inspector on it

@ben.sless Good point. Please, open a ticket about this and we'll see what we can do about this.