Re: Clojure 1.5.1 and Sockets

2013-08-11 Thread Christian Sperandio
Thanks for your answer. I'm wrapping the Java methods so. Without regret or remorse :) -- -- 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 - p

Re: Clojure 1.5.1 and Sockets

2013-08-11 Thread Plínio Balduino
Hi, Christian If you look the sources of create-server, you will see it's using Java sockets wrapped as Clojure functions. The same thing about Java threads. It's not a bad thing and soon or later you will find some Java object wrapped somewhere. IMHO, I don't think Clojure need something specif

Re: clojure 1.5.1, emacs/nrepl and clojure.repl

2013-07-08 Thread Colin Yates
That works a treat - thanks. On 8 July 2013 16:49, Neale Swinnerton wrote: > Hi Col, > > On Mon, Jul 8, 2013 at 4:43 PM, Colin Yates wrote: > >> Alternatively, in the vein of just getting things done, can I do some >> emacs fu to automatically load clojure.repl? Silly me - of course I can - >

Re: clojure 1.5.1, emacs/nrepl and clojure.repl

2013-07-08 Thread Colin Yates
Ah yes - nice find. On 8 July 2013 17:24, Tim Visher wrote: > On Mon, Jul 8, 2013 at 11:43 AM, Colin Yates > wrote: > > If using clojure 1.4.0 then when I start nrepl (CcMj) then I the > > clojure.repl namespace is automatically 'used. If I upgrade to Clojure > > 1.5.1 then it doesn't. I can

Re: clojure 1.5.1, emacs/nrepl and clojure.repl

2013-07-08 Thread Tim Visher
On Mon, Jul 8, 2013 at 11:43 AM, Colin Yates wrote: > If using clojure 1.4.0 then when I start nrepl (CcMj) then I the > clojure.repl namespace is automatically 'used. If I upgrade to Clojure > 1.5.1 then it doesn't. I can still (use 'clojure.repl) but is this a bug? > > I can't believe I would

Re: clojure 1.5.1, emacs/nrepl and clojure.repl

2013-07-08 Thread Neale Swinnerton
Hi Col, On Mon, Jul 8, 2013 at 4:43 PM, Colin Yates wrote: > Alternatively, in the vein of just getting things done, can I do some > emacs fu to automatically load clojure.repl? Silly me - of course I can - > this is emacs :). No idea what that fu would be though... Any hints? > > Since nrepl

Re: Clojure 1.5.1 head holding

2013-07-01 Thread Kevin Downey
On 7/1/13 3:49 AM, Gerrard McNulty wrote: > Suppose I had code like: > > ((fn [rs] (take-last 3 rs)) (range 2000)) > > This seems to run fine with no head holding. But if I write something like: > > (defn- log [f] > (println "start") > (f) > (println "end")) > > ((fn [rs] (log #(take

Re: Clojure 1.5.1 head holding

2013-07-01 Thread Gerrard McNulty
Hi Meikel, That works for me too. I can use that when I control the definition of that function. However sometimes I don't e.g. when I use with-redefs, which calls with-redefs-fn. On Monday, July 1, 2013 12:23:34 PM UTC+1, Meikel Brandmeyer (kotarak) wrote: > > Hi, > > I did a slight variati

Re: Clojure 1.5.1 head holding

2013-07-01 Thread Meikel Brandmeyer (kotarak)
Hi, I did a slight variation which does not close over the head and it seems to work fine. (defn log [f & args] (println "start") (apply f args) (println "stop")) ((fn [xs] (log take-last 3 xs)) (range 2)) Kind regards Meikel -- -- You received this message because you are s

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Colin Yates
Ah OK, I didn't realise. I thought the vars would be locally scoped, i.e. semantically equivalent to 'let'ed symbols. Thanks everyone for contributing. On Friday, 21 June 2013 14:49:52 UTC+1, Jim foo.bar wrote: > > On 21/06/13 14:34, Colin Yates wrote: > > Is it correct but simply non-idiom

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Jim - FooBar();
On 21/06/13 15:06, Andy Fingerhut wrote: Colin showed pretty clearly in his email that he was using "lein uberjar" followed by running the JVM explicitly with his own command line, so Leiningen has no way to affect the JVM command line options in that case. oops! I thought Michael meant the g

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Michael Klishin
2013/6/21 Jim - FooBar(); > Did you read the entire thread? > both Jason and Leon (who originally posted) admit that this was the > problem...Stuart even opened this issue: > https://github.com/technomancy/leiningen/pull/1230 > Leiningen's default only apply if you, hm, run Leiningen. If you ru

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Andy Fingerhut
:jvm-opts and that ticket for Leiningen only affect the options passed to the JVM if you let Leiningen invoke the JVM for you, e.g. via "lein run ..." Colin showed pretty clearly in his email that he was using "lein uberjar" followed by running the JVM explicitly with his own command line, so Lein

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Jim - FooBar();
Did you read the entire thread? both Jason and Leon (who originally posted) admit that this was the problem...Stuart even opened this issue: https://github.com/technomancy/leiningen/pull/1230 the very last post reads: I should follow up on this and clarify that core.matrix's esum is in fact a

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Michael Klishin
2013/6/21 Jim - FooBar(); > If you're using leiningen, add this entry to your project.clj and rerun > your benchmarks. > > :jvm-opts ^replace [] > Original post suggests the code is executed by building an uberjar running java -jar target/… so Leiningen default JVM options are not relevant. --

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Michael Klishin
2013/6/21 Colin Yates > Is it correct but simply non-idiomatic? It's not how defs are supposed to be used. It's like using fields for everything in Java even though you could use local variables for a lot of things, just because you can. def produces a shared (well, namespace-local) var. You p

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Jim - FooBar();
On 21/06/13 14:34, Colin Yates wrote: Is it correct but simply non-idiomatic? no no it's actually very *dangerous*...by doing this you're essentially introducing mutable global state in your program and Clojure is a language that strives hard to minimise mutable and especially global state!

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Colin Yates
Thanks Jim and David. David, can you expand on why it is incorrect? That is such a strong word. Is it correct but simply non-idiomatic? Also note that if I move the body out of the 'let' version of the array into another function passing in the array then the performance is the same as the 'def

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread David Nolen
Using `def` like that is simply incorrect. `def` should always be at the top level unlike say Scheme. I would first remove all internal defs and then rerun your benchmarks. On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates wrote: > Hi all, > > I am doing some (naive and trivial) performance tests b

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

2013-06-21 Thread Jim - FooBar();
a start would be to set *warn-on-reflection* & *unchecked-math* to true...I think you're not properly type-hinting your 'aget' calls. areduce is the fastest way to sum up an array of primitives given that there are no reflective calls. This takes just over 19 ms on my humble machine and don't f

Re: Clojure 1.5.1

2013-03-11 Thread Stuart Halloway
Fixed, thanks. Stu On Sun, Mar 10, 2013 at 7:28 PM, wrote: > I think there's a typo in the download link on > http://clojure.org/downloads: > > It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0* > /clojure-1.5.1.zip

Re: Clojure 1.5.1

2013-03-10 Thread ke . mar . 92
I think there's a typo in the download link on http://clojure.org/downloads: It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0* /clojure-1.5.1.zip whereas it should be http://repo1.maven.org/maven2/org/clojur

Re: Clojure 1.5.1

2013-03-10 Thread Ghadi Shayban
fyi - Rich's .idea/ crept in on the bug fix commit. On Sunday, March 10, 2013 8:35:34 PM UTC+2, Stuart Halloway wrote: > > Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here: > > https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ > > Getting Clojure: > > Web: