Re: [ANN] walmartlabs/datascope 0.1.0

[Alan Moore]

+1 Thanks for this!

Alan

On Monday, June 27, 2016 at 10:57:56 AM UTC-7, Howard M. Lewis Ship wrote:
>
>
> A library that can be used to render typical Clojure data structures using 
> Graphviz.
>
> https://github.com/walmartlabs/datascope
>
> -- 
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

-- 
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: clojure.spec - s/and interferes with regular expressions

[Sean Corfield]

Using s/& and Mark’s fdef does “work” but the failure messages seem misleading:

 

boot.user=> (f 2 :even 4)

nil

boot.user=> (f 2 :even 3)

 

clojure.lang.ExceptionInfo: Call to #'boot.user/f did not conform to spec:

    val: () fails at: [:args :options] predicate: (& (* 
(cat :clojure.spec/k keyword? :clojure.spec/v :clojure.spec/any)) 
:clojure.spec/kvs->map (keys :opt-un [:boot.user/even])),  Insufficient input

    :clojure.spec/args  (2 :even 3)

    :clojure.spec/failure  :instrument-check-failed

 

Why Insufficient input here? Why doesn’t it point at 3 failing the ::even or 
even? predicate?

    

boot.user=> (f 2 :even 4 :odd 5)

 

clojure.lang.ExceptionInfo: Call to #'boot.user/f did not conform to spec:

    val: {:even 4, :odd 5} fails at: [:args :options] 
predicate: (fn [m] (not (contains? m :odd)))

    :clojure.spec/args  (2 :even 4 :odd 5)

    :clojure.spec/failure  :instrument-check-failed

 

This is fine: we see it fails the specific predicate provided.

    

boot.user=> (f 2 :even 4 :o 5)

nil

 

 

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 6/29/16, 5:07 PM, "Alex Miller"  wrote:

 

As soon as you introduce the s/and, you have dropped out of regex land and into 
a predicate. You are then matching something in a new nested regex inside the 
and like:  [[::even 4]]. To stay within the top-level regex and supply extra 
predicates, use s/& instead:

 

(s/def ::options

  (s/& (s/keys* :opt-un [::even]) (fn [m] (not (contains? m :odd)

 

user=> (s/conform ::options [:even 2])

{:even 2}

user=> (s/conform ::options [:even 2 :foo 5])

{:even 2, :foo 5}

 

user=> (s/explain ::options [:even 3])

val: () fails spec: :user/options predicate: (& (* (cat :clojure.spec/k 
keyword? :clojure.spec/v :clojure.spec/any)) :clojure.spec/kvs->map (keys 
:opt-un [:user/even])),  Insufficient input

user=> (s/explain ::options [:even 2 :odd 3])

val: {:even 2, :odd 3} fails spec: :user/options predicate: (fn [m] (not 
(contains? m :odd)))

 


On Wednesday, June 29, 2016 at 5:19:09 PM UTC-5, puzzler wrote:

I'm having trouble spec'ing out something like this, a function that takes an 
integer as an input followed by a series of optional keyworded args.  :even is 
an allowed optional keyword, but we definitely want to forbid :odd as an 
optional keyword.

(s/def ::even even?)
(s/def ::options 
  (s/and 
(s/keys* :opt-un [::even])
(fn [m] (not (contains? m :odd)

(defn f [n & {:as options}] nil)
(s/fdef f :args (s/cat :integer int? :options ::options))
(stest/instrument `f)

This doesn't work at all and gives all sorts of errors when f is called with 
any input. I believe it is because the use of s/and in the definition of 
::options interferes with the ability of ::options to be "flattened" into the 
s/cat definition.

My reasoning:

::options correctly validates [:even 2] and rejects [:even 2 :odd 3] and [:even 
3].  

If I omit the s/and and the second clause so that it reads:
(s/def ::options (s/keys* :opt-un [::even]))

this also behaves as expected.


So my conclusion is that the s/and is interfering with the ability of s/keys* 
to sit within the s/cat definition.

How does one solve this problem?

-- 
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: clojure.spec - s/and interferes with regular expressions

[Alex Miller]

As soon as you introduce the s/and, you have dropped out of regex land and 
into a predicate. You are then matching something in a new nested regex 
inside the and like:  [[::even 4]]. To stay within the top-level regex and 
supply extra predicates, use s/& instead:

(s/def ::options
  (s/& (s/keys* :opt-un [::even]) (fn [m] (not (contains? m :odd)

user=> (s/conform ::options [:even 2])
{:even 2}
user=> (s/conform ::options [:even 2 :foo 5])
{:even 2, :foo 5}

user=> (s/explain ::options [:even 3])
val: () fails spec: :user/options predicate: (& (* (cat :clojure.spec/k 
keyword? :clojure.spec/v :clojure.spec/any)) :clojure.spec/kvs->map (keys 
:opt-un [:user/even])),  Insufficient input
user=> (s/explain ::options [:even 2 :odd 3])
val: {:even 2, :odd 3} fails spec: :user/options predicate: (fn [m] (not 
(contains? m :odd)))


On Wednesday, June 29, 2016 at 5:19:09 PM UTC-5, puzzler wrote:
>
> I'm having trouble spec'ing out something like this, a function that takes 
> an integer as an input followed by a series of optional keyworded args.  
> :even is an allowed optional keyword, but we definitely want to forbid :odd 
> as an optional keyword.
>
> (s/def ::even even?)
> (s/def ::options 
>   (s/and 
> (s/keys* :opt-un [::even])
> (fn [m] (not (contains? m :odd)
> 
> (defn f [n & {:as options}] nil)
> (s/fdef f :args (s/cat :integer int? :options ::options))
> (stest/instrument `f)
>
> This doesn't work at all and gives all sorts of errors when f is called 
> with any input. I believe it is because the use of s/and in the definition 
> of ::options interferes with the ability of ::options to be "flattened" 
> into the s/cat definition.
>
> My reasoning:
> ::options correctly validates [:even 2] and rejects [:even 2 :odd 3] and 
> [:even 3].  
> If I omit the s/and and the second clause so that it reads:
> (s/def ::options (s/keys* :opt-un [::even]))
> this also behaves as expected.
>
> So my conclusion is that the s/and is interfering with the ability of 
> s/keys* to sit within the s/cat definition.
>
> How does one solve this problem?
>

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

clojure.spec - s/and interferes with regular expressions

[Mark Engelberg]

I'm having trouble spec'ing out something like this, a function that takes
an integer as an input followed by a series of optional keyworded args.
:even is an allowed optional keyword, but we definitely want to forbid :odd
as an optional keyword.

(s/def ::even even?)
(s/def ::options
  (s/and
(s/keys* :opt-un [::even])
(fn [m] (not (contains? m :odd)

(defn f [n & {:as options}] nil)
(s/fdef f :args (s/cat :integer int? :options ::options))
(stest/instrument `f)

This doesn't work at all and gives all sorts of errors when f is called
with any input. I believe it is because the use of s/and in the definition
of ::options interferes with the ability of ::options to be "flattened"
into the s/cat definition.

My reasoning:
::options correctly validates [:even 2] and rejects [:even 2 :odd 3] and
[:even 3].
If I omit the s/and and the second clause so that it reads:
(s/def ::options (s/keys* :opt-un [::even]))
this also behaves as expected.

So my conclusion is that the s/and is interfering with the ability of
s/keys* to sit within the s/cat definition.

How does one solve this problem?

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

Learning Google's Map Reduce with Clojure

[Olek]

Hi!

I was refreshing my knowledge from Google's Map Reduce.
I've decided to code some examples in Clojure since it is my favorite 
language.
Here is the code from the learning process 
https://github.com/naleksander/mapreduce

I guess that it is time now to code it in Scala *wink*

Btw. if I were to implement it from ground in real scalable manner I would 
choose HDFS, some distributed reliable message queue and would work on 
serializing and distributing user defined functions between nodes. Also 
current API had to be changed a bit (for example instead of few arguments I 
would just pass the map being the map reduce job specification).

Viva 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/d/optout.

Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8

[Sean Corfield]

On 6/29/16, 10:03 AM, "Lucas Bradstreet"  wrote:
> Sean, a lot of library developers still want to support Clojure 1.8,
> but this would prevent using spec with their projects.

clojure.java.jdbc solves that by having the specs in a separate namespace (and 
by the tests conditionally loading that and clojure.spec.test). 
clojure.java.jdbc supports back to Clojure 1.4.

Nikita, it would be interesting to know how far back (in Clojure versions) your 
library could support. I can see real value in being able to back port spec 
beyond 1.8…

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



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

Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8

[Lucas Bradstreet]

This looks great Nikita.

Sean, a lot of library developers still want to support Clojure 1.8,
but this would prevent using spec with their projects. This would help
there. Onyx in particular was going to avoid using spec for the time
being, but we may re-evaluate now.

On 30 June 2016 at 00:31, Sean Corfield  wrote:
> Interesting idea.
>
>
>
> If you’re already on Clojure 1.8, I think it’s pretty safe to upgrade to the
> Alpha builds of 1.9. We’re running 1.9 Alpha 7 in production at the moment
> (and will move to Alpha 8 in our next build after today).
>
>
>
> The only glitches we ran into were name collisions in libraries due to new
> predicates being added to core, and only one of those caused an actual
> breakage – and those libraries all got updated very quickly (big thanks
> mostly to Peter Taoussanis for the fast responses).
>
>
>
> 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 6/29/16, 5:16 AM, "Nikita Prokopov"  of proko...@gmail.com> wrote:
>
>
>
> Hi!
>
>
>
> Not sure if a good idea or bad, but if you were eager to play with latest
> version of clojure.spec but don’t want to upgrade your production to alpha
> version of the language, you can add clojure.spec capabilities as a library
> to 1.8:
>
>
>
> https://github.com/tonsky/clojure-future-spec
>
>
>
> :dependencies [
>
>   [org.clojure/clojure "1.8.0"]
>
>   [clojure-future-spec "1.9.0-alpha8"]
>
> ]
>
>
>
> (require '[clojure.spec :as spec])
>
> (require '[clojure.spec.gen :as spec.gen])
>
> (require '[clojure.future :refer :all])
>
>
>
> clojure.future namespace contains all new clojure.core functions like int?,
> seqable? etc
>
>
>
> The version numbers will follow clojure 1.9 versions. Expect this lib
> upgraded with every new Clojure alpha release until 1.9 if finally out.
>
>
>
> Nikita.
>
>
>
> --
> 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] clojure-future-spec, a backport of clojure.spec for 1.8

[Sean Corfield]

Interesting idea.

 

If you’re already on Clojure 1.8, I think it’s pretty safe to upgrade to the 
Alpha builds of 1.9. We’re running 1.9 Alpha 7 in production at the moment (and 
will move to Alpha 8 in our next build after today).

 

The only glitches we ran into were name collisions in libraries due to new 
predicates being added to core, and only one of those caused an actual breakage 
– and those libraries all got updated very quickly (big thanks mostly to Peter 
Taoussanis for the fast responses).

 

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 6/29/16, 5:16 AM, "Nikita Prokopov"  wrote:

 

Hi!

 

Not sure if a good idea or bad, but if you were eager to play with latest 
version of clojure.spec but don’t want to upgrade your production to alpha 
version of the language, you can add clojure.spec capabilities as a library to 
1.8:

 

https://github.com/tonsky/clojure-future-spec

 

:dependencies [

  [org.clojure/clojure "1.8.0"]

  [clojure-future-spec "1.9.0-alpha8"]

]

 

(require '[clojure.spec :as spec])

(require '[clojure.spec.gen :as spec.gen])

(require '[clojure.future :refer :all])

 

clojure.future namespace contains all new clojure.core functions like int?, 
seqable? etc

 

The version numbers will follow clojure 1.9 versions. Expect this lib upgraded 
with every new Clojure alpha release until 1.9 if finally out.

 

Nikita.

 

-- 
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: clojure.spec Invalid token error from different namespace when specs are registered with number

[Alex Miller]

According to the reader page (http://clojure.org/reference/reader), keyword 
names can't start with a number. However, unqualified keywords that start 
with a number have (accidentally) worked for a long time and we have 
effectively grandfathered them in. You're seeing some of the ragged edges 
of this (which has nothing to do with spec). There is a longer history and 
a number of tickets related to this if you poke around in jira.

On Wednesday, June 29, 2016 at 9:25:41 AM UTC-5, Leon Grapenthin wrote:
>
> Have isolated more: Namespaced keywords with numbers in the name all don't 
> work, but when using double-colon syntax they can be fabricated. 
>
> :a/1 -> RuntimeException Invalid token: :a/1 
>  clojure.lang.Util.runtimeException (Util.java:221)
> :user/1 ->  RuntimeException Invalid token: :a/1 
>  clojure.lang.Util.runtimeException (Util.java:221)
>
> ::1 -> :user/1
>
>
> On Wednesday, June 29, 2016 at 4:21:49 PM UTC+2, Leon Grapenthin wrote:
>>
>> I believe that this is a problem with how the reader resolves aliased 
>> keywords as the problem can be reproduced without spec. You should file a 
>> JIRA ticket.
>>
>> On Wednesday, June 29, 2016 at 9:22:49 AM UTC+2, Mamun wrote:
>>>
>>> Hi,
>>>
>>> Invalid token error from different namespace when specs are registered 
>>> with number
>>>
>>> Example 
>>>
>>> ;one.clj
>>>
>>> (s/def ::a string?)
>>> (s/def ::1 int?)
>>>
>>> ::1  ;Ok
>>> ::a  ;Ok
>>>
>>> ;one-test.clj
>>>
>>> :one/1  ;; Error
>>> :one/a  ;;Ok
>>>
>>> ;(gen/sample (s/gen ::1))
>>> ;(gen/sample (s/gen ::a))
>>>
>>>
>>>
>>> I am not sure, it is bug or not. But error should display in same 
>>> namespace also. 
>>>
>>> Clojure version: [org.clojure/clojure "1.9.0-alpha8"]
>>>
>>>
>>> Br,
>>> Mamun
>>>
>>

-- 
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: clojure.spec Invalid token error from different namespace when specs are registered with number

[Leon Grapenthin]

I believe that this is a problem with how the reader resolves aliased 
keywords as the problem can be reproduced without spec. You should file a 
JIRA ticket.

On Wednesday, June 29, 2016 at 9:22:49 AM UTC+2, Mamun wrote:
>
> Hi,
>
> Invalid token error from different namespace when specs are registered 
> with number
>
> Example 
>
> ;one.clj
>
> (s/def ::a string?)
> (s/def ::1 int?)
>
> ::1  ;Ok
> ::a  ;Ok
>
> ;one-test.clj
>
> :one/1  ;; Error
> :one/a  ;;Ok
>
> ;(gen/sample (s/gen ::1))
> ;(gen/sample (s/gen ::a))
>
>
>
> I am not sure, it is bug or not. But error should display in same 
> namespace also. 
>
> Clojure version: [org.clojure/clojure "1.9.0-alpha8"]
>
>
> Br,
> Mamun
>

-- 
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: clojure.spec Invalid token error from different namespace when specs are registered with number

[Leon Grapenthin]

Have isolated more: Namespaced keywords with numbers in the name all don't 
work, but when using double-colon syntax they can be fabricated. 

:a/1 -> RuntimeException Invalid token: :a/1 
 clojure.lang.Util.runtimeException (Util.java:221)
:user/1 ->  RuntimeException Invalid token: :a/1 
 clojure.lang.Util.runtimeException (Util.java:221)

::1 -> :user/1


On Wednesday, June 29, 2016 at 4:21:49 PM UTC+2, Leon Grapenthin wrote:
>
> I believe that this is a problem with how the reader resolves aliased 
> keywords as the problem can be reproduced without spec. You should file a 
> JIRA ticket.
>
> On Wednesday, June 29, 2016 at 9:22:49 AM UTC+2, Mamun wrote:
>>
>> Hi,
>>
>> Invalid token error from different namespace when specs are registered 
>> with number
>>
>> Example 
>>
>> ;one.clj
>>
>> (s/def ::a string?)
>> (s/def ::1 int?)
>>
>> ::1  ;Ok
>> ::a  ;Ok
>>
>> ;one-test.clj
>>
>> :one/1  ;; Error
>> :one/a  ;;Ok
>>
>> ;(gen/sample (s/gen ::1))
>> ;(gen/sample (s/gen ::a))
>>
>>
>>
>> I am not sure, it is bug or not. But error should display in same 
>> namespace also. 
>>
>> Clojure version: [org.clojure/clojure "1.9.0-alpha8"]
>>
>>
>> Br,
>> Mamun
>>
>

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

Re: [ANN] Clojure 1.9.0-alpha8

[Simon Belak]

Missed that s/nilable exists. Cheers. 


On 29 June 2016 at 16:04:05, Alex Miller (a...@puredanger.com) wrote:

Also, you can turn any predicate into a nil-accepting predicate with s/nilable.

user=> (s/valid? (s/nilable (s/every ::s/any)) nil)
true

On Wednesday, June 29, 2016 at 9:02:43 AM UTC-5, Alex Miller wrote:
user=> (s/explain (s/every ::s/any) nil)
val: nil fails predicate: coll?

indicates that s/every (also s/coll-of) validate using coll? as the predicate 
and coll? (like most type predicates) does not validate nil.

nil punning is more often done for sequences. Sequences with structure are 
typically speced using regex ops, which does validate on nil.

user=> (s/valid? (s/* ::s/any) nil)
true

On Wednesday, June 29, 2016 at 8:57:49 AM UTC-5, Simon Belak wrote:
map-of now conforming is fantastic news! 
One question though: why doesn't every validate when given nil for collection? 
Seems inconsistent given pervasive nil punning elsewhere and that [] validates.

s
--
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/vF3RuDWuX8I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] Clojure 1.9.0-alpha8

[Alex Miller]

Also, you can turn any predicate into a nil-accepting predicate with 
s/nilable.

user=> (s/valid? (s/nilable (s/every ::s/any)) nil)
true

On Wednesday, June 29, 2016 at 9:02:43 AM UTC-5, Alex Miller wrote:
>
> user=> (s/explain (s/every ::s/any) nil)
> val: nil fails predicate: coll?
>
> indicates that s/every (also s/coll-of) validate using coll? as the 
> predicate and coll? (like most type predicates) does not validate nil.
>
> nil punning is more often done for sequences. Sequences with structure are 
> typically speced using regex ops, which does validate on nil.
>
> user=> (s/valid? (s/* ::s/any) nil)
> true
>
> On Wednesday, June 29, 2016 at 8:57:49 AM UTC-5, Simon Belak wrote:
>>
>> map-of now conforming is fantastic news! 
>> One question though: why doesn't every validate when given nil for 
>> collection? Seems inconsistent given pervasive nil punning elsewhere and 
>> that [] validates.
>>
>> s
>>
>

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

Re: [ANN] Clojure 1.9.0-alpha8

[Alex Miller]

user=> (s/explain (s/every ::s/any) nil)
val: nil fails predicate: coll?

indicates that s/every (also s/coll-of) validate using coll? as the 
predicate and coll? (like most type predicates) does not validate nil.

nil punning is more often done for sequences. Sequences with structure are 
typically speced using regex ops, which does validate on nil.

user=> (s/valid? (s/* ::s/any) nil)
true

On Wednesday, June 29, 2016 at 8:57:49 AM UTC-5, Simon Belak wrote:
>
> map-of now conforming is fantastic news! 
> One question though: why doesn't every validate when given nil for 
> collection? Seems inconsistent given pervasive nil punning elsewhere and 
> that [] validates.
>
> s
>
>
> On Wednesday, June 29, 2016 at 12:13:25 AM UTC+2, Alex Miller wrote:
>>
>> Clojure 1.9.0-alpha8 is now available.
>>
>> Try it via
>>
>> - Download: 
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha8
>> - Dependency: [org.clojure/clojure "1.9.0-alpha8"]
>>
>> 1.9.0-alpha8 includes the following changes since 1.9.0-alpha7:
>>
>> The collection spec support has been greatly enhanced, with new controls 
>> for conforming, generation, counts, distinct elements and collection kinds. 
>> See the docs for every, every-kv, coll-of and map-of for details.
>>
>> instrumenting and testing has been streamlined and made more composable, 
>> with powerful new features for spec and gen overrides, stubbing, and 
>> mocking. See the docs for these functions in clojure.spec.test: instrument, 
>> test, enumerate-ns and summarize-results.
>>
>> Namespaced keyword reader format, printing and destructuring have been 
>> enhanced for lifting namespaces up for keys, supporting more succinct use 
>> of fully-qualified keywords. Updated docs will be added to clojure.org 
>> soon.
>>
>> Many utilities have been added, for keys spec merging, fn exercising, 
>> Java 1.8 timestamps, bounded-count and more.
>>
>> Changelog:
>>
>> clojure.spec:
>>
>> - [changed] map-of - now conforms all values and optionally all keys, has 
>> additional kind, count, gen options
>> - [changed] coll-of - now conforms all elements, has additional kind, 
>> count, gen options. No longer takes init-coll param.
>> - [added] every - validates a collection by sampling, with many 
>> additional options
>> - [added] every-kv - validates a map by sampling, with many additional 
>> options
>> - [added] merge
>> - [changed] gen overrides can now be specified by either name or path
>> - [changed] fspec generator - creates a function that generates return 
>> values according to the :ret spec and ignores :fn spec
>> - [added] explain-out - produces an explain output string from an 
>> explain-data result
>> - [changed] explain-data - output is now a vector of problems with a 
>> :path element, not a map keyed by path
>> - [added] get-spec - for looking up a spec in the registry by keyword or 
>> symbol
>> - [removed] fn-spec - see get-spec
>> - [added] exercise-fn - given a spec'ed function, returns generated args 
>> and the return value
>> - All instrument functions moved to clojure.spec.test
>>
>> clojure.spec.test:
>>
>> - [changed] instrument - previously took a var, now takes either a 
>> symbol, namespace symbol, or a collection of symbols or namespaces, plus 
>> many new options for stubbing or mocking. Check the docstring for more info.
>> - [removed] instrument-ns - see instrument
>> - [removed] instrument-all - see instrument
>> - [changed] unstrument - previously took a var, now takes a symbol, 
>> namespace symbol, or collection of symbol or namespaces
>> - [removed] unstrument-ns - see unstrument
>> - [removed] unstrument-all - see unstrument
>> - [added] instrumentable-syms - syms that can be instrumented
>> - [added] with-instrument-disabled - disable instrument's checking of 
>> calls within a scope
>> - [changed] check-var renamed to test and has a different signature, 
>> check docs
>> - [changed] run-tests - see test
>> - [changed] run-all-tests - see test
>> - [changed] check-fn - renamed to test-fn
>> - [added] abbrev-result - returns a briefer description of a test
>> - [added] summarize-result - returns a summary of many tests
>> - [added] testable-syms - syms that can be tested
>> - [added] enumerate-namespace - provides symbols for vars in namespaces
>>
>> clojure.core:
>>
>> - [changed] - inst-ms now works with java.time.Instant instances when 
>> Clojure is used with Java 8
>> - [added] bounded-count - if coll is counted? returns its count, else 
>> counts at most first n elements of coll using its seq
>>
>>

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

Re: [ANN] Clojure 1.9.0-alpha8

[Simon Belak]

map-of now conforming is fantastic news! 
One question though: why doesn't every validate when given nil for 
collection? Seems inconsistent given pervasive nil punning elsewhere and 
that [] validates.

s


On Wednesday, June 29, 2016 at 12:13:25 AM UTC+2, Alex Miller wrote:
>
> Clojure 1.9.0-alpha8 is now available.
>
> Try it via
>
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha8
> - Dependency: [org.clojure/clojure "1.9.0-alpha8"]
>
> 1.9.0-alpha8 includes the following changes since 1.9.0-alpha7:
>
> The collection spec support has been greatly enhanced, with new controls 
> for conforming, generation, counts, distinct elements and collection kinds. 
> See the docs for every, every-kv, coll-of and map-of for details.
>
> instrumenting and testing has been streamlined and made more composable, 
> with powerful new features for spec and gen overrides, stubbing, and 
> mocking. See the docs for these functions in clojure.spec.test: instrument, 
> test, enumerate-ns and summarize-results.
>
> Namespaced keyword reader format, printing and destructuring have been 
> enhanced for lifting namespaces up for keys, supporting more succinct use 
> of fully-qualified keywords. Updated docs will be added to clojure.org 
> soon.
>
> Many utilities have been added, for keys spec merging, fn exercising, Java 
> 1.8 timestamps, bounded-count and more.
>
> Changelog:
>
> clojure.spec:
>
> - [changed] map-of - now conforms all values and optionally all keys, has 
> additional kind, count, gen options
> - [changed] coll-of - now conforms all elements, has additional kind, 
> count, gen options. No longer takes init-coll param.
> - [added] every - validates a collection by sampling, with many additional 
> options
> - [added] every-kv - validates a map by sampling, with many additional 
> options
> - [added] merge
> - [changed] gen overrides can now be specified by either name or path
> - [changed] fspec generator - creates a function that generates return 
> values according to the :ret spec and ignores :fn spec
> - [added] explain-out - produces an explain output string from an 
> explain-data result
> - [changed] explain-data - output is now a vector of problems with a :path 
> element, not a map keyed by path
> - [added] get-spec - for looking up a spec in the registry by keyword or 
> symbol
> - [removed] fn-spec - see get-spec
> - [added] exercise-fn - given a spec'ed function, returns generated args 
> and the return value
> - All instrument functions moved to clojure.spec.test
>
> clojure.spec.test:
>
> - [changed] instrument - previously took a var, now takes either a symbol, 
> namespace symbol, or a collection of symbols or namespaces, plus many new 
> options for stubbing or mocking. Check the docstring for more info.
> - [removed] instrument-ns - see instrument
> - [removed] instrument-all - see instrument
> - [changed] unstrument - previously took a var, now takes a symbol, 
> namespace symbol, or collection of symbol or namespaces
> - [removed] unstrument-ns - see unstrument
> - [removed] unstrument-all - see unstrument
> - [added] instrumentable-syms - syms that can be instrumented
> - [added] with-instrument-disabled - disable instrument's checking of 
> calls within a scope
> - [changed] check-var renamed to test and has a different signature, check 
> docs
> - [changed] run-tests - see test
> - [changed] run-all-tests - see test
> - [changed] check-fn - renamed to test-fn
> - [added] abbrev-result - returns a briefer description of a test
> - [added] summarize-result - returns a summary of many tests
> - [added] testable-syms - syms that can be tested
> - [added] enumerate-namespace - provides symbols for vars in namespaces
>
> clojure.core:
>
> - [changed] - inst-ms now works with java.time.Instant instances when 
> Clojure is used with Java 8
> - [added] bounded-count - if coll is counted? returns its count, else 
> counts at most first n elements of coll using its seq
>
>

-- 
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] clojure-future-spec, a backport of clojure.spec for 1.8

[Nikita Prokopov]

Hi!

Not sure if a good idea or bad, but if you were eager to play with latest 
version of clojure.spec but don’t want to upgrade your production to alpha 
version of the language, you can add clojure.spec capabilities as a library 
to 1.8:

https://github.com/tonsky/clojure-future-spec

:dependencies [
  [org.clojure/clojure "1.8.0"]
  [clojure-future-spec "1.9.0-alpha8"]
]

(require '[clojure.spec :as spec])
(require '[clojure.spec.gen :as spec.gen])
(require '[clojure.future :refer :all])

clojure.future namespace contains all new clojure.core functions like int?, 
seqable? etc

The version numbers will follow clojure 1.9 versions. Expect this lib 
upgraded with every new Clojure alpha release until 1.9 if finally out.

Nikita.

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

clojure.spec Invalid token error from different namespace when specs are registered with number

[Mamun]

Hi,

Invalid token error from different namespace when specs are registered with 
number

Example 

;one.clj

(s/def ::a string?)
(s/def ::1 int?)

::1  ;Ok
::a  ;Ok

;one-test.clj

:one/1  ;; Error
:one/a  ;;Ok

;(gen/sample (s/gen ::1))
;(gen/sample (s/gen ::a))



I am not sure, it is bug or not. But error should display in same namespace 
also. 

Clojure version: [org.clojure/clojure "1.9.0-alpha8"]


Br,
Mamun

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