Fork me on GitHub
Marcus Pemer08:04:52

Thank you @nathanmarz - after looking at the main I found a section that clearly documents this as well - this paragraph says it all: > When doing more involved transformations, you often find you lose context when navigating deep within a data structure and need information "up" the data structure to perform the transformation. Specter solves this problem by allowing you to collect values during navigation to use in the transform function. In retrospect I don't know how I missed it. Thanks again.


@nathanmarz is there any plan to publish 1.1.1-SNAPSHOT in clojars?


I’m having an issue in my reagent project where I’m getting atom updates unexpectedly. I tried to debug this issue by creating an Error object in my add-watch and printing out the stack trace, but the stack bottoms out at this line:$rpl$specter$$rpl$specter$protocols$RichNavigator$transform_STAR_$arity$4 ()
Any idea why I’m losing stack context beyond this line? I’d really like to figure out where in my code I’m calling specter that is doing this, but it is hard. I wasn’t expecting specter to be async.


@lee.justin.m there's nothing async or lazy about specter


whenever i have an error with an unexpected stack trace I look to see if I'm inadvertently using laziness somewhere


e.g. if you're doing (map #(transform ...) aseq) and not realizing the result until later on


thanks @nathanmarz. i’m probably misunderstanding something about laziness, but wouldn’t i see the lazy function at the bottom of the stack instead of seeing specter at the bottom? that’s the part that is confusing me.


hm, now that i’m saying this out loud, maybe its because i’m in a go block? that can shear stack traces.


not sure, I don't use core.async


ah yea that was it. the one piece of async code that doesn’t log. too bad my little stacktrace trick doesn’t work across async boundaries. sorry for the noise.