Re: slackpocalypse?

[Cam Peterson]

A company I did some work for adopted Ryver for the very reason that it was the 
"free" alternative to Slack. While it did most of the job as the company's comm 
bus, my experience was that they are a far cry from Slack. The integration 
story is weak too. This crowd would not be happy with Ryver, though it's not a 
bad choice for a smaller company that needs free chat. 

-- 
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: slackpocalypse? (Alternatives to Slack like Matrix.org)

[Herwig Hochleitner]

In any such discussion, I'll heavily favor matrix.org. To me,
decentralization seems inevitable and I hope that it will already carry,
what marketers will be calling web 3.0. Current matrix.org infrastructure
is only semi-decentralized (similar to xmpp), but the data model is already
built with full decentralization in mind and current matrix clients are
already pretty complete and user friendly.

That said, I'm not aware of any existing Clojure/ClojureScript integration,
but I fathom it would be natural to just use
https://github.com/matrix-org/matrix-js-sdk from ClojureScript.

Also, have a look at the Clojure Community channel (bridged to a slack
channel): https://riot.im/app/#/room/#clojure-community:matrix.org
and the IRC bridge channel: https://riot.im/app/#/room/#clojure:matrix.org

-- 
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: slackpocalypse?

[Herwig Hochleitner]

As I said in the other thread, let's migrate to matrix.org:
https://riot.im/app/#/room/#clojure:matrix.org
There, if the official servers ever get overloaded/dropped/monetized, we
can just start hosting our own server without loosing any history.
Also it has no message limit and full searchability.
​

-- 
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: Cases of `RT/canSeq`

[Mikera]

One of the things that JVMs can do is create a small cache for the most 
recently seen classes in instanceof checks. I believe both OpenJDK and the 
Oracle JVM do this.

So if you check for both ISeq and Seqable, you may find that you get twice 
as many classes cached, and therefore see a performance benefit. Of course 
this is implementation dependant so YMMV.

On Friday, 19 May 2017 11:28:27 UTC+8, Tianxiang Xiong wrote:
>
> But if something is `ISeq`, it's `Seqable`, so checking for `Seqable` 
> alone should be sufficient. 
>
> Am I missing something here? Is there a performance performance benefit of 
> checking for `ISeq` *and* `Seqable` that I'm not aware of?
>
> On Wednesday, May 3, 2017 at 2:19:42 AM UTC-7, Mikera wrote:
>>
>> Clearly not necessary from a functional perspective.
>>
>> However I believe the ordering of these tests will affect JVM 
>> optimisations. You want to test the common/fast cases first. And the JVM 
>> does some clever things with caching most recently used lookups, which will 
>> again behave differently if you test things in different orders.
>>
>> Benchmarking on realistic workloads would typically be required to 
>> determine the optimal order.
>>
>> FWIW I find it odd that the null check is third. This is extremely fast 
>> (certainly faster than instance checks) and is a very common case given the 
>> amount of nil usage in idiomatic Clojure code (as an empty seq), so I would 
>> probably put it first.
>>
>> On Wednesday, 3 May 2017 11:59:29 UTC+8, Tianxiang Xiong wrote:
>>>
>>> Why does `clojure.lang.RT/canSeq` need to check both `ISeq` _and_ 
>>> `Seqable` when `ISeq <- IPersistentCollection <- Seqable`?
>>>
>>> static public boolean canSeq(Object coll){
>>> return coll instanceof ISeq
>>> || coll instanceof Seqable
>>> || coll == null
>>> || coll instanceof Iterable
>>> || coll.getClass().isArray()
>>> || coll instanceof CharSequence
>>> || coll instanceof Map;
>>> }
>>>
>>>

-- 
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: Understanding `clojure.core.reducers/rfn`

[Alex Miller]

This is a place where reducers and transducers diverge. Transducers don't 
have support for automatic kv reducing (there are some tricky details as to 
why this was possible in reducers but not as easy in transducers, which I 
mostly don't remember at this point). That is an area of possible future 
extension.



On Friday, May 19, 2017 at 12:49:09 AM UTC-5, Tianxiang Xiong wrote:
>
> I think this is one of those cases where I need to see an example to 
> understand.
>
> From what I can tell, the `(fn [f1] (rfn ...))` argument to `folder` is a 
> reducing-function-transformer--i.e. transducer, except there are some 
> differences in things like order of application in composition. I *don't* see 
> this 3-arity case for the transducer version of `clojure.core/map`.
>
> In my mind, the following are equivalent
>
> (r/reducer [1 2 3] (map f))
>
> (r/map f [1 2 3])
>
> So the following should be equivalent:
>
> ;; Reducer
> (fn [f1]
>   (rfn [f1 k]
>([ret k v]
> (f1 ret (f k v)
>
> ;; macroexpands to
> (fn [f1]
>   (fn
> ([] (f1))
> ([ret v] (f1 ret (f v)))
> ([ret k v] (f1 ret (f k v)
>
> ;; and should be equivalent to the transducer (map f):
> (fn [rf]
>   (fn
> ([] (rf))
> ([result] (rf result))
> ([result input]
>  (rf result (f input)))
> ([result input & inputs]
>  (rf result (apply f input inputs)
>
>
> Yet they are clearly *not* the same: there is nothing in the transducer 
> about `[ret k v]`. So I must be missing something fundamental about the 
> relationship between reducers and transducers.
>
>
> On Thursday, May 18, 2017 at 9:34:54 PM UTC-7, Alex Miller wrote:
>>
>> Reducers combine functionally, so they all have to support it to create 
>> any composite reducer that contains map.
>>
>> On Thursday, May 18, 2017 at 10:11:23 PM UTC-5, Tianxiang Xiong wrote:
>>>
>>> Would that ever be the case for `r/map`? Or does it only apply to 
>>> certain other reducers?
>>>
>>> On Thursday, May 18, 2017 at 4:11:39 PM UTC-7, Alex Miller wrote:

 The 3 arity is used when reducing over a map, like reduce-kv. Reducers 
 do this automatically which varies from the core reduce.
>>>
>>>

-- 
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: Cases of `RT/canSeq`

[Tianxiang Xiong]

That seems unlikely to be the reason here. ¯\_(ツ)_/¯

As you said, the `null` check should come first if performance is the 
driving concern. Besides, why check for a subinterface *and* its 
superinterface only for this case? There are more cases that could be 
checked.

On Friday, May 19, 2017 at 7:09:00 AM UTC-7, Mikera wrote:
>
> One of the things that JVMs can do is create a small cache for the most 
> recently seen classes in instanceof checks. I believe both OpenJDK and the 
> Oracle JVM do this.
>
> So if you check for both ISeq and Seqable, you may find that you get twice 
> as many classes cached, and therefore see a performance benefit. Of course 
> this is implementation dependant so YMMV.
>
> On Friday, 19 May 2017 11:28:27 UTC+8, Tianxiang Xiong wrote:
>>
>> But if something is `ISeq`, it's `Seqable`, so checking for `Seqable` 
>> alone should be sufficient. 
>>
>> Am I missing something here? Is there a performance performance benefit 
>> of checking for `ISeq` *and* `Seqable` that I'm not aware of?
>>
>> On Wednesday, May 3, 2017 at 2:19:42 AM UTC-7, Mikera wrote:
>>>
>>> Clearly not necessary from a functional perspective.
>>>
>>> However I believe the ordering of these tests will affect JVM 
>>> optimisations. You want to test the common/fast cases first. And the JVM 
>>> does some clever things with caching most recently used lookups, which will 
>>> again behave differently if you test things in different orders.
>>>
>>> Benchmarking on realistic workloads would typically be required to 
>>> determine the optimal order.
>>>
>>> FWIW I find it odd that the null check is third. This is extremely fast 
>>> (certainly faster than instance checks) and is a very common case given the 
>>> amount of nil usage in idiomatic Clojure code (as an empty seq), so I would 
>>> probably put it first.
>>>
>>> On Wednesday, 3 May 2017 11:59:29 UTC+8, Tianxiang Xiong wrote:

 Why does `clojure.lang.RT/canSeq` need to check both `ISeq` _and_ 
 `Seqable` when `ISeq <- IPersistentCollection <- Seqable`?

 static public boolean canSeq(Object coll){
 return coll instanceof ISeq
 || coll instanceof Seqable
 || coll == null
 || coll instanceof Iterable
 || coll.getClass().isArray()
 || coll instanceof CharSequence
 || coll instanceof Map;
 }



-- 
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: slackpocalypse?

[Mars0i]

I have no opinion, but fwiw the OCaml folks began experimenting with Discourse 
about a week ago: https://discuss.ocaml.org.

This isn't really an IRC/Slack style platform, afaics, but the discussions that 
led up to it included concern about Slack's message limit.  (These discussions 
can be found on the Google OCaml Aggregation list starting last summer.)

-- 
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: Understanding `clojure.core.reducers/rfn`

[Tianxiang Xiong]

OK, so would you say it's *not* good practice to do:

(r/reducer [1 2 3] (map f))

instead of 

(r/map f [1 2 3])

because the former doesn't create a reducer that handles kv-reduction? 

If so, it seems that `folder`/`reducer` are not fns intended for public 
consumption, since `rfn` is private and there's no easy way to create 
reducing function transformers that work with `folder`/`reducer`. Is this 
the case?

Creating a reducer from a transducer may not be very useful, given that 
`reduce`/`transduce` can be used to get *sequential* reduction either way. 
Creating a *folder* from a transducer, however, seems like it'd be 
useful--the transducer captures the *what*, while the folder captures the 
*how* (parallel via fork/join). So it'd be nice if

(r/folder [1 2 3] xf)

was the way to do it.

On Friday, May 19, 2017 at 8:11:47 AM UTC-7, Alex Miller wrote:
>
> This is a place where reducers and transducers diverge. Transducers don't 
> have support for automatic kv reducing (there are some tricky details as to 
> why this was possible in reducers but not as easy in transducers, which I 
> mostly don't remember at this point). That is an area of possible future 
> extension.
>
>
>
> On Friday, May 19, 2017 at 12:49:09 AM UTC-5, Tianxiang Xiong wrote:
>>
>> I think this is one of those cases where I need to see an example to 
>> understand.
>>
>> From what I can tell, the `(fn [f1] (rfn ...))` argument to `folder` is a 
>> reducing-function-transformer--i.e. transducer, except there are some 
>> differences in things like order of application in composition. I *don't* 
>> see 
>> this 3-arity case for the transducer version of `clojure.core/map`.
>>
>> In my mind, the following are equivalent
>>
>> (r/reducer [1 2 3] (map f))
>>
>> (r/map f [1 2 3])
>>
>> So the following should be equivalent:
>>
>> ;; Reducer
>> (fn [f1]
>>   (rfn [f1 k]
>>([ret k v]
>> (f1 ret (f k v)
>>
>> ;; macroexpands to
>> (fn [f1]
>>   (fn
>> ([] (f1))
>> ([ret v] (f1 ret (f v)))
>> ([ret k v] (f1 ret (f k v)
>>
>> ;; and should be equivalent to the transducer (map f):
>> (fn [rf]
>>   (fn
>> ([] (rf))
>> ([result] (rf result))
>> ([result input]
>>  (rf result (f input)))
>> ([result input & inputs]
>>  (rf result (apply f input inputs)
>>
>>
>> Yet they are clearly *not* the same: there is nothing in the transducer 
>> about `[ret k v]`. So I must be missing something fundamental about the 
>> relationship between reducers and transducers.
>>
>>
>> On Thursday, May 18, 2017 at 9:34:54 PM UTC-7, Alex Miller wrote:
>>>
>>> Reducers combine functionally, so they all have to support it to create 
>>> any composite reducer that contains map.
>>>
>>> On Thursday, May 18, 2017 at 10:11:23 PM UTC-5, Tianxiang Xiong wrote:

 Would that ever be the case for `r/map`? Or does it only apply to 
 certain other reducers?

 On Thursday, May 18, 2017 at 4:11:39 PM UTC-7, Alex Miller wrote:
>
> The 3 arity is used when reducing over a map, like reduce-kv. Reducers 
> do this automatically which varies from the core reduce.



-- 
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: Sayid Pro - Transparency for Clojure Production Environments (kickstarter)

[Tianxiang Xiong]

Honest feedback: $45,000 seems far too high as a Kickstarter goal, and the 
current results seem to bear that out. 

It may be a good idea to start with a lower amount, deliver more features, 
then try to raise more money.

On Monday, May 8, 2017 at 10:51:55 AM UTC-7, Bill Piel wrote:
>
> I was surprised by some of the results too. One thing to consider though: 
> if you added up all the editors (emacs, cursive, vim, atom), I think it 
> exceeded the votes for a web UI, but web is the common denominator.
>
>
>
> On Monday, May 8, 2017 at 1:30:00 PM UTC-4, adrian...@mail.yu.edu wrote:
>>
>> Thanks for the clarifications and answers! Interested to see what Emacs 
>> integration looks like. I'm surprised most developers want web interfaces 
>> for this stuff but can't argue with the data if it means more licenses sold 
>> for you. 
>>
>> On Monday, May 8, 2017 at 1:10:37 PM UTC-4, Bill Piel wrote:
>>>
>>> Thanks for the questions and feedback, Adrian.
>>>
>>> > Why is the Pro version acceptable for production use and the free 
>>> version is not? 
>>>
>>> I thought I addressed that well in the video, but maybe not. And I 
>>> didn't do much to address that in the text. The answer is that sayid stores 
>>> all the data that it captures in memory. It would be much too easy to take 
>>> down a production server by capturing too much. Sayid Pro immediately 
>>> exports everything it captures to a db, minimizing impact on a server. I 
>>> hope that makes sense.
>>>
>>> > Why then is a web interface for this necessary or even desirable?
>>>
>>> My focus with sayid has been on the emacs integration, because that's 
>>> what I use. For Sayid Pro, I wanted to build what the community wanted. I 
>>> conducted a survey and a web interface was *far* more requested than 
>>> anything else. If the market wants integrations with IDEs/editors, or 
>>> possibly other production monitoring services, I will build that. But for 
>>> the prototype, I wanted to show what I believed would be generally most 
>>> appealing.
>>>
>>> Additionally, you describe cider and cursive as being the most mature 
>>> *development* environments. Agreed. They are excellent. But, I wouldn't 
>>> describe sayid pro as a development tool.
>>>
>>> I hope that helps.
>>>
>>> thanks
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Monday, May 8, 2017 at 12:54:23 PM UTC-4, adrian...@mail.yu.edu 
>>> wrote:

 Why is the Pro version acceptable for production use and the free 
 version is not? Is it just the UI/UX improvements? I looked for this in 
 the 
 Kickstarter since I assumed this would be a major selling point, but could 
 not find the answer. Apologies if I missed something.  

 I guess I also have unrelated concerns. 

 TRACE is a facility which has been part of Lisp systems since time 
 immemorial. Visualizing traces is common in the Common Lisp world. Like 
 other Lisp tooling, progress on porting equivalent functionality to 
 Clojure 
 has been slow, but has progressed significantly. At this point CIDER and 
 Cursive have progressed to the most mature development environments 
 available for Clojure programming. Why then is a web interface for this 
 necessary or even desirable? If you have a better solution than what is 
 provided by the built in functionality of your preferred development 
 environment, you extend it. This means plugins in the IDE world, Elisp 
 packages in the Emacs world, etc. Why not take that approach, which will 
 lead to a product that integrates well with a developers existing tooling. 

 On Monday, May 8, 2017 at 10:35:00 AM UTC-4, Bill Piel wrote:
>
> Today I launched a kickstarter for Sayid Pro.
>
>
> https://www.kickstarter.com/projects/1269641244/sayid-pro-transparency-for-clojure-production-envi
>
> Maybe you've heard of Sayid, a clojure debugger and profiler, that I 
> wrote 
> and then presented at Conj 2016. After my talk, a lot of people asked 
> me if sayid could be used in a production environment. I strongly 
> discouraged that. A month later, I started working on a new tool that 
> brings the same transparency as Sayid, but is designed for use in a 
> production environment. Sayid Pro nows exists as a very rough, but 
> promising, prototype.
>
> If you would like to help me build a tool that will give you insight into 
> your production servers -- far beyond what logs or metrics could ever 
> deliver -- please consider supporting this kickstarter.
>
> thanks,
> Bill
>


-- 
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://gro

Re: Cases of `RT/canSeq`

[Dragan Djuric]

To me it looks like a leftover from some Clojure pre-history where it made 
functional sense.

On Friday, May 19, 2017 at 6:54:32 PM UTC+2, Tianxiang Xiong wrote:
>
> That seems unlikely to be the reason here. ¯\_(ツ)_/¯
>
> As you said, the `null` check should come first if performance is the 
> driving concern. Besides, why check for a subinterface *and* its 
> superinterface only for this case? There are more cases that could be 
> checked.
>
> On Friday, May 19, 2017 at 7:09:00 AM UTC-7, Mikera wrote:
>>
>> One of the things that JVMs can do is create a small cache for the most 
>> recently seen classes in instanceof checks. I believe both OpenJDK and the 
>> Oracle JVM do this.
>>
>> So if you check for both ISeq and Seqable, you may find that you get 
>> twice as many classes cached, and therefore see a performance benefit. Of 
>> course this is implementation dependant so YMMV.
>>
>> On Friday, 19 May 2017 11:28:27 UTC+8, Tianxiang Xiong wrote:
>>>
>>> But if something is `ISeq`, it's `Seqable`, so checking for `Seqable` 
>>> alone should be sufficient. 
>>>
>>> Am I missing something here? Is there a performance performance benefit 
>>> of checking for `ISeq` *and* `Seqable` that I'm not aware of?
>>>
>>> On Wednesday, May 3, 2017 at 2:19:42 AM UTC-7, Mikera wrote:

 Clearly not necessary from a functional perspective.

 However I believe the ordering of these tests will affect JVM 
 optimisations. You want to test the common/fast cases first. And the JVM 
 does some clever things with caching most recently used lookups, which 
 will 
 again behave differently if you test things in different orders.

 Benchmarking on realistic workloads would typically be required to 
 determine the optimal order.

 FWIW I find it odd that the null check is third. This is extremely fast 
 (certainly faster than instance checks) and is a very common case given 
 the 
 amount of nil usage in idiomatic Clojure code (as an empty seq), so I 
 would 
 probably put it first.

 On Wednesday, 3 May 2017 11:59:29 UTC+8, Tianxiang Xiong wrote:
>
> Why does `clojure.lang.RT/canSeq` need to check both `ISeq` _and_ 
> `Seqable` when `ISeq <- IPersistentCollection <- Seqable`?
>
> static public boolean canSeq(Object coll){
> return coll instanceof ISeq
> || coll instanceof Seqable
> || coll == null
> || coll instanceof Iterable
> || coll.getClass().isArray()
> || coll instanceof CharSequence
> || coll instanceof Map;
> }
>
>

-- 
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: slackpocalypse?

['Lee Spector' via Clojure]

FWIW my research group used Slack for a while, but we switched to Discourse 
close to two years ago and have been quite happy with it 
(https://push-language.hampshire.edu, although only a tiny subset is publicly 
viewable). 

We're a much smaller community, with different needs, but still, I can attest 
to Discourse being nice in several ways. Among other things, it seems to 
encourage more deliberative interactions than I generally see on Slack, with a 
better mix of rapid communication with longer-term documentation. 

 -Lee

> On May 19, 2017, at 1:01 PM, Mars0i  wrote:
> 
> I have no opinion, but fwiw the OCaml folks began experimenting with 
> Discourse about a week ago: https://discuss.ocaml.org.
> 
> This isn't really an IRC/Slack style platform, afaics, but the discussions 
> that led up to it included concern about Slack's message limit.  (These 
> discussions can be found on the Google OCaml Aggregation list starting last 
> summer.)

-- 
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: slackpocalypse?

[Gregg Reynolds]

On May 19, 2017 2:11 PM, "'Lee Spector' via Clojure" <
clojure@googlegroups.com> wrote:


FWIW my research group used Slack for a while, but we switched to Discourse
close to two years ago and have been quite happy with it (
https://push-language.hampshire.edu, although only a tiny subset is
publicly viewable).

We're a much smaller community, with different needs, but still, I can
attest to Discourse being nice in several ways. Among other things, it
seems to encourage more deliberative interactions than I generally see on
Slack, with a better mix of rapid communication with longer-term
documentation.


I'm inclined to think moving away from slack would be wise, but only with
the blessing of the core Clojure team.  After all any of us could set up
something on matrix or discourse etc. but if successful that would lead to
fragmentation of the community.

I wonder what the thinking within the core team is on this.

g

-- 
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: slackpocalypse?

[Alex Miller]

On Friday, May 19, 2017 at 2:27:35 PM UTC-5, Gregg Reynolds wrote:
>
>
> I'm inclined to think moving away from slack would be wise, but only with 
> the blessing of the core Clojure team.  After all any of us could set up 
> something on matrix or discourse etc. but if successful that would lead to 
> fragmentation of the community.
>
> I wonder what the thinking within the core team is on this.
>

Our "official" channels for Clojure discussion are the clojure, 
clojurescript, and clojure-dev mailing lists. We moderate and maintain 
these lists.

The Clojure/core team has no involvement with the creation or management of 
the Clojurians Slack channel. The community does not need our blessing to 
set up a discussion forum - we're happy to have more places for Clojure 
folks to talk about Clojure. I'd rather have the community decide what they 
want to do - we (the core team) are not looking to add additional 
moderation/admin duties beyond what we currently do. Perhaps the new group 
that was established under the Software Freedom Conservancy could be of 
assistance in choosing and managing a preferred forum.

I personally monitor (to varying degrees): the mailing lists, Slack, 
#clojure on irc, clojure subreddit, and Twitter and try to answer questions 
in those locations based on my available time to do so.

Alex
 

-- 
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: slackpocalypse?

[Gregg Reynolds]

On May 19, 2017 2:57 PM, "Alex Miller"  wrote:


On Friday, May 19, 2017 at 2:27:35 PM UTC-5, Gregg Reynolds wrote:
>
>
> I'm inclined to think moving away from slack would be wise, but only with
> the blessing of the core Clojure team.  After all any of us could set up
> something on matrix or discourse etc. but if successful that would lead to
> fragmentation of the community.
>
> I wonder what the thinking within the core team is on this.
>

Our "official" channels for Clojure discussion are the clojure,
clojurescript, and clojure-dev mailing lists. We moderate and maintain
these lists.

The Clojure/core team has no involvement with the creation or management of
the Clojurians Slack channel. The community does not need our blessing to
set up a discussion forum - we're happy to have more places for Clojure
folks to talk about Clojure. I'd rather have the community decide what they
want to do - we (the core team) are not looking to add additional
moderation/admin duties beyond what we currently do.


gee, why not?  ;)

Perhaps the new group that was established under the Software Freedom
Conservancy could be of assistance in choosing and managing a preferred
forum.


link?

I don't have time to figger out how to do this correctly at the moment, but
some kind of survey of folks on the various comm. channels seems to be in
order. Some topics, loosely: given what we (think we) know about slack, is
that a prob?  if we wanted to go elsewhere, where would that be?  if we did
go elsewhere, would you, too?  etc.  Volunteers?

moving from slack to sth else would be a big job.


I personally monitor (to varying degrees): the mailing lists, Slack,
#clojure on irc, clojure subreddit, and Twitter and try to answer questions
in those locations based on my available time to do so.


for the record you and your colleagues (including all the volunteers) do an
amazing job!

Alex


-- 
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: In search of the little transducer

[Tianxiang Xiong]

Transducers are *reducing function transformers*. They take a reducing 
function and return another reducing function with some new actions. E.g.

(let [xf ((comp (map inc) (filter even?)))]
  (reduce (xf +) 0 [1 2 3]))

Here, `xf` is the transducer. It takes the reducing function `+` as an 
argument and returns another reducing function that incorporates the `(map 
inc)` and the `(filter even?)` into the `+`. There are some fine details 
about order of composition, but that's the gist of it.

What transducers do is capture the entire logic of *what* to do, while the 
collection (*reducible*) handles *how* to do it (by implementing one of the 
reduce-related interfaces, e.g. `CollReduce`). This is a useful 
decomplection of concerns.

Coincidentally, I was just preparing a presentation on 
reducers/transducers, so here's a big 'ol list of references on transducers:


   - 
   
   Transducers are Coming 
   
   - 
  
  Transducers (Video) 
  - 
  
  Inside Transducers (Video) 
  
  - 
   
   Rich Hickey explaining transducers--in Haskell 
   

   - 
   
   Building ETL pipelines with Clojure and transducers 
   
   

On Friday, May 12, 2017 at 5:47:19 PM UTC-7, tbc++ wrote:
>
> Sure, you can contact me at the address used in this reply :)
>
> Timothy Baldridge
>
> On Fri, May 12, 2017 at 11:19 AM, Erlis Vidal  > wrote:
>
>> Is there a way I can contact Tim Baldridge for questions about the 
>> subscription? 
>>
>> Thanks!
>>
>> On Sun, Jan 31, 2016 at 12:40 PM, Mars0i > > wrote:
>>
>>> Thanks jjttjj, Magomimmo.  I do prefer reading to videos, but I'll 
>>> consider getting Baldridge's series anyway.  Seems worth it.  I don't mind 
>>> paying.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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.

Clojure Discord server

[Luke Burton]

Hi all,

After reading about some of the hassles people had with Slack, I posted earlier 
today in /r/clojure A Discord for Clojurians 
. 

We've had about 50 people pass through the Discord so far. Please drop by and 
see if you like it. To reiterate what I mentioned in the reddit post – this is 
very much an experiment, and a fun one at that. 

I spent a portion of today hacking together a repl-bot that lives in #repl-bot. 
Everything said in that channel will be evaluated in a very non-judgemental 
manner by the repl-bot. Even, as we discovered, System/exit. All part of the 
fun.

We also found that Clojure has full syntax highlighting support in Discord. So 
far, threaded conversations are the major missing feature as compared to Slack. 

Hopefully this little experiment will help the community figure out future 
directions for reliable community collaboration, whatever they may be.

The URL for joining the Discord server: https://discord.gg/v9QMy9D 


Luke.


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