Re: [ANN] async-sockets - work with sockets using core.async channels

[Max Penet]

This is something that should be configurable & extendable in core.async 
really... but given how long it took to have this possibility with agents I 
am not holding my breath (not to mention it was never even considered for 
c.c/future).

On Tuesday, October 7, 2014 8:48:23 PM UTC+2, Brian Guthrie wrote:
>
>
> On Sun, Oct 5, 2014 at 11:57 PM, Zach Tellman  > wrote:
>
>> If I'm reading this correctly, you're using non-blocking thread pools for 
>> blocking operations on the sockets.  Given more than N connections (last 
>> time I looked the thread pool's size was 42), you risk deadlock or at the 
>> very least poor average throughput.
>
>
> I'd thought the thread pool's size was a function of your core count plus 
> some constant, which I believe is 42. But yes, that is a constraint, and 
> deadlock is a risk with too many concurrent connections. I haven't tried to 
> measure throughput yet but that seems like a reasonable next step. Thanks 
> for the code review!
>

-- 
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] async-sockets - work with sockets using core.async channels

[Jozef Wagner]

One way how to handle this elegantly in Java is to add support for
java.nio.channels.SelectableChannel in core.async buffer. That way you
could select on any combination of core.async channels and io
resources, waiting for core.async channels to free and resources to
have data ready.

Jozef

On Wed, Oct 8, 2014 at 8:00 AM, Zach Tellman  wrote:
> The reason the thread-per-connection approach is nice is because it
> correctly propagates backpressure.  If we're copying data from a source to a
> sink (let's say reading it in from the network and writing to a file), it's
> possible that the production of data may outstrip the consumption.  If this
> happens, we need to make sure the producer slows down, or we risk running
> out of memory.  In Java, the producer is typically connected to the consumer
> via a blocking queue, and if the queue fills up the producer can't send
> anything more to the consumer.  A Java socket is one such queue, and if it
> fills up it will exert backpressure via TCP.  This will work no matter how
> many queues or other mechanisms separate the producer and consumer.
>
> However, every attempt I've seen to marry core.async to an async network
> stack has been fundamentally broken, in that it doesn't do this.  Often,
> they'll just use 'put!', which works fine until the channel's queue fills
> up, and 1024 pending puts are accumulated, and finally the channel throws an
> exception.  Alternately, they'll use a blocking put on the channel, which
> means that any backpressure will also extend to whatever other connections
> are sharing that thread or the thread pool.  Note that the software that
> uses core.async in this way may work flawlessly in a wide variety of cases,
> but there's still an intractable failure mode lying in wait.
>
> In some cases, such as http-kit's websocket mechanism, there's no way to
> even exert backpressure (you register a callback, and have no way to
> indicate in your callback that you can't handle more messages).  This means
> that any attempt to use http-kit in conjunction with core.async will be
> subtly but fundamentally broken.  Arguably, even without core.async in the
> equation it's broken.  This is not a good state of affairs.  I'll admit that
> it took me a few failures in production to realize how important correct
> handling of backpressure is, but this isn't something that our ecosystem can
> afford to ignore, especially as Clojure is used for larger-scale projects.
>
> I will note that I am working on a solution to this, in the form of the
> upcoming Aleph release [1].  This will model every network connection via
> streams that can trivially be converted into core.async channels [2], and
> which exert backpressure over TCP wherever necessary without requiring a
> thread per connection.  A formal beta should be available in the near future
> (it's already handling billions of requests a day in production without
> issue).
>
> Zach
>
> [1] https://github.com/ztellman/aleph/tree/0.4.0
> [2] https://github.com/ztellman/manifold
>
>
>
> On Tuesday, October 7, 2014 1:36:16 PM UTC-7, adrian...@mail.yu.edu wrote:
>>
>> It's not about 'safety' (depending on what that means in this context),
>> but as Zach pointed out, if you aren't careful about backpressure you can
>> run into performance bottlenecks with unrestrained async IO operations
>> because although they let you code as if you could handle an unlimited
>> amount of connections, obviously that isn't true. There is only a finite
>> amount of data that can be buffered in and out of any network according to
>> its hardware. When you don't regulate that, your system will end up spending
>> an inordinate amount of time compensating for this. You don't need to worry
>> about this with "regular io" because the "thread per connection" abstraction
>> effectively bounds your activity within the acceptable physical constraints
>> of the server.
>>
>> On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote:
>>>
>>>
>>> On Mon, Oct 6, 2014 at 12:10 AM,  wrote:

 Zach makes an excellent point; I've used AsyncSocketChannels and its irk
 (http://docs.oracle.com/javase/8/docs/api/java/nio/channels/AsynchronousServerSocketChannel.html),
 with core.async in the past. Perhaps replacing your direct java.net.Sockets
 with nio classes that can be given CompletionHandlers
 (http://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html)
 would be a better fit.
>>>
>>>
>>> Once I do some performance instrumentation I'll give that a shot. I admit
>>> that I'm not familiar with all the implications of using the nio classes;
>>> were I to switch, is it safe to continue using go blocks, or is it worth
>>> explicitly allocating a single thread per socket?
>>>
>>> Brian
>
> --
> 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 m

Re: com.stuartsierra/component & ring/compojure example

[Daniel Szmulewicz]

1, Extract the app out of the Webserver record into its own var. 
2, Add to the Webserver record an additional argument called handler. 
2, Put the component in a separate namespace. 
3, Initialize your component with the app var. 

OR, use system, which does all of the above for you. 
https://github.com/danielsz/system/ 


I'll post an example application in the repo if people are interested.  

On Wednesday, October 8, 2014 8:42:14 AM UTC+3, Andrew Meredith wrote:
>
> This is not a full example, but I ran into the same issue when building an 
> app for the Clojure Cup not too long ago. The general approach I used is 
> this:
>
>- create the Compojure routes in a function with the components I need 
>as parameters
>- declare the web server itself (I used httpkit) as a component with 
>the dependencies needed for the routes
>- build a handler from the routes within the web server component's 
>start function, passing the dependencies into the route-generating function
>
> I'm no Clojure expert, and this was my first project using Stuart Sierra's 
> Component library, so I would be interested to hear some feedback from the 
> more seasoned Clojure folks here.
>
> Here is the relevant file from my project if you are interested: 
> https://github.com/kendru/tourbillon/blob/master/src/tourbillon/www/core.clj#L67
>
> On Tuesday, October 7, 2014 11:33:33 AM UTC, JPatrick Davenport wrote:
>>
>> Hello,
>> I'm trying to create a web app. I'm having the damnest time trying to 
>> figure out how to layer my application. I want to pass protocol 
>> implementations to the routes. The protocols define interacting with 
>> various data sources that I need down the way. 
>>
>> I saw Stuart Sierra's talk about Component. It looks to satisfy my needs. 
>> What I can't find is an example project for component and compojure. 
>> Unfortunately the project com.stuartsierra/component is poorly named. 
>> Googling for component + compojure brings back mostly false positives.
>>
>> Does anyone have a gist or blog post about how to do this?
>>
>> Thanks,
>> JPD
>>
>

-- 
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: com.stuartsierra/component & ring/compojure example

[Daniel Szmulewicz]

I posted a working example in the system repo: 

https://github.com/danielsz/system/tree/master/example

On Tuesday, October 7, 2014 2:33:33 PM UTC+3, JPatrick Davenport wrote:
>
> Hello,
> I'm trying to create a web app. I'm having the damnest time trying to 
> figure out how to layer my application. I want to pass protocol 
> implementations to the routes. The protocols define interacting with 
> various data sources that I need down the way. 
>
> I saw Stuart Sierra's talk about Component. It looks to satisfy my needs. 
> What I can't find is an example project for component and compojure. 
> Unfortunately the project com.stuartsierra/component is poorly named. 
> Googling for component + compojure brings back mostly false positives.
>
> Does anyone have a gist or blog post about how to do this?
>
> Thanks,
> JPD
>

-- 
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] Example project to illustrate usage of system library

[Daniel Szmulewicz]

Hello everybody, 

I noticed a demand for examples in how to put together a web app with the 
reloaded approach (Stuart Sierra's components). 

For this reason, I've published an example project in the system library. 

https://github.com/danielsz/system/tree/master/example

Enjoy.

Please let me know if you have comments/suggestions/etc. 

-- 
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: Advice for building backend REST services from scratch using clojure

[Daniel Szmulewicz]

I felt the Austin pain. Then I discovered figwheel. In one fell swoop, it 
solved all aforementioned problems.
Live coding with Emacs has never been more joyful.

https://github.com/bhauman/lein-figwheel

On Tuesday, October 7, 2014 7:21:19 PM UTC+3, g vim wrote:
>
> On 11/04/2014 09:17, Colin Yates wrote: 
> >   * you can fight it as hard as you like but you will eventually end up 
> > using emacs, clojure-mode, cider, paredit and magit and then wonder 
> > how you ever lived without it, but not without spending at least a 
> > month or two cursing anything to do with emacs :). 
> > 
>
> Whilst I love Emacs, clojure-mode & cider for working with Clojure I 
> wasted far too much time trying to get a Clojurescript browser repl 
> working with cider. Tried Weasel but it didn't seem to be keeping up 
> with Clojurescript releases or else it was some other mysterious bug. 
> Austin seemed to require far too much boilerplate addition to get 
> anything working so I eventually resorted to Lighttable which has smooth 
> interaction with a browser repl in Chrome. 
>
> Until the whole lein/cider/Clojurescript/browser repl toolchain settles 
> into something stable I would caution anyone trumpeting the advantages 
> of Emacs. For Clojurescript the current state of play seems to favour 
> Lighttable and Cursive. 
>
> gvim 
>
>

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

Issue with log4j inside lein plugin.

[Max Gonzih]

Hello guys,

I'm trying to create small lein plugin 
(https://github.com/Gonzih/lein-feeds2imap/blob/master/src/leiningen/feeds2imap.clj)
 
that should use library underneath that uses log4j via 
clojure.tools.logging. But I don't see logging output when I call plugin. I 
tried to configure it in many different ways (properties, 
System/setProperty, log4j properties) without much result. Is this 
something related to leiningein or am I doing something wrong?

Any advice is welcome, 
Thanks!

-- 
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] async-sockets - work with sockets using core.async channels

[adrian . medina]

Check out https://github.com/halgari/com.tbaldridge.hermod for an 
interesting take on this. 

On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:
>
>  BTW, is there any network based core.async channel available now?
>
> On 10/08/2014 04:36 AM, adrian...@mail.yu.edu  wrote:
>  
>  It's not about 'safety' (depending on what that means in this context), 
> but as Zach pointed out, if you aren't careful about backpressure you can 
> run into performance bottlenecks with unrestrained async IO operations 
> because although they let you code as if you could handle an unlimited 
> amount of connections, obviously that isn't true. There is only a finite 
> amount of data that can be buffered in and out of any network according to 
> its hardware. When you don't regulate that, your system will end up 
> spending an inordinate amount of time compensating for this. You don't need 
> to worry about this with "regular io" because the "thread per connection" 
> abstraction effectively bounds your activity within the acceptable physical 
> constraints of the server. 
>
> On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote: 
>>
>>  
>> On Mon, Oct 6, 2014 at 12:10 AM,  wrote:
>>
>>> Zach makes an excellent point; I've used AsyncSocketChannels and its irk 
>>> (
>>> http://docs.oracle.com/javase/8/docs/api/java/nio/channels/AsynchronousServerSocketChannel.html),
>>>  
>>> with core.async in the past. Perhaps replacing your direct java.net.Sockets 
>>> with nio classes that can be given CompletionHandlers (
>>> http://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html)
>>>  
>>> would be a better fit. 
>>>
>>  
>> Once I do some performance instrumentation I'll give that a shot. I admit 
>> that I'm not familiar with all the implications of using the nio classes; 
>> were I to switch, is it safe to continue using go blocks, or is it worth 
>> explicitly allocating a single thread per socket?
>>
>>  Brian
>>  
>  -- 
> 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 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] async-sockets - work with sockets using core.async channels

[Zach Tellman]

I wasn't aware of hermod, that's interesting.  I would still characterize
its approach to backpressure as "broken", though, since when the queues get
full it silently drops messages on the ground.  In fairness, this is very
clearly documented, so it's less pernicious than some of the other cases
out there.

Both core.async buffers and SelectableChannels have very particular
semantics, and I would be very surprised if they could be combined in that
way.  It's perfectly possible to feed one into the other and handle
backpressure properly (again, I'm doing just that with Aleph 0.4.0, using
Netty), but it's a nuanced integration and easy to get wrong.

On Wed, Oct 8, 2014 at 7:12 AM,  wrote:

> Check out https://github.com/halgari/com.tbaldridge.hermod for an
> interesting take on this.
>
> On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:
>>
>>  BTW, is there any network based core.async channel available now?
>>
>> On 10/08/2014 04:36 AM, adrian...@mail.yu.edu wrote:
>>
>>  It's not about 'safety' (depending on what that means in this context),
>> but as Zach pointed out, if you aren't careful about backpressure you can
>> run into performance bottlenecks with unrestrained async IO operations
>> because although they let you code as if you could handle an unlimited
>> amount of connections, obviously that isn't true. There is only a finite
>> amount of data that can be buffered in and out of any network according to
>> its hardware. When you don't regulate that, your system will end up
>> spending an inordinate amount of time compensating for this. You don't need
>> to worry about this with "regular io" because the "thread per connection"
>> abstraction effectively bounds your activity within the acceptable physical
>> constraints of the server.
>>
>> On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote:
>>>
>>>
>>> On Mon, Oct 6, 2014 at 12:10 AM,  wrote:
>>>
 Zach makes an excellent point; I've used AsyncSocketChannels and its
 irk (http://docs.oracle.com/javase/8/docs/api/java/nio/channels/
 AsynchronousServerSocketChannel.html), with core.async in the past.
 Perhaps replacing your direct java.net.Sockets with nio classes that can be
 given CompletionHandlers (http://docs.oracle.com/
 javase/7/docs/api/java/nio/channels/CompletionHandler.html) would be a
 better fit.

>>>
>>> Once I do some performance instrumentation I'll give that a shot. I
>>> admit that I'm not familiar with all the implications of using the nio
>>> classes; were I to switch, is it safe to continue using go blocks, or is it
>>> worth explicitly allocating a single thread per socket?
>>>
>>>  Brian
>>>
>>  --
>> 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 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/TVMQJwaij1U/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: [ANN] Clojure instaREPL for web

[Dylan Butman]

Very nice! looks like there are some css issues with output display for 
example, (map inc [1 2 3 4]) doesn't output on a single line, and seems to 
shift a little bit from time to time.

With a little more polishing this could be fantastic teaching tool for 
intro to clojure workshops and tutorials. Lighttable has been my goto for 
this in the past, and is still a more robust solution for larger project 
workshops, but having an immediate way to get code working is fantastic.

How about a gist integration? It'd be absolutely wonderful if you could 
permalink to a instarepl that pulls code from a gist and then just start 
evaluating.

On Tuesday, October 7, 2014 3:00:08 PM UTC-4, Lauri Hartikka wrote:
>
> A web based clojure instaREPL,
>
> Check it out :)
>
> http://clojurerepl.com
>
>
>

-- 
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] rmap - define lazy, recursive maps

[Zach Tellman]

Hi Arnout,

This is interesting, but may be a lot less useful than you think without 
filling in all the other methods that a normal map has.  For instance, you 
cannot do an equality check with another map (no use of 
clojure.lang.MapEquivalence or implementation of equals and equiv), nor use 
it in a set or key in another map (no implementation of hashCode and 
hasheq), etc. etc.  Unless you and everyone else using it is certain that 
every line of code in your application and the libraries you depend on 
don't do this, this is a ticking timebomb.

For an example of a full map implementation, it might be helpful to take a 
look at 
https://github.com/ztellman/potemkin/blob/master/src/potemkin/collections.clj, 
and will definitely be useful to 
run https://github.com/ztellman/collection-check against your map 
implementation.  One issue that collection-check would uncover is the fact 
that the underlying LinkedHashMap that you're using has different key 
equality semantics than Clojure does, so calling (-> m (assoc 1 :foo) 
(dissoc 1N)) would likely break a bunch of stuff.  

Please don't be discouraged by this, making custom map-like data structures 
is much harder right now than it should be.  I just want to make sure no 
one gets an unpleasant surprise in production somewhere down the line.

Best,
Zach

On Monday, October 6, 2014 1:45:02 AM UTC-7, Arnout Roemers wrote:
>
> Thank you for your kind responses! I will look into writing a post that 
> shows what the motivation was (i.e. how I use it), how it works, and how it 
> compares to Prismatic's Graph. 
>
> Cheers,
> Arnout
>

-- 
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: Evaluation order

[Johannes Langøy]

Thanks!

kl. 02:17:45 UTC+2 onsdag 8. oktober 2014 skrev adrian...@mail.yu.edu 
følgende:
>
> *output
>
> On Tuesday, October 7, 2014 8:17:34 PM UTC-4, adrian...@mail.yu.edu wrote:
>>
>> You need to flush the input stream after printing. Call 
>> (clojure.core/flush) to do so.
>>
>> On Tuesday, October 7, 2014 4:51:05 PM UTC-4, Johannes Langøy wrote:
>>>
>>> Hi, I can't figure this out.  I have these two functions:
>>>
>>> (defn get-number []
>>>   (try (let [input (read-string (read-line))]
>>>  (if (number? input)
>>>input
>>>(get-number)))
>>>(catch Exception e (get-number
>>>
>>> (defn selection-handler [tests]
>>>   (dotimes [i (count tests)]
>>> (printf "(%s) %s: %s\n"
>>> (inc i)
>>> (first (nth tests i))
>>> (or (second (nth tests i))
>>> "--")))
>>>   (loop [input (dec (get-number))]
>>> (if ((set (range (count tests))) input)
>>>   (nth tests input)
>>>   (recur (dec (get-number))
>>>
>>> Now, the problem is that when I run selection-handler, the dotimes 
>>> output isn't printed until (get-number) has returned. Why is this?
>>>
>>

-- 
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] async-sockets - work with sockets using core.async channels

[Jozef Wagner]

If you want to handle multiple TCP connections and async channels in one 
thread, you need a way how to block on both connections (wait for new input 
to arrive) and channels (wait for a free space in a buffer). Blocking only 
on connections will get you a busy loop if channels are full. If you could 
point me to the part of Aleph sources that handles this issue, I would be 
very grateful. I'm not familiar with netty API nor manifold's concepts, so 
I'm having trouble navigating in the Aleph sources.

Thanks,
Jozef

On Wednesday, October 8, 2014 6:15:47 PM UTC+2, Zach Tellman wrote:
>
> I wasn't aware of hermod, that's interesting.  I would still characterize 
> its approach to backpressure as "broken", though, since when the queues get 
> full it silently drops messages on the ground.  In fairness, this is very 
> clearly documented, so it's less pernicious than some of the other cases 
> out there.
>
> Both core.async buffers and SelectableChannels have very particular 
> semantics, and I would be very surprised if they could be combined in that 
> way.  It's perfectly possible to feed one into the other and handle 
> backpressure properly (again, I'm doing just that with Aleph 0.4.0, using 
> Netty), but it's a nuanced integration and easy to get wrong.
>
> On Wed, Oct 8, 2014 at 7:12 AM, > 
> wrote:
>
>> Check out https://github.com/halgari/com.tbaldridge.hermod for an 
>> interesting take on this. 
>>
>> On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:
>>>
>>>  BTW, is there any network based core.async channel available now?
>>>
>>> On 10/08/2014 04:36 AM, adrian...@mail.yu.edu wrote:
>>>  
>>>  It's not about 'safety' (depending on what that means in this 
>>> context), but as Zach pointed out, if you aren't careful about backpressure 
>>> you can run into performance bottlenecks with unrestrained async IO 
>>> operations because although they let you code as if you could handle an 
>>> unlimited amount of connections, obviously that isn't true. There is only a 
>>> finite amount of data that can be buffered in and out of any network 
>>> according to its hardware. When you don't regulate that, your system will 
>>> end up spending an inordinate amount of time compensating for this. You 
>>> don't need to worry about this with "regular io" because the "thread per 
>>> connection" abstraction effectively bounds your activity within the 
>>> acceptable physical constraints of the server. 
>>>
>>> On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote: 

  
 On Mon, Oct 6, 2014 at 12:10 AM,  wrote:

> Zach makes an excellent point; I've used AsyncSocketChannels and its 
> irk (http://docs.oracle.com/javase/8/docs/api/java/nio/channels/
> AsynchronousServerSocketChannel.html), with core.async in the past. 
> Perhaps replacing your direct java.net.Sockets with nio classes that can 
> be 
> given CompletionHandlers (http://docs.oracle.com/
> javase/7/docs/api/java/nio/channels/CompletionHandler.html) would be 
> a better fit. 
>
  
 Once I do some performance instrumentation I'll give that a shot. I 
 admit that I'm not familiar with all the implications of using the nio 
 classes; were I to switch, is it safe to continue using go blocks, or is 
 it 
 worth explicitly allocating a single thread per socket?

  Brian
  
>>>  -- 
>>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/TVMQJwaij1U/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.
>>
>
>

-- 
Y

Re: Evaluation order

[Johannes Langøy]

Here is the finished Yatzy, in case anyone is interested:
https://github.com/Jovlang/catzy/blob/master/src/catzy/core.clj

kl. 19:05:50 UTC+2 onsdag 8. oktober 2014 skrev Johannes Langøy følgende:
>
> Thanks!
>
> kl. 02:17:45 UTC+2 onsdag 8. oktober 2014 skrev adrian...@mail.yu.edu 
> følgende:
>>
>> *output
>>
>> On Tuesday, October 7, 2014 8:17:34 PM UTC-4, adrian...@mail.yu.edu 
>> wrote:
>>>
>>> You need to flush the input stream after printing. Call 
>>> (clojure.core/flush) to do so.
>>>
>>> On Tuesday, October 7, 2014 4:51:05 PM UTC-4, Johannes Langøy wrote:

 Hi, I can't figure this out.  I have these two functions:

 (defn get-number []
   (try (let [input (read-string (read-line))]
  (if (number? input)
input
(get-number)))
(catch Exception e (get-number

 (defn selection-handler [tests]
   (dotimes [i (count tests)]
 (printf "(%s) %s: %s\n"
 (inc i)
 (first (nth tests i))
 (or (second (nth tests i))
 "--")))
   (loop [input (dec (get-number))]
 (if ((set (range (count tests))) input)
   (nth tests input)
   (recur (dec (get-number))

 Now, the problem is that when I run selection-handler, the dotimes 
 output isn't printed until (get-number) has returned. Why is this?

>>>

-- 
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] async-sockets - work with sockets using core.async channels

[Zach Tellman]

The documentation for Manifold can explain the API better than I can here.
The point where that interacts with Netty w.r.t. backpressure is here:
https://github.com/ztellman/aleph/blob/0.4.0/src/aleph/netty.clj#L109.
Here the stream represents data coming off the wire, and if the put onto
the stream is not immediately successful, backpressure is enabled until the
put completes.  No blocking required anywhere.

On Wed, Oct 8, 2014 at 10:10 AM, Jozef Wagner 
wrote:

> If you want to handle multiple TCP connections and async channels in one
> thread, you need a way how to block on both connections (wait for new input
> to arrive) and channels (wait for a free space in a buffer). Blocking only
> on connections will get you a busy loop if channels are full. If you could
> point me to the part of Aleph sources that handles this issue, I would be
> very grateful. I'm not familiar with netty API nor manifold's concepts, so
> I'm having trouble navigating in the Aleph sources.
>
> Thanks,
> Jozef
>
> On Wednesday, October 8, 2014 6:15:47 PM UTC+2, Zach Tellman wrote:
>>
>> I wasn't aware of hermod, that's interesting.  I would still characterize
>> its approach to backpressure as "broken", though, since when the queues get
>> full it silently drops messages on the ground.  In fairness, this is very
>> clearly documented, so it's less pernicious than some of the other cases
>> out there.
>>
>> Both core.async buffers and SelectableChannels have very particular
>> semantics, and I would be very surprised if they could be combined in that
>> way.  It's perfectly possible to feed one into the other and handle
>> backpressure properly (again, I'm doing just that with Aleph 0.4.0, using
>> Netty), but it's a nuanced integration and easy to get wrong.
>>
>> On Wed, Oct 8, 2014 at 7:12 AM,  wrote:
>>
>>> Check out https://github.com/halgari/com.tbaldridge.hermod for an
>>> interesting take on this.
>>>
>>> On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:

  BTW, is there any network based core.async channel available now?

 On 10/08/2014 04:36 AM, adrian...@mail.yu.edu wrote:

  It's not about 'safety' (depending on what that means in this
 context), but as Zach pointed out, if you aren't careful about backpressure
 you can run into performance bottlenecks with unrestrained async IO
 operations because although they let you code as if you could handle an
 unlimited amount of connections, obviously that isn't true. There is only a
 finite amount of data that can be buffered in and out of any network
 according to its hardware. When you don't regulate that, your system will
 end up spending an inordinate amount of time compensating for this. You
 don't need to worry about this with "regular io" because the "thread per
 connection" abstraction effectively bounds your activity within the
 acceptable physical constraints of the server.

 On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote:
>
>
> On Mon, Oct 6, 2014 at 12:10 AM,  wrote:
>
>> Zach makes an excellent point; I've used AsyncSocketChannels and its
>> irk (http://docs.oracle.com/javase/8/docs/api/java/nio/channels/
>> AsynchronousServerSocketChannel.html), with core.async in the past.
>> Perhaps replacing your direct java.net.Sockets with nio classes that can 
>> be
>> given CompletionHandlers (http://docs.oracle.com/javase
>> /7/docs/api/java/nio/channels/CompletionHandler.html) would be a
>> better fit.
>>
>
> Once I do some performance instrumentation I'll give that a shot. I
> admit that I'm not familiar with all the implications of using the nio
> classes; were I to switch, is it safe to continue using go blocks, or is 
> it
> worth explicitly allocating a single thread per socket?
>
>  Brian
>
  --
 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...@goo

Re: [ANN] async-sockets - work with sockets using core.async channels

[Zach Tellman]

Sorry, didn't cover converse case.  That's handled by the ChannelSink
directly underneath.  Note that each write returns a Netty ChannelFuture
representing completion of the write, which is transformed into a Manifold
deferred.  Any time a Manifold put returns an unrealized deferred, that
creates upstream backpressure.

On Wed, Oct 8, 2014 at 10:16 AM, Zach Tellman  wrote:

> The documentation for Manifold can explain the API better than I can
> here.  The point where that interacts with Netty w.r.t. backpressure is
> here:
> https://github.com/ztellman/aleph/blob/0.4.0/src/aleph/netty.clj#L109.
> Here the stream represents data coming off the wire, and if the put onto
> the stream is not immediately successful, backpressure is enabled until the
> put completes.  No blocking required anywhere.
>
> On Wed, Oct 8, 2014 at 10:10 AM, Jozef Wagner 
> wrote:
>
>> If you want to handle multiple TCP connections and async channels in one
>> thread, you need a way how to block on both connections (wait for new input
>> to arrive) and channels (wait for a free space in a buffer). Blocking only
>> on connections will get you a busy loop if channels are full. If you could
>> point me to the part of Aleph sources that handles this issue, I would be
>> very grateful. I'm not familiar with netty API nor manifold's concepts, so
>> I'm having trouble navigating in the Aleph sources.
>>
>> Thanks,
>> Jozef
>>
>> On Wednesday, October 8, 2014 6:15:47 PM UTC+2, Zach Tellman wrote:
>>>
>>> I wasn't aware of hermod, that's interesting.  I would still
>>> characterize its approach to backpressure as "broken", though, since when
>>> the queues get full it silently drops messages on the ground.  In fairness,
>>> this is very clearly documented, so it's less pernicious than some of the
>>> other cases out there.
>>>
>>> Both core.async buffers and SelectableChannels have very particular
>>> semantics, and I would be very surprised if they could be combined in that
>>> way.  It's perfectly possible to feed one into the other and handle
>>> backpressure properly (again, I'm doing just that with Aleph 0.4.0, using
>>> Netty), but it's a nuanced integration and easy to get wrong.
>>>
>>> On Wed, Oct 8, 2014 at 7:12 AM,  wrote:
>>>
 Check out https://github.com/halgari/com.tbaldridge.hermod for an
 interesting take on this.

 On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:
>
>  BTW, is there any network based core.async channel available now?
>
> On 10/08/2014 04:36 AM, adrian...@mail.yu.edu wrote:
>
>  It's not about 'safety' (depending on what that means in this
> context), but as Zach pointed out, if you aren't careful about 
> backpressure
> you can run into performance bottlenecks with unrestrained async IO
> operations because although they let you code as if you could handle an
> unlimited amount of connections, obviously that isn't true. There is only 
> a
> finite amount of data that can be buffered in and out of any network
> according to its hardware. When you don't regulate that, your system will
> end up spending an inordinate amount of time compensating for this. You
> don't need to worry about this with "regular io" because the "thread per
> connection" abstraction effectively bounds your activity within the
> acceptable physical constraints of the server.
>
> On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote:
>>
>>
>> On Mon, Oct 6, 2014 at 12:10 AM,  wrote:
>>
>>> Zach makes an excellent point; I've used AsyncSocketChannels and its
>>> irk (http://docs.oracle.com/javase/8/docs/api/java/nio/channels/
>>> AsynchronousServerSocketChannel.html), with core.async in the past.
>>> Perhaps replacing your direct java.net.Sockets with nio classes that 
>>> can be
>>> given CompletionHandlers (http://docs.oracle.com/javase
>>> /7/docs/api/java/nio/channels/CompletionHandler.html) would be a
>>> better fit.
>>>
>>
>> Once I do some performance instrumentation I'll give that a shot. I
>> admit that I'm not familiar with all the implications of using the nio
>> classes; were I to switch, is it safe to continue using go blocks, or is 
>> it
>> worth explicitly allocating a single thread per socket?
>>
>>  Brian
>>
>  --
> 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 sto

Re: com.stuartsierra/component & ring/compojure example

[Juho Teperi]

The Stuart Sierra's talk about Component has short bit about using it with 
ring, at around 32:24 .

Idea is that you'll wrap your basic routes with a middleware which will 
assoc components to every request.
Difference to the other approach (creating the routes using fn taking the 
components as params) is that you are referencing the routes through a var 
so you can update your routes by evaluating the route definition again and 
you don't need to reset the system.

I have a example here: https://gist.github.com/Deraen/9d65f447593859dd07ae. 
It also has some compojure-api stuff to enable easier access to components 
for the handlers.

On Tuesday, October 7, 2014 2:33:33 PM UTC+3, JPatrick Davenport wrote:
>
> Hello,
> I'm trying to create a web app. I'm having the damnest time trying to 
> figure out how to layer my application. I want to pass protocol 
> implementations to the routes. The protocols define interacting with 
> various data sources that I need down the way. 
>
> I saw Stuart Sierra's talk about Component. It looks to satisfy my needs. 
> What I can't find is an example project for component and compojure. 
> Unfortunately the project com.stuartsierra/component is poorly named. 
> Googling for component + compojure brings back mostly false positives.
>
> Does anyone have a gist or blog post about how to do this?
>
> Thanks,
> JPD
>

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

help with sequence, "seq", Seq, and `seq`

[John Gabriele]

Reading Joy of Clojure, section 5.1.2, I'm hoping someone here can help me 
understand the following:

  * `clojure.core/seq` returns a "seq" or a "sequence"? Likewise for `map` 
and `filter`.

  * What is the difference between a "seq" and a "sequence"?

  * A seq may possibly be lazy, but vectors and lists are always 
fully-realized, correct?

  * What does "seqable" mean?

  * Is Seq (ISeq?) or is Sequential the `first`/`rest` API? What is the 
difference between ISeq and Sequential (see `seq?` & `sequential?`)?

Thanks!

-- 
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: State of Clojure 2014 Survey - please contribute!!

[Alex Miller]

The 2014 State of Clojure survey is now available! This year's edition is
broken into 2 parts - one for anyone who uses any Clojure dialect and a
second specifically for ClojureScript users.

http://blog.cognitect.com/blog/2014/10/3/2014-state-of-clojure-clojurescript-survey

>From a community perspective, it is really great to see this feedback every
year to gauge the size and interests of the community. Both raw data and
some analysis will be published after the survey ends on October 17th.

Let me know if you have any questions,
Alex Miller
alex.mil...@cognitect.com

-- 
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] async-sockets - work with sockets using core.async channels

[Jozef Wagner]

Thank you! Using put! callback to control backpressure is a very elegant 
solution. BTW there always has to be blocking somewhere. Netty uses 
selector to block at [1] and .setAutoRead causes respective channel to 
deregister itself from a selector [2], until put! completes.

Regarding the other way around, it seems to me from the quick look (sorry 
if I misinterpreted) that using futures to represent write completion will 
cause the eventual backpressure to block the thread, causing analogous 
drawback as a blocking put! in the "reading from multiple connection" case.

[1] 
https://github.com/netty/netty/blob/220660e351b2a22112b19c4af45e403eab1f73ab/transport/src/main/java/io/netty/channel/nio/NioEventLoop.java#L625
[2] 
https://github.com/netty/netty/blob/220660e351b2a22112b19c4af45e403eab1f73ab/transport/src/main/java/io/netty/channel/nio/AbstractNioChannel.java#L173

Jozef

On Wednesday, October 8, 2014 7:16:44 PM UTC+2, Zach Tellman wrote:
>
> The documentation for Manifold can explain the API better than I can 
> here.  The point where that interacts with Netty w.r.t. backpressure is 
> here: 
> https://github.com/ztellman/aleph/blob/0.4.0/src/aleph/netty.clj#L109.  
> Here the stream represents data coming off the wire, and if the put onto 
> the stream is not immediately successful, backpressure is enabled until the 
> put completes.  No blocking required anywhere.
>
> On Wed, Oct 8, 2014 at 10:10 AM, Jozef Wagner  > wrote:
>
>> If you want to handle multiple TCP connections and async channels in one 
>> thread, you need a way how to block on both connections (wait for new input 
>> to arrive) and channels (wait for a free space in a buffer). Blocking only 
>> on connections will get you a busy loop if channels are full. If you could 
>> point me to the part of Aleph sources that handles this issue, I would be 
>> very grateful. I'm not familiar with netty API nor manifold's concepts, so 
>> I'm having trouble navigating in the Aleph sources.
>>
>> Thanks,
>> Jozef
>>
>> On Wednesday, October 8, 2014 6:15:47 PM UTC+2, Zach Tellman wrote:
>>>
>>> I wasn't aware of hermod, that's interesting.  I would still 
>>> characterize its approach to backpressure as "broken", though, since when 
>>> the queues get full it silently drops messages on the ground.  In fairness, 
>>> this is very clearly documented, so it's less pernicious than some of the 
>>> other cases out there.
>>>
>>> Both core.async buffers and SelectableChannels have very particular 
>>> semantics, and I would be very surprised if they could be combined in that 
>>> way.  It's perfectly possible to feed one into the other and handle 
>>> backpressure properly (again, I'm doing just that with Aleph 0.4.0, using 
>>> Netty), but it's a nuanced integration and easy to get wrong.
>>>
>>> On Wed, Oct 8, 2014 at 7:12 AM,  wrote:
>>>
 Check out https://github.com/halgari/com.tbaldridge.hermod for an 
 interesting take on this. 

 On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:
>
>  BTW, is there any network based core.async channel available now?
>
> On 10/08/2014 04:36 AM, adrian...@mail.yu.edu wrote:
>  
>  It's not about 'safety' (depending on what that means in this 
> context), but as Zach pointed out, if you aren't careful about 
> backpressure 
> you can run into performance bottlenecks with unrestrained async IO 
> operations because although they let you code as if you could handle an 
> unlimited amount of connections, obviously that isn't true. There is only 
> a 
> finite amount of data that can be buffered in and out of any network 
> according to its hardware. When you don't regulate that, your system will 
> end up spending an inordinate amount of time compensating for this. You 
> don't need to worry about this with "regular io" because the "thread per 
> connection" abstraction effectively bounds your activity within the 
> acceptable physical constraints of the server. 
>
> On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote: 
>>
>>  
>> On Mon, Oct 6, 2014 at 12:10 AM,  wrote:
>>
>>> Zach makes an excellent point; I've used AsyncSocketChannels and its 
>>> irk (http://docs.oracle.com/javase/8/docs/api/java/nio/channels/
>>> AsynchronousServerSocketChannel.html), with core.async in the past. 
>>> Perhaps replacing your direct java.net.Sockets with nio classes that 
>>> can be 
>>> given CompletionHandlers (http://docs.oracle.com/javase
>>> /7/docs/api/java/nio/channels/CompletionHandler.html) would be a 
>>> better fit. 
>>>
>>  
>> Once I do some performance instrumentation I'll give that a shot. I 
>> admit that I'm not familiar with all the implications of using the nio 
>> classes; were I to switch, is it safe to continue using go blocks, or is 
>> it 
>> worth explicitly allocating a single thread per socket?
>>
>>  B

Re: [ANN] async-sockets - work with sockets using core.async channels

[Zach Tellman]

Yes, I didn't mean to imply that there are no blocking operations anywhere,
only that nothing in the worker threads (where the put! occurs) will block,
and that backpressure isn't exerted by causing an active thread to hang.

As to the second point, I'm not sure why you'd think that.  These aren't
futures that are being accessed via blocking dereference, so there's no
reason any thread would block as a result of an unrealized future/deferred.



On Wed, Oct 8, 2014 at 12:22 PM, Jozef Wagner 
wrote:

> Thank you! Using put! callback to control backpressure is a very elegant
> solution. BTW there always has to be blocking somewhere. Netty uses
> selector to block at [1] and .setAutoRead causes respective channel to
> deregister itself from a selector [2], until put! completes.
>
> Regarding the other way around, it seems to me from the quick look (sorry
> if I misinterpreted) that using futures to represent write completion will
> cause the eventual backpressure to block the thread, causing analogous
> drawback as a blocking put! in the "reading from multiple connection" case.
>
> [1]
> https://github.com/netty/netty/blob/220660e351b2a22112b19c4af45e403eab1f73ab/transport/src/main/java/io/netty/channel/nio/NioEventLoop.java#L625
> [2]
> https://github.com/netty/netty/blob/220660e351b2a22112b19c4af45e403eab1f73ab/transport/src/main/java/io/netty/channel/nio/AbstractNioChannel.java#L173
>
> Jozef
>
> On Wednesday, October 8, 2014 7:16:44 PM UTC+2, Zach Tellman wrote:
>>
>> The documentation for Manifold can explain the API better than I can
>> here.  The point where that interacts with Netty w.r.t. backpressure is
>> here: https://github.com/ztellman/aleph/blob/0.4.0/src/
>> aleph/netty.clj#L109.  Here the stream represents data coming off the
>> wire, and if the put onto the stream is not immediately successful,
>> backpressure is enabled until the put completes.  No blocking required
>> anywhere.
>>
>> On Wed, Oct 8, 2014 at 10:10 AM, Jozef Wagner 
>> wrote:
>>
>>> If you want to handle multiple TCP connections and async channels in one
>>> thread, you need a way how to block on both connections (wait for new input
>>> to arrive) and channels (wait for a free space in a buffer). Blocking only
>>> on connections will get you a busy loop if channels are full. If you could
>>> point me to the part of Aleph sources that handles this issue, I would be
>>> very grateful. I'm not familiar with netty API nor manifold's concepts, so
>>> I'm having trouble navigating in the Aleph sources.
>>>
>>> Thanks,
>>> Jozef
>>>
>>> On Wednesday, October 8, 2014 6:15:47 PM UTC+2, Zach Tellman wrote:

 I wasn't aware of hermod, that's interesting.  I would still
 characterize its approach to backpressure as "broken", though, since when
 the queues get full it silently drops messages on the ground.  In fairness,
 this is very clearly documented, so it's less pernicious than some of the
 other cases out there.

 Both core.async buffers and SelectableChannels have very particular
 semantics, and I would be very surprised if they could be combined in that
 way.  It's perfectly possible to feed one into the other and handle
 backpressure properly (again, I'm doing just that with Aleph 0.4.0, using
 Netty), but it's a nuanced integration and easy to get wrong.

 On Wed, Oct 8, 2014 at 7:12 AM,  wrote:

> Check out https://github.com/halgari/com.tbaldridge.hermod for an
> interesting take on this.
>
> On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:
>>
>>  BTW, is there any network based core.async channel available now?
>>
>> On 10/08/2014 04:36 AM, adrian...@mail.yu.edu wrote:
>>
>>  It's not about 'safety' (depending on what that means in this
>> context), but as Zach pointed out, if you aren't careful about 
>> backpressure
>> you can run into performance bottlenecks with unrestrained async IO
>> operations because although they let you code as if you could handle an
>> unlimited amount of connections, obviously that isn't true. There is 
>> only a
>> finite amount of data that can be buffered in and out of any network
>> according to its hardware. When you don't regulate that, your system will
>> end up spending an inordinate amount of time compensating for this. You
>> don't need to worry about this with "regular io" because the "thread per
>> connection" abstraction effectively bounds your activity within the
>> acceptable physical constraints of the server.
>>
>> On Tuesday, October 7, 2014 2:49:30 PM UTC-4, Brian Guthrie wrote:
>>>
>>>
>>> On Mon, Oct 6, 2014 at 12:10 AM,  wrote:
>>>
 Zach makes an excellent point; I've used AsyncSocketChannels and
 its irk (http://docs.oracle.com/javase/8/docs/api/java/nio/
 channels/AsynchronousServerSocketChannel.html), with core.async in
 the past. Perhaps replacing your dire

Unmarshalling EDN to Java Object

[Timur]

Hi everyone,

One can use into-edn [1] to convert from Java objects to EDN structures. 

Is there a way to convert EDN structures to their original Java objects? 

Regards,

Timur

[1] https://github.com/thebusby/into-edn

-- 
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: Unmarshalling EDN to Java Object

[Mark Mandel]

I'm sure you can, but you would need to implement your own custom methods
to do it, using :readers or :default options in edn/read  / edn/read-string

It would very much depend on the format of the outputted EDN as to which
approach to take.

Mark



On 9 October 2014 07:12, Timur  wrote:

> Hi everyone,
>
> One can use into-edn [1] to convert from Java objects to EDN structures.
>
> Is there a way to convert EDN structures to their original Java objects?
>
> Regards,
>
> Timur
>
> [1] https://github.com/thebusby/into-edn
>
> --
> 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.
>



-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

-- 
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] rmap - define lazy, recursive maps

[Arnout Roemers]

Hi Zach,

Thank you for checking out the library. You were right, some interfaces 
were missing and some methods had not been implemented. Though this was 
documented, they were limitations that could be fixed.

*So, I'd like to announce version 0.2.0.*

This version does implement all the necessary interfaces. Your source of 
def-map-type from "Potemkin" certainly helped here, although I did not use 
it directly. Nice work by the way. I have tested the current rmap 
implementation with the "collection-check" library, and it passes. Again, 
nice work, Zach.

I still use a LinkedHashMap as the underlying data structure (as I want to 
keep track of the evaluation order), but I could not break that structure 
like the way you said. It seems to behave fine. Please let me know if you 
do know of a counter example.

P.S. Zach, the README of the "collection-check" library is not updated with 
the dependency change to "test.check".
P.P.S. Still working on a post about the motivation and how it works.

-- 
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] async-sockets - work with sockets using core.async channels

[Jozef Wagner]

It was just my ignorance of manifold's concepts :). I was thinking in terms 
of "I have this thread which should connect these channels to those 
sockets, when to do what". Manifold's async approach with its connectable 
streams and deferreds with callbacks seems to abstract away such 
bookkeeping.

Jozef 

On Wednesday, October 8, 2014 9:31:50 PM UTC+2, Zach Tellman wrote:
>
> Yes, I didn't mean to imply that there are no blocking operations 
> anywhere, only that nothing in the worker threads (where the put! occurs) 
> will block, and that backpressure isn't exerted by causing an active thread 
> to hang.
>
> As to the second point, I'm not sure why you'd think that.  These aren't 
> futures that are being accessed via blocking dereference, so there's no 
> reason any thread would block as a result of an unrealized future/deferred.
>
>
>
> On Wed, Oct 8, 2014 at 12:22 PM, Jozef Wagner  > wrote:
>
>> Thank you! Using put! callback to control backpressure is a very elegant 
>> solution. BTW there always has to be blocking somewhere. Netty uses 
>> selector to block at [1] and .setAutoRead causes respective channel to 
>> deregister itself from a selector [2], until put! completes.
>>
>> Regarding the other way around, it seems to me from the quick look (sorry 
>> if I misinterpreted) that using futures to represent write completion will 
>> cause the eventual backpressure to block the thread, causing analogous 
>> drawback as a blocking put! in the "reading from multiple connection" case.
>>
>> [1] 
>> https://github.com/netty/netty/blob/220660e351b2a22112b19c4af45e403eab1f73ab/transport/src/main/java/io/netty/channel/nio/NioEventLoop.java#L625
>> [2] 
>> https://github.com/netty/netty/blob/220660e351b2a22112b19c4af45e403eab1f73ab/transport/src/main/java/io/netty/channel/nio/AbstractNioChannel.java#L173
>>
>> Jozef
>>
>> On Wednesday, October 8, 2014 7:16:44 PM UTC+2, Zach Tellman wrote:
>>>
>>> The documentation for Manifold can explain the API better than I can 
>>> here.  The point where that interacts with Netty w.r.t. backpressure is 
>>> here: https://github.com/ztellman/aleph/blob/0.4.0/src/
>>> aleph/netty.clj#L109.  Here the stream represents data coming off the 
>>> wire, and if the put onto the stream is not immediately successful, 
>>> backpressure is enabled until the put completes.  No blocking required 
>>> anywhere.
>>>
>>> On Wed, Oct 8, 2014 at 10:10 AM, Jozef Wagner  
>>> wrote:
>>>
 If you want to handle multiple TCP connections and async channels in 
 one thread, you need a way how to block on both connections (wait for new 
 input to arrive) and channels (wait for a free space in a buffer). 
 Blocking 
 only on connections will get you a busy loop if channels are full. If you 
 could point me to the part of Aleph sources that handles this issue, I 
 would be very grateful. I'm not familiar with netty API nor manifold's 
 concepts, so I'm having trouble navigating in the Aleph sources.

 Thanks,
 Jozef

 On Wednesday, October 8, 2014 6:15:47 PM UTC+2, Zach Tellman wrote:
>
> I wasn't aware of hermod, that's interesting.  I would still 
> characterize its approach to backpressure as "broken", though, since when 
> the queues get full it silently drops messages on the ground.  In 
> fairness, 
> this is very clearly documented, so it's less pernicious than some of the 
> other cases out there.
>
> Both core.async buffers and SelectableChannels have very particular 
> semantics, and I would be very surprised if they could be combined in 
> that 
> way.  It's perfectly possible to feed one into the other and handle 
> backpressure properly (again, I'm doing just that with Aleph 0.4.0, using 
> Netty), but it's a nuanced integration and easy to get wrong.
>
> On Wed, Oct 8, 2014 at 7:12 AM,  wrote:
>
>> Check out https://github.com/halgari/com.tbaldridge.hermod for an 
>> interesting take on this. 
>>
>> On Wednesday, October 8, 2014 1:17:11 AM UTC-4, Sun Ning wrote:
>>>
>>>  BTW, is there any network based core.async channel available now?
>>>
>>> On 10/08/2014 04:36 AM, adrian...@mail.yu.edu wrote:
>>>  
>>>  It's not about 'safety' (depending on what that means in this 
>>> context), but as Zach pointed out, if you aren't careful about 
>>> backpressure 
>>> you can run into performance bottlenecks with unrestrained async IO 
>>> operations because although they let you code as if you could handle an 
>>> unlimited amount of connections, obviously that isn't true. There is 
>>> only a 
>>> finite amount of data that can be buffered in and out of any network 
>>> according to its hardware. When you don't regulate that, your system 
>>> will 
>>> end up spending an inordinate amount of time compensating for this. You 
>>> don't need to worry about this with "regular io" because the "thread

Re: com.stuartsierra/component & ring/compojure example

[Huahai Yang]

This solution (creating the routes in a function and passing components 
into the function) seems to be the best solution. Other solutions all 
require defining the routes a prior, which may be the root of the problems, 
because some handlers may depend on functions generated by components in 
the run time.

-huahai


On Tuesday, October 7, 2014 10:42:14 PM UTC-7, Andrew Meredith wrote:
>
> This is not a full example, but I ran into the same issue when building an 
> app for the Clojure Cup not too long ago. The general approach I used is 
> this:
>
>- create the Compojure routes in a function with the components I need 
>as parameters
>- declare the web server itself (I used httpkit) as a component with 
>the dependencies needed for the routes
>- build a handler from the routes within the web server component's 
>start function, passing the dependencies into the route-generating function
>
> I'm no Clojure expert, and this was my first project using Stuart Sierra's 
> Component library, so I would be interested to hear some feedback from the 
> more seasoned Clojure folks here.
>
> Here is the relevant file from my project if you are interested: 
> https://github.com/kendru/tourbillon/blob/master/src/tourbillon/www/core.clj#L67
>
> On Tuesday, October 7, 2014 11:33:33 AM UTC, JPatrick Davenport wrote:
>>
>> Hello,
>> I'm trying to create a web app. I'm having the damnest time trying to 
>> figure out how to layer my application. I want to pass protocol 
>> implementations to the routes. The protocols define interacting with 
>> various data sources that I need down the way. 
>>
>> I saw Stuart Sierra's talk about Component. It looks to satisfy my needs. 
>> What I can't find is an example project for component and compojure. 
>> Unfortunately the project com.stuartsierra/component is poorly named. 
>> Googling for component + compojure brings back mostly false positives.
>>
>> Does anyone have a gist or blog post about how to do this?
>>
>> Thanks,
>> JPD
>>
>

-- 
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: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript

[Dom Kiva-Meyer]

Thanks for putting that together, Dylan. Looking forward to seeing what
you're building. :)

Olli, please feel free to reach out to me (email, Twitter, GitHub issue,
whatever) if you have any questions. Thanks for trying it out!

On Tue, Oct 7, 2014 at 12:05 PM, Dylan Butman  wrote:

> Sorry i don't have time to really explain any of this...
>
> but here's some code I pulled out of a recent project. maybe it'll be
> helpful to you. unfortunately I can't share the whole project.
>
> https://gist.github.com/pleasetrythisathome/7adbdc9c8b7ab689df45
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
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: help with sequence, "seq", Seq, and `seq`

[tao.zhou2009]

you can read Programming Clojure 2nd, which explains very clearly. 

-- 
tao.zhou2009
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, October 9, 2014 at 2:39 AM, John Gabriele wrote:

> Reading Joy of Clojure, section 5.1.2, I'm hoping someone here can help me 
> understand the following:
> 
>   * `clojure.core/seq` returns a "seq" or a "sequence"? Likewise for `map` 
> and `filter`.
> 
>   * What is the difference between a "seq" and a "sequence"?
> 
>   * A seq may possibly be lazy, but vectors and lists are always 
> fully-realized, correct?
> 
>   * What does "seqable" mean?
> 
>   * Is Seq (ISeq?) or is Sequential the `first`/`rest` API? What is the 
> difference between ISeq and Sequential (see `seq?` & `sequential?`)?
> 
> Thanks!
> 
> -- 
> 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 
> (mailto: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 
> (mailto: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 
> (mailto: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: help with sequence, "seq", Seq, and `seq`

[James Reeves]

The words "seq" and "sequence" can be used interchangeably.

The "map" and "filter" functions return seqs.

Yes, a seq may be lazy, but vectors and lists cannot.

"seqable" means any data structure that can be turned into a seq using the
"seq" function. This includes the Clojure collections, but also strings,
arrays and Java collections.

The Sequential interface is a way of indicating a collection has a natural
order. So seqs, lists and vectors are sequential, but maps and sets are not.

The ISeq interface is the internal interface for seqs. An object is a seq
if it implements ISeq.

- James


On 8 October 2014 19:39, John Gabriele  wrote:

> Reading Joy of Clojure, section 5.1.2, I'm hoping someone here can help me
> understand the following:
>
>   * `clojure.core/seq` returns a "seq" or a "sequence"? Likewise for `map`
> and `filter`.
>
>   * What is the difference between a "seq" and a "sequence"?
>
>   * A seq may possibly be lazy, but vectors and lists are always
> fully-realized, correct?
>
>   * What does "seqable" mean?
>
>   * Is Seq (ISeq?) or is Sequential the `first`/`rest` API? What is the
> difference between ISeq and Sequential (see `seq?` & `sequential?`)?
>
> Thanks!
>
>  --
> 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: [PSA] Clojars scp disabled until further notice

[Bridget]

On Friday, September 26, 2014 11:09:55 AM UTC-4, Nelson Morris wrote:
>
> Clojars has become a critical part of the clojure ecosystem. As a small 
> sample, it hosts artifacts for:
>
> * Web development - ring, compojure, hoplon, hiccup, enlive, friend, 
> immutant
> * Tooling - lein templates/plugins, cider-nrepl, clojure-complete, 
> gorilla-repl
> * Clojurescript - lein-cljsbuild, austin, om, reagent, sente
> * Misc - Clojurewerkz projects, storm, incanter, clj-time, cheshire, 
> clj-http, 
> * Company projects - pedestal, dommy, schema
>

Just want to take this opportunity to say, yet again - because it can't be 
said enough - THANK YOU to Nelson (and Phil, of course!) for all of the 
hard - and unpaid - work that you put into Clojars. 

I hope that some sponsors can step forward to say thank you in a more 
concrete way.

Bridget

-- 
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] rmap - define lazy, recursive maps

[Ben Wolfson]

This is pretty nifty:

user=> (require '[rmap.core :as rmap])
nil
user=> (def fibs (rmap/rmap FIBS {:a 0 :b 1 :next (-> FIBS (update-in [:a]
(constantly (:b FIBS))) (update-in [:b] (constantly (+ (:b FIBS) (:a
FIBS)}))
#'user/fibs
user=> (defn fib [n] (loop [fibs fibs n n] (if (zero? n) (:a fibs) (recur
(:next fibs) (dec n)
#'user/fib
user=> (fib 40)
102334155



On Wed, Oct 8, 2014 at 1:37 PM, Arnout Roemers <
goo...@company.romeinszoon.nl> wrote:

> Hi Zach,
>
> Thank you for checking out the library. You were right, some interfaces
> were missing and some methods had not been implemented. Though this was
> documented, they were limitations that could be fixed.
>
> *So, I'd like to announce version 0.2.0.*
>
> This version does implement all the necessary interfaces. Your source of
> def-map-type from "Potemkin" certainly helped here, although I did not
> use it directly. Nice work by the way. I have tested the current rmap
> implementation with the "collection-check" library, and it passes. Again,
> nice work, Zach.
>
> I still use a LinkedHashMap as the underlying data structure (as I want
> to keep track of the evaluation order), but I could not break that
> structure like the way you said. It seems to behave fine. Please let me
> know if you do know of a counter example.
>
> P.S. Zach, the README of the "collection-check" library is not updated
> with the dependency change to "test.check".
> P.P.S. Still working on a post about the motivation and how it works.
>
> --
> 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.
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

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

Re: [ANN] Clojure instaREPL for web

[Sam Raker]

This is great. A little buggy, but that's to be expected :)
I really appreciate the ability to hop onilne and test the behavior of 
little bits of code without waiting for a local repl to start up!

On Tuesday, October 7, 2014 3:00:08 PM UTC-4, Lauri Hartikka wrote:
>
> A web based clojure instaREPL,
>
> Check it out :)
>
> http://clojurerepl.com
>
>
>

-- 
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: Profiling in Counterclockwise

[Skottk]

I just did this for the first time last week.  Run VisualVM, it gives you a 
list of running VMs. Select one. Hit the button to start collecting profiling 
data. Execute some code in the REPL. Eventually it will finish, and you'll have 
a big stack of profiling data. It won't go down to the granularity of your 
individual fn's, but you can tell a ton from which library fn's are soaking up 
your time. 
What I'm saying is, it almost couldn't be easier. 
SK

-- 
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: help with sequence, "seq", Seq, and `seq`

[John Gabriele]

Thanks, James!

What still throws me off is that the JoC book points out a symmetry that I 
wanted to better grasp. It first notes that:

  * `(first []) ;=> nil` and
  * `(rest []) ;=> ()`

and then goes on to say:

  * "Clojure functions that promise to return sequences, such as `map` and 
`filter`, work the same way as `rest`." And,

  * (when calling `seq` on a coll) "...In either case, if the collection is 
empty, `seq` returns nil and never an empty sequence. Functions that 
promise to return seqs (not sequences), such as `next`, work the same way."

Hm. "seqs (not sequences)" doesn't make sense to me here. Maybe I'm 
misunderstanding, or maybe there's a typo (or mis-capitalization) in there 
somewhere?

-- John



On Wednesday, October 8, 2014 8:16:38 PM UTC-4, James Reeves wrote:
>
> The words "seq" and "sequence" can be used interchangeably.
>
> The "map" and "filter" functions return seqs.
>
> Yes, a seq may be lazy, but vectors and lists cannot.
>
> "seqable" means any data structure that can be turned into a seq using the 
> "seq" function. This includes the Clojure collections, but also strings, 
> arrays and Java collections.
>
> The Sequential interface is a way of indicating a collection has a natural 
> order. So seqs, lists and vectors are sequential, but maps and sets are not.
>
> The ISeq interface is the internal interface for seqs. An object is a seq 
> if it implements ISeq.
>
> - James
>
>
> On 8 October 2014 19:39, John Gabriele > 
> wrote:
>
>> Reading Joy of Clojure, section 5.1.2, I'm hoping someone here can help 
>> me understand the following:
>>
>>   * `clojure.core/seq` returns a "seq" or a "sequence"? Likewise for 
>> `map` and `filter`.
>>
>>   * What is the difference between a "seq" and a "sequence"?
>>
>>   * A seq may possibly be lazy, but vectors and lists are always 
>> fully-realized, correct?
>>
>>   * What does "seqable" mean?
>>
>>   * Is Seq (ISeq?) or is Sequential the `first`/`rest` API? What is the 
>> difference between ISeq and Sequential (see `seq?` & `sequential?`)?
>>
>> Thanks!
>>
>>  

-- 
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: peek the next value from a channel without consuming it

[Fluid Dynamics]

On Monday, October 6, 2014 9:36:59 AM UTC-4, edbond wrote:
>
> Add one more chan, "external ready".
> Put :ok there to let producer generate new value.
>
> producer:
> - read from "external ready"
> - generate value
> - put into "outgoing" chan
>
> client:
> - contact external server, put in "external ready" if ok
> - read from "outgoing" chan
> - send to external
>
> Handle exceptions and loop where you need.
>

If you're not reading from "outgoing" until the external server is known to 
be ready, you don't need the "external ready" channel. Backpressure on the 
"outgoing" channel will suffice to keep the producer from overrunning the 
consumer in this case. 

-- 
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: Profiling in Counterclockwise

[Fluid Dynamics]

On Wednesday, October 8, 2014 9:20:31 PM UTC-4, Skottk wrote:
>
> I just did this for the first time last week.  Run VisualVM, it gives you 
> a list of running VMs. Select one. Hit the button to start collecting 
> profiling data. Execute some code in the REPL. Eventually it will finish, 
> and you'll have a big stack of profiling data. It won't go down to the 
> granularity of your individual fn's, but you can tell a ton from which 
> library fn's are soaking up your time. 
> What I'm saying is, it almost couldn't be easier. 
> SK


OK, I'll keep that in mind. 

-- 
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: help with sequence, "seq", Seq, and `seq`

[Fluid Dynamics]

On Wednesday, October 8, 2014 8:16:38 PM UTC-4, James Reeves wrote:
>
> The words "seq" and "sequence" can be used interchangeably.
>
> The "map" and "filter" functions return seqs.
>
> Yes, a seq may be lazy, but vectors and lists cannot.
>
> "seqable" means any data structure that can be turned into a seq using the 
> "seq" function. This includes the Clojure collections, but also strings, 
> arrays and Java collections.
>
> The Sequential interface is a way of indicating a collection has a natural 
> order. So seqs, lists and vectors are sequential, but maps and sets are not.
>

Oddly, this seems to include sorted maps and sorted sets 
(clojure.lang.PersistentTreeFoo), even though those do have a natural order 
(unlike their PersistentHashFoo brethren). 

-- 
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: State of Clojure 2014 Survey - please contribute!!

[Mars0i]

Thanks for the survey!

I have a couple of suggestions/questions:

For domains, there are no categories for scientific or other research 
applications.  For example, I mainly use Clojure for writing agent-based 
models for academic research.  Would a set of categories in this area be 
usedful?

The development environment options leave out more basic, simple methods.  
For example, I generally use vim and a repl run from the command line, 
which works well for me.  I guess I should chose "other", but that means I 
don't get counted among the vim users.  Maybe the number of people like me 
is so small as to be ignorable?

-- 
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: help with sequence, "seq", Seq, and `seq`

[Ambrose Bonnaire-Sergeant]

On Wed, Oct 8, 2014 at 10:55 PM, John Gabriele  wrote:

>   * (when calling `seq` on a coll) "...In either case, if the collection
> is empty, `seq` returns nil and never an empty sequence. Functions that
> promise to return seqs (not sequences), such as `next`, work the same way."
>
>
I think that's a typo. I don't know what the difference between a "seq" and
a "sequence" would be in this context.

Thanks,
Ambrose


>
>
> On Wednesday, October 8, 2014 8:16:38 PM UTC-4, James Reeves wrote:
>>
>> The words "seq" and "sequence" can be used interchangeably.
>>
>> The "map" and "filter" functions return seqs.
>>
>> Yes, a seq may be lazy, but vectors and lists cannot.
>>
>> "seqable" means any data structure that can be turned into a seq using
>> the "seq" function. This includes the Clojure collections, but also
>> strings, arrays and Java collections.
>>
>> The Sequential interface is a way of indicating a collection has a
>> natural order. So seqs, lists and vectors are sequential, but maps and sets
>> are not.
>>
>> The ISeq interface is the internal interface for seqs. An object is a seq
>> if it implements ISeq.
>>
>> - James
>>
>>
>> On 8 October 2014 19:39, John Gabriele  wrote:
>>
>>> Reading Joy of Clojure, section 5.1.2, I'm hoping someone here can help
>>> me understand the following:
>>>
>>>   * `clojure.core/seq` returns a "seq" or a "sequence"? Likewise for
>>> `map` and `filter`.
>>>
>>>   * What is the difference between a "seq" and a "sequence"?
>>>
>>>   * A seq may possibly be lazy, but vectors and lists are always
>>> fully-realized, correct?
>>>
>>>   * What does "seqable" mean?
>>>
>>>   * Is Seq (ISeq?) or is Sequential the `first`/`rest` API? What is the
>>> difference between ISeq and Sequential (see `seq?` & `sequential?`)?
>>>
>>> Thanks!
>>>
>>>   --
> 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.