Re: [Review] Slow server, not maxing out CPU

2016-07-20 Thread James Reeves 
On 21 July 2016 at 05:05, Ashish Negi  wrote:

> with core async `go` you can not do blocking IO or any time consuming work.
> `go` uses fixed threadpool (no of cpus + 2 or something).
> and in your async-handler you are using ` https://clojure.github.io/core.async/
>
> Try with `future`. https://clojuredocs.org/clojure.core/future
>

While futures will work, it's worth pointing out you'd get the same result
just by increasing the thread count on the adapter. Either way you're using
up a thread per request.

Since the database functions are not asynchronous, core.async isn't really
useful in this context. My suggestion would be to drop it altogether.

- James

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

Re: [Review] Slow server, not maxing out CPU

2016-07-20 Thread Ashish Negi 
with core async `go` you can not do blocking IO or any time consuming work.
`go` uses fixed threadpool (no of cpus + 2 or something).
and in your async-handler you are using `https://clojure.github.io/core.async/

Try with `future`. https://clojuredocs.org/clojure.core/future

Simplest would be to pass your `channel` in with-channel to the future 
which would put the data in it after it gets from `work`.

-- 
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: Enhance spec/double-in to handle open and half-open intervals?

2016-07-20 Thread Mars0i 


On Wednesday, July 20, 2016 at 10:02:17 PM UTC-5, Alex Miller wrote:
>
> On Wednesday, July 20, 2016 at 9:41:59 PM UTC-5, Mars0i wrote:
>>
>> On Wednesday, July 20, 2016 at 4:32:40 PM UTC-5, Alex Miller wrote:
>>>
>>> You can file a jira if you like, I'm not sure Rich's thoughts on this. 
>>>
>>
>> I understand.  Thanks--will do.
>>  
>>
>>> Also, keep in mind that you can also compose preds and get this with 
>>> slightly more effort now:
>>>
>>> (s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %))
>>>
>>
>> Yes, definitely.  Though #(and (> % 0.0) (<= % 1)) seems simpler if one 
>> doesn't really need the NaN and Infinity tests. 
>>
>
> You'll find that the generator for double-in is far better than what 
> you're suggesting, and you should lean on it when doing things slightly 
> differently. 
>
> I didn't try it but I don't think your example would gen at all - you'd 
> need to s/and double? in there too at the beginning and even then it's 
> going to generate random doubles then filter to your range, but most 
> generated values will not be in the range. s/double-in is designed to only 
> generate values in the specified range.
>

Ah.  Thanks.   I'm sure you're right.  I didn't understand the role of the 
spec logic functions generating for testing.  I hadn't thought about the 
generator functionality at all--just validation of real inputs.  I'm still 
feeling my way in the dark with spec.  I needed half-open and closed 
interval tests for user input the very small application that I'm using to 
explore spec, which is how the issue about double-in arose for me.  i.e. I 
have a real use case, but my testing can be pretty simple.

-- 
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: Enhance spec/double-in to handle open and half-open intervals?

2016-07-20 Thread Alex Miller 


On Wednesday, July 20, 2016 at 9:41:59 PM UTC-5, Mars0i wrote:
>
> On Wednesday, July 20, 2016 at 4:32:40 PM UTC-5, Alex Miller wrote:
>>
>> You can file a jira if you like, I'm not sure Rich's thoughts on this. 
>>
>
> I understand.  Thanks--will do.
>  
>
>> Also, keep in mind that you can also compose preds and get this with 
>> slightly more effort now:
>>
>> (s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %))
>>
>
> Yes, definitely.  Though #(and (> % 0.0) (<= % 1)) seems simpler if one 
> doesn't really need the NaN and Infinity tests. 
>

You'll find that the generator for double-in is far better than what you're 
suggesting, and you should lean on it when doing things slightly 
differently. 

I didn't try it but I don't think your example would gen at all - you'd 
need to s/and double? in there too at the beginning and even then it's 
going to generate random doubles then filter to your range, but most 
generated values will not be in the range. s/double-in is designed to only 
generate values in the specified range.
 

>
> Thanks.
>
>
>

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

Re: Enhance spec/double-in to handle open and half-open intervals?

2016-07-20 Thread Mars0i 
On Wednesday, July 20, 2016 at 4:32:40 PM UTC-5, Alex Miller wrote:
>
> You can file a jira if you like, I'm not sure Rich's thoughts on this. 
>

I understand.  Thanks--will do.
 

> Also, keep in mind that you can also compose preds and get this with 
> slightly more effort now:
>
> (s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %))
>

Yes, definitely.  Though #(and (> % 0.0) (<= % 1)) seems simpler if one 
doesn't really need the NaN and Infinity tests. 

Thanks.


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

Re: Frustrations so far

2016-07-20 Thread Alan Thompson 
Hi Peter - I started the Tupelo library 
and related Tupelo-Datomic library
 in order to collect helper &
convenience functions that I felt were missing (IMHO) from core Clojure.
If you have any ideas to add or improve them, please let me know!
Bye,
Alan


On Wed, Jul 20, 2016 at 5:49 AM, Peter Romfeld 
wrote:

> I really love clojure over all, it makes maintenance/collaboration of code
> such a breeze. its easy to get new employees start to work on it even
> without any previous clojure knowledge!
>
> I do hate the JVM startup shit, i hate how you it takes forever to fetch
> deps on a aws medium instance (you probably can fix it with uberjars)
> Im frustrated with `empty?` throwing exceptions for Long and Keyword
> Not complete clojure, but i hate datomic.api/log since you cant put into
> your tests with a in-mem db
> I had some issues understanding that maps of certain size are not in order
> anymore because of the underlying java functions and optimizations
> Im a bit upset about development reload with defrecords
> most of the things that are not documented by the community are documented
> very cryptic and hard to understand
> the api docs are almost useless! - to get the arrity and stuff.. wtf i
> still have no clue how to use this new function i never used before...
> security features in most frameworks are just smoke and mirrors, functions
> that dont actually do what they should do...
>
> anyways, if i remember more i can add...
> just wanted to give you guys some input, and looking forward to make
> development experience even better!
>
> cheers,
> peter
>
> --
> 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: [Bug?] Spec: spec/? not working?

2016-07-20 Thread Sean Corfield 
Your code works for me as expected on 1.9.0 Alpha 10. What version are you 
using?

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 7/20/16, 2:59 PM, "Torsten Anders"  wrote:

 

Dear all,

I have some problems using clojure.spec: ? does not work as I would expect it. 
Instead of specifying an optional value, it seems that such values are never 
permitted, and instead the next value is always matched. Please see the short 
example demonstration below. BTW, * seems to cause the same problem. 

What am I missing?


(ns test-ns
  (:require [clojure.spec :as spec]))

(spec/def ::test-spec (spec/cat :symbol symbol?
:optional-string (spec/? string?)
:int int?))
(spec/valid? ::test-spec '[test 42]) ; -> true
(spec/valid? ::test-spec '[test "my string" 42]) ; -> false

(spec/explain ::test-spec '[test "my string" 42])
;; In: [1] val: "my string" fails spec: :clojure2minizinc.core/test-spec at: 
[:int] predicate: int?


Best,
Torsten

 

-- 
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: Amazonica and S3

2016-07-20 Thread Andrea Richiardi 
Maybe not related, but I was checking that api and this showed up, maybe it 
can be helpful?

https://stackoverflow.com/questions/30521046/malformedxml-when-tagging-an-s3-bucket

On Wednesday, July 20, 2016 at 7:56:10 AM UTC-7, Gareth Rogers wrote:
>
> After chatting with a colleague who read this and showed me the magic of 
> trace I think the problem with amazonica.aws.
> s3/set-bucket-tagging-configuration is that I need
>
> {:tag-sets [{:tag {"Formation" "notlive"}}]}
>
> i.e. I need to know how to call setTag(string key, string value) which 
> takes two args through the Amazonica. I've only dealt with single args 
> before.
>
> On Wednesday, 20 July 2016 14:53:11 UTC+1, Gareth Rogers wrote:
>>
>> Hi
>>
>> Has any one had any success using either 
>> amazonica.aws.s3/set-bucket-notification-configuration or 
>> amazonica.aws.s3/set-bucket-tagging-configuration?
>>
>> I've got
>>
>> (amazonica.aws.s3/set-bucket-notification-configuration
>> "my.bucket.name"
>> {"my-custom-event-name"
>> {"" ;; This replaced with the ARN of an SQS queue I've 
>> created
>>  "ObjectCreatedByPut" ;; [S3Event/ObjectCreatedByPut] ;; 
>> "s3:ObjectCreated:Put" <-- tried all three
>>  ;; :filter"/_SUCCESS"
>>  }})
>>
>> and
>>
>> (amazonica.aws.s3/set-bucket-tagging-configuration
>>  "my.bucket.name"
>>  {:tag-sets [{"Formation" "notlive"}]})
>>
>> Both of those are wrapped with amazonica.core/with-credential which I've 
>> omitted.
>>
>> The call to amazonica.aws.s3/set-bucket-notification-configuration returns 
>> nil. I guess this means it's getting converted to a valid call but the S3 
>> API is rejecting it silently? Anyone know what it should look like?
>>
>> The call to amazonica.aws.s3/set-bucket-tagging-configuration is 
>> throwing:
>>
>> Unhandled com.amazonaws.services.s3.model.AmazonS3Exception
>>The XML you provided was not well-formed or did not validate
>>against our published schema (Service: Amazon S3; Status Code: 400;
>>Error Code: MalformedXML; Request ID: )
>>
>> I can't figure out what might be wrong there either. I've tried a few 
>> variations on the tag sets but it either doesn't run because it can't find 
>> an appropriate function or gives the XML error.
>>
>> Any pointers would be appreciated.
>>
>> Thanks
>> Gareth
>>
>

-- 
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: [Review] Slow server, not maxing out CPU

2016-07-20 Thread James Reeves 
If you're going to be working with blocking I/O, then you're probably going
to get constrained by the default threadpool size of HTTP Kit, which is
only 4 threads. Up it to around 1000 and see if that improves matters.

You can get around this by writing asynchronous code, but your
async-handler isn't asynchronous.

- James

On 20 July 2016 at 22:02, Вук Мировић  wrote:

> I'm fooling around with Clojure and I implemented simple server that will
> randomly query/insert/update/delete random data from DB on every request.
> When I benchmark (wrk) server is slow (compared to similar solution) and I
> noticed that CPU is not maxed out, it's about ~30-40%.
> I used http-kit for HTTP server, Hakiri-CP as connection pool. Added some
> core.async hoping to improve the speed but results are the same.
> There is clearly something wrong with my code but I can't figure it out.
> I'm hoping if someone could throw a glimpse on my code to give a sugestion.
> Here is the code:
> https://github.com/wooque/bench/blob/master/clojure/src/bench/core.clj
>
> --
> 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.

[Bug?] Spec: spec/? not working?

2016-07-20 Thread Torsten Anders 
Dear all,

I have some problems using clojure.spec: ? does not work as I would expect 
it. Instead of specifying an optional value, it seems that such values are 
never permitted, and instead the next value is always matched. Please see 
the short example demonstration below. BTW, * seems to cause the same 
problem. 

What am I missing?


(ns test-ns
  (:require [clojure.spec :as spec]))

(spec/def ::test-spec (spec/cat :symbol symbol?
:optional-string (spec/? string?)
:int int?))
(spec/valid? ::test-spec '[test 42]) ; -> true
(spec/valid? ::test-spec '[test "my string" 42]) ; -> false

(spec/explain ::test-spec '[test "my string" 42])
;; In: [1] val: "my string" fails spec: :clojure2minizinc.core/test-spec 
at: [:int] predicate: int?


Best,
Torsten

-- 
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: Enhance spec/double-in to handle open and half-open intervals?

2016-07-20 Thread Alex Miller 
You can file a jira if you like, I'm not sure Rich's thoughts on this. 

Also, keep in mind that you can also compose preds and get this with 
slightly more effort now:

(s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %))




On Wednesday, July 20, 2016 at 2:03:28 PM UTC-5, Mars0i wrote:
>
> clojure.spec/double-in defines a spec that tests whether a double is 
> greater than or equal to a minimum value and less than or equal to a 
> maximum value.  This is useful for many purposes, but sometimes you need to 
> test whether a double is greater than a minimum or less than a maximum. 
>  There are many mathematical applications that assume half-open intervals 
> (> min and <= max; >= min and < max) or open intervals (> min and < max). 
>  Example: You are going to divide by the double, so it must be > 0, not 
> just >= 0.  Providing double-in but only allowing it to specify closed 
> intervals seems arbitrary.
>
> It's easy enough to write open-interval and half-open interval tests, 
> either using s/and with s/double-in, or just by defining a function from 
> scratch.  However, if Clojure is going to provide double-in, why make us do 
> that?  Why not have a common interface that adds two optional keywords to 
> specify whether the bounds are open or closed?  This is not a request to 
> add the kitchen sink; it's a natural extension to deal with a common use 
> case.  The alternative would be to define three additional versions of 
> double-in, and people will do that on their own, or define a new more 
> flexible double-in if there's no built-in spec function that does it.
>
>
> I'd suggest a new keyword with one of the following forms: 
>
>
> :min-open, :min-greater, :min-greater-than, :min-strict, :greater-min, 
> :strict-min, etc.,
>
>
> and a corresponding keyword for the max side.
>
>
> Default values should be false, for compatibility with the current 
> definition of double-in.
>
>
> I can add a JIRA ticket if this seems worthwhile.  I wanted to see what 
> people think first.  (I'd have to sign up with the JIRA system, but I 
> assume I'm allowed to do that.)  My apologies if there's already a JIRA 
> ticket for this.  I don't seem to be able to find anything on double-in, 
> but I'm not sure I understand the search syntax.
>

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

[Review] Slow server, not maxing out CPU

2016-07-20 Thread Вук Мировић 
I'm fooling around with Clojure and I implemented simple server that will 
randomly query/insert/update/delete random data from DB on every request.
When I benchmark (wrk) server is slow (compared to similar solution) and I 
noticed that CPU is not maxed out, it's about ~30-40%.
I used http-kit for HTTP server, Hakiri-CP as connection pool. Added some 
core.async hoping to improve the speed but results are the same.
There is clearly something wrong with my code but I can't figure it out. 
I'm hoping if someone could throw a glimpse on my code to give a sugestion.
Here is the 
code: https://github.com/wooque/bench/blob/master/clojure/src/bench/core.clj

-- 
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: Thoughts on clojure.spec

2016-07-20 Thread Gary Fredericks 
Here's a library you could add that functionality to: 
https://github.com/gfredericks/schpec

Gary

On Tuesday, July 19, 2016 at 1:30:27 AM UTC-5, Beau Fabry wrote:
>
> Right, and I don't think the "this is closed we shouldn't discuss it 
> anymore" line is great when people are advocating for a piece of 
> functionality. I understand Alex doesn't want endless threads bikeshedding 
> basically arbitrary naming choices, but that's not the same as people 
> making simple points of "I think X would be a good addition because of Y" 
> with no back and forth.
>
> Maybe enough people saying "yes that sounds like a good idea because Y" in 
> this thread will convince someone else that they should create a lib that 
> mirrors the old functionality, this is the general Clojure group and not 
> clojure-dev after all.
>
> Sorry about the meta.
>
> On Tuesday, July 19, 2016 at 3:51:09 PM UTC+10, Sean Corfield wrote:
>>
>> Well, both Alex and Rich have said the change is deliberate and there are 
>> no plans to change that decision – and Rich talked about ways you can add 
>> return value testing manually based on specs (if you want, but he won’t 
>> help you) – so it seems like a “closed” topic to me? (and Alex has shut 
>> down a couple of other threads that have continued on past a clear line of 
>> decision)
>>
>>  
>>
>> I was sad to see :ret checking go away but I accept Rich’s line of 
>> thinking on this and I’ll adjust my workflow accordingly. I find Rich’s 
>> point that instrumentation is now about ensuring functions are _*called*_ 
>> correctly rather than trying to establish that they _*behave*_ correctly 
>> oddly compelling, now that I’ve had some time to think about it and play 
>> with it 
>>
>>  
>>
>> Sean Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org
>>
>>  
>>
>> *From: *Beau Fabry
>> *Sent: *Monday, July 18, 2016 8:50 PM
>> *To: *Clojure
>> *Subject: *Re: Thoughts on clojure.spec
>>
>>  
>>
>> I think that was an explanation of why it's not particularly valuable in 
>> unit tests, but not really an explanation of why it wouldn't be useful in 
>> lower environments or canary boxes in distributed deployments. This thread 
>> has also touched on how not everything is gen-testable because of 
>> complexity, and I'd add that side-effects are another reason for that. We 
>> also have "you can just use assert on the return value" which is true, but 
>> seeing as I already have a database of expected return values that I've 
>> defined then it seems natural to be able to use that database to gain some 
>> extra testing value rather than define it again.
>>
>>  
>>
>> I'm not trying to argue for inclusion, if clojure core doesn't want to 
>> implement the feature then those who see value in it can trivially 
>> implement it themselves, but I haven't read anything that's made me think 
>> it wouldn't be useful.
>>
>>
>> On Tuesday, July 19, 2016 at 12:53:49 PM UTC+10, Sean Corfield wrote:
>>
>> Rich has given a pretty good explanation of why this was removed 
>> elsewhere. And in this thread, a week ago, he explained again why 
>> gen-testing :ret and :fn specs was the better approach.
>>
>>  
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>  
>>
>> On 7/18/16, 7:46 PM, "Oliver George" > of oli...@condense.com.au> wrote:
>>
>>  
>>
>> Here's the commit removing that aspect of instrument-all.  Not a big 
>> change.
>>
>>  
>>
>>
>> https://github.com/clojure/clojure/commit/30dd3d8554ff96f1acda7cbe31470d92df2f565a
>>
>>  
>>
>> As an aside, I also love the idea of the Clojure community fostering a 
>> culture of gen testing each chunk of well defined functionality.  If it's 
>> truly achievable the Clojure community could become known as an unstoppable 
>> force of robust code.
>>
>>  
>>
>> It would be something of a challenge for many of us... especially those 
>> wanting this particular feature!
>>
>>  
>>
>>  
>>
>> On 19 July 2016 at 10:36, Beau Fabry  wrote:
>>
>> > Do you find it frustrating that there's no way to turn on 
>> instrumentation of function outputs for manual testing?
>>
>>  
>>
>> Yes. I've mentioned this elsewhere but I think being able to turn on 
>> output checking in lower environments (dev, test, master, staging) is 
>> getting extra values from specs basically for free. Being able to do it 
>> seems pragmatic. I'm hoping it won't be too difficult to write an 
>> `overinstrument-all` that gives me that when I want it.
>>
>>
>> On Tuesday, July 12, 2016 at 5:36:39 PM UTC+10, Maarten Truyens wrote:
>>
>> I would also truly appreciate instrumentation of function outputs for 
>> manual outputs. I understand the rationale for not having it as the 
>> default, but could it perhaps be specified as an option s/instrument? 
>> (Considering that it was present in

Enhance spec/double-in to handle open and half-open intervals?

2016-07-20 Thread Mars0i 
clojure.spec/double-in defines a spec that tests whether a double is 
greater than or equal to a minimum value and less than or equal to a 
maximum value.  This is useful for many purposes, but sometimes you need to 
test whether a double is greater than a minimum or less than a maximum. 
 There are many mathematical applications that assume half-open intervals 
(> min and <= max; >= min and < max) or open intervals (> min and < max). 
 Example: You are going to divide by the double, so it must be > 0, not 
just >= 0.  Providing double-in but only allowing it to specify closed 
intervals seems arbitrary.

It's easy enough to write open-interval and half-open interval tests, 
either using s/and with s/double-in, or just by defining a function from 
scratch.  However, if Clojure is going to provide double-in, why make us do 
that?  Why not have a common interface that adds two optional keywords to 
specify whether the bounds are open or closed?  This is not a request to 
add the kitchen sink; it's a natural extension to deal with a common use 
case.  The alternative would be to define three additional versions of 
double-in, and people will do that on their own, or define a new more 
flexible double-in if there's no built-in spec function that does it.


I'd suggest a new keyword with one of the following forms: 


:min-open, :min-greater, :min-greater-than, :min-strict, :greater-min, 
:strict-min, etc.,


and a corresponding keyword for the max side.


Default values should be false, for compatibility with the current 
definition of double-in.


I can add a JIRA ticket if this seems worthwhile.  I wanted to see what 
people think first.  (I'd have to sign up with the JIRA system, but I 
assume I'm allowed to do that.)  My apologies if there's already a JIRA 
ticket for this.  I don't seem to be able to find anything on double-in, 
but I'm not sure I understand the search syntax.

-- 
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: ClojureScript 1.9.89 - cljs.spec & :preloads

2016-07-20 Thread mars0i 
This version isn't supposed to have implemented spec/double-in yet, right?  

I get "Use of undeclared Var cljs.spec/double-in".

Sorry to ask--I don't know my way around JIRA well, and searching for 
"double-in" brings up a lot of irrelevant tickets.

Thanks much.

-- 
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: Recursive clojure.spec doesn't work

2016-07-20 Thread Johan Jonasson 
It works! Thanks! 

Seems like I have to learn more about s/spec.

On Wednesday, July 20, 2016 at 5:46:20 PM UTC+2, Alex Miller wrote:
>
> s/spec is going to try to resolve that keyword during the definition. Does 
> this do what you want?
>
> (s/def :html/element
>   (s/spec (s/cat
>  :tag keyword?
>  :attrs map?
>  :children (s/* (s/alt :element :html/element 
>:string string?)
>
>
> On Wednesday, July 20, 2016 at 10:38:41 AM UTC-5, Johan Jonasson wrote:
>>
>> I might have stumbled upon a bug in clojure.spec, while trying to define 
>> a spec. This doesn't compile:
>>
>> (s/def :html/element
>>   (s/cat
>>:tag keyword?
>>:attrs map?
>>:children (s/* (s/alt :element (s/spec :html/element)
>>  :string  string?
>>
>> The exception says: "Unable to resolve spec: :html/element".
>>
>> Is it a bug, or is there another way to define this?
>>
>

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

Re: Recursive clojure.spec doesn't work

2016-07-20 Thread Alex Miller 
s/spec is going to try to resolve that keyword during the definition. Does 
this do what you want?

(s/def :html/element
  (s/spec (s/cat
 :tag keyword?
 :attrs map?
 :children (s/* (s/alt :element :html/element 
   :string string?)


On Wednesday, July 20, 2016 at 10:38:41 AM UTC-5, Johan Jonasson wrote:
>
> I might have stumbled upon a bug in clojure.spec, while trying to define a 
> spec. This doesn't compile:
>
> (s/def :html/element
>   (s/cat
>:tag keyword?
>:attrs map?
>:children (s/* (s/alt :element (s/spec :html/element)
>  :string  string?
>
> The exception says: "Unable to resolve spec: :html/element".
>
> Is it a bug, or is there another way to define this?
>

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

Recursive clojure.spec doesn't work

2016-07-20 Thread Johan Jonasson 
I might have stumbled upon a bug in clojure.spec, while trying to define a 
spec. This doesn't compile:

(s/def :html/element
  (s/cat
   :tag keyword?
   :attrs map?
   :children (s/* (s/alt :element (s/spec :html/element)
 :string  string?

The exception says: "Unable to resolve spec: :html/element".

Is it a bug, or is there another way to define this?

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

Re: Amazonica and S3

2016-07-20 Thread Gareth Rogers 
After chatting with a colleague who read this and showed me the magic of 
trace I think the problem with amazonica.aws.
s3/set-bucket-tagging-configuration is that I need

{:tag-sets [{:tag {"Formation" "notlive"}}]}

i.e. I need to know how to call setTag(string key, string value) which 
takes two args through the Amazonica. I've only dealt with single args 
before.

On Wednesday, 20 July 2016 14:53:11 UTC+1, Gareth Rogers wrote:
>
> Hi
>
> Has any one had any success using either 
> amazonica.aws.s3/set-bucket-notification-configuration or 
> amazonica.aws.s3/set-bucket-tagging-configuration?
>
> I've got
>
> (amazonica.aws.s3/set-bucket-notification-configuration
> "my.bucket.name"
> {"my-custom-event-name"
> {"" ;; This replaced with the ARN of an SQS queue I've created
>  "ObjectCreatedByPut" ;; [S3Event/ObjectCreatedByPut] ;; 
> "s3:ObjectCreated:Put" <-- tried all three
>  ;; :filter"/_SUCCESS"
>  }})
>
> and
>
> (amazonica.aws.s3/set-bucket-tagging-configuration
>  "my.bucket.name"
>  {:tag-sets [{"Formation" "notlive"}]})
>
> Both of those are wrapped with amazonica.core/with-credential which I've 
> omitted.
>
> The call to amazonica.aws.s3/set-bucket-notification-configuration returns 
> nil. I guess this means it's getting converted to a valid call but the S3 
> API is rejecting it silently? Anyone know what it should look like?
>
> The call to amazonica.aws.s3/set-bucket-tagging-configuration is throwing:
>
> Unhandled com.amazonaws.services.s3.model.AmazonS3Exception
>The XML you provided was not well-formed or did not validate
>against our published schema (Service: Amazon S3; Status Code: 400;
>Error Code: MalformedXML; Request ID: )
>
> I can't figure out what might be wrong there either. I've tried a few 
> variations on the tag sets but it either doesn't run because it can't find 
> an appropriate function or gives the XML error.
>
> Any pointers would be appreciated.
>
> Thanks
> Gareth
>

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

Amazonica and S3

2016-07-20 Thread Gareth Rogers 
Hi

Has any one had any success using either 
amazonica.aws.s3/set-bucket-notification-configuration or 
amazonica.aws.s3/set-bucket-tagging-configuration?

I've got

(amazonica.aws.s3/set-bucket-notification-configuration
"my.bucket.name"
{"my-custom-event-name"
{"" ;; This replaced with the ARN of an SQS queue I've created
 "ObjectCreatedByPut" ;; [S3Event/ObjectCreatedByPut] ;; 
"s3:ObjectCreated:Put" <-- tried all three
 ;; :filter"/_SUCCESS"
 }})

and

(amazonica.aws.s3/set-bucket-tagging-configuration
 "my.bucket.name"
 {:tag-sets [{"Formation" "notlive"}]})

Both of those are wrapped with amazonica.core/with-credential which I've 
omitted.

The call to amazonica.aws.s3/set-bucket-notification-configuration returns 
nil. I guess this means it's getting converted to a valid call but the S3 
API is rejecting it silently? Anyone know what it should look like?

The call to amazonica.aws.s3/set-bucket-tagging-configuration is throwing:

Unhandled com.amazonaws.services.s3.model.AmazonS3Exception
   The XML you provided was not well-formed or did not validate
   against our published schema (Service: Amazon S3; Status Code: 400;
   Error Code: MalformedXML; Request ID: )

I can't figure out what might be wrong there either. I've tried a few 
variations on the tag sets but it either doesn't run because it can't find 
an appropriate function or gives the XML error.

Any pointers would be appreciated.

Thanks
Gareth

-- 
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: Frustrations so far

2016-07-20 Thread James Reeves 
On 20 July 2016 at 13:49, Peter Romfeld  wrote:

> I really love clojure over all, it makes maintenance/collaboration of code
> such a breeze. its easy to get new employees start to work on it even
> without any previous clojure knowledge!
>
> I do hate the JVM startup shit, i hate how you it takes forever to fetch
> deps on a aws medium instance (you probably can fix it with uberjars)
>

To my mind, uberjars are the better way of deploying as they guarantee a
fixed binary, and you only have to build them once.


> Im frustrated with `empty?` throwing exceptions for Long and Keyword
>

What should happen? Asking whether an integer or keyword is "empty?"
doesn't really make sense IMO, and if it doesn't make sense, it should
throw an exception.


> I had some issues understanding that maps of certain size are not in order
> anymore because of the underlying java functions and optimizations
>

Maps are officially unordered. The fact that small maps are ordered is an
implementation detail (though one that I know trips up a lot of newcomers).


> the api docs are almost useless! - to get the arrity and stuff.. wtf i
> still have no clue how to use this new function i never used before...
>

Do you have an example of a poorly documented function? Also, do you know
about https://clojuredocs.org/?


> security features in most frameworks are just smoke and mirrors, functions
> that dont actually do what they should do...
>

Do you have an example?


> anyways, if i remember more i can add...
> just wanted to give you guys some input, and looking forward to make
> development experience even better!
>

Thanks for taking the trouble to post :)

- James

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

Frustrations so far

2016-07-20 Thread Peter Romfeld 
I really love clojure over all, it makes maintenance/collaboration of code 
such a breeze. its easy to get new employees start to work on it even 
without any previous clojure knowledge!

I do hate the JVM startup shit, i hate how you it takes forever to fetch 
deps on a aws medium instance (you probably can fix it with uberjars)
Im frustrated with `empty?` throwing exceptions for Long and Keyword
Not complete clojure, but i hate datomic.api/log since you cant put into 
your tests with a in-mem db
I had some issues understanding that maps of certain size are not in order 
anymore because of the underlying java functions and optimizations 
Im a bit upset about development reload with defrecords
most of the things that are not documented by the community are documented 
very cryptic and hard to understand
the api docs are almost useless! - to get the arrity and stuff.. wtf i 
still have no clue how to use this new function i never used before...
security features in most frameworks are just smoke and mirrors, functions 
that dont actually do what they should do...

anyways, if i remember more i can add...
just wanted to give you guys some input, and looking forward to make 
development experience even better!

cheers,
peter

-- 
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: Tongue, DYI i18n library for Clojure/Script

2016-07-20 Thread Nikita Prokopov 
Tongue is a do-it-yourself i18n library for Clojure and ClojureScript.

Tongue is very simple yet capable:

- Dictionaries are just Clojure maps.
- Translations are either strings, template strings or arbitrary functions.
- No additional build steps, no runtime resource loading.
- It comes with no built-in knowledge of world locales. It has all the 
tooling for you to define locales yourself though.
- Pure Clojure implementation, no dependencies.
- Can be used from both Clojure and ClojureScript.

In contrast with other i18n solutions relying on complex and limiting 
string-based syntax for defining pluralization, wording, special cases etc, 
Tongue lets you use arbitrary functions. It gives you convenience, code 
reuse and endless possibilities.

As a result you have a library that handles exaclty your case well with as 
much detail and precision as you need.

https://github.com/tonsky/tongue

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