This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-13
Channels
- # adventofcode (69)
- # announcements (1)
- # babashka (68)
- # beginners (37)
- # calva (3)
- # cider (4)
- # cljdoc (4)
- # cljsrn (1)
- # clojure (73)
- # clojure-europe (13)
- # clojure-nl (15)
- # clojure-switzerland (11)
- # clojure-uk (6)
- # clojurescript (14)
- # code-reviews (1)
- # conjure (1)
- # cryogen (3)
- # fulcro (32)
- # lambdaisland (8)
- # pathom (13)
- # reagent (6)
- # releases (1)
- # reveal (43)
- # shadow-cljs (9)
- # tools-deps (2)
- # vim (2)
Hello, I am testing reveal for fun, and I wonder if you were interested with some feedback or questions?
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?
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
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: https://vlaaad.github.io/reveal/#remote-prepl
> 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])
(add-tap
(comp
(reveal/ui)
#(rx/stream-as-is
(rx/horizontal
(rx/raw-string "=>" {:fill :util})
rx/separator
(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
Thanks a lot!
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.
Shadow-cljs supports prepl: https://github.com/thheller/shadow-cljs/issues/508#issuecomment-535866881
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 :)
I think I will check djblue/portal implementation and check if I can transport it to reveal.
shadow-cljs sends data through web socket to its inspects, maybe we can leverage that.
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?
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
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
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.
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.yes, imports without error
(Platform/startup #())
Execution error (UnsatisfiedLinkError) at java.lang.ClassLoader/loadLibrary (ClassLoader.java:2670).
no glass in java.library.path: [/usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]
That seems to be the proximate cause!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?
found this in cljfxapi. I suppose I will try suppressing platform initialization.
haha okay that certainly wasn’t it
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!