This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-03
Channels
- # aws (5)
- # beginners (67)
- # boot (30)
- # cider (55)
- # clara (7)
- # cljs-dev (6)
- # cljsjs (6)
- # cljsrn (1)
- # clojure (136)
- # clojure-brasil (2)
- # clojure-dusseldorf (14)
- # clojure-finland (9)
- # clojure-italy (49)
- # clojure-nl (1)
- # clojure-romania (6)
- # clojure-russia (4)
- # clojure-uk (16)
- # clojurescript (136)
- # core-async (1)
- # cursive (21)
- # datomic (64)
- # fulcro (26)
- # hoplon (25)
- # jobs-discuss (53)
- # keechma (3)
- # leiningen (6)
- # luminus (11)
- # lumo (2)
- # off-topic (351)
- # om (1)
- # onyx (11)
- # parinfer (32)
- # portkey (9)
- # re-frame (45)
- # reagent (38)
- # shadow-cljs (60)
- # specter (9)
- # vim (8)
- # yada (22)
is refactor-nrepl
a hard dep? I thought it was injected but I get a Exception in thread "main" java.io.FileNotFoundException: Could not locate refactor_nrepl/middleware__init.class
when launching with clojure-cli
. Possible problem?
only tools.nrepl
and cider/cider-nrepl
get injected
No actually once I add it to deps.edn
things have started working
the vanilla command was: clojure -Sdeps '{:deps {org.clojure/tools.nrepl {:mvn/version "0.2.13"} cider/cider-nrepl {:mvn/version "0.17.0-SNAPSHOT"}}}' -e '(require (quote cider-nrepl.main)) (cider-nrepl.main/init ["refactor-nrepl.middleware/wrap-refactor"])'
so no refactor-nrepl
in there
but you can see "refactor-nrepl.middleware/wrap-refactor"
in there
@richiardiandrea It’s a dependency of CIDER, but I think it’s almost a hard dependency of clj-refactor.el
. It has a separate setting about injecting it on cider-jack-in, which is t
by default.
Oh ok, it makes sense because I think I am not requiring that anymore 😄
@grzm There’s no special functionality about working with Java source files in CIDER.
@bozhidar so, if I have a repl open, and I make a change to a .java source file, how do I get that to be recompiled? Does that happen automatically?
@dpsutton If that's directed at me, I dunno. If I've tried this in lein before, it's faded into the fog of my memory
I don't know how to do it either. But cider just calls up lein and then has a few new ops in the nrepl protocol is all. I don't think there's a way right now
@ztellman’s Virgil reloads Java files: https://github.com/ztellman/virgil
@arrdem When do you expect to finish the REPL images functionality? As it stands it and @gonewest818’s work on the result/output truncation are the final two things for 0.17. 🙂
I was mostly off grid for a week of spring skiing, and now engaged in interviews (hire me!) as well. So time is tight but I’ll renegade hopefully over the weekend.
s/renegade/re-engage/
@bozhidar I'm honored. this coming weekend maybe, I'm up against a work deadline atm and taking the end of the week off during which time I'll probably not let myself have a laptop.
I rely on M-/ to autocomplete fn names and generally find that enough, but what I'm wondering if it's possible for that to work on a namespace, i.e. if i type some-ns/... anything after the / will not autocomplete because it is assumed to be part of the entire form (unless I've previously typed that entire form with the ns). Any way to get around this?
I'm not sure I follow. Can you explain with more concrete name spaces? Suppose your in foo/core.clj and you have another namespace called foo/bar.clj
do you use built-in emacs fn for autocompletion dabbrev-expand? if so, is there a way to get it work on a name, excluding the namespace and slash, such that if you have a (defn some-fn []...) you can get autocomplete on foo/some-fn which it normally will not do unless you have previously typed foo/some-fn somewhere
dabbrev-expand includes the ns and slash as part of the pattern match and therefore will not match on just the fn name after the slash. I'd like to type foo/so... and get it to autocomplete foo/some-fn
That’s CIDER-specific - generates completion candidates from the actually running REPL. It does’t get much better than this. 🙂
Trying to get my mind off some stuff at work and looking at adapting my REPL images changeset to sorta comply with https://tools.ietf.org/html/rfc1521#section-7.3.3 which seems to send a pair of content-type headers.
Eg. What my image display middleware really does is according to 1521
Content-Type: message/external-body; access-type=local-file; name="/home/arrdem/img.png"
Content-Type: image/png
In that the server is directing the client to fetch some other content, which has the SECOND type.I suppose it wouldn’t be wrong to do something like have an External-Body-Content-Type: ...
part, it just wouldn’t be to the RFC. But nREPL is a different protocol than mail transfer so it’s not really a problem, just need to pick something.
@cemerick would you choose a different structure here rather than trying to shoehorn MIME stuff in?
Sending along a mime type probably makes sense. I dont know hiw much the rest of the actual mime specs help.
Right so what I’ve got right now is an nREPL middleware which recognizes AWT images, and returns them as base64'd data with a MIME type. That totally works and is well explored.
The “problem” here is that I want to support rich content handling for files which happen to be images.
RFC1521 defines the above … dance for messages which want to refer to external message bodies.
Although I suppose that in the embedded nREPL case, you want nREPL to transport the file. Humm.
That's exactly what an early version of nrepl did, based on a set of capabilities the client reports upon connection.