Re: clojure.spec - Using :pre conditions (or not)?

[Mamun]

When function is throwing exception because of argument. I would prefer to 
throw IllegalArgumentException not AssertionError. 


(defn check [type data]
  (if (sp/valid? type data)
true
(throw (IllegalArgumentException. (sp/explain type data)


Br,
Mamun


On Friday, September 16, 2016 at 7:20:53 AM UTC+2, joakim.t...@nova.com 
wrote:
>
> I came up with this solution:
>
> (ns spec-test.core
>   (:require [clojure.spec :as s]))
>
> (s/def :user/name string?)
> (s/def :common/user (s/keys :req [:user/name]))
>
> ;; with this little helper function...
> (defn check [type data]
>   (if (s/valid? type data)
> true
> (throw (AssertionError. (s/explain type data)
>
> ;; I can use it in my :pre condition
> (defn aname [user]
>   {:pre [(check :common/user user)]}
>   (-> user :user/name))
>
> ;; when I call name with an illegal arguement...
> (aname {:x "Elon"})
>
> ;; ...it not fails and returns a better error message:
> CompilerException java.lang.AssertionError: null, 
> compiling:(/Users/joakimtengstrand/IdeaProjects/spec-test/src/spec_test/core.clj:19:1)
> val: {:x "Elon"} fails spec: :common/user predicate: (contains? % :user/name)
>
>
> With this solution I don't need to enable assertions, and the code is neat 
> and less verbose!
>
> /Joakim
>
> On Thursday, September 15, 2016 at 3:11:32 PM UTC+2, Shantanu Kumar wrote:
>>
>> Hi Joakim,
>>
>> You might be interested in Paul Stadig's library 
>> https://github.com/pjstadig/assertions that leverages Java's `-ea` 
>> (enable-assertions, which you may want to keep enabled in dev) command-line 
>> flag. If you have a bunch of things together to assert, you may want to use 
>> the `when-assert` macro for wholesale optimization: 
>> https://github.com/pjstadig/assertions/blob/0.2.0/src/pjstadig/assertions.clj#L13
>>
>>
>> Shantanu
>>
>> On Thursday, 15 September 2016 16:50:17 UTC+5:30, joakim.t...@nova.com 
>> wrote:
>>>
>>> Ok, thanks!
>>>
>>> In the Java world, the assertions is also something that need to be turn 
>>> on explicitly.
>>> In that sence, they are kind of not mandatory to be executed (or at 
>>> least signals that to the reader of the code).
>>>
>>> I would be happier if you guys could add another method, that I can use 
>>> in my :pre conditions, that leverage
>>> the same amount of details in the error messages, but that is always 
>>> "turned on".
>>>
>>> In the meanwhile, I will use s/assert ;-)
>>>
>>> BR,
>>> Joakim Tengstrand
>>>
>>>
>>> On Wednesday, 14 September 2016 15:59:09 UTC+2, Alex Miller wrote:

 Another option that has been added since the guide was written is 
 s/assert which seems closer to what you're suggesting.

 (defn name [user]
   {:pre [(s/assert :common/user user)]}
   (-> user :user/name))

 ;; need to enable assertion checking - this can also be enabled 
 globally with system property clojure.spec.check-asserts
 (s/check-asserts true)

 (name {:user/name "Elon"})
 "Elon"

 (name {:x "Elon"})
 ExceptionInfo Spec assertion failed
 val: {:x "Elon"} fails predicate: (contains? % :user/name)
 :clojure.spec/failure  :assertion-failed
   clojure.core/ex-info (core.clj:4725)

 Rather than use it in a precondition, you can also use s/assert 
 directly in the code.

 On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, 
 joakim.t...@nova.com wrote:
>
> (ns spec-test.core
>   (:require [clojure.spec :as s]))
>
> (s/def :user/name string?)
> (s/def :common/user (s/keys :req [:user/name]))
>
> ; first version of name (using :pre)
> (defn name [user]
>   {:pre [(s/valid? :common/user user)]}
>   (-> user :user/name))
>
> ; This statement works ok and returns "Elon":
> (name {:user/name "Elon"})
>
> ; but this statement...
> (name {:x "Elon"})
>
> ;...will throw:
> CompilerException java.lang.AssertionError:
> Assert failed: (s/valid? :common/user user)
>
> ; ...but then I don't get as much information
> ; about the error as if I would have called:
> (s/explain :common/user {:x "Elon"})
>
> ;...which also contains the predicate:
> val: {:x "Elon"} fails spec: :common/user
> predicate: (contains? % :user/name)
>
> ; (second version of name - more verbose)
> ; or do I need to wite it like this:
> (defn name [user]
>   (let [parsed (s/conform :common/user user)]
> (if (= parsed ::s/invalid)
>   (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
>   (-> user :user/name
>
> ; so that:
> (name {:x "Elon"})
>
> ; ...will return:
> CompilerException clojure.lang.ExceptionInfo:
>   Invalid input #:clojure.spec{:problems}
> ({:path [], :pred (contains? % :user/name),
>   :val {:x "Elon"}, :via [:common/user], :in []})
>
> ; It should be nice if I could be able to write it like this

Re: clojure.spec - Using :pre conditions (or not)?

[joakim . tengstrand]

I came up with this solution:

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

(s/def :user/name string?)
(s/def :common/user (s/keys :req [:user/name]))

;; with this little helper function...
(defn check [type data]
  (if (s/valid? type data)
true
(throw (AssertionError. (s/explain type data)

;; I can use it in my :pre condition
(defn aname [user]
  {:pre [(check :common/user user)]}
  (-> user :user/name))

;; when I call name with an illegal arguement...
(aname {:x "Elon"})

;; ...it not fails and returns a better error message:
CompilerException java.lang.AssertionError: null, 
compiling:(/Users/joakimtengstrand/IdeaProjects/spec-test/src/spec_test/core.clj:19:1)
val: {:x "Elon"} fails spec: :common/user predicate: (contains? % :user/name)


With this solution I don't need to enable assertions, and the code is neat 
and less verbose!

/Joakim

On Thursday, September 15, 2016 at 3:11:32 PM UTC+2, Shantanu Kumar wrote:
>
> Hi Joakim,
>
> You might be interested in Paul Stadig's library 
> https://github.com/pjstadig/assertions that leverages Java's `-ea` 
> (enable-assertions, which you may want to keep enabled in dev) command-line 
> flag. If you have a bunch of things together to assert, you may want to use 
> the `when-assert` macro for wholesale optimization: 
> https://github.com/pjstadig/assertions/blob/0.2.0/src/pjstadig/assertions.clj#L13
>
>
> Shantanu
>
> On Thursday, 15 September 2016 16:50:17 UTC+5:30, joakim.t...@nova.com 
> wrote:
>>
>> Ok, thanks!
>>
>> In the Java world, the assertions is also something that need to be turn 
>> on explicitly.
>> In that sence, they are kind of not mandatory to be executed (or at least 
>> signals that to the reader of the code).
>>
>> I would be happier if you guys could add another method, that I can use 
>> in my :pre conditions, that leverage
>> the same amount of details in the error messages, but that is always 
>> "turned on".
>>
>> In the meanwhile, I will use s/assert ;-)
>>
>> BR,
>> Joakim Tengstrand
>>
>>
>> On Wednesday, 14 September 2016 15:59:09 UTC+2, Alex Miller wrote:
>>>
>>> Another option that has been added since the guide was written is 
>>> s/assert which seems closer to what you're suggesting.
>>>
>>> (defn name [user]
>>>   {:pre [(s/assert :common/user user)]}
>>>   (-> user :user/name))
>>>
>>> ;; need to enable assertion checking - this can also be enabled globally 
>>> with system property clojure.spec.check-asserts
>>> (s/check-asserts true)
>>>
>>> (name {:user/name "Elon"})
>>> "Elon"
>>>
>>> (name {:x "Elon"})
>>> ExceptionInfo Spec assertion failed
>>> val: {:x "Elon"} fails predicate: (contains? % :user/name)
>>> :clojure.spec/failure  :assertion-failed
>>>   clojure.core/ex-info (core.clj:4725)
>>>
>>> Rather than use it in a precondition, you can also use s/assert directly 
>>> in the code.
>>>
>>> On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, 
>>> joakim.t...@nova.com wrote:

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

 (s/def :user/name string?)
 (s/def :common/user (s/keys :req [:user/name]))

 ; first version of name (using :pre)
 (defn name [user]
   {:pre [(s/valid? :common/user user)]}
   (-> user :user/name))

 ; This statement works ok and returns "Elon":
 (name {:user/name "Elon"})

 ; but this statement...
 (name {:x "Elon"})

 ;...will throw:
 CompilerException java.lang.AssertionError:
 Assert failed: (s/valid? :common/user user)

 ; ...but then I don't get as much information
 ; about the error as if I would have called:
 (s/explain :common/user {:x "Elon"})

 ;...which also contains the predicate:
 val: {:x "Elon"} fails spec: :common/user
 predicate: (contains? % :user/name)

 ; (second version of name - more verbose)
 ; or do I need to wite it like this:
 (defn name [user]
   (let [parsed (s/conform :common/user user)]
 (if (= parsed ::s/invalid)
   (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
   (-> user :user/name

 ; so that:
 (name {:x "Elon"})

 ; ...will return:
 CompilerException clojure.lang.ExceptionInfo:
   Invalid input #:clojure.spec{:problems}
 ({:path [], :pred (contains? % :user/name),
   :val {:x "Elon"}, :via [:common/user], :in []})

 ; It should be nice if I could be able to write it like this
 ; (or similar, to get a better error message):
 (defn name [user]
   {:pre [(s/explain :common/user user)]}
   (-> user :user/name))



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

Re: [CfP] :clojureD 2017

[Mars0i]

Glad that this is happening.
You might want to add the date to the CFP and Schedule pages.  I only found 
it on the Press page.

On Wednesday, September 14, 2016 at 9:38:09 AM UTC-5, Stefan Kamphausen 
wrote:
>
> Dear Clojure-community,
>
>
> Please let me bring the current call for proposals for the next iteration 
> of the German clojure conference in Berlin, the :clojureD, to your 
> attention: 
>
>
> http://www.clojured.de/call-for-proposals/
>
> We call to send us talks for the upcoming :clojureD conference 2017.
>
> The conference is open for all topics. Our main purpose is to learn more 
> about Clojure with basic and advanced topics. All talks will be held in 
> English.
>
> We will have two types of talks:
>
>- Standard Talks (ca. 30 min)
>- Lightning Talks (ca. 6 min)
>
> It would be great if you can activate speakers with many topics! Good 
> lightning talks are not much of an effort. Do you know a keynote speaker?
>
> *The CfP ends 31.10.2016!*
>
>
>
> The team behind the conference is looking forward to receiving your 
> proposals.
>
>
> Regards,
> Stefan
>

-- 
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 support for Visual Studio Code

[Rick Beerendonk]

Great, I like VSCode, so certainly very helpful, 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: Clojure support for Visual Studio Code

[Ikuru Kanuma]

Hi Andrey, thanks for sharing this great work!

- I did want to try it out on an Ubuntu machine, but simply dragging and 
dropping seemed to not work.
Could you perhaps point to an alternative way to install extensions (First 
time ever touching vs code, so it is hard for me to even google how to do 
it)?

- Cider injects its own nrepl middleware. Would that be hard to achieve?
It would greatly make things easy for newbies.

Ikuru

On Thursday, September 15, 2016 at 8:17:38 PM UTC+9, Andrey Lisin wrote:
>
> Hey guys,
>
> I've been working on Clojure support for Visual Studio Code text editor 
> for a while. The first version is very close to the point when it can be 
> published to Visual Studio Code marketplace, but I would like to test it a 
> bit more before. Maybe there are Visual Studio Code uses here who can try 
> the extension and give feedback.
>
> Features extension supports:
>
> - code completion
> - interaction with REPL
> - go to definition
> - documentation hints
>
> The extension can be obtained from its GitHub page (
> https://github.com/avli/clojureVSCode/releases). Download the vsix file 
> and drag-and-drop it to the Visual Studio Code. The extension relies on 
> cider-nrepl, so don't forget to add it to the dependencies list. To connect 
> to nREPL use "Connect to nREPL" command from the command palette. More 
> information is available on the extension's GitHub page.
>
> Hope it be useful for someone.
>
>

-- 
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: Encapsulating Sub-Systems with Protocols

[Sean Corfield]

Take a look at Stuart Sierra’s talk “Clojure in the Large” from Clojure/West:

 

https://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques

 

He talks about several techniques for managing boundaries, including protocols.

 

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 9/15/16, 12:50 PM, "Cameron Barre"  wrote:

 

Has anyone used protocols to create explicit boundaries between the bigger 
pieces of their systems? We want to track/control the interactions between 
these sub-systems and are considering using protocols to define public APIs. Is 
this good practice? Would it be better to simply create our API like a normal 
library and be explicit about which functions are part of the public API? 

 

-- 
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: Encapsulating Sub-Systems with Protocols

[Christopher Small]

I've used protocols this way. In fact, this pattern meshes quite well with 
Stuart Sierra's Component lib/pattern. By building system components around 
protocols, subsystems/components can be made swappable. This is rather 
integral to the current design of Datsys actually.

Of course, as other's have pointed out, whether this is worth while is 
totally dependent on whether or not you actually need that kind of 
polymorphism. But if you do, it's a great way to go.

Chris


On Thursday, September 15, 2016 at 1:21:43 PM UTC-7, Cameron Barre wrote:
>
> Has anyone used protocols to create explicit boundaries between the bigger 
> pieces of their systems? We want to track/control the interactions between 
> these sub-systems and are considering using protocols to define public 
> APIs. Is this good practice? Would it be better to simply create our API 
> like a normal library and be explicit about which functions are part of the 
> public API? 
>

-- 
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: Encapsulating Sub-Systems with Protocols

[James Reeves]

On 15 September 2016 at 20:50, Cameron Barre  wrote:

> Has anyone used protocols to create explicit boundaries between the bigger
> pieces of their systems? We want to track/control the interactions between
> these sub-systems and are considering using protocols to define public
> APIs. Is this good practice? Would it be better to simply create our API
> like a normal library and be explicit about which functions are part of the
> public API?
>

Protocols are a mechanism for polymorphism. If you need polymorphism, use a
protocol, if not, then don't.

Protocols can be useful for defining an external boundary, such as an
interface to a service. In this case it's useful to have polymorphism so we
can substitute different services, or use mock services for testing.

- James

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

Re: Encapsulating Sub-Systems with Protocols

[Gregg Reynolds]

On Sep 15, 2016 3:20 PM, "Cameron Barre"  wrote:
>
> Has anyone used protocols to create explicit boundaries between the
bigger pieces of their systems?

Absolutely.  Depending on what you mean by "boundaries between bigger
pieces".  Clojure itself, for one. Also core.matrix, if I'm not mistaken.

We want to track/control the interactions between these sub-systems and are
considering using protocols to define public APIs. Is this good practice?

IMHO, yes, usually.

Would it be better to simply create our API like a normal library and be
explicit about which functions are part of the public API?

By "normal library" do you mean a collection of functions?

You can think of protocols as OO, only better.  Well, I can, ymmv.

hth,

gregg

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

Encapsulating Sub-Systems with Protocols

[Cameron Barre]

Has anyone used protocols to create explicit boundaries between the bigger 
pieces of their systems? We want to track/control the interactions between 
these sub-systems and are considering using protocols to define public 
APIs. Is this good practice? Would it be better to simply create our API 
like a normal library and be explicit about which functions are part of the 
public API? 

-- 
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: Deref Nil

[Tim Gilbert]

In this specific case, I might personally use something like:

(render-image (some-> product-image-list first deref))

...or maybe write a little function that does the above. Alternately, in 
(render-image) you might start out with (if (nil? cursor) (default-image) 
(code-to-render @cursor)). You'd need to check for nil to render the 
default image even if deref was nil-punnable, right?

Tim

On Monday, September 12, 2016 at 4:30:00 AM UTC-4, Deon Moolman wrote:
>
> Hi Tim,
>
> Thanks for your feedback, I appreciate it! :)
>
> Ye, I've been tempted and bitten by atoms-in-atoms before, and that's no 
> fun - My case here is slightly different though, I have a single atom and 
> construct cursors to paths within, which are swappable and deref'able like 
> normal atoms, but they modify the value of the original atom (just their 
> allocated slice inside though).
>
> I'll give a bit of detail on one very specific usecase I have, my 
> structure looks like so:
>
> My atom (and its value) looks like so:
>
> (atom
>   {:product
>[{:product/id 1 :product/name "Cooker"}
> {:product/id 2 :product/name "Pan"}]
>:image
>[{:image/id 1 :image/url "..." :image/product 1}]})
>
> And I have a function (reverse-lookup) that will take a product id and 
> return a list of cursors that point to the individual images for a product, 
> so:
>
> (reverse-lookup :image/product 1) => [(cursor {:image/id :image/url "..." 
> :image/product 1})]
> (reverse-lookup :image/product 2) => []
>
> If I'm only interested in, say, rendering the first image, I can call 
> (render-image 
> @(first product-image-list)) - without nil-punning, I have to do add an 
> if to every usage, where I'd rather just handle nil to a default image 
> placeholder inside render-image.
>
> I also have a function will literally return the first (and likely only) 
> element in the lookup, which will also return a cursor or nil if not found. 
> One could argue that the data needs integrity checking in that case before 
> getting into the atom, but in my case I'd rather just nil-pun all the 
> things since it's not exactly a big deal.
>
> Anyhow - back to the original question - I'm wondering if there's anything 
> I'm missing about the decision to not nil-pun deref - If it's simply a 
> matter of 'didn't really think of it', that's fine, I'm quite content to 
> work around it, but if there's a deeper philosophical reason, then I'm keen 
> to add it to my understanding of the underlying foundation of clojure.
>
> Thanks again for all the feedback, I really do appreciate your time!
>
> Cheers,
>  - Deon
>
> On Sat, Sep 10, 2016 at 9:08 PM, Timothy Baldridge  > wrote:
>
>> I've worked with a model much like this, and as an experience report: it 
>> resulted in a lot of pain. Atoms inside atoms, or really more than one atom 
>> for the entire state of your app results in to many sources of mutability. 
>> On top of that, you have the problem of async updates: some part of your 
>> state may or may not exist depending if some async call to the server has 
>> completed yet. I can't say much more without seeing your code, but I would 
>> use this as an opprotunity to re-think the design of the app a bit. 
>>
>> If you are getting nils in unexpected places you can either nil-prune 
>> (what you're asking for here), or you can ask "why am I getting a nil here 
>> when I didn't expect it...how can I keep from doing this in the future?". 
>> Perhaps the answer is as simple as never calling the render function of a 
>> component until all its state exists (Om.Next takes an approach somewhat 
>> like this). 
>>
>> On Sat, Sep 10, 2016 at 11:12 AM, Deon Moolman > > wrote:
>>
>>> Hi Sean,
>>>
>>> Good point - as you have noticed, my use case is in ClojureScript - I'm 
>>> using reagent cursors (hence the deref) fairly heavily to chop my main atom 
>>> up and send only the relevant bits to components, but still allow them to 
>>> locally modify their state. 
>>>
>>> In my specific case, I do lookups for parts of the tree that may not 
>>> exist, and in that case 'nil' is the obvious return value.
>>>
>>> Cheers,
>>>  - Deon
>>>
>>> On Fri, Sep 9, 2016 at 6:55 PM, Sean Corfield >> > wrote:
>>>
 Like Stuart, I don’t encounter atom-or-nil as a common pattern – could 
 you explain why you have functions that might return an atom or might 
 return nil?

  

 FYI, We have about 40,000 lines of Clojure at World Singles and just a 
 handful of atoms (and most of those are going away as we refactor the code 
 to use Component more extensively).

  

 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 9/9/16, 1:10 AM, "Deon Moolman"  

Re: Clojure support for Visual Studio Code

[Michael Ball]

This looks great, will definitely try it out this weekend!


On Thursday, September 15, 2016 at 4:17:38 AM UTC-7, Andrey Lisin wrote:
>
> Hey guys,
>
> I've been working on Clojure support for Visual Studio Code text editor 
> for a while. The first version is very close to the point when it can be 
> published to Visual Studio Code marketplace, but I would like to test it a 
> bit more before. Maybe there are Visual Studio Code uses here who can try 
> the extension and give feedback.
>
> Features extension supports:
>
> - code completion
> - interaction with REPL
> - go to definition
> - documentation hints
>
> The extension can be obtained from its GitHub page (
> https://github.com/avli/clojureVSCode/releases). Download the vsix file 
> and drag-and-drop it to the Visual Studio Code. The extension relies on 
> cider-nrepl, so don't forget to add it to the dependencies list. To connect 
> to nREPL use "Connect to nREPL" command from the command palette. More 
> information is available on the extension's GitHub page.
>
> Hope it be useful for someone.
>
>

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

Re: clojure.spec - Using :pre conditions (or not)?

[joakim . tengstrand]

Thanks for the tip!

On Thursday, September 15, 2016 at 3:11:32 PM UTC+2, Shantanu Kumar wrote:
>
> Hi Joakim,
>
> You might be interested in Paul Stadig's library 
> https://github.com/pjstadig/assertions that leverages Java's `-ea` 
> (enable-assertions, which you may want to keep enabled in dev) command-line 
> flag. If you have a bunch of things together to assert, you may want to use 
> the `when-assert` macro for wholesale optimization: 
> https://github.com/pjstadig/assertions/blob/0.2.0/src/pjstadig/assertions.clj#L13
>
>
> Shantanu
>
> On Thursday, 15 September 2016 16:50:17 UTC+5:30, joakim.t...@nova.com 
> wrote:
>>
>> Ok, thanks!
>>
>> In the Java world, the assertions is also something that need to be turn 
>> on explicitly.
>> In that sence, they are kind of not mandatory to be executed (or at least 
>> signals that to the reader of the code).
>>
>> I would be happier if you guys could add another method, that I can use 
>> in my :pre conditions, that leverage
>> the same amount of details in the error messages, but that is always 
>> "turned on".
>>
>> In the meanwhile, I will use s/assert ;-)
>>
>> BR,
>> Joakim Tengstrand
>>
>>
>> On Wednesday, 14 September 2016 15:59:09 UTC+2, Alex Miller wrote:
>>>
>>> Another option that has been added since the guide was written is 
>>> s/assert which seems closer to what you're suggesting.
>>>
>>> (defn name [user]
>>>   {:pre [(s/assert :common/user user)]}
>>>   (-> user :user/name))
>>>
>>> ;; need to enable assertion checking - this can also be enabled globally 
>>> with system property clojure.spec.check-asserts
>>> (s/check-asserts true)
>>>
>>> (name {:user/name "Elon"})
>>> "Elon"
>>>
>>> (name {:x "Elon"})
>>> ExceptionInfo Spec assertion failed
>>> val: {:x "Elon"} fails predicate: (contains? % :user/name)
>>> :clojure.spec/failure  :assertion-failed
>>>   clojure.core/ex-info (core.clj:4725)
>>>
>>> Rather than use it in a precondition, you can also use s/assert directly 
>>> in the code.
>>>
>>> On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, 
>>> joakim.t...@nova.com wrote:

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

 (s/def :user/name string?)
 (s/def :common/user (s/keys :req [:user/name]))

 ; first version of name (using :pre)
 (defn name [user]
   {:pre [(s/valid? :common/user user)]}
   (-> user :user/name))

 ; This statement works ok and returns "Elon":
 (name {:user/name "Elon"})

 ; but this statement...
 (name {:x "Elon"})

 ;...will throw:
 CompilerException java.lang.AssertionError:
 Assert failed: (s/valid? :common/user user)

 ; ...but then I don't get as much information
 ; about the error as if I would have called:
 (s/explain :common/user {:x "Elon"})

 ;...which also contains the predicate:
 val: {:x "Elon"} fails spec: :common/user
 predicate: (contains? % :user/name)

 ; (second version of name - more verbose)
 ; or do I need to wite it like this:
 (defn name [user]
   (let [parsed (s/conform :common/user user)]
 (if (= parsed ::s/invalid)
   (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
   (-> user :user/name

 ; so that:
 (name {:x "Elon"})

 ; ...will return:
 CompilerException clojure.lang.ExceptionInfo:
   Invalid input #:clojure.spec{:problems}
 ({:path [], :pred (contains? % :user/name),
   :val {:x "Elon"}, :via [:common/user], :in []})

 ; It should be nice if I could be able to write it like this
 ; (or similar, to get a better error message):
 (defn name [user]
   {:pre [(s/explain :common/user user)]}
   (-> user :user/name))



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

Re: clojure.spec - Using :pre conditions (or not)?

[Shantanu Kumar]

Hi Joakim,

You might be interested in Paul Stadig's library 
https://github.com/pjstadig/assertions that leverages Java's `-ea` 
(enable-assertions, which you may want to keep enabled in dev) command-line 
flag. If you have a bunch of things together to assert, you may want to use 
the `when-assert` macro for wholesale 
optimization: 
https://github.com/pjstadig/assertions/blob/0.2.0/src/pjstadig/assertions.clj#L13


Shantanu

On Thursday, 15 September 2016 16:50:17 UTC+5:30, joakim.t...@nova.com 
wrote:
>
> Ok, thanks!
>
> In the Java world, the assertions is also something that need to be turn 
> on explicitly.
> In that sence, they are kind of not mandatory to be executed (or at least 
> signals that to the reader of the code).
>
> I would be happier if you guys could add another method, that I can use in 
> my :pre conditions, that leverage
> the same amount of details in the error messages, but that is always 
> "turned on".
>
> In the meanwhile, I will use s/assert ;-)
>
> BR,
> Joakim Tengstrand
>
>
> On Wednesday, 14 September 2016 15:59:09 UTC+2, Alex Miller wrote:
>>
>> Another option that has been added since the guide was written is 
>> s/assert which seems closer to what you're suggesting.
>>
>> (defn name [user]
>>   {:pre [(s/assert :common/user user)]}
>>   (-> user :user/name))
>>
>> ;; need to enable assertion checking - this can also be enabled globally 
>> with system property clojure.spec.check-asserts
>> (s/check-asserts true)
>>
>> (name {:user/name "Elon"})
>> "Elon"
>>
>> (name {:x "Elon"})
>> ExceptionInfo Spec assertion failed
>> val: {:x "Elon"} fails predicate: (contains? % :user/name)
>> :clojure.spec/failure  :assertion-failed
>>   clojure.core/ex-info (core.clj:4725)
>>
>> Rather than use it in a precondition, you can also use s/assert directly 
>> in the code.
>>
>> On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, 
>> joakim.t...@nova.com wrote:
>>>
>>> (ns spec-test.core
>>>   (:require [clojure.spec :as s]))
>>>
>>> (s/def :user/name string?)
>>> (s/def :common/user (s/keys :req [:user/name]))
>>>
>>> ; first version of name (using :pre)
>>> (defn name [user]
>>>   {:pre [(s/valid? :common/user user)]}
>>>   (-> user :user/name))
>>>
>>> ; This statement works ok and returns "Elon":
>>> (name {:user/name "Elon"})
>>>
>>> ; but this statement...
>>> (name {:x "Elon"})
>>>
>>> ;...will throw:
>>> CompilerException java.lang.AssertionError:
>>> Assert failed: (s/valid? :common/user user)
>>>
>>> ; ...but then I don't get as much information
>>> ; about the error as if I would have called:
>>> (s/explain :common/user {:x "Elon"})
>>>
>>> ;...which also contains the predicate:
>>> val: {:x "Elon"} fails spec: :common/user
>>> predicate: (contains? % :user/name)
>>>
>>> ; (second version of name - more verbose)
>>> ; or do I need to wite it like this:
>>> (defn name [user]
>>>   (let [parsed (s/conform :common/user user)]
>>> (if (= parsed ::s/invalid)
>>>   (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
>>>   (-> user :user/name
>>>
>>> ; so that:
>>> (name {:x "Elon"})
>>>
>>> ; ...will return:
>>> CompilerException clojure.lang.ExceptionInfo:
>>>   Invalid input #:clojure.spec{:problems}
>>> ({:path [], :pred (contains? % :user/name),
>>>   :val {:x "Elon"}, :via [:common/user], :in []})
>>>
>>> ; It should be nice if I could be able to write it like this
>>> ; (or similar, to get a better error message):
>>> (defn name [user]
>>>   {:pre [(s/explain :common/user user)]}
>>>   (-> user :user/name))
>>>
>>>

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

Re: clojure.spec - Using :pre conditions (or not)?

[joakim . tengstrand]

Ok, thanks!

In the Java world, the assertions is also something that need to be turn on 
explicitly.
In that sence, they are kind of not mandatory to be executed (or at least 
signals that to the reader of the code).

I would be happier if you guys could add another method, that I can use in 
my :pre conditions, that leverage
the same amount of details in the error messages, but that is always 
"turned on".

In the meanwhile, I will use s/assert ;-)

BR,
Joakim Tengstrand


On Wednesday, 14 September 2016 15:59:09 UTC+2, Alex Miller wrote:
>
> Another option that has been added since the guide was written is s/assert 
> which seems closer to what you're suggesting.
>
> (defn name [user]
>   {:pre [(s/assert :common/user user)]}
>   (-> user :user/name))
>
> ;; need to enable assertion checking - this can also be enabled globally 
> with system property clojure.spec.check-asserts
> (s/check-asserts true)
>
> (name {:user/name "Elon"})
> "Elon"
>
> (name {:x "Elon"})
> ExceptionInfo Spec assertion failed
> val: {:x "Elon"} fails predicate: (contains? % :user/name)
> :clojure.spec/failure  :assertion-failed
>   clojure.core/ex-info (core.clj:4725)
>
> Rather than use it in a precondition, you can also use s/assert directly 
> in the code.
>
> On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, joakim.t...@nova.com 
>  wrote:
>>
>> (ns spec-test.core
>>   (:require [clojure.spec :as s]))
>>
>> (s/def :user/name string?)
>> (s/def :common/user (s/keys :req [:user/name]))
>>
>> ; first version of name (using :pre)
>> (defn name [user]
>>   {:pre [(s/valid? :common/user user)]}
>>   (-> user :user/name))
>>
>> ; This statement works ok and returns "Elon":
>> (name {:user/name "Elon"})
>>
>> ; but this statement...
>> (name {:x "Elon"})
>>
>> ;...will throw:
>> CompilerException java.lang.AssertionError:
>> Assert failed: (s/valid? :common/user user)
>>
>> ; ...but then I don't get as much information
>> ; about the error as if I would have called:
>> (s/explain :common/user {:x "Elon"})
>>
>> ;...which also contains the predicate:
>> val: {:x "Elon"} fails spec: :common/user
>> predicate: (contains? % :user/name)
>>
>> ; (second version of name - more verbose)
>> ; or do I need to wite it like this:
>> (defn name [user]
>>   (let [parsed (s/conform :common/user user)]
>> (if (= parsed ::s/invalid)
>>   (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
>>   (-> user :user/name
>>
>> ; so that:
>> (name {:x "Elon"})
>>
>> ; ...will return:
>> CompilerException clojure.lang.ExceptionInfo:
>>   Invalid input #:clojure.spec{:problems}
>> ({:path [], :pred (contains? % :user/name),
>>   :val {:x "Elon"}, :via [:common/user], :in []})
>>
>> ; It should be nice if I could be able to write it like this
>> ; (or similar, to get a better error message):
>> (defn name [user]
>>   {:pre [(s/explain :common/user user)]}
>>   (-> user :user/name))
>>
>>

-- 
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 support for Visual Studio Code

[Andrey Lisin]

Hey guys,

I've been working on Clojure support for Visual Studio Code text editor for 
a while. The first version is very close to the point when it can be 
published to Visual Studio Code marketplace, but I would like to test it a 
bit more before. Maybe there are Visual Studio Code uses here who can try 
the extension and give feedback.

Features extension supports:

- code completion
- interaction with REPL
- go to definition
- documentation hints

The extension can be obtained from its GitHub page 
(https://github.com/avli/clojureVSCode/releases). Download the vsix file 
and drag-and-drop it to the Visual Studio Code. The extension relies on 
cider-nrepl, so don't forget to add it to the dependencies list. To connect 
to nREPL use "Connect to nREPL" command from the command palette. More 
information is available on the extension's GitHub page.

Hope it be useful for someone.

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