This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-04
Channels
- # architecture (5)
- # aws (11)
- # aws-lambda (1)
- # beginners (108)
- # boot (11)
- # cider (37)
- # clara (19)
- # cljsrn (72)
- # clojure (170)
- # clojure-austin (2)
- # clojure-dev (1)
- # clojure-dusseldorf (2)
- # clojure-italy (1)
- # clojure-spec (41)
- # clojure-uk (24)
- # clojurescript (113)
- # component (2)
- # core-async (29)
- # cursive (9)
- # data-science (5)
- # datomic (72)
- # docs (23)
- # duct (61)
- # editors (1)
- # emacs (1)
- # events (5)
- # fulcro (77)
- # graphql (2)
- # hoplon (4)
- # jobs (3)
- # jobs-discuss (16)
- # leiningen (5)
- # off-topic (94)
- # onyx (37)
- # precept (5)
- # re-frame (17)
- # reagent (11)
- # shadow-cljs (18)
- # spacemacs (107)
- # specter (3)
- # unrepl (64)
- # yada (1)
@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 https://github.com/clojure-emacs/cider/pull/2069
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)
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
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#)
my-res#))
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?
@james-clojure if code ever threw an exception, you'd leave an open file. Which is bad afaik
@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))))
Now I need to look up how to avoid the "WARNING: > already refers to..." diagnostic I get when first defining these macros. 😉
Hmm, looks like it's an Open issue: https://dev.clojure.org/jira/browse/CLJ-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel