cider 2018-12-06 | Slack Archive

It doesn’t work only in 0.18.0, as we didn’t account for this usecase.

The new eval dispatch refuses to eval stuff outside the context of your project (to prevent you from accidentally evaluating code against the wrong connection) and such third-party libraries were affected by this.

jumar08:12:13

I haven't been watching REBL closely but is there a possibility to integrate it with Emacs/Cider and, preferably, leiningen?

bozhidar08:12:15

Leiningen? By this you mean lein repl, I presume, right?

jumar09:12:18

I just mean that my project is based on leiningen and not on deps.edn - not sure if that changes anything or not.

jumar09:12:44

And I want to be able to send expressions from my editor to the REBL.

jumar09:12:13

I guess one thing is that REBL is only available as a local jar....

bozhidar08:12:41

You can run it from a REPL, so you’ve got some integration for free, but I haven’t used it and I don’t know many details. I hope that we’ll bring some of its features to CIDER’s inspector down the road.

jumar09:12:22

Ok, so I did this to install rebl into local repo:

mvn install:install-file -Dfile=/Users/jumar/tools/clojure/rebl/REBL-0.9.109/REBL-0.9.109.jar -DgroupId=com.cognitect -DartifactId=rebl -Dversion=0.9.109 -Dpackaging=jar -DgeneratePom=true

# Then in project.clj
[com.cognitect/rebl "0.9.109"]

Now launch the UI from the REPL:

(cognitect.rebl/ui)

I can "send" expressions to the REBL:

(cognitect.rebl/inspect (+ 10 20))
;;=> true

... but it would be nice to have better integration: just eval inside my emacs and having it sent to the REBL automatically. In the end, I think that having the features directly in the cider inspector can be more valuable - just wanna play with this REBL now 🙂

plexus09:12:07

meh I'll wait for the open source clone

bozhidar10:12:29

> In the end, I think that having the features directly in the cider inspector can be more valuable - just wanna play with this REBL now 🙂

bozhidar10:12:07

I share @plexus’s sentiment. 🙂 It’s a cool idea, but I don’t plan to use it, and unfortunately I don’t have time to work on a clone any time soon.

bozhidar10:12:23

I’m certainly someone will tackle this pretty soon, though.

dominicm10:12:32

I'm bothering someone here in JUXT. He's been working on stuff like REBL for years. Now there's helpers in core, he might be able to do something much better than before 🙂

plexus11:12:34

nav and datify seem pretty useful, and I guess it's great to have them in core so people are encouraged to implement the protocols in their own libraries, but it does mean anything you build with them is Clojure 1.10+ only. Had it been a library we could use it today on pretty much any version of Clojure.

rickmoynihan22:12:43

is this really a concern? Updating clojure is almost always just upgrading a coordinate and have it just work.

plexus07:12:28

It's a concern for library authors who want to support multiple versions.

rickmoynihan10:12:18

It certainly is - but the clojure community upgrade pretty quick if you look at the state of clojure surveys. I think this is a bigger issue for tool smiths than library authors though… but I guess this is #cider 🙂

plexus16:12:10

Exactly. For Kaocha I'm targeting 1.9+, which since it's a new tool I'm fine with not bothering about older versions, but I'm not planning to drop 1.9 support until 1.10 has been out for at least a year or two. That's just basic courtesy to your users.

rickmoynihan16:12:05

:thumbsup: ahh I’ve been looking at kaocha, it looks really nice… My understanding though is that it’s only been out a few months - do you think you’ll have lots of 1.9 users? BTW it would probably be pretty easy to target 1.9 and 1.10 — but conditionalise datafy/navify so you only get them if *clojure-version* is 1.10+

dominicm11:12:49

the metadata is quite useful to avoid it, because you can do:

(vary-meta '{clojure.core.protocols/datafy (fn)} [])

dominicm11:12:59

but otherwise you need to conditionally resolve the protocol

orestis11:12:43

The core thing in Clojure 1.10 AFAICT is the metadata-protocol-extension, so that you can actually call datafy and nav on everything, not just records. Everything else could easily live in a library, but would be much less useful.

bozhidar12:12:36

Yeah, the changes in core were absolutely necessary for this to be universal.

rickmoynihan23:12:28

Yeah it’s a big deal being able to hook a protocol onto a map, vector or set value. As it means just data can participate in a protocol now.

2018-12-06

Channels