Fork me on GitHub
David Pham13:12:55

Hello, I am testing reveal for fun, and I wonder if you were interested with some feedback or questions?


Hi! I'm very much interested in feedback and questions!

David Pham13:12:04

I really like it and I can totally see myself using it constantly next to my repl. I wonder what was the story with ClojureScript? Moreover, I wonder if we could add a few pixel in horizontal padding. Then finally, what are the possibles shortcut to navigate inside the reveal window? I think the simple navigation from vim/emacs would be great (`n` for next, p for previous, and q for exiting the result panel). Moreover, when you press enter to see additional views on an output in reveal, does it make sense to auto-complete with the single choice available?


What do you mean about the story with clojurescript?


Re padding: can you show me where you need it and why?


About navigation and shortcuts: I'm planning to make controls configurable, so you'll be able to customize keyboard shortcuts to be however you want.


I'm not sure I understand the question about action popup with single option... The text input there is not only an autocomplete filter, it also acts as a way to evaluate arbitrary code on selection, which means it should be there no matter the amount of actions available for particular object


I'm glad you like Reveal 😊

David Pham17:12:43

For ClojureScript: how does it work when you start a ClojureScript repl? Can you also use reveal with it? For the padding, if you evaluate (tap> 3) you see the 3 is glued to the left of the output panel, I had some trouble to read it, so having a small space might help. Thanks for the keyboard customization! As for the context menu, say you (tap> {:x 3}) and enter the context menu and desire to select view:bar-chart. At the beginning you have three choices, and if you start typing view:bar then you only have a single choice left, so I would expect by hitting tab to complete it (not to scroll down and hit enter).


Regarding cljs: you can't run reveal in the same process as js because those are different languages and runtimes, so you have to do a remote connection from reveal to cljs repl, this is described here:


> For the padding, if you evaluate `(tap> 3)` you see the 3 is glued to the left of the output panel It looks like you use reveal as a tap target? e.g. (add-tap (reveal/ui))? When using reveal repls/nrepl middleware, tapped values are shown as tap> 3 , so there is no glueing to the left.


You can use custom streaming for every tapped value, e.g. like that:

(require '[vlaaad.reveal :as reveal]
         '[vlaaad.reveal.ext :as rx])

         (rx/raw-string "=>" {:fill :util})
         (rx/stream %)))))


This will show every tapped value as a "result", so it will look like that:

=> 1
=> 2
=> {:a 1}


I think it's nice since it doesn't have any glueing and beginning of every value is clearly denoted

David Pham20:12:43

Thanks a lot!

David Pham21:12:38

so, just for sure, is it possible to have a CLJS nrepl then? Sorry for the silly question. I use shadow-cljs and I think it use a nrepl.


I know Reveal supports nrepl, but I don't know how it will work with nrepl that talks to shadow-cljs environment, I'd suggest to experiment with it :)

David Pham22:12:06

I think I will check djblue/portal implementation and check if I can transport it to reveal.

David Pham22:12:07

shadow-cljs sends data through web socket to its inspects, maybe we can leverage that.

Dane Filipczak18:12:39

I’m trying to integrate reveal into what’s potentially an unsupported setup, but wanted to see if anyone can see a way forward or an alternative. The application I’m trying to connect to is running in docker and I typically use a remote nrepl to talk to it. After adding reveal to the n-repl middleware, I get an error about not finding libx11 when trying to call reveal/ui. This seems pretty reasonable, as docker wouldn’t have access to native libraries. My naive fix was to exec into the docker container and apt-get install libx11-dev, which seems to fix the libx11 not found problem, but the same call to reveal/ui is now throwing namespace 'cljfx.api' not found. I’m able to require cljfx directly from the repl so I’m not sure what’s up here. I’m not sure if I’m close and should persist on figuring out this cljfx dependency problem, or if what I’m trying to do is fundamentally unsupported / insane. Anyone successful using reveal on apps running in docker?


Does this docker container run on the same machine you use for development?

Dane Filipczak18:12:56

yes, during the dev workflow I’m interested in


it seems docker does not have the concept of graphics, but it seems to be possible to make it somehow connect to x server on your machine

Dane Filipczak18:12:10

hmm interesting. Thanks for the lead! I’ll take a look


My pleasure! If you succeed, please make a write up or post a snippet you used, it would be great to know for other people that run docker in dev

👍 1

This is pretty similar to what you need when running Clojure/Reveal on WSL2 on Windows. You need VcXsrv (Xlaunch) running on Windows right now for X11 UI apps running on WSL2 to be able to display. I use VS Code on the Windows side with the Remote WSL2 extension so everything runs on Ubuntu (under WSL2) and when I start Reveal on Ubuntu, the UI starts on Windows via VcXsrv.


It usually spits out a warning or two about graphics libraries (something about Prism) but it works well enough.

Dane Filipczak20:12:32

thanks for the pointers yall! I’m able to connect to docker graphics via xquartz, but I’m still not quite able to get cljfx to load. When calling reveal/ui, it does a requiring resolve of cljfx/api, which throws

Syntax error (UnsatisfiedLinkError) compiling at (cljfx/api.clj:70:1).
no glass in java.library.path: [/usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]` 
I’m assuming this means that cljfx is making a call to native UI libraries on initialization that don’t exist in the docker container, although I’m not sure. Thought I’d drop it here in case it’s familiar to anyone. My use case is complicated by docker running within a vagrant vm (for… reasons), so after setting up the xqartz ssh fowarding and whatnot I’m out of time to fiddle with this for now. Hopefully will get back to it later.


can you do (import 'javafx.application.Platform) ?

Dane Filipczak21:12:12

yes, imports without error


and then (Platform/startup #()) ?

Dane Filipczak21:12:00

(Platform/startup #())
Execution error (UnsatisfiedLinkError) at java.lang.ClassLoader/loadLibrary (
no glass in java.library.path: [/usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]
That seems to be the proximate cause!

Dane Filipczak21:12:03

I suppose I don’t understand why a similar error wasn’t thrown on the initial startup of the application. Is cljfx starting a second jvm?

Dane Filipczak21:12:24

found this in cljfxapi. I suppose I will try suppressing platform initialization.

Dane Filipczak21:12:22

haha okay that certainly wasn’t it

Dane Filipczak21:12:34

going to do some research and try to understand some of the principles underlying the system lib calls and why they might be failing. Thanks for your help!


no, JavaFX does not start a second vm


hard to tell what's happening... perhaps cljfx is extracting native libraries it needs, but it does not work with docker's fs?


I know it extracts stuff to ~/.openjfx/cache


maybe ~/.openjfx has to be backed by a real folder in docker


on my (windows) machine, there is a glass.dll in ~/.openjfx/cache/${javafx-version}