Re: Unexpected behaviour of transient map

[Mark Melling]

Thanks, that is useful advice.

I do think that the docstring for assoc! could be more explicit about the 
dangers of not using the return value. 

Given the value placed in experimenting in the REPL it's easy to see how 
one could be fooled into using assoc! incorrectly.


On Friday, 24 November 2017 16:52:15 UTC, Stuart Sierra wrote:
>
> The way I like to think of it, if it helps: Transients are still 
> *immutable*, but they are not *persistent*. Each new value *invalidates* 
> the previous value.
>
> –S
>
>
> On Friday, November 24, 2017 at 11:01:48 AM UTC-5, Alex Miller wrote:
>>
>> Transients must still be used in the same calling pattern as persistent 
>> data structures. That is, you must use the value returned from the ! call 
>> to make the next call. 
>>
>

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

[Zach Oakes]

I'm releasing a new project called Dynadoc which generates a single 
searchable doc website for everything in your project, including all your 
dependencies. It supports Clojure *and* ClojureScript. It also lets you 
create interactive code examples that can be edited from the browser. 
Currently the documentation on how to use it is scarce...hah. Anyway enjoy!

https://github.com/oakes/Dynadoc

-- 
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 behaviour of transient map

[Andy Fingerhut]

I know they aren't "official" Clojure documentation, but the examples and
comments at clojuredocs.org are often correct, and even sometimes
illuminating.

http://clojuredocs.org/clojure.core/assoc!

All of the clojuredocs.org pages for transient operations refer to that one
for a more full discussion of the correct way to use them.

Andy

On Mon, Nov 27, 2017 at 1:16 AM, Mark Melling 
wrote:

> Thanks, that is useful advice.
>
> I do think that the docstring for assoc! could be more explicit about the
> dangers of not using the return value.
>
> Given the value placed in experimenting in the REPL it's easy to see how
> one could be fooled into using assoc! incorrectly.
>
>
> On Friday, 24 November 2017 16:52:15 UTC, Stuart Sierra wrote:
>>
>> The way I like to think of it, if it helps: Transients are still
>> *immutable*, but they are not *persistent*. Each new value *invalidates*
>> the previous value.
>>
>> –S
>>
>>
>> On Friday, November 24, 2017 at 11:01:48 AM UTC-5, Alex Miller wrote:
>>>
>>> Transients must still be used in the same calling pattern as persistent
>>> data structures. That is, you must use the value returned from the ! call
>>> to make the next call.
>>>
>> --
> 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: Unexpected performace of transducers

[David Bürgin]

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

[Timothy Baldridge]

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



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

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

Re: Unexpected performace of transducers

[Alex Miller]

Chunked seqs are annoyingly fast. :)

On Monday, November 27, 2017 at 3:07:10 PM UTC-6, 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 clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

[ANN] Clojure 1.9.0-RC2

[Alex Miller]

Clojure 1.9.0-RC2 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-RC2
- Leiningen: [org.clojure/clojure "1.9.0-RC2"]

1.9.0-RC2 is largely the same as RC1 but has the following changes:

- There is a new Maven profile and Ant target in the build to build an 
executable Clojure jar with deps included (and test.check). This can be 
useful for doing dev on Clojure itself or for just cloning the repo and 
doing a quick build to get something runnable.
- The readme.txt has been updated to include information about how to 
create and run a local jar.
- We have stopped publishing the clojure-VERSION.zip file as part of the 
release.

We would appreciate anything you can do to try out this release. We do not 
plan to make any further changes prior to 1.9.0 unless regressions are 
found.

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

I should also mention that I've re-built the Clojure doc automation process 
and the Clojure docs have refreshed for the first time in a long while. 
Most importantly, the 1.9 docs are up to date and now include specs for 
things that have been spec'ed:

https://clojure.github.io/clojure/branch-master/index.html

Example macro with specs:
https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/refer-clojure

Additionally, I am in the process of overhauling the contrib project doc 
automation. In the meantime, I have at least done a manual update of the 
spec API docs:

https://clojure.github.io/spec.alpha


On Monday, November 27, 2017 at 3:47:25 PM UTC-6, Alex Miller wrote:
>
> Clojure 1.9.0-RC2 is now available.
>
> Try it via
>
> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-RC2
> - Leiningen: [org.clojure/clojure "1.9.0-RC2"]
>
> 1.9.0-RC2 is largely the same as RC1 but has the following changes:
>
> - There is a new Maven profile and Ant target in the build to build an 
> executable Clojure jar with deps included (and test.check). This can be 
> useful for doing dev on Clojure itself or for just cloning the repo and 
> doing a quick build to get something runnable.
> - The readme.txt has been updated to include information about how to 
> create and run a local jar.
> - We have stopped publishing the clojure-VERSION.zip file as part of the 
> release.
>
> We would appreciate anything you can do to try out this release. We do not 
> plan to make any further changes prior to 1.9.0 unless regressions are 
> found.
>
>

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

[Michael Glaesemann]

> On 2017-11-27, at 16:17, Alex Miller  wrote:
> 
> I should also mention that I've re-built the Clojure doc automation process 
> and the Clojure docs have refreshed for the first time in a long while.

Thanks, Alex!

Michael Glaesemann
grzm seespotcode net



-- 
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: Grateful Appreciation

[Karl Blomström]

Hi!

I would also like to express my appreciation for the language and the
community.
I use Clojure at work and it hits me daily how fun and interesting it is to
program in.
A big thank you to all developers and maintainers of the core language and
all open source libraries.
Thanks to all kind people helping out both here on the mailing list, on
reddit and in the slack channel.

Sincerely,

Kalle

2017-11-03 19:56 GMT+01:00 Alex Baranosky :

> Clojure is amazing, and at this point I couldn't imagine life without
> Clojure. (I guess I'd have to become a Common Lisp guy if Clojure fell off
> the face of the Earth, hehe)
>
> Clojure and Rich's talks have over the years totally changed my thinking
> on creating software.
>
> Thanks for all the work thats gone into it :)
>
> On Wed, Nov 1, 2017 at 7:33 PM, Wei Hsu  wrote:
>
>> I want to say the same. I've been using Clojure for nearly a decade and
>> it remains my favorite language to work in, largely thanks to the ecosystem
>> and wonderful community. Keep up the good 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.
>>
>
> --
> 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.

[ANN] Dynadoc, dynamic docs for Clojure(Script)

[Alan Moore]

Nice! This will come in very handy.

I’ve also been checking out your Nightlight project. Very impressive work.

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

[Jiacai Liu]

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

Re: Unexpected performace of transducers

[Alex Miller]

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)

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.

Re: [ANN] Clojure 1.9.0-RC2

[Egg Syntax]

Great choices on how to present core specs 

 
-- really clean & readable.

Thanks!

On Monday, November 27, 2017 at 5:17:10 PM UTC-5, Alex Miller wrote:
>
> I should also mention that I've re-built the Clojure doc automation 
> process and the Clojure docs have refreshed for the first time in a long 
> while. Most importantly, the 1.9 docs are up to date and now include specs 
> for things that have been spec'ed:
>
> https://clojure.github.io/clojure/branch-master/index.html
>
> Example macro with specs:
>
> https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/refer-clojure
>
> Additionally, I am in the process of overhauling the contrib project doc 
> automation. In the meantime, I have at least done a manual update of the 
> spec API docs:
>
> https://clojure.github.io/spec.alpha
>
>
> On Monday, November 27, 2017 at 3:47:25 PM UTC-6, Alex Miller wrote:
>>
>> Clojure 1.9.0-RC2 is now available.
>>
>> Try it via
>>
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-RC2
>> - Leiningen: [org.clojure/clojure "1.9.0-RC2"]
>>
>> 1.9.0-RC2 is largely the same as RC1 but has the following changes:
>>
>> - There is a new Maven profile and Ant target in the build to build an 
>> executable Clojure jar with deps included (and test.check). This can be 
>> useful for doing dev on Clojure itself or for just cloning the repo and 
>> doing a quick build to get something runnable.
>> - The readme.txt has been updated to include information about how to 
>> create and run a local jar.
>> - We have stopped publishing the clojure-VERSION.zip file as part of the 
>> release.
>>
>> We would appreciate anything you can do to try out this release. We do 
>> not plan to make any further changes prior to 1.9.0 unless regressions are 
>> found.
>>
>>

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

[Jiacai Liu]

Thanks Alex. Good summary.
I think this can be added to https://clojure.org/reference/transducers

On Tue, Nov 28, 2017 at 10:54 AM, 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)
>
> 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.com/d/optout.