This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-03
Channels
- # announcements (4)
- # beginners (68)
- # boot (3)
- # business (20)
- # cider (39)
- # cljs-dev (7)
- # cljsjs (1)
- # cljsrn (12)
- # clojure (122)
- # clojure-brasil (2)
- # clojure-italy (7)
- # clojure-nl (5)
- # clojure-spec (60)
- # clojure-uk (41)
- # clojurescript (67)
- # cursive (7)
- # datomic (13)
- # emacs (6)
- # figwheel-main (18)
- # fulcro (40)
- # garden (3)
- # graphql (2)
- # hyperfiddle (4)
- # jobs-discuss (10)
- # lein-figwheel (5)
- # leiningen (12)
- # luminus (6)
- # mount (3)
- # off-topic (52)
- # portkey (2)
- # re-frame (1)
- # reagent (6)
- # reitit (24)
- # shadow-cljs (15)
- # sql (3)
- # tools-deps (12)
Thanks @bozhidar.
Figured out the problem. Earlier I was using emacs from shell and now I started using it via the emacs App on OSX.
It turns out with the emacs app get different env variables from when you launch emacs from shell (it gets shells env variables)
Fixed the PATH and exec-path
and it works fine again.
@avichalp You should probably use https://github.com/purcell/exec-path-from-shell
When I jack in cljs or create a sibling cljs all goes well, figwheel starts, browser connects. The buffer modeline shows (cljs pending). But as soon as the cljs.user> promt shows the modeline switches to (clj) not (cljs). The repl works but cljs buffers modeline reads (ClojureScript cider[not connected] and trying to eval code responds "No cljs REPLs in current session". How do I tell the REPL it is a cljs repl?
I guess we really to implement some warning when cemerick/piggieback
is detected. That should help in situations like this one.
When doing cider-jack-in
in a deps.edn project, is there a way to specify aliases? I need to add some extra dev-only paths and libraries when in CIDER.
((nil
(cider-clojure-cli-global-options . "-A:fig")))
i've been using this in dir-locals @orestisWorks like a charm, thanks. I tried to look for clojure-cli
in cider’s source but github search wasn’t helping.
Related question, when I jack-in to deps.edn project, I feel very quickly that things start to become slow. The emacs process is taking 160mb and 11%cpu for very little things. Would it be more wise to start the project from the shell and just connect, any tricks like making the startup time longer for a performance gain?
Ok, one big piece missing, I'm starting many subprocesses from clojure, that may be the main cause actually...
@hlolli CIDER doesn’t really care how the server was started - it just needs a server to connect to. There should be no difference performance-wise between any of the different tools you can use to spin the server via cider-jack-in.
@bozhidar true, it's just that I was surprised that emacs started to become slow. But I believe the source is the java process, I try increasing memory and heap size in jvm-opts. So it's off-topic for cider. Cider rocks as always.
@bozhidar
> I guess we really to implement some warning when cemerick/piggieback
is detected. That should help in situations like this one.
Good idea. I was also bitten by this earlier.
what's the point of (put 'cider-jack-in-cljs-lein-plugins 'risky-local-variable t)
? It just makes navigation in dired painful for me
Generally, any variable that can cause foreign code execution should be marked as risky in Emacs.
Otherwise someone could hijack your computer by sending you a plain text file with local variables written at the end.
> Otherwise someone could hijack your computer by sending you a plain text file with local variables written at the end. @U051C77FP But those vars don’t really execute anything by themselves, and you’ll have to jack-in from that compromised file to cause any harm, which seems unlikely to me. There’s also the point that a similar argument can be made about any shell command that’s configurable, but I’ve rarely seen those marked as unsafe.
Perhaps marking a variable a variable as risky means that the user will never be offered the option of saving a value as safe
In that case I suppose the proper behaviour is to just NOT mark the variable as safe nor risky.
So you would still be prompted the first time, but then you'd have the option to save it.
Yep, this certainly makes sense to me. And maybe we can make those vars defcustoms and directly initialize them.
> Hm. Maybe I misunderstood the purpose of risky locals. To my knowledge only elisp code contained if vars/defcustoms is risky, because then it’s pretty easy mess someone up, as that code would immediately be executed. A classic example for this would be a dynamic modeline or something like this.