Re: [ANN] permissions - role & permission based access control

2016-10-13 Thread Stefan Kamphausen 
Hi,

Doesn't that feel like premature optimization to you, too?  Bitmasks are 
much harder to read than sets with spelled out roles and I wonder if the 
performance gain is really worth that. And it poses a limit of 64 roles.  I 
have seen several enterprise applications that had far more than 64 roles 
and/or permissions.

Or am I missing something here?

Just my 2ct.

Kind regards,
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/d/optout.

Re: AOT classes with clj files on classpath causing ClassNotFoundException

2016-10-13 Thread Piotr Bzdyl 
Thank you all for the replies - now I understand where the problem comes 
from.

Best regards,
Piotr

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

{ANN}} Carmine-sentinel: connect redis by sentinel, make carmine to support sentinel.

2016-10-13 Thread dennis zhuang 
Hi, all

I wrote a library to make carmine 
support redis sentinel :

https://github.com/killme2008/carmine-sentinel

Someone may want to try it if you are interested. It's a beta release,
feedback is welcome.

-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

-- 
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] permissions - role & permission based access control

2016-10-13 Thread Torsten Uhlmann 
It might be premature optimization, or you could view it as a different
approach, for a different usage scenario.
I'm myself pretty content with the literal approach, we're using this in a
fairly large application and haven't experienced any problems with regards
of performance or amount of data attached to users so far.

On the other hand I see these suggestions as a way to experiment with
alternative approaches, which might as well teach me something...

Stefan Kamphausen  schrieb am Do., 13. Okt. 2016 um
10:29 Uhr:

> Hi,
>
> Doesn't that feel like premature optimization to you, too?  Bitmasks are
> much harder to read than sets with spelled out roles and I wonder if the
> performance gain is really worth that. And it poses a limit of 64 roles.  I
> have seen several enterprise applications that had far more than 64 roles
> and/or permissions.
>
> Or am I missing something here?
>
> Just my 2ct.
>
> Kind regards,
> 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/d/optout.
>

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

Re: [ANN] permissions - role & permission based access control

2016-10-13 Thread adrian . medina 
My suggestion of a bitmask was just a response to a suggestion of prime 
factorization for encoding roles in an integer. I think using a set is just 
fine. The space requirements for a small set of keywords is negligible in 
the larger scheme of things. It also permits more readable code (always a 
good thing) with bits of code that need to interact with it. 

On Thursday, October 13, 2016 at 7:56:10 AM UTC-4, Torsten Uhlmann wrote:
>
> It might be premature optimization, or you could view it as a different 
> approach, for a different usage scenario.
> I'm myself pretty content with the literal approach, we're using this in a 
> fairly large application and haven't experienced any problems with regards 
> of performance or amount of data attached to users so far.
>
> On the other hand I see these suggestions as a way to experiment with 
> alternative approaches, which might as well teach me something...
>
> Stefan Kamphausen > schrieb am Do., 13. 
> Okt. 2016 um 10:29 Uhr:
>
>> Hi,
>>
>> Doesn't that feel like premature optimization to you, too?  Bitmasks are 
>> much harder to read than sets with spelled out roles and I wonder if the 
>> performance gain is really worth that. And it poses a limit of 64 roles.  I 
>> have seen several enterprise applications that had far more than 64 roles 
>> and/or permissions.
>>
>> Or am I missing something here?
>>
>> Just my 2ct.
>>
>> Kind regards,
>> Stefan
>>
>> -- 
>> 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.

Diffing clojure data structures faster

2016-10-13 Thread Dan 
Hi

I would like to be able to take advantage of the tree structures underneath 
e.g. hash-maps for a faster diff.

I wrote a gist to do this in 
clojurescript 
https://gist.github.com/danjohansson/add5515b2067b3036044d450cbec08f3

I guess BitmapIndexedNode etc are implementation details of 
PersistentHashMaps and its a bad idea to use them directly.
In clojure it is not straightforward to do this at all since root is 
private.

So to my question:
Is there or has there been any plans to add a diff or a diff enabler on the 
data structures to be able to make faster diffs.

Thanks
Dan





-- 
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: Keywords with colon on the backside?

2016-10-13 Thread larry google groups 
Am I correct in saying that this conversation is at least partly related to 
the question of "Will Clojure ever support reader macros?" And for now the 
answer is "no". Because with reader macros, programmers could change the 
meaning of ":".


On Friday, September 23, 2016 at 7:13:30 PM UTC-4, John Mastro wrote:
>
> Timothy Baldridge > wrote: 
> > The syntax (I think) comes from Ruby although they call keywords 
> "symbols". 
>
> The reader syntax for Common Lisp's keywords has the leading colon too. 
>
> John 
>

-- 
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: Diffing clojure data structures faster

2016-10-13 Thread Alex Miller 


On Thursday, October 13, 2016 at 12:23:21 PM UTC-5, Dan wrote:
>
> Hi
>
> I would like to be able to take advantage of the tree structures 
> underneath e.g. hash-maps for a faster diff.
>
> I wrote a gist to do this in clojurescript 
> https://gist.github.com/danjohansson/add5515b2067b3036044d450cbec08f3 
> 
>
> I guess BitmapIndexedNode etc are implementation details of 
> PersistentHashMaps and its a bad idea to use them directly.
>

Correct.
 

> In clojure it is not straightforward to do this at all since root is 
> private.
>

Should be considered implementation details.
 

> So to my question:
> Is there or has there been any plans to add a diff or a diff enabler on 
> the data structures to be able to make faster diffs.
>

No.

It seems like the "right" way to do such a thing would be to create an 
interface/protocol for diffing and extend/implement it on the data 
structures as directly as possible, which seems like the path you're going 
down. 

Given the perf diff you demonstrated (would be curious to see how that 
translates to Clojure), might be an interesting enhancement.

Another option would be to look at optimizations for the existing generic 
data diff as well. Might guess is there is probably room for improvement.


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

Re: core.async top use cases

2016-10-13 Thread larry google groups 
> It is not just convenience. For example agents don't provide 
functionality like buffering, back pressure 
> and select aka alts. If you send an action to an agent you don't get to 
know when it's done or 
> to choose what to do if it is currently busy. 


So when to use agents? I've looked through Clojure repos on Github, looking 
for uses of agents, and I found very few. (I was writing a blog post about 
concurrency in Clojure, and I found that agents are among the least used 
tools for concurrency). I found a lot of uses of futures and promises and 
channels and core.async, and certainly atoms, but I didn't find many uses 
of agents. When are agents best used? 





On Monday, September 19, 2016 at 1:19:55 PM UTC-4, Leon Grapenthin wrote:
>
> It is not just convenience. For example agents don't provide functionality 
> like buffering, backpressure and select aka alts. If you send an action to 
> an agent you don't get to know when it's done or to choose what to do if it 
> is currently busy. 
>
> On Monday, September 19, 2016 at 11:49:13 AM UTC+2, Matan Safriel wrote:
>>
>> Thanks, and I put the blog post on my reading list. 
>> Although I can't avoid thinking that we already have asynchronous idioms 
>> in the core language itself, like agents. I think the crux for server-side 
>> is more about the convenient piping, rather than the mere asynchronism 
>> itself, but I might be wrong in any of this.
>>
>> On Mon, Sep 19, 2016 at 9:14 AM, Mond Ray  wrote:
>>
>>> Pushing asynchrony further into the stack is useful for reliability and 
>>> fault tolerance. We can also use it as a basis for Complex Event Processing 
>>> using time series windows. 
>>>
>>> I wrote up a few examples in my blog 
>>> 
>>>  
>>> if you have the time to check out a longer explanation with code.
>>>
>>> I recently wrote a small set of functions to enable HTML5 Server Sent 
>>> Events from any Kafka topic which also uses core.async (with an example 
>>> using Aleph and Compojure). You might like to check that repo 
>>>  out too.
>>>
>>> Ray
>>>
>>> On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote:

 Hi,

 It's very easy to see how core.async solves callback hell for front-end 
 development with clojurescript.
 In what use cases would you use it for server-side? we already have 
 non-blocking IO from Java, and we have clojure agents. So what's a bunch 
 of 
 salient use cases?
 Are there prominent clojure http server implementations which rely on 
 it for transcending the threaded web service paradigm?

 Thanks,
 Matan

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

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

Re: WAT: JavaScript & Ruby

2016-10-13 Thread larry google groups 
> Waiting for the Clojure and Scala version. :-}

But there won't be. Not ever. Not really. The reason I prefer Clojure over 
Javascript or Ruby is because so much care and thought went into the APIs 
of Clojure's core structures and syntax. If you try really hard, you can 
find the occasional article about some unusual choices that the Clojure 
core team has made, but you won't find anything quite as crazy "wat - 1" == 
NaN. 

You look at the way the core team waited to figure out how to handle the 
passing of data structures to functions, and the beautiful style of 
destructuring that emerged -- that's the history of Clojure in a  nutshell. 

I am willing to believe that there are some Haskell fanatics who find 
aspects of Clojure funny, but the point of the lighting talk was about 
things that are obviously wrong: 

[] + {}
Object

{} + []
0

Can you think of anything in Clojure that is as crazy as that? 






On Friday, September 23, 2016 at 12:01:30 PM UTC-4, Alan Moore wrote:
>
> Thanks for the laugh! Waiting for the Clojure and Scala version. :-}
>
> Alan
>

-- 
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: Should I switch to Clojure after 3 years of learning another full stack ?

2016-10-13 Thread Gregg Reynolds 
On Oct 13, 2016 12:59 AM, "Mars0i"  wrote:
>
> Others have meatier, more detailed answers.  Here's one more factor that
might matter:
>
> Clojure makes me happy.  I'm happier programming in Clojure than in other
languages that are also very suitable for my projects.  I enjoy myself
more, and it's easier.  I even prefer to use Clojure when I could probably
do a project more quickly using something else.  It's not the only language
that can make me feel that way, but it's the best one for me right now.
You may not feel the same way after you get comfortable with Clojure--but
you might.
>

+1

fill in the blank:  "it's just *fun* to program in ."  for me at least
Clojure is the only word that makes that a sentence. and I've programmed in
a lot of languages.

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

-- 
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: Should I switch to Clojure after 3 years of learning another full stack ?

2016-10-13 Thread Paul Gowder 
Another thing worth thinking about is that Cojure(script) is great for pure 
front-end applications ("single page applications").  The reagent library is a 
scarily magical way of just abstracting away the dom, and figwheel is a scarily 
effective build tool. This template is a convenient way to get started: 
https://github.com/reagent-project/reagent-frontend-template.  I actually built 
a static site using reagent once, hard-coding the content into the 
clojurescript for shits and giggles gowder.io), but that's pretty stupid. :-)

If you don't need to do anything heavy server-side, reagent might be a good 
starting point, and then no need to think about things like webservers and 
databases and routing. 

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

Re: core.async top use cases

2016-10-13 Thread William la Forge 
On Thursday, October 13, 2016 at 3:38:16 PM UTC-4, larry google groups 
wrote:
>
> So when to use agents? I've looked through Clojure repos on Github, 
> looking for uses of agents, and I found very few. (I was writing a blog 
> post about concurrency in Clojure, and I found that agents are among the 
> least used tools for concurrency). I found a lot of uses of futures and 
> promises and channels and core.async, and certainly atoms, but I didn't 
> find many uses of agents. When are agents best used? 
>
>>
>>>
When using clojurescript, adding async really increases the load time. 
That's one place where you might want to use agents when you can.
 

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

Re: core.async top use cases

2016-10-13 Thread Timothy Baldridge 
>> When using clojurescript, adding async really increases the load time.
That's one place where you might want to use agents when you can.

But Clojurescript doesn't support agents.

On Thu, Oct 13, 2016 at 7:16 PM, William la Forge 
wrote:

> On Thursday, October 13, 2016 at 3:38:16 PM UTC-4, larry google groups
> wrote:
>>
>> So when to use agents? I've looked through Clojure repos on Github,
>> looking for uses of agents, and I found very few. (I was writing a blog
>> post about concurrency in Clojure, and I found that agents are among the
>> least used tools for concurrency). I found a lot of uses of futures and
>> promises and channels and core.async, and certainly atoms, but I didn't
>> find many uses of agents. When are agents best used?
>>
>>>

> When using clojurescript, adding async really increases the load time.
> That's one place where you might want to use agents when you can.
>
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: core.async top use cases

2016-10-13 Thread Timothy Baldridge 
Agents combine two things 1) a queue of functions, 2) mutable state. The
key thing about agents is that they still respect Clojure's concept of
"instant deref". That is to say, you can always deref an agent even if the
queue is backlogged. This is one of the key differences between agents and
actors. You have to send a message to an actor to deref it, an agent is
always deref-able.

Now it's true that you could build an agent via a core.async channel and an
atom, but there's really no need since agents already exist in the runtime.
Agents also support the lesser known features of Clojure's mutable refs,
namely, validators and watchers. But the short answer is: agents existed
before core.async. I've used them once in the past 2 years, but that's not
to say they aren't useful sometimes. And it's nice being able to have a
queue attached to a mutable reference without having to import core.async.

On Thu, Oct 13, 2016 at 7:28 PM, Timothy Baldridge 
wrote:

> >> When using clojurescript, adding async really increases the load time.
> That's one place where you might want to use agents when you can.
>
> But Clojurescript doesn't support agents.
>
> On Thu, Oct 13, 2016 at 7:16 PM, William la Forge 
> wrote:
>
>> On Thursday, October 13, 2016 at 3:38:16 PM UTC-4, larry google groups
>> wrote:
>>>
>>> So when to use agents? I've looked through Clojure repos on Github,
>>> looking for uses of agents, and I found very few. (I was writing a blog
>>> post about concurrency in Clojure, and I found that agents are among the
>>> least used tools for concurrency). I found a lot of uses of futures and
>>> promises and channels and core.async, and certainly atoms, but I didn't
>>> find many uses of agents. When are agents best used?
>>>

>
>> When using clojurescript, adding async really increases the load time.
>> That's one place where you might want to use agents when you can.
>>
>>
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: core.async top use cases

2016-10-13 Thread Alex Miller 
The other other special feature of agents is that the stm knows about them so 
it's a safe way to have a side effect occur in an stm transaction (all agent 
sends are delayed till the txn succeeds). I've found that to be pretty handy in 
advanced usage.

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

Re: core.async top use cases

2016-10-13 Thread Mark Engelberg 
My primary use case for agents has always been when I want to coordinate
multiple threads writing to a log file.  The agent effectively serializes
all the write requests with a minimum of fuss.

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

Re: core.async top use cases

2016-10-13 Thread Mark Engelberg 
I always found it a bit ironic that my main use case for agents doesn't
really at all make use of the "mutable ref" aspect of the agent, only the
queue piece.  I usually hold the name of the log file in the mutable ref to
emphasize that the agent is "guarding" this particular log file, but I
don't actually mutate it, so the mutability doesn't really matter for this
purpose.

On Thu, Oct 13, 2016 at 7:02 PM, Mark Engelberg 
wrote:

> My primary use case for agents has always been when I want to coordinate
> multiple threads writing to a log file.  The agent effectively serializes
> all the write requests with a minimum of fuss.
>

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

Re: core.async top use cases

2016-10-13 Thread Timothy Baldridge 
Yeah, I used to do that, but once core.async came out I started to desire
the back pressure aspects of channels. I don't think I've used agents for
logging since. You always run the risk of something backing up the queue of
the agent and causing your thread to crash when it runs out of memory.

On Thu, Oct 13, 2016 at 8:04 PM, Mark Engelberg 
wrote:

> I always found it a bit ironic that my main use case for agents doesn't
> really at all make use of the "mutable ref" aspect of the agent, only the
> queue piece.  I usually hold the name of the log file in the mutable ref to
> emphasize that the agent is "guarding" this particular log file, but I
> don't actually mutate it, so the mutability doesn't really matter for this
> purpose.
>
> On Thu, Oct 13, 2016 at 7:02 PM, Mark Engelberg 
> wrote:
>
>> My primary use case for agents has always been when I want to coordinate
>> multiple threads writing to a log file.  The agent effectively serializes
>> all the write requests with a minimum of fuss.
>>
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Love the Medley library :)

2016-10-13 Thread Alan Thompson 
I had nearly forgotten all of the very convenient functions in the Medley
library  until I was reminded by a
small mention in the Clojure Cheatsheet
.
It allows you to very easily remove nil values from a list of maps and
merge them all together:

(ns clj.core
  (:require [tupelo.core :as t]
[medley.core :as medley] ))
(t/refer-tupelo)

(def src [ {:a 1 :b nil}
   {:c 3 }
   {:d nil :e 5 } ] )

(spyx (apply glue src))
;=> (apply glue src) => {:a 1, :b nil, :c 3, :d nil, :e 5}

(spyx (medley/remove-vals nil? {:d nil :e 5}))
;=> (medley/remove-vals nil? {:d nil, :e 5}) => {:e 5}

(def result (medley/remove-vals
  nil?
  (apply t/glue src)))
(spyx result)
;=> result => {:a 1, :c 3, :e 5}


​
​Alan​

-- 
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: WAT: JavaScript & Ruby

2016-10-13 Thread Alan Thompson 
I cannot think of anything in Clojure as crazy as the stuff in the video;
90% of the stuff in Clojure is a big, big improvement over Java, et al.
And a good chunk of that 90% is simply brilliant.

Having said that, there are a few WAT type things in Clojure, from small
annoyances like the presence of assoc-in but no dissoc-in to larger ones
like the surprising conversion of vectors into (effectively) lists, and the
unintended consequences that follow (see https://goo.gl/2ANisU).

The whole reason I posted this link was so people would think about how a
decision that seems like an expedient shortcut in the present can cause
long-lasting pain in the future.

Alan


On Thu, Oct 13, 2016 at 1:14 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

> > Waiting for the Clojure and Scala version. :-}
>
> But there won't be. Not ever. Not really. The reason I prefer Clojure over
> Javascript or Ruby is because so much care and thought went into the APIs
> of Clojure's core structures and syntax. If you try really hard, you can
> find the occasional article about some unusual choices that the Clojure
> core team has made, but you won't find anything quite as crazy "wat - 1" ==
> NaN.
>
> You look at the way the core team waited to figure out how to handle the
> passing of data structures to functions, and the beautiful style of
> destructuring that emerged -- that's the history of Clojure in a  nutshell.
>
> I am willing to believe that there are some Haskell fanatics who find
> aspects of Clojure funny, but the point of the lighting talk was about
> things that are obviously wrong:
>
> [] + {}
> Object
>
> {} + []
> 0
>
> Can you think of anything in Clojure that is as crazy as that?
>
>
>
>
>
>
> On Friday, September 23, 2016 at 12:01:30 PM UTC-4, Alan Moore wrote:
>>
>> Thanks for the laugh! Waiting for the Clojure and Scala version. :-}
>>
>> Alan
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Is there an easy way for s/keys spec to work against both qualified/unqualiffied keys at the same time?

2016-10-13 Thread Ikuru Kanuma 
Hi,

I was reading the official spec guide's explanation for the s/keys macro, 
played around with it a bit,
and was a little surprised that the :req and :req-un are exclusive specs as 
illustrated below:

(ns my.ns
  (:require [clojure.spec :as s]))

(s/def ::some-number int?)
(s/def ::map-with-numbers1 (s/keys :req [::some-number]))
(s/valid? ::map-with-numbers1 {::some-number 3}) => true
(s/valid? ::map-with-numbers1 {:some-number 3}) => false

(s/def ::map-with-numbers2 (s/keys :req-un [::some-number]))
(s/valid? ::map-with-numbers2 {::some-number 3}) => false
(s/valid? ::map-with-numbers2 {:some-number 3}) => true

In other words, would there a convenient way to specify a spec that would 
work for both qualified/unqualified keys at the same time?
;;Want a spec that validates as follows
(s/valid? ::map-with-numbers {::some-number 3}) => true
(s/valid? ::map-with-numbers {:some-number 3}) => true

Regards,

Ikuru

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