Re: core.async top use cases

2016-09-19 Thread Ken Restivo 
On Sat, Sep 17, 2016 at 11:37:38PM -0700, Matan Safriel wrote:
> Hi,
> 
> It's very easy to see how core.async solves callback hell for front-end 
> development with clojurescript.
> In what use cases would you use it for server-side? we already have 
> non-blocking IO from Java, and we have clojure agents. So what's a bunch of 
> salient use cases?
> Are there prominent clojure http server implementations which rely on it 
> for transcending the threaded web service paradigm?
> 

Decoupling components within a system, similar to what one would use queues or 
a messaging architecture for.

Used it extensively in two projects (one open source, one for a client) some 
years ago.

Rather than coupling the components via namespace dependencies and a call API, 
I just had the components passing data via async channels (queues), including 
pub/sub and topic subscription.

Worked great for its intended purpose.

-ken

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

Re: Clojure support for Visual Studio Code

2016-09-19 Thread Ikuru Kanuma 
Thanks for the tips, Andry & Michael!

Will investigate the rabbit hole deeper when I have time (Tried you 
suggestion but no success...),
but thanks Andrey for releasing it into the market place because now
I can try it out in the mean while.

Cheers,

-- 
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 Monger 3.1.0 is released

2016-09-19 Thread Michael Klishin 
Monger [1] is a Clojure MongoDB driver for a more civilized age.

Release notes:
http://blog.clojurewerkz.org/blog/2016/09/18/monger-3-dot-1-0-is-released/

1. http://clojuremongodb.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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: core.async top use cases

2016-09-19 Thread William la Forge 
The really nice thing to me is that async handles side-effects while agents 
do not.

-- 
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: core.async top use cases

2016-09-19 Thread Matan Safriel 
Right!

 Original Message 
From:Leon Grapenthin 
Sent:Mon, 19 Sep 2016 20:19:55 +0300
To:Clojure 
Subject:Re: core.async top use cases

>It is not just convenience. For example agents don't provide functionality 
>like buffering, backpressure and select aka alts. If you send an action to an 
>agent you don't get to know when it's done or to choose what to do if it is 
>currently busy. 
>
>On Monday, September 19, 2016 at 11:49:13 AM UTC+2, Matan Safriel wrote:
>
>Thanks, and I put the blog post on my reading list. 
>
>Although I can't avoid thinking that we already have asynchronous idioms in 
>the core language itself, like agents. I think the crux for server-side is 
>more about the convenient piping, rather than the mere asynchronism itself, 
>but I might be wrong in any of this.
>
>
>On Mon, Sep 19, 2016 at 9:14 AM, Mond Ray  wrote:
>
>Pushing asynchrony further into the stack is useful for reliability and fault 
>tolerance. We can also use it as a basis for Complex Event Processing using 
>time series windows. 
>
>
>I wrote up a few examples in my blog if you have the time to check out a 
>longer explanation with code.
>
>
>I recently wrote a small set of functions to enable HTML5 Server Sent Events 
>from any Kafka topic which also uses core.async (with an example using Aleph 
>and Compojure). You might like to check that repo out too.
>
>
>Ray
>
>
>On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote:
>
>Hi,
>
>
>It's very easy to see how core.async solves callback hell for front-end 
>development with clojurescript.
>
>In what use cases would you use it for server-side? we already have 
>non-blocking IO from Java, and we have clojure agents. So what's a bunch of 
>salient use cases?
>
>Are there prominent clojure http server implementations which rely on it for 
>transcending the threaded web service paradigm?
>
>
>Thanks,
>
>Matan
>
>
>-- 
>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 a topic in the Google 
>Groups "Clojure" group.
>To unsubscribe from this topic, visit 
>https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to 
>clojure+u...@googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.
>
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "Clojure" group.
>To post to this group, send email to clojure@googlegroups.com
>Note that posts from new members are moderated - please be patient with your 
>first post.
>To unsubscribe from this group, send email to
>clojure+unsubscr...@googlegroups.com
>For more options, visit this group at
>http://groups.google.com/group/clojure?hl=en
>--- 
>You received this message because you are subscribed to a topic in the Google 
>Groups "Clojure" group.
>To unsubscribe from this topic, visit 
>https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to 
>clojure+unsubscr...@googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

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

Re: Clojure support for Visual Studio Code

2016-09-19 Thread Michael Ball 

>
> On Saturday, September 17, 2016 at 4:32:39 AM UTC+6, Michael Ball wrote:
>>
>>
>> - Explicit docs/instructions on how to start and connect to the repl 
>> would be good. I was able to get it connected but it was unclear if the 
>> repl should be started from within VS code, or from a terminal then only 
>> connect to it from VS code.
>>
>
> The instructions can be found in the "How to Use?" section of readme file. 
> Not sure I understand your point about where the repl should be started. Do 
> you mean you mean you expected repl will be run by VSCode on connect like 
> it happens in Emacs?
>

Yes, in LightTable and Cider generally the repl is started up from within 
the editor, and it was unclear if there was an editor action that would do 
this, or if the repl needed to be started in a terminal, then connected to.



- Docstrings don't seem to work for thread first  (-> xxx)? I also noticed 
>> that it took some time after initial repl connect for the docstrings to 
>> become available, probably some indexing delay because my laptop is 
>> old+slow, initially they showed "Docstring not found". Also the docstring 
>> not found message pops up for all characters on hover of mouse over things 
>> such as parenthesis.
>>
>
> You're right about the thread first docstring. It looks like I need to 
> adjust the regex for finding Clojure words. Will fix it soon.
>
> About docstrings. There shouldn't be snoticable time between pointing a 
> thing and getting its documentation. However, the is a subtly aspect you 
> should be aware of. If you have a namespace definition in the beginning of 
> a file you should eval the file first. Say, you have a file with the 
> following content:
>
> (ns foo)
>
> (println "Hello World")
>
>  When you point println you won't see the docstring. The reason is the 
> extension sends the following message to the repl: "Give me a docstring for 
> the function println from foo namespace." But at the moment repl *know 
> nothing *about foo namespace! So you neen to eval the file. This will 
> result adding foo namespace to the repl and importing everything from 
> clojure.core namespace to it (this is a sideeffect of ns macro). I believe, 
> this is the common behaviour for all solutions based on cider-nrepl (I've 
> checked it is true for Emacs Cider and Vim Fireplace). Though I admit it's 
> not the most intuitive one. So I'm open to suggestions.
>

Ah, you're probably right on the eval. Also was thinking that perhaps 
doc-string could/should be shown on a keystroke instead of mouse-over?


 

> - If I had one feature request it would be for inline results a-la 
>> LightTable. Any plans for something like that?
>>
>
> It's definetly a useful feature and I can add it easily. The only thing 
> I'm not sure about is where to show an evaluation result :) Do you have any 
> ideas. Maybe you've seen the similar feature in other VSCode plugins and 
> know how to do it right?
>

I don't know if there's a really good way to do it right now, but in some 
very timely news just this morning a feature got some attention and we 
hopefully should see it in October. Probably should watch this issue and 
then use whatever they come up with. You could comment on that issue with 
your use case as jrieken requested.

https://github.com/Microsoft/vscode/issues/3220#issuecomment-248040912


You might also have look at LightTable(my personal favorite for inline 
results), and atom proto-repl for ideas on how to add inline results. In 
proto-repl, I have to admit for larger data-structures, the expandable 
data-structure inspector looks pretty nice. 
https://atom.io/packages/proto-repl

-- 
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: core.async top use cases

2016-09-19 Thread Leon Grapenthin 
It is not just convenience. For example agents don't provide functionality 
like buffering, backpressure and select aka alts. If you send an action to 
an agent you don't get to know when it's done or to choose what to do if it 
is currently busy. 

On Monday, September 19, 2016 at 11:49:13 AM UTC+2, Matan Safriel wrote:
>
> Thanks, and I put the blog post on my reading list. 
> Although I can't avoid thinking that we already have asynchronous idioms 
> in the core language itself, like agents. I think the crux for server-side 
> is more about the convenient piping, rather than the mere asynchronism 
> itself, but I might be wrong in any of this.
>
> On Mon, Sep 19, 2016 at 9:14 AM, Mond Ray  > wrote:
>
>> Pushing asynchrony further into the stack is useful for reliability and 
>> fault tolerance. We can also use it as a basis for Complex Event Processing 
>> using time series windows. 
>>
>> I wrote up a few examples in my blog 
>> 
>>  
>> if you have the time to check out a longer explanation with code.
>>
>> I recently wrote a small set of functions to enable HTML5 Server Sent 
>> Events from any Kafka topic which also uses core.async (with an example 
>> using Aleph and Compojure). You might like to check that repo 
>>  out too.
>>
>> Ray
>>
>> On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote:
>>>
>>> Hi,
>>>
>>> It's very easy to see how core.async solves callback hell for front-end 
>>> development with clojurescript.
>>> In what use cases would you use it for server-side? we already have 
>>> non-blocking IO from Java, and we have clojure agents. So what's a bunch of 
>>> salient use cases?
>>> Are there prominent clojure http server implementations which rely on it 
>>> for transcending the threaded web service paradigm?
>>>
>>> Thanks,
>>> Matan
>>>
>>> -- 
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Reader macro not ignoring form?

2016-09-19 Thread craig worrall 
Many thanks Alex.

Craig



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

Re: Clojure support for Visual Studio Code

2016-09-19 Thread Andrey Lisin 
Uploaded the extension to the Visual Studio Code marketplace. Now you can 
install using VSCode 'Extensions' menu.

-- 
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: core.async top use cases

2016-09-19 Thread Matan Safriel 
Thanks, and I put the blog post on my reading list.
Although I can't avoid thinking that we already have asynchronous idioms in
the core language itself, like agents. I think the crux for server-side is
more about the convenient piping, rather than the mere asynchronism itself,
but I might be wrong in any of this.

On Mon, Sep 19, 2016 at 9:14 AM, Mond Ray  wrote:

> Pushing asynchrony further into the stack is useful for reliability and
> fault tolerance. We can also use it as a basis for Complex Event Processing
> using time series windows.
>
> I wrote up a few examples in my blog
> 
> if you have the time to check out a longer explanation with code.
>
> I recently wrote a small set of functions to enable HTML5 Server Sent
> Events from any Kafka topic which also uses core.async (with an example
> using Aleph and Compojure). You might like to check that repo
>  out too.
>
> Ray
>
> On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote:
>>
>> Hi,
>>
>> It's very easy to see how core.async solves callback hell for front-end
>> development with clojurescript.
>> In what use cases would you use it for server-side? we already have
>> non-blocking IO from Java, and we have clojure agents. So what's a bunch of
>> salient use cases?
>> Are there prominent clojure http server implementations which rely on it
>> for transcending the threaded web service paradigm?
>>
>> Thanks,
>> Matan
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/peJXvE0nBZs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: core.async top use cases

2016-09-19 Thread Mond Ray 
Pushing asynchrony further into the stack is useful for reliability and 
fault tolerance. We can also use it as a basis for Complex Event Processing 
using time series windows. 

I wrote up a few examples in my blog 

 
if you have the time to check out a longer explanation with code.

I recently wrote a small set of functions to enable HTML5 Server Sent 
Events from any Kafka topic which also uses core.async (with an example 
using Aleph and Compojure). You might like to check that repo 
 out too.

Ray

On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote:
>
> Hi,
>
> It's very easy to see how core.async solves callback hell for front-end 
> development with clojurescript.
> In what use cases would you use it for server-side? we already have 
> non-blocking IO from Java, and we have clojure agents. So what's a bunch of 
> salient use cases?
> Are there prominent clojure http server implementations which rely on it 
> for transcending the threaded web service paradigm?
>
> Thanks,
> Matan
>
>

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