Re: ANN: Parallel let macro!

[Henrik Eneroth]

Very nice! Kudos.

-- 
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 libraries without Lein

[Sean Corfield]

In addition to tools.deps, which reads dependencies etc from a deps.edn file, 
you might want to look at Boot http://boot-clj.com which allows you to use 
libraries via the command line without needing a project or source files etc:

boot -d clj-http repl

This will start a Clojure REPL (anywhere) with the clj-http library loaded. 
Boot also has a call task that accepts Clojure code via the command-line:

boot -d clj-http call -p -e “(require ‘[clj-http.client :as http])” -e 
‘(http/get “http://google.com”)’

The -p option tells call to print the result of each expression.

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

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


From: clojure@googlegroups.com  on behalf of C K 
Kashyap 
Sent: Tuesday, November 28, 2017 2:49:53 PM
To: clojure@googlegroups.com
Subject: Re: Using libraries without Lein

Thanks Alex ... just what I was looking for - putting the jars in classpath 
that is!

I'll try out the new tool a little later though.

Regards,
Kashyap

On Tue, Nov 28, 2017 at 2:27 PM, Alex Miller 
mailto:a...@puredanger.com>> wrote:
Sure. You need a jar for Clojure and a jar for clj-http and then just run Java 
with those in a classpath:

java -cp clojure.jar:clj-http.jar my-program

There is a lighter weight tool that we've added in Clojure 1.9 (also works with 
1.8) that can help in assembling classpaths and serving as a runner. All it's 
really doing is taking a statement of deps and building the classpath to make 
that call. If you're interested in that, this will be useful:

https://clojure.org/guides/deps_and_cli



On Tuesday, November 28, 2017 at 4:20:43 PM UTC-6, Kashyap CK wrote:
Hi,
I am trying to use clj-http in my clojure program. I am trying to do the whole 
thing in a "light-weight" manner - without creating a project and all or using 
lein. Is that possible? or do I need to use Lein?
Regards,
Kashyap

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

-- 
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] Dynadoc, dynamic docs for Clojure(Script)

[Zach Oakes]

Right on! I don't remember which of my insights did the humdinging but I'm 
glad you liked it.

On Tuesday, November 28, 2017 at 7:28:04 PM UTC-5, Matching Socks wrote:
>
> Hey, gang!  There is something important here.  Gold!, amidst the nuts and 
> bolts.  A humdinger of first-rate philosophical insight is tucked, 
> inconspicuously, way toward the end of the linked demo video.  In a word, 
> it is a bat-it-out-of-the-park answer to the docstring-improvement 
> chatter.  Tastes great *and *less filling!
>
> So, endure the demo.  The deadpan showmanship does not disappoint.  
> Materially, there is fun stuff to think about, springing from the first 
> four-fifths of the video.  Imagine what clojure.org could do along these 
> lines, or what clojuredocs might do.  But don't get sidetracked before you 
> reach the big idea.  The fifth fifth.
>

-- 
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] Dynadoc, dynamic docs for Clojure(Script)

[Matching Socks]

Hey, gang!  There is something important here.  Gold!, amidst the nuts and 
bolts.  A humdinger of first-rate philosophical insight is tucked, 
inconspicuously, way toward the end of the linked demo video.  In a word, 
it is a bat-it-out-of-the-park answer to the docstring-improvement 
chatter.  Tastes great *and *less filling!

So, endure the demo.  The deadpan showmanship does not disappoint.  
Materially, there is fun stuff to think about, springing from the first 
four-fifths of the video.  Imagine what clojure.org could do along these 
lines, or what clojuredocs might do.  But don't get sidetracked before you 
reach the big idea.  The fifth fifth.

-- 
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 libraries without Lein

[C K Kashyap]

Thanks Alex ... just what I was looking for - putting the jars in classpath
that is!

I'll try out the new tool a little later though.

Regards,
Kashyap

On Tue, Nov 28, 2017 at 2:27 PM, Alex Miller  wrote:

> Sure. You need a jar for Clojure and a jar for clj-http and then just run
> Java with those in a classpath:
>
> java -cp clojure.jar:clj-http.jar my-program
>
> There is a lighter weight tool that we've added in Clojure 1.9 (also works
> with 1.8) that can help in assembling classpaths and serving as a runner.
> All it's really doing is taking a statement of deps and building the
> classpath to make that call. If you're interested in that, this will be
> useful:
>
> https://clojure.org/guides/deps_and_cli
>
>
>
> On Tuesday, November 28, 2017 at 4:20:43 PM UTC-6, Kashyap CK wrote:
>>
>> Hi,
>> I am trying to use clj-http in my clojure program. I am trying to do the
>> whole thing in a "light-weight" manner - without creating a project and all
>> or using lein. Is that possible? or do I need to use Lein?
>> Regards,
>> Kashyap
>>
> --
> 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/JaIX3aOZmvQ/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: clojure.edn versus clojure.tools.reader.edn

[Andy Fingerhut]

I am pretty sure that clojure.tools.reader.edn is a version of the Clojure
reader specifically for the edn subset, hence the name of the namespace.

That said, no need to add a separate dependency on clojure.tools.reader if
you would prefer to avoid it, and you are reading EDN inside Clojure on the
JVM.

Andy

On Tue, Nov 28, 2017 at 1:14 PM, Alex Miller  wrote:

> Presuming you're in Clojure, just use clojure.edn. clojure.edn is written
> in Java and targets the edn subset of Clojure's syntax. Presuming you're
> reading typical edn data, this is the best answer.
>
> clojure.tools.reader is a version of the Clojure reader (not the edn
> subset) written in Clojure (the biggest user of this is ClojureScript).
>
>
> On Tuesday, November 28, 2017 at 9:51:45 AM UTC-6, Aaron Cummings wrote:
>>
>> I have a case where I'm reading a Clojure data structure serialized to
>> edn, but I don't have complete trust in the soure.
>>
>> Clearly I want to avoid clojure.core/read-string.  The
>> cheatsheet at https://clojure.org/api/cheatsheet hints that
>> clojure.tools.reader.edn/read-string is a good choice, but I also see
>> clojure.edn/read-string.
>>
>> Are both of these edn readers considered equally safe on untrusted
>> input?  What tradeoffs are there for one versus the other?
>>
>> Thanks,
>> Aaron
>>
> --
> 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: Using libraries without Lein

[Alex Miller]

Sure. You need a jar for Clojure and a jar for clj-http and then just run 
Java with those in a classpath:

java -cp clojure.jar:clj-http.jar my-program

There is a lighter weight tool that we've added in Clojure 1.9 (also works 
with 1.8) that can help in assembling classpaths and serving as a runner. 
All it's really doing is taking a statement of deps and building the 
classpath to make that call. If you're interested in that, this will be 
useful:

https://clojure.org/guides/deps_and_cli



On Tuesday, November 28, 2017 at 4:20:43 PM UTC-6, Kashyap CK wrote:
>
> Hi,
> I am trying to use clj-http in my clojure program. I am trying to do the 
> whole thing in a "light-weight" manner - without creating a project and all 
> or using lein. Is that possible? or do I need to use Lein?
> Regards,
> Kashyap 
>

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

[Alex Miller]

On Tue, Nov 28, 2017 at 3:22 PM, Khalid Jebbari 
wrote:

> Specs in docs are nice, great addition.
>
> 2 things related to them :
> - what is `quotable` ? Couldn't find its docs in the page
>

All of the core specs are defined in an external library (so we can update
it more frequently than Clojure):
https://github.com/clojure/core.specs.alpha

In this case, quotable is a helper function (refer-clojure and import are
particularly weird in source/spec as they are designed to be used both
directly at the repl and inside the ns macro):
https://github.com/clojure/core.specs.alpha/blob/master/src/main/clojure/clojure/core/specs/alpha.clj#L222

We use the short form description in the docs (s/describe) rather than the
long-form fully-qualified version (s/form) for readability. This is a
tradeoff as it omits information but I think usually wins. It would be
better if we could easily link to the definition of the spec source, which
is possible to add.


> - I suppose `:closure.core.spec.alpha/exclude` refers to a spec, but
> again it's absent from the docs.


As this is defined in another project you won't see it here. FYI, you can
use `doc` to look at any spec by name at the repl:

user=>  (doc :clojure.core.specs.alpha/exclude)
-
:clojure.core.specs.alpha/exclude
Spec
  (coll-of simple-symbol?)

A quick search in clojure.core and spec.alpha repos didn't reveal it. Where
> are they defined ? It would be nice if they where included in docs and/or
> were clickable directly from docstrings.
>

Agreed and you would see it here (but not clickable) if it was defined in
this project. You can see an example of this in the java.jdbc docs:
http://clojure.github.io/java.jdbc/#:clojure.java.jdbc.spec/as-arrays?

It would be a nice enhancement to support an external http source for those
external specs in the doc generator.

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

Using libraries without Lein

[Kashyap CK]

Hi,
I am trying to use clj-http in my clojure program. I am trying to do the 
whole thing in a "light-weight" manner - without creating a project and all 
or using lein. Is that possible? or do I need to use Lein?
Regards,
Kashyap 

-- 
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.edn versus clojure.tools.reader.edn

[Alex Miller]

To a large degree Clojure and ClojureScript should be the same from a reader 
compatibility point of view.

-- 
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.edn versus clojure.tools.reader.edn

[Aaron Cummings]

Thanks Alex.  This makes sense.

It did occur to the the recommendation in the cheatsheet might be
aimed at ClojureScript compatibility.  Since I'm in JVM Clojure only
for this project I'll switch over to clojure.edn.

-Aaron

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

[Khalid Jebbari]

Specs in docs are nice, great addition.

2 things related to them :
- what is `quotable` ? Couldn't find its docs in the page
- I suppose `:closure.core.spec.alpha/exclude` refers to a spec, but again it's 
absent from the docs. A quick search in clojure.core and spec.alpha repos 
didn't reveal it. Where are they defined ? It would be nice if they where 
included in docs and/or were clickable directly from docstrings.

Thanks again for your hard work.

-- 
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.edn versus clojure.tools.reader.edn

[Alex Miller]

Presuming you're in Clojure, just use clojure.edn. clojure.edn is written 
in Java and targets the edn subset of Clojure's syntax. Presuming you're 
reading typical edn data, this is the best answer.

clojure.tools.reader is a version of the Clojure reader (not the edn 
subset) written in Clojure (the biggest user of this is ClojureScript). 

On Tuesday, November 28, 2017 at 9:51:45 AM UTC-6, Aaron Cummings wrote:
>
> I have a case where I'm reading a Clojure data structure serialized to 
> edn, but I don't have complete trust in the soure. 
>
> Clearly I want to avoid clojure.core/read-string.  The 
> cheatsheet at https://clojure.org/api/cheatsheet hints that 
> clojure.tools.reader.edn/read-string is a good choice, but I also see 
> clojure.edn/read-string. 
>
> Are both of these edn readers considered equally safe on untrusted 
> input?  What tradeoffs are there for one versus the other? 
>
> Thanks, 
> Aaron 
>

-- 
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.edn versus clojure.tools.reader.edn

[Aaron Cummings]

I have a case where I'm reading a Clojure data structure serialized to
edn, but I don't have complete trust in the soure.

Clearly I want to avoid clojure.core/read-string.  The
cheatsheet at https://clojure.org/api/cheatsheet hints that
clojure.tools.reader.edn/read-string is a good choice, but I also see
clojure.edn/read-string.

Are both of these edn readers considered equally safe on untrusted
input?  What tradeoffs are there for one versus the other?

Thanks,
Aaron

-- 
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.edn versus clojure.tools.reader.edn

[Aaron Cummings]

I have a case where I'm reading a Clojure data structure serialized to
edn, but I don't have complete trust in the soure.

Clearly I want to avoid clojure.core/read-string.  The
cheatsheet at https://clojure.org/api/cheatsheet hints that
clojure.tools.reader.edn/read-string is a good choice, but I also see
clojure.edn/read-string.

Are both of these edn readers considered equally safe on untrusted
input?  What tradeoffs are there for one versus the other?

Thanks,
Aaron

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

ANN: Parallel let macro!

[Eunmin Kim]

Hi, folks

This is small piece of code that is inspired by haxl, 
muse(https://github.com/kachayev/muse), 
urania(https://github.com/funcool/urania). Not a library.

(defn remote-req [result]
  (Thread/sleep 1000)
  result)

(defmacro plet [bindings & body]
  (let [bents (partition 2 (destructure bindings))
smap (into {} (map (fn [[b _]]
 [b `(deref ~b)])
   bents))
bindings (vec (mapcat (fn [[b v]]
[b `(future ~(postwalk-replace smap v))])
  bents))]
`(let ~bindings
   ~@(postwalk-replace smap body

(time
 (let [{:keys [a]} (remote-req {:a 1 :x 2})
   b (remote-req 1)
   c (+ a b)
   d (remote-req 1)
   e (remote-req 1)
   f (+ d e)]
   (+ c f)));; "Elapsed time: 4007.60237 msecs"

(time
 (plet [{:keys [a]} (remote-req {:a 1 :x 2})
b (remote-req 1)
c (+ a b)
d (remote-req 1)
e (remote-req 1)
f (+ d e)]
   (+ c f)));; "Elapsed time: 1003.733416 msecs"


https://github.com/eunmin/plet

Thanks!

- Eunmin

-- 
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 performace of transducers

[Renzo Borgatti]

> On 28 Nov 2017, at 02:54, Alex Miller  wrote:
> 
> I would say transducers are preferable when:
> 
> 1) you have reducible collections
> 2) you have a lot of pipelined transformations (transducers handle these in 
> one pass with no intermediate data)
> 3) the number of elements is "large" (this amplifies the memory and perf 
> savings from #2)
> 4) you put to produce a concrete output collection (seqs need an extra step 
> to pour the seq into a collection; transducers can create it directly)
> 5) you want a reusable transformation that can be used in multiple contexts 
> (reduction, sequence, core.async, etc)

I agree with the above Alex, although I think that is the kind of checklist I'd 
look at if performance optimizations is my primary goal. In any other case, I'd 
reach for transducers as the default. There are then several corner cases to 
understand, but that's true for normal sequential processing too.

Renzo

> 
> On Monday, November 27, 2017 at 8:33:50 PM UTC-6, Jiacai Liu wrote:
> > Also, most of the performance boost from transducers is due to less garbage 
> > being created, and some times the heap of the JVM is so large you'll never 
> > see much change from switching to transducers. 
> 
> Thanks for this tip. I seldom use transducers in my daily work, and I was 
> convinced transducers are a better choice in whatever situation after reading 
> some articles. But the test shows it isn't an easy choice, only when do 
> something reducible, will transducers make more sense.
> 
> On Tuesday, November 28, 2017 at 5:07:10 AM UTC+8, tbc++ wrote:
> >> Also, I think the transducer version should always be faster, no matter 
> >> the size of the source collection (no threshold).
> 
> It's a bit more complicated than that, mostly because transducer pipelines 
> require about 2 allocations per step during creation. Also, most of the 
> performance boost from transducers is due to less garbage being created, and 
> some times the heap of the JVM is so large you'll never see much change from 
> switching to transducers. 
> 
> Don't get me wrong, transducers are great and I often default to them over 
> seqs, but in micro-benchmarks like this there's too much in play to always 
> see a 100% performance boost. 
> 
> On Mon, Nov 27, 2017 at 12:55 PM, David Bürgin  wrote:
> Jiacai –
> 
> I saw you updated the gist. Just in case it passed you by: performance
> profits from the source collection being reducible. So pouring ‘dataset’
> into a vector beforehand should speed up the processing quite a bit.
> 
> Also, I think the transducer version should always be faster, no matter
> the size of the source collection (no threshold).
> 
> 
> --
> David
> 
> --
> 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.
> 
> 
> 
> -- 
> “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.

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

Re: Unexpected performace of transducers

[Renzo Borgatti]

> On 28 Nov 2017, at 02:33, Jiacai Liu  wrote:
> 
> > Also, most of the performance boost from transducers is due to less garbage 
> > being created, and some times the heap of the JVM is so large you'll never 
> > see much change from switching to transducers. 
> 
> Thanks for this tip. I seldom use transducers in my daily work, and I was 
> convinced transducers are a better choice in whatever situation after reading 
> some articles. But the test shows it isn't an easy choice, only when do 
> something reducible, will transducers make more sense.

If you're going for pure speed (such as, you have functional use cases to make 
the application faster) you shouldn't take them from granted. It's true that 
they might be faster option in many situations, but you should always benchmark 
it.

Missing the pure speed requirement, I'd use them as the default option, 
reducible or not. I prefer the flexibility they offer out of the box, the fact 
that I can stack up xducers as I need and then refactor/compose them out, when 
and if it makes sense. As a bonus, I like the fact that transducers let me turn 
off caching of lazy seqs (eduction) or fold a stateless chain in parallel.

IMHO, it's more flexible option to grant default use.

Renzo

> 
> On Tuesday, November 28, 2017 at 5:07:10 AM UTC+8, tbc++ wrote:
> >> Also, I think the transducer version should always be faster, no matter 
> >> the size of the source collection (no threshold).
> 
> It's a bit more complicated than that, mostly because transducer pipelines 
> require about 2 allocations per step during creation. Also, most of the 
> performance boost from transducers is due to less garbage being created, and 
> some times the heap of the JVM is so large you'll never see much change from 
> switching to transducers. 
> 
> Don't get me wrong, transducers are great and I often default to them over 
> seqs, but in micro-benchmarks like this there's too much in play to always 
> see a 100% performance boost. 
> 
> On Mon, Nov 27, 2017 at 12:55 PM, David Bürgin  wrote:
> Jiacai –
> 
> I saw you updated the gist. Just in case it passed you by: performance
> profits from the source collection being reducible. So pouring ‘dataset’
> into a vector beforehand should speed up the processing quite a bit.
> 
> Also, I think the transducer version should always be faster, no matter
> the size of the source collection (no threshold).
> 
> 
> --
> David
> 
> --
> 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.
> 
> 
> 
> -- 
> “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.

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