Re: [ANN] Book "The Clojure Standard Library - Annotated Reference"

[Torsten Uhlmann]

Thanks for working on this!

Back in the day I had a "Java Developers Almanac" for Java 1.4 and it
helped getting around the lesser used API parts, or discovering
functionality I hadn't used before.


Alex Miller  schrieb am Do., 8. Dez. 2016 um 04:13 Uhr:

> This is a good gotcha. From Clojure's perspective this is just referencing
> a Java field (which could be mutable and NOT a constant). Maybe it would be
> possible to reflectively determine that this field is actually a constant
> and make it work, not sure.
>
> The number one special case I see people ask about with case though is
> Java class constants (which are *not* constants and don't work). One
> workaround is to use the class name as a string.
>
>
> On Wednesday, December 7, 2016 at 5:43:28 PM UTC-6, Ryan Fowler wrote:
>
> I love the idea.
>
> ​A gotchas section of some sort could be useful. For instance, a detail
> about `case` to consider mentioning is that Java Constants don't work as
> tests.
>
> ryans-mbp:~% cat test.clj
> (let [incoming-character Character/LINE_SEPARATOR]
>   (println "case w/ constant"
>(case incoming-character
>  Character/LINE_SEPARATOR :line-separator
>  :unknown))
>   (println "case w/ int "
>(case incoming-character
>  13 :line-separator
>  :unknown)))
>
> ryans-mbp:~% java -jar $CLOJURE test.clj
> case w/ constant :unknown
> case w/ int  :line-separator
>
> ​I think I understand why this doesn't work but it feels like it should
> work. And without prior knowledge, I don't think I would assume that
> constants don't work.
>
> ​Ryan​
>
>
> On Wed, Dec 7, 2016 at 4:57 PM, Alex Miller  wrote:
>
> This is a cool idea so thanks for working on it.
>
> I was going to buy this (as I buy most of the Clojure books that come out)
> but $48 for an unfinished ebook put me off so I didn't. I totally get why a
> physical book of this length would be that much (because paper is expensive
> right now), but I don't get it with the ebook (particularly EA)? I know you
> likely have little control over this, so it's not really fair to complain
> to you, but maybe you can feed it back to your editor.
>
> While pretty thorough, that case description is still lacking a
> description of one important feature - grouping multiple tests that have
> the same output in a list. Basically this line from the doc string:
>
> (test-constant1 ... test-constantN)  result-expr
>
>
> Example:
>
> (case 3
>   (1 2 3) "1, 2, or 3"
>   4 "4"
>   (5 6 7) "5, 6, or 7")
>
> ;;=> "1, 2, or 3"
>
> I think most people are unaware of this feature and seems like it's the
> kind of thing you'd want in the book.
>
> Alex
>
> On Wednesday, December 7, 2016 at 12:14:29 PM UTC-6, Renzo Borgatti wrote:
>
> Hi all,
>
> I'm very happy to announce the early access of a new book: "Clojure
> Standard Library - Annotated Reference" by Manning. Although it's a
> reference of the roughly 700+ functions (and macros) coming out of the box
> with the Clojure jar file, it is not designed to read as a boring list.
> Think of all the Stackoverflow, mailing lists, ClojureDocs, articles, blogs
> all mashed together to create an essay for each function. The book website
> is:
>
> https://www.manning.com/books/clojure-standard-library
>
> It contains now a total of 4 chapters (around 200 pages) or ~30 functions,
> starting with some of the most important available in the standard library.
> Here's a sample of “case" how it appears on the book
> http://tinyurl.com/hekc55u to give you an idea of the kind of treatment
> they get. Needless to say any feedback is highly appreciated. Any question
> please shout here, personally at reborg*at*reborg.net or on the book
> forum.
>
> Regards,
> Renzo
>
> --
> 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 Grou

Re: RIP Anthony Grimes (Raynes)

[Ken Restivo]

Many people who have been here a while know what a bright, talented, and 
promising young programmer he was, and of his impressive list of contributions 
to the Clojure community. He seemed relentlessly curious, and worked 
professionally in Clojure, Haskell, NodeJS, CoffeeScript, Python, and last week 
was selling me on the virtues of some new javascript thing called 
Svelte.technology.

My project.clj's-- and I'm sure many other people's as well-- are filled with 
calls to his fine libraries.

What a lot of people might not know about Anthony is how much his first love 
(perhaps even more than programming) appeared to have been music. He regularly 
made videos of his singing and rapping covers. He could spend hours talking 
about and playing music, and he was as fearless and eclectic in his tastes in 
music as in technology.

Only a subset of the music he loved made it into my playlist, but I will never 
again be able to hear Eminiem, Watsky, Yelawolf, twentyone pilots, George 
Jones, Adam Lambert, Panic! at the Disco, The Pretty Reckless, CHVRCHES, Fall 
Out Boy, Kitty Pryde, One Republic, Dolly Parton, Paramore, Lana del Rey, and a 
few others, without thinking of him.

If you've never heard some of these artists, and you look up their music find 
that you like it, I'd venture a guess that he'd have been happy to have been a 
motivation for your discovery.

-ken
--
-
On Wed, Dec 07, 2016 at 08:32:06AM -0500, Chas Emerick wrote:
> As some may have already seen on Twitter or other channels, our friend
> Anthony Grimes (Raynes in #clojure IRC and elsewhere, @StRaynes on Twitter)
> has passed away.
> 
> The most immediate announcement of this came via Lance Bradley, one of
> Anthony's closer friends from the Clojure community:
> 
> https://www.facebook.com/lancepantz/posts/10104155686547809?pnref=story
> 
> Anthony's family set up a fundraiser to help with his final expenses, but
> people are going well beyond the target set there; in any case, the family
> would certainly appreciate any help you can offer:
> 
> https://www.gofundme.com/32m55h4
> 
> If you don't know of Anthony, he was a constant inspiration and helping hand
> in Clojure's earlier days, especially in #clojure IRC where he tutored and
> encouraged people daily for years. He was also the creator or a significant
> contributor to dozens of Clojure projects, some of which I guarantee you
> still rely upon every day.
> 
> Anthony himself wrote about some of his history in the Clojure community,
> and also happened to recount at length the most significant memory I'll have
> of him, when we all helped to get a kind 16-year-old to the first Clojure
> Conj in 2010:
> http://blog.raynes.me/blog/2011/11/27/the-clojure-community-and-me/
> 
> I have other memories of and about Anthony that I'd like to share, but not
> now, not yet. Of course, the family will be having a local service for him
> in their time and way. ABecause so many people around the world knew, worked
> with, and called Anthony a friend, I'm hoping we can all have an
> online/remote memorial (maybe an any-comers Hangout or something). That's
> just an idea at the moment, details TBD.
> 
> If you'd like to talk a bit about how Anthony influenced or inspired you,
> please feel free to, here. Some people are also using the #RIPRaynes
> hashtag, if that's your game.
> 
> Rest easy, dude.
> 
> love,
> 
> - Chas
> 
> -- 
> 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] Book "The Clojure Standard Library - Annotated Reference"

[Alex Miller]

This is a good gotcha. From Clojure's perspective this is just referencing 
a Java field (which could be mutable and NOT a constant). Maybe it would be 
possible to reflectively determine that this field is actually a constant 
and make it work, not sure.

The number one special case I see people ask about with case though is Java 
class constants (which are *not* constants and don't work). One workaround 
is to use the class name as a string.


On Wednesday, December 7, 2016 at 5:43:28 PM UTC-6, Ryan Fowler wrote:
>
> I love the idea.
>
> ​A gotchas section of some sort could be useful. For instance, a detail 
> about `case` to consider mentioning is that Java Constants don't work as 
> tests.
>
> ryans-mbp:~% cat test.clj
> (let [incoming-character Character/LINE_SEPARATOR]
>   (println "case w/ constant"
>(case incoming-character
>  Character/LINE_SEPARATOR :line-separator
>  :unknown))
>   (println "case w/ int "
>(case incoming-character
>  13 :line-separator
>  :unknown)))
>
> ryans-mbp:~% java -jar $CLOJURE test.clj
> case w/ constant :unknown
> case w/ int  :line-separator
>
> ​I think I understand why this doesn't work but it feels like it should 
> work. And without prior knowledge, I don't think I would assume that 
> constants don't work.
>
> ​Ryan​
>
>
> On Wed, Dec 7, 2016 at 4:57 PM, Alex Miller  wrote:
>
>> This is a cool idea so thanks for working on it.
>>
>> I was going to buy this (as I buy most of the Clojure books that come 
>> out) but $48 for an unfinished ebook put me off so I didn't. I totally get 
>> why a physical book of this length would be that much (because paper is 
>> expensive right now), but I don't get it with the ebook (particularly EA)? 
>> I know you likely have little control over this, so it's not really fair to 
>> complain to you, but maybe you can feed it back to your editor.
>>
>> While pretty thorough, that case description is still lacking a 
>> description of one important feature - grouping multiple tests that have 
>> the same output in a list. Basically this line from the doc string:
>>
>> (test-constant1 ... test-constantN)  result-expr
>>
>>
>> Example:
>>
>> (case 3
>>   (1 2 3) "1, 2, or 3"
>>   4 "4"
>>   (5 6 7) "5, 6, or 7")
>>
>> ;;=> "1, 2, or 3"
>>
>> I think most people are unaware of this feature and seems like it's the 
>> kind of thing you'd want in the book.
>>
>> Alex
>>
>> On Wednesday, December 7, 2016 at 12:14:29 PM UTC-6, Renzo Borgatti wrote:
>>>
>>> Hi all, 
>>>
>>> I'm very happy to announce the early access of a new book: "Clojure 
>>> Standard Library - Annotated Reference" by Manning. Although it's a 
>>> reference of the roughly 700+ functions (and macros) coming out of the box 
>>> with the Clojure jar file, it is not designed to read as a boring list. 
>>> Think of all the Stackoverflow, mailing lists, ClojureDocs, articles, blogs 
>>> all mashed together to create an essay for each function. The book website 
>>> is: 
>>>
>>> https://www.manning.com/books/clojure-standard-library 
>>>
>>> It contains now a total of 4 chapters (around 200 pages) or ~30 
>>> functions, starting with some of the most important available in the 
>>> standard library. Here's a sample of “case" how it appears on the book 
>>> http://tinyurl.com/hekc55u to give you an idea of the kind of treatment 
>>> they get. Needless to say any feedback is highly appreciated. Any question 
>>> please shout here, personally at reborg*at*reborg.net or on the book 
>>> forum. 
>>>
>>> Regards, 
>>> Renzo 
>>>
>> -- 
>> 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

Re: [ANN] Book "The Clojure Standard Library - Annotated Reference"

[Ryan Fowler]

I love the idea.

​A gotchas section of some sort could be useful. For instance, a detail
about `case` to consider mentioning is that Java Constants don't work as
tests.

ryans-mbp:~% cat test.clj
(let [incoming-character Character/LINE_SEPARATOR]
  (println "case w/ constant"
   (case incoming-character
 Character/LINE_SEPARATOR :line-separator
 :unknown))
  (println "case w/ int "
   (case incoming-character
 13 :line-separator
 :unknown)))

ryans-mbp:~% java -jar $CLOJURE test.clj
case w/ constant :unknown
case w/ int  :line-separator

​I think I understand why this doesn't work but it feels like it should
work. And without prior knowledge, I don't think I would assume that
constants don't work.

​Ryan​


On Wed, Dec 7, 2016 at 4:57 PM, Alex Miller  wrote:

> This is a cool idea so thanks for working on it.
>
> I was going to buy this (as I buy most of the Clojure books that come out)
> but $48 for an unfinished ebook put me off so I didn't. I totally get why a
> physical book of this length would be that much (because paper is expensive
> right now), but I don't get it with the ebook (particularly EA)? I know you
> likely have little control over this, so it's not really fair to complain
> to you, but maybe you can feed it back to your editor.
>
> While pretty thorough, that case description is still lacking a
> description of one important feature - grouping multiple tests that have
> the same output in a list. Basically this line from the doc string:
>
> (test-constant1 ... test-constantN)  result-expr
>
>
> Example:
>
> (case 3
>   (1 2 3) "1, 2, or 3"
>   4 "4"
>   (5 6 7) "5, 6, or 7")
>
> ;;=> "1, 2, or 3"
>
> I think most people are unaware of this feature and seems like it's the
> kind of thing you'd want in the book.
>
> Alex
>
> On Wednesday, December 7, 2016 at 12:14:29 PM UTC-6, Renzo Borgatti wrote:
>>
>> Hi all,
>>
>> I'm very happy to announce the early access of a new book: "Clojure
>> Standard Library - Annotated Reference" by Manning. Although it's a
>> reference of the roughly 700+ functions (and macros) coming out of the box
>> with the Clojure jar file, it is not designed to read as a boring list.
>> Think of all the Stackoverflow, mailing lists, ClojureDocs, articles, blogs
>> all mashed together to create an essay for each function. The book website
>> is:
>>
>> https://www.manning.com/books/clojure-standard-library
>>
>> It contains now a total of 4 chapters (around 200 pages) or ~30
>> functions, starting with some of the most important available in the
>> standard library. Here's a sample of “case" how it appears on the book
>> http://tinyurl.com/hekc55u to give you an idea of the kind of treatment
>> they get. Needless to say any feedback is highly appreciated. Any question
>> please shout here, personally at reborg*at*reborg.net or on the book
>> forum.
>>
>> Regards,
>> Renzo
>>
> --
> 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] Book "The Clojure Standard Library - Annotated Reference"

[Alex Miller]

This is a cool idea so thanks for working on it.

I was going to buy this (as I buy most of the Clojure books that come out) 
but $48 for an unfinished ebook put me off so I didn't. I totally get why a 
physical book of this length would be that much (because paper is expensive 
right now), but I don't get it with the ebook (particularly EA)? I know you 
likely have little control over this, so it's not really fair to complain 
to you, but maybe you can feed it back to your editor.

While pretty thorough, that case description is still lacking a description 
of one important feature - grouping multiple tests that have the same 
output in a list. Basically this line from the doc string:

(test-constant1 ... test-constantN)  result-expr


Example:

(case 3
  (1 2 3) "1, 2, or 3"
  4 "4"
  (5 6 7) "5, 6, or 7")

;;=> "1, 2, or 3"

I think most people are unaware of this feature and seems like it's the 
kind of thing you'd want in the book.

Alex

On Wednesday, December 7, 2016 at 12:14:29 PM UTC-6, Renzo Borgatti wrote:
>
> Hi all, 
>
> I'm very happy to announce the early access of a new book: "Clojure 
> Standard Library - Annotated Reference" by Manning. Although it's a 
> reference of the roughly 700+ functions (and macros) coming out of the box 
> with the Clojure jar file, it is not designed to read as a boring list. 
> Think of all the Stackoverflow, mailing lists, ClojureDocs, articles, blogs 
> all mashed together to create an essay for each function. The book website 
> is: 
>
> https://www.manning.com/books/clojure-standard-library 
>
> It contains now a total of 4 chapters (around 200 pages) or ~30 functions, 
> starting with some of the most important available in the standard library. 
> Here's a sample of “case" how it appears on the book 
> http://tinyurl.com/hekc55u to give you an idea of the kind of treatment 
> they get. Needless to say any feedback is highly appreciated. Any question 
> please shout here, personally at reborg*at*reborg.net or on the book 
> forum. 
>
> Regards, 
> Renzo 
>

-- 
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: Java memory model & stateful tranducers

[Léo Noel]

>
> And then I think it is the responsibility of the transducing context to 
> lock appropriately to ensure visibility (if needed).


Totally agree, that's why volatile instead of unsynchronized in transducer 
sounds like belt and suspenders to me.


On Wednesday, December 7, 2016 at 7:00:09 PM UTC+1, Alex Miller wrote:
>
> I think the reason for some things being volatile and some not is that we 
> want all of that stuff to be stateful. The volatile ones are making things 
> stateful by explicitly creating a stateful Clojure container for immutable 
> values. The ArrayLists are inherently stateful because they are mutable 
> (done for perf reasons).
>
> And then I think it is the responsibility of the transducing context to 
> lock appropriately to ensure visibility (if needed).
>
> On Wednesday, December 7, 2016 at 11:56:13 AM UTC-6, Alex Miller wrote:
>>
>> Transducers are expected to be invoked always in a single thread context. 
>> Everything in core maintains that by just running it in a single thread. 
>> core.async channels may be invoked from many threads, but only one at a 
>> time, and channel itself properly locks to make that state visible. That 
>> said, it does seem odd to me now that partition-by and partition-all have 
>> state that is not volatile. Thinking about it.
>>
>> On Wednesday, December 7, 2016 at 11:39:54 AM UTC-6, Léo Noel wrote:
>>>
>>> Hi !
>>>
>>> I'm a bit confused about the official design rules for stateful 
>>> transducers and transducing contexts, especially about which one should be 
>>> in charge of memory visibility guarantees.
>>>
>>> The common practice seems to be using volatiles to hold state in 
>>> transducers (e.g distinct 
>>> )
>>>  
>>> to ensure memory visibility. This usage of volatile is actually the 
>>> original motivation 
>>> 
>>>  
>>> for adding it in core, and is explained further here 
>>>  
>>> and here .
>>> However, some stateful tranducers use unsynchronized mutable state 
>>> instead (e.g partition-all 
>>> ),
>>>  
>>> which goes against the previous volatile argument of "safely publish values 
>>> between threads".
>>> In practice, partition-all works fine in e.g core.async because each 
>>> call to the (maybe stateful) step function is made inside the channel lock.
>>>
>>> So my question is, does it make any sense at all to have a transducing 
>>> context that does *not* enforce a *happens-before* order between 
>>> successive calls to the step function ?
>>> If yes, I would be curious to see an example, and that would mean 
>>> partition-all is broken.
>>> If no, what is the point of using volatiles for stateful transducers ? 
>>> As long as they are not exposed to the outside, unsynchronized variables 
>>> would do the job and should be slightly faster.
>>>
>>> Am I missing something ?
>>> Thanks
>>>
>>> Leo
>>>
>>
On Wednesday, December 7, 2016 at 7:00:09 PM UTC+1, Alex Miller wrote:
>
> I think the reason for some things being volatile and some not is that we 
> want all of that stuff to be stateful. The volatile ones are making things 
> stateful by explicitly creating a stateful Clojure container for immutable 
> values. The ArrayLists are inherently stateful because they are mutable 
> (done for perf reasons).
>
> And then I think it is the responsibility of the transducing context to 
> lock appropriately to ensure visibility (if needed).
>
> On Wednesday, December 7, 2016 at 11:56:13 AM UTC-6, Alex Miller wrote:
>>
>> Transducers are expected to be invoked always in a single thread context. 
>> Everything in core maintains that by just running it in a single thread. 
>> core.async channels may be invoked from many threads, but only one at a 
>> time, and channel itself properly locks to make that state visible. That 
>> said, it does seem odd to me now that partition-by and partition-all have 
>> state that is not volatile. Thinking about it.
>>
>> On Wednesday, December 7, 2016 at 11:39:54 AM UTC-6, Léo Noel wrote:
>>>
>>> Hi !
>>>
>>> I'm a bit confused about the official design rules for stateful 
>>> transducers and transducing contexts, especially about which one should be 
>>> in charge of memory visibility guarantees.
>>>
>>> The common practice seems to be using volatiles to hold state in 
>>> transducers (e.g distinct 
>>> )
>

[ANN] Book "The Clojure Standard Library - Annotated Reference"

[Renzo Borgatti]

Hi all, 

I'm very happy to announce the early access of a new book: "Clojure Standard 
Library - Annotated Reference" by Manning. Although it's a reference of the 
roughly 700+ functions (and macros) coming out of the box with the Clojure jar 
file, it is not designed to read as a boring list. Think of all the 
Stackoverflow, mailing lists, ClojureDocs, articles, blogs all mashed together 
to create an essay for each function. The book website is:

https://www.manning.com/books/clojure-standard-library

It contains now a total of 4 chapters (around 200 pages) or ~30 functions, 
starting with some of the most important available in the standard library. 
Here's a sample of “case" how it appears on the book http://tinyurl.com/hekc55u 
to give you an idea of the kind of treatment they get. Needless to say any 
feedback is highly appreciated. Any question please shout here, personally at 
reborg*at*reborg.net or on the book forum.

Regards,
Renzo

-- 
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: Index of an element in a vector of vectors

[Andy-]

One option is to use keep-indexed:

(first
  (keep-indexed
(fn [i xs]
  (first
(keep-indexed
  (fn [j x]
(when (= x "5")
  [i j]))
  xs)))
players))



On Wednesday, December 7, 2016 at 5:32:10 PM UTC+1, Rickesh Bedia wrote:
>
> If I have 
>
> (def players [["1" "2" "3"] ["4" "5" "6"] ["7" "8" "9"]])
>
> How would I get the index of number 5? I think it should be [1 1] but 
> don't know how to get this
>
> If it were more simple such as
>
> (def players ["1" "2" "3"])
>
> I can get the index using
>
> (.indexOf players "2") > 1
> (.indexOf players "3") > 2
>
>

-- 
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: Java memory model & stateful tranducers

[Alex Miller]

I think the reason for some things being volatile and some not is that we 
want all of that stuff to be stateful. The volatile ones are making things 
stateful by explicitly creating a stateful Clojure container for immutable 
values. The ArrayLists are inherently stateful because they are mutable 
(done for perf reasons).

And then I think it is the responsibility of the transducing context to 
lock appropriately to ensure visibility (if needed).

On Wednesday, December 7, 2016 at 11:56:13 AM UTC-6, Alex Miller wrote:
>
> Transducers are expected to be invoked always in a single thread context. 
> Everything in core maintains that by just running it in a single thread. 
> core.async channels may be invoked from many threads, but only one at a 
> time, and channel itself properly locks to make that state visible. That 
> said, it does seem odd to me now that partition-by and partition-all have 
> state that is not volatile. Thinking about it.
>
> On Wednesday, December 7, 2016 at 11:39:54 AM UTC-6, Léo Noel wrote:
>>
>> Hi !
>>
>> I'm a bit confused about the official design rules for stateful 
>> transducers and transducing contexts, especially about which one should be 
>> in charge of memory visibility guarantees.
>>
>> The common practice seems to be using volatiles to hold state in 
>> transducers (e.g distinct 
>> )
>>  
>> to ensure memory visibility. This usage of volatile is actually the 
>> original motivation 
>> 
>>  
>> for adding it in core, and is explained further here 
>>  
>> and here .
>> However, some stateful tranducers use unsynchronized mutable state 
>> instead (e.g partition-all 
>> ),
>>  
>> which goes against the previous volatile argument of "safely publish values 
>> between threads".
>> In practice, partition-all works fine in e.g core.async because each call 
>> to the (maybe stateful) step function is made inside the channel lock.
>>
>> So my question is, does it make any sense at all to have a transducing 
>> context that does *not* enforce a *happens-before* order between 
>> successive calls to the step function ?
>> If yes, I would be curious to see an example, and that would mean 
>> partition-all is broken.
>> If no, what is the point of using volatiles for stateful transducers ? As 
>> long as they are not exposed to the outside, unsynchronized variables would 
>> do the job and should be slightly faster.
>>
>> Am I missing something ?
>> Thanks
>>
>> Leo
>>
>

-- 
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: Java memory model & stateful tranducers

[Alex Miller]

Transducers are expected to be invoked always in a single thread context. 
Everything in core maintains that by just running it in a single thread. 
core.async channels may be invoked from many threads, but only one at a 
time, and channel itself properly locks to make that state visible. That 
said, it does seem odd to me now that partition-by and partition-all have 
state that is not volatile. Thinking about it.

On Wednesday, December 7, 2016 at 11:39:54 AM UTC-6, Léo Noel wrote:
>
> Hi !
>
> I'm a bit confused about the official design rules for stateful 
> transducers and transducing contexts, especially about which one should be 
> in charge of memory visibility guarantees.
>
> The common practice seems to be using volatiles to hold state in 
> transducers (e.g distinct 
> )
>  
> to ensure memory visibility. This usage of volatile is actually the 
> original motivation 
> 
>  
> for adding it in core, and is explained further here 
>  
> and here .
> However, some stateful tranducers use unsynchronized mutable state instead 
> (e.g partition-all 
> ),
>  
> which goes against the previous volatile argument of "safely publish values 
> between threads".
> In practice, partition-all works fine in e.g core.async because each call 
> to the (maybe stateful) step function is made inside the channel lock.
>
> So my question is, does it make any sense at all to have a transducing 
> context that does *not* enforce a *happens-before* order between 
> successive calls to the step function ?
> If yes, I would be curious to see an example, and that would mean 
> partition-all is broken.
> If no, what is the point of using volatiles for stateful transducers ? As 
> long as they are not exposed to the outside, unsynchronized variables would 
> do the job and should be slightly faster.
>
> Am I missing something ?
> Thanks
>
> Leo
>

-- 
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: RIP Anthony Grimes (Raynes)

[Alex Miller]

Just tragic news today. You can find some other memories 
at 
https://www.reddit.com/r/Clojure/comments/5gyyxw/clojure_open_source_contributor_anthony_grimes/
 
as well. He will be missed!

On Wednesday, December 7, 2016 at 7:32:23 AM UTC-6, Chas Emerick wrote:
>
> As some may have already seen on Twitter or other channels, our friend 
> Anthony Grimes (Raynes in #clojure IRC and elsewhere, @StRaynes on 
> Twitter) has passed away. 
>
> The most immediate announcement of this came via Lance Bradley, one of 
> Anthony's closer friends from the Clojure community: 
>
> https://www.facebook.com/lancepantz/posts/10104155686547809?pnref=story 
>
> Anthony's family set up a fundraiser to help with his final expenses, 
> but people are going well beyond the target set there; in any case, the 
> family would certainly appreciate any help you can offer: 
>
> https://www.gofundme.com/32m55h4 
>
> If you don't know of Anthony, he was a constant inspiration and helping 
> hand in Clojure's earlier days, especially in #clojure IRC where he 
> tutored and encouraged people daily for years. He was also the creator 
> or a significant contributor to dozens of Clojure projects, some of 
> which I guarantee you still rely upon every day. 
>
> Anthony himself wrote about some of his history in the Clojure 
> community, and also happened to recount at length the most significant 
> memory I'll have of him, when we all helped to get a kind 16-year-old to 
> the first Clojure Conj in 2010: 
> http://blog.raynes.me/blog/2011/11/27/the-clojure-community-and-me/ 
>
> I have other memories of and about Anthony that I'd like to share, but 
> not now, not yet. Of course, the family will be having a local service 
> for him in their time and way. ABecause so many people around the world 
> knew, worked with, and called Anthony a friend, I'm hoping we can all 
> have an online/remote memorial (maybe an any-comers Hangout or 
> something). That's just an idea at the moment, details TBD. 
>
> If you'd like to talk a bit about how Anthony influenced or inspired 
> you, please feel free to, here. Some people are also using the 
> #RIPRaynes hashtag, if that's your game. 
>
> Rest easy, dude. 
>
> love, 
>
> - Chas 
>

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

Java memory model & stateful tranducers

[Léo Noel]

Hi !

I'm a bit confused about the official design rules for stateful transducers 
and transducing contexts, especially about which one should be in charge of 
memory visibility guarantees.

The common practice seems to be using volatiles to hold state in 
transducers (e.g distinct 
)
 
to ensure memory visibility. This usage of volatile is actually the 
original motivation  for 
adding it in core, and is explained further here 
 and 
here .
However, some stateful tranducers use unsynchronized mutable state instead 
(e.g partition-all 
),
 
which goes against the previous volatile argument of "safely publish values 
between threads".
In practice, partition-all works fine in e.g core.async because each call 
to the (maybe stateful) step function is made inside the channel lock.

So my question is, does it make any sense at all to have a transducing 
context that does *not* enforce a *happens-before* order between successive 
calls to the step function ?
If yes, I would be curious to see an example, and that would mean 
partition-all is broken.
If no, what is the point of using volatiles for stateful transducers ? As 
long as they are not exposed to the outside, unsynchronized variables would 
do the job and should be slightly faster.

Am I missing something ?
Thanks

Leo

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

Index of an element in a vector of vectors

['Rickesh Bedia' via Clojure]

If I have 

(def players [["1" "2" "3"] ["4" "5" "6"] ["7" "8" "9"]])

How would I get the index of number 5? I think it should be [1 1] but don't 
know how to get this

If it were more simple such as

(def players ["1" "2" "3"])

I can get the index using

(.indexOf players "2") > 1
(.indexOf players "3") > 2

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

RIP Anthony Grimes (Raynes)

[Alan Moore]

Oh no... so sad and tragic. I remember everyone pitching in to "get him to the 
conj"... and all his great Clojure contributions. I always admired his 
enthusiasm and spirit.

My condolences to his close friends and family. While I never met him in person 
his presence was felt in this forum and in many others. He will be sorely 
missed.

#RipRaynes

-- 
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] Nightlight 1.3.0: Total Rewrite (of the frontend)

[Zach Oakes]

TL;DR: Nightlight, and embedded Clojure editor, just got a makeover: 
https://sekao.net/nightlight/

Well, it had to happen at some point. The original version of Nightlight I 
wrote a few months ago was cobbled together with bootstrap, jQuery, and 
regrets. I knew about React, but I was but a simple farmer tending to my 
parenthesis, and wasn’t sure how to use it.

I finally found the time to learn and over a few days I rewrote the front 
end with Reagent and the Material UI library. In addition to just looking 
better (subjectively), it’ll be much nicer to maintain. Here’s the 
obligatory before 

 
and after  
shots.

Oh, and I will be giving a talk about Nightlight at ClojureD in February!

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

RIP Anthony Grimes (Raynes)

[Chas Emerick]

As some may have already seen on Twitter or other channels, our friend 
Anthony Grimes (Raynes in #clojure IRC and elsewhere, @StRaynes on 
Twitter) has passed away.


The most immediate announcement of this came via Lance Bradley, one of 
Anthony's closer friends from the Clojure community:


https://www.facebook.com/lancepantz/posts/10104155686547809?pnref=story

Anthony's family set up a fundraiser to help with his final expenses, 
but people are going well beyond the target set there; in any case, the 
family would certainly appreciate any help you can offer:


https://www.gofundme.com/32m55h4

If you don't know of Anthony, he was a constant inspiration and helping 
hand in Clojure's earlier days, especially in #clojure IRC where he 
tutored and encouraged people daily for years. He was also the creator 
or a significant contributor to dozens of Clojure projects, some of 
which I guarantee you still rely upon every day.


Anthony himself wrote about some of his history in the Clojure 
community, and also happened to recount at length the most significant 
memory I'll have of him, when we all helped to get a kind 16-year-old to 
the first Clojure Conj in 2010: 
http://blog.raynes.me/blog/2011/11/27/the-clojure-community-and-me/


I have other memories of and about Anthony that I'd like to share, but 
not now, not yet. Of course, the family will be having a local service 
for him in their time and way. ABecause so many people around the world 
knew, worked with, and called Anthony a friend, I'm hoping we can all 
have an online/remote memorial (maybe an any-comers Hangout or 
something). That's just an idea at the moment, details TBD.


If you'd like to talk a bit about how Anthony influenced or inspired 
you, please feel free to, here. Some people are also using the 
#RIPRaynes hashtag, if that's your game.


Rest easy, dude.

love,

- Chas

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