Re: clojure, not the go to for data science

[Sayth Renshaw]

Technically I see the JVM as an advantage. F# now as well as Julia are seen
as the data science languages contenders of the future.

Clojure has a lot going for it but never gets a mention,  just could not
understand why that is. Spark implements Scala and Python as languages to
use,  again you would wonder why not clojure here.

Is there a level of advocacy missing?

Sayth

On Tue, 31 Mar 2015 5:06 PM Mikera  wrote:

>
>
> On Tuesday, 31 March 2015 00:01:32 UTC+8, Phillip Lord wrote:
>
>>
>>
>>
>> Sayth Renshaw  writes:
>> > I last learned clojure in 1.2. Just curious why Clojure hasn't
>> > developed as a go to for data science?
>> >
>> > It never seems to get a mention R,Python and now Julia get the
>> > attention. By design it would appear that Clojure would be a good fit.
>> > Is it a lack of libraries, ease of install, no good default
>> > environment (R Rstudio, IPython ) where as you would need to use emacs
>> > with clojure, or is there just a better default use of Clojure?
>>
>>
>> I would say, lack of numpy or equivalent. And nice tools to link between
>> Clojure and the many C/Fortran numeric libraries. Python and R do this
>> natively.
>>
>
> core.matrix is effectively the equivalent of NumPy
>
> In some ways it is much more versatile, because it works with a general
> array abstraction rather than a specific concrete array format. There are
> core.matrix implementations (e.g. Clatrix) that link to native numerical
> libraries. There are also core.matrix implementations that run in pure,
> portable JVM code (e.g. vectorz-clj). You can also use plain old Clojure
> persistent vectors as a (slow but convenient) core.matrix implementation.
> Having all these options usable via the *same API* is a big win.
>
> core.matrix is certainly not yet as mature or fully featured as NumPy. But
> if it doesn't do what you need - please help improve it! PRs, bug reports
> and enhancement ideas all gratefully accepted.
>
> https://github.com/mikera/core.matrix
>
> There is also a Google Group here specifically dedicated to numerical
> topics in Clojure:
>
> https://groups.google.com/forum/#!forum/numerical-clojure
>
>
>>
>> Maybe if Clojure pulls itself away from the JVM this will change. One
>> big problem with both python and R for data science is that a lot of
>> interactive data visualisation happens on the web these days, and
>> neither python nor R support that so well. An ecosystem with a C hosted
>> clojure at the back end and Clojure script at the front end might work
>> well.
>>
>
> I agree Clojure is a great back-end for data-driven web applications.
>
> I would argue however that you don't need a "C-hosted" Clojure to get
> native back end performance since you can use tools like Clatrix to access
> BLAS etc. And aside from that, the JVM gives you a lot of big advantages on
> the server side (sophisticated memory management, excellent JIT
> compilation, concurrency, portability, library ecosystem etc.). I never
> quite understand the motivation of people who seem to want to reinvent all
> of this (probably badly) in native code. The JVM is an amazing piece of
> engineering, and I believe that a lot of the sucess of Clojure comes from
> taking advantage of this.
>
> I've personally had good experiences with Clojure on the back end and
> JavaScript/ClojureScript on the front end, and never once worried about
> performance.
>
>

-- 
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, not the go to for data science

[Mikera]

On Tuesday, 31 March 2015 00:01:32 UTC+8, Phillip Lord wrote:
>
>
>
>
> Sayth Renshaw > writes: 
> > I last learned clojure in 1.2. Just curious why Clojure hasn't 
> > developed as a go to for data science? 
> > 
> > It never seems to get a mention R,Python and now Julia get the 
> > attention. By design it would appear that Clojure would be a good fit. 
> > Is it a lack of libraries, ease of install, no good default 
> > environment (R Rstudio, IPython ) where as you would need to use emacs 
> > with clojure, or is there just a better default use of Clojure? 
>
>
> I would say, lack of numpy or equivalent. And nice tools to link between 
> Clojure and the many C/Fortran numeric libraries. Python and R do this 
> natively. 
>

core.matrix is effectively the equivalent of NumPy

In some ways it is much more versatile, because it works with a general 
array abstraction rather than a specific concrete array format. There are 
core.matrix implementations (e.g. Clatrix) that link to native numerical 
libraries. There are also core.matrix implementations that run in pure, 
portable JVM code (e.g. vectorz-clj). You can also use plain old Clojure 
persistent vectors as a (slow but convenient) core.matrix implementation. 
Having all these options usable via the *same API* is a big win.

core.matrix is certainly not yet as mature or fully featured as NumPy. But 
if it doesn't do what you need - please help improve it! PRs, bug reports 
and enhancement ideas all gratefully accepted. 

https://github.com/mikera/core.matrix

There is also a Google Group here specifically dedicated to numerical 
topics in Clojure:

https://groups.google.com/forum/#!forum/numerical-clojure
 

>
> Maybe if Clojure pulls itself away from the JVM this will change. One 
> big problem with both python and R for data science is that a lot of 
> interactive data visualisation happens on the web these days, and 
> neither python nor R support that so well. An ecosystem with a C hosted 
> clojure at the back end and Clojure script at the front end might work 
> well. 
>

I agree Clojure is a great back-end for data-driven web applications. 

I would argue however that you don't need a "C-hosted" Clojure to get 
native back end performance since you can use tools like Clatrix to access 
BLAS etc. And aside from that, the JVM gives you a lot of big advantages on 
the server side (sophisticated memory management, excellent JIT 
compilation, concurrency, portability, library ecosystem etc.). I never 
quite understand the motivation of people who seem to want to reinvent all 
of this (probably badly) in native code. The JVM is an amazing piece of 
engineering, and I believe that a lot of the sucess of Clojure comes from 
taking advantage of this.

I've personally had good experiences with Clojure on the back end and 
JavaScript/ClojureScript on the front end, and never once worried about 
performance.
 

-- 
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: square brackets

[Steven Deobald]

Hi Haris!

Weirdly, this became a source of amusement in our office and we couldn't
help but google the answer. Many of us are curious about the state of
ever-collapsing international user interfaces. It looks like the keystroke
you're looking for should be *[ALT] + F* or *[ALT] + G*. Give that a try?

>From wikipedia:

http://en.wikipedia.org/wiki/QWERTZ

It appears that this is the layout used in a Croatian keyboard:

http://en.wikipedia.org/wiki/QWERTZ#/media/File:KB_Slovene.svg

You can see a live version here:

http://gate2home.com/Croatian-Keyboard

We found this by googling "croatian keyboard layout windows". :)

Steven Deobald -- ⌀ -- nilenso.com

On Tue, Mar 31, 2015 at 1:57 AM,  wrote:

> Hi
>
> I cannot type square brackets. I tried left Alt key with key right to
> letter "p" and nothing appears.
> I have Croatian keyboard and use Windows 7.
> Please help.
>
> Thanks
>
> --
> 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: Clojure Jobs Available

[Michael Klishin]

On 31 March 2015 at 04:45:39, Jan Drake (jan.s.dr...@gmail.com) wrote:
> We have teams in Seattle, Sydney, and Costa Rica and are looking  
> to hire senior engineers with Clojure/Lisp experience.

Jan,

It would help if you clarify what locations/timezones you require candidates
to be in. Many talented engineers on this list are not in Seattle or  Sydney.

The line above suggests your team is distributed but what do I know,
maybe Costa Rica is a technology hub these days :)
--  
@michaelklishin, github.com/michaelklishin

-- 
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.

Clojure Jobs Available

[Jan Drake]

 

We're a stealth startup in the fintech space building consumer-scale, fully 
distributed systems in Clojure along with cutting edge data storage and 
transaction technologies.  We're Clojure all the way to the edge.


We have teams in Seattle, Sydney, and Costa Rica and are looking to hire 
senior engineers with Clojure/Lisp experience.  Many of our engineers come 
from a CL background and we also have senior engineers who have recently 
switched to functional programming and LISP.


If you're looking for an excellent team and awesome product to work on, 
then here at SecureOne™ is the best place to be.  


We care about solid engineering, reliable and resilient systems, low 
latency distributed processing, streaming analytics, high scalability, and 
extreme performance… and we're doing all of them.


If you're interested, please deliver a resume to jobs at SecureOne.com and 
Jan Drake (http://www.linkedin.com/in/janman) will get back to you.


We hope to hear from you.



Jan Drake

VP of Engineering & Operations

SecureOne Corporation

-- 
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.

square brackets

[haris . bogdanovic]

Hi

I cannot type square brackets. I tried left Alt key with key right to 
letter "p" and nothing appears.
I have Croatian keyboard and use Windows 7.
Please help.

Thanks

-- 
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: Debugging in CIDER

[Matt Mitchell]

Awesome.

+1 for a new release too, lots of other good stuff in there too.

- Matt

On Saturday, March 28, 2015 at 1:46:33 PM UTC-4, Bozhidar Batsov wrote:
>
> Hey everyone,
>
> Just wanted to let you know that the most requested feature for CIDER (a 
> debugger, in case you're wondering) has just landed in the master branch (
> https://github.com/clojure-emacs/cider/pull/1019#issuecomment-87240470).
>
> The new CIDER debugger is inspired by edebug (Emacs's own debugger) and 
> based on https://github.com/razum2um/clj-debugger
>
> It's not super fancy and there's clearly room for improvement in both 
> clj-debugger and CIDER itself, but it's a pretty good first step. Please, 
> take the new debugger out for a spin and let us know what do you think 
> about it. You might also report any problems you've encountered. :-)
>
> If all is well, CIDER 0.9 will probably be released in a week or so.
>
> P.S. Thanks, Artur (https://github.com/Malabarba), for all the hard work 
> on the debugger! You've once again showed the power of the OSS! There's 
> nothing we can't build together!
>

-- 
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: Deterministic macro expansion for Clojure?

[David James]

Thanks! A great suggestion. I'll try it.

On Friday, March 27, 2015 at 8:56:21 PM UTC-4, Ben wrote:
>
> One way you can get what you want is to give up on the auto-gensym feature 
> of the #-terminated identifiers, and call gensym directly, enabling it to 
> be mocked out with with-redefs. E.g. instead of:
>
> (defmacro m1
>   [x f]
>   `(let [x# ~x]
> (~f x#)))
>
> do
>
> (defmacro m1 [x f]
>(let [x-sym (gensym)]
>  `(let [~x-sym ~x] (~f ~x-sym
>
> You can then do something like
>
> (defn new-gensym []
>(let [counter (atom 0)]
>   (fn [& [extra]] (symbol (str (or extra "G_") (swap! counter inc))
>
> (with-redefs [gensym (new-gensym)] (macroexpand-1 '(m1 1 inc)))
>
> (not tested)
>
> On Fri, Mar 27, 2015 at 5:50 PM, David James  > wrote:
>
>> I agree with this motivation behind this request, which I explain in more 
>> detail here: 
>> http://stackoverflow.com/questions/16745135/how-to-test-a-clojure-macro-that-uses-gensyms
>>
>> We should be able to test the behavior *and* the macroexpansion. (Most 
>> things in life are not simple either/or decisions. Don't believe people 
>> that tell you otherwise.)
>>
>> On Monday, March 23, 2015 at 12:58:49 PM UTC-4, Chris Ford wrote:
>>>
>>> I think it's useful to think of macros as an odd form of I/O. Just as 
>>> you would separate out your templating from your domain functions, separate 
>>> out your defmacro from regular functions that just happen to manipulate 
>>> symbols. These functions will be easier to test.
>>>
>>> On 23 March 2015 at 16:23, Sean Corfield  wrote:
>>>
 On Mar 22, 2015, at 7:52 PM, myguidingstar  
 wrote:
 > I wonder if there is any way to make macro expansion in Clojure 
 deterministic. That would be useful in unit tests.

 I’d be very interested to understand your use case… Testing what the 
 macro expands to seems like it is test the macro system itself, not your 
 own code. Surely in a unit test you’d want to test the _behavior_ of the 
 code instead?

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

 "Perfection is the enemy of the good."
 -- Gustave Flaubert, French realist novelist (1821-1880)



 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@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+u...@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+u...@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 clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Ben Wolfson
> "Human kind has used its intelligence to vary the flavour of drinks, which 
> may be sweet, aromatic, fermented or spirit-based. ... Family and social 
> life also offer numerous other occasions to consume drinks for pleasure." 
> [Larousse, "Drink" entry]
>
> 

-- 
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, not the go to for data science

[danle...@gmail.com]

http://www.scribd.com/doc/30605092/Saturn-v-Flight-Manual

I have tracked down the flight manual of the Saturn-V rocket so we can 
objectively decide whether emacs is more, or less, difficult.

-- 
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 ecommerce

[Ben McFerren]

I also am interesting in finding a clojure ecommerce library

I'm posting here so that I can keep up on this topic and receive an email 
with any news




On Monday, January 5, 2015 at 9:03:52 AM UTC-8, g vim wrote:
>
> Are there currently any Clojure ecommerce packages or libraries, 
> preferably open source? Something like Shopify. Failing that, what are 
> Clojure developers using to build ecommerce sites? 
>
> gvim 
>
>

-- 
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: Update multiple values in vector at once

[Alexandr]

Thanks a lot!

On Monday, March 30, 2015 at 8:11:25 PM UTC+2, Michał Marczyk wrote:
>
> (defn upd-vec [input-vector ids new-values]
>   (reduce-kv #(assoc %1 %3 (new-values %2)) input-vector ids))
>
> (upd-vec [0 0 0 0 0] [1 3] [1.44 1.45])
> ;= [0 1.44 0 1.45 0]
>
>
> On 30 March 2015 at 20:05, Alexandr > 
> wrote:
>
>> Hello everybody,
>>
>> How can I update values in the vector given vector of id-s and new values?
>>
>> For example
>>
>> (defn upd-vec [input-vector ids new-values]
>> 
>> )
>>
>> (upd-vec [0 0 0 0 0] [1 3] [1.44 1.45]) 
>>
>> Output: [0 1.44 0 1.45 0]  (1st and 3rd elements are replaced)
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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: Update multiple values in vector at once

[Michał Marczyk]

(defn upd-vec [input-vector ids new-values]
  (reduce-kv #(assoc %1 %3 (new-values %2)) input-vector ids))

(upd-vec [0 0 0 0 0] [1 3] [1.44 1.45])
;= [0 1.44 0 1.45 0]


On 30 March 2015 at 20:05, Alexandr  wrote:

> Hello everybody,
>
> How can I update values in the vector given vector of id-s and new values?
>
> For example
>
> (defn upd-vec [input-vector ids new-values]
> 
> )
>
> (upd-vec [0 0 0 0 0] [1 3] [1.44 1.45])
>
> Output: [0 1.44 0 1.45 0]  (1st and 3rd elements are replaced)
>
> --
> 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.

Update multiple values in vector at once

[Alexandr]

Hello everybody,

How can I update values in the vector given vector of id-s and new values?

For example

(defn upd-vec [input-vector ids new-values]

)

(upd-vec [0 0 0 0 0] [1 3] [1.44 1.45]) 

Output: [0 1.44 0 1.45 0]  (1st and 3rd elements are replaced)

-- 
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, not the go to for data science

[Phillip Lord]

Sayth Renshaw  writes:
> I last learned clojure in 1.2. Just curious why Clojure hasn't
> developed as a go to for data science?
>
> It never seems to get a mention R,Python and now Julia get the
> attention. By design it would appear that Clojure would be a good fit.
> Is it a lack of libraries, ease of install, no good default
> environment (R Rstudio, IPython ) where as you would need to use emacs
> with clojure, or is there just a better default use of Clojure?


I would say, lack of numpy or equivalent. And nice tools to link between
Clojure and the many C/Fortran numeric libraries. Python and R do this
natively.

Maybe if Clojure pulls itself away from the JVM this will change. One
big problem with both python and R for data science is that a lot of
interactive data visualisation happens on the web these days, and
neither python nor R support that so well. An ecosystem with a C hosted
clojure at the back end and Clojure script at the front end might work
well.

Phil



-- 
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.

New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



UPDATED: Senior Software Engineer (Clojure, FP) at SecureOne

http://functionaljobs.com/jobs/8801-updated-senior-software-engineer-clojure-fp-at-secureone



Cheers,

Sean Murphy

FunctionalJobs.com


-- 
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: State of the Art in Clojure Debugging

[Paul deGrandis]

Because of the blocking nature of vim-fireplace (really of vim itself), 
you'll have to run most of the debuggers from a live, dedicated repl.

I've been slowly evolving my own debug-repl for a few years now.  It works 
in a `user.clj` setting or in a project related file.  At a quick glance, 
it supports the major features found in clj-debugger (file info exists, but 
no file pretty-print).  You can see a recent gist of it here: 
https://gist.github.com/ohpauleez/4ca0b646b89512f38ea2

Some people may want to rename `debug-repl` to `break`, and `quit-dr` to 
`continue`.

 * Locals are in a map, easy to print or consume
 * The debug repl captures the metadata about the call-site, so you can 
easily print the file contents based on that information
 * There's a shorthand to bounce the debugger into the namespace where the 
call happened, `in-debug-ns`
 * There's tooling/functions to make any uncaught exception trigger the 
debugger/repl
 * There's a `try-repl` (try an expression and launch the debugger/repl on 
an exception)
 * There's an `assert-repl` (like `try-repl` but with an assert - useful 
when testing function contracts/invariants)
 * One can make the debug repl return a new form into the call-site (at 
`quit`/`continue`) or establish a default one.
 * This debug repl nests correctly

In a more recent version (not in the gist), I've toyed with capturing 
stackframes as objects, allowing you to go up/down in the "stack" within a 
limited scope.  I don't think this is a particularly good idea, but in 
certain contexts, it works nicely.

While I've never used it, you may want to look at vim-redl - 
https://github.com/dgrnbrg/vim-redl.  You could also use emacs with evil, 
and then use ritz for a true JVM debugger - https://github.com/pallet/ritz

Cheers,
Paul

-- 
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: State of the Art in Clojure Debugging

[Lee Spector]

Thanks for this Bozhidar.

I just took a look at clj-debugger  
and am excited about several of its features, especially the ability to print 
locals.

Does anyone know if it supports (or could easily support -- I'd post an issue 
if it seems possible) a way to say something like (print-locals-on-exception 
(some-fn)) where nothing in some-fn actually calls break or anything else in 
clj-debugger, and where, if an exception is raised in the execution of some-fn, 
then the locals at the point of the exception get printed?

 -Lee


> On Mar 30, 2015, at 10:27 AM, Bozhidar Batsov  wrote:
> 
> This is a newish REPL debugger that's editor agnostic - 
> https://github.com/razum2um/clj-debugger 
>  (and accidentally it's powering 
> CIDER's own debugger).
> 
> I'm pretty sure Cursive has the most sophisticated debugger right now, so the 
> question is whether you dislike Intellij IDEA as much as Emacs. :-)
> 

-- 
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, not the go to for data science

[Tassilo Horn]

Fluid Dynamics  writes:

> You can have as many of them open as you like, say, one for 
> "task X", and one for "switching focus between windows".
>
> And then have what, two 27x24 and a 26x24 keyhole to squint through at
> everything? :) Less a couple of lines at the bottom for status
> notifications and the little command input area, of course.

You can have as many windows as you want, and you can have as many
buffers as you want.  Windows display buffers.  You can have 2 windows
on the same buffer, or you can have one window and a gazillion buffers
in which case only one of them is displayed currently, but you can
switch from one buffer to another buffer in the current window with `C-x
b '.  It's not uncommon that I have 50 or more buffers at a
time, and it's still very manageable.

And of course, you don't need to run emacs on the linux console.  I run
it maximized in X with its graphical UI, and then I can easily have 3
windows side-by-side which are still wider than 80 columns.

Anyway, there's no point in discussing with you as it seems you know
better anyhow.  So the discussion is finished for me.

Bye,
Tassilo

-- 
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: State of the Art in Clojure Debugging

[Vijay Kiran]

I've been using Spacemacs with great 
success https://github.com/syl20bnr/spacemacs and I heard some rave things 
from Vim aficionados. So you can get all the good stuff from bbastov's 
hardwork and still use Vim like environment :)

./Vijay


On Monday, March 30, 2015 at 4:27:32 PM UTC+2, Bozhidar Batsov wrote:
>
> This is a newish REPL debugger that's editor agnostic - 
> https://github.com/razum2um/clj-debugger (and accidentally it's powering 
> CIDER's own debugger).
>
> I'm pretty sure Cursive has the most sophisticated debugger right now, so 
> the question is whether you dislike Intellij IDEA as much as Emacs. :-)
>
>
>
> On 30 March 2015 at 15:20, Matthew West  > wrote:
>
>> What is the current preferred strategy for debugging Clojure code? I'd 
>> prefer a solution that doesn't involve Emacs, as I already know vim pretty 
>> well and don't really want to switch. What are my options that are still 
>> actively maintained?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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: [ANN][book] Clojure Reactive Programming

[danle...@gmail.com]

I am now a proud owner of your e-book!  Congratulations, I am looking forward 
to reading this latest addition to my Clojure library.

-- 
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: State of the Art in Clojure Debugging

[Bozhidar Batsov]

This is a newish REPL debugger that's editor agnostic -
https://github.com/razum2um/clj-debugger (and accidentally it's powering
CIDER's own debugger).

I'm pretty sure Cursive has the most sophisticated debugger right now, so
the question is whether you dislike Intellij IDEA as much as Emacs. :-)



On 30 March 2015 at 15:20, Matthew West  wrote:

> What is the current preferred strategy for debugging Clojure code? I'd
> prefer a solution that doesn't involve Emacs, as I already know vim pretty
> well and don't really want to switch. What are my options that are still
> actively maintained?
>
> --
> 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.

Easy-install/GUI emacs for Clojure (was: Re: clojure, not the go to for data science)

[Lee Spector]

[Forked the thread as per suggestion by Timothy Baldridge.]

On Mar 30, 2015, at 9:29 AM, Christian Weilbach  
wrote:
> 
> I have failed to setup Emacs for development and used Vim or Eclipse
> primarily before entering Clojure-land. emacs-live allowed me to just
> execute a shell script and get a decent Clojure environment which I
> have used for 2 years until I have reconfigured my emacs having a
> better understanding. Its emphasis on live-coding inspired by
> composing music is a very compelling. The only thing I had to add to
> emacs live was evil-mode, which wasn't too hard.

I agree that emacs-live is a great step forward! I explored it for a while and 
considered adopting it for my teaching and research work. (I'm not a software 
developer, I'm a computer science professor/researcher.) I didn't think it got 
quite far enough towards meeting my needs for me to make the leap, but it came 
the closest so far. Perhaps it'd be a good starting point for someone to take 
the next step.

FWIW I try to survey all of the options every year or so, and I currently teach 
with and mostly use Counterclockwise, although I sometimes recommend Nightcode 
for newbies. Both of these are great, and I'm immensely grateful to their 
developers. But if an emacs-based environment came along with the right 
usability features (see bullet points below) then I'd almost certainly switch 
to that.

 -Lee


> On 30.03.2015 15:12, Lee Spector wrote:
>>> On Mar 30, 2015, at 7:35 AM, Jony Hudson 
>>> wrote:
>>> 
>>> I propose, instead of this discussion, everyone channels their
>>> energy into writing an open-source data-science library, or blog
>>> post/article promoting Clojure for data science. In their
>>> favourite editor, of course!
>>> 
>>> 
>>> Jony
>> 
>> 
>> 
>> That's a good idea, but I'd also like to say a bit more about the
>> pro/con-emacs discussion, which I hope to be constructive.
>> 
>> I think I actually agree with most of the comments both by the
>> emacs critics and the emacs proponents in this thread. Even the
>> most intense ones, on both sides. But rather than worrying about
>> who is more correct I want to point out that it's entirely
>> possible, and would be gloriously beautiful, for an emacs-based
>> Clojure environment to be produced that:
>> 
>> - Can be downloaded in a single click and run with one more click
>> to do basic Clojure development with no further configuration, on
>> Mac/Windows/Linux.
>> 
>> - Provides reasonably standard GUI elements (familiar to any
>> computer user without reading a manual) for triggering core
>> functionality and for discovering additional features.
>> 
>> As some have mentioned in this thread, a lot of work has been done
>> on easing configuration (by people on this list among others) and
>> there are some GUI-based packages out there, but as far as I know
>> there's nothing that comes close to meeting both of the bullet
>> points above. I think that most emacs-based folks either don't
>> think this is possible or don't see it as a priority, but something
>> like this must be possible (and there have been things close to
>> this for other Lisps in the past), and  if it became a reality that
>> I would switch to it for all of my coding and teaching and I'd
>> evangelize it from the rooftops.
>> 
>> I'm not in a position to do development work on this myself, but I
>> believe quite fervently that this would be a fabulous thing for the
>> Clojure community.
>> 
>> I'd be happy to discuss this further off-list and/or beta-test
>> projects aimed at these goals.

-- 
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, not the go to for data science

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.03.2015 13:35, Jony Hudson wrote:
> I propose, instead of this discussion, everyone channels their
> energy into writing an open-source data-science library, or blog
> post/article promoting Clojure for data science. In their favourite
> editor, of course!

I have started working on R integration with the help of rinancanter
(1) and it was nice to have dedicated R code cells with at least
syntax highlighting that I can mix with Clojure code in the same JVM
environment.
http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=rincanter.clj
I am not sure whether this fits the design atm. though. I also had a
look at renjin, but I think the native plugins mandate an RVM
integration atm.

Sadly JyNI has made little progress towards Numpy support, (2)
otherwise Clojure could integrate more mature data science platforms
like R and Python more easily and leverage its integrative JVM
advantage more. The fragmentation on runtime level is really stupid imo.

It can be difficult to address some data science techniques in
Clojure, because you have to reimplement them from R, Python or
something else compared to Clojure being able to use Java libraries
directly and "sitting on top of the hill" by default for "business"
problems. Java is just not a good data science language and hated by
many people in my environment. But gorilla is really nice in
combination with ggplot already, so I think if one could at least
integrate R there, the disadvantages would shrink significantly.

I also have taken a paper I liked and implemented a quick version of
SNE, which was fairly nice to do in Gorilla REPL:
http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
A problem seems to be unicode support, I tried to use some math
symbols from the notation in the paper directly, but the viewer seems
to have a problem with it.

Christian

(1) https://github.com/jolby/rincanter
(2) https://github.com/Stewori/JyNI/issues/2#
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVGVPFAAoJEKel+aujRZMkLBYIAKp+kzS7l0iiKdKVhRl1e0wP
utRHY+KFwmIRpc0vBf1Y5I5Lo2jFlemslDlWmQb5iPcYfALpLrzhHVP4CL4nRy+c
SMfnHPOS4nD6usAbTjyi3ZP8/wTbL3Du6oGQmwQMcMpklTgh+qgBsLmLdYabwXcm
YMifMYZVjSEtFcAz/FLxukLGGOSa86Nld79Wgj9hu2kTpS3ZFIx2gSpNzeeyiZBU
O+QtKTVAM603vBDQF0dgYu5u45pfsW/SZ0dThOvKN9632MX8Xb+SzzS34pxtxGWr
/JMpffYOIZ7kw0qto1zKKwewoO0zmhCjmOXDS063wYfHWvEqhcia9ChdT/4rxvY=
=0XIe
-END PGP SIGNATURE-

-- 
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, not the go to for data science

[Fluid Dynamics]

On Monday, March 30, 2015 at 7:29:36 AM UTC-4, Alexis wrote:
>
>
> Fluid Dynamics > writes: 
>   
> >> * i don't have to learn and use a distinct, possibly   
> >>   resource-hungry,  IDE[2] for every new programming language 
> >>   or environment i  need/want to work in. (When the Swift 
> >>   language was released, for  example, basic Swift support in 
> >>   the form of `swift-mode` became  available within less than a 
> >>   week.)   
> > 
> > Eclipse has plugins for a wide variety of languages.   
>
> True, but i don't think i've ever heard that one of Eclipse's main 
> selling points is that it's light on resource usage. 
>

Its resource usage as a percentage of what's available with a typical 
developer's hardware now is probably comparable to emacs's as a percentage 
of what was available with a typical developer's hardware circa 1985. Of 
course, on modern hardware that percentage can do a whole heck of a lot 
more, such as presenting an actual user interface. :)

>> * Further to the resource-usage issue, i can more easily use 
> >> Emacs   
> >>   remotely over low-bandwidth links than i could use an IDE.   
> > 
> > Typical home and mobile connection speeds are multiple MBPS 
> > these days. 
>
> You respond to me saying that /i/ like Emacs for its ease-of-use 
> across low-bandwidth links (which i regularly have to deal with) 
> by  what, implying that i should be a so-called 'typical' 
> home/mobile connection user instead? 
>

Forgive me for assuming that you meant to suggest that as a general selling 
point, rather than a personal idiosyncracy or something. :)
 

> Anyway, 'typical' varies from geographic location to geographic 
> location. My home connection is ADSL2+, but my mobile provides 4G 
> speeds only within a limited geographic area - and when i visited 
> the city of Newcastle, New South Wales, recently, with it's 
> population of ~300,000, my mobile data connection was 
> intermittent, let alone of a decent speed. In such a situation, 
> i've found being able to use a text-based UI, rather than being 
> forced to use a graphical UI (even using something like NoMachine) 
> quite a boon. 
>

In such a situation, I'd find using infrequent and discrete network 
accesses, such as checkins and checkouts from a remote repository, and 
working with local copies of checked-out files with a local editor on my 
own device, to be quite a boon. And who wants their UI to have noticeable 
latency anyways? If you're trying to arrow to a position (or worse, 
backspace or delete to one), it's like skating on ice: you're prone to 
overshoot and spend ages playing golf with the damn cursor. If you have a 
local laggy UI, such as due to something else abruptly hogging the CPU 
unexpectedly (svchost.exe being the standard culprit on Windows), at least 
you can resort to the mouse to click the cursor into position in one move, 
but with a remote terminal emulation you won't even have that option.

Further, even ADSL2+ bandwidth can be heavily saturated when other 
> people on the connection are e.g. streaming HD movies at the same 
> time as one is trying to work on a remote system  
>

Isn't that cable you're thinking of? Which is why sane people use DSL/4G 
for most needs, unless they download a shitton of giant .mkvs themselves.

>> * IDEs typically don't allow one to change their basic 
> >> behaviours   
> >>   whilst  they're running. Related: if there's a bug fix or 
> >>   feature i want  applied, i can apply it myself, rather than 
> >>   having to hope that  the maintainers will (a) accept that 
> >>   it's something that  /should/ be applied, and (b) actually 
> >>   apply it.   
> > 
> > The second, at least, applies to every open source IDE, 
> > including a certain EPL-licensed one. 
>
> Not quite, at least not insofar as i understand what you're 
> saying. i'm talking about not having to patch the source tree and 
> recompile, even across new versions. In my Emacs config, i've 
> redefined a few different Emacs functions to behave the way i 
> want, such that, even when i install a new version of Emacs, i 
> don't need to make any changes to the source itself to get the 
> desired behaviour.
>

That sounds unbelievably fragile. Like monkey-patching clojure.core or a 
major Ruby class, and then updating Clojure/Ruby.   

> Unfortunately, one MUST do all of that and CANNOT use it as a 
> > black box, because it is the software analogue of a computer 
> > with no keyboard or monitor or anything else resembling a user 
> > interface, so one must toggle everything in and know the 
> > hardware internals backwards and forwards to get anything 
> > done. :) 
>
> A strong claim, considerably stronger than the weaker claim that 
> Emacs needs tweaking to get to one's 'ideal' workflow, or even 
> that Emacs needs more tweaking than other software to get to that 
> workflow.


To get to something that so much as vaguely resembles your normal workflow 
appears to take an astonishing amoun

Re: clojure, not the go to for data science

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.03.2015 15:12, Lee Spector wrote:
>> On Mar 30, 2015, at 7:35 AM, Jony Hudson 
>> wrote:
>> 
>> I propose, instead of this discussion, everyone channels their
>> energy into writing an open-source data-science library, or blog
>> post/article promoting Clojure for data science. In their
>> favourite editor, of course!
>> 
>> 
>> Jony
> 
> 
> 
> That's a good idea, but I'd also like to say a bit more about the
> pro/con-emacs discussion, which I hope to be constructive.
> 
> I think I actually agree with most of the comments both by the
> emacs critics and the emacs proponents in this thread. Even the
> most intense ones, on both sides. But rather than worrying about
> who is more correct I want to point out that it's entirely
> possible, and would be gloriously beautiful, for an emacs-based
> Clojure environment to be produced that:
> 
> - Can be downloaded in a single click and run with one more click
> to do basic Clojure development with no further configuration, on
> Mac/Windows/Linux.
> 
> - Provides reasonably standard GUI elements (familiar to any
> computer user without reading a manual) for triggering core
> functionality and for discovering additional features.
> 
> As some have mentioned in this thread, a lot of work has been done
> on easing configuration (by people on this list among others) and
> there are some GUI-based packages out there, but as far as I know
> there's nothing that comes close to meeting both of the bullet
> points above. I think that most emacs-based folks either don't
> think this is possible or don't see it as a priority, but something
> like this must be possible (and there have been things close to
> this for other Lisps in the past), and  if it became a reality that
> I would switch to it for all of my coding and teaching and I'd
> evangelize it from the rooftops.
> 
> I'm not in a position to do development work on this myself, but I
> believe quite fervently that this would be a fabulous thing for the
> Clojure community.
> 
> I'd be happy to discuss this further off-list and/or beta-test
> projects aimed at these goals.

I have failed to setup Emacs for development and used Vim or Eclipse
primarily before entering Clojure-land. emacs-live allowed me to just
execute a shell script and get a decent Clojure environment which I
have used for 2 years until I have reconfigured my emacs having a
better understanding. Its emphasis on live-coding inspired by
composing music is a very compelling. The only thing I had to add to
emacs live was evil-mode, which wasn't too hard.

Also installing packages in emacs 24 is a breeze, no match to Eclipse
plugin repository mess and screw-ups and I don't want to use a closed
source IDE. No matter how many resources you have, being able to run
emacs in a shared tmux session is a big plus. I even have aliased
emacs-client as vim, so I don't have to rethink starting vim for quick
edits and still do it in a common emacs environment. I also find it
interesting that Rich still uses inferior-lisp mode and I think people
get too obsessed with tooling. I usually wait until it really hurts
and then I try to adjust my tooling.

It is really important that the nrepl middleware is shared between
IDEs and I had the impression recently that Cursive and others started
to integrate features directly into the IDE, which I don't think is a
good strategy.

A thankful shoutout again to the emacs-live maintainers!
https://github.com/overtone/emacs-live

Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVGU+dAAoJEKel+aujRZMkMRIH+gJJ1rLqB4NZNDZHmZSz6E2W
7OwsDXcn7bqZeaGv/s/VRjZ9Hk6saxS2hJP+PEzWSnXU48fBvYSAU8tu657U85tk
wFuWqm2A5kl/RyKwukYY1o05GYmVQvkGA2cKM63rTItXL/4pkhMpMQhwkOZHe1Zt
ZesL4A8B1A5jiZqp3bwhHIt/c1Awi33XG2BrFmMqdlSINJ3t0ADDNZra5328G1yZ
eZDIO+ljRISkfxAOz/u45yi/KT9mDWe7AXqhavKwDFXbFZxmofrPNAHYRkB/+WuY
vZAuw+zyVvY8NyBmBNKW1b5oqljQtUBQxSbNdC1sdE9Z1pe2yYsyOD0Jp3EZjR0=
=jt1D
-END PGP SIGNATURE-

-- 
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, not the go to for data science

[Timothy Baldridge]

>> That's a good idea, but I'd also like to say a bit more about the
pro/con-emacs discussion, which I hope to be constructive.

Discussion is often a good idea, but in a dedicated thread. Perhaps it's
time to fork the original topic so that this discussion about editors can
continue without derailing this thread even further.

Timothy

On Mon, Mar 30, 2015 at 7:12 AM, Lee Spector  wrote:

> > On Mar 30, 2015, at 7:35 AM, Jony Hudson  wrote:
> >
> > I propose, instead of this discussion, everyone channels their energy
> into writing an open-source data-science library, or blog post/article
> promoting Clojure for data science. In their favourite editor, of course!
> >
> >
> > Jony
>
>
>
> That's a good idea, but I'd also like to say a bit more about the
> pro/con-emacs discussion, which I hope to be constructive.
>
> I think I actually agree with most of the comments both by the emacs
> critics and the emacs proponents in this thread. Even the most intense
> ones, on both sides. But rather than worrying about who is more correct I
> want to point out that it's entirely possible, and would be gloriously
> beautiful, for an emacs-based Clojure environment to be produced that:
>
> - Can be downloaded in a single click and run with one more click to do
> basic Clojure development with no further configuration, on
> Mac/Windows/Linux.
>
> - Provides reasonably standard GUI elements (familiar to any computer user
> without reading a manual) for triggering core functionality and for
> discovering additional features.
>
> As some have mentioned in this thread, a lot of work has been done on
> easing configuration (by people on this list among others) and there are
> some GUI-based packages out there, but as far as I know there's nothing
> that comes close to meeting both of the bullet points above. I think that
> most emacs-based folks either don't think this is possible or don't see it
> as a priority, but something like this must be possible (and there have
> been things close to this for other Lisps in the past), and  if it became a
> reality that I would switch to it for all of my coding and teaching and I'd
> evangelize it from the rooftops.
>
> I'm not in a position to do development work on this myself, but I believe
> quite fervently that this would be a fabulous thing for the Clojure
> community.
>
> I'd be happy to discuss this further off-list and/or beta-test projects
> aimed at these goals.
>
>  -Lee
>
>
>
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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, not the go to for data science

[Lee Spector]

> On Mar 30, 2015, at 7:35 AM, Jony Hudson  wrote:
> 
> I propose, instead of this discussion, everyone channels their energy into 
> writing an open-source data-science library, or blog post/article promoting 
> Clojure for data science. In their favourite editor, of course!
> 
> 
> Jony



That's a good idea, but I'd also like to say a bit more about the pro/con-emacs 
discussion, which I hope to be constructive.

I think I actually agree with most of the comments both by the emacs critics 
and the emacs proponents in this thread. Even the most intense ones, on both 
sides. But rather than worrying about who is more correct I want to point out 
that it's entirely possible, and would be gloriously beautiful, for an 
emacs-based Clojure environment to be produced that:

- Can be downloaded in a single click and run with one more click to do basic 
Clojure development with no further configuration, on Mac/Windows/Linux.

- Provides reasonably standard GUI elements (familiar to any computer user 
without reading a manual) for triggering core functionality and for discovering 
additional features.

As some have mentioned in this thread, a lot of work has been done on easing 
configuration (by people on this list among others) and there are some 
GUI-based packages out there, but as far as I know there's nothing that comes 
close to meeting both of the bullet points above. I think that most emacs-based 
folks either don't think this is possible or don't see it as a priority, but 
something like this must be possible (and there have been things close to this 
for other Lisps in the past), and  if it became a reality that I would switch 
to it for all of my coding and teaching and I'd evangelize it from the rooftops.

I'm not in a position to do development work on this myself, but I believe 
quite fervently that this would be a fabulous thing for the Clojure community.

I'd be happy to discuss this further off-list and/or beta-test projects aimed 
at these goals.

 -Lee




-- 
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, not the go to for data science

[Colin Fleming]

Without wanting to get involved in this discussion, I'd just like to point
out that there's plenty of anti-IntelliJ trolling goes on in the Clojure
community as well. The trick is just to ignore it, something that I mostly
manage to do.

I'd also like to second Jony's suggestion that we also talk a bit about
data science, which was the original question.

On 31 March 2015 at 01:53, Fluid Dynamics  wrote:

> On Monday, March 30, 2015 at 7:23:00 AM UTC-4, Tassilo Horn wrote:
>>
>> Fluid Dynamics  writes:
>>
>> > * Further to the resource-usage issue, i can more easily use Emacs
>> > remotely over low-bandwidth links than i could use an IDE.
>> >
>> > Typical home and mobile connection speeds are multiple MBPS these days.
>>
>> Still, running Eclipse or some other IDE via X forwarding isn't too much
>> fun even with X2Go.
>>
>
> Most people these days also have all their devices, even the handheld
> ones, powerful enough to run a decent IDE locally, which can work with
> local files or connect to a remote git repository. This obviates the need
> to SSH or telnet into a remote host and run both the editor AND the
> repository there, or to use X forwarding.
>
> > Unfortunately, one MUST do all of that and CANNOT use it as a black
>> > box, because it is the software analogue of a computer with no
>> > keyboard or monitor or anything else resembling a user interface, so
>> > one must toggle everything in and know the hardware internals
>> > backwards and forwards to get anything done. :)
>>
>> That's nonsense.  As soon as you have made yourself acquainted with the
>> basic Emacs terminology and concepts, getting started with Clojure
>> development is a piece of cake.  Of course,
>
>
> the devil is in the details. Including the implementation details that
> leak out all over the place, starting with the ubiquitous use of the term
> "buffer" in user-facing documentation.
>
>
>> Emacs follows the unicode standard and represents characters as
>> UTF8-encoded codepoints.
>>
>
> All very useful, right up until the time comes to display such strings to
> ttya0 :)
>
> > Rather, the last time I tried using emacs, I seem to recall always
>> > ending up with this sequence of events:
>> >
>> > a) I am trying to do some task X, for which the obvious key combination
>> bleeps
>> > or does something weird but definitely doesn't do X for some reason.
>> > b) Soon, I have a split pane with my document on the left and the help
>> files on
>> > the right, with the latter open to a page on task X and the input focus
>> in it.
>> > c) A little bit later, I have a split pane with my document on the
>> left, the
>> > input focus in my document, and the help pane on the right open to a
>> page on
>> > how to switch focus between panes, and I don't remember the long and
>> > complicated sequence of keystrokes needed to perform task X any more
>> because it
>> > was deleted from my brain's short term memory to remember the long and
>> > complicated sequence of keystrokes that is how one says "alt+tab" in
>> the
>> > obscure and archaic dialect known as emacsese.
>> > d) Repeat b) and c) a few times, while experiencing an acute event of
>> abnormal
>> > pre-menopausal hair loss.
>> > e) Give up and fire up Notepad, Eclipse, or whatever seems best suited
>> to
>> > current task. ;)
>>
>> I think with "help pane" you mean a window showing the Emacs info
>> manual.
>
>
> Oh, if only. If it had been an actual window, I'd have been able to use
> OS-native window switching to switch between it and the document I was
> working on, and leave the help window open to something other than the how
> to switch panes topic! :)
>
>  You can have as many of them open as you like, say, one for
>> "task X", and one for "switching focus between windows".
>>
>
> And then have what, two 27x24 and a 26x24 keyhole to squint through at
> everything? :) Less a couple of lines at the bottom for status
> notifications and the little command input area, of course.
>
> > * The Emacs ecosystem is growing rapidly; http://melpa.org/
>> > currently lists ~2400 packages ("extensions" or "addons")
>> > available for easy installation via Emacs' package.el UI.
>> >
>> >
>> > I wonder how anyone can find anything in that mess.
>>
>> Searching might be a start.
>>
>
> If searching in emacs was as intuitive as control-F and type in a
> substring to look for, it likely would be. :)
>
> > The Java and Clojure IDEs are probably each sandwiched amongst
>> > hundreds of consecutive entries
>>
>> Yes, of course.  Hey, how to people use apt-get/packman/yum/whatever?
>> The packages needed for "task X" are sandwiched between tens of
>> thousands of unrelated packages.
>>
>
> For something like Ubuntu, there's probably a nicely designed searchable
> website not entirely unlike the Firefox addons site Moz runs. Given the
> vintage of the emacs "user experience" (I use this term loosely), its
> version probably is a textual alphabetical list with a blinking prompt at

Re: clojure, not the go to for data science

[Fluid Dynamics]

On Monday, March 30, 2015 at 7:23:00 AM UTC-4, Tassilo Horn wrote:
>
> Fluid Dynamics > writes: 
>
> > * Further to the resource-usage issue, i can more easily use Emacs 
> > remotely over low-bandwidth links than i could use an IDE. 
> > 
> > Typical home and mobile connection speeds are multiple MBPS these days. 
>
> Still, running Eclipse or some other IDE via X forwarding isn't too much 
> fun even with X2Go. 
>

Most people these days also have all their devices, even the handheld ones, 
powerful enough to run a decent IDE locally, which can work with local 
files or connect to a remote git repository. This obviates the need to SSH 
or telnet into a remote host and run both the editor AND the repository 
there, or to use X forwarding.

> Unfortunately, one MUST do all of that and CANNOT use it as a black 
> > box, because it is the software analogue of a computer with no 
> > keyboard or monitor or anything else resembling a user interface, so 
> > one must toggle everything in and know the hardware internals 
> > backwards and forwards to get anything done. :) 
>
> That's nonsense.  As soon as you have made yourself acquainted with the 
> basic Emacs terminology and concepts, getting started with Clojure 
> development is a piece of cake.  Of course,


the devil is in the details. Including the implementation details that leak 
out all over the place, starting with the ubiquitous use of the term 
"buffer" in user-facing documentation.
 

> Emacs follows the unicode standard and represents characters as 
> UTF8-encoded codepoints.
>

All very useful, right up until the time comes to display such strings to 
ttya0 :)

> Rather, the last time I tried using emacs, I seem to recall always 
> > ending up with this sequence of events: 
> > 
> > a) I am trying to do some task X, for which the obvious key combination 
> bleeps 
> > or does something weird but definitely doesn't do X for some reason. 
> > b) Soon, I have a split pane with my document on the left and the help 
> files on 
> > the right, with the latter open to a page on task X and the input focus 
> in it. 
> > c) A little bit later, I have a split pane with my document on the left, 
> the 
> > input focus in my document, and the help pane on the right open to a 
> page on 
> > how to switch focus between panes, and I don't remember the long and 
> > complicated sequence of keystrokes needed to perform task X any more 
> because it 
> > was deleted from my brain's short term memory to remember the long and 
> > complicated sequence of keystrokes that is how one says "alt+tab" in the 
> > obscure and archaic dialect known as emacsese. 
> > d) Repeat b) and c) a few times, while experiencing an acute event of 
> abnormal 
> > pre-menopausal hair loss. 
> > e) Give up and fire up Notepad, Eclipse, or whatever seems best suited 
> to 
> > current task. ;) 
>
> I think with "help pane" you mean a window showing the Emacs info 
> manual.


Oh, if only. If it had been an actual window, I'd have been able to use 
OS-native window switching to switch between it and the document I was 
working on, and leave the help window open to something other than the how 
to switch panes topic! :)

 You can have as many of them open as you like, say, one for 
> "task X", and one for "switching focus between windows".
>

And then have what, two 27x24 and a 26x24 keyhole to squint through at 
everything? :) Less a couple of lines at the bottom for status 
notifications and the little command input area, of course.

> * The Emacs ecosystem is growing rapidly; http://melpa.org/ 
> > currently lists ~2400 packages ("extensions" or "addons") 
> > available for easy installation via Emacs' package.el UI. 
> > 
> > 
> > I wonder how anyone can find anything in that mess. 
>
> Searching might be a start.
>

If searching in emacs was as intuitive as control-F and type in a substring 
to look for, it likely would be. :) 

> The Java and Clojure IDEs are probably each sandwiched amongst 
> > hundreds of consecutive entries 
>
> Yes, of course.  Hey, how to people use apt-get/packman/yum/whatever? 
> The packages needed for "task X" are sandwiched between tens of 
> thousands of unrelated packages.
>

For something like Ubuntu, there's probably a nicely designed searchable 
website not entirely unlike the Firefox addons site Moz runs. Given the 
vintage of the emacs "user experience" (I use this term loosely), its 
version probably is a textual alphabetical list with a blinking prompt at 
the bottom, with no perceived affordances of any way to search or jump 
nonlinearly within the list, and unless you're lucky perhaps not even an 
obvious way to page down and page up. (The keys on every keyboard bearing 
those precise labels, no doubt, beep and do nothing else, or else do things 
entirely unrelated to paging down and up, this being emacs we're discussing 
after all.)

> all the rest of which are for languages nobody has ever heard of 
> > outside of one obsc

State of the Art in Clojure Debugging

[Matthew West]

What is the current preferred strategy for debugging Clojure code? I'd 
prefer a solution that doesn't involve Emacs, as I already know vim pretty 
well and don't really want to switch. What are my options that are still 
actively maintained?

-- 
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, not the go to for data science

[Jony Hudson]

I propose, instead of this discussion, everyone channels their energy into 
writing an open-source data-science library, or blog post/article promoting 
Clojure for data science. In their favourite editor, of course!


Jony


On Sunday, 29 March 2015 10:55:34 UTC+1, Sayth Renshaw wrote:
>
> Hi 
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
> as a go to for data science? 
>
> It never seems to get a mention R,Python and now Julia get the attention. 
> By design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, 
> IPython ) where as you would need to use emacs with clojure, or is there 
> just a better default use of Clojure? 
>
> Sayth

-- 
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, not the go to for data science

[Alexis]

i'm assuming this response is a troll, given the use of the sort 
of gratuitous insults that Bozhidar mentioned; specific examples 
noted below. (And this somewhat amuses me, given the recent 
discussion about whether it's possible to critique different 
technologies without resorting to doing little more than 
trash-talking them.)


If it's /not/ intended to be a troll, then i feel it pretty much 
providing data which substantiates Bozhidar's complaint.


At any rate, on this occasion, i'll respond to a number of the 
points made; but feel free to have the final word (and sling some 
more gratuitous insults).


Fluid Dynamics  writes: 

* i don't have to learn and use a distinct, possibly  
  resource-hungry,  IDE[2] for every new programming language 
  or environment i  need/want to work in. (When the Swift 
  language was released, for  example, basic Swift support in 
  the form of `swift-mode` became  available within less than a 
  week.)  


Eclipse has plugins for a wide variety of languages.  


True, but i don't think i've ever heard that one of Eclipse's main 
selling points is that it's light on resource usage.


* Further to the resource-usage issue, i can more easily use 
Emacs  
  remotely over low-bandwidth links than i could use an IDE.  


Typical home and mobile connection speeds are multiple MBPS 
these days.


You respond to me saying that /i/ like Emacs for its ease-of-use 
across low-bandwidth links (which i regularly have to deal with) 
by  what, implying that i should be a so-called 'typical' 
home/mobile connection user instead?


Anyway, 'typical' varies from geographic location to geographic 
location. My home connection is ADSL2+, but my mobile provides 4G 
speeds only within a limited geographic area - and when i visited 
the city of Newcastle, New South Wales, recently, with it's 
population of ~300,000, my mobile data connection was 
intermittent, let alone of a decent speed. In such a situation, 
i've found being able to use a text-based UI, rather than being 
forced to use a graphical UI (even using something like NoMachine) 
quite a boon.


Further, even ADSL2+ bandwidth can be heavily saturated when other 
people on the connection are e.g. streaming HD movies at the same 
time as one is trying to work on a remote system 


* IDEs typically don't allow one to change their basic 
behaviours  
  whilst  they're running. Related: if there's a bug fix or 
  feature i want  applied, i can apply it myself, rather than 
  having to hope that  the maintainers will (a) accept that 
  it's something that  /should/ be applied, and (b) actually 
  apply it.  


The second, at least, applies to every open source IDE, 
including a certain EPL-licensed one. 


Not quite, at least not insofar as i understand what you're 
saying. i'm talking about not having to patch the source tree and 
recompile, even across new versions. In my Emacs config, i've 
redefined a few different Emacs functions to behave the way i 
want, such that, even when i install a new version of Emacs, i 
don't need to make any changes to the source itself to get the 
desired behaviour.


Unfortunately, one MUST do all of that and CANNOT use it as a 
black box, because it is the software analogue of a computer 
with no keyboard or monitor or anything else resembling a user 
interface, so one must toggle everything in and know the 
hardware internals backwards and forwards to get anything 
done. :)


A strong claim, considerably stronger than the weaker claim that 
Emacs needs tweaking to get to one's 'ideal' workflow, or even 
that Emacs needs more tweaking than other software to get to that 
workflow. i actually agree with the latter claim, but also feel 
that /for me/ the the benefits of doing most of it just once in 
Emacs have vastly outweighed the costs. i certainly acknowledge, 
howver, that this is a classic instance of 'YMMV'. 

Of course, there are some IDEs that run on top of the JVM, and 
are thus as widely available platform-wise as the JVM ... 


Granted. 

* Emacs is the product of approximately three decades of 
constant  
  development, such that it handles many corner-cases of many 
  scenarios (e.g. in the area of i18n) and continues to adapt 
  to  new ones.  


Three decades worth of accumulated legacy code. I can barely 
begin to  imagine what horrors must be lurking in some of the 
darker and less  well-traveled corners of that thing's /src 
directory. But you could  probably form a fairly accurate basic 
picture by reading the collected  works of one H. P. Lovecraft 
... :) 


A gratuitous insult, but sure, see http://emacshorrors.com/ for 
such examples.


Still, it's easy to dismiss the ugliness of legacy code when one 
doesn't have the luxury of not having to deal with the needs of a 
diverse user base over an extended period of time:


http://www.joelonsoftware.com/articles/fog69.html

And what kind of i18n corner cases tend to arise with a 7-bit 
80x24 character-based displ

Re: clojure, not the go to for data science

[Tassilo Horn]

Fluid Dynamics  writes:

> * i don't have to learn and use a distinct, possibly
> resource-hungry, IDE[2] for every new programming language or
> environment i need/want to work in. (When the Swift language was
> released, for example, basic Swift support in the form of
> `swift-mode` became available within less than a week.)
>
> Eclipse has plugins for a wide variety of languages. 

My experience has been that many plugins except for the really major
ones are frequently incompatible.  I.e., some cool plugin appears and
with the next eclipse release it won't work anymore because its
maintainers have a hard time keeping it up-to-date.

For that reason, it is not uncommon that people set up separate eclipse
installations for each and every project which has the exact version
required by the plugins needed for that project.

> * Further to the resource-usage issue, i can more easily use Emacs 
> remotely over low-bandwidth links than i could use an IDE. 
>
> Typical home and mobile connection speeds are multiple MBPS these days. 

Still, running Eclipse or some other IDE via X forwarding isn't too much
fun even with X2Go.

> * In my experience, Emacs tends to be less of a 'black box' than
> some IDEs, in that i can more easily get a better sense of what's
> going on "behind the scenes". This in turn means that i've got a
> better sense of the relevant build system, and how to fix and/or
> tune it in particular circumstances.
>
> Unfortunately, one MUST do all of that and CANNOT use it as a black
> box, because it is the software analogue of a computer with no
> keyboard or monitor or anything else resembling a user interface, so
> one must toggle everything in and know the hardware internals
> backwards and forwards to get anything done. :)

That's nonsense.  As soon as you have made yourself acquainted with the
basic Emacs terminology and concepts, getting started with Clojure
development is a piece of cake.  Of course, knowing more than that will
make it easier to make best use of its features and adapt it to your
personal preferences but that's the same with IDEs, too.

> And what kind of i18n corner cases tend to arise with a 7-bit 80x24
> character-based display (or emulation of same)?

Emacs follows the unicode standard and represents characters as
UTF8-encoded codepoints.

> * Emacs is, in my experience, one of the best-documented pieces of 
> software i've encountered. Absent or poor documentation is 
> typically treated as a bug. 
>
> The issue with its documentation isn't, of course, its existence or
> comprehensiveness.

No, but that's the issue many IDEs have.  Usually, you have a button or
a menu entry for some functionality possibly with some tooltip, and
that's as much "documentation" as you get.

> Rather, the last time I tried using emacs, I seem to recall always
> ending up with this sequence of events:
>
> a) I am trying to do some task X, for which the obvious key combination bleeps
> or does something weird but definitely doesn't do X for some reason.
> b) Soon, I have a split pane with my document on the left and the help files 
> on
> the right, with the latter open to a page on task X and the input focus in it.
> c) A little bit later, I have a split pane with my document on the left, the
> input focus in my document, and the help pane on the right open to a page on
> how to switch focus between panes, and I don't remember the long and
> complicated sequence of keystrokes needed to perform task X any more because 
> it
> was deleted from my brain's short term memory to remember the long and
> complicated sequence of keystrokes that is how one says "alt+tab" in the
> obscure and archaic dialect known as emacsese.
> d) Repeat b) and c) a few times, while experiencing an acute event of abnormal
> pre-menopausal hair loss.
> e) Give up and fire up Notepad, Eclipse, or whatever seems best suited to
> current task. ;)

I think with "help pane" you mean a window showing the Emacs info
manual.  You can have as many of them open as you like, say, one for
"task X", and one for "switching focus between windows".

> * The Emacs ecosystem is growing rapidly; http://melpa.org/
> currently lists ~2400 packages ("extensions" or "addons")
> available for easy installation via Emacs' package.el UI.
>
>
> I wonder how anyone can find anything in that mess.

Searching might be a start.

> The Java and Clojure IDEs are probably each sandwiched amongst
> hundreds of consecutive entries

Yes, of course.  Hey, how to people use apt-get/packman/yum/whatever?
The packages needed for "task X" are sandwiched between tens of
thousands of unrelated packages.

> all the rest of which are for languages nobody has ever heard of
> outside of one obscure city near Bernhöfen, or that nobody has used
> since 1987, or that nobody has used period because the whole thing was
> invented as an obscure joke (e.g.  Befunge).

I don't see how support for nic

Re: clojure, not the go to for data science

[Fluid Dynamics]

On Monday, March 30, 2015 at 4:18:03 AM UTC-4, Alexis wrote:
>
>
> Bozhidar Batsov > writes: 
>
> > Anti-Emacs stuff really gets to me. 
>
> i too find it somewhat tiresome. It makes me wonder how many 
> people have actually stopped and asked themselves: "Given that 
> Emacs seems like a crusty ancient artifact from The Land That Time 
> Forgot, why do so many people keep using it?" 
>
> i can't speak for other Emacs users, of course, but here are some 
> of the main reasons i prefer to use (GNU) Emacs[1]: 
>
> * i don't have to learn and use a distinct, possibly 
>   resource-hungry, 
>   IDE[2] for every new programming language or environment i 
>   need/want to work in. (When the Swift language was released, for 
>   example, basic Swift support in the form of `swift-mode` became 
>   available within less than a week.) 
>

Eclipse has plugins for a wide variety of languages. 

* Further to the resource-usage issue, i can more easily use Emacs 
>   remotely over low-bandwidth links than i could use an IDE. 
>

Typical home and mobile connection speeds are multiple MBPS these days. 

* IDEs typically don't allow one to change their basic behaviours 
>   whilst 
>   they're running. Related: if there's a bug fix or feature i want 
>   applied, i can apply it myself, rather than having to hope that 
>   the maintainers will (a) accept that it's something that 
>   /should/ be applied, and (b) actually apply it. 
>

The second, at least, applies to every open source IDE, including a certain 
EPL-licensed one.
 

> * In my experience, Emacs tends to be less of a 'black box' than 
>   some 
>   IDEs, in that i can more easily get a better sense of what's 
>   going on "behind the scenes". This in turn means that i've got a 
>   better sense of the relevant build system, and how to fix and/or 
>   tune it in particular circumstances.
>

Unfortunately, one MUST do all of that and CANNOT use it as a black box, 
because it is the software analogue of a computer with no keyboard or 
monitor or anything else resembling a user interface, so one must toggle 
everything in and know the hardware internals backwards and forwards to get 
anything done. :) 

* Emacs is available for a wider range of platforms than most 
>   IDEs, 
>   meaning it's more likely to be available to me should i need to 
>   work on a particular platform. 
>

Of course, there are some IDEs that run on top of the JVM, and are thus as 
widely available platform-wise as the JVM ...
 

> * Emacs is the product of approximately three decades of constant 
>   development, such that it handles many corner-cases of many 
>   scenarios (e.g. in the area of i18n) and continues to adapt to 
>   new ones. 
>

Three decades worth of accumulated legacy code. I can barely begin to 
imagine what horrors must be lurking in some of the darker and less 
well-traveled corners of that thing's /src directory. But you could 
probably form a fairly accurate basic picture by reading the collected 
works of one H. P. Lovecraft ... :)

And what kind of i18n corner cases tend to arise with a 7-bit 80x24 
character-based display (or emulation of same)? Just out of curiosity.

* Emacs is, in my experience, one of the best-documented pieces of 
>   software i've encountered. Absent or poor documentation is 
>   typically treated as a bug. 
>

The issue with its documentation isn't, of course, its existence or 
comprehensiveness. Rather, the last time I tried using emacs, I seem to 
recall always ending up with this sequence of events:

a) I am trying to do some task X, for which the obvious key combination 
bleeps or does something weird but definitely doesn't do X for some reason.
b) Soon, I have a split pane with my document on the left and the help 
files on the right, with the latter open to a page on task X and the input 
focus in it.
c) A little bit later, I have a split pane with my document on the left, 
the input focus in my document, and the help pane on the right open to a 
page on how to switch focus between panes, and I don't remember the long 
and complicated sequence of keystrokes needed to perform task X any more 
because it was deleted from my brain's short term memory to remember the 
long and complicated sequence of keystrokes that is how one says "alt+tab" 
in the obscure and archaic dialect known as emacsese.
d) Repeat b) and c) a few times, while experiencing an acute event of 
abnormal pre-menopausal hair loss.
e) Give up and fire up Notepad, Eclipse, or whatever seems best suited to 
current task. ;)

* The Emacs ecosystem is growing rapidly; http://melpa.org/ 
>   currently 
>   lists ~2400 packages ("extensions" or "addons") available for 
>   easy installation via Emacs' package.el UI. 
>

I wonder how anyone can find anything in that mess. The Java and Clojure 
IDEs are probably each sandwiched amongst hundreds of consecutive entries 
all the rest of which are for languages nobody has ever heard of outside of 
one obscure city near Bernhöfen, or

Re: clojure, not the go to for data science

[Alexis]

Colin Yates  writes:


I used it a few years back


[snip]

[and] even after man-months spent tinkering, hunting down the 
right version on MELPA or MARMALADE (or whatever it is called)


MELPA and Marmalade are two separate ELPAs ("Emacs Lisp Package 
Archives") - others include MELPA Stable, GNU ELPA and quelpa.


i basically only use MELPA and GNU ELPA. In terms of the ~200 
packages i've installed from MELPA, i can't remember having to 
deal with versioning issues at all. Further, despite some people 
fretting about the theoretical lack of stability of packages on 
MELPA, i've only rarely had to deal with broken packages - and 
those breakages have been fixed very rapidly by the 
maintainers. (i maintain a few ELisp packages myself, and also 
work to address issues with my packages promptly.)



I still couldn't get close to what Cursive gives me OOTB.


*nod*

However, Emacs configuration management has, i feel, improved 
significantly over the last couple of years, with things like 
`use-package`:


https://github.com/jwiegley/use-package

or `pallet`:

https://github.com/rdallasgray/pallet

enabling one to create easily-reproducible config setups across 
environments/machines.



Alexis.

--
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: how do you re-load a clojure library?

[Juvenn Woo]

Hey Andy,

As a devops, I do appreciate that, thank you for sharing!



—
Sent from Mailbox

On Sun, Mar 29, 2015 at 10:17 PM, Andy-  wrote:

> Off topic for this list but I'm sure helpful to some:
> On Windows: You can see open file handles with MS's Process Explorer.
> On Linux: There is `lsof`, or if you like interactive: The popular `htop` 
> utility allows you to press `l` to see all open ports, files and cwd of a 
> process.
> This quickly allows you to figure out where the .jar's are actually loaded 
> from.
> Both are very good to know in general.
> HTH
> On Sunday, March 29, 2015 at 10:11:18 AM UTC-4, Dan Campbell wrote:
>>
>>
>>
>> There it is, in Windows, at c:\Users\DC\.m2\repository, will try that, 
>> thanks Juvenn.
>>
>>
>>
>>
>>
>> On Sunday, March 29, 2015 at 8:08:22 AM UTC-4, juvenn wrote:
>>>
>>>  Hi Dan, 
>>>
>>> All jars files are kept at `~/.m2/repositories` on *nix, as far as I 
>>> know. So you can just find and delete them over there. The next time you 
>>> run a lein task, it will re-download it.
>>>
>>> Best,
>>> -- 
>>> Juvenn Woo
>>> Sent with Sparrow 
>>>
>>> On Sunday, 29 March, 2015 at 7:43 pm, Dan Campbell wrote:
>>>
>>>
>>> If you wanted to sort of 'clean out' a clojar or any contrib, korma or 
>>> core.async or whatever, how would you do that?
>>>
>>> In other words, if you wanted a specific library to be re-downloaded and 
>>> deployed (i.e., refreshed) on your desktop, what command would you run?  Or 
>>> what folders would you clean out?
>>>
>>>
>>>  -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@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.

Re: clojure, not the go to for data science

[Colin Yates]

For me personally, I absolutely admire emacs - I really do. I used it
a few years back when I first started in Clojure before Cursive was
around and when it was configured correctly it was absolutely great.
>From an engineering POV, yeah, it rocks.

I am sure that for anything I can do in IDE-X I can do it in emacs.
The major difference is, and the reason that I no longer use emacs is
that IDE-X _probably_ ships it out of the box (or at least is one or
two plugins away), and this is very important when you end up
re-installing stuff a lot on your machine and co-developers. Yeah, I
know, git your .emacs or use one of the curated packs (of which
Batsov's is absolutely great), but even after man-months spent
tinkering, hunting down the right version on MELPA or MARMALADE (or
whatever it is called) I still couldn't get close to what Cursive
gives me OOTB.

Emacs to me was something that could be absolutely great, but I just
ran out of time making it so. Do I feel part of the
'I'm-not-clever-enough-to-make-emacs-work-properly' club - sure :).

Emacs is great if you want to build your own editor, anything else is
great if you need to work now.

On 30 March 2015 at 05:32, Alexis  wrote:
>
> Bozhidar Batsov  writes:
>
>> Anti-Emacs stuff really gets to me.
>
>
> i too find it somewhat tiresome. It makes me wonder how many people have
> actually stopped and asked themselves: "Given that Emacs seems like a crusty
> ancient artifact from The Land That Time Forgot, why do so many people keep
> using it?"
>
> i can't speak for other Emacs users, of course, but here are some of the
> main reasons i prefer to use (GNU) Emacs[1]:
>
> * i don't have to learn and use a distinct, possibly  resource-hungry,
> IDE[2] for every new programming language or environment i  need/want to
> work in. (When the Swift language was released, for  example, basic Swift
> support in the form of `swift-mode` became  available within less than a
> week.)
>
> * Further to the resource-usage issue, i can more easily use Emacs  remotely
> over low-bandwidth links than i could use an IDE.
>
> * IDEs typically don't allow one to change their basic behaviours  whilst
> they're running. Related: if there's a bug fix or feature i want  applied, i
> can apply it myself, rather than having to hope that  the maintainers will
> (a) accept that it's something that  /should/ be applied, and (b) actually
> apply it.
>
> * In my experience, Emacs tends to be less of a 'black box' than  some
> IDEs, in that i can more easily get a better sense of what's  going on
> "behind the scenes". This in turn means that i've got a  better sense of the
> relevant build system, and how to fix and/or  tune it in particular
> circumstances.
>
> * Emacs is available for a wider range of platforms than most  IDEs,
> meaning it's more likely to be available to me should i need to  work on a
> particular platform.
>
> * Emacs is the product of approximately three decades of constant
> development, such that it handles many corner-cases of many  scenarios (e.g.
> in the area of i18n) and continues to adapt to  new ones.
>
> * Emacs is, in my experience, one of the best-documented pieces of  software
> i've encountered. Absent or poor documentation is  typically treated as a
> bug.
>
> * The Emacs ecosystem is growing rapidly; http://melpa.org/  currently
> lists ~2400 packages ("extensions" or "addons") available for  easy
> installation via Emacs' package.el UI.
>
> * Clojure-oriented point #1: since ~80%[3] of Emacs is written in  Emacs
> Lisp, a lot of work has been put into support for sexp-based  languages; cf.
> `paredit`.
>
> * Clojure-oriented point #2: having a polyglot dev system written  in an
> easily-modifiable Lisp environment makes it more attractive to  me as
> someone with a Lisp mindset, as per my interest in  Clojure. :-)
>
> Yes, there can be a steeper initial learning curve with Emacs than with
> IDEs, e.g. things like 'frames' and 'windows' not meaning what one might
> expect (which is hardly surprising, given that GNU Emacs predates the
> existence of GUIs-as-standard, and the Web). Yet this is a one-time cost
> that, in my experience, is rapidly amortised as one starts to use Emacs in
> an increasingly wider variety of contexts. For example: being able to use
> CIDER when i wanted to start learning Clojure meant that i could focus on
> learning Clojure itself, rather than an entire new dev system.
>
> Emacs is surely not the best tool for all developers in all contexts, but i
> also feel it's something that developers - and Clojure developers in
> particular - should perhaps at least give a second look.
>
>
> Alexis.
>
> ---
>
> [1] Or Vim, if Emacs isn't an option. Some things i mention here arealso
> applicable to use of Vim.
>
> [2] In the /literal/ sense of the phrase, Emacs can indeed provide an
> Integrated Development Environment. But obviously, i'm herereferring to
> highly graphical IDEs such as Eclipse.
> [3] According to David A. Wheele

Re: clojure, not the go to for data science

[Alexis]

Bozhidar Batsov  writes:


Anti-Emacs stuff really gets to me.


i too find it somewhat tiresome. It makes me wonder how many 
people have actually stopped and asked themselves: "Given that 
Emacs seems like a crusty ancient artifact from The Land That Time 
Forgot, why do so many people keep using it?"


i can't speak for other Emacs users, of course, but here are some 
of the main reasons i prefer to use (GNU) Emacs[1]:


* i don't have to learn and use a distinct, possibly 
 resource-hungry, 
 IDE[2] for every new programming language or environment i 
 need/want to work in. (When the Swift language was released, for 
 example, basic Swift support in the form of `swift-mode` became 
 available within less than a week.)


* Further to the resource-usage issue, i can more easily use Emacs 
 remotely over low-bandwidth links than i could use an IDE.


* IDEs typically don't allow one to change their basic behaviours 
 whilst 
 they're running. Related: if there's a bug fix or feature i want 
 applied, i can apply it myself, rather than having to hope that 
 the maintainers will (a) accept that it's something that 
 /should/ be applied, and (b) actually apply it.


* In my experience, Emacs tends to be less of a 'black box' than 
 some 
 IDEs, in that i can more easily get a better sense of what's 
 going on "behind the scenes". This in turn means that i've got a 
 better sense of the relevant build system, and how to fix and/or 
 tune it in particular circumstances.


* Emacs is available for a wider range of platforms than most 
 IDEs, 
 meaning it's more likely to be available to me should i need to 
 work on a particular platform.


* Emacs is the product of approximately three decades of constant 
 development, such that it handles many corner-cases of many 
 scenarios (e.g. in the area of i18n) and continues to adapt to 
 new ones.


* Emacs is, in my experience, one of the best-documented pieces of 
 software i've encountered. Absent or poor documentation is 
 typically treated as a bug.


* The Emacs ecosystem is growing rapidly; http://melpa.org/ 
 currently 
 lists ~2400 packages ("extensions" or "addons") available for 
 easy installation via Emacs' package.el UI.


* Clojure-oriented point #1: since ~80%[3] of Emacs is written in 
 Emacs 
 Lisp, a lot of work has been put into support for sexp-based 
 languages; cf. `paredit`.


* Clojure-oriented point #2: having a polyglot dev system written 
 in an 
 easily-modifiable Lisp environment makes it more attractive to 
 me as someone with a Lisp mindset, as per my interest in 
 Clojure. :-)


Yes, there can be a steeper initial learning curve with Emacs than 
with IDEs, e.g. things like 'frames' and 'windows' not meaning 
what one might expect (which is hardly surprising, given that GNU 
Emacs predates the existence of GUIs-as-standard, and the 
Web). Yet this is a one-time cost that, in my experience, is 
rapidly amortised as one starts to use Emacs in an increasingly 
wider variety of contexts. For example: being able to use CIDER 
when i wanted to start learning Clojure meant that i could focus 
on learning Clojure itself, rather than an entire new dev system.


Emacs is surely not the best tool for all developers in all 
contexts, but i also feel it's something that developers - and 
Clojure developers in particular - should perhaps at least give a 
second look.



Alexis.

---

[1] Or Vim, if Emacs isn't an option. Some things i mention here 
are 
   also applicable to use of Vim.


[2] In the /literal/ sense of the phrase, Emacs can indeed provide 
an 
   Integrated Development Environment. But obviously, i'm here 
   referring to highly graphical IDEs such as Eclipse. 


[3] According to David A. Wheeler's sloccount(1) run on the Emacs 24.5.1
   sources.

--
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: How do I upgrade nREPL?

[Shannon Severance]

I saw no difference in behavior, if I understood how to create the :dev 
profile:

{:user {:plugins [[cider/cider-nrepl "0.9.0-SNAPSHOT"]
  [lein-pprint "1.1.2"]]
:dependencies [[org.clojure/tools.nrepl "0.2.10"]]}
 :dev {:dependencies [[org.clojure/tools.nrepl "0.2.10"]]}}

>
>>

-- 
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: How do I upgrade nREPL?

[Bozhidar Batsov]

Yeah, other have noticed this as well
https://github.com/clojure-emacs/cider/issues/961

Not sure if this is a Lein bug or a feature.

On 30 March 2015 at 10:09, Shannon Severance  wrote:

> Through some additional experimentation, I have found when I start
> Leiningen repl within a Leiningen project, the nrepl dependency from
> ~/.lien/profiles.clj is being used. nREPL 0.2.10 is started. This is true
> if I start via `lein repl` or `cider-jack-in`.
>
> The problem exists when starting free of a project.
>
> -- Shannon
>
> --
> 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: How do I upgrade nREPL?

[Shannon Severance]

Through some additional experimentation, I have found when I start 
Leiningen repl within a Leiningen project, the nrepl dependency from 
~/.lien/profiles.clj is being used. nREPL 0.2.10 is started. This is true 
if I start via `lein repl` or `cider-jack-in`.

The problem exists when starting free of a project.

-- Shannon

-- 
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.