Clojurians Log v2

Is it currently possible to use the reveal repl window in a program connecting to a remote nREPL server? (similarly how the -m vlaaad.reveal remote-prepl works, but for nREPL)

no

are you using remote-prepl already? 😄

I was considering some breaking changes there to make it more clj -X:alias compatible..

well, currently we have an app which is using the datomic peer api. it runs close to the transactor, on a machine with 80GB RAM. instead of exposing its functionality over some web or data api, i thought i would just expose that app over an nrepl server. however, i would like to use reveal as a UI for it, from other machines.

if you have remote process, it’s very easy to augment it to have prepl server, all you need is pass a java property on a startup, like -Dclojure.server.repl="{:port 8881 :accept clojure.core.server/io-prepl}"

since reveal is primarily the output side of the UI, i would still need to expose the process running reveal to an editor over some protocol, so i can send forms for evaluation to it

yes, i read the docs and that's why im asking how to do something similar but with nrepl (for example)

so assuming we have machines and processes arranged like on this diagram: https://excalidraw.com/#json=5642235093712896,jDMLGuoEuZIs2BqWlf0m5Q How can I make the result of a form sent from the IntelliJ Editor panel to be evaluated remotely in the Application process on the App server machine, appear in the Reveal window on the Workstation machine?

using the prepl client/server example from the reveal/README.md works, but only allows input from a terminal REPL

what a timing, I was experimenting with exactly this yesterday

hmm, not exactly this. but very similar

i was expecting to be able to somehow start a stock nREPL client, but with a/the Reveal nREPL middleware, but doing the from the command-line didn't open the Reveal window:

clj -A:nREPL -A:reveal -m nrepl.cmdline --middleware '[vlaaad.reveal.nrepl/middleware]' --connect --port 5555

u can probably tell that i still don't understand nREPL very well. i was trying to avoid understanding it deeper, but it seems it's unavoidable... 😕

so the benefit of creating this architecture would be that i don't have to convert my application logic to depend on the Datomic client API and I wouldn't need to bother with looking after Datomic peer-server processes. I have some Datomic transaction functions, which I must make available for the transactor, but I can test them locally a lot more directly if I can just stick to using the Datomic peer API.

I don’t understand nrepl well, and socket repls are very simple, so I’m trying to stick to those 🙂

Can’t help with nrepl, but I would setup this with socket repl like that: 1. Make app server run prepl socket server with this java option -Dclojure.server.prepl="{:port 5555 :accept clojure.core.server/io-prepl}" 2. In intellij: create local repl run configuration with clojure.main/run with deps, select aliases that put reveal on a classpath, and in Parameters section add -m vlaaad.reveal remote-prepl :port 5555 :host app-server-host

I’m going to write all this in reveal docs for 1.0 release

I’m currently in the process of figuring out various ways to setup of reveal

i would be happy to proof read 🙂

these new command-line options are very exciting, right? hopefully, they might allow quite some simplifications in the ways how one can integrate reveal.

And by the way, this is working, but a limited way to run reveal. Reveal shines when it runs in the process that is being developed, because it has references to all the values in the jvm process. When reveal has to cross process boundary, all it has are deserialized responses from the remote process, so it can’t watch the atoms, see the classes etc.

ah, and don't forget to fully qualify lib names, even in the examples! for example, nrepl is not fully qualified here:

clj \
-Sdeps '{:deps {vlaaad/reveal {:mvn/version "0.1.0-ea25"} nrepl {:mvn/version "0.7.0"}}}' \
-m nrepl.cmdline --middleware '[vlaaad.reveal.nrepl/middleware]'

it’s all going to be in documentation 😄

oh right, I forgot about the examples 😄

ah, i see... well, what u just said, has already helped me a lot! i guess, in that case, i will have to transition to the datomic client api after all.

I used datomic client api with reveal!

it’s nice — datomic client api adds datafy/nav metadata to its values, and reveal can use those to explore more data at the repl

what are you using in your tests to test datomic related code? dev-local? https://github.com/ComputeSoftware/datomic-client-memdb ? https://github.com/ComputeSoftware/dev-local-tu ?

u should do a quick screen-cast about that datafy/nav experience! that would quite revealing for many ppl! ;D

and thx for mentioning that; one more reason for transitioning to the client api then

I don’t use datomic currently, but previously we created throwaway databases in prod for integration tests :D

but now that they released dev-local I’d probably try to integrate that

> u should do a quick screen-cast about that datafy/nav experience

> I’m planning to do all that for 1.0 😄

god damn it slack

like feature use examples

here is a little gem for Datomic Peer API users:

(defmethod vlaaad.reveal.stream/emit datomic.db.Db [db]
  (vlaaad.reveal.stream/emit
    {:basis-t (d/basis-t db)
     :db-id   (:id db)}))

playing with reveal again (I tried it out very early on), and I had a couple questions

watching the latest and all versions of an atom is very cool, is there a way to apply a transform (like a table of a subkey) and making that live too?

and is there a way of doing the same thing as watching an atom without using an atom? i.e. submitting new values to reveal and having them behave like it was an atom update (so I can see the latest or history)

1. regarding views over refs — I think it's a cool idea and I did it a couple of times. Don't remember why I haven't committed anything related to that to reveal, I think I wrote a buggy implementation 😄 But reveal ref watchers work on anything implementing clojure.lang.IRef interface, so there might already be some cursor implementations out there that you can just use. 2. you can use reveal as "output panel" that you submit values to by yourself — see vlaaad.reveal/ui function

regarding #2, is there a way to clear the panel?

programmatically, I mean

nope

oh, wait, programmatically

yes 😄

but not when you have window created by vlaaad.reveal/ui

ah

is there another way to make a window?

I was imagining for #2 above, writing code that made a window and then when new values came in that I want to display, clearing the window and then sending the new value, so that the window is always only the latest

well that's what built in watchers in reveal do

the ref watchers?

watching the latest and all versions of refs

not only atoms, but also vars, agents etc

great, I'll check it out later today