Re: core.async count in a channel

[Paul Viola]

@Meikel, I like your solution.  Its key advantage is that you have enable 
arbitrary functionality in the "monitoring" of a channel.  Since I am new 
to Clojure, and I bet others are too, I was subconsciously thinking about 
creating a new kind of channel (monitored channel).  This solution does 
something similar, by defining a new output channel that is a copy of the 
previous channel while enabling monitoring.  You've done this without a new 
type of class.

I particularly like this better than simply adding "count" because it 
solves the problem of *when* to call count for monitoring.  Your code calls 
count iff count changes.

Regardless of implementation, a monitored channel is a good thing.  Not all 
channels have zero queue.  

Thanks,
Paul

On Friday, January 17, 2014 2:54:47 AM UTC-8, t x wrote:
>
> @Meikel: I am now convinced that you are right. It's clear to me that I 
> completely underestimated the power / flexibility of the Channel 
> abastraction.
>
> @World: I now retract my second-ing of "adding count to Protocol of 
> Channel"
>
>
> On Fri, Jan 17, 2014 at 2:10 AM, Meikel Brandmeyer (kotarak) <
> m...@kotka.de > wrote:
>
>> Hi again,
>>
>> and some more golfing by Christophe:
>>
>> (defn queue-process-uncontrolled
>>   [input output stats]
>>   (async/go
>> (loop [q clojure.lang.PersistentQueue/EMPTY]
>>   (let [[val-to-q ch] (async/alts! 
>> (if-let [v (peek q)]
>>   [input [output v]]
>>   [input]))]
>> (swap! stats update-stats-as-you-see-fit q)
>> (cond
>>   ; Read a value from input.
>>   val-to-q (recur (conj q val-to-q))
>> ; Input channel is closed. => drain queue.
>>   (identical? ch input) (doseq [v q] (async/>! output v))
>>  
>>   ; Write happened.
>>   :else (recur (pop q)
>>  
>> (defn queue-process-controlled
>>   [input stats]
>>   (let [output  (async/chan)
>> process (queue-process-uncontrolled input output stats)]
>> (async/go
>>   (>   (async/close! output))
>> output))
>>
>>
>> Plus an improvement for the closing of the output channel. 
>> queue-process-uncontrolled is not necessarily the master of the channel.
>>
>> Meikel
>>
>>  -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: liberator video, compression question

[Leonardo Borges]

beat me to it.

But yes, that's also what I got from the talk.

Leonardo Borges
www.leonardoborges.com


On Sun, Jan 19, 2014 at 12:40 PM, Brian Craft  wrote:

> http://www.youtube.com/watch?v=OEZZOz6__CY
>
> At about 30 min he mentions that gzip, etc. aren't so interesting here
> because we can use, um.. something transfer, proxies... don't know what
> he's saying. Anyone know what he's talking about?
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: liberator video, compression question

[Benjamin R. Haskell]

On Sat, 18 Jan 2014, Brian Craft wrote:


http://www.youtube.com/watch?v=OEZZOz6__CY

At about 30 min he mentions that gzip, etc. aren't so interesting here 
because we can use, um.. something transfer, proxies... don't know 
what he's saying. Anyone know what he's talking about?


Slide for context:

{:media-type "application/edn"
 :language "de"
 :charset "UTF-8"
 :encoding "deflate"}

With that on-screen, he says:

"""
...and we have an encoding, which can be for example, deflate or gzip or 
like that, um, which we don't care about a lot, I think, on this side of the 
server, because we can use like transparent proxies to do all those 
on-the-fly gzip things for us, but it's possible.

"""

Presumably, he's talking about something like putting a Clojure app 
behind an nginx frontend server, where handling gzip is as simple as 
adding 'gzip on;' to the 'server {}' configuration block.  (So, you 
don't care about gzip'ing on the Clojure side of the application, you 
care about it on the transparent-proxying-server side.)


--
Best,
Ben

--
--
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/groups/opt_out.

liberator video, compression question

[Brian Craft]

http://www.youtube.com/watch?v=OEZZOz6__CY

At about 30 min he mentions that gzip, etc. aren't so interesting here 
because we can use, um.. something transfer, proxies... don't know what 
he's saying. Anyone know what he's talking about?

-- 
-- 
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/groups/opt_out.

Re: concat/forth in ->, ->>

[Nicola Mometto]

I don't know if that's what you're asking for, but there's
https://github.com/brandonbloom/factjor

t x writes:

> Hi,
>
>   Despite the title and content of this email, this is a serious, non
> joking (i.e. brainfuck) question.
>
> After studying
> https://github.com/rplevy/swiss-arrows/blob/master/src/swiss/arrows.clj for
> a bit, it hit me:
>
> -> and ->> are special cases of forth machines, where there is a stack,
> which always has exactly one item.
>
> Thus, when we have something like
> (-> init
>   instr1
>   instr2
>   ... instr k ... )
>
> what happens is that "init" is pushed onto the stack, then for each $i$, we
> pop the top item off the stack, pass it to (instr i), then push the value
> back on the stack.
>
>
> Now, if take a few steps back and squint, we ask: why is it that we only
> have one item on the stack? why not multiple items on the stack -- and now,
> suddenly, we are approaching forth.
>
> Thus, in a completely serious question -- is there any clojure
> threading-macro DSL basically provides a forth-like?
>
> --

-- 
-- 
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/groups/opt_out.

concat/forth in ->, ->>

[t x]

Hi,

  Despite the title and content of this email, this is a serious, non
joking (i.e. brainfuck) question.

After studying
https://github.com/rplevy/swiss-arrows/blob/master/src/swiss/arrows.clj for
a bit, it hit me:

-> and ->> are special cases of forth machines, where there is a stack,
which always has exactly one item.

Thus, when we have something like
(-> init
  instr1
  instr2
  ... instr k ... )

what happens is that "init" is pushed onto the stack, then for each $i$, we
pop the top item off the stack, pass it to (instr i), then push the value
back on the stack.


Now, if take a few steps back and squint, we ask: why is it that we only
have one item on the stack? why not multiple items on the stack -- and now,
suddenly, we are approaching forth.

Thus, in a completely serious question -- is there any clojure
threading-macro DSL basically provides a forth-like?

-- 
-- 
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/groups/opt_out.

Re: clojure key destructuring motivation

[Alex Miller]

On Saturday, January 18, 2014 2:19:08 PM UTC-6, Stefan Kanev wrote:
>
> On 18/01/14, Alex Miller wrote: 
> > I have some sympathy for this view of things as it was a question I had 
> > while learning Clojure as well. 
> > 
> > The general justification for the current behavior is that the thing 
> being 
> > bound is always on the left and the expression defining it is always on 
> the 
> > right. 
>
> That's not really true.  For example: 
>
> (let [{:keys (foo bar)} map] 
>   ...) 
>
>
":keys" acts as syntax here. The symbols being bound ("foo" and "bar") are 
still on the left and the expression "map" is on the right. Or if you 
prefer, in each binding the thing being bound is first and the expression 
is last. 
 

> Here it is actually on the "right" (noting that "left" and "right" are 
> very relative in this case). 
>
> If I were to guess, I would say that the example above is the reason for 
> the design – :keys seem useful more often than naming individual keys. 
> Of course, I'm just guessing. 
>
> -- 
> Stefan Kanev  ¦  @skanev  ¦  http://skanev.com/ 
> Beware of the Turing tar-pit in which everything is possible but nothing 
> of 
> interest is easy. 
>

-- 
-- 
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/groups/opt_out.

Re: clojure key destructuring motivation

[Matching Socks]

Map keys need to be unique.  Therefore, it's tidy for the symbol to be the 
key to the destructuring map.


On Saturday, January 18, 2014 2:57:09 PM UTC-5, Alex Miller wrote:
>
> I have some sympathy for this view of things as it was a question I had 
> while learning Clojure as well.
>
> The general justification for the current behavior is that the thing being 
> bound is always on the left and the expression defining it is always on the 
> right. 
>

-- 
-- 
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/groups/opt_out.

Re: oob schemas, re: The Language of the System

[Brian Craft]

Ok, so consider a different system (besides google) that handles the JSON 
example. If it has no prior knowledge of the date field, of what use is it 
to know that it's a date? What is a situation where a system reading the 
JSON needs to know a field is a date, but has no idea what the field is for?

On Saturday, January 18, 2014 1:27:31 PM UTC-8, Jonas wrote:
>
> IIRC in that particular part of the talk he was specifically talking about 
> (non-self describing) protocol buffers and not JSON.  
>
> On Saturday, January 18, 2014 10:00:09 PM UTC+2, Brian Craft wrote:
>>
>> Regarding Rich's talk (http://www.youtube.com/watch?v=ROor6_NGIWU), can 
>> anyone explain the points he's trying to make about self-describing and 
>> extensible data formats, with the JSON and google examples?
>>
>> He argues that google couldn't exist if the web depended on out-of-band 
>> schemas. He gives as an example of such a schema a JSON encoding where an 
>> out-of-band agreement is made that field names with substring "date" refer 
>> to string-encoded dates.
>>
>> However, this is exactly the sort of thing google does. It finds dates, 
>> and other data types, heuristically, and not through the formats of the web 
>> being self-describing or extensible.
>>
>>
>>

-- 
-- 
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/groups/opt_out.

Re: RESTful API Auth with Friend and Liberator

[Sam Ritchie]

The code for that tutorial is all here:

https://github.com/paddleguru/liberator-friend

PaddleGuru.com isn't open source, so I can't share any of the 
dashboards, unfortunately. Maybe some examples down the road.



Bastien 
January 18, 2014 9:39 AM
Hi Sam,


Can we see the code, by any chance?

It would be great -- tutorials are fun to read, but real-world
examples with well commented code is even better IMHO.

Sam Ritchie 
January 18, 2014 7:29 AM
Hey,

These are the choices and libraries that drove me toward Liberator. 
Liberator should help with the API definitions, and (with a little 
trust and understanding) Friend shouldn't get in your way with auth.


FWIW We currently use ClojureScript with template sharing between 
Enfocus on the client and Enlive on the server. For a new payments 
dashboard I'm going to try out Om.



clojure.u...@gmail.com 
January 17, 2014 9:28 PM
Thanks!

I have been looking at a lot of combinations for the front end to go 
with the liberator/friend back end e.g. using client-side technologies


om(clojurescript)
purnam (angularjs + clojurescript)

or going for a server side
hiccup/enlive templating + clojurescript (for any client side js)

I know it is not directly relevant but would like to know what you 
experience has been and what would you suggest.


Thanks in advance!



On Saturday, January 18, 2014 2:57:10 AM UTC+5:30, Sam Ritchie wrote:
--
--
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/groups/opt_out.
Sam Ritchie 
January 17, 2014 2:27 PM
Hey guys,

Those of you working on webapps might find this interesting:

http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/

Enjoy!


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
--
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/groups/opt_out.
<><>

Re: oob schemas, re: The Language of the System

[Jonas]

IIRC in that particular part of the talk he was specifically talking about 
(non-self describing) protocol buffers and not JSON.  

On Saturday, January 18, 2014 10:00:09 PM UTC+2, Brian Craft wrote:
>
> Regarding Rich's talk (http://www.youtube.com/watch?v=ROor6_NGIWU), can 
> anyone explain the points he's trying to make about self-describing and 
> extensible data formats, with the JSON and google examples?
>
> He argues that google couldn't exist if the web depended on out-of-band 
> schemas. He gives as an example of such a schema a JSON encoding where an 
> out-of-band agreement is made that field names with substring "date" refer 
> to string-encoded dates.
>
> However, this is exactly the sort of thing google does. It finds dates, 
> and other data types, heuristically, and not through the formats of the web 
> being self-describing or extensible.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Factual is hiring Clojure engineers

[Zach Tellman]

We will consider candidates from outside the US if they're willing to
relocate here.  I'm happy to talk in more detail if you like, just email me
at the above address.


On Sat, Jan 18, 2014 at 3:31 AM, Petr  wrote:

> Do you consider non US candidates?
> Wihout extensive data analysis experience?
>
>
> On Saturday, January 18, 2014 7:34:38 AM UTC+7, Zach Tellman wrote:
>>
>> It's been six months since I last announced this, so: Factual is
>> perpetually hiring smart, driven engineers to solve deep problems in data
>> analysis and systems engineering.  We have offices in both SF and LA, and
>> remote candidates with a strong background in analysis will be considered.
>>
>> Factual provides an index of things in the world (businesses, places, and
>> products).  You can either use this directly via our API [1] to ask
>> questions like "what are the three coffee shops nearest to me", or
>> indirectly by giving us your own real world data to enrich and refine [2]
>> [3].  Factual uses Clojure extensively [4], both for realtime systems and
>> batch data analysis.  Systems written purely in Clojure handle the
>> following:
>>
>> * realtime intake of 70k datapoints/sec from our partners
>> * batch processing of 7 billion new datapoints every day, comprising
>> terabytes of compressed textual data
>> * generating, storing, and serving 150 million records, refreshed daily
>>
>> Both of these numbers have at least doubled in the last six months, and
>> could very easily do so again.  There are also other projects that use
>> Clojure alongside Java to work at similar scales.
>>
>> Libraries developed in the course of working on these projects include:
>>
>> https://github.com/factual/skuld
>> https://github.com/factual/clj-leveldb
>> https://github.com/aphyr/merkle
>> https://github.com/ztellman/clj-tuple
>> https://github.com/ztellman/narrator
>>
>> Several other libraries are on the cusp of being open sourced, when we
>> get a chance.
>>
>> We need people who enjoy using technology as a lever to accomplish
>> amazing things (wasn't it Archimedes who said "give me a large enough data
>> center..."), who want to work alongside people they can continuously learn
>> from, and who want to be just a little uncomfortable with the scale and
>> scope of their responsibilities.
>>
>> If this sounds interesting, contact me at zach at factual.com.  I'm
>> heading up the small but growing SF office, and am happy to talk in person
>> with anyone in the Bay Area who'd like to know more.
>>
>> [1] http://developer.factual.com/working-with-factual-places/
>> [2] http://www.factual.com/products/geopulse-audience
>> [3] http://www.factual.com/products/resolve
>> [4] http://www.factual.com/jobs/clojure
>>
>  --
> --
> 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/8bPIEnNpfyQ/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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

[ANN] Clojure/West registration now open, 1 week left for CFP!

[Alex Miller]

Clojure/West  registration opened yesterday:
https://www.eventbrite.com/e/clojurewest-2014-tickets-10153269703

Unfortunately the early bird tickets have already sold out before I was
able to post this, but regular registration tickets are $415.

If you are interested in submitting a talk, the CFP is open till Friday
Jan. 24th (just a few days away). We've had about 30 talks submitted so far
and it looks like a great selection. Keep 'em coming!

https://cognitect.wufoo.com/forms/clojurewest-2014-call-for-presentations/

The sponsorship prospectus is also now available! Please help us in making
Clojure/West a great west coast Clojure event!

http://www.clojurewest.org/sponsorship-prospectus.pdf

Questions: clojure-w...@cognitect.com

Thanks!
Alex

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

Re: Functional purity and "globals" in Clojure

[Honza Pokorny]

>  we do this using Graph

Could you show a simple example of this? I think this might be a good topic 
for a blog post.

On Thursday, September 12, 2013 6:35:20 AM UTC+2, Jason Wolfe wrote:
>
> At Prismatic, we do this using Graph:
>
> https://github.com/Prismatic/plumbing
>
> I really try to avoid global vars, but passing through the seven 
> parameters or resources you need through four layers of intermediate 
> functions is also a hassle.  Graph makes it easier to define your service 
> in a functional way, instantiate it with your parameters, and the data 
> automatically flows to the leaves where it's needed.  When we leave the 
> Graph core and enter ordinary function land, resources and parameters are 
> passed through as a nested map, which at least means you only have a single 
> context argument rather than a mess of args.  It's not a complete solution, 
> but I think it's worked pretty well for us thus far.
>
> On Tuesday, September 10, 2013 12:19:35 AM UTC-7, Alexandr Kurilin wrote:
>>
>> I'm trying to determine how to best deal with the concept of globals in 
>> Clojure. Say I have a map of configuration values for my Ring app, populate 
>> at app startup from disk or env, and I need to reference the contents of 
>> this map from all over the project. Assuming MVC, models and controllers 
>> all would be interested in its contents. I just want to clarify that the 
>> question is not so much about "configuration" as it is about dealing with 
>> state that many different components in an application might be all 
>> interested in. This is an issue that seems to arise very often.
>>
>> I'm seeing a couple of options here:
>>
>>- Pass the configs map along with each Ring request with some 
>>middleware, and then down every subsequent function call that might 
>>eventually need it. It's a bit of a hassle since now you're passing more 
>>data, potentially increasing the # of parameters, or forcing you to use a 
>>parameter map everywhere where you might have passed along just 1 
>>primitive. Nonetheless, this is as pure as it gets.
>>- Def the configs map in a namespace somewhere and refer to it from 
>>wherever, just like global state. The trick is now that now you're no 
>>longer certain what e.g. your model functions are expecting there to be 
>> in 
>>the system and testing becomes trickier. Now you have to either lein test 
>>with a separate set of configurations (which doesn't actually give you 
>> much 
>>per-test granularity) or use with-redefs everywhere to make sure the 
>> right 
>>test config state is being used.
>>- Something in the middle where perhaps you agree to never directly 
>>reference the configs map from your models (again, thinking MVC here) and 
>>instead only ever access it from controllers, and pass the necessary 
>>options along down to the model functions. This way you can test both 
>>controllers and models in isolation in purity.
>>
>> Ultimately I want to contain the chaos of having to know internal 
>> implementation details of my functions at different layers and want them to 
>> be easily testable in isolation. It does seem like the first option is the 
>> most straightforward, but I'd be curious to find out what those of you who 
>> have deal with the problem for a while would recommend. Purity all the way, 
>> or are there patterns that can give you the best of both worlds? Or what 
>> else?
>>
>>
>>

-- 
-- 
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/groups/opt_out.

Re: clojure key destructuring motivation

[Stefan Kanev]

On 18/01/14, Alex Miller wrote:
> I have some sympathy for this view of things as it was a question I had 
> while learning Clojure as well.
> 
> The general justification for the current behavior is that the thing being 
> bound is always on the left and the expression defining it is always on the 
> right. 

That's not really true.  For example:

(let [{:keys (foo bar)} map]
  ...)

Here it is actually on the "right" (noting that "left" and "right" are
very relative in this case).

If I were to guess, I would say that the example above is the reason for
the design – :keys seem useful more often than naming individual keys.
Of course, I'm just guessing.

-- 
Stefan Kanev  ¦  @skanev  ¦  http://skanev.com/
Beware of the Turing tar-pit in which everything is possible but nothing of
interest is easy.

-- 
-- 
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/groups/opt_out.

Re: Servlet adapter for ring handlers with support for asynchronous processing

[Jan Herich]

Hello Shantanu,

Thank you for this hint, i will definitely look at your lein-servlet 
project. 
In the meantime, i'm taking inspiration from prototype of pedestal 
core.async based interceptor 
chain,
 
looks very interesting.

Jan

Dňa sobota, 18. januára 2014 20:32:19 UTC+1 Shantanu Kumar napísal(-a):
>
> Hi Jan,
>
> This not directly related, but i thought it might be useful in some way. 
> In case you do the java interop stuff on your own to implement the servlet 
> 3.0 methods, you might want to use lein-servlet to run the servlet using 
> Jetty 9 maybe.
>
> https://github.com/kumarshantanu/lein-servlet
>
> Shantanu
>
> On Saturday, 18 January 2014 16:01:02 UTC+5:30, Jan Herich wrote:
>>
>> Hi Folks,
>>
>> Is someone aware of servlet adapter (other then pedestal-service) for 
>> ring based handlers with support for 
>> asynchronous processing as specified in Servlet 3.0+ api ?
>>
>> Given that ring core was already refactored to support such solutions 
>> (middleware had been split into wrapping 
>> and request "modifying" functions) it should be not so hard to combine it 
>> with core.async go macros to assemble 
>> handler chain which supporting async processing and write an adapter to 
>> connect it with Servler 3.0+ API ->
>> HttpServletRequest.startAsync(), AsyncContext.complete() and so on... 
>>
>> If you assembled something similar yourself, or you now about such 
>> project (even in development, immature, alpha),
>> please let me know, thank you very much.
>>
>> 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/groups/opt_out.

oob schemas, re: The Language of the System

[Brian Craft]

Regarding Rich's talk (http://www.youtube.com/watch?v=ROor6_NGIWU), can 
anyone explain the points he's trying to make about self-describing and 
extensible data formats, with the JSON and google examples?

He argues that google couldn't exist if the web depended on out-of-band 
schemas. He gives as an example of such a schema a JSON encoding where an 
out-of-band agreement is made that field names with substring "date" refer 
to string-encoded dates.

However, this is exactly the sort of thing google does. It finds dates, and 
other data types, heuristically, and not through the formats of the web 
being self-describing or extensible.


-- 
-- 
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/groups/opt_out.

Re: clojure key destructuring motivation

[Alex Miller]

I have some sympathy for this view of things as it was a question I had 
while learning Clojure as well.

The general justification for the current behavior is that the thing being 
bound is always on the left and the expression defining it is always on the 
right. 

On Saturday, January 18, 2014 3:58:09 AM UTC-6, t x wrote:
>
> With apologies for 3 questions in 1 day:
>
> (def a {:foo {:cat 20
>   :dog 30}
> :bar "hi"})
>
> (let [{{cat :cat
> dog :dog} :foo
> bar :bar} a]
>   [cat dog bar])
>
>
> (leth [{:foo {:cat cat
>   :dog dog}
> :bar bar} a]
>   [cat dog bar])
>
>
> I don't understand the reason why existing let key destructuring is 
> "backwards"
>
> To me, it seems the fictional leth example is much "simpler" -- the mental 
> model is just "do pattern matching"
>
> The current let example seems to be: "okay, um, so for "cat", you look at 
> :cat, then you look at :foo", then you think (:cat (:foo a)) -- which seems 
> much more work and error prone.
>
>
> Question:
>
> Where can I read up on the rationale behind the current design of map 
> destructuring in let?
>
> 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/groups/opt_out.

Re: Servlet adapter for ring handlers with support for asynchronous processing

[Shantanu Kumar]

Hi Jan,

This not directly related, but i thought it might be useful in some way. In 
case you do the java interop stuff on your own to implement the servlet 3.0 
methods, you might want to use lein-servlet to run the servlet using Jetty 
9 maybe.

https://github.com/kumarshantanu/lein-servlet

Shantanu

On Saturday, 18 January 2014 16:01:02 UTC+5:30, Jan Herich wrote:
>
> Hi Folks,
>
> Is someone aware of servlet adapter (other then pedestal-service) for ring 
> based handlers with support for 
> asynchronous processing as specified in Servlet 3.0+ api ?
>
> Given that ring core was already refactored to support such solutions 
> (middleware had been split into wrapping 
> and request "modifying" functions) it should be not so hard to combine it 
> with core.async go macros to assemble 
> handler chain which supporting async processing and write an adapter to 
> connect it with Servler 3.0+ API ->
> HttpServletRequest.startAsync(), AsyncContext.complete() and so on... 
>
> If you assembled something similar yourself, or you now about such project 
> (even in development, immature, alpha),
> please let me know, thank you very much.
>
> 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/groups/opt_out.

Re: ClojureScript integration with Emacs/Cider ?

[Gary Trakhman]

Bozhidar, I had to slightly modify cider-interaction.el to make
autocomplete work for cljs.

--- cider-interaction.el2014-01-18 13:51:28.082131609 -0500
+++ /home/gary/.emacs.d/elpa/cider-0.4.0/cider-interaction.el   2014-01-17
19:06:45.872591834 -0500
@@ -469,12 +469,12 @@
   (let ((strlst (plist-get
  (nrepl-send-request-sync
   (list "op" "complete"
-"session" (nrepl-current-tooling-session)
+"session" (nrepl-current-session)
 "ns" nrepl-buffer-ns
 "symbol" str))
  :value)))
 (when strlst
-  (car strlst
+  strlst)))


Here's the current implementing code:
https://github.com/gtrak/nrepl-complete/blob/master/src/nrepl_complete/middleware.clj

Here's a screenshot: http://i.imgur.com/GmBJ6Fj.png

It can't be implemented for cljs on the tooling session without sending the
real session id over somehow, it seems this would be wasteful and not a
good precedent for other middlewares.

I'd appreciate your thoughts.

I'm also curious what it would take to make the display pretty like
ac-nrepl, which I had to disable.

As soon as this stuff is finalized, I'll package everything up nice and
make a first release.



On Mon, Jan 13, 2014 at 10:21 AM, Gary Trakhman wrote:

> Austin's lein-plugin already manipulates project middlewares, so that's an
> easy target.  Onward!
>
>
> On Mon, Jan 13, 2014 at 10:10 AM, Bozhidar Batsov wrote:
>
>> Cider’s completion understands a `complete` op, so the middleware is the
>> best approach if you ask me. The only reason that there’s also an eval
>> based completion mechanism (the one used by default) is that
>> clojure-complete is present as a REPLy (which is used by lein) dependency
>> and many newcomers have absolutely no idea what an nREPL middleware is.
>> Unfortunately it’s hard to balance initial easy of setup and good design
>> decisions.
>>
>> --
>> Cheers,
>> Bozhidar
>>
>> On Monday, January 13, 2014 at 4:55 PM, Gary Trakhman wrote:
>>
>> On talking to Chas,
>> https://github.com/cemerick/piggieback/issues/22
>>
>> it seems like the right approach is to reify ac-nrepl's use of eval into
>> a real "complete" op, and reimplement it to use that, then a common
>> middleware can either use clojure's environment (clojure-complete) or
>> piggieback's compiler state to implement the appropriate auto-complete
>> based on the active repl.
>>
>> The issue here is that clojure's auto-complete takes the JVM state as an
>> implicit parameter, whereas cljs-complete requires an 'env' arg that has to
>> come from somewhere (piggieback has a var that keeps track of repl session
>> state).  Ac-nrepl shouldn't be able to eval code, that means it's being
>> coupled to the JVM state, which won't do for cljs or other sorts of
>> repls-on-repls.
>>
>>
>>
>> On Mon, Jan 13, 2014 at 9:03 AM, Gary Trakhman 
>> wrote:
>>
>> I've released a cljs port of clojure-complete:
>>
>> Here's the mailing list announcement, also inlined.
>>
>> https://groups.google.com/forum/#!topic/clojurescript/Dt1s4laHFXc
>> cljs-complete, A Clojure library designed to auto-complete clojurescript
>> based on cljs compiler state.
>>
>> - With leiningen:
>>  [cljs-complete "0.1.0"]
>>
>> - Usage
>>
>> ;; env is pulled from cljs compiler state
>> => (completions @cljs.env/*compiler* "al" 'cljs.core)
>> ("alength" "alter-meta!")
>>
>> This is meant to hook into piggieback, that'll be the next thing I try. I
>> hope I can get some help with the hairy emacs bits :-).
>>
>>
>> On Tuesday, January 7, 2014 1:54:27 AM UTC-5, Bozhidar Batsov wrote:
>>
>> I'm cider's maintainer. The problem with code completion for
>> ClojureScript is that the default mechanism is based on the Clojure-only
>> library https://github.com/ninjudd/clojure-complete. As I don't use
>> ClojureScript I haven't paid much attention to it so far. If there is a
>> similar library for ClojureScript I might add support for it. Btw, cider
>> will also pick up any nREPL middleware that provides a "complete" op - if
>> there is a ClojureScript nREPL completion middleware it can be used with
>> cider even now. Ideally at some point we'll have unified middleware
>> supporting both Clojure & ClojureScript.
>>
>> On Sunday, January 5, 2014 10:30:44 PM UTC+2, Alexandru Nedelcu wrote:
>>
>> Hi,
>>
>> I can’t get auto-completion or jumping to the definition of a function in
>> Emacs, while working with ClojureScript. Is this a limitation of Emacs’
>> Cider  plugin?
>>
>> I managed to get nRepl working by using the awesome 
>> com.cemerick/austinplugin for lein 
>> (besides including the plugin in
>> project.clj I’ve got no other special configuration). So to work with
>> ClojureScript, from inside an nRepl session, I execute the following (not
>> sure if this is right):
>>
>> (cemerick.austin.repls/exec :exec-cmds ["google-chrome"])

[ANN] - modern-cljs integrates a port on emacs of lt-cljs-tutorial By David Nolen

[Mimmo Cosenza]

Hi all,

the `modern-cljs` series 

https://github.com/magomimmo/modern-cljs

now includes a port for Emacs users 

https://github.com/magomimmo/modern-cljs/tree/master/cljs-tutorial

of the recent lt-cljs-tutorial - A ClojureScript Programming Language Tutorial 
for Light Table Users
by David Nolen.

https://github.com/swannodette/lt-cljs-tutorial

I consider `lt-cljs-tutorial` the best companion resource for the
`modern-cljs` series because it represents the fastest path to start
learning the ClojureScript Programming Language as is, in a very
interactive way, and from the most competent guy for the language
itself.

For those not using Emacs or Light Table, it should be
very easy to run the emacs port of the David's tutorial with any editor/IDE 
supporting nREPL. The port has been generated by `cljs-start` lein-temaplate 
which works without problem with CCW, so the ported tutorial should work as 
well on it. 

Enjoy

Mimmo





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RESTful API Auth with Friend and Liberator

[Bastien]

Hi Sam,

Sam Ritchie  writes:

> FWIW We currently use ClojureScript with template sharing between
> Enfocus on the client and Enlive on the server. For a new payments
> dashboard I'm going to try out Om.

Can we see the code, by any chance?

It would be great -- tutorials are fun to read, but real-world
examples with well commented code is even better IMHO.

-- 
 Bastien

-- 
-- 
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/groups/opt_out.

Re: RESTful API Auth with Friend and Liberator

[Sam Ritchie]

Hey,

These are the choices and libraries that drove me toward Liberator. 
Liberator should help with the API definitions, and (with a little trust 
and understanding) Friend shouldn't get in your way with auth.


FWIW We currently use ClojureScript with template sharing between 
Enfocus on the client and Enlive on the server. For a new payments 
dashboard I'm going to try out Om.



clojure.u...@gmail.com 
January 17, 2014 9:28 PM
Thanks!

I have been looking at a lot of combinations for the front end to go 
with the liberator/friend back end e.g. using client-side technologies


om(clojurescript)
purnam (angularjs + clojurescript)

or going for a server side
hiccup/enlive templating + clojurescript (for any client side js)

I know it is not directly relevant but would like to know what you 
experience has been and what would you suggest.


Thanks in advance!



On Saturday, January 18, 2014 2:57:10 AM UTC+5:30, Sam Ritchie wrote:
--
--
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/groups/opt_out.
Sam Ritchie 
January 17, 2014 2:27 PM
Hey guys,

Those of you working on webapps might find this interesting:

http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/

Enjoy!


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
--
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/groups/opt_out.
<><>

Re: Managing role-based permissions in Ring apps

[Stefan Kamphausen]

On Friday, January 17, 2014 8:29:21 PM UTC+1, Sam Ritchie wrote:
>
> Okay, here's my post: 
> http://sritchie.github.io/2014/01/17/api-authentication-with-liberator-and-friend/
>

Gee, that's way more complicated than I expected.  Thanks for sharing 
anyway!

stefan 

-- 
-- 
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/groups/opt_out.

Re: Factual is hiring Clojure engineers

[Petr]

Do you consider non US candidates? 
Wihout extensive data analysis experience?

On Saturday, January 18, 2014 7:34:38 AM UTC+7, Zach Tellman wrote:
>
> It's been six months since I last announced this, so: Factual is 
> perpetually hiring smart, driven engineers to solve deep problems in data 
> analysis and systems engineering.  We have offices in both SF and LA, and 
> remote candidates with a strong background in analysis will be considered.
>
> Factual provides an index of things in the world (businesses, places, and 
> products).  You can either use this directly via our API [1] to ask 
> questions like "what are the three coffee shops nearest to me", or 
> indirectly by giving us your own real world data to enrich and refine [2] 
> [3].  Factual uses Clojure extensively [4], both for realtime systems and 
> batch data analysis.  Systems written purely in Clojure handle the 
> following:
>
> * realtime intake of 70k datapoints/sec from our partners
> * batch processing of 7 billion new datapoints every day, comprising 
> terabytes of compressed textual data
> * generating, storing, and serving 150 million records, refreshed daily
>
> Both of these numbers have at least doubled in the last six months, and 
> could very easily do so again.  There are also other projects that use 
> Clojure alongside Java to work at similar scales.
>
> Libraries developed in the course of working on these projects include:
>
> https://github.com/factual/skuld
> https://github.com/factual/clj-leveldb
> https://github.com/aphyr/merkle
> https://github.com/ztellman/clj-tuple
> https://github.com/ztellman/narrator
>
> Several other libraries are on the cusp of being open sourced, when we get 
> a chance.
>
> We need people who enjoy using technology as a lever to accomplish amazing 
> things (wasn't it Archimedes who said "give me a large enough data 
> center..."), who want to work alongside people they can continuously learn 
> from, and who want to be just a little uncomfortable with the scale and 
> scope of their responsibilities.
>
> If this sounds interesting, contact me at zach at factual.com.  I'm 
> heading up the small but growing SF office, and am happy to talk in person 
> with anyone in the Bay Area who'd like to know more.
>
> [1] http://developer.factual.com/working-with-factual-places/
> [2] http://www.factual.com/products/geopulse-audience
> [3] http://www.factual.com/products/resolve
> [4] http://www.factual.com/jobs/clojure
>

-- 
-- 
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/groups/opt_out.

Servlet adapter for ring handlers with support for asynchronous processing

[Jan Herich]

Hi Folks,

Is someone aware of servlet adapter (other then pedestal-service) for ring 
based handlers with support for 
asynchronous processing as specified in Servlet 3.0+ api ?

Given that ring core was already refactored to support such solutions 
(middleware had been split into wrapping 
and request "modifying" functions) it should be not so hard to combine it 
with core.async go macros to assemble 
handler chain which supporting async processing and write an adapter to 
connect it with Servler 3.0+ API ->
HttpServletRequest.startAsync(), AsyncContext.complete() and so on... 

If you assembled something similar yourself, or you now about such project 
(even in development, immature, alpha),
please let me know, thank you very much.

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/groups/opt_out.

clojure key destructuring motivation

[t x]

With apologies for 3 questions in 1 day:

(def a {:foo {:cat 20
  :dog 30}
:bar "hi"})

(let [{{cat :cat
dog :dog} :foo
bar :bar} a]
  [cat dog bar])


(leth [{:foo {:cat cat
  :dog dog}
:bar bar} a]
  [cat dog bar])


I don't understand the reason why existing let key destructuring is
"backwards"

To me, it seems the fictional leth example is much "simpler" -- the mental
model is just "do pattern matching"

The current let example seems to be: "okay, um, so for "cat", you look at
:cat, then you look at :foo", then you think (:cat (:foo a)) -- which seems
much more work and error prone.


Question:

Where can I read up on the rationale behind the current design of map
destructuring in let?

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/groups/opt_out.

Re: idiomatic extension to -> / --> ?

[t x]

I hope -<> and <> becomes part of clojure core.

Q: How did you solve XYZ?
A: I used the Diamond Wand.


On Sat, Jan 18, 2014 at 1:36 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> I think if you have to choose one that is idiomatic, you'd have to say it
> is as->, due to its inclusion in clojure.core.  I should start using that
> pattern...
>
>
> On Sat, Jan 18, 2014 at 12:47 AM, Jozef Wagner wrote:
>
>> There is a Syntax threading library at
>> https://github.com/LonoCloud/synthread . See it in action at
>> http://www.infoq.com/presentations/Macros-Monads
>>
>>
>> On Sat, Jan 18, 2014 at 9:18 AM, Jordan Berg wrote:
>>
>>> You can also use as-> in 1.5+
>>>
>>> (-> 2
>>> (+ 2)
>>> (as-> x (* 1 x 3)))
>>>
>>> I like this a bit more than the (#()) approach, personally
>>>
>>> On Sat, Jan 18, 2014 at 12:07 AM, Alex Baranosky
>>>  wrote:
>>> > What I think is the interesting part of the question is the inclusion
>>> of the
>>> > word "idiomatic". I'm not sure swiss-arrows is idiomatic... that said I
>>> > don't know what would be considered idiomatic here.a
>>> >
>>> > One solution I know of for examples like this is:
>>> >
>>> > (-> 2
>>> >  (+ 2)
>>> >  (#(* 1 % 3)))
>>> >
>>> > I'm not sure this is idiomatic either, but it at least has the benefit
>>> of
>>> > requiring no additional dependencies.
>>> >
>>> >
>>> >
>>> > On Fri, Jan 17, 2014 at 11:29 PM, t x  wrote:
>>> >>
>>> >> You win. :-)
>>> >>
>>> >>
>>> >> On Fri, Jan 17, 2014 at 11:26 PM, Shaun Gilchrist <
>>> shaunxc...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> https://github.com/rplevy/swiss-arrows
>>> >>>
>>> >>>
>>> >>> On Fri, Jan 17, 2014 at 11:05 PM, t x  wrote:
>>> 
>>>  I have the following:
>>> 
>>>  (defn helper [initial funcs]
>>>    (loop [fns funcs
>>>   ans initial]
>>>  (if (empty? fns)
>>>    ans
>>>    (recur (rest fns)
>>>   (list (first fns) ans)
>>> 
>>>  (defmacro => [initial & funcs]
>>>    (helper initial funcs))
>>> 
>>>  (macroexpand-1
>>>   '(=> 2
>>>    #(+ % 2)
>>>    #(* 1 % 3)))
>>> 
>>> 
>>>  Is there something part of the idiomatic clojure / clojure core
>>> which
>>>  does the above? Basically, I like the idea of -> and -->, but I
>>> find that I
>>>  can't always guarantee (1) last element or (2) 2nd element.
>>> 
>>>  The above lets me place the argument directly via #%
>>> 
>>>  Question: is there something part of idiomatic clojure / clojure
>>> core
>>>  that already does the above?
>>> 
>>>  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/groups/opt_out.
>>> >>>
>>> >>>
>>> >>> --
>>> >>> --
>>> >>> 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/groups/opt_out.
>>> >>
>>> >>
>>> >> --
>>> >> --
>>> >> 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 u

Re: idiomatic extension to -> / --> ?

[Alex Baranosky]

I think if you have to choose one that is idiomatic, you'd have to say it
is as->, due to its inclusion in clojure.core.  I should start using that
pattern...


On Sat, Jan 18, 2014 at 12:47 AM, Jozef Wagner wrote:

> There is a Syntax threading library at
> https://github.com/LonoCloud/synthread . See it in action at
> http://www.infoq.com/presentations/Macros-Monads
>
>
> On Sat, Jan 18, 2014 at 9:18 AM, Jordan Berg wrote:
>
>> You can also use as-> in 1.5+
>>
>> (-> 2
>> (+ 2)
>> (as-> x (* 1 x 3)))
>>
>> I like this a bit more than the (#()) approach, personally
>>
>> On Sat, Jan 18, 2014 at 12:07 AM, Alex Baranosky
>>  wrote:
>> > What I think is the interesting part of the question is the inclusion
>> of the
>> > word "idiomatic". I'm not sure swiss-arrows is idiomatic... that said I
>> > don't know what would be considered idiomatic here.a
>> >
>> > One solution I know of for examples like this is:
>> >
>> > (-> 2
>> >  (+ 2)
>> >  (#(* 1 % 3)))
>> >
>> > I'm not sure this is idiomatic either, but it at least has the benefit
>> of
>> > requiring no additional dependencies.
>> >
>> >
>> >
>> > On Fri, Jan 17, 2014 at 11:29 PM, t x  wrote:
>> >>
>> >> You win. :-)
>> >>
>> >>
>> >> On Fri, Jan 17, 2014 at 11:26 PM, Shaun Gilchrist <
>> shaunxc...@gmail.com>
>> >> wrote:
>> >>>
>> >>> https://github.com/rplevy/swiss-arrows
>> >>>
>> >>>
>> >>> On Fri, Jan 17, 2014 at 11:05 PM, t x  wrote:
>> 
>>  I have the following:
>> 
>>  (defn helper [initial funcs]
>>    (loop [fns funcs
>>   ans initial]
>>  (if (empty? fns)
>>    ans
>>    (recur (rest fns)
>>   (list (first fns) ans)
>> 
>>  (defmacro => [initial & funcs]
>>    (helper initial funcs))
>> 
>>  (macroexpand-1
>>   '(=> 2
>>    #(+ % 2)
>>    #(* 1 % 3)))
>> 
>> 
>>  Is there something part of the idiomatic clojure / clojure core which
>>  does the above? Basically, I like the idea of -> and -->, but I find
>> that I
>>  can't always guarantee (1) last element or (2) 2nd element.
>> 
>>  The above lets me place the argument directly via #%
>> 
>>  Question: is there something part of idiomatic clojure / clojure core
>>  that already does the above?
>> 
>>  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/groups/opt_out.
>> >>>
>> >>>
>> >>> --
>> >>> --
>> >>> 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/groups/opt_out.
>> >>
>> >>
>> >> --
>> >> --
>> >> 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/groups/opt_out.
>> >
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, se

Re: idiomatic extension to -> / --> ?

[Jozef Wagner]

There is a Syntax threading library at
https://github.com/LonoCloud/synthread . See it in action at
http://www.infoq.com/presentations/Macros-Monads


On Sat, Jan 18, 2014 at 9:18 AM, Jordan Berg wrote:

> You can also use as-> in 1.5+
>
> (-> 2
> (+ 2)
> (as-> x (* 1 x 3)))
>
> I like this a bit more than the (#()) approach, personally
>
> On Sat, Jan 18, 2014 at 12:07 AM, Alex Baranosky
>  wrote:
> > What I think is the interesting part of the question is the inclusion of
> the
> > word "idiomatic". I'm not sure swiss-arrows is idiomatic... that said I
> > don't know what would be considered idiomatic here.a
> >
> > One solution I know of for examples like this is:
> >
> > (-> 2
> >  (+ 2)
> >  (#(* 1 % 3)))
> >
> > I'm not sure this is idiomatic either, but it at least has the benefit of
> > requiring no additional dependencies.
> >
> >
> >
> > On Fri, Jan 17, 2014 at 11:29 PM, t x  wrote:
> >>
> >> You win. :-)
> >>
> >>
> >> On Fri, Jan 17, 2014 at 11:26 PM, Shaun Gilchrist  >
> >> wrote:
> >>>
> >>> https://github.com/rplevy/swiss-arrows
> >>>
> >>>
> >>> On Fri, Jan 17, 2014 at 11:05 PM, t x  wrote:
> 
>  I have the following:
> 
>  (defn helper [initial funcs]
>    (loop [fns funcs
>   ans initial]
>  (if (empty? fns)
>    ans
>    (recur (rest fns)
>   (list (first fns) ans)
> 
>  (defmacro => [initial & funcs]
>    (helper initial funcs))
> 
>  (macroexpand-1
>   '(=> 2
>    #(+ % 2)
>    #(* 1 % 3)))
> 
> 
>  Is there something part of the idiomatic clojure / clojure core which
>  does the above? Basically, I like the idea of -> and -->, but I find
> that I
>  can't always guarantee (1) last element or (2) 2nd element.
> 
>  The above lets me place the argument directly via #%
> 
>  Question: is there something part of idiomatic clojure / clojure core
>  that already does the above?
> 
>  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/groups/opt_out.
> >>>
> >>>
> >>> --
> >>> --
> >>> 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/groups/opt_out.
> >>
> >>
> >> --
> >> --
> >> 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/groups/opt_out.
> >
> >
> > --
> > --
> > 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 

Re: idiomatic extension to -> / --> ?

[Jordan Berg]

You can also use as-> in 1.5+

(-> 2
(+ 2)
(as-> x (* 1 x 3)))

I like this a bit more than the (#()) approach, personally

On Sat, Jan 18, 2014 at 12:07 AM, Alex Baranosky
 wrote:
> What I think is the interesting part of the question is the inclusion of the
> word "idiomatic". I'm not sure swiss-arrows is idiomatic... that said I
> don't know what would be considered idiomatic here.a
>
> One solution I know of for examples like this is:
>
> (-> 2
>  (+ 2)
>  (#(* 1 % 3)))
>
> I'm not sure this is idiomatic either, but it at least has the benefit of
> requiring no additional dependencies.
>
>
>
> On Fri, Jan 17, 2014 at 11:29 PM, t x  wrote:
>>
>> You win. :-)
>>
>>
>> On Fri, Jan 17, 2014 at 11:26 PM, Shaun Gilchrist 
>> wrote:
>>>
>>> https://github.com/rplevy/swiss-arrows
>>>
>>>
>>> On Fri, Jan 17, 2014 at 11:05 PM, t x  wrote:

 I have the following:

 (defn helper [initial funcs]
   (loop [fns funcs
  ans initial]
 (if (empty? fns)
   ans
   (recur (rest fns)
  (list (first fns) ans)

 (defmacro => [initial & funcs]
   (helper initial funcs))

 (macroexpand-1
  '(=> 2
   #(+ % 2)
   #(* 1 % 3)))


 Is there something part of the idiomatic clojure / clojure core which
 does the above? Basically, I like the idea of -> and -->, but I find that I
 can't always guarantee (1) last element or (2) 2nd element.

 The above lets me place the argument directly via #%

 Question: is there something part of idiomatic clojure / clojure core
 that already does the above?

 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/groups/opt_out.
>>>
>>>
>>> --
>>> --
>>> 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/groups/opt_out.
>>
>>
>> --
>> --
>> 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/groups/opt_out.
>
>
> --
> --
> 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/groups/opt_out.

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

Re: idiomatic extension to -> / --> ?

[Alex Baranosky]

What I think is the interesting part of the question is the inclusion of
the word "idiomatic". I'm not sure swiss-arrows is idiomatic... that said I
don't know what would be considered idiomatic here.a

One solution I know of for examples like this is:

(-> 2
 (+ 2)
 (#(* 1 % 3)))

I'm not sure this is idiomatic either, but it at least has the benefit of
requiring no additional dependencies.



On Fri, Jan 17, 2014 at 11:29 PM, t x  wrote:

> You win. :-)
>
>
> On Fri, Jan 17, 2014 at 11:26 PM, Shaun Gilchrist wrote:
>
>> https://github.com/rplevy/swiss-arrows
>>
>>
>> On Fri, Jan 17, 2014 at 11:05 PM, t x  wrote:
>>
>>> I have the following:
>>>
>>> (defn helper [initial funcs]
>>>   (loop [fns funcs
>>>  ans initial]
>>> (if (empty? fns)
>>>   ans
>>>   (recur (rest fns)
>>>  (list (first fns) ans)
>>>
>>> (defmacro => [initial & funcs]
>>>   (helper initial funcs))
>>>
>>> (macroexpand-1
>>>  '(=> 2
>>>   #(+ % 2)
>>>   #(* 1 % 3)))
>>>
>>>
>>> Is there something part of the idiomatic clojure / clojure core which
>>> does the above? Basically, I like the idea of -> and -->, but I find that I
>>> can't always guarantee (1) last element or (2) 2nd element.
>>>
>>> The above lets me place the argument directly via #%
>>>
>>> Question: is there something part of idiomatic clojure / clojure core
>>> that already does the above?
>>>
>>> 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/groups/opt_out.
>>>
>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>
>  --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.