Re: Guidelines/Recommendations for namespaces and qualified keywords

[Mauricio Aldazosa]

On Mon, Oct 17, 2016 at 9:46 PM, James Gatannah 
wrote:

>
>
> On Saturday, October 15, 2016 at 10:17:15 PM UTC-5, Josh Tilles wrote:
>>
>> I’ve got a couple questions for Alex Miller and/or the other Cognitect
>> folks.
>>
>
> That isn't me. I'm just chiming in from the peanut gallery. Must of my
> "experience" so far stems from converting
> my toy projects from prismatic schema to spec.
>
>>
>>1. *Are single-segment namespaces still “bad” when it comes to
>>registering specs under qualified keywords?*
>>In the past, single-segment namespaces have been discouraged in the
>>Clojure community—both because of Java interop concerns and because of the
>>possibility of name-collision when combining projects. However, many of 
>> the
>>spec examples I’ve seen have demonstrated registering specs under keywords
>>qualified by a single-segment namespace. For example, the guide’s
>>section on multi-spec 
>>defines :search/url and :error/message. Is that because
>>namespace-qualifiers of specs shouldn’t be under the same constraints as
>>namespaces used to organize code?
>>
>> This part of the question interests me a lot.
>
> I've found myself defining a lot of specs in, say, the
> com.foo.project.schemas namespace.
>
> This used to be extremely convenient, due to ns aliases.
>
> I think the docs say that I should be able to set up the same kind of
> basic aliasing so that I can
> just refer to those specs as (for example) :c.f.p.s/whatever. But I
> haven't been able to actually
> get that to work yet.
>

You can use the alias to do that, if you have a ns declaration like this:

(ns test.core
  (:require [com.foo.project.schemas :as sch]))

Then you can use the alias to get to the specs in that namespace

::sch/bar => :com.foo.project.schemas/bar

Cheers,
Mauricio

-- 
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: Guidelines/Recommendations for namespaces and qualified keywords

[James Gatannah]

On Saturday, October 15, 2016 at 10:17:15 PM UTC-5, Josh Tilles wrote:
>
> I’ve got a couple questions for Alex Miller and/or the other Cognitect 
> folks.
>

That isn't me. I'm just chiming in from the peanut gallery. Must of my 
"experience" so far stems from converting
my toy projects from prismatic schema to spec.

>
>1. *Are single-segment namespaces still “bad” when it comes to 
>registering specs under qualified keywords?*
>In the past, single-segment namespaces have been discouraged in the 
>Clojure community—both because of Java interop concerns and because of the 
>possibility of name-collision when combining projects. However, many of 
> the 
>spec examples I’ve seen have demonstrated registering specs under keywords 
>qualified by a single-segment namespace. For example, the guide’s 
>section on multi-spec  
>defines :search/url and :error/message. Is that because 
>namespace-qualifiers of specs shouldn’t be under the same constraints as 
>namespaces used to organize code?
>
> This part of the question interests me a lot.

I've found myself defining a lot of specs in, say, the 
com.foo.project.schemas namespace.

This used to be extremely convenient, due to ns aliases.

I think the docs say that I should be able to set up the same kind of basic 
aliasing so that I can
just refer to those specs as (for example) :c.f.p.s/whatever. But I haven't 
been able to actually 
get that to work yet.

I've found myself with a lot of definitions that look like (apologies for 
the formatting/whitespace):

(s/def ::socket-description (s/keys :opt [::client-keys
  ::server-key]
:req [::ctx
  
:com.jimrthy.cljeromq.common/direction
  ::port
  ::sock-type
  
:com.jimrthy.cljeromq.common/socket
  :com.jimrthy.cljeromq.core/url]))

That isn't *too* bad. But this sort of thing gets annoying when I'm nesting 
these things into other namespaces. Especially from the REPL, which is 
lisp's strongest selling point (to me).

I'm willing to bet that I've just missed a talk somewhere about how this is 
supposed to work. Or maybe I just need to keep working on getting my head 
wrapped around these changes.

I don't want to hijack your thread. This was more of a "Me too! This is 
why...I think" sort of thing.. 




>1. I’m *guessing* not; it seems more likely that the single-segment 
>namespaces have been used only to keep the code snippets straightforward 
>and focused on spec, and that “real” code would alias (e.g.) 
>my-company.my-project.search as search before defining a ::search/url 
>spec.
>
>
> Thank you for your help. I really appreciate it.
>

Again, me too! Thanks,
James 

>
> Best,
> Josh
>

-- 
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] clj-xchart – A charting/plotting library for Clojure

[Mars0i]

On Monday, October 17, 2016 at 3:37:51 PM UTC-5, Jean Niklas L'orange wrote:
>
> Hi Marshall,
>
> On 17 October 2016 at 07:54, Mars0i  
> wrote:
>
>> Looks very nice! Thanks Jean Niklas.  I've been using Incanter for 
>> charts, which has been fine so far for my needs, but clj-xchart looks like 
>> it will make it easier to make nicer charts, and it would avoid loading 
>> much of Incanter when you don't need some of the other things Incanter 
>> provides.  (I also use nvd3 to generate charts in a browser with 
>> Clojurescript.)
>>
>
> Thanks! This was also parts of the rationale for clj-xchart as well: 
> Incanter is great, but it feels a bit strange to drag in both json and csv 
> dependencies if you only need to plot some charts.
>  
>
>> But if I'm plotting several sequences of y values that are embedded in a 
>> sequence of maps or vectors, each with several y values for the same x, I 
>> wonder if it could be more to efficient pass the entire complex sequence to 
>> the plotting function at once, and only provide one set of x values if all 
>> of the y values will share the same x's.  If the plotting function extracts 
>> the y values as it reads through the sequence of maps/vectors, and needs 
>> only one sequence of x's, then only two sequences are realized.
>>
>> Maybe this is an unusual need, at present, but as Clojure is used for 
>> more scientific applications, it might become more common.
>>
>
> XChart (and consequently clj-xchart) can take the same x-axis as input. So 
> you can reuse the same x values instead of creating 3 distinct but 
> identical ones:
>
> (let [x [1 2 3]
>   y1 [1 2 3]
>   y2 [2 4 6]
>   y3 [3 6 9]]
>   (c/xy-chart {"y1" {:x x :y y1}
>"y2" {:x x :y y2}
>"y3" {:x x :y y3}}))
>
> I don't think this is unique to clj-xchart though, the same should apply 
> to Incanter/JFreeChart.
>

Right.  I don't know why I didn't think of that.  Good idea.

Unfortunately, clj-xchart will indirectly realise almost all lists it is 
> given, as it calls .size() on them to ensure that the X/Y/error lists are 
> identical in size. It will also walk the lists to find the size/scale of 
> the chart to plot. I'm not sure if there's a way around that, except 
> perhaps if one pin the boundaries of the plot axes.
>
> That being said, it doesn't seem like a bad idea to provide some sort of 
> efficient view over data to avoid creating a new list that will be realised 
> with the exact same data in another list. I made an issue 
>  on this, it shouldn't 
> be too hard to implement either.
>

Great. 

> For what it's worth, I've had the same "issue" with large datasets as well 
> (10-20M elements). In my case there isn't that much interesting to look at 
> except the occational outlier, or if you have values which differ extremely 
> from one datapoint to another.
>
> What I tend to do is rebin/shrink the data set, typically by computing the 
> average/max value of partitions (after filtering away outliers), depending 
> on what I need to plot. I have a small section in the "Gotchas" section 
> named Many Datapoints 
> 
>  (bottom 
> of the page) which has a couple of lines on how one can do that. I haven't 
> found a good generic interface for it yet, so it's not provided by 
> clj-xchart as of now.
>

Yes, good idea for some situations.  For my present project, it's OK to 
simply use every 10th or 100th point, even when the data is wildly random, 
but sometimes I want to see them all.   Other data elements are roughly 
continuous, so it's no problem to sample every nth point.

-- 
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] boot-bundle, DRY for dependencies

[James Gatannah]

Sweet! And thanks!

I've been trying to find the time to learn enough boot to write this for 
myself.

On Saturday, October 15, 2016 at 8:28:58 AM UTC-5, Borkdude wrote:
>
> Only a few lines of code, but it does the job:
>
> https://github.com/borkdude/boot-bundle
>
> This library lets you define a set of dependencies by a keyword. Details 
> in the README.
>
> I found it especially useful in a multi-project repo where we use a lot of 
> the same dependencies in each project. 
> It's also possible to share your personal bundle via Clojars and use it in 
> your personal projects.
>

-- 
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: Possible ClojureScript compiler issue...

[Antonin Hildebrand]

I think one reason why these issues are reported infrequently is because it 
is really hard to track them down. I can imagine people disable :advanced 
optimizations or restructure their code instead of hunting down the real 
cause. John went really far to isolate/demonstrate the issue.

Thanks for posting that sentinel idea, Thomas. It looks really simple. I 
think instead of sentinel object we could use some large random integer 
which could have similar performance profile as checking for boolean.

I would add another possible idea:

4. we could alter google closure compiler with ClojureScript-aware renaming 
logic, it would preserve prefix $cljs prefix when renaming properties[1]. 
Also in ClojureScript compiler we would rename all cljs-related properties 
to use this convention.

Pros:
1. This would decrease a chance of clashes. When someone runs into it - it 
would be quite self-describing that "$cljs" named property is involved.

Cons:
1. This would lead to slightly bigger generated code (all the $cljs 
prefixes which would previously disappear).
2. The bigger downside IMO is that we would have to maintain our own fork 
of Closure Compiler. Which is not that scary with git. It is pretty easy to 
automate rebasing of a few patch-commits on top of arbitrary complex 
foreign repo.

[1] 
https://github.com/google/closure-compiler/blob/5616a66e40c5dc6ec9be9beacfc0ea20d47bbcfc/src/com/google/javascript/jscomp/RenameProperties.java#L284



On Sunday, October 16, 2016 at 4:36:38 PM UTC+2, Thomas Heller wrote:
>
> FWIW I investigated the check with "true" and a sentinel value and found 
> them to both have a small performance impact over just checking for a 
> true-ish property.
>
> http://dev.clojure.org/jira/browse/CLJS-1658
>
> The impact is really small so it might be worth the trade-off.
>
> /thomas
>
> On Sunday, October 16, 2016 at 3:59:20 PM UTC+2, David Nolen wrote:
>>
>> It's true that there other scenarios where you can encounter this but it 
>> gets reported infrequently enough that I don't think these kinds of 
>> property name collisions are common.
>>
>> Still it has come up before and I think the simplest solution least 
>> likely to adversely affect performance is to test for a def'onced unique 
>> object instead of `true`.
>>
>> David
>>
>> On Sat, Oct 15, 2016 at 8:46 PM, Antonin Hildebrand <
>> antonin.h...@gmail.com> wrote:
>>
>>> Unfortunately, this problem is not specific to `js->clj` only.
>>>
>>> I believe in general under :advanced optimizations, any object which was 
>>> created or modified by a code which 
>>> was not subject of the same closure compiler optimization pass could 
>>> exhibit similar problems when used with ClojureScript core functions like 
>>> `satisfies?`.
>>>
>>> That also includes working with external data (your case), and working 
>>> with objects created/modified by adding properties by string names.
>>>
>>> To illustrate, I created a screenshot of cljs type instance with two 
>>> protocols, to see the internals in dev mode:
>>> https://dl.dropboxusercontent.com/u/559047/cljs-protocol-internals-01.png
>>> In the selected text I highlighted part of generated code for 
>>> `satisfies?` call.
>>>
>>> ClojureScript adds/checks $cljs prefixed properties to objects. These 
>>> internal properties get renamed by closure compiler.
>>> So any object which happens to have one of those renamed names 
>>> independently added as their property will potentially confuse functions 
>>> like `satisfies?`.
>>>
>>> Possible solutions I see:
>>>
>>> 1. use string names for clojurescript internal properties, and avoid 
>>> clashes by using "unique-enough" prefix even in advanced mode - still not 
>>> safe solution, but would minimize clash chances
>>>
>>> or 
>>>
>>> 2. start tracking which objects belong to cljs land, have one 
>>> "unique-enough" string name as a marker, clojurescript functions like 
>>> satisfies? would check this marker before proceeding further. Still dirty, 
>>> one could clobber cljs properties by modifying a cljs-land-object from 
>>> unaware Javascript code. And this would probably change behaviour of some 
>>> existing code.
>>>
>>> or
>>>
>>> 3. use prototypal inheritance and "hide" all ClojureScript internal 
>>> properties in a new link in the prototype chain, plain javascript objects 
>>> would miss this link so it could be easily detected, properties would not 
>>> clash even if they got same names. ClojureScript functions like satisfies? 
>>> would properly
>>> walk the chain and read properties from proper link which belongs only 
>>> to ClojureScript. Ale we would not need any special "magic" marker - the 
>>> Javascript type of the link in prototype would safely identify it.
>>> I believe this would be correct solution. But I guess, this would be too 
>>> dramatic change in ClojureScript internals and might break a lot of other 
>>> things I currently don't understand. Also performance could get a hit.
>>>
>>> Better ideas, anyone? :-)
>>>

Re: Java interop: dealing with Java implementation instances vs interfaces

[Aaron Cohen]

My guess is that you're getting a message related to there being no
overload of the Producer.send method that accepts a String.

In your Java code, you're calling String.getBytes you need to do the same
in you Clojure code.

--Aaron

On Sun, Oct 16, 2016 at 2:42 AM, hiskennyness  wrote:

> Not sure if this is a Java question or Clojure question, but I think it is
> the latter.
>
> I am trying to use the Yahoo pulsar library https://mvnrepository.
> com/artifact/com.yahoo.pulsar/pulsar-client/1.14 from Clojure.
>
> It is going OK in general, but a couple times now trying to replicate Java
> code such as:
>
> Producer producer = client.createProducer("persistent://sample/
> standalone/ns1/my-topic");
>
> ..with:
>
>   (let [prod (.createProducer client "persistent://sample/
> standalone/ns1/ktopic")]
> )
>
> ...all goes well except I end up with prod bound to an instance of
> ProducerImpl.
>
> My Java is zilch but I presume the Java code binding the impl to a var
> type Producer is why the code can then execute:
>
> producer.send("my-message".getBytes());
>
> ...whereas I get an error about send not being defined when I do:
>
> (.send prod "Hi Mom")
>
> I looked around for a way to "cast" the impl to a Producer but came up
> empty.
>
> I did find a public sendAsync on ProducerImpl and that almost worked but
> then I ran into the same impl vs interface issue with another class
> (MessageBuilder) and decided I better figure this issue out once and for
> all.
>
> Any ideas?
>
> -kt
>
>
>
> --
> 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.

code from spec with clojure.spec?

[Joe Corneli]

As a running example related to the ideas in 
http://clojure.org/guides/spec#_spec_ing_functions, please consider the 
following function:

(defn mapper [x y]
  {:tacos (vec (range x))
   :burritos (vec (range y))})

Example input and output:

(mapper 2 4) ;=> {:tacos [0 1], :burritos [0 1 2 3]}

OK, I'll go ahead and write a sensible-seeming spec for this function now, 
as follows:

(s/fdef mapper
:args (s/cat :t (s/and integer? #(> % 0))
 :b (s/and integer? #(> % 0)))
:ret map?
:fn (s/and #(= (-> % :ret :tacos)
   (vec (range (-> % :args :t
   #(= (-> % :ret :burritos)
   (vec (range (-> % :args :b))

My first question: Is there a way to only write the spec, and have the 
function generated automatically?   The behavior I have in mind is (after 
all) specified in the :fn part of the fdef. 

And, another somewhat related question: if I redefine the function to do 
nothing, and then exercise it, I get output that doesn't seem to conform to 
the :fn condition given above, but no error -- why is that?

(defn mapper [x y])
(s/exercise-fn `mapper)
;=> ([(1 3) nil] [(1 1) nil] [(4 2) nil] [(2 3) nil] [(6 3) nil] [(15 2633) 
nil] [(3 1) nil] [(3 4) nil] [(1 1) nil] [(28 4) nil])

Thanks for any help!

-- 
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] clj-xchart – A charting/plotting library for Clojure

[Jean Niklas L'orange]

Hi Marshall,

On 17 October 2016 at 07:54, Mars0i  wrote:

> Looks very nice! Thanks Jean Niklas.  I've been using Incanter for charts,
> which has been fine so far for my needs, but clj-xchart looks like it will
> make it easier to make nicer charts, and it would avoid loading much of
> Incanter when you don't need some of the other things Incanter provides.
> (I also use nvd3 to generate charts in a browser with Clojurescript.)
>

Thanks! This was also parts of the rationale for clj-xchart as well:
Incanter is great, but it feels a bit strange to drag in both json and csv
dependencies if you only need to plot some charts.


> Since you've developed a charting library, maybe I'll mention a feature
> that I have wanted (I think!):
>
> I've been making plots with a large number of points--100K, sometimes even
> 1M or 2M per data sequence.  Sometimes I will sample a larger sequence
> every 10 or 100 steps to reduce the burden on the Incanter or nvd3 plotting
> function, but sometimes I want to see what the data looks like with all of
> the points.
>
> I generate the data in a lazy sequence, using iterate, where, let's say,
> each element of the sequence is a map containing several pieces  of y
> values for the x value corresponding to that element of the sequence, e.g.
>
> data = ({:a y-a-1, :b y-b-1, :c y-c-1}, {:a y-a-2, :b y-b-2, :c y-c-2},
> ...)
>
> In order to plot all three sequences of y values in Incanter or nvd3 (and
> clj-xchart?), I have to extract a new sequence of values for each data
> series, e.g. like this:
>
> (map :a data)
> (map :b data)
> (map :c data)
>
> and I have to generate several sequences of x values by calling (range)
> repeatedly.  I pass these six lazy sequences to the chart function, but at
> least in Incanter and nvd3, I don't believe Incanter does anything until it
> realizes all of the sequences.  That means that it realizes six distinct
> sequences, I think, and my initial sequence of maps will have been realized
> as well.
>
> But if I'm plotting several sequences of y values that are embedded in a
> sequence of maps or vectors, each with several y values for the same x, I
> wonder if it could be more to efficient pass the entire complex sequence to
> the plotting function at once, and only provide one set of x values if all
> of the y values will share the same x's.  If the plotting function extracts
> the y values as it reads through the sequence of maps/vectors, and needs
> only one sequence of x's, then only two sequences are realized.
>
> Maybe this is an unusual need, at present, but as Clojure is used for more
> scientific applications, it might become more common.
>

XChart (and consequently clj-xchart) can take the same x-axis as input. So
you can reuse the same x values instead of creating 3 distinct but
identical ones:

(let [x [1 2 3]
  y1 [1 2 3]
  y2 [2 4 6]
  y3 [3 6 9]]
  (c/xy-chart {"y1" {:x x :y y1}
   "y2" {:x x :y y2}
   "y3" {:x x :y y3}}))

I don't think this is unique to clj-xchart though, the same should apply to
Incanter/JFreeChart.

Unfortunately, clj-xchart will indirectly realise almost all lists it is
given, as it calls .size() on them to ensure that the X/Y/error lists are
identical in size. It will also walk the lists to find the size/scale of
the chart to plot. I'm not sure if there's a way around that, except
perhaps if one pin the boundaries of the plot axes.

That being said, it doesn't seem like a bad idea to provide some sort of
efficient view over data to avoid creating a new list that will be realised
with the exact same data in another list. I made an issue
 on this, it shouldn't be
too hard to implement either.



For what it's worth, I've had the same "issue" with large datasets as well
(10-20M elements). In my case there isn't that much interesting to look at
except the occational outlier, or if you have values which differ extremely
from one datapoint to another.

What I tend to do is rebin/shrink the data set, typically by computing the
average/max value of partitions (after filtering away outliers), depending
on what I need to plot. I have a small section in the "Gotchas" section
named Many Datapoints

(bottom
of the page) which has a couple of lines on how one can do that. I haven't
found a good generic interface for it yet, so it's not provided by
clj-xchart as of now.

-- 
Regards,
Jean Niklas L'orange

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

Re: Help with using spec

[Alex Miller]

I would back way up to the beginning and reconsider your ::board spec. 
Generally for any data where the structures are homogenous, you're probably 
better off using one of the collection specs like coll-of (or map-of, 
every, every-kv) rather than a regex, which should primarily be used when 
you have a sequential structure with syntactic "parts" to it (such as an 
arg string or other "dsl" type use case).

Because s/and flows conformed values you can get the same effect as you did 
with &:

(s/def ::board (s/and (s/coll-of ::row :min-count 1) #(apply = (map count 
%

Your generator seems like it should work. You might also want to constrain 
more tightly than pos-int? to keep it from getting out of hand. You could 
use something like (s/gen (s/int-in 1 10)) for example.



On Monday, October 17, 2016 at 2:32:20 PM UTC-5, Jason Courcoux wrote:
>
> Hi.
>
> I've been experimenting with clojure spec and a game of life problem, and 
> have been trying to spec a rectangular board of unknown size made up of a 
> collection of rows, each of which contain an equal number of cells. My 
> initial attempt was:-
>
> (def cell? #{0 1})
>
> (s/def ::row (s/coll-of cell? :min-count 1))
>
> (s/def ::board (s/& (s/+ ::row)
> #(apply = (map count %
>
>
> This appears to work, but I'm wondering if there is a better way to 
> specify the constraint that every row should be the same length? What would 
> be the recommended way to achieve this?
>
> Following on from this, I then wanted to generate input boards and 
> exercise a function so I tried the following which give me an 
> ArityException:-
>
> (s/def ::board (s/with-gen
>  (s/& (s/+ ::row)
>   #(apply = (map count %)))
>  #(gen/bind (s/gen pos-int?)
> (fn [n]
>   (s/gen (s/coll-of (s/coll-of cell? :count 
> n)))
>
> (s/fdef my-function :args (s/cat :board ::board))
>
> (defn my-function [board])
>
> (s/exercise (:args (s/get-spec `my-function)) 1)
>
> => ([([1] [0] [0] [1] [0]) {:board [[1] [0] [0] [1] [0]]}])
>
> (s/exercise-fn `my-function)
>
> => ArityException Wrong number of args (20) passed to: user/my-function
>
>
This is pretty interesting and the number 20 is pretty suspicious as that's 
the max number of args per function - I'm guessing pos-int? is causing 
problems there.
 

>
>
> If I try and do something similar without the custom generator such as:
>
> (s/def ::coll (s/coll-of (s/coll-of int? :count 2)))
>
> (s/fdef my-function2 :args (s/cat :board ::coll))
>
> (defn my-function2 [board])
>
> (s/exercise (:args (s/get-spec `my-function2)) 1)
>
> => ([(*[*[0 -1] [0 -1] [0 -1]*]*) {:board [[0 -1] [0 -1] [0 -1]]}])
>
> (s/exercise-fn `my-function2)
>
> This all works as expected. I can see that there is an extra level of 
> nesting here though and this must be where the error is coming from, as 
> it's applying my-function to the collection rather than using it as a 
> single argument - but I'm not sure what is causing this difference. 
>
> These look the same in terms of structure:
>
> (gen/sample (s/gen ::coll) 1)
> => ([[-1 -1] [-1 0] [0 -1] [-1 -1] [-1 0] [-1 0]])
>
> (gen/sample (s/gen ::board) 1)
> => ([[0 1] [1 1] [1 1] [1 1] [1 1] [0 0] [0 1]])
>
> (s/fdef my-function :args (s/cat :board ::board))
>
> (s/fdef my-function2 :args (s/cat :board ::coll))
>
>
> But these don't:
>
> (gen/sample (s/gen (:args (s/get-spec `my-function))) 1)
> => (([1 0] [0 0] [0 1] [0 1] [1 1]))
> (gen/sample (s/gen (:args (s/get-spec `my-function2))) 1)
> => (([[-1 -1] [-1 -1] [0 0] [0 0] [-1 0] [-1 -1] [0 0]]))
>
>
> I'm sure it's something obvious, but I been looking for a couple of hours 
> and can't seem to see it - could someone please help point me in the right 
> direction.
>
> Thanks in advance.
>
> Jason
>
>
> -- 
> Jason Courcoux
>

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

Help with using spec

['Jason Courcoux' via Clojure]

Hi.

I've been experimenting with clojure spec and a game of life problem, and
have been trying to spec a rectangular board of unknown size made up of a
collection of rows, each of which contain an equal number of cells. My
initial attempt was:-

(def cell? #{0 1})

(s/def ::row (s/coll-of cell? :min-count 1))

(s/def ::board (s/& (s/+ ::row)
#(apply = (map count %


This appears to work, but I'm wondering if there is a better way to specify
the constraint that every row should be the same length? What would be the
recommended way to achieve this?

Following on from this, I then wanted to generate input boards and exercise
a function so I tried the following which give me an ArityException:-

(s/def ::board (s/with-gen
 (s/& (s/+ ::row)
  #(apply = (map count %)))
 #(gen/bind (s/gen pos-int?)
(fn [n]
  (s/gen (s/coll-of (s/coll-of cell? :count n)))

(s/fdef my-function :args (s/cat :board ::board))

(defn my-function [board])

(s/exercise (:args (s/get-spec `my-function)) 1)

=> ([([1] [0] [0] [1] [0]) {:board [[1] [0] [0] [1] [0]]}])

(s/exercise-fn `my-function)

=> ArityException Wrong number of args (20) passed to: user/my-function



If I try and do something similar without the custom generator such as:

(s/def ::coll (s/coll-of (s/coll-of int? :count 2)))

(s/fdef my-function2 :args (s/cat :board ::coll))

(defn my-function2 [board])

(s/exercise (:args (s/get-spec `my-function2)) 1)

=> ([(*[*[0 -1] [0 -1] [0 -1]*]*) {:board [[0 -1] [0 -1] [0 -1]]}])

(s/exercise-fn `my-function2)

This all works as expected. I can see that there is an extra level of
nesting here though and this must be where the error is coming from, as
it's applying my-function to the collection rather than using it as a
single argument - but I'm not sure what is causing this difference.

These look the same in terms of structure:

(gen/sample (s/gen ::coll) 1)
=> ([[-1 -1] [-1 0] [0 -1] [-1 -1] [-1 0] [-1 0]])

(gen/sample (s/gen ::board) 1)
=> ([[0 1] [1 1] [1 1] [1 1] [1 1] [0 0] [0 1]])

(s/fdef my-function :args (s/cat :board ::board))

(s/fdef my-function2 :args (s/cat :board ::coll))


But these don't:

(gen/sample (s/gen (:args (s/get-spec `my-function))) 1)
=> (([1 0] [0 0] [0 1] [0 1] [1 1]))
(gen/sample (s/gen (:args (s/get-spec `my-function2))) 1)
=> (([[-1 -1] [-1 -1] [0 0] [0 0] [-1 0] [-1 -1] [0 0]]))


I'm sure it's something obvious, but I been looking for a couple of hours
and can't seem to see it - could someone please help point me in the right
direction.

Thanks in advance.

Jason


-- 
Jason Courcoux

-- 
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: Is there an easy way for s/keys spec to work against both qualified/unqualiffied keys at the same time?

[Mauricio Aldazosa]

On Sun, Oct 16, 2016 at 11:40 PM, Ikuru Kanuma  wrote:

> Mauricio, thanks for the response!
> I agree that that gets what I asked for done, but that solution is in
> essence writing the same
> qualified/unqualified version of the spec twice and sounded redundant,
> which lead to my question.
> I guess it is what it is in that case...
>

Oh I see, maybe the reduncancy can be removed by creating a macro.
Something like:

(defmacro qualified-or-unqualified
  [k & specs]
  `(s/def ~k
 (s/or :qualified (s/keys :req ~specs)
   :unqualified (s/keys :req-un ~specs

And then defining the new specs would be something like:

(qualified-or-unqualified ::map-with-numbers ::some-number)
(s/valid? ::map-with-numbers {::some-number 3}) => true
(s/valid? ::map-with-numbers {:some-number 3})  => true

I'm sure the proposed macro is by no means complete, but I hope it points
you to one possible solution.

Cheers,
Mauricio

-- 
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: Java like static typing for Clojure?

[Colin Yates]

Thanks Sean.

On 17 October 2016 at 19:21, Sean Corfield  wrote:
> We have 1.9 Alpha 13 in production.
>
> We’ve had nearly all the 1.9 Alpha builds in production. After all, right now 
> 1.9 = 1.8 plus clojure.spec with some minor additions to clojure.core (new 
> predicates).
>
> 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 10/17/16, 10:47 AM, "Colin Yates"  colin.ya...@gmail.com> wrote:
>
> I have finally found time to watch Stu's video. It was very useful
> introducing clojure.spec (even if I thought he over-egged the pudding
> somewhat ;-)).
>
> I know there is a back port, but are there any other strategies of
> using this on 1.9 and building against 1.8? I was thinking of building
> a tower of yaks such that a lein 1.9 profile included a src directory
> which had all of the spec declarations in which the 1.8 profile used
> in production excluded. I am hesitant to rely on 1.9 at the moment -
> how stable have others found it?
>
>
>
>
> --
> 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: Java like static typing for Clojure?

[Sean Corfield]

We have 1.9 Alpha 13 in production.

We’ve had nearly all the 1.9 Alpha builds in production. After all, right now 
1.9 = 1.8 plus clojure.spec with some minor additions to clojure.core (new 
predicates).

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 10/17/16, 10:47 AM, "Colin Yates"  wrote:

I have finally found time to watch Stu's video. It was very useful
introducing clojure.spec (even if I thought he over-egged the pudding
somewhat ;-)).

I know there is a back port, but are there any other strategies of
using this on 1.9 and building against 1.8? I was thinking of building
a tower of yaks such that a lein 1.9 profile included a src directory
which had all of the spec declarations in which the 1.8 profile used
in production excluded. I am hesitant to rely on 1.9 at the moment -
how stable have others found it?
   



-- 
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: Java like static typing for Clojure?

[Colin Yates]

I have finally found time to watch Stu's video. It was very useful
introducing clojure.spec (even if I thought he over-egged the pudding
somewhat ;-)).

I know there is a back port, but are there any other strategies of
using this on 1.9 and building against 1.8? I was thinking of building
a tower of yaks such that a lein 1.9 profile included a src directory
which had all of the spec declarations in which the 1.8 profile used
in production excluded. I am hesitant to rely on 1.9 at the moment -
how stable have others found it?

On 17 October 2016 at 13:08, Timothy Baldridge  wrote:
> I highly recommend this talk on Spec by Stu Halloway. Spec is a new feature
> coming in Clojure 1.9, and this talk goes into the pros/cons of static
> typing and tests and shows how there can be a better way.
>
> https://www.youtube.com/watch?v=VNTQ-M_uSo8
>
>
>
> On Sun, Oct 16, 2016 at 5:58 PM, Alan Thompson  wrote:
>>
>> Be sure to check out Plumatic Schema (previously Prismatic Schema) if you
>> haven't already.  There is also a good Clojure Conj video from 2013.
>> Alan
>>
>> On Sat, Oct 15, 2016 at 3:14 PM, Didier  wrote:
>>>
>>> I know a lot of people like to say how unhelpful Java like static typing
>>> is, and only more powerful type systems of the ML family add value, but I've
>>> been wondering recently if for Clojure it wouldn't make more sense to simply
>>> extend the type hints to enable an optional Java like static typing scheme.
>>>
>>> It is my understanding that ML style static typing is incredibly
>>> difficult to add properly and without compromise to a dynamic language. That
>>> doing so limits the scope of type inference, rendering the task of adding
>>> type info more tedious then in ML languages themselves.
>>>
>>> ML style static typing provide enhanced safety grantees, but seem to add
>>> too much complexity to Clojure to be practical. What about a Java like
>>> static typing scheme though?
>>>
>>> I haven't found in practice that the safety of Clojure was an issue, as
>>> the REPL workflow tend to promote quite a lot of testing. So I'm not too
>>> worried about needing the state of the art of provable correctness for my
>>> programs. What has been a biggest cause of issue to me was refactoring and
>>> shared code base across a team. Those last two use cases are actually pretty
>>> well handled by Java like static type checking. Is it a powerful type
>>> checker, not really, but it enables most trivial type errors to be caught
>>> early, and it allows easier integration points for other devs to follow, as
>>> well as documentation for functions, better tools support and easier
>>> refactoring, while also enabling performance optimizations.
>>>
>>> I have limited knowledge in typing systems, and have no idea how easy it
>>> is to implement them, but as a user of Clojure, I feel like I would find an
>>> optional Java like static typing a great addition, one that I am more
>>> willing to use and benefit from then Typed Clojure's more complex ML style
>>> type checking.
>>>
>>> What do other think?
>>> Can anyone with better knowledge tell me if this would be feasible or if
>>> adding such gradual typing system is effectively as hard as adding ML style
>>> type checking?
>>>
>>> --
>>> 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.
>
>
>
>
> --
> “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 

Re: Java like static typing for Clojure?

[Stephen Lester]

Hi there!

There is an 'optional type system' for Clojure in 'core.typed':

https://github.com/clojure/core.typed

But it also seems like others who were using such a type system have
stepped away from it:

https://circleci.com/blog/why-were-no-longer-using-core-typed/


On 10/15/2016 03:14 PM, Didier wrote:
> I know a lot of people like to say how unhelpful Java like static
> typing is, and only more powerful type systems of the ML family add
> value, but I've been wondering recently if for Clojure it wouldn't
> make more sense to simply extend the type hints to enable an optional
> Java like static typing scheme.
>
> It is my understanding that ML style static typing is incredibly
> difficult to add properly and without compromise to a dynamic
> language. That doing so limits the scope of type inference, rendering
> the task of adding type info more tedious then in ML languages themselves.
>
> ML style static typing provide enhanced safety grantees, but seem to
> add too much complexity to Clojure to be practical. What about a Java
> like static typing scheme though?
>
> I haven't found in practice that the safety of Clojure was an issue,
> as the REPL workflow tend to promote quite a lot of testing. So I'm
> not too worried about needing the state of the art of provable
> correctness for my programs. What has been a biggest cause of issue to
> me was refactoring and shared code base across a team. Those last two
> use cases are actually pretty well handled by Java like static type
> checking. Is it a powerful type checker, not really, but it enables
> most trivial type errors to be caught early, and it allows easier
> integration points for other devs to follow, as well as documentation
> for functions, better tools support and easier refactoring, while also
> enabling performance optimizations.
>
> I have limited knowledge in typing systems, and have no idea how easy
> it is to implement them, but as a user of Clojure, I feel like I would
> find an optional Java like static typing a great addition, one that I
> am more willing to use and benefit from then Typed Clojure's more
> complex ML style type checking.
>
> What do other think?
> Can anyone with better knowledge tell me if this would be feasible or
> if adding such gradual typing system is effectively as hard as adding
> ML style type checking?
> -- 
> 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.


signature.asc
Description: OpenPGP digital signature

Call for Contributions: BOB 2017 - Berlin, Feb 24, 2017 (Deadline Oct 30)

[Michael Sperber]

Clojure proposals are very welcome at BOB!

 BOB Conference 2017
 "What happens when we use what's best for a change?"
  http://bobkonf.de/2017/en/cfp.html
 Berlin, February 24
Call for Contributions
  Deadline: October 30, 2016

You are actively engaged in advanced software engineering methods,
implement ambitious architectures and are open to cutting-edge
innovation? Attend this conference, meet people that share your goals,
and get to know the best software tools and technologies available
today. We strive to offer a day full of new experiences and
impressions that you can use to immediately improve your daily life as
a software developer.

If you share our vision and want to contribute, submit a proposal for
a talk or tutorial!

Topics
--

We are looking for talks about best-of-breed software technology, e.g.:

- functional programming
- persistent data structures and databases
- types
- formal methods for correctness and robustness
- abstractions for concurrency and parallelism
- metaprogramming
- probabilistic programming
- ... everything really that isn’t mainstream, but you think should be.

Presenters should provide the audience with information that is
practically useful for software developers.

This time, we’re especially interested in experience reports. But this
could also take other forms, e.g.:

- introductory talks on technical background
- overviews of a given field
- demos and how-tos

Requirements


We accept proposals for presentations of 45 minutes (40 minutes talk +
5 minutes questions), as well as 90 minute tutorials for
beginners. The language of presentation should be either English or
German.

Your proposal should include (in your presentation language of choice):

- an abstract of max. 1500 characters.
- a short bio/cv
- contact information (including at least email address)
- a list of 3-5 concrete ideas of how your work can be applied in a developer’s 
daily life
-additional material (websites, blogs, slides, videos of past presentations, …)

Submit here:

https://docs.google.com/forms/d/e/1FAIpQLSfFuyBhBTCOTS0zTXBzY1KVuKpumyIBTucLcJ1ArC1XpWsG-Q/viewform

Organisation

- direct questions to bobkonf at active minus group dot de
- proposal deadline: October 30, 2016
- notification: November 15, 2016
- program: December 1, 2016

NOTE: The conference fee will be waived for presenters, but travel
expenses will not be covered.

Speaker Grants
--

BOB has Speaker Grants available to support speakers from groups
under-represented in technology. We specifically seek women speakers
and speakers who are not be able to attend the conference for
financial reasons. Details are here:

http://bobkonf.de/2017/en/speaker-grants.html

Shepherding
---

The program committee offers shepherding to all speakers. Shepherding
provides speakers assistance with preparing their sessions, as well as
a review of the talk slides.

Program Committee
-

(more information here: http://bobkonf.de/2017/programmkomitee.html)

- Matthias Fischmann, zerobuzz UG
- Matthias Neubauer, SICK AG
- Nicole Rauch, Softwareentwicklung und Entwicklungscoaching
- Michael Sperber, Active Group
- Stefan Wehr, factis research

Scientific Advisory Board

- Annette Bieniusa, TU Kaiserslautern
- Torsten Grust, Uni Tübingen
- Peter Thiemann, Uni Freiburg


-- 
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: Java like static typing for Clojure?

[Timothy Baldridge]

I highly recommend this talk on Spec by Stu Halloway. Spec is a new feature
coming in Clojure 1.9, and this talk goes into the pros/cons of static
typing and tests and shows how there can be a better way.

https://www.youtube.com/watch?v=VNTQ-M_uSo8



On Sun, Oct 16, 2016 at 5:58 PM, Alan Thompson  wrote:

> Be sure to check out Plumatic Schema 
> (previously Prismatic Schema) if you haven't already.  There is also a good 
> Clojure
> Conj video  from 2013.
> Alan
>
> On Sat, Oct 15, 2016 at 3:14 PM, Didier  wrote:
>
>> I know a lot of people like to say how unhelpful Java like static typing
>> is, and only more powerful type systems of the ML family add value, but
>> I've been wondering recently if for Clojure it wouldn't make more sense to
>> simply extend the type hints to enable an optional Java like static typing
>> scheme.
>>
>> It is my understanding that ML style static typing is incredibly
>> difficult to add properly and without compromise to a dynamic language.
>> That doing so limits the scope of type inference, rendering the task of
>> adding type info more tedious then in ML languages themselves.
>>
>> ML style static typing provide enhanced safety grantees, but seem to add
>> too much complexity to Clojure to be practical. What about a Java like
>> static typing scheme though?
>>
>> I haven't found in practice that the safety of Clojure was an issue, as
>> the REPL workflow tend to promote quite a lot of testing. So I'm not too
>> worried about needing the state of the art of provable correctness for my
>> programs. What has been a biggest cause of issue to me was refactoring and
>> shared code base across a team. Those last two use cases are actually
>> pretty well handled by Java like static type checking. Is it a powerful
>> type checker, not really, but it enables most trivial type errors to be
>> caught early, and it allows easier integration points for other devs to
>> follow, as well as documentation for functions, better tools support and
>> easier refactoring, while also enabling performance optimizations.
>>
>> I have limited knowledge in typing systems, and have no idea how easy it
>> is to implement them, but as a user of Clojure, I feel like I would find an
>> optional Java like static typing a great addition, one that I am more
>> willing to use and benefit from then Typed Clojure's more complex ML style
>> type checking.
>>
>> What do other think?
>> Can anyone with better knowledge tell me if this would be feasible or if
>> adding such gradual typing system is effectively as hard as adding ML style
>> type checking?
>>
>> --
>> 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.
>



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

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

[dennis zhuang]

hi, all

I released carmine-sentinel 0.1.0-RC1, it supports reading data from  Redis
slave and supports other APIs(MQ, Pub/Sub,Lock etc) in carmine.

(def slave-conn {:pool {} :spec {}
 :sentinel-group :group1 :master-name "mymaster"
 :prefer-slave? true})

(defmacro wcars* [& body] `(cs/wcar slave-conn ~@body))

(wcars* (car/set "key" 1)) ;; ExceptionInfo READONLY You can't write
against a read only slave


More info please visit https://github.com/killme2008/carmine-sentinel



2016-10-13 19:43 GMT+08:00 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
>
>
>


-- 
庄晓丹
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.