How to try/catch Let bindings?

2017-09-30 Thread Marcus Magnusson 
I've used try-let (link below) for this, it's worked great!

https://github.com/rufoa/try-let

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

How to try/catch Let bindings?

2017-09-30 Thread Didier 
I'm curious how others handle this use case, which I feel should be pretty 
common.

Given you have a series of business process steps, where the flow is too 
complex for the arrow macros, and you also like to name the step results 
descriptively, so you use let:

(let [a (do-a ...)
  b (do-b . a . .)
  c (do-c . a . b)]
  (log/info "Success" {:a a
   :b b
   :c c})
  c)

Now, say each steps could possibly throw an exception. So you want to 
try/catch the let bindings:

(try
  (let [a (do-a ...)
b (do-b . a . .)
c (do-c . a . b)]
(log/info "Success" {:a a
 :b b
 :c c})
c)
  (catch Exception e
(log/error "Failed" {:a a
 :b b
 :c c})
(throw e)))

But, inside the catch, you need access to the let bindings a,b,c, in order 
to recover from the failure, or like in my example, just to log so that 
debugging of the issue is easier.

Now the catch will not be in scope of the bindings, and this won't even 
compile: "Can not find symbol a,b,c in context...".

What would be the idomatic thing to do here?

Is there another way to execute a set of complex steps which does not rely 
on let and can be try/catched in the manner I describe?

Or is there a way to re-write the let that satisfies my case, and remains 
idiomatic, and does not add accidental complexities?

Thank You.

-- 
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 a way to use spec/fdef function specs with clojure.test ?

2017-09-30 Thread Khalid Jebbari 
I could indeed, but if it fails, what does the report look like ? Does it
display the output of `st/test` (which contains all details, notably args,
return and smallest input ?

Khalid aka DjebbZ
@Dj3bbZ

On Fri, Sep 29, 2017 at 5:27 PM, Beau Fabry  wrote:

> Can't you just assert on the return value of spec.test.check in a
> clojure.test test? ie, this is a test in one of our repos:
> (deftest ^:spec generative
> (is (not-any? :failure (st/check [`export/invert-table->account-ids]
>
> On Friday, September 29, 2017 at 3:36:26 AM UTC-7, Khalid Jebbari wrote:
>>
>> I've managed to get something working. Very dirty and hardcoded most
>> things though, so not reusable at all. The key here is to parse the return
>> of spec/describe and retrieve the value for the :arg, convert it to real
>> spec with eval and retrieve its generator.
>>
>> (defspec a-test
>>  (let [args (nth (s/describe 'foo.core/bar) 2)
>>spec-code (map #(if (symbol? %) (symbol
>> "clojure.spec.alpha" (str %)) %) args)
>>spec (eval spec-code)
>>args-gen (s/gen spec)]
>>(prop/for-all [argz args-gen]
>>  (s/valid? ::ret-spec (apply foo.core/bar argz)
>>
>>
>> In the end one shoot write a proper spec/describe parser ?
>>
>> Or has someone a better idea ?
>>
>>
>> On Friday, September 29, 2017 at 12:08:57 PM UTC+2, Khalid Jebbari wrote:
>>>
>>> Hello,
>>>
>>> I'm struggling to find a way to to use the fdef specs I wrote in
>>> clojure.test tests. I can run them fine in the repl with spec/exercise-fn
>>> or spec.test/check, really nice when developping by the way. Now that I'm
>>> happy with the result I'd like to encode this knowledge in tests to prevent
>>> regressions. I don't need more tests that this, not specific property etc.
>>>
>>> I found no way to plug the spec.test/check in clojure.test or easily
>>> reuse fdef specs. test.check/defspec and quickcheck expect properties as
>>> their argument. spec/describe return a LazySeq that I found hard to exploit
>>> without a lot of manual wiring, parsing and trial-and-errors.
>>>
>>> If I had to write it by hand, it would look like :
>>>
>>> (defspec myspec 100 (prop/for-all [one (spec/gen ::first-arg)
>>>two (spec/gen
>>> ::second-arg)]
>>> (is (true? (spec/valid?
>>> ::ret-spec (myfunc one two
>>>
>>> The problem is that it's incomplete with regards to spec possibilities :
>>> spec/or, spec/nilable etc. and I use them. Also I the function changes (in
>>> any way) the test becomes irrelevant instantly.
>>>
>>> A colleague resorted to manually calling spec.test/check in clojure.test
>>> and manually verifying the output of the function (the :result boolean, the
>>> :num-tests etc.). Feels way too manual, and doesn't report the shrunk value
>>> as nicely as test.check does.
>>>
>>>
>>> Maybe I missed something completely. spec/describe seems the best bet to
>>> introspect the spec and use it in for-all calls. But still too manual.
>>>
>>> Any help much appreciated.
>>>
>> --
> 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/0UjSFT926vg/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: Help ship Clojure 1.9!

2017-09-30 Thread Borkdude 
Other than spotting an issue with yada which involved upgrading aleph 
(https://github.com/juxt/yada/issues/199) and an issue with ClojureScript 
with was fixed on master I haven't encountered any problems. All our 
integration tests pass. Good luck with bringing Clojure 1.9.0 out the door!

On Thursday, September 28, 2017 at 4:00:16 PM UTC+2, stuart@gmail.com 
wrote:
>
> Clojure 1.9 has been quite stable throughout the alpha period, and we now 
> hope to release after a very short beta. Please test your existing programs 
> on the latest beta (see below), and respond on this thread ASAP if you 
> discover anything you believe to be a regression.
>
> Thanks!
> Stu
>
> ;; Clojure deps.edn
> org.clojure/clojure {:mvn/version "1.9.0-beta1"}
>
> ;; lein & boot
> [org.clojure/clojure "1.9.0-beta1"]
>
>

-- 
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: Help ship Clojure 1.9!

2017-09-30 Thread David Bürgin 
On 28/09/17 16:00, Stuart Halloway wrote:
> Clojure 1.9 has been quite stable throughout the alpha period, and we
> now hope to release after a very short beta. Please test your existing
> programs on the latest beta (see below), and respond on this thread ASAP
> if you discover anything you believe to be a regression.

Will there be a non-alpha release of spec together with Clojure 1.9?

Some newer libraries have statements like ‘in alpha while Clojure 1.9 is
in alpha’, but what they actually seem to mean is that they’re in alpha
while spec is in alpha. I think a proper release of spec (namespaces
without the word ‘alpha’) sometime soon would be very welcome.

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