Clojurians Log v2

So this might be more of a tools.deps question, but I can’t figure out how to quote things properly. I’d like to put this in my ~/.clojure/deps.edn:

:jvm-opts ["-Dvlaaad.reveal.prefs='{:font-family \"Fira Code\" :font-size 20}'"]

Oh, this might actually also be a comma/space thing…

Well, this is a workaround, but it works:

:jvm-opts ["-Dvlaaad.reveal.prefs={:font-family,\"<https://github.com/tonsky/FiraCode/raw/master/distr/ttf/FiraCode-Retina.ttf>\",:font-size,20}"]

@flowthing Yup, in deps.edn you need , instead of space in :jvm-opts and :main-opts

(I've gotten so used to it that I also tend to use , on the command-line inside options 🙂

Yeah, using a comma solves the issue otherwise, except the "Fira Code" part, because I can’t use a comma there.

I just use it as a property in my clj alias...

clojure -J-XX:-OmitStackTraceInFastThrow -J-Dclojure.core.async.go-checking=true -J-Dvlaaad.reveal.prefs='{:font-family "JetBrains Mono Medium" :font-size 20}' -A:rebel:base:test

works grand 🙂

Yeah, that’ll work — I’d rather not alias clj, though. 🙂

meh

🙂

my full command is this

clj () {
	if [[ -z $@ ]]
	then
		command clojure -J-XX:-OmitStackTraceInFastThrow -J-Dclojure.core.async.go-checking=true -J-Dvlaaad.reveal.prefs='{:font-family "JetBrains Mono Medium" :font-size 20}' -A:rebel:base:test
	else
		command clj -J-XX:-OmitStackTraceInFastThrow -J-Dclojure.core.async.go-checking=true $@
	fi
}

Ah, good point on commas in an actual font name 😞

Not tried, but you may be able to use the alternative name

i.e.,

JetBrains Mono Medium (JetBrainsMono-Medium)

so either are valid

Yeah, that’s worth a try.

Fira Code Medium (FiraCode-Medium)

caveat, I'm on Arch Linux, not mac 🙂

This sort of stuff is also why we have a build shell script wrapped around clojure/`clj` so it can a) run multiple clojure commands from a single invocation and b) add JVM options via the command-line as needed 🙂

indeed, something I perfer, hence my tiny simple alias 🙂

No dice:

Execution error - invalid arguments to vlaaad.reveal.prefs/fn at (prefs.clj:38).
"FiraCode-Medium" - failed: valid-url? at: [:font-family :url-string] spec: :vlaaad.reveal.prefs/font-family
"FiraCode-Medium" - failed: system-font? at: [:font-family :system-font] spec: :vlaaad.reveal.prefs/font-family

For complex things, I have a bin dir in my project folder, usually with a build or prompt something

Well, the URL works, so it’s not a big deal.

(we're getting off-topic for Reveal 🙂 )

indeed 🙂

Some feedback for @vlaaad: being able to nav around the output panel in larger jumps would be really helpful. If I've eval'ing lots of stuff into Reveal, the cursor stays where it last was instead of moving to the end of the buffer, when is a pain when I've eval several giant maps. I can fn-down to page down but the cursor stays put instead of following the fn-down action so I then have to mouse-click somewhere in the visible area to get the cursor to move.

Being able to jump between matching () {} and [] would greatly ease that too.

I notice that alt/opt-up/down seem to jump multiple words, which is about the fastest way to navigate with the keyboard right now.

Also, is there a way to clear the output panel?

Not yet @flowthing He mentioned that he's had requests for that.

@vlaaad is there a Java .properties file that reveal will check for, in which we could put theme configuration? This would save putting it on an alias or command line and having to manage spaces. Thanks

I definitely miss being able to datafy things (there's only a nav option, and it does the datafy thing behind the scenes automatically on the enclosing data structure). And I'm already missing REBL's automatic "display as table" when possible for hash map and vector results.

Morning yall!

at least here it’s morning…

"FiraCode-Medium" - failed: system-font? at: [:font-family :system-font] spec: :vlaaad.reveal.prefs/font-family means system font uses a different name

Welcome to Thursday! 🙂

Thank you for feedback! I think I just got used to that, but now that you brought my attention to it, I agree — cursor should follow the navigation more. I’ll think about that

Yes, structural navigation is the next thing I’m planning to work on

Good point about troubles with escaping in jvm-opts, I’ll investigate other ways to supply configuration

there is datafy action available for objects if their datafication is different from the initial object (e.g. vars)

How does it detect "different"? I'm not getting the right result from Reveal's datafy for a JDBC Connection object -- it seems to do object reflection, whereas if I explicitly call datafy on it, I get the right thing (the protocol implementation from next.jdbc.datafy).

https://www.dropbox.com/s/g4hzw157mojyv00/Screen%20Shot%202020-09-17%20at%201.20.26%20AM.png?dl=0 If I use Reveal's datafy option, I get the result panel shown but if I call datafy directly, I get the hash map with :schema, :closed etc (shown in the output panel, below the connection object).

As a follow-up, here's a screen cap of the inline results in Atom, showing the two evals that were tap>'d into Reveal for the screenshot above: https://www.dropbox.com/s/7rgswf2118weo2t/Screen%20Shot%202020-09-17%20at%201.22.38%20AM.png?dl=0

You are datafying a class in a first screenshot

select #object[

I'm datafying a class explicitly for the hash map result shown tho'

Oh... OK, let me try. It seemed to jump over that...

Bingo! OK, that works. I'll have to watch for that...

If I have the cursor as shown here https://www.dropbox.com/s/oczgayt1tho9j9z/Screen%20Shot%202020-09-17%20at%201.34.51%20AM.png?dl=0 and I cursor down, I end up on the classname, not the object which was confusing.

If, instead, I use cursor right, I end up on tap> which seems kind of pointless, then cursor right and I end up on #object[ and then I can datafy it.

Yeah, I really should start working on structural navigation ASAP...

I'd probably be a lot less confused with that 🙂

What about the second half of my comment -- about automatically displaying a result as a table if applicable without needing to switch from the editor to Reveal, navigate to the last tap>'d value, pressing space, selecting view:table, and pressing return, and then switching back to the editor?

(it would need to be a transient result tab that was updated with each new tap>'d result)

@vlaaad I'm getting a lot of these warnings, BTW:

WARNING: Illegal reflective access by vlaaad.reveal.action$eval3927$fn__3928$fn__3929$fn__3933 to field java.lang.Class.enumConstants
WARNING: Illegal reflective access by vlaaad.reveal.action$eval3927$fn__3928$fn__3929$fn__3933 to field java.lang.Class.enumConstantDirectory
WARNING: Illegal reflective access by vlaaad.reveal.action$eval3927$fn__3928$fn__3929$fn__3933 to field java.lang.Class.annotationData
WARNING: Illegal reflective access by vlaaad.reveal.action$eval3927$fn__3928$fn__3929$fn__3933 to field java.lang.Class.annotationType
WARNING: Illegal reflective access by vlaaad.reveal.action$eval3927$fn__3928$fn__3929$fn__3933 to field java.lang.Class.classValueMap

(Java 14)

what do you mean by showing results as table? the table that gets a new row on every tap>?

or replace the whole table contents with rows/columns from the latest tapped value?

I mean a shortcut that basically does view:table automatically (if applicable) for every new result.

Which is what REBL does, essentially.

But it would be a temporary tab that would go away as soon as the next result came along. Which in turn would create a new tab for view:table if it was applicable.

In java-bean action I assume? I’ll have a look if there is a good way to avoid these warnings without compromising the ability to inspect objects…

In other words, for every result that could have view:table applied, do it automatically. It could be a mode selected via a JVM option -- it wouldn't have to be the default. Maybe :auto-table true in the prefs?

And the new tab created with the table view would automatically close (or just be replaced) as each new result came in.

hmm, good idea, I’ll think about that!

I haven't been using java-bean in the drop-down so I'm not sure what is causing it.

many thanks for your feedback!

That's probably the #1 usability issue for me, coming from REBL.

and your need applies to tap only, or to everything submitted to reveal?

I think "everything submitted to Reveal" makes sense -- since REBL does this for REPL values as well as submitted values.

I just confirmed datafy on namespaces is very usable. Slightly more work than REBL (again, the auto-table view thing) but acceptable.

(ok, I'm off to bed)

I hear you 🙂 I agree, Reveal requires more work to use than REBL because of it’s approach to inspection as an open set of actions, and some sort of automation would benefit it.

Good night!

ah, that’s interesting…

@seancorfield I made a new release — 1.0.130 — that fixes a bug with reveal's table view that I found while prototyping something that might be useful to you. With that version, you can evaluate the following:

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

(let [last-tap (atom nil)]
  (add-tap #(reset! last-tap %))
  (rx/view-as-is
    {:fx/type rx/observable-view
     :ref last-tap
     :fn (fn [x]
           (if (or (nil? x) (string? x) (not (seqable? x)))
             {:fx/type rx/table-view
              :items [x]
              :columns [{:fn identity :header 'value}]}
             (let [head (first x)]
               {:fx/type rx/table-view
                :items x
                :columns (cond
                           (map? head) (for [k (keys head)] {:header k :fn #(get % k)})
                           (map-entry? head) [{:header 'key :fn key} {:header 'val :fn val}]
                           (indexed? head) (for [i (range (count head))] {:header i :fn #(nth % i)})
                           :else [{:header 'item :fn identity}])})))}))

How do I use it?

(i.e., after eval'ing that expression, what do I do with the view?)

after you eval it, there will be an #object[blah blah blag] in the output. Select #object[ and choose view action

then try tap> -ing stuff 🙂

Got it! Oh, that is very nice. Yes, that's pretty much exactly what I was thinking of with the "auto-table" preference!

Yeah!!! That's much more REBL-like! Thank you!

...and it's possible today using default extensibility mechanisms 🙂

And how would I automate that so it always got eval'd and "view"'d on startup of Reveal?

and that is a story for another time 🙂

I agree, some sort of automation with regards to preferred views will improve Reveal, I'm not giving up on that

Is the view option in the drop-down, something that can be called in code? (I would assume so, but don't know where to start looking for that)

do you want to trigger that action from code?

I'm not sure this is possible from the repl. You need to get a reference to the ui function and then reflectively reach event handler, and then dispatch :vlaaad.reveal.ui/execute-action event

that's, like, super implementation details 🙂

Ah, OK. Then I guess I'll wait for this to get built-in as a pref that can be triggered 🙂

(and, meanwhile, do some of it manually)

I've pasted that code into my dev.repl ns at work so at least I have it easily to hand if I restart my REPL.