Clojurians Log v2

I’ve been thinking about that before 🙂 In general it’s not possible since we usually have repls that are unaware of reveal, e.g. how would you do that with remote prepl? Eval is in different process that has no way to access Reveal… But it’s possible to create local repls that ARE aware of reveal, and maybe built-in repl could have their eval augmented to access currently selected value.

Some possibilities • maybe a function call that just asks reveal what its currently selected value is • a reveal command that sets a callback to be called whenever the currently selected value changes. Then I can use that callback to put the latest value wherever it's convenient • Since it's only for development, it might it even make sense to intern a var in clojure.core like *r that gets updated with the latest selection. This option would make it easier to share workflows

Good suggestions! One reason I haven’t done this so far (besides higher prio stuff) is because I think there might be another way to

..oops, hit enter too fast 😄

Anyway, I think there is another issue that could be fixable with access to selection in one swoop: there is no sharing of bindings between reveal’s eval on selection and user’s repl

for example, using (prn *v) in eval-on-selection popup will print… somewhere, but not in Reveal’s UI, while using (prn :foo) with reveal-connected repl will print both to reveal and to process’ out

does reveal know what the currently selected namespace is?

nope, and this is another problem in this area

not sure it does, but if it did, then there could be an option to def a var in the current namespace

oh, bummer

but I guess *ns* is a part of those bindings

true

so if/when I figure this stuff out, maybe (def foo *v) will pick a better ns than clojure.core

like user , or ns that was active when reveal repl was started, or ns from latest eval… this needs some more hammock time

if you don't have enough options, you could also create a reveal namespace named something short like r or reveal. Then it's easy to use from the repl with r/*v , r/my-saved-val, etc.

you wouldn't even need to require the namespace since it would be fully qualified

so it would work regardless of which namespace you're working in

the main benefit is that you wouldn't have to add requires in namespaces just to access reveal values

the main downside is that short names are more likely to clash with common aliases

I just made a bugfix release — 1.3.206 fixes 2 issues: • attempt to print cancelled future threw exceptions • attempt to open a sorted map with non-keyword keys in a results panel threw exception

why not just a normal namespace like reveal.repl/*v ? Optionally other namespace / other name for *v. I woudn't consider (require '[reveal.repl :refer [*v]]) in user.clj too much of a hassle. I'm assuming it's not possible to connect multiple reveal processes? Caveat: Reveal noob, this might not make sense.

@teodorlu, for my personal workflow, I might be working in several different namespaces at once, so remembering to run (require '[reveal.repl :refer [*v]]) in each namespace I might be in adds enough friction that I probably wouldn't use it that often

hooking on what @teodorlu said, that could be a thing Reveal does, when the user changes the selection on reveal, reveal updates reveal.repl/*v (that value being an atom or something) to reflect that reference, maybe that’s what @teodorlu was saying

updating reveal.repl/*v makes sense. I was hoping for a shorter name for reveal.repl/*v like r/*v

@smith.adriane to deal with the long names I would make a live template (aka snippet) to expand something like rv to @reveal.repl/*v