Recursive codec/frames in gloss?

[Ken Restivo]

I'm playing around with Gloss, trying to decode a packet, part of which has the 
following nested struture:

header-length (1 byte, value n)
byte0 ... byten (count defined by that header-length byte)
   actual payload (length of which is the sum of the values of the 
above bytes)

So instead of a fixed-size value (uint16, uint32, uint64, etc) defining the 
size of the payload, there's a variable-length  list of bytes (up to 255),  
which has to be summed, to determine the length of the payload.

Pretty easy to do imperatively, but I got lost in the dense forest of gloss's 
abstractions, and couldn't figure out if it makes sense to try to handle a case 
like this with it.

-ken

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

Re: [ANN] Example project to illustrate usage of system library

[Daniel Szmulewicz]

 

Yes, because locally you are in the repl already. The repl in production is 
brought in explicitly to be able to login/debug remotely into the 
application where it’s hosted.
Does that make sense? 

On Friday, October 10, 2014 7:13:39 AM UTC+3, Atamert Ölçgen wrote:
>
> prod-system has a REPL but dev-system doesn't. Is this intentional?
>
>
> https://github.com/danielsz/system/blob/master/example/src/example/systems.clj
>
> On Wed, Oct 8, 2014 at 7:57 PM, Daniel Szmulewicz  > wrote:
>
>> 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 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.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> -+-
> --+
> +++
>
> www.muhuk.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] Clojure Videos (with options for Linux users)

[Eric Normand]

Hello,

To plug my own videos, the LispCast core.async videos are coming out soon! 
I have a strict deadline of "before the conj". You can get on the mailing 
list to get a discount when they come out. You'll also get a core.async 
cheatsheet for signing up.

http://purelyfunctional.tv/core-async

They are definitely good for the beginner level. They only assume basic 
Clojure knowledge.

Rock on!
Eric

-- 
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: Where can one find low hanging fruit for open source contribution?

[Eric Normand]

There's a new weekly newsletter called Clojure in the Open that lists small 
tasks that Open Source projects are asking for:

http://www.longstorm.org/weekly/cito/1/

Eric

On Saturday, September 27, 2014 1:34:19 AM UTC-5, kurofune wrote:
>
> I am an looking for a good, active, open source Clojure library/project to 
> contribute to, but am not sure where to start. Could somebody give an 
> intermediate level programmer a  few pointers as to where to begin? 
>

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

[Atamert Ölçgen]

prod-system has a REPL but dev-system doesn't. Is this intentional?

https://github.com/danielsz/system/blob/master/example/src/example/systems.clj

On Wed, Oct 8, 2014 at 7:57 PM, Daniel Szmulewicz <
daniel.szmulew...@gmail.com> wrote:

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



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.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: How to read a transit string from client side (transit-cljs) on server side (tansit-clj)

[Bin Li]

More detail here, thanks for help~

https://groups.google.com/forum/#!msg/transit-format/c_5BuPb1R1A/_jXl3mCS-1IJ

On Thursday, September 25, 2014 9:44:23 PM UTC+8, Ashton Kemerling wrote:
>
> I think you should take a look at the transit-Clj README, it has docs and 
> examples. 
>
> https://github.com/cognitect/transit-clj/blob/master/README.md
>
>
> On Thu, Sep 25, 2014 at 6:56 AM, Bin Li > 
> wrote:
>
>> Hi Guys,
>>
>> I was playing around the transit library recently , that is what I did:
>>
>> On client side , which using tansit-cljs (*clojrescript*)  :
>>
>> (def w (t/writer :json))
>>
>>  (.send xhr
>>  url
>>  "POST"
>>  (transit/write w *{:test :test-value}*)
>>  #js {"Content-Type" "application/transit+json"})
>>  
>>
>> And from server side , using *clojure *:
>> I got the string like: *["^ ","~:test","~:test-value"]* 
>>
>>  The question is how can I read this transit'ed string back to a map ?
>>
>> Thanks in advance!
>>  
>> -- 
>> 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: Where can one find low hanging fruit for open source contribution?

[Beau Fabry]

LightTable, the editor written in Clojurescript is currently looking for 
contributors, and have started tagging issues as beginner friendly. 
https://github.com/LightTable/LightTable

On Saturday, September 27, 2014 4:34:19 PM UTC+10, kurofune wrote:
>
> I am an looking for a good, active, open source Clojure library/project to 
> contribute to, but am not sure where to start. Could somebody give an 
> intermediate level programmer a  few pointers as to where to begin? 
>

-- 
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: Where can one find low hanging fruit for open source contribution?

[António Monteiro]

this website has a weekly curated list of simple tasks to be done in open 
source Clojure projects (it appeared to me on HN the other day):
http://www.longstorm.org/weekly/cito/1/

Hope it helps.

On Friday, October 10, 2014 12:06:06 AM UTC+2, Michael Blume wrote:
>
> Agree with Michael Klishin, I've gotten a few patches into Leiningen as a 
> relative Clojure newb and the maintainers have been super friendly and 
> helpful.
>
> On Friday, September 26, 2014 11:45:18 PM UTC-7, Michael Klishin wrote:
>>
>> On 27 September 2014 at 10:34:28, kurofune (jessel...@gmail.com) wrote: 
>> > I am an looking for a good, active, open source Clojure library/project 
>> > to contribute to, but am not sure where to start. Could somebody 
>> > give an intermediate level programmer a few pointers as to where 
>> > to begin? 
>>
>> Leiningen has issues tagged "newbie" and its maintainers are some of the 
>> nicest 
>> people you'll find in open source: 
>>
>> https://github.com/technomancy/leiningen/labels/Newbie 
>>
>> Some (unfortunately, only a few to date) ClojureWerkz projects use a 
>> similar 
>> tag: 
>> https://github.com/clojurewerkz/elastisch/labels/low-hanging%20fruit 
>>
>> Ultimately I'd recommend contributing to either what you can easily see 
>> yourself 
>> using or something that sounds really interesting. Leiningen is something 
>> you will use if you use Clojure, which makes it a no-brainer. 
>> -- 
>> @michaelklishin, github.com/michaelklishin 
>>
>

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

Re: core.async: peek the next value from a channel without consuming it

[Leon Grapenthin]

On Thursday, October 9, 2014 10:25:38 PM UTC+2, Nahuel Greco wrote:
>
> Leon: your :useless example is equivalent to one using the hypothetical 
> peek operation and to the ack-channel solution, but what you define as 
> ":useless multithreading" because at one time only one thread is working, 
> is a valid synchronization scenario and the one I was searching for. The 
> objective here was not to max CPU usage with these two threads / go-blocks.
>

What I wanted to illustrate with useless multithreading was my earlier 
point that for your requirements I can't find a reason for multithreading 
and hence no reason for synchronization.
 

> As I said in a previous mail "maybe you want to reserve the cpu cycles 
> for other tasks, or the producer needs a confirmation for other purposes 
> before computing or requesting the value from another party, this is a 
> distilled example". 
>
What difference should this make? I have already integrated these 
requirements in my mail from Oct. 5. You can put the confirmation part 
between steps 3 and 4.
 

> Also think the producer after sending the computed value and before 
> sending the :useless signal can do other things, maybe contacting other 
> services to pre-fetch data used in the next value. 
>
 
 It could, because it is unblocked.

But i f you had used peek!, it couldn't. It would just have to pre-fetch 
its data and peek! would be blocked until its done and has produced a 
value. (I hope the discussion is still about finding a valid reason why 
peek! would be a useful operation in core.async)
 

>
> Also the :useless example needs more code on the producer side than a 
> simple (>! c v). Given there is no peek operation and the producer code 
> must participate explicitly in the synchronization, I prefer the ack 
> solution over the :useless one.
>
The producer must participate in the synchronization in the ack solution as 
well. There is no peek operation in the ack solution as well. 

You could as well let the producer put the value twice and every first take 
would be your peak. 

I don't recommend :useless or an ack channel as a "solution" over the 
other. My point is that if this problem was real, using multiple threads as 
a solution and the resulting effort to coordinate them so that only one of 
them would run at a time doesn't seem to provide benefits in terms of 
performance, abstraction or readability.


Kind regards,
 Leon.

You are right about impossibility of using alts! in the producer code to 
check if the chan can be written to before computing the value. I forgot 
alts! is a function, not a macro, and you can't pass expressions to it to 
be evaluated when the chan becomes available to write.

Your last sample seems an useful way to manage simple stateless 
single-value producers from the consumer, but producers can be long-running 
go-blocks with their own state and with channels to other services, so I 
think is a little off base the original question.

>
>
> Saludos,
> Nahuel Greco.
>
> On Thu, Oct 9, 2014 at 4:16 PM, Leon Grapenthin  > wrote:
>
>> On Thursday, October 9, 2014 2:22:50 PM UTC+2, Nahuel Greco wrote:
>>>
>>> Fluid: as you said, backpressure on the outgoing channel will be 
>>> sufficient to avoid producer to overrun consumer (without using any extra 
>>> ack-channel), but the producer will compute a new not-yet-used value before 
>>> blocking on sending it to consumer. That's what I want to avoid.
>>>
>>  
>> You can avoid this very easily. Everytime before the producer expensively 
>> calculates its next value to put it on the channel, make it put a cheaply 
>> calculated value, e. g. the keyword :useless, on the channel instead. 
>>
>> Now on the consumer side you can do this:
>>
>> 0. Blocking (immediate take): Consume the keyword :useless = The producer 
>> will begin production
>> 1. *This is what you want from peek! *Blocking take = Waiting for the 
>> producer to have produced the expensive value, consume it *but the 
>> producer won't calculate the next value (because he puts the :useless 
>> keyword which won't be consumed until later)*
>> 2. Wait for external service to be ready, put value there
>> 3. Go to step 1 trigger production of the next value
>>
>> Assuming the producer and the consumer run on different threads, what 
>> have you won by introducing step 0? 
>>
>> 1. The producer thread can't begin to work until the consumer thread did 
>> his work
>> 2. The consumer thread can't begin to work until the producer thread did 
>> his work
>>
>> = At every point in time only one thread performs. Entirely :useless 
>> multi-threading.
>>
>> I can also use alts! on the producer to check if he can write to the 
>>> channel before computing the value,  [...]
>>>
>> You can't 
>>
>>  
>>
>>> [...]
>>>
>>  
>>
>>> Fregal: If middleman is managing all the communication with the external 
>>> service for *multiple* producers, then it can't be reduced to a simple 
>>> synchronous function call from a producer, hence the

Re: ANN: State of Clojure 2014 Survey - please contribute!!

[Lee Spector]

FWIW I'm another person using Clojure mostly for academic research. And for 
computer science education, e.g. I'm currently teaching a Clojure-based AI 
course. I'd be curious to know how many others of us are out there. And BTW I 
think that attention to users in these categories could help to grow the 
community.

 -Lee

On Oct 9, 2014, at 12:32 AM, Mars0i  wrote:

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

-- 
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: Where can one find low hanging fruit for open source contribution?

[Michael Blume]

Agree with Michael Klishin, I've gotten a few patches into Leiningen as a 
relative Clojure newb and the maintainers have been super friendly and 
helpful.

On Friday, September 26, 2014 11:45:18 PM UTC-7, Michael Klishin wrote:
>
> On 27 September 2014 at 10:34:28, kurofune (jessel...@gmail.com 
> ) wrote: 
> > I am an looking for a good, active, open source Clojure library/project 
> > to contribute to, but am not sure where to start. Could somebody 
> > give an intermediate level programmer a few pointers as to where 
> > to begin? 
>
> Leiningen has issues tagged "newbie" and its maintainers are some of the 
> nicest 
> people you'll find in open source: 
>
> https://github.com/technomancy/leiningen/labels/Newbie 
>
> Some (unfortunately, only a few to date) ClojureWerkz projects use a 
> similar 
> tag: 
> https://github.com/clojurewerkz/elastisch/labels/low-hanging%20fruit 
>
> Ultimately I'd recommend contributing to either what you can easily see 
> yourself 
> using or something that sounds really interesting. Leiningen is something 
> you will use if you use Clojure, which makes it a no-brainer. 
> -- 
> @michaelklishin, github.com/michaelklishin 
>

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

Re: core.async: peek the next value from a channel without consuming it

[Nahuel Greco]

Leon: your :useless example is equivalent to one using the hypothetical
peek operation and to the ack-channel solution, but what you define as
":useless multithreading" because at one time only one thread is working,
is a valid synchronization scenario and the one I was searching for. The
objective here was not to max CPU usage with these two threads / go-blocks.
As I said in a previous mail "maybe you want to reserve the cpu cycles for
other tasks, or the producer needs a confirmation for other purposes before
computing or requesting the value from another party, this is a distilled
example". Also think the producer after sending the computed value and
before sending the :useless signal can do other things, maybe contacting
other services to pre-fetch data used in the next value.

Also the :useless example needs more code on the producer side than a
simple (>! c v). Given there is no peek operation and the producer code
must participate explicitly in the synchronization, I prefer the ack
solution over the :useless one.

You are right about impossibility of using alts! in the producer code to
check if the chan can be written to before computing the value. I forgot
alts! is a function, not a macro, and you can't pass expressions to it to
be evaluated when the chan becomes available to write.

Your last sample seems an useful way to manage simple stateless
single-value producers from the consumer, but producers can be long-running
go-blocks with their own state and with channels to other services, so I
think is a little off base the original question.


Saludos,
Nahuel Greco.

On Thu, Oct 9, 2014 at 4:16 PM, Leon Grapenthin 
wrote:

> On Thursday, October 9, 2014 2:22:50 PM UTC+2, Nahuel Greco wrote:
>>
>> Fluid: as you said, backpressure on the outgoing channel will be
>> sufficient to avoid producer to overrun consumer (without using any extra
>> ack-channel), but the producer will compute a new not-yet-used value before
>> blocking on sending it to consumer. That's what I want to avoid.
>>
>
> You can avoid this very easily. Everytime before the producer expensively
> calculates its next value to put it on the channel, make it put a cheaply
> calculated value, e. g. the keyword :useless, on the channel instead.
>
> Now on the consumer side you can do this:
>
> 0. Blocking (immediate take): Consume the keyword :useless = The producer
> will begin production
> 1. *This is what you want from peek! *Blocking take = Waiting for the
> producer to have produced the expensive value, consume it *but the
> producer won't calculate the next value (because he puts the :useless
> keyword which won't be consumed until later)*
> 2. Wait for external service to be ready, put value there
> 3. Go to step 1 trigger production of the next value
>
> Assuming the producer and the consumer run on different threads, what have
> you won by introducing step 0?
>
> 1. The producer thread can't begin to work until the consumer thread did
> his work
> 2. The consumer thread can't begin to work until the producer thread did
> his work
>
> = At every point in time only one thread performs. Entirely :useless
> multi-threading.
>
> I can also use alts! on the producer to check if he can write to the
>> channel before computing the value,  [...]
>>
> You can't
>
>
>
>> [...]
>>
>
>
>> Fregal: If middleman is managing all the communication with the external
>> service for *multiple* producers, then it can't be reduced to a simple
>> synchronous function call from a producer, hence the necessity of
>> core.async (the alternative is to descend to locks world).
>>
>
> If I understand you right, you would want to start production of multiple
> values in parallel, wait for the first to be ready, then put that to the
> external service and loop. Here core.async can be of help. E. g.
> (defn exp-calcs
>   []
>   #{(a/thread calc-exp-val-1)
> (a/thread calc-exp-val-2)
> (a/thread calc-exp-val-3)
> (a/thread calc-exp-val-4)
> (a/thread calc-exp-val-5)
> ; ...
> })
>
> (loop [chans (exp-calcs)]
>   (let [[val ch] (a/alts!! (seq exp-calcs))]
> ;; wait for external service, put val there
>
> ;; also have the cancellation ch in chans and use it to guard the
> ;; following form
> (let [chans (disj chans ch)]
>   (recur (if (seq chans)
>chans
>(exp-calcs))
>
>
>
> Again, no peek required.
>
>
>>
>>
>>
>> Saludos,
>> Nahuel Greco.
>>
>> On Thu, Oct 9, 2014 at 9:07 AM, Fergal Byrne 
>> wrote:
>>
>>> Hi Nahuel,
>>>
>>> I think it's worth stepping back from discussing solutions and have a
>>> look at the problem. If I'm reading things right you need the following:
>>>
>>> 1. Producer produces values one at a time - should not step until last
>>> value has been handled correctly elsewhere.
>>> 2. Middleman needs to consume one value and (potentially) retry an
>>> external service until it can verify correct handling.
>>> 3. Producer should not interpret the consumption of a value 

Re: Seeking Large Companies That Employ Clojure

[Sean Corfield]

That's very vague. Can you explain _why_ you want to talk to such users?

I'm in your target audience but I would not contact you based on such a vague 
post. My first reaction is you're trying to sell me something...

Sean

On Oct 9, 2014, at 12:13 PM, Jan Drake  wrote:
> You can learn a bit about me here.
> 
> I am looking to connect with engineering teams and managers of those teams 
> that are using Clojure in enterprise and/or web scale scenarios to discuss 
> various topics important to users of Clojure at scale, in production, etc.  
> If you are one, please contact me directly; if you know of one, please make 
> me an introduction.
> 
> Onward in the great Clojure Adventure!




signature.asc
Description: Message signed with OpenPGP using GPGMail

Seeking Large Companies That Employ Clojure

[Jan Drake]

Greetings,

You can learn a bit about me here .

I am looking to connect with engineering teams and managers of those teams 
that are using Clojure in enterprise and/or web scale scenarios to discuss 
various topics important to users of Clojure at scale, in production, etc. 
 If you are one, please contact me directly; if you know of one, please 
make me an introduction.

Onward in the great Clojure Adventure!


Regards,



Jan

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

[Leon Grapenthin]

On Thursday, October 9, 2014 2:22:50 PM UTC+2, Nahuel Greco wrote:
>
> Fluid: as you said, backpressure on the outgoing channel will be 
> sufficient to avoid producer to overrun consumer (without using any extra 
> ack-channel), but the producer will compute a new not-yet-used value before 
> blocking on sending it to consumer. That's what I want to avoid.
>
 
You can avoid this very easily. Everytime before the producer expensively 
calculates its next value to put it on the channel, make it put a cheaply 
calculated value, e. g. the keyword :useless, on the channel instead. 

Now on the consumer side you can do this:

0. Blocking (immediate take): Consume the keyword :useless = The producer 
will begin production
1. *This is what you want from peek! *Blocking take = Waiting for the 
producer to have produced the expensive value, consume it *but the producer 
won't calculate the next value (because he puts the :useless keyword which 
won't be consumed until later)*
2. Wait for external service to be ready, put value there
3. Go to step 1 trigger production of the next value

Assuming the producer and the consumer run on different threads, what have 
you won by introducing step 0? 

1. The producer thread can't begin to work until the consumer thread did 
his work
2. The consumer thread can't begin to work until the producer thread did 
his work

= At every point in time only one thread performs. Entirely :useless 
multi-threading.

I can also use alts! on the producer to check if he can write to the 
> channel before computing the value,  [...]
>
You can't 

 

> [...]
>
 

> Fregal: If middleman is managing all the communication with the external 
> service for *multiple* producers, then it can't be reduced to a simple 
> synchronous function call from a producer, hence the necessity of 
> core.async (the alternative is to descend to locks world). 
>
 
If I understand you right, you would want to start production of multiple 
values in parallel, wait for the first to be ready, then put that to the 
external service and loop. Here core.async can be of help. E. g. 
(defn exp-calcs
  []
  #{(a/thread calc-exp-val-1)
(a/thread calc-exp-val-2)
(a/thread calc-exp-val-3)
(a/thread calc-exp-val-4)
(a/thread calc-exp-val-5)
; ...
})

(loop [chans (exp-calcs)]
  (let [[val ch] (a/alts!! (seq exp-calcs))]
;; wait for external service, put val there

;; also have the cancellation ch in chans and use it to guard the
;; following form
(let [chans (disj chans ch)]
  (recur (if (seq chans)
   chans
   (exp-calcs))



Again, no peek required.
 

>
>
>
> Saludos,
> Nahuel Greco.
>
> On Thu, Oct 9, 2014 at 9:07 AM, Fergal Byrne  > wrote:
>
>> Hi Nahuel,
>>
>> I think it's worth stepping back from discussing solutions and have a 
>> look at the problem. If I'm reading things right you need the following:
>>
>> 1. Producer produces values one at a time - should not step until last 
>> value has been handled correctly elsewhere.
>> 2. Middleman needs to consume one value and (potentially) retry an 
>> external service until it can verify correct handling.
>> 3. Producer should not interpret the consumption of a value as a signal 
>> to proceed.
>>
>> You also seem to want the following:
>>
>> a. Use core.async
>> b. Make the solution "elegant"
>>
>> That's all fine, but it seems like a bit of a golden hammer. Your problem 
>> is precisely not the kind of problem core.async channels are designed to 
>> solve. Channels are there to provide decoupling of producer and consumer, 
>> whereas you, in fact, need the kind of coupling provide by function calls.
>>
>> Channels are for when you don't want to know how or when your product is 
>> handled. You're finished, you throw the product on a channel, and you move 
>> on to making your next product. All you ever find out is if/that your 
>> product has been picked off the channel.
>>
>> Function calls are for when you do need to know what happened to your 
>> product, and when it has all happened, because you can't move on until the 
>> last thing has been done.
>>
>> Just call the middleman in synchronous code in your producer, with one 
>> value, and look at its return value to tell you what to do next. You get 
>> your blocking semantics (1-3) and you also get information about success or 
>> failure. 
>>
>> Using channels, consumption is the only information the producer hears 
>> back. To tell the producer you've completed your mission as middleman, 
>> you'll need another channel. If you really want to use core.async:
>>
>> (>! c v) ; blocks until consumed
>> (respond-to (> ...do expensive stuff
>>
>> but this is just an expensive function call.
>>
>> Regards,
>>
>> Fergal Byrne
>>
>>
>> On Thu, Oct 9, 2014 at 11:16 AM, Eduard Bondarenko > > wrote:
>>
>>> I think the point is to not generate values by producer if external
>>> service is not available
>>> "The producer only unparks when the value is eff

[PSA] Rock the Clojure JIRA vote

[Andy Fingerhut]

Sorry, I know of no musicians who will perform at special events to rock
the Clojure JIRA vote.  Perhaps if some of the musicians among Cognitect
employees become inspired ...


Why vote?

It can make a difference in how soon Clojure tickets are addressed.

Quotes from Alex Miller:

"In particular I use votes to decide what gets triaged.  We also used votes
as a way to see which issues needed to be kept in [Clojure] 1.7 this week
vs pushed off to 1.8.  So I'm telling you (as the one that makes those
decisions), that it's useful. I look [at] those numbers every day." -- Alex
Miller (puredanger) on #clojure IRC log Oct 8 2014



How to vote:

If you already have a Clojure JIRA account, find a ticket you are
interested in and click on the "Vote" link near the top right of the page
describing the ticket.  If you created the ticket, you can't also vote for
it, so that link is disabled -- it is pretty clear already that you are in
favor of tickets you create.  You are allowed to persuade others to vote on
tickets.

If you don't have a JIRA account yet, you can create one by going to the
Clojure JIRA page [1].  If you see a "Log in" link near the top right of
the page, click on that, and then click the "Sign up" link on the next page
you reach.

There are various ways to search JIRA, the simplest of which is to type in
search terms in the Quick Search text box near the top right of the page.
No, that doesn't always instantly take you to the ticket that is most
relevant for what you want.  Feel free to ask on the Clojure Google group
if you are curious whether there is already a ticket for some issue, and
someone may be willing to answer.  If all you know is the number of a
ticket, e.g. CLJ-322, you can type that into the Quick Search box.

You can also see a report that I update a couple of times a week on the top
voted tickets, sorted by 'weighted vote' [2].  The HTML versions of those
reports have links to the tickets.  For Clojure and ClojureScript, those
reports do not list all open tickets (there are over 400 such tickets as of
today for Clojure), only ones that already have votes, or they have already
made some progress towards resolution (e.g. a Clojure screener has marked
the ticket as Triaged [3]).

Andy Fingerhut


[1] http://dev.clojure.org/jira/browse/CLJ
or if you lose the link, go to Google and enter the search: clojure jira

[2] http://jafingerhut.github.io/clj-ticket-status/clojure-ticket-info.html
or enter the Google search: clojure top voted
and you should see early search result that links to that page, plus
another relevant one implemented as a JIRA search query

[3] For more info on what the states of Clojure tickets mean, and the
workflow, see http://dev.clojure.org/display/community/JIRA+workflow

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

[Nahuel Greco]

Fergal: readability when using an ack channel is improved, you are totally
right on this point and is probably the most important argument for using
acks, besides there is no peek currently on core.async (note if you have a
long producer-consumer1-consumerN chain everyone must implement the ack
procedure). But I think you are wrong when you say a middleman using peek
can only support a single product at time and no multiple producers
batching. Without thinking about producer code form, peeking + consuming
(implicit "ack") is the same thing as doing consuming + explicit ack. Sure,
you need a multiple channels alts!-like peek operation. What can change the
equation is to use a single ack per multiple values, I think peek can't
support something like that, but that also changes the design of the
producer code.

Note "waiting until the service is ready before taking from the channel"
without using acks or peek+consume can introduce race conditions where the
service goes down just after sensing it ready and consuming the producer
value.

Just to be clear, I know acks solves this (changing producer code), and I
currently use an acks schema. I'm only curious about why a peek operation
wasn't included in core.async and the feasibility of adding it.

Thanks for your replies.

Saludos,
Nahuel Greco.

On Thu, Oct 9, 2014 at 11:04 AM, Fergal Byrne 
wrote:

> Hi Nahuel,
>
> If you look at the definition of "simple" it means "not compound". In your
> case, you are trying to have a single thing (the channel) do two jobs:
> convey the value, and control the producer. This is not simple, and makes
> the producer trust that the middleman will always respect this hidden
> dependence. It also hides your intent elsewhere (anyone reading your code
> would assume that the producer does not have to wait).
>
> In this case (the ack channel), you are adding a couple of lines of code
> (to make the ack channel and to block until it comes back), but you are
> simplifying the producer when you do this, not complicating it. The (!< c
> [v ack]) does one thing - I'm finished my expensive op, please deal with
> it. The (respond-to ( been processed, now I can move on.
>
> The code is self-documenting. The producer finishes its work, puts the
> stuff on a channel with a self-addressed envelope, and then immediately
> blocks for the ack. It couldn't possibly be simpler than this.
>
> The decoupling channels provide is exactly that: everything except
> backpressure is decoupled. You're trying to recouple the producer and
> middleman, by trying to make a non-atomic thing atomic.
>
> You're also designing the middleman based on the needs of the producer.
> With your design, the middleman can only handle one product at a time. With
> the put-ack design, the middleman could have a longer queue, construct
> batches of similar values, and more efficiently use the external service.
> You're also creating a bottleneck, because other producers are all blocked
> until your middleman has got the external service to work with your value.
>
> Either the external service's ability to complete is based on something in
> your value or not. If not, then have the middleman wait until the service
> is ready (as someone suggested) before taking from the channel - this
> achieves your goals with backpressure. If you do need to know something in
> the value, then take the value and spin up a go block to retry the service
> (passing it the ack channel, so it can unblock the producer), and move on.
>
> Adding peek to channels couldn't be hard (it's open source after all!), so
> you could do it for yourself if you think it would give you any value. But
> I can give you a fairly precise estimate on how long a PR for this would
> sit in Rich's in-tray..
>
> Cheers,
>
> Fergal
>
>
> On Thu, Oct 9, 2014 at 2:01 PM, Nahuel Greco  wrote:
>
>> Fergal: I knew about the ack channel solution (note I mentioned it a
>> while couple of mails ago), I was trying to avoid it with the objective of
>> making the producer code extra simple.
>>
>> Also note, in core.async the producers aren't totally decoupled from
>> consumers, there is an implicit consumer->producer signalling in the form
>> of channel backpressure. The only way to decouple them totally is to use
>> "infinitely" sized or dropping queues (something like Erlang tries to do
>> given enough memory, where the only form of backpressure are explicit
>> acks). The peek operation I proposed is a way to fine control that
>> backpressure signalling.
>>
>> In POSIX the select() operation doesn't peeks the value but can be used
>> to know if there is a value present without consuming it. In contrast, I
>> think alts! complects three operations: 1- blocking until new value / can
>> write one 2- reading/putting it 3- when reading, consuming it.
>>
>> Besides the alternative solutions for the producer code (waiting on ack
>> channel, alts! before computing the value) my original question remains
>> unanswered: There is something in 

Re: [PSA] Clojars scp disabled until further notice

[Eric Normand]

Hey Nelson,

I would love to help out with raising funds for Clojars. I've got a great 
idea that I need to talk to you about. I can provide execution and 
promotion.

Let's talk.

Eric

On Wednesday, October 8, 2014 7:49:38 PM UTC-5, Bridget wrote:
>
>
>
> 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: help with sequence, "seq", Seq, and `seq`

[John Gabriele]

On Thursday, October 9, 2014 10:38:42 AM UTC-4, Gary Verhaegen wrote:
>
> I have not checked the second edition yet, but when I read JoC, my 
> understanding was that seq is used specifically for an object that 
> implements ISeq and is used as such (i.e. by calling first and rest on it) 
> while sequence denotes any ordered collection.
>
> Under this interpretation, they are not interchangeable: seqs are not 
> collections, so they can't be sequences, and sequences are not seqs (though 
> most of them can be turned into seqs). Some non-sequences may also be 
> converted to seqs.
>
>
"seqs are not collections"? Yow, that doesn't make any sense to me.

~~~clojure
(coll? [])
;;=> true
(coll? (seq []))
;;=> false
;; `map` returns a seq, right?
(class (map identity (range 3)))
;;=> clojure.lang.LazySeq
(coll? (map identity (range 3)))
;;=> true
~~~

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

On 9 October 2014 15:38, Gary Verhaegen  wrote:

> I have not checked the second edition yet, but when I read JoC, my
> understanding was that seq is used specifically for an object that
> implements ISeq and is used as such (i.e. by calling first and rest on it)
> while sequence denotes any ordered collection.


Ah, okay, so they're using "sequence" to denote sequential collections. I
guess "sequences" is a better noun than "sequentials" for that purpose.

- James

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

[Gary Verhaegen]

I have not checked the second edition yet, but when I read JoC, my
understanding was that seq is used specifically for an object that
implements ISeq and is used as such (i.e. by calling first and rest on it)
while sequence denotes any ordered collection.

Under this interpretation, they are not interchangeable: seqs are not
collections, so they can't be sequences, and sequences are not seqs (though
most of them can be turned into seqs). Some non-sequences may also be
converted to seqs.

Map, filter et al. were thus defined as taking seqs as arguments, although
they converted if needed.

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

On 9 October 2014 03:55, 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."
>
> 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?
>

To me, that looks like they accidentally wrote "sequence" when they meant
"list":

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

- James

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

[Fergal Byrne]

Hi Nahuel,

If you look at the definition of "simple" it means "not compound". In your
case, you are trying to have a single thing (the channel) do two jobs:
convey the value, and control the producer. This is not simple, and makes
the producer trust that the middleman will always respect this hidden
dependence. It also hides your intent elsewhere (anyone reading your code
would assume that the producer does not have to wait).

In this case (the ack channel), you are adding a couple of lines of code
(to make the ack channel and to block until it comes back), but you are
simplifying the producer when you do this, not complicating it. The (!< c
[v ack]) does one thing - I'm finished my expensive op, please deal with
it. The (respond-to ( wrote:

> Fergal: I knew about the ack channel solution (note I mentioned it a while
> couple of mails ago), I was trying to avoid it with the objective of making
> the producer code extra simple.
>
> Also note, in core.async the producers aren't totally decoupled from
> consumers, there is an implicit consumer->producer signalling in the form
> of channel backpressure. The only way to decouple them totally is to use
> "infinitely" sized or dropping queues (something like Erlang tries to do
> given enough memory, where the only form of backpressure are explicit
> acks). The peek operation I proposed is a way to fine control that
> backpressure signalling.
>
> In POSIX the select() operation doesn't peeks the value but can be used to
> know if there is a value present without consuming it. In contrast, I think
> alts! complects three operations: 1- blocking until new value / can write
> one 2- reading/putting it 3- when reading, consuming it.
>
> Besides the alternative solutions for the producer code (waiting on ack
> channel, alts! before computing the value) my original question remains
> unanswered: There is something in core.async implementation/design/roadmap
> preventing adding a peek operation? I was hoping to avoid a deep dive on
> core.async code :)
>
>
>
> Saludos,
> Nahuel Greco.
>
> On Thu, Oct 9, 2014 at 9:39 AM, Fergal Byrne 
> wrote:
>
>> Hi Nahuel,
>>
>> Thanks for the clarification. Multiple producers, single middleman is a
>> different problem from the one we (or at least I) thought we were dealing
>> with. In that case, the put your ack channel in your product, block on the
>> ack channel method is the right one.
>>
>> (loop [...]
>> ..something expensive...
>>   (let [ack (chan)]
>> (>! c [v ack])
>> (respond-to (> (recur ...))
>>
>> Regards,
>>
>> Fergal
>>
>> On Thu, Oct 9, 2014 at 1:21 PM, Nahuel Greco  wrote:
>>
>>> Fluid: as you said, backpressure on the outgoing channel will be
>>> sufficient to avoid producer to overrun consumer (without using any extra
>>> ack-channel), but the producer will compute a new not-yet-used value before
>>> blocking on sending it to consumer. That's what I want to avoid.
>>>
>>> I can also use alts! on the producer to check if he can write to the
>>> channel before computing the value, but I wanted to keep the code in the
>>> producer in the simplest form possible (a simple (>! c v) parking until all
>>> parties consume the value, avoiding an ack-chan or an alts!) .
>>>
>>> Eduard: Exactly.
>>>
>>> Fregal: If middleman is managing all the communication with the external
>>> service for *multiple* producers, then it can't be reduced to a simple
>>> synchronous function call from a producer, hence the necessity of
>>> core.async (the alternative is to descend to locks world).
>>>
>>>
>>>
>>> Saludos,
>>> Nahuel Greco.
>>>
>>> On Thu, Oct 9, 2014 at 9:07 AM, Fergal Byrne <
>>> fergalbyrnedub...@gmail.com> wrote:
>>>
 Hi Nahuel,

 I think it's worth stepping back from discussing solutions and have a
 look at the problem. If I'm reading things right you need the following:

 1. Producer produces values one at a time - should not step until last
 value has been handled correctly elsewhere.
 2. Middleman needs to consume one value and (potentially) retry an
 external service until it can verify correct handling.
 3. Producer should not interpret the consumption of a value as a signal
 to proceed.

 You also seem to want the following:

 a. Use core.async
 b. Make the solution "elegant"

 That's all fine, but it seems like a bit of a golden hammer. Your
 problem is precisely not the kind of problem core.async channels are
 designed to solve. Channels are there to provide decoupling of producer and
 consumer, whereas you, in fact, need the kind of coupling provide by
 function calls.

 Channels are for when you don't want to know how or when your product
 is handled. You're finished, you throw the product on a channel, and you
 move on to making your next product. All you ever find out is if/that your
 product has been picked off the channel.

 Function calls are for when you do need to know what happen

Requiring namespaces *just* to register multimethod implementations?

[Laurens Van Houtven]

I am writing some software that is essentially an interpreter for 
structures called plans, which are either:

- steps, maps that have a specific way of handling them based on their 
:type. Examples include e.g. make a http request, which would look like 
{:type :http :url "http://whatever"; :method :put}.
- sets of plans (recursive)
- vectors of plans (recursive)

So, eventually, it's steps at the "leaves", and then there's a recursive 
tree-like structure organizing them (except that some branches are ordered, 
and some are unordered).

For example:

[#{{:type :x :temperature 30}
   {:type :y :color "#dfcdfc"}}
 {:type :log :message "Success!"}]

... which means "do :x with temperature 30 and :y with color #dfcdfc 
concurrently. When you're done with both, log a success message.". It's a 
little trickier than that (failure etc), but that's the gist of it.

Right now, I'm doing this with a multimethod. Dispatching happens based on 
if it's a set, vector or a step:

  (fn [x] (cond (set? x) ::unordered-plans
   (vector? x) ::ordered-plans
   :else (:type x)))

That works, but implementations are in different namespaces, so I find 
myself requiring namespaces for the side-effect. It works, but it's not 
great. I guess maybe I'm abusing multimethods. Additional considerations:

- I would like to not have to manage a manual list of things I'm 
:require-ing, but instead just automagically :require all the stuff in 
myproject.handlers.* namespaces.
- I would like people to be able to write their own implementations; so I 
guess I need to be able to namespaces as configuration as well.
- I *think* I want these handlers to be configurable so that people can 
choose to drop support for some of them, in which case "works if it has 
been :require'd" sounds like it maybe isn't the best API.

Any guidance is appreciated. Maybe I should make it register all 
*available* handlers in an atom-wrapped map internally, or something.

thanks in advance,
lvh

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

On Thursday, October 9, 2014 12:51:47 AM UTC-4, Ambrose Bonnaire-Sergeant 
wrote:
>
> 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.

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

[Nahuel Greco]

Fergal: I knew about the ack channel solution (note I mentioned it a while
couple of mails ago), I was trying to avoid it with the objective of making
the producer code extra simple.

Also note, in core.async the producers aren't totally decoupled from
consumers, there is an implicit consumer->producer signalling in the form
of channel backpressure. The only way to decouple them totally is to use
"infinitely" sized or dropping queues (something like Erlang tries to do
given enough memory, where the only form of backpressure are explicit
acks). The peek operation I proposed is a way to fine control that
backpressure signalling.

In POSIX the select() operation doesn't peeks the value but can be used to
know if there is a value present without consuming it. In contrast, I think
alts! complects three operations: 1- blocking until new value / can write
one 2- reading/putting it 3- when reading, consuming it.

Besides the alternative solutions for the producer code (waiting on ack
channel, alts! before computing the value) my original question remains
unanswered: There is something in core.async implementation/design/roadmap
preventing adding a peek operation? I was hoping to avoid a deep dive on
core.async code :)



Saludos,
Nahuel Greco.

On Thu, Oct 9, 2014 at 9:39 AM, Fergal Byrne 
wrote:

> Hi Nahuel,
>
> Thanks for the clarification. Multiple producers, single middleman is a
> different problem from the one we (or at least I) thought we were dealing
> with. In that case, the put your ack channel in your product, block on the
> ack channel method is the right one.
>
> (loop [...]
> ..something expensive...
>   (let [ack (chan)]
> (>! c [v ack])
> (respond-to ( (recur ...))
>
> Regards,
>
> Fergal
>
> On Thu, Oct 9, 2014 at 1:21 PM, Nahuel Greco  wrote:
>
>> Fluid: as you said, backpressure on the outgoing channel will be
>> sufficient to avoid producer to overrun consumer (without using any extra
>> ack-channel), but the producer will compute a new not-yet-used value before
>> blocking on sending it to consumer. That's what I want to avoid.
>>
>> I can also use alts! on the producer to check if he can write to the
>> channel before computing the value, but I wanted to keep the code in the
>> producer in the simplest form possible (a simple (>! c v) parking until all
>> parties consume the value, avoiding an ack-chan or an alts!) .
>>
>> Eduard: Exactly.
>>
>> Fregal: If middleman is managing all the communication with the external
>> service for *multiple* producers, then it can't be reduced to a simple
>> synchronous function call from a producer, hence the necessity of
>> core.async (the alternative is to descend to locks world).
>>
>>
>>
>> Saludos,
>> Nahuel Greco.
>>
>> On Thu, Oct 9, 2014 at 9:07 AM, Fergal Byrne > > wrote:
>>
>>> Hi Nahuel,
>>>
>>> I think it's worth stepping back from discussing solutions and have a
>>> look at the problem. If I'm reading things right you need the following:
>>>
>>> 1. Producer produces values one at a time - should not step until last
>>> value has been handled correctly elsewhere.
>>> 2. Middleman needs to consume one value and (potentially) retry an
>>> external service until it can verify correct handling.
>>> 3. Producer should not interpret the consumption of a value as a signal
>>> to proceed.
>>>
>>> You also seem to want the following:
>>>
>>> a. Use core.async
>>> b. Make the solution "elegant"
>>>
>>> That's all fine, but it seems like a bit of a golden hammer. Your
>>> problem is precisely not the kind of problem core.async channels are
>>> designed to solve. Channels are there to provide decoupling of producer and
>>> consumer, whereas you, in fact, need the kind of coupling provide by
>>> function calls.
>>>
>>> Channels are for when you don't want to know how or when your product is
>>> handled. You're finished, you throw the product on a channel, and you move
>>> on to making your next product. All you ever find out is if/that your
>>> product has been picked off the channel.
>>>
>>> Function calls are for when you do need to know what happened to your
>>> product, and when it has all happened, because you can't move on until the
>>> last thing has been done.
>>>
>>> Just call the middleman in synchronous code in your producer, with one
>>> value, and look at its return value to tell you what to do next. You get
>>> your blocking semantics (1-3) and you also get information about success or
>>> failure.
>>>
>>> Using channels, consumption is the only information the producer hears
>>> back. To tell the producer you've completed your mission as middleman,
>>> you'll need another channel. If you really want to use core.async:
>>>
>>> (>! c v) ; blocks until consumed
>>> (respond-to (>> ...do expensive stuff
>>>
>>> but this is just an expensive function call.
>>>
>>> Regards,
>>>
>>> Fergal Byrne
>>>
>>>
>>> On Thu, Oct 9, 2014 at 11:16 AM, Eduard Bondarenko 
>>> wrote:
>>>
 I think the point is to not generate values by producer if e

Re: core.async: peek the next value from a channel without consuming it

[Fergal Byrne]

Hi Nahuel,

Thanks for the clarification. Multiple producers, single middleman is a
different problem from the one we (or at least I) thought we were dealing
with. In that case, the put your ack channel in your product, block on the
ack channel method is the right one.

(loop [...]
..something expensive...
  (let [ack (chan)]
(>! c [v ack])
(respond-to ( wrote:

> Fluid: as you said, backpressure on the outgoing channel will be
> sufficient to avoid producer to overrun consumer (without using any extra
> ack-channel), but the producer will compute a new not-yet-used value before
> blocking on sending it to consumer. That's what I want to avoid.
>
> I can also use alts! on the producer to check if he can write to the
> channel before computing the value, but I wanted to keep the code in the
> producer in the simplest form possible (a simple (>! c v) parking until all
> parties consume the value, avoiding an ack-chan or an alts!) .
>
> Eduard: Exactly.
>
> Fregal: If middleman is managing all the communication with the external
> service for *multiple* producers, then it can't be reduced to a simple
> synchronous function call from a producer, hence the necessity of
> core.async (the alternative is to descend to locks world).
>
>
>
> Saludos,
> Nahuel Greco.
>
> On Thu, Oct 9, 2014 at 9:07 AM, Fergal Byrne 
> wrote:
>
>> Hi Nahuel,
>>
>> I think it's worth stepping back from discussing solutions and have a
>> look at the problem. If I'm reading things right you need the following:
>>
>> 1. Producer produces values one at a time - should not step until last
>> value has been handled correctly elsewhere.
>> 2. Middleman needs to consume one value and (potentially) retry an
>> external service until it can verify correct handling.
>> 3. Producer should not interpret the consumption of a value as a signal
>> to proceed.
>>
>> You also seem to want the following:
>>
>> a. Use core.async
>> b. Make the solution "elegant"
>>
>> That's all fine, but it seems like a bit of a golden hammer. Your problem
>> is precisely not the kind of problem core.async channels are designed to
>> solve. Channels are there to provide decoupling of producer and consumer,
>> whereas you, in fact, need the kind of coupling provide by function calls.
>>
>> Channels are for when you don't want to know how or when your product is
>> handled. You're finished, you throw the product on a channel, and you move
>> on to making your next product. All you ever find out is if/that your
>> product has been picked off the channel.
>>
>> Function calls are for when you do need to know what happened to your
>> product, and when it has all happened, because you can't move on until the
>> last thing has been done.
>>
>> Just call the middleman in synchronous code in your producer, with one
>> value, and look at its return value to tell you what to do next. You get
>> your blocking semantics (1-3) and you also get information about success or
>> failure.
>>
>> Using channels, consumption is the only information the producer hears
>> back. To tell the producer you've completed your mission as middleman,
>> you'll need another channel. If you really want to use core.async:
>>
>> (>! c v) ; blocks until consumed
>> (respond-to (> ...do expensive stuff
>>
>> but this is just an expensive function call.
>>
>> Regards,
>>
>> Fergal Byrne
>>
>>
>> On Thu, Oct 9, 2014 at 11:16 AM, Eduard Bondarenko 
>> wrote:
>>
>>> I think the point is to not generate values by producer if external
>>> service is not available
>>> "The producer only unparks when the value is effectively consumed by
>>> the external service. That's my objective."
>>>
>>> "external ready" channel here serves as a latch that stops producer
>>> generating value.
>>>
>>> On Thu, Oct 9, 2014 at 6:39 AM, Fluid Dynamics 
>>> wrote:
>>> > 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

Re: core.async: peek the next value from a channel without consuming it

[Nahuel Greco]

Fluid: as you said, backpressure on the outgoing channel will be sufficient
to avoid producer to overrun consumer (without using any extra
ack-channel), but the producer will compute a new not-yet-used value before
blocking on sending it to consumer. That's what I want to avoid.

I can also use alts! on the producer to check if he can write to the
channel before computing the value, but I wanted to keep the code in the
producer in the simplest form possible (a simple (>! c v) parking until all
parties consume the value, avoiding an ack-chan or an alts!) .

Eduard: Exactly.

Fregal: If middleman is managing all the communication with the external
service for *multiple* producers, then it can't be reduced to a simple
synchronous function call from a producer, hence the necessity of
core.async (the alternative is to descend to locks world).



Saludos,
Nahuel Greco.

On Thu, Oct 9, 2014 at 9:07 AM, Fergal Byrne 
wrote:

> Hi Nahuel,
>
> I think it's worth stepping back from discussing solutions and have a look
> at the problem. If I'm reading things right you need the following:
>
> 1. Producer produces values one at a time - should not step until last
> value has been handled correctly elsewhere.
> 2. Middleman needs to consume one value and (potentially) retry an
> external service until it can verify correct handling.
> 3. Producer should not interpret the consumption of a value as a signal to
> proceed.
>
> You also seem to want the following:
>
> a. Use core.async
> b. Make the solution "elegant"
>
> That's all fine, but it seems like a bit of a golden hammer. Your problem
> is precisely not the kind of problem core.async channels are designed to
> solve. Channels are there to provide decoupling of producer and consumer,
> whereas you, in fact, need the kind of coupling provide by function calls.
>
> Channels are for when you don't want to know how or when your product is
> handled. You're finished, you throw the product on a channel, and you move
> on to making your next product. All you ever find out is if/that your
> product has been picked off the channel.
>
> Function calls are for when you do need to know what happened to your
> product, and when it has all happened, because you can't move on until the
> last thing has been done.
>
> Just call the middleman in synchronous code in your producer, with one
> value, and look at its return value to tell you what to do next. You get
> your blocking semantics (1-3) and you also get information about success or
> failure.
>
> Using channels, consumption is the only information the producer hears
> back. To tell the producer you've completed your mission as middleman,
> you'll need another channel. If you really want to use core.async:
>
> (>! c v) ; blocks until consumed
> (respond-to ( ...do expensive stuff
>
> but this is just an expensive function call.
>
> Regards,
>
> Fergal Byrne
>
>
> On Thu, Oct 9, 2014 at 11:16 AM, Eduard Bondarenko 
> wrote:
>
>> I think the point is to not generate values by producer if external
>> service is not available
>> "The producer only unparks when the value is effectively consumed by
>> the external service. That's my objective."
>>
>> "external ready" channel here serves as a latch that stops producer
>> generating value.
>>
>> On Thu, Oct 9, 2014 at 6:39 AM, Fluid Dynamics 
>> wrote:
>> > 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 a topic in the
>> > Google Groups "Clojure" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/clojure/QbiwXYDw6oA/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.
>>
>> --
>> Y

Re: core.async: peek the next value from a channel without consuming it

[Fergal Byrne]

Hi Nahuel,

I think it's worth stepping back from discussing solutions and have a look
at the problem. If I'm reading things right you need the following:

1. Producer produces values one at a time - should not step until last
value has been handled correctly elsewhere.
2. Middleman needs to consume one value and (potentially) retry an external
service until it can verify correct handling.
3. Producer should not interpret the consumption of a value as a signal to
proceed.

You also seem to want the following:

a. Use core.async
b. Make the solution "elegant"

That's all fine, but it seems like a bit of a golden hammer. Your problem
is precisely not the kind of problem core.async channels are designed to
solve. Channels are there to provide decoupling of producer and consumer,
whereas you, in fact, need the kind of coupling provide by function calls.

Channels are for when you don't want to know how or when your product is
handled. You're finished, you throw the product on a channel, and you move
on to making your next product. All you ever find out is if/that your
product has been picked off the channel.

Function calls are for when you do need to know what happened to your
product, and when it has all happened, because you can't move on until the
last thing has been done.

Just call the middleman in synchronous code in your producer, with one
value, and look at its return value to tell you what to do next. You get
your blocking semantics (1-3) and you also get information about success or
failure.

Using channels, consumption is the only information the producer hears
back. To tell the producer you've completed your mission as middleman,
you'll need another channel. If you really want to use core.async:

(>! c v) ; blocks until consumed
(respond-to ( wrote:

> I think the point is to not generate values by producer if external
> service is not available
> "The producer only unparks when the value is effectively consumed by
> the external service. That's my objective."
>
> "external ready" channel here serves as a latch that stops producer
> generating value.
>
> On Thu, Oct 9, 2014 at 6:39 AM, Fluid Dynamics  wrote:
> > 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 a topic in the
> > Google Groups "Clojure" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/clojure/QbiwXYDw6oA/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.
>



-- 

Fergal Byrne, Brenter IT

http://inbits.com - Better Living through Thoughtful Technology
http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne

Founder of Clortex: HTM in Clojure -
https://github.com/nupic-community/clortex

Author, Real Machine Intelligence with Clortex and NuPIC
Read for free or buy the book at https://leanpub.com/realsmartmachines

Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014:
http://euroclojure.com/2014/
and at LambdaJam Chicago, July 2014: http:

Re: Profiling in Counterclockwise

[Gary Verhaegen]

On Sunday, 5 October 2014, Fluid Dynamics  wrote:

> On Sunday, October 5, 2014 3:57:37 PM UTC-4, Gary Verhaegen wrote:
>>
>> When I need to profile (which is asmittedly quite rare), I use VisualVM,
>> which should have been installed along with the JDK. I'd recommend editing
>> the default settings to remove clojure.** and add your own namespaces as
>> starting points for the profiling.
>>
>> For more lightweight approaches, I'd suggest checking out Timbre and
>> Criterium, though I have very little experience with both.
>>
>>
>> None of this is Eclipse specific or runs in Eclipse.
>>
>
> So, what you're saying is that I'd have to
>
> 1) Package everything up
> 2) Deploy to somewhere
> 3) Learn how to use  classpath configuration and stuff>
> 4) Identify hot spots
> 5) Make improvement of some sort
> 6) Back to step 1?
>
> Because that seems to *completely eliminate* the benefit of having a REPL
> and fast development/try things/edit cycle. :(
>
> Meanwhile, why did I get google results for a supposed "Profiling and
> Logging perspective" in Eclipse if no such thing exists?
>

No, I was not saying anything like that. My message was perhaps a bit
terse, so here are a few more details.

* VisualVM, as others have pointed out, is a very easy to use, graphical
profiling tool distributed by Oracle as part of the JDK (some Linux distros
have a separate package for it). It is an executable that requires no
classpath mucking and is completely external to your application (no
classpath, bo dependencies, etc.). Once it opens, it lists all of the
currently running JVMs on your machine, which should include your REPL, and
can connect to them and start profiling without any modification on your
code or workflow. It does require some dynamic bytecode modifications which
take some time, and it does make your code run a bit slower. It is the
easiest approach I know of for a one time, hit and run kind of profiling.

* Criterium is a microbenchmarking library. You can use it to run some
benchmarks from you REPL for targeted profiling, but you can also integrate
it into your test suite and collect historical results from your
build/integration system. It can also return its results as data so you can
actually test your performance (although if done naively this can lead to
very fragile tests that depend on the computer they are running on and its
current load).

* Timbre is a logging library, which also has features to colloect
performance metrics on your running application. This may be more in the
monitoring space than the profiling one, but it is nonetheless related and
interesting to know about as an option. (It is meant to collect these
metrics in production.)

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

Re: Understanding how a collection reduce itself

[Hussein B.]

Thank you all and especially @James. That is exactly what I'm missing.
Thanks again for help.

On Wednesday, September 24, 2014 5:51:09 PM UTC+2, James Reeves wrote:
>
> Reducers primarily have two benefits:
>
> 1. You don't need to create intermediate seqs
> 2. You can use them to perform a parallel fold
>
> When you use clojure.core/map, it creates a lazy seq. When you use 
> clojure.core.reducers/map, it returns a small reified object that 
> implements CollReduce.
>
> Perhaps the best way to understand what's going on is to start with the 
> normal seq functions. For instance, consider this code:
>
> (let [ys (map inc xs)]
>   (filter even? ys))
>
> In this example, an intermediate seq, ys, needs to be constructed.
>
> We can avoid this intermediate seq by using a reduce that combines both 
> steps:
>
> (reduce (fn [r x] (if (even? x) (conj r (inc x)) r) [] xs)
>
> The problem with this approach is that it's rather complected. What we 
> need is something that resolves to a reduce, but can be combined like map 
> and filter. This is where reducers come in.
>
> The main idea is to factor out that pesky conj, so we can separating the 
> reduction from the implementation details of the collection. So we can take 
> the inner reducing function:
>
> (fn [r x] (if (even? x) (conj r (inc x)) r)
>
> And then factor out conj:
>
> (fn [f] (fn [r x] (if (even? x) (f r (inc x)) r))
>
> We can then split out the filter and map to get two functions
>
> (fn [f] (fn [r x] (if (even? x) (f r x) r))
> (fn [f] (fn [r x] (f r (inc x)))
>
> And then take out even? and inc to get generic filter and map functions:
>
> (defn filterer [xf] (fn [f] (fn [r x] (if (xf x) (f r x) r))
> (defn mapper   [xf] (fn [f] (fn [r x] (f r (xf x)))
>
> So now we have the essence of map and filter, but we've removed the 
> implementation details of the collection. 
>
> Next we just need to figure out how to use these highly abstracted 
> functions. If we just want to use one of the functions, we can do so like 
> this:
>
> ((mapper inc) conj)
>
> This returns a function:
>
> (fn [r x] (conj r (inc x)))
>
> If we want to combine map and filter, we need an expression like:
>
> (fn [r x] (if (even? x) (conj r (inc x)) r))
>
> We can do this by passing the result of the mapping function into filterer 
> as f:
>
> ((filterer even?) ((mapper inc) conj))
>
> Or, we could use comp to compose the two functions, then apply conj, since 
> (f (g x)) is the same as ((comp f g) x):
>
> ((comp (filterer even?) (mapper inc)) conj))
>
> Now we can can finally create our efficient map/filter in a clean way:
>
> (let [f (comp (filterer even?)
>   (mapper inc))]
>   (reduce (f conj) [] xs))
>
> The reducer library goes one step further, and uses protocols to make it a 
> little nicer to use, but the mechanics are more or less the same.
>
> - James
>
>
> On 24 September 2014 15:30, Hussein B. > 
> wrote:
>
>> To elaborate more,
>> I know that with reducers, map for example isn't going to create the 
>> resulting sequence by using cons. That is clear to me.
>> But, if the collections is going to call cons while reducing itself, then 
>> I'm not sure what is the benefit of reducers (besides it makes sense and 
>> makes a nice abstraction).
>>
>> Thanks.
>>
>> On Wednesday, September 24, 2014 2:58:18 PM UTC+2, Aleš Roubíček wrote:
>>
>>> Resulting function is passed to reduction function as an recipe, how to 
>>> process the data. Collections implements CollReduce protocol. When you call 
>>> reduce function it will delegate the work to concrete implementation of the 
>>> protocol.
>>
>>  -- 
>> 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 

Re: core.async: peek the next value from a channel without consuming it

[Eduard Bondarenko]

I think the point is to not generate values by producer if external
service is not available
"The producer only unparks when the value is effectively consumed by
the external service. That's my objective."

"external ready" channel here serves as a latch that stops producer
generating value.

On Thu, Oct 9, 2014 at 6:39 AM, Fluid Dynamics  wrote:
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/QbiwXYDw6oA/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: Profiling in Counterclockwise

[Christophe Grand]

To profile whithin Eclipse you need to have the TPTP pugin installed
http://www.eclipse.org/tptp/.
That said, I *never* managed to have it work (I haven't tried for at least
two years), launching from Eclipse as usual and connecting an external
profiler (VisualVM or Yourkit works fine -- Yourkit even offers some simple
integration with eclipse run configurations).

When profiling Clojure code I always start by sampling object allocation
(with stack traces recorded) before looking at CPU usage.

Christophe

On Sun, Oct 5, 2014 at 10:38 PM, Fluid Dynamics  wrote:

> On Sunday, October 5, 2014 3:57:37 PM UTC-4, Gary Verhaegen wrote:
>>
>> When I need to profile (which is asmittedly quite rare), I use VisualVM,
>> which should have been installed along with the JDK. I'd recommend editing
>> the default settings to remove clojure.** and add your own namespaces as
>> starting points for the profiling.
>>
>> For more lightweight approaches, I'd suggest checking out Timbre and
>> Criterium, though I have very little experience with both.
>>
>>
>> None of this is Eclipse specific or runs in Eclipse.
>>
>
> So, what you're saying is that I'd have to
>
> 1) Package everything up
> 2) Deploy to somewhere
> 3) Learn how to use  classpath configuration and stuff>
> 4) Identify hot spots
> 5) Make improvement of some sort
> 6) Back to step 1?
>
> Because that seems to *completely eliminate* the benefit of having a REPL
> and fast development/try things/edit cycle. :(
>
> Meanwhile, why did I get google results for a supposed "Profiling and
> Logging perspective" in Eclipse if no such thing exists?
>
>  --
> 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.
>



-- 
On Clojure http://clj-me.cgrand.net/
Clojure Programming http://clojurebook.com
Training, Consulting & Contracting http://lambdanext.eu/

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