is there a way to walk any arbitrary map/vector/map nested structure?

trying to get success generations of something like {:a "blah" :b :undefined} -> {:a blah :b [{:a "blah :b :undefined}] }

@albaker yes, walker does that

or you can define a more precise navigator using recursive-path

not sure what you're going for with that transformation, need more examples or explanation

@nathanmarz thank you. Got the select part right while tinkering last night, should have seen the view function pattern, guidance much appreciated.

@nathanmarz is there any way to refer back to a collect-one:ed value in a filter expression later in the path?

@mbjarland yes, use collected?

also see DISPENSE and with-fresh-collected

@nathanmarz fresh out the oven? these don't seem to be part of the online docs, will fire up a repl and take a look

@mbjarland not on the wiki but in the API docs http://nathanmarz.github.io/specter/

@nathanmarz basically want to run something like (transform walker expander-function) that I can repeatedly call until some notion of completion

where each transform has that {:a "blah" :b :undefined} -> {:a blah :b [{:a "blah :b :undefined}] } style replace a key in the map, or maybe nested map/vectors

@albaker you can use stay-then-continue to transform something and then continue recursing into the transformed value

e.g. (recursive-path [] p [(walker vector?) (stay-then-continue ALL p)])

but that'll walk vectors or also maps/vectors of maps, with vectors of maps, etc

that will walk all clojure data structures until it reaches a vector, then it will do the transformation and continue walking

if you want different behavior then you can encode that into your recursive path definition

so walker wants a predicate function that returns truthy for something you want to process

yea

ok cool, I'll give that a whirl

@nathanmarz if I am on a node which is a map and want to do a calculation on the values for two keys on that map, i.e.

(view #(- (read-string (:to %)) (read-string (:from %))))

take that back, figured it out, my bad

@nathanmarz so that works so well, I'm stack overflowing as the descent into the tree (or madness?) goes.. in this case, making a graph query to find more children until no more children can be had. Are there any gotchas (other then don't do that) to avoid in the transform?

I guess I could move the query into a core.async channel, so transform is just pulling from channels

@albaker specter doesn't use any more stack than you would expect

each level in data structure you go down during the transform will be another stack frame

yeah I suspect it's in the db client somewhere

don't know enough about your use case to give any guidance beyond that

I'll move the db client behind a core.async queue and leaves the transforming function only doing a quick put a thing on, get a thing back transaction and lets the db query run separately

don't feel like playing the "why I hate Apache HTTP commons today" game on why it's stack overflowing 😄

Does anyone have any suggestions for a faster clojure.data/diff? I don’t know if anyone’s e.g. tried specter for this (or if it’d even help). I imagine zippers might, at least. I currently have two mostly-similar nested trees (flattened about 2E5 entries) and clojure.data/diff just takes a very long time

I dunno if it matters, but the two data structures are very similar, deeply nested, and form a deep (as opposed to broad) tree