Re: Spec of conform of spec

[l0st3d]

I was asking how you would conform a value to a falsey value. If the 
interface for the function is that returning nil or false means that the 
input is not valid (which is what I understood from the discussion) then 
how can you conform to nil or false? However, on reading the docs for 
conformer that you posted here, it suggests that returning falsey values 
does not mean that they are invalid, only :clojure.spec/invalid means that. 
So apologies for the misunderstanding. I was away from a computer that I 
could reasonably run a REPL on, so I just asked rather than tested ;)

Many thanks,

Ed

On Thursday, 1 September 2016 00:31:43 UTC+1, Alex Miller wrote:
>
> user=> (doc s/conformer)
> -
> clojure.spec/conformer
> ([f] [f unf])
> Macro
>   takes a predicate function with the semantics of conform i.e. it should 
> return either a
>   (possibly converted) value or :clojure.spec/invalid, and returns a
>   spec that uses it as a predicate/conformer. Optionally takes a
>   second fn that does unform of result of first
>
> Conformers are expected return either a value or ::s/invalid if invalid.
>
>
> On Wednesday, August 31, 2016 at 6:29:23 PM UTC-5, Alex Miller wrote:
>>
>> I don't understand the question. What are you trying to do?
>>
>> On Wednesday, August 31, 2016 at 4:08:00 PM UTC-5, l0st3d wrote:
>>>
>>> So how would you conform something to nil or false? For example:
>>>
>>> (s/conform (s/conformer read-string) "nil")
>>>
>>> ?
>>>
>>>

-- 
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: Spec of conform of spec

[Alex Miller]

I think you may be confusing the return value of a predicate value (acting as a 
spec) with the return value of the function passed to conformer.

In the former case a predicate function's return value is a logically truthy 
value and a return of nil or false indicates the value is invalid.

The function passed to a conformer is expected to return either a conformed 
value or ::s/invalid.

-- 
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] Manifail 0.4.0

[platonovadim]

Hello,

I'm pleased to announce a release of Manifail 
 - a failure/retry handling library 
built on top of Manifold . 
I know we have Diehard  already, 
conveniently wrapping the Failsafe  
Java library. However, I wanted to see if a more Clojurey approach was 
possible. In this case, an approach which would let you express retry 
handling logic directly instead of smearing it across callbacks.

Please feel free to check out the readme 
 and an example 
 project!

Github: https://github.com/tulos/manifail

-- 
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] Manifail 0.4.0

[lvh]

Hi!

> On Sep 1, 2016, at 12:03 PM, platonova...@gmail.com wrote:
> 
> Hello,
> 
> I'm pleased to announce a release of Manifail 
>  - a failure/retry handling library built 
> on top of Manifold . 
> I know we have Diehard  already, 
> conveniently wrapping the Failsafe  
> Java library. However, I wanted to see if a more Clojurey approach was 
> possible. In this case, an approach which would let you express retry 
> handling logic directly instead of smearing it across callbacks.


Cool! I was wondering if you had seen https://github.com/RackSec/banach 
 (something we develop at Rackspace Managed 
Security), which includes a failure/retry library. It seems to have a similar 
approach in being more clojure-y, but uses combinators to produce behavior.

Here’s the retry logic: 
https://github.com/RackSec/banach/blob/master/src/banach/retry.clj

lvh


> Please feel free to check out the readme 
>  and an example 
>  project!
> 
> Github: https://github.com/tulos/manifail 
> 
> -- 
> 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 1.9.0-alpha11

[Ambrose Bonnaire-Sergeant]

Hi,

There seems to be some issues instrumenting functions that
compile to .invokePrim calls.

user=> (s/fdef blah :args (s/cat :foo int?) :ret any?)
user/blah
user=> (defn blah [^long a])
#'user/blah
user=> (st/instrument)
[clojure.core/symbol user/blah]
user=> (blah 1)

ClassCastException clojure.spec.test$spec_checking_fn$fn__13057 cannot be 
cast to clojure.lang.IFn$LO  user/eval70134 
(form-init2184258571072833082.clj:1)
user=> 

I'm about to tackle this problem in core.typed, so I should have some useful
utilities to fix this soon (if interested).

Thanks,
Ambrose

On Friday, August 19, 2016 at 2:15:06 PM UTC-4, Alex Miller wrote:
>
> Clojure 1.9.0-alpha11 is now available.
>
> Try it via
>
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha11
> - Leiningen: [org.clojure/clojure "1.9.0-alpha11"]
>
> 1.9.0-alpha11 includes the following changes since 1.9.0-alpha10:
>
> Clojure now has specs for the following clojure.core macros: let, if-let, 
> when-let, defn, defn-, fn, and ns. Because macro specs are checked during 
> macroexpansion invalid syntax in these macros will now fail at compile time 
> whereas some errors were caught at runtime and some were not caught at all.
>
> - CLJ-1914 - Fixed race condition in concurrent range realization
> - CLJ-1870 - Fixed reloading a defmulti removes metadata on the var
> - CLJ-1744 - Clear unused locals, which can prevent memory leaks in some 
> cases
> - CLJ-1423 - Allow vars to be invoked with infinite arglists (also, faster)
> - CLJ-1993 - Added *print-namespace-maps* dynamic var that controls 
> whether to use namespace map syntax for maps with keys from the same 
> namespace. The default is false, but standard REPL bindings set this to 
> true.
> - CLJ-1985 - Fixed with-gen of conformer losing unform fn
> - Fixed clojure.spec.test/check to skip spec'ed macros
> - Fixed regression from 1.9.0-alpha8 where type hints within destructuring 
> were lost
> - Fixed clojure.spec/merge docstring to note merge doesn't flow conformed 
> values
> - Fixed regex ops to use gen overrides if they are used
>

-- 
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] Manifail 0.4.0

[platonovadim]

I did! After I wrote first few versions of Manifail though. One of the 
issues in Banach repo inspired me to add a `reset!` marker in addition to 
`abort!` - https://github.com/RackSec/banach/issues/12. 

I've tried expressing retry logic through streams at first too, but settled 
on a different approach in the end.

On Thursday, September 1, 2016 at 7:19:28 PM UTC+2, lvh ‌ wrote:
>
> Hi!
>
> On Sep 1, 2016, at 12:03 PM, platon...@gmail.com  wrote:
>
> Hello,
>
> I'm pleased to announce a release of Manifail 
>  - a failure/retry handling library 
> built on top of Manifold . 
> I know we have Diehard  already, 
> conveniently wrapping the Failsafe 
>  Java library. However, I wanted 
> to see if a more Clojurey approach was possible. In this case, an approach 
> which would let you express retry handling logic directly instead of 
> smearing it across callbacks.
>
>
>
> Cool! I was wondering if you had seen https://github.com/RackSec/banach 
> (something 
> we develop at Rackspace Managed Security), which includes a failure/retry 
> library. It seems to have a similar approach in being more clojure-y, but 
> uses combinators to produce behavior.
>
> Here’s the retry logic: 
> https://github.com/RackSec/banach/blob/master/src/banach/retry.clj
>
> lvh
>
>
> Please feel free to check out the readme 
>  and an example 
>  project!
>
> Github: https://github.com/tulos/manifail
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: [ANN] Clojure 1.9.0-alpha11

[Kevin Downey]

instrument is going to have issues with any calling convention outisde
of the normal deref var + invoking path.
http://dev.clojure.org/jira/browse/CLJ-1941 is a similar case with some
discussion in the comments.

On 09/01/2016 11:33 AM, Ambrose Bonnaire-Sergeant wrote:
> Hi,
> 
> There seems to be some issues instrumenting functions that
> compile to .invokePrim calls.
> 
> user=> (s/fdef blah :args (s/cat :foo int?) :ret any?)
> user/blah
> user=> (defn blah [^long a])
> #'user/blah
> user=> (st/instrument)
> [clojure.core/symbol user/blah]
> user=> (blah 1)
> 
> ClassCastException clojure.spec.test$spec_checking_fn$fn__13057 cannot
> be cast to clojure.lang.IFn$LO  user/eval70134
> (form-init2184258571072833082.clj:1)
> user=> 
> 
> I'm about to tackle this problem in core.typed, so I should have some useful
> utilities to fix this soon (if interested).
> 
> Thanks,
> Ambrose
> 
> On Friday, August 19, 2016 at 2:15:06 PM UTC-4, Alex Miller wrote:
> 
> Clojure 1.9.0-alpha11 is now available.
> 
> Try it via
> 
> - Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha11
> 
> - Leiningen: [org.clojure/clojure "1.9.0-alpha11"]
> 
> 1.9.0-alpha11 includes the following changes since 1.9.0-alpha10:
> 
> Clojure now has specs for the following clojure.core macros: let,
> if-let, when-let, defn, defn-, fn, and ns. Because macro specs are
> checked during macroexpansion invalid syntax in these macros will
> now fail at compile time whereas some errors were caught at runtime
> and some were not caught at all.
> 
> - CLJ-1914 - Fixed race condition in concurrent range realization
> - CLJ-1870 - Fixed reloading a defmulti removes metadata on the var
> - CLJ-1744 - Clear unused locals, which can prevent memory leaks in
> some cases
> - CLJ-1423 - Allow vars to be invoked with infinite arglists (also,
> faster)
> - CLJ-1993 - Added *print-namespace-maps* dynamic var that controls
> whether to use namespace map syntax for maps with keys from the same
> namespace. The default is false, but standard REPL bindings set this
> to true.
> - CLJ-1985 - Fixed with-gen of conformer losing unform fn
> - Fixed clojure.spec.test/check to skip spec'ed macros
> - Fixed regression from 1.9.0-alpha8 where type hints within
> destructuring were lost
> - Fixed clojure.spec/merge docstring to note merge doesn't flow
> conformed values
> - Fixed regex ops to use gen overrides if they are used
> 
> -- 
> 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.


-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

[Ambrose Bonnaire-Sergeant]

invokePrim seems to be the most common alternative calling convention.

I've worked around this myself for core.typed, basically generating a
deftype with the correct primitive invoke interfaces based on the :arglists
of the current var we're instrumenting.

I can prepare a patch if this approach isn't too hacky for core.

https://gist.github.com/frenchy64/7eb65d244a4edbb3a10dd4d9f889a3bd

Thanks,
Ambrose

On Thursday, September 1, 2016 at 3:54:39 PM UTC-4, red...@gmail.com wrote:
>
> instrument is going to have issues with any calling convention outisde 
> of the normal deref var + invoking path. 
> http://dev.clojure.org/jira/browse/CLJ-1941 is a similar case with some 
> discussion in the comments. 
>
> On 09/01/2016 11:33 AM, Ambrose Bonnaire-Sergeant wrote: 
> > Hi, 
> > 
> > There seems to be some issues instrumenting functions that 
> > compile to .invokePrim calls. 
> > 
> > user=> (s/fdef blah :args (s/cat :foo int?) :ret any?) 
> > user/blah 
> > user=> (defn blah [^long a]) 
> > #'user/blah 
> > user=> (st/instrument) 
> > [clojure.core/symbol user/blah] 
> > user=> (blah 1) 
> > 
> > ClassCastException clojure.spec.test$spec_checking_fn$fn__13057 cannot 
> > be cast to clojure.lang.IFn$LO  user/eval70134 
> > (form-init2184258571072833082.clj:1) 
> > user=> 
> > 
> > I'm about to tackle this problem in core.typed, so I should have some 
> useful 
> > utilities to fix this soon (if interested). 
> > 
> > Thanks, 
> > Ambrose 
> > 
> > On Friday, August 19, 2016 at 2:15:06 PM UTC-4, Alex Miller wrote: 
> > 
> > Clojure 1.9.0-alpha11 is now available. 
> > 
> > Try it via 
> > 
> > - Download: 
> > https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha11 
> >  
> > - Leiningen: [org.clojure/clojure "1.9.0-alpha11"] 
> > 
> > 1.9.0-alpha11 includes the following changes since 1.9.0-alpha10: 
> > 
> > Clojure now has specs for the following clojure.core macros: let, 
> > if-let, when-let, defn, defn-, fn, and ns. Because macro specs are 
> > checked during macroexpansion invalid syntax in these macros will 
> > now fail at compile time whereas some errors were caught at runtime 
> > and some were not caught at all. 
> > 
> > - CLJ-1914 - Fixed race condition in concurrent range realization 
> > - CLJ-1870 - Fixed reloading a defmulti removes metadata on the var 
> > - CLJ-1744 - Clear unused locals, which can prevent memory leaks in 
> > some cases 
> > - CLJ-1423 - Allow vars to be invoked with infinite arglists (also, 
> > faster) 
> > - CLJ-1993 - Added *print-namespace-maps* dynamic var that controls 
> > whether to use namespace map syntax for maps with keys from the same 
> > namespace. The default is false, but standard REPL bindings set this 
> > to true. 
> > - CLJ-1985 - Fixed with-gen of conformer losing unform fn 
> > - Fixed clojure.spec.test/check to skip spec'ed macros 
> > - Fixed regression from 1.9.0-alpha8 where type hints within 
> > destructuring were lost 
> > - Fixed clojure.spec/merge docstring to note merge doesn't flow 
> > conformed values 
> > - Fixed regex ops to use gen overrides if they are used 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> > your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to clojure+u...@googlegroups.com  
> > . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> And what is good, Phaedrus, 
> And what is not good— 
> Need we ask anyone to tell us these things? 
>

-- 
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.java.jdbc - upcoming (small) breaking change

[Sean Corfield]

Just a quick heads up that the next version of clojure.java.jdbc will be 0.7.0 
(Alpha 1, probably) and will have a small breaking change – hence the jump from 
the planned 0.6.2 version.

https://github.com/clojure/java.jdbc/blob/master/CHANGES.md

The signatures of as-sql-name and quoted have changed slightly: the former no 
longer has the curried (single argument) version, and the latter no longer has 
the two argument version. This change came out of a discussion on Slack which 
indicated curried functions are non-idiomatic. If you relied on the curried 
version of as-sql-name, you will not need to use partial. If you relied on the 
two argument version of quoted, you will need to add an extra ( ) for the one 
argument call. I'd be fairly surprised if anyone is using as-sql-name at all 
since it is really an implementation detail. I'd also be surprised if anyone 
was using the two argument version of quoted since the natural usage is 
:entities (quoted [\[ \]]) to create a naming strategy (that provides SQL 
entity quoting).

If my assumptions about the usage of as-sql-name and/or quoted are incorrect, 
please let me know.

Also a reminder (to the Clojure Mailing List) that there is a dedicated 
clojure-java-jdbc Google Group if you want to discuss JDBC-specific stuff.

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

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)




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