Fork me on GitHub

@richiardiandrea yeah, I should be looking up "fake.class.path" Thanks!


Looks like I'll be making .dir-locals.el files to specify cider-boot-parameters and add the appropriate deps there.


Oh not good. Cljc usage is in a poor state. Anytime a connection is determined by cider other connection it returns a random connection of that type that just happens to often be the correct one. Example you jack into fipp which has cljc files. You have another clojure script project open. Trying to load any file loads that file into your fipp clj repl and the cljs repl for your other project.


I've also noticed that C-c C-z doesn't always bring me to the appropriate repl. I wonder if they're related.


@dpsutton As I think you know we have a solution in the works


It was postponed for a while due to my desire to get 0.16 out of the door first, before making API changes, but for 0.17 that’s definitely on the table. Now it’s mostly up to @vspinu to get this to mergeable state.


Oh, cider doesn't support multiple connecitons at once right now? I thought I'd seen my colleagues do that :thinking_face:


Fwiw, Fireplace has a term it calls "scope", and you scope a connection to a directory/file. It doesn't expose it much, except for when you do a manual :Connect . By default it scopes to the auto-detected .nrepl-port on first action (e.g. when you do your first :Doc defn or similar)


@dominicm It does support them, it just doesn’t scope them very well.


That’s what this PR is about - a new way to bundle related connection together. When CIDER was created it didn’t support ClojureScript and cljc didn’t exist. The support for both of those was added on the simple connection API we had since day one and the result was a bit messy. Streamlining this in the next release is going to be huge everyone who’s doing more than Clojure development.


The fireplace design for cljs ended up ok, but I think it was difficult to get where we are. I'll have to look through this PR and see if there's any ideas to take.


I always have multiple REPL buffers open, one for CLJ and one CLJS in Cider against the same nREPL server. I also, often have other nREPL servers I’m connected to in other REPL buffers. I have never seen an issue with that.


It often behaves correctly. However if you jack into a cljc problem without clojurescript it will eval that clojurescript in a random cljs buffer from another project


I only found it last night. But the toggling isn't great either. And could be broken on account of this. I'll have to see. I might need to update it to be project aware


anyone else having trouble to get cider-find-ns to work?


oh, I guess it simply doesn't work with neither cljs or cljc


So, here's a silly question: how do I redirect stdin (`*in*`) to a file so my little program's read-line function invocations come from the file instead of my command line?


(I don't want to change the function -- I want the equivalent of sh's < test-file-0.txt.)


For now, I'll use , use the bound result in a binding [*in*] construct, .close the bound result afterwards, and maybe just wrap up all that stuff in a namespace of my own having such handy tools.


FWIW, here's what I whipped up to address my immediate concern (it's probably horrible but I wanted to play around with macros, so...):

(ns com.burleyarch.bash)

(defmacro <
  "Evaluate body with *in* bound to file"
  [p & body]
  `(let [my-in# ( ~p)
         my-res# (binding [*in* my-in#] (do ~@body))]
     (.close my-in#)
Use case:
(require ['com.burleyarch.bash :as 'bash])
(bash/< "path-to-file"  (print (read-line)) (print (read-line)) (print (read-line)))
That should print the first three lines of the file.


But I'm not sure whether I should really be using with-open in lieu of that first let's binding -- the macroexpansion suggests binding takes care of wrapping body in try...`finally`, so maybe the above is okay?


(Using with-open, I'd be able to forego the .close, of course....)


@james-clojure if code ever threw an exception, you'd leave an open file. Which is bad afaik


You mean if body threw an exception? Yes, that's what I'm worried about.


@james-clojure that's why to prefer with-open :) it's a good macro to rely on


Okay, will refactor accordingly. What I noticed is that binding expands to include this:

...try (do (quote body)) (finally (clojure.core/pop-thread-bindings))))...
But I'm not sure that means an exception in body will both pop the thread bindings and continue on to run .close outside the let.


In any case, I agree I shouldn't count on that behavior, and my macro is "obviously wrong" to anyone looking at it!


@james-clojure it doesn't have a catch, which means it's just doing it's clean-up, and then throwing the exception again.


How's this?

(defmacro <
  "Evaluate body with *in* bound to file"
  [p & body]
  `(with-open [my-in# ( ~p)]
     (binding [*in* my-in#] (do ~@body))))


The brevity is beautiful. I don't think you need the (do) fwiw


Ah, of course, thanks!


Now I need to look up how to avoid the "WARNING: > already refers to..." diagnostic I get when first defining these macros. 😉


You need (:refer-clojure :exclude [>]) in your ns definition