Re: :refer-clojure broken?

[Gregg Reynolds]

Never mind.  For some reason I had   (:require [clojure.core :refer :all]
...) after(:refer-clojure :exclude [print println print-str]) .

Sorry about the bother.

Gregg



On Tue, Sep 15, 2015 at 1:22 PM, Gregg Reynolds  wrote:

>
>
> On Sun, Sep 13, 2015 at 9:23 PM, Alex Miller  wrote:
>
>> Can you be more specific about how you are loading the namespace?
>>
>
> Sorry for not getting back to you sooner, I did a little more
> experimenting to no avail.  You can see it in action at migae datastore
>  .  Clone it, run
>
> $ lein with-profile compile compile
> $ lein repl
>
> and you should see the WARNINGS.  Note that my :dev profile is configured
> to add "dev" to the source path, so dev/user.clj is picked up; it requires
> the offending library, migae.datastore.
>
> Thanks,
>
> Gregg
>
>
>>
>> I can't reproduce this with a pure Clojure repl or with a Leiningen repl
>> on Clojure 1.7 or 1.8.
>>
>> On Sunday, September 13, 2015 at 6:23:37 PM UTC-5, Gregg Reynolds wrote:
>>>
>>> PS.
>>>
>>> REPL-y 0.3.5, nREPL 0.2.10
>>> Clojure 1.7.0
>>> Java HotSpot(TM) 64-Bit Server VM 1.8.0_45-b14
>>>
>>>
>>> On Sun, Sep 13, 2015 at 6:21 PM, Gregg Reynolds 
>>> wrote:
>>>
 Just to be perverse, in my library I'm defining `print`.  So I get the
 usual warning:

 WARNING: print already refers to: #'clojure.core/print in namespace:
 migae.datastore, being replaced by: #'migae.datastore/print

 So I add a clause to my (ns...) form:

   (:refer-clojure :exclude [print])

 This has no effect - I still get the warning.  What's wrong with this
 picture?

 Thanks,

 Gregg

>>>
>>> --
>> 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: deftype code reload oddity

[Gregg Reynolds]

Here's another bit of strangeness.  I tried putting my interfaces file at
the root (see https://github.com/migae/datastore/tree/master/src/clojure);
this seems to work ok.  Then I fooled around with profiles etc. to try to
avoid having Interfaces.clj ever be reloaded - it's only needed once, for
aot compilation.  So I created src/clj-compile/Interfaces.clj, configured a
profile to compile that and excluded it from the :dev profile; even though
it is in clj-compile, it generates class files in src/clojure.  Then I
compile once, and when I start the repl the Interfaces.clj file is not
touched.   Seemed to work ok - but the dynamic reloading stopped working.
BTW the deftype files that implement the generated interfaces are
src/clojure/migae/datastore/Persistent*.  The reloading stops working just
for those deftypes.

Even weirder:  reloading the deftypes only works if I reload something else
first.  datastore.clj loads the Persistent*.clj files (containing deftype)
first, then defines some stuff, then loads some other files (which use
in-ns).  It is only after I edit and reload one of those other files (e.g.
ctor_local.clj) that reloading the deftype stuff works.

Thanks,

Gregg

On Sat, Sep 12, 2015 at 10:21 AM, Gregg Reynolds  wrote:

>
>
> On Sat, Sep 12, 2015 at 7:17 AM, Alex Miller  wrote:
>
>> This is a tricky area and one that has seen changes lately - what version
>> of Clojure are you using?
>>
>
> Clojure 1.7.0
> Java HotSpot(TM) 64-Bit Server VM 1.8.0_45-b14
>
> A little more background info in case it helps:  I've got two
> gen-interfaces, and three typedefs.  I want the typedefs in separate files
> (to void editing confusion) but same namespace, so I have:
>
> ;; foo/core.clj
> (ns foo.core...)
> ...
> (load "bar/mytype")
>
> ;; foo/bar/mytype.clj
> (in-ns 'foo.core)
> ...
> (typedef MyType
> foo.bar.IMyInterface
>  ...)
>
> ;; foo/interfaces.clj  (aot-compiled)
> (gen-interface :name foo.bar.IMyInterface
>   :extends [clojure.lang.IFn
> clojure.lang.IPersistentMap
> ...])
>
>
> Then I use ns-tracker to handle reloading.  Then the problem is that
> ns-tracker that when I edit foo/mytype.clj, ns-tracker picks up the quote
> in (in-ns 'foo.core) and throws
>
>   java.lang.Exception: Found lib name 'foo.core' containing period
> with prefix 'quote'.  lib names inside prefix lists must not contain periods
>
> My workaround is:
>
> (def mod-namespaces (ns-tracker [ ...blah blah ...]))
> (doseq [ns-sym (mod-namespaces)]
>(let [sym (if (symbol? ns-sym)
> ns-sym
>   (last ns-sym))]   ;; if foo/bar/mytype.clj is the
> changed file, ns-sym is (quote foo.core), of type clojure.lang.Cons
> (require sym :reload)))
>
> Works great so far, as long as my typedefs specify an interface generated
> by gen-interface.
>
> Thanks,
>
> Gregg
>
>
>
>>
>>
>> On Friday, September 11, 2015 at 10:42:32 PM UTC-5, Gregg Reynolds wrote:
>>>
>>> Here's something a little perplexing that I discovered by trial and
>>> error:  if you reload (using require :reload) a clj file containing a
>>> deftype implementing clojure interfaces (e.g. ISeq, etc.) plus some
>>> functions, the functions will be reloaded but not the deftype
>>> implementation code.  That is, the clj file will be reloaded, but changes
>>> in the deftype implementation code will not take effect.
>>>
>>> But if you use gen-interface (in another file, aot-compiled) to create
>>> your interface using your own namespace, and then list that custom
>>> interface (rather than the clojure interfaces) in the deftype, then the
>>> implementation code gets reloaded.  I don't really see why this is so, and
>>> haven't found any relevant documentation.  Can anybody explain what's
>>> happening behind the curtain?
>>>
>>> Note: I'm running this on the Gooble AppEngine dev server, but I
>>> shouldn't think that makes any difference.
>>>
>>> Thanks,
>>>
>>> -Gregg
>>>
>>> Example:
>>>
>>> A.  This does not support code reloading for the deftype implementation
>>> code:
>>>
>>> ;; in foo/bar.clj:
>>> (ns foo.bar...)
>>> ... other functions...
>>> (deftype baz
>>> clojure.lang.Seq
>>> (first [_] ...)
>>> (next [_] ...)
>>> )
>>>
>>>
>>> B.  This does support reloading of the detype:
>>>
>>> ;; in some/other/namespace.clj:
>>> (ns some.other.namespace ...)
>>> (gen-interface :name foo.bar.Baz
>>>  :extends [clojure.lang.Seq ...]
>>> ...)
>>>
>>> ;; in foo/bar.clj:
>>> (ns foo.bar ...)
>>> ... other functions ...
>>> (deftype baz
>>>foo.bar.Baz
>>>... implementations as before ...
>>> )
>>>
>> --
>> 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/cl

Re: lazy-seq and threads

[Andy L]

Hi,

Thanks for looking into my questions. I posted a self contained example
here https://github.com/coreasync/parallel-gzip with instructions how to
create test data as well. Also attached results below I get on my quite
decent hardware (partial 'time' results are mangled, was not sure how to
separate them). I use two separate 'lazy-seq', however I heard somewhere,
that they are not free even if no synchronization takes place, like in this
case but could be optimized out for a single thread situation. Apologies
for jumping into conclusion ... Also, I do not believe that we deal with a
significant amount of IO as those test files easily fit into O/S buffers.

Two test runs below show, that we can easily take advantage of multiple
cores. Java versions scale well. Same in the Clojure code for uncompressed
files. In all 3 cases, resulting in JVM taking a stable 200% of CPU, i.e.
occupying two cores. Also Java and Clojure time numbers are quite
consistent.

However, as soon as I add a GZIPInputStream input stream, Clojure version
start pegging 400, 500, 600% of CPU varying over time. I assumed initially,
taht effort was spend for some thread synchronization tasks as JIT was not
able to factor out due to more code involved. Interestingly enough, YourKit
shows only two threads busy interlaced with empty spaces, almost looking
like JVM being busy doing some kind of house keeping, hitting CPU really
bad. Thread dumps did not reveal anything weird, no locking contention, etc
... I tried Java 7 and 8 as well as Clojure 1.7 and 1.8 - none of make any
difference.

Understanding where that limitation comes from is quite critical, as I try
to use hardware to the best possible extend.

Thanks in advance for hints and clues ...
AndyL


# create test data
$curl -o 1 http://norvig.com/big.txt
$cat 1 1 1 1 1 1 1 1 > 2
$cat 2 2 2 2 2 2 2 2 > 3
$cat 3 3 3 3 3 3 3 3 > 4
$gzip -k 4
$lein run 4
starting...

uncompressed
Java code:
"Elapsed time: 8258.013802 msecs"
(65769984)
"Elapsed time: 8268.641987 msecs"
Clojure code:
"Elapsed time: 9117.814135 msecs"
(65769984)
"Elapsed time: 9118.270526 msecs"

compressed
Java code:
"Elapsed time: 21522.20167 msecs"
(65769984)
"Elapsed time: 21522.663463 msecs"
Clojure code:
"Elapsed time: 21573.585966 msecs"
(65769984)
"Elapsed time: 21574.013417 msecs"
...finished
$ lein run 4 4
starting...

uncompressed
Java code:
""EEllaappsseedd  ttiimmee::  77226688..0857983348 msec1s "m
secs"
(65769984 65769984)
"Elapsed time: 7280.09169 msecs"
Clojure code:
""EEllaappsseedd  ttiimmee::  9911..113308627362  mmsseeccss""

(65769984 65769984)
"Elapsed time: 9177.644745 msecs"

compressed
Java code:
"Elapsed time: 22324.81872 msecs"
"Elapsed time: 23122.111874 msecs"
(65769984 65769984)
"Elapsed time: 23122.511818 msecs"
Clojure code:
"Elapsed time: 75968.051536 msecs"
"Elapsed time: 76018.787437 msecs"
(65769984 65769984)
"Elapsed time: 76019.215303 msecs"
...finished

-- 
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: Unexpected behavior for symbols or keywords used in the operator position

[Michael O'Keefe]

Aha, got it. Just surprised me that it still worked without a map.

Thanks for clearing it up!

Cheers

On Tuesday, September 15, 2015 at 10:29:08 PM UTC-6, Carlo wrote:
>
> Symbols and keywords act as functions which look themselves up in their 
> argument. Essentially:
>
>   ('sym map) => (get map 'sym)
>  ('sym map not-found) => (get map 'sym not-found)
>
>   (:key map) => (get map :key)
>  (:key map not-found) => (get map :key not-found)
>
> It's often pretty useful, in my experience. It looks cleaner, and it 
> means that you can just use :keyword instead of #(get % :keyword) in 
> cases where you provide a function as an argument (for example: (map 
> :type objects)).
>
> On 16 September 2015 at 14:20, Michael O'Keefe  > wrote:
>
>> Hello All:
>>
>> Noticed the following works in Clojure 1.6 and 1.7 (didn't test prior to 
>> that):
>>
>> user=> ('+ 'a 'b)
>> b
>>
>> Also "works" for any set of symbols:
>>
>> user=> ('abra 'ka 'dabra)
>> dabra
>>
>> My expectation was that using symbols or keywords in the 
>> function/operator position would throw an exception similar to this:
>>
>> user=> (3 4)
>>
>>
>> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn 
>>  user/eval7668 (form-init2947310628177413729.clj:1)
>>
>>
>> I noticed Keywords can also be used in the operator position:
>>
>> user=> (:abra :ka :dabra)
>> :dabra
>>
>> And mixing and matching is OK:
>>
>> user=> (:a 'b 3)
>> 3
>>
>> It seems to act something like an implicit `do` in that it returns the 
>> last value but, in fact, not quite as you seem to need to have more than 
>> two items:
>>
>> user=> ('do)
>>
>> ArityException Wrong number of args (0) passed to: Symbol 
>>  clojure.lang.AFn.throwArity (AFn.java:429)
>>
>>
>> user=> ('do (+ 1 2 3))
>> nil
>>
>>
>> user=> ('do 'this (+ 1 2 3))
>> 6
>>
>> But more than 3 is not accepted:
>>
>> user=> ('do 'this 'please 3)
>>
>>
>> ArityException Wrong number of args (3) passed to: Symbol 
>>  clojure.lang.AFn.throwArity (AFn.java:429)
>>
>> user=> ('do 'this 'please 'now 'ok?)
>>
>>
>> ArityException Wrong number of args (4) passed to: Symbol 
>>  clojure.lang.AFn.throwArity (AFn.java:429)
>>
>>
>> A quick search didn't reveal any bug reports or previous discussions on 
>> this but I may have missed something (feel free to point me in the right 
>> direction).
>>
>> Is it just a "quirk" or is it useful in some way? Intended behavior or 
>> bug?
>>
>> Cheers,
>>
>> Michael O'Keefe
>>
>> -- 
>> 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: Unexpected behavior for symbols or keywords used in the operator position

[Carlo Zancanaro]

Symbols and keywords act as functions which look themselves up in their
argument. Essentially:

  ('sym map) => (get map 'sym)
 ('sym map not-found) => (get map 'sym not-found)

  (:key map) => (get map :key)
 (:key map not-found) => (get map :key not-found)

It's often pretty useful, in my experience. It looks cleaner, and it means
that you can just use :keyword instead of #(get % :keyword) in cases where
you provide a function as an argument (for example: (map :type objects)).

On 16 September 2015 at 14:20, Michael O'Keefe 
wrote:

> Hello All:
>
> Noticed the following works in Clojure 1.6 and 1.7 (didn't test prior to
> that):
>
> user=> ('+ 'a 'b)
> b
>
> Also "works" for any set of symbols:
>
> user=> ('abra 'ka 'dabra)
> dabra
>
> My expectation was that using symbols or keywords in the function/operator
> position would throw an exception similar to this:
>
> user=> (3 4)
>
>
> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn  user
> /eval7668 (form-init2947310628177413729.clj:1)
>
>
> I noticed Keywords can also be used in the operator position:
>
> user=> (:abra :ka :dabra)
> :dabra
>
> And mixing and matching is OK:
>
> user=> (:a 'b 3)
> 3
>
> It seems to act something like an implicit `do` in that it returns the
> last value but, in fact, not quite as you seem to need to have more than
> two items:
>
> user=> ('do)
>
> ArityException Wrong number of args (0) passed to: Symbol
>  clojure.lang.AFn.throwArity (AFn.java:429)
>
>
> user=> ('do (+ 1 2 3))
> nil
>
>
> user=> ('do 'this (+ 1 2 3))
> 6
>
> But more than 3 is not accepted:
>
> user=> ('do 'this 'please 3)
>
>
> ArityException Wrong number of args (3) passed to: Symbol
>  clojure.lang.AFn.throwArity (AFn.java:429)
>
> user=> ('do 'this 'please 'now 'ok?)
>
>
> ArityException Wrong number of args (4) passed to: Symbol
>  clojure.lang.AFn.throwArity (AFn.java:429)
>
>
> A quick search didn't reveal any bug reports or previous discussions on
> this but I may have missed something (feel free to point me in the right
> direction).
>
> Is it just a "quirk" or is it useful in some way? Intended behavior or bug?
>
> Cheers,
>
> Michael O'Keefe
>
> --
> 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.

Unexpected behavior for symbols or keywords used in the operator position

[Michael O'Keefe]

Hello All:

Noticed the following works in Clojure 1.6 and 1.7 (didn't test prior to 
that):

user=> ('+ 'a 'b)
b

Also "works" for any set of symbols:

user=> ('abra 'ka 'dabra)
dabra

My expectation was that using symbols or keywords in the function/operator 
position would throw an exception similar to this:

user=> (3 4)


ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn  
user/eval7668 
(form-init2947310628177413729.clj:1)


I noticed Keywords can also be used in the operator position:

user=> (:abra :ka :dabra)
:dabra

And mixing and matching is OK:

user=> (:a 'b 3)
3

It seems to act something like an implicit `do` in that it returns the last 
value but, in fact, not quite as you seem to need to have more than two 
items:

user=> ('do)

ArityException Wrong number of args (0) passed to: Symbol 
 clojure.lang.AFn.throwArity (AFn.java:429)


user=> ('do (+ 1 2 3))
nil


user=> ('do 'this (+ 1 2 3))
6

But more than 3 is not accepted:

user=> ('do 'this 'please 3)


ArityException Wrong number of args (3) passed to: Symbol 
 clojure.lang.AFn.throwArity (AFn.java:429)

user=> ('do 'this 'please 'now 'ok?)


ArityException Wrong number of args (4) passed to: Symbol 
 clojure.lang.AFn.throwArity (AFn.java:429)


A quick search didn't reveal any bug reports or previous discussions on 
this but I may have missed something (feel free to point me in the right 
direction).

Is it just a "quirk" or is it useful in some way? Intended behavior or bug?

Cheers,

Michael O'Keefe

-- 
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/Pedestal vs Go

[Michael Gardner]

On Sep 15, 2015, at 20:45, Mikera  wrote:
> 
> 7. The open source library ecosystem on the JVM is awesome. There's nothing 
> like it for any other language.

I like your other points, but in my experience this one is (arguably) no longer 
true. I've often found the JVM library ecosystem to be lacking in comparison to 
Python's, especially for newer problem domains. I'd attribute this to Java no 
longer being a "hip" language, which counts for a lot in OSS development!

-- 
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/Pedestal vs Go

[Mikera]

Go is fine for system-level programming, but I personally wouldn't use it 
as a web application programming language. Ten reasons to consider.:

1. There isn't really much speed difference on micro-benchmarks between JVM 
code and Go. See e.g.: http://benchmarksgame.alioth.debian.org/u64q/go.html

2. In many real-world cases JVM code will outperform Go, see e.g. 
http://zhen.org/blog/go-vs-java-decoding-billions-of-integers-per-second/

3. The JVM GC is superior to the GC in Go. This makes a big difference for 
complex applications with a lot of live objects on the heap, especially 
when dealing with stuff like immutable persistent data structures (and you 
want to use those, right?). Overall, I'd expect Clojure to easily 
outperform Go for these types of applications. 

4. The JVM startup time / memory overhead is irrelevant for long running 
server applications. If you are restarting the JVM regularly, you are 
definitely doing something wrong. The JVM is well tuned for long-running 
server side web applications in general, rather than the lightweight 
processes / scripts that are more suited to Go.

5. Functional programming is natural in Clojure and is IMHO the future for 
building modern applications

6. If you like the CSP stuff (goroutines, channels etc.), Clojure has the 
excellent core.async, which basically lets you do all the nice CSP type 
things in Clojure you can do in Go. However that isn't forced on you: 
Clojure supports a lot of other paradigms for concurrent programming. 
Choose what works best for you.

7. The open source library ecosystem on the JVM is awesome. There's nothing 
like it for any other language. Even if nobody has written a Clojure 
library that wraps up the functionality you need yet, using Java libraries 
from Clojure is very painless (often easier than using Java libraries from 
Java!)

8. Virtually all the key big data stuff depends on the JVM. Spark, Hadoop 
ecosystem etc. Being on the JVM is a valuable strategic choice if you are 
into data processing. / analytics.

9. Clojure has an compelling full stack development story with 
ClojureScript on the browser and Clojure on the server. It's pretty useful 
to be able to share code between the server and the client.

10. Once you've experienced interactive REPL driven web application 
development with stuff like Figwheel, you probably won't want to go back to 
anything else

On Monday, 14 September 2015 03:44:48 UTC+8, Alan Thompson wrote:
>
> Hi,
>
> I'm about to start a new web project and they are thinking about using Go 
> (golang) instead of a JVM (preferably Clojure) based approach.  The idea is 
> "BARE METAL SPEED!!!", but I really think the network and DB will be the 
> bottlenecks, not Clojure vs Go.
>
> Is anybody out there aware of any speed comparisons using Clojure/Pedestal 
> and/or Go?  I'm thinking basic measurements like connections/sec, latency, 
> simultaneous users, etc.
>
> Thanks,
> Alan
>

-- 
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/Pedestal vs Go

[Christopher Small]

I also am no Go expert. All I'll add is that I overheard that the lead 
author rejected a proposal to add `map` to the language, stating that it is 
"too niche". Doesn't bode well for FP in Go...

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

Libraries for dealing with DNS

[Kyle Sexton]

Does anyone have a recommendation or know of a good library to interact with 
DNS?  I've found com.brweber2/clj-dns, but it is dated and I get 
NullPointerExceptions doing basic lookups.

-- 
Kyle Sexton

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

Write Clojure & tackle tough problems for a promising start up

[Drew F]

My advanced apologies if posting this job to the group is inappropriate. I 
preemptively searched this topic and most people seemed to say it's OK. 

Curbside is enabling a new way to shop, built for the era of instant mobile 
commerce. The Curbside App allows you to find, buy and seamlessly pick up 
products from nearby local stores. The Curbside app searches realtime local 
inventory across retailers and uses location-based technologies to alert 
stores when a customer is arriving for a pickup. Curbside helps consumers 
quickly get what they need and helps retailers better serve their 
increasingly mobile centric customers. The Curbside Merchant Console 
enables alerts to staff as customers arrive to pick up orders and also 
manages online order workflow.

*Job Description*

Responsible for designing and developing large scale distributed server 
applications, software API, persistent data store and client/server 
communication architecture. Candidates must be familiar with distributed 
computing theories and have experience building distributed systems and 
client/server applications.


*Qualifications*

   - BS in Computer Science or related technical field or equivalent 
   practical experience
   - Excellent coding skills in Clojure or other functional programming 
   language (or Jave/C++ and a desire to learn Clojure)
   - We're interested in hiring great engineers at all experience levels
   - Must be able to communicate effectively and solve problems efficiently 
   in a dynamic team environment
   - Engineering and applied research experience in the areas of 
   information retrieval, data mining, machine learning and artificial 
   intelligence are highly desirable

*Additional Information*

Curbside’s investors include Sutter Hill Ventures, Index Ventures, Jerry 
Yang’s AME Cloud Ventures, Eric Schmidt’s Innovation Endeavors, O’Reilly 
AlphaTech Ventures, Gil Elbaz & David Waxman’s TenOneTen and Chicago 
Ventures.

Read more: press.shopcurbside.com. Email d...@shopcurbside.com for more 
info or to apply. All positions based in Palo Alto. 

-- 
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: Using metadata to specify how calls to a macro should be indented

[Colin Fleming]

This is an interesting proposal, and I like it in general. Everything in
Cursive is based on extensions identified by the head form, like this:

(style/register-formatting :clojure.core/def :only-indent)
(style/register-formatting :clojure.core/defn- :only-indent)
(style/register-formatting resolve/fn-forms :only-indent)
(style/register-formatting resolve/local-binding-forms 1)

I think it's important that the declaration of the formatting be separated
from the declaration of the macro itself. This allows forms which the
editor developer doesn't control to be annotated, e.g. core. Perhaps
library owners could produce an EDN doc containing these specs? Or perhaps
we could obey annotations in the functions themselves, but I think that
some way to additionally annotate external things is essential.

I also think that Mr Dynamics is correct, we should not go down the path of
special casing anything, even defn - this is a hard rule that I have in
Cursive that I only break very occasionally :-). The spec should support
everything we need to do. It will be difficult, though - in Cursive I
actually support programmatically organising the blocks that make up the
source, and I'm not sure how to handle many cases without this. I like the
hierarchical nature of this spec, though, I suspect that many of the cases
I currently solve programmatically could be solved using something like
this.

There are also many more aspects to formatting that this does not address
that I think we should think about - line indentation is only one part of
it. What about breaking lines when they're too long? Aligning subforms like
let-binding values? Do we want to do anything about those? Cursive can
handle all of that but doesn't expose the knobs right now. clj-fmt does, I
believe - I think it can take a single line of pr-str output and produce
nicely formatted code.

There are also lots of edge cases that need to be thought through.
Multi-arity function declarations for letfn, proxy etc come to mind.
extend-type also supports multiple arity declarations. condp is another
example of a form with variable numbers of elements per "block" (the :>>
keyword). for-blocks have internal let blocks, etc etc.

It's hard to tell how far to go with this. One thing that I'm planning in
Cursive that I'm not doing currently is also to identify forms which are
part of a do-body-like-thing. This is very useful for refactoring. This
might not have a place in a spec that is purely for indentation, but
definitely would in a more general form structure spec. I also think it
would be very useful to express implicit grouping of elements, e.g. let
binding keys/values, cond forms etc.


On 16 September 2015 at 07:08, Josh Tilles 
wrote:

>
>
> On Sunday, September 13, 2015 at 8:25:42 AM UTC-4, Artur Malabarba wrote:
>>
>>
>> On 13 Sep 2015 12:33 pm, "Matching Socks"  wrote:
>> >
>> > Unless clojure.core itself will carry these annotations, could the
>> keyword be namespaced?
>>
>> Or do you mean it should be ::indent? (i.e., carry the namespace of the
>> var that they're applied on)
>>
> I suspect that “Matching Socks” meant that there should be a standard
> namespace, similar to how the recent Socket Server REPL design
> 
>  uses
> a “repl” namespace for its magic keywords.
> It seems natural to me to pick a namespace like “editors” or “editing”,
> but alternatives like :display/indentation or :visual/structure also look
> good.
>
> --
> 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.

Oxford (UK) Clojure Group

[Kévin Etienne]

Hi,

I've seen a previous thread 
https://groups.google.com/forum/#!topic/clojure/dRPF8bEpjBE
where a Clojure group in Oxford was mentioned. I don't know what happened 
to Oxjure but
I'm interested in running a group and meeting people around Clojure and 
more extensively
LISP. I've been to a Clojure in London and really enjoyed a few years ago.

Let me know if you're around and if want to meet. At the moment I'm trying 
to see if there's
enough traction and see what we can do.

Thanks,
Kevin 

-- 
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: Using metadata to specify how calls to a macro should be indented

[Josh Tilles]

On Sunday, September 13, 2015 at 8:25:42 AM UTC-4, Artur Malabarba wrote:
>
>
> On 13 Sep 2015 12:33 pm, "Matching Socks"  > wrote:
> >
> > Unless clojure.core itself will carry these annotations, could the 
> keyword be namespaced?
>
> Or do you mean it should be ::indent? (i.e., carry the namespace of the 
> var that they're applied on)
>
I suspect that “Matching Socks” meant that there should be a standard 
namespace, similar to how the recent Socket Server REPL design 

 uses 
a “repl” namespace for its magic keywords.
It seems natural to me to pick a namespace like “editors” or “editing”, but 
alternatives like :display/indentation or :visual/structure also look good.

-- 
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: :refer-clojure broken?

[Gregg Reynolds]

On Sun, Sep 13, 2015 at 9:23 PM, Alex Miller  wrote:

> Can you be more specific about how you are loading the namespace?
>

Sorry for not getting back to you sooner, I did a little more experimenting
to no avail.  You can see it in action at migae datastore
 .  Clone it, run

$ lein with-profile compile compile
$ lein repl

and you should see the WARNINGS.  Note that my :dev profile is configured
to add "dev" to the source path, so dev/user.clj is picked up; it requires
the offending library, migae.datastore.

Thanks,

Gregg


>
> I can't reproduce this with a pure Clojure repl or with a Leiningen repl
> on Clojure 1.7 or 1.8.
>
> On Sunday, September 13, 2015 at 6:23:37 PM UTC-5, Gregg Reynolds wrote:
>>
>> PS.
>>
>> REPL-y 0.3.5, nREPL 0.2.10
>> Clojure 1.7.0
>> Java HotSpot(TM) 64-Bit Server VM 1.8.0_45-b14
>>
>>
>> On Sun, Sep 13, 2015 at 6:21 PM, Gregg Reynolds 
>> wrote:
>>
>>> Just to be perverse, in my library I'm defining `print`.  So I get the
>>> usual warning:
>>>
>>> WARNING: print already refers to: #'clojure.core/print in namespace:
>>> migae.datastore, being replaced by: #'migae.datastore/print
>>>
>>> So I add a clause to my (ns...) form:
>>>
>>>   (:refer-clojure :exclude [print])
>>>
>>> This has no effect - I still get the warning.  What's wrong with this
>>> picture?
>>>
>>> Thanks,
>>>
>>> Gregg
>>>
>>
>> --
> 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/Pedestal vs Go

[kovas boguta]

At least in one area -- data infrastructure -- the JVM has no
competitors for off-the-shelf solutions.

Hadoop, Spark, Storm, Kafka, Cassandra, HBase, etc etc are all JVM-based.

In the alpha-nerd set, one can easily argue that the relevance of Go
is fading and its being replaced by Rust.

I'm not too worried.


On Sun, Sep 13, 2015 at 4:14 PM, Max Countryman  wrote:
> Hi,
>
> I'd love to see some discussion about this as well: I've struggled to
> justify the JVM in a production environment that's dominated by Go. My
> experience with my team has been that they are very unwilling to use the JVM
> and will go to great lengths to avoid it. The argument seems to be that Go
> produces light, extremely fast binaries, and has phenomenal networking
> libraries built into the standard lib, making it ideal for writing
> server-side components that may handle large amounts of data and need to
> scale horizontally. Despite my attempts to have members of my team checkout
> Clojure the final decision has always been to use Go instead. I'm personally
> a bit concerned that Go has started to become the replacement for Java and
> that the relevance of the JVM may be declining. It would be great to see
> some counterpoints to Go vis-à-vis Clojure and the JVM.
>
>
> Max
>
>
>
> Sent from my iPhone
> On Sep 13, 2015, at 12:44, Alan Thompson  wrote:
>
> Hi,
>
> I'm about to start a new web project and they are thinking about using Go
> (golang) instead of a JVM (preferably Clojure) based approach.  The idea is
> "BARE METAL SPEED!!!", but I really think the network and DB will be the
> bottlenecks, not Clojure vs Go.
>
> Is anybody out there aware of any speed comparisons using Clojure/Pedestal
> and/or Go?  I'm thinking basic measurements like connections/sec, latency,
> simultaneous users, etc.
>
> Thanks,
> Alan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Clojure/Pedestal vs Go

[Max Countryman]

Alan,

Absolutely no need to apologize! :) I would hardly consider myself an expert 
either, I’m basing my understanding on the experiences I’ve had at my day job 
and the large body of developing articles and blogposts related to the language 
that seem to pop up at a near-constant rate on your favorite programming news 
aggregator.

If people are doing FP with Go somewhere, that’s awesome and I would love to 
see it. My suspicion is it’s difficult and generally not what you “want” to be 
doing with the language. Go’s popularity is a big disappoint for me personally, 
but again your experience may differ.


Max

> On Sep 15, 2015, at 10:18, Alan Moore  wrote:
> 
> Max,
> 
> You obviously know way more than I do about Go... I stand corrected, thanks. 
> I did know that it doesn't support TCO so it doesn't surprise me that other 
> language features went the wrong way too.
> 
> I did not mean to misinform anyone, my apologies for speaking beyond my core 
> competency (Go is not one of them.) I was trying to give our friend some 
> hope... Those of us with day jobs in C/C++ (and Go) need some of that to keep 
> us sane. :-(
> 
> Alan
> 
> -- 
> 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/Pedestal vs Go

[Alan Moore]

Max,

You obviously know way more than I do about Go... I stand corrected, thanks. I 
did know that it doesn't support TCO so it doesn't surprise me that other 
language features went the wrong way too.

I did not mean to misinform anyone, my apologies for speaking beyond my core 
competency (Go is not one of them.) I was trying to give our friend some 
hope... Those of us with day jobs in C/C++ (and Go) need some of that to keep 
us sane. :-(

Alan

-- 
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: lazy-seq and threads

[Alex Miller]

I had the same question - are you running independent thread-isolated 
lazy-seqs on different sources in different threads? Or are you creating 
one lazy-seq and then *using* it to do different things in multiple threads?

In the first case, the synchronization in lazy-seq only happens in a 
thread-isolated context (each instance is independent) and the JVM can 
optimize this in lots of ways. In the later, there may be other better 
options in this case.

I was a bit confused by the CPU usage you reported - it was unclear to me 
what workload you were running in Clojure and Java cases. Presumably on the 
same workload, you'd want to have higher CPU usage indicating you are 
keeping more cores busy (assuming they're not busy doing extra stuff). If 
your problem was locking contention, I would expect to see much lower CPU 
usage though. You might try just taking a few thread dumps while your 
program is running to see if it is really something else in your logic 
that's slow (rather than contention). Tools like YourKit can help identify 
locking contention hotspots too.


On Tuesday, September 15, 2015 at 7:50:25 AM UTC-5, Alan Thompson wrote:
>
> Do you have a corresponding example of the parallel code?  I'm not sure 
> which part(s) are being delegated to other threads.
>
> Often it is just the I/O cost of reading the file that is the dominant 
> cost, so parallelism doesn't buy you much.
>
> Alan 
>
> On Mon, Sep 14, 2015 at 9:10 PM, Andy L > 
> wrote:
>
>> Hi,
>>
>> I would like ask for some advise with regards to kind of unusual 
>> interaction between lazy-seq and threads. I have a code opening some big 
>> compressed text files and processing them line by line. The code reduced to 
>> a viable example would look like that:
>>
>>   (with-open [i (-> "mybigfile.gz" clojure.java.io/input-stream 
>> java.util.zip.GZIPInputStream. clojure.java.io/reader)] (count (line-seq 
>> i)))
>>
>> where for the sake of visualization, the processing is replaced by a 
>> simple counting.
>>
>> In a single thread situation, everything works very well, with 
>> performance numbers close to Java (or even equal with 
>> "-XX:MaxInlineLevel=16"). However, once I run it in threads, either native 
>> Java Thread or future, instead of nice effect parallel processing, things 
>> are even slower from as they would be run sequentially. Interestingly 
>> enough, JVM pegs at 500-600% of CPU (I have 8 cores). I was not sure what 
>> was the reason, and in order to rule out some basics assumptions, I created 
>> a Java equivalent. It runs at 200% CPU and scales above 4 cores - which is 
>> exactly what I want, and matches gzip behavior. (I can run almost 6 "gunzip 
>> -c mybigfile.gz | wc -l" which all taking 100% CPU each).
>>
>> Next logical step was to look into Clojure sources. What I am finding 
>> out, is that lazy-seq is synchronized: 
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java
>>  
>> . From what I understand, JIT optimizes the single thread case and removes 
>> "synchronized" guards, however as soon as other threads come into play I am 
>> forced to pay price for synchronization, which causes the performance 
>> degradation*.
>>
>> Interestingly enough, JIT optimizes a version without GZIPInputStream and 
>> am getting same results as with Java with multiple threads. I have to run 
>> it with "-XX:MaxInlineLevel=16" though. With a default 
>> "-XX:MaxInlineLevel=9", JIT does not kick in and performance is not there. 
>> There is probably another switch in JVM which would help hinting JIT 
>> better, however I am not convinces that this is a right direction.
>>
>> I really like semantics of line-seq, however without that "synchronized" 
>> part, as in my context there is no way that two threads touch same seq.
>>
>> I would like ask for some advise, what would be my options here. The last 
>> resort is to write handling code in Java, but I really want to avoid this.
>>
>> Best,
>> Andy
>>
>> *My analysis might be wrong of course. 
>>
>>
>>
>>
>>
>>
>> -- 
>> 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

Re: [ANN] Clojure 1.8.0-alpha5

[Alex Miller]

Glad to hear it!

On Tue, Sep 15, 2015 at 10:19 AM, Tom Marble  wrote:

> On Friday, September 11, 2015 at 8:41:34 AM UTC-5, Alex Miller wrote:
>>
>> Clojure 1.8.0-alpha5 is now available.
>>
>
>  I am pleased to report that this version of Clojure builds fine with the
> early access version of JDK 9 (w/jigsaw):
>
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004480.html
> https://jdk9.java.net/jigsaw/
>
> tmarble@ficelle 141 :) mvn -version
> Apache Maven 3.3.3
> Maven home: /usr/share/maven
> Java version: 1.9.0-ea, vendor: Oracle Corporation
> Java home: /home/tmarble/src/oracle/jdk1.9.0
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.1.0-2-amd64", arch: "amd64", family: "unix"
> tmarble@ficelle 142 :) time mvn package > build-14.log 2>&1 &
> [1] 7124
> tmarble@ficelle 143 :) tail -7 build-14.log
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 01:49 min
> [INFO] Finished at: 2015-09-15T10:09:43-05:00
> [INFO] Final Memory: 17M/128M
> [INFO]
> 
> tmarble@ficelle 144 :)
>
> Regards,
>
> --Tom
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/xZ2YpiKg2FU/unsubscribe.
> To unsubscribe from this group and all its topics, 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: [ANN] Clojure 1.8.0-alpha5

[Tom Marble]

On Friday, September 11, 2015 at 8:41:34 AM UTC-5, Alex Miller wrote:
>
> Clojure 1.8.0-alpha5 is now available.
>
 
 I am pleased to report that this version of Clojure builds fine with the 
early access version of JDK 9 (w/jigsaw):
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004480.html
https://jdk9.java.net/jigsaw/

tmarble@ficelle 141 :) mvn -version
Apache Maven 3.3.3
Maven home: /usr/share/maven
Java version: 1.9.0-ea, vendor: Oracle Corporation
Java home: /home/tmarble/src/oracle/jdk1.9.0
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.1.0-2-amd64", arch: "amd64", family: "unix"
tmarble@ficelle 142 :) time mvn package > build-14.log 2>&1 &
[1] 7124
tmarble@ficelle 143 :) tail -7 build-14.log
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 01:49 min
[INFO] Finished at: 2015-09-15T10:09:43-05:00
[INFO] Final Memory: 17M/128M
[INFO] 

tmarble@ficelle 144 :) 

Regards,

--Tom

-- 
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: Martin Thompson: "Designing for Performance" video

[Alan Thompson]

The keynote is quite good, too:
https://youtu.be/oxjT7veKi9c?list=PLEx5khR4g7PKFs3Y-gWd8TX4Y_5yTyUTP

"Shared Mutable State:  The most feared words in computing"   -   quite a
bit of overlap with the ideals of Clojure.

Alan

On Tue, Sep 15, 2015 at 5:43 AM, Alan Thompson  wrote:

> If you haven't seen any of Martin's talks before, you should give this one
> a try.  It is one of his best and reminds me a lot of Rich's best talks.
>
> This one is motivated by getting higher performance from code, but most of
> it emphasizes good design fundamentals as the basis for everything else.
>
> https://youtu.be/fDGWWpHlzvw
>
> Enjoy!
> Alan
>

-- 
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/Pedestal vs Go

[Max Countryman]

Hi Alan,

>From my experience this is not true: Go does not provide generics and actively 
>resists what most of us would consider good functional programming--Go is very 
>opinionated and doesn't allow much deviation from these opinions, by design.  
>So implementing practical immutable data structures would be difficult and 
>likely of limited utility in Go. That said, you should still try yourself if 
>given the opportunity. 


Max

> On Sep 14, 2015, at 21:44, Alan Moore  wrote:
> 
> One more thing: if you are truly stuck with Go you can still adopt functional 
> patterns, style and data structures to good effect. Just because the opening 
> paren is on the wrong side of the function name doesn't mean you can't find 
> (or write?) an immutable data structure library for Go and promote functional 
> programming ideas within your team.
> 
> Here is are some simple examples from C++ (from one of the authors of the D 
> language):
> 
> http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c
> http://bartoszmilewski.com/2013/11/25/functional-data-structures-in-c-trees
> https://github.com/BartoszMilewski/Okasaki
> 
> I'm pretty sure you could port these or some other implementation to Go 
> fairly easily - YMMV.
> 
> Alan
> 
>> On Mon, Sep 14, 2015 at 7:18 PM, Alan Moore  
>> wrote:
>> I'll second Paul's comments and raise you two:
>> 
>> 1) Depending on your app's use cases, speed going forward will be gained 
>> primarily from parallelism. I think Clojure has a better story there than Go 
>> but that is just my opinion.
>> 
>> 2) It is very hard to fight against cultural bias against the JVM. I work in 
>> embedded systems where anything but C/C++ (or Lua, Python) is taboo. Your 
>> best bet is to "Go" with their momentum and when they run into a roadblock 
>> in Go (probably something related to mutability/locks in the face of heavy 
>> load), give a shot at the same problem with Clojure.
>> 
>> Obviously this has to be done in a non-intrusive way (on the other end of a 
>> socket) but will give you a chance to prove Clojure and the JVM can handle 
>> the job. Unfortunately your company won't gain the other benefits of Clojure 
>> beyond just performance (e.g. clarity, simplicity, etc.) because the rest of 
>> the code base will be in Go but... clearly that ship has already sailed.
>> 
>> Good luck! Let us know how things turn out.
>> 
>> Alan
>> 
>> --
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/p_cZoGCpvbE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> -- 
> "Whatever you can do, or dream you can do, begin it. Boldness has genius, 
> power, and magic in it. Begin it now." - Goethe
> -- 
> 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: lazy-seq and threads

[Alan Thompson]

Do you have a corresponding example of the parallel code?  I'm not sure
which part(s) are being delegated to other threads.

Often it is just the I/O cost of reading the file that is the dominant
cost, so parallelism doesn't buy you much.

Alan

On Mon, Sep 14, 2015 at 9:10 PM, Andy L  wrote:

> Hi,
>
> I would like ask for some advise with regards to kind of unusual
> interaction between lazy-seq and threads. I have a code opening some big
> compressed text files and processing them line by line. The code reduced to
> a viable example would look like that:
>
>   (with-open [i (-> "mybigfile.gz" clojure.java.io/input-stream
> java.util.zip.GZIPInputStream. clojure.java.io/reader)] (count (line-seq
> i)))
>
> where for the sake of visualization, the processing is replaced by a
> simple counting.
>
> In a single thread situation, everything works very well, with performance
> numbers close to Java (or even equal with "-XX:MaxInlineLevel=16").
> However, once I run it in threads, either native Java Thread or future,
> instead of nice effect parallel processing, things are even slower from as
> they would be run sequentially. Interestingly enough, JVM pegs at 500-600%
> of CPU (I have 8 cores). I was not sure what was the reason, and in order
> to rule out some basics assumptions, I created a Java equivalent. It runs
> at 200% CPU and scales above 4 cores - which is exactly what I want, and
> matches gzip behavior. (I can run almost 6 "gunzip -c mybigfile.gz | wc -l"
> which all taking 100% CPU each).
>
> Next logical step was to look into Clojure sources. What I am finding out,
> is that lazy-seq is synchronized:
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java
> . From what I understand, JIT optimizes the single thread case and removes
> "synchronized" guards, however as soon as other threads come into play I am
> forced to pay price for synchronization, which causes the performance
> degradation*.
>
> Interestingly enough, JIT optimizes a version without GZIPInputStream and
> am getting same results as with Java with multiple threads. I have to run
> it with "-XX:MaxInlineLevel=16" though. With a default
> "-XX:MaxInlineLevel=9", JIT does not kick in and performance is not there.
> There is probably another switch in JVM which would help hinting JIT
> better, however I am not convinces that this is a right direction.
>
> I really like semantics of line-seq, however without that "synchronized"
> part, as in my context there is no way that two threads touch same seq.
>
> I would like ask for some advise, what would be my options here. The last
> resort is to write handling code in Java, but I really want to avoid this.
>
> Best,
> Andy
>
> *My analysis might be wrong of course.
>
>
>
>
>
>
> --
> 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.

Martin Thompson: "Designing for Performance" video

[Alan Thompson]

If you haven't seen any of Martin's talks before, you should give this one
a try.  It is one of his best and reminds me a lot of Rich's best talks.

This one is motivated by getting higher performance from code, but most of
it emphasizes good design fundamentals as the basis for everything else.

https://youtu.be/fDGWWpHlzvw

Enjoy!
Alan

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