Re: Idiom question

[Alan Thompson]

The idea of the `it->` operator in the Tupelo library
 is basically
just a combination of the explicitness of swiss arrows and the pronoun `it`
from Groovy.
Alan

On Fri, Sep 30, 2016 at 2:00 PM, Stephen Spalding 
wrote:

> The semantic of the swiss-arrows 
> -<> macro are nice. It's like as-> except that the operator is
> automatically specified as <>, and it has a default position.
>
> Your original example would become:
>
> (-<> blah
>  (do-this)
>  (do-that arg)
>  (do-the-other a1 <> a2))
>
> The combination of a pre-specified operator and a default position  makes
> it so handy that I often wish there were a built-in equivalent.
>
> On Wednesday, September 28, 2016 at 6:10:05 PM UTC-4, pa...@pwjw.com
> wrote:
>>
>> All very interesting, and Sean that first/or threading pattern is very
>> helpful.
>>
>> @puzzler - totally get that the language is extensible yup and appreciate
>> the mainstream warning. When I read your cond-better version I got it; and
>> I also thought "a return statement like thing could be useful in a
>> construct something like this" and then remembered just how far the macro
>> system in lisps lets you go, which was really instructive.
>>
>> The patterns here are very useful. Thanks again to all of you who offered
>> up tips so far.
>>
>> On Wednesday, September 28, 2016 at 5:53:10 PM UTC-4, Sean Corfield wrote:
>>>
>>> Ooops, should be:
>>>
>>> (defn has-transmitters
>>>   [^MidiDevice device]
>>>   (<= 0 (.getMaxTransmitters device)))
>>>
>>> And if we made a helper for open-device, we could make it return the
>>> now-open device and then you wouldn’t need the doto – just call
>>> (open-device).
>>>
>>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "If you're not annoying somebody, you're not really alive."
>>> -- Margaret Atwood
>>>
>>> On 9/28/16, 2:48 PM, "Sean Corfield"  wrote:
>>>
>>> And for comparison, here’s a threaded version that uses -> (with ->>
>>> embedded, and doto):
>>>
>>>   (-> (MidiSystem/getMidiDeviceInfo)
>>>   (->> (filter #(= (.getName ^MidiDevice$Info %) name))
>>>(map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
>>>(filter #(>= (.getMaxTransmitters ^MidiDevice %) 0)))
>>>   (first)
>>>   (or (throw (ex-info "No midi devices with recievers" {:name
>>> name})))
>>>   (doto (.open))
>>>   (.getReceiver))
>>>
>>> Note that I replaced the empty? check by just calling first followed
>>> by or/throw. Calling first on an empty sequence produces nil and (or x
>>> (throw …)) will yield x if it is not nil (else throw the exception).
>>>
>>> Also note that you lose the type hints here which may affect
>>> performance and/or method resolution (if the calls are ambiguous without
>>> the type hints).
>>>
>>> If the code isn’t performance critical and the calls are still
>>> resolvable without type hint, I’d probably omit them just to make the code
>>> cleaner. If the hints are needed, then I’d probably defn helpers for the
>>> interop calls (with type hinted arguments) to make the code cleaner:
>>>
>>>   (-> (MidiSystem/getMidiDeviceInfo)
>>>   (->> (filter #(= (get-device-name %) name))
>>>(map get-midi-device)
>>>(filter #(>= (get-max-transmitters %) 0)))
>>>   (first)
>>>   (or (throw (ex-info "No midi devices with recievers" {:name
>>> name})))
>>>   (doto (open-device))
>>>   (get-receiver))
>>>
>>> I’d probably make predicates for the two filter calls:
>>>
>>> (defn matches-device-name
>>>   [name]
>>>   (fn [^MidiDevice$Info info]
>>> (= name (.getName info
>>>
>>> (defn has-transmitters
>>>   [^MidiDevice$Info info]
>>>   (<= 0 (.getMaxTransmitters info)))
>>>
>>>   (-> (MidiSystem/getMidiDeviceInfo)
>>>   (->> (filter (matches-device-name name))
>>>(map get-midi-device)
>>>(filter has-transmitters))
>>>   (first)
>>>   (or (throw (ex-info "No midi devices with recievers" {:name
>>> name})))
>>>   (doto (open-device))
>>>   (get-receiver))
>>>
>>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "If you're not annoying somebody, you're not really alive."
>>> -- Margaret Atwood
>>>
>>> On 9/28/16, 2:12 PM, "clo...@googlegroups.com on behalf of
>>> pa...@pwjw.com" 
>>> wrote:
>>>
>>> This is a super interesting thread. Thank you all for your input
>>>
>>> I think you are right, @puzzler, that for my case a let may be
>>> better. The original code is above. Using as-> it looks like this (using
>>> 'it' as the name)
>>>

Re: Idiom question

[Stephen Spalding]

The semantic of the swiss-arrows  
-<> macro are nice. It's like as-> except that the operator is 
automatically specified as <>, and it has a default position.

Your original example would become:

(-<> blah
 (do-this)
 (do-that arg)
 (do-the-other a1 <> a2))

The combination of a pre-specified operator and a default position  makes 
it so handy that I often wish there were a built-in equivalent.

On Wednesday, September 28, 2016 at 6:10:05 PM UTC-4, pa...@pwjw.com wrote:
>
> All very interesting, and Sean that first/or threading pattern is very 
> helpful.
>
> @puzzler - totally get that the language is extensible yup and appreciate 
> the mainstream warning. When I read your cond-better version I got it; and 
> I also thought "a return statement like thing could be useful in a 
> construct something like this" and then remembered just how far the macro 
> system in lisps lets you go, which was really instructive.
>
> The patterns here are very useful. Thanks again to all of you who offered 
> up tips so far.
>
> On Wednesday, September 28, 2016 at 5:53:10 PM UTC-4, Sean Corfield wrote:
>>
>> Ooops, should be: 
>>
>> (defn has-transmitters 
>>   [^MidiDevice device] 
>>   (<= 0 (.getMaxTransmitters device))) 
>>
>> And if we made a helper for open-device, we could make it return the 
>> now-open device and then you wouldn’t need the doto – just call 
>> (open-device). 
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN 
>> An Architect's View -- http://corfield.org/ 
>>
>> "If you're not annoying somebody, you're not really alive." 
>> -- Margaret Atwood 
>>
>> On 9/28/16, 2:48 PM, "Sean Corfield"  wrote: 
>>
>> And for comparison, here’s a threaded version that uses -> (with ->> 
>> embedded, and doto): 
>> 
>>   (-> (MidiSystem/getMidiDeviceInfo) 
>>   (->> (filter #(= (.getName ^MidiDevice$Info %) name)) 
>>(map #(MidiSystem/getMidiDevice ^MidDevice$Info %)) 
>>(filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))) 
>>   (first) 
>>   (or (throw (ex-info "No midi devices with recievers" {:name 
>> name}))) 
>>   (doto (.open)) 
>>   (.getReceiver)) 
>> 
>> Note that I replaced the empty? check by just calling first followed 
>> by or/throw. Calling first on an empty sequence produces nil and (or x 
>> (throw …)) will yield x if it is not nil (else throw the exception). 
>> 
>> Also note that you lose the type hints here which may affect 
>> performance and/or method resolution (if the calls are ambiguous without 
>> the type hints). 
>> 
>> If the code isn’t performance critical and the calls are still 
>> resolvable without type hint, I’d probably omit them just to make the code 
>> cleaner. If the hints are needed, then I’d probably defn helpers for the 
>> interop calls (with type hinted arguments) to make the code cleaner: 
>> 
>>   (-> (MidiSystem/getMidiDeviceInfo) 
>>   (->> (filter #(= (get-device-name %) name)) 
>>(map get-midi-device) 
>>(filter #(>= (get-max-transmitters %) 0))) 
>>   (first) 
>>   (or (throw (ex-info "No midi devices with recievers" {:name 
>> name}))) 
>>   (doto (open-device)) 
>>   (get-receiver)) 
>> 
>> I’d probably make predicates for the two filter calls: 
>> 
>> (defn matches-device-name 
>>   [name] 
>>   (fn [^MidiDevice$Info info] 
>> (= name (.getName info 
>> 
>> (defn has-transmitters 
>>   [^MidiDevice$Info info] 
>>   (<= 0 (.getMaxTransmitters info))) 
>> 
>>   (-> (MidiSystem/getMidiDeviceInfo) 
>>   (->> (filter (matches-device-name name)) 
>>(map get-midi-device) 
>>(filter has-transmitters)) 
>>   (first) 
>>   (or (throw (ex-info "No midi devices with recievers" {:name 
>> name}))) 
>>   (doto (open-device)) 
>>   (get-receiver)) 
>> 
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN 
>> An Architect's View -- http://corfield.org/ 
>> 
>> "If you're not annoying somebody, you're not really alive." 
>> -- Margaret Atwood 
>> 
>> On 9/28/16, 2:12 PM, "clo...@googlegroups.com on behalf of 
>> pa...@pwjw.com"  
>> wrote: 
>> 
>> This is a super interesting thread. Thank you all for your input 
>> 
>> I think you are right, @puzzler, that for my case a let may be 
>> better. The original code is above. Using as-> it looks like this (using 
>> 'it' as the name) 
>> 
>>   (as-> (MidiSystem/getMidiDeviceInfo) it 
>>  (filter #(= (.getName ^MidiDevice$Info %) name) it) 
>>  (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it) 
>>  (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it) 
>>  (if (empty? it) (throw 

Re: Is Pallet abandoned? Alternatives?

[Sean Corfield]

I’ll second what Ray said: Pallet has some great concepts and it’s very 
powerful, but the model is a big shift from how most DevOps tools work and it 
can be very hard to develop your own crates etc. We tried to go down that path 
several years ago and even with assistance from the Pallet team we did not get 
very far.

 

I don’t think there are any actively maintained alternatives in Clojure so 
Ansible / Chef / Puppet is going to be your best bet I think.

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 9/30/16, 2:39 AM, "Ray Miller"  wrote:

 

I also got excited about pallet a year or so ago. There are some awesome ideas 
in there, but I found that in practice it was slow to develop with and much 
less flexible than it promised. In the end I switched to ansible and achieved 
more in 1 day than I had in a week's effort with pallet. I think the main 
problem is the small user base. The more mainstream solutions in this space 
have better documentation and are better tested in the wild. There's a much 
better chance you'll find someone else has already done the thing you're trying 
to do, so you will either find a module to do the work or an example to help 
you along.

 

Ray.

 

On 30 September 2016 at 03:38, Miroslav Kubíček  
wrote:

Hi there,
I just got super excited about Pallet only to find out that the last commit was 
3 years ago and that it is not being actively maintained (using now old version 
of jCoulds etc.).
Are there any alternatives that would work well with Clojure paradigm?

Or are my options only to either go with chef/puppet or to fork pallet? I am 
also interested to hear what works for people and what not so much.

Thanks!
Miro

 

 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec to match string

[Serzh Nechyporchuk]

Thanks for all. I will look at your suggestions.
> On Sep 29, 2016, at 20:59, lvh <_...@lvh.io> wrote:
> 
>> 
>> On Sep 29, 2016, at 11:42 AM, Sean Corfield > > wrote:
>> 
>> The test.chuck library from Gary Fredericks has a generator for regex 
>> strings that works pretty well.
> 
> Whenever I get some time (not soon, if my inbox is anything to go by), I’ll 
> add the equivalent part to schpec.
> 
> lvh
> 
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> 
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>> 
>> On 9/29/16, 7:20 AM, "Serzh Nechyporchuk" > behalf of nechyporc...@gmail.com> wrote:
>> 
>>   Thank you Alex. That’s true, I can use just predicate to validate string. 
>> But I want a little more from this.
>>   I really want to use generators and conforming. 
>>   I know that strings are seqable, s/cat works with seq. So my question is: 
>> Are there any way to combine this? 
>> 
>>> On Sep 29, 2016, at 15:39, Alex Miller  wrote:
>>> 
>>> You can make a predicate using re-matches - there is an email example in 
>>> http://clojure.org/guides/spec
>> 
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Interesting work by Mark Engleberg using regular expressions to solve (hard) programming riddles

[Yehonathan Sharvit]

http://blog.klipse.tech/clojure/2016/09/30/automata-segments-1.html

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is Pallet abandoned? Alternatives?

[Ray Miller]

I also got excited about pallet a year or so ago. There are some awesome
ideas in there, but I found that in practice it was slow to develop with
and much less flexible than it promised. In the end I switched to ansible
and achieved more in 1 day than I had in a week's effort with pallet. I
think the main problem is the small user base. The more mainstream
solutions in this space have better documentation and are better tested in
the wild. There's a much better chance you'll find someone else has already
done the thing you're trying to do, so you will either find a module to do
the work or an example to help you along.

Ray.

On 30 September 2016 at 03:38, Miroslav Kubíček 
wrote:

> Hi there,
> I just got super excited about Pallet only to find out that the last
> commit was 3 years ago and that it is not being actively maintained (using
> now old version of jCoulds etc.).
> Are there any alternatives that would work well with Clojure paradigm?
>
> Or are my options only to either go with chef/puppet or to fork pallet? I
> am also interested to hear what works for people and what not so much.
>
> Thanks!
> Miro
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CIDER: function definition is void: nrepl-current-connection-buffer

[Bozhidar Batsov]

Ah, noticed your problem - ac-nrepl is a legacy package that hasn't been
updated in ages. There's ac-cider now.

On 30 September 2016 at 09:37, Bozhidar Batsov  wrote:

> A long time ago this function was renamed to cider-current-connection.
>
> On 30 September 2016 at 00:56,  wrote:
>
>> How do I inspect and resolve the following? (Thanks in advance for any
>> help)
>>
>> I did M-x cider-jack-in-clojurescript with CIDER from MELPA stable as
>> well as MELPA and got the same result.
>>
>> I was thinking perhaps I have inconsistent versions of things, or perhaps
>> I have something that's out-dated. Here's some of the emacs packages I have
>> installed:
>>
>> egrep "cider|clojure|clj|repl" packages | grep installed
>>
>>   ac-nrepl   0.21
>>   cider  20160927.2135
>>   cider-eval-sexp-fu 1.1
>>   cljsbuild-mode 0.2.0
>>   clojure-cheatsheet 0.4.0
>>   clojure-mode   5.5.2
>>   clojure-mode-ex... 5.5.2
>>   clojurescript-mode 0.5
>>   flycheck-clojure   20160704.1221
>>   typed-clojure-mode 1.0.0
>>
>> M-x cider-jack-in-clojurescript
>>
>> Starting nREPL server via /home/user/bin/lein update-in :dependencies
>> conj \[org.clojure/tools.nrepl\ \"0.2.12\"\] -- update-in :plugins conj
>> \[cider/cider-nrepl\ \"0.13.0\"\] -- repl :headless...
>> nREPL server started on 37596
>> [nREPL] Establishing direct connection to localhost:37596 ...
>> [nREPL] Direct connection established
>> Connected.  nREPL server is up, CIDER REPL is online!
>> *error in process filter: ac-nrepl-refresh-class-cache: Symbol's function
>> definition is void: nrepl-current-connection-buffer*
>> *error in process filter: Symbol's function definition is void:
>> nrepl-current-connection-buffer*
>>
>> ;; Connected to nREPL server - nrepl://localhost:37596
>> ;; CIDER 0.14.0snapshot (package: 20160927.2135) (California), nREPL
>> 0.2.12
>> ;; Clojure 1.8.0, Java 1.8.0_45
>> user>
>>
>> *~/.lein/profiles.clj* says
>>
>> {:user {:plugins [[org.clojure/clojure "1.8.0"]]}}
>>
>> Here's my *project.clj*. I took out references to nrepl but that did not
>> resolve the issue.
>>
>> (defproject foo "0.1.0-SNAPSHOT"
>>   :description "FIXME: write this!"
>>   :url "http://example.com/FIXME;
>>   :license {:name "Eclipse Public License"
>> :url "http://www.eclipse.org/legal/epl-v10.html"}
>>
>>   :min-lein-version "2.6.1"
>>
>>   :dependencies [[org.clojure/clojure "1.8.0"]
>>  [org.clojure/clojurescript "1.9.229"]
>>  [org.clojure/core.async "0.2.385"
>>   :exclusions [org.clojure/tools.reader]]
>>  [prismatic/dommy "1.1.0"]]
>>
>>   :plugins [[lein-figwheel "0.5.8"]
>> [lein-cljsbuild "1.1.4" :exclusions [[org.clojure/clojure
>>
>>   :source-paths ["src"]
>>
>>   :clean-targets ^{:protect false} ["resources/public/js/compiled"
>> "target"]
>>
>>   :cljsbuild {:builds
>>   [{:id "test"
>> :source-paths ["src" "test"]
>> :compiler {:output-to  "resources/test/compiled.js"
>>:output-dir "resources/test/js/compiled/out"
>>:optimizations :whitespace
>>:pretty-print true}}
>>{:id "dev"
>> :source-paths ["src" "test" "cljs_src"]
>> :figwheel {:on-jsload "foo.test/run"
>>:open-urls ["http://localhost:3449/index.html
>> "]}
>>
>> :compiler {:main foo.core
>>:asset-path "js/compiled/out"
>>:output-to  "resources/public/js/compiled
>> /foo.js"
>>:output-dir "resources/public/js/compiled/out"
>>:source-map-timestamp true
>>:preloads [devtools.preload]}}
>>{:id "min"
>> :source-paths ["src"]
>> :compiler {:output-to "resources/public/js/compiled/
>> foo.js"
>>:main foo.core
>>:optimizations :advanced
>>:pretty-print false}}]
>>   :test-commands {"test" ["phantomjs"
>>   "resources/test/test.js"
>>   "resources/test/test.html"]}}
>>
>>   :figwheel {:css-dirs ["resources/public/css"]}
>>
>>   :profiles {:dev {:dependencies [[binaryage/devtools "0.7.2"]
>>   [figwheel-sidecar "0.5.7"]
>>   [com.cemerick/piggieback "0.2.1"]]
>>:source-paths ["src" "dev" "cljs_src"]
>>:repl-options {:init (set! *print-length* 50)
>>   :nrepl-middleware
>> [cemerick.piggieback/wrap-cljs-repl]}}})
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, 

Re: CIDER: function definition is void: nrepl-current-connection-buffer

[Bozhidar Batsov]

A long time ago this function was renamed to cider-current-connection.

On 30 September 2016 at 00:56,  wrote:

> How do I inspect and resolve the following? (Thanks in advance for any
> help)
>
> I did M-x cider-jack-in-clojurescript with CIDER from MELPA stable as
> well as MELPA and got the same result.
>
> I was thinking perhaps I have inconsistent versions of things, or perhaps
> I have something that's out-dated. Here's some of the emacs packages I have
> installed:
>
> egrep "cider|clojure|clj|repl" packages | grep installed
>
>   ac-nrepl   0.21
>   cider  20160927.2135
>   cider-eval-sexp-fu 1.1
>   cljsbuild-mode 0.2.0
>   clojure-cheatsheet 0.4.0
>   clojure-mode   5.5.2
>   clojure-mode-ex... 5.5.2
>   clojurescript-mode 0.5
>   flycheck-clojure   20160704.1221
>   typed-clojure-mode 1.0.0
>
> M-x cider-jack-in-clojurescript
>
> Starting nREPL server via /home/user/bin/lein update-in :dependencies conj
> \[org.clojure/tools.nrepl\ \"0.2.12\"\] -- update-in :plugins conj
> \[cider/cider-nrepl\ \"0.13.0\"\] -- repl :headless...
> nREPL server started on 37596
> [nREPL] Establishing direct connection to localhost:37596 ...
> [nREPL] Direct connection established
> Connected.  nREPL server is up, CIDER REPL is online!
> *error in process filter: ac-nrepl-refresh-class-cache: Symbol's function
> definition is void: nrepl-current-connection-buffer*
> *error in process filter: Symbol's function definition is void:
> nrepl-current-connection-buffer*
>
> ;; Connected to nREPL server - nrepl://localhost:37596
> ;; CIDER 0.14.0snapshot (package: 20160927.2135) (California), nREPL 0.2.12
> ;; Clojure 1.8.0, Java 1.8.0_45
> user>
>
> *~/.lein/profiles.clj* says
>
> {:user {:plugins [[org.clojure/clojure "1.8.0"]]}}
>
> Here's my *project.clj*. I took out references to nrepl but that did not
> resolve the issue.
>
> (defproject foo "0.1.0-SNAPSHOT"
>   :description "FIXME: write this!"
>   :url "http://example.com/FIXME;
>   :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
>
>   :min-lein-version "2.6.1"
>
>   :dependencies [[org.clojure/clojure "1.8.0"]
>  [org.clojure/clojurescript "1.9.229"]
>  [org.clojure/core.async "0.2.385"
>   :exclusions [org.clojure/tools.reader]]
>  [prismatic/dommy "1.1.0"]]
>
>   :plugins [[lein-figwheel "0.5.8"]
> [lein-cljsbuild "1.1.4" :exclusions [[org.clojure/clojure
>
>   :source-paths ["src"]
>
>   :clean-targets ^{:protect false} ["resources/public/js/compiled"
> "target"]
>
>   :cljsbuild {:builds
>   [{:id "test"
> :source-paths ["src" "test"]
> :compiler {:output-to  "resources/test/compiled.js"
>:output-dir "resources/test/js/compiled/out"
>:optimizations :whitespace
>:pretty-print true}}
>{:id "dev"
> :source-paths ["src" "test" "cljs_src"]
> :figwheel {:on-jsload "foo.test/run"
>:open-urls ["http://localhost:3449/index.html
> "]}
>
> :compiler {:main foo.core
>:asset-path "js/compiled/out"
>:output-to  "resources/public/js/
> compiled/foo.js"
>:output-dir "resources/public/js/compiled/out"
>:source-map-timestamp true
>:preloads [devtools.preload]}}
>{:id "min"
> :source-paths ["src"]
> :compiler {:output-to "resources/public/js/compiled/
> foo.js"
>:main foo.core
>:optimizations :advanced
>:pretty-print false}}]
>   :test-commands {"test" ["phantomjs"
>   "resources/test/test.js"
>   "resources/test/test.html"]}}
>
>   :figwheel {:css-dirs ["resources/public/css"]}
>
>   :profiles {:dev {:dependencies [[binaryage/devtools "0.7.2"]
>   [figwheel-sidecar "0.5.7"]
>   [com.cemerick/piggieback "0.2.1"]]
>:source-paths ["src" "dev" "cljs_src"]
>:repl-options {:init (set! *print-length* 50)
>   :nrepl-middleware
> [cemerick.piggieback/wrap-cljs-repl]}}})
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You