Re: Using core.match in tests?
Thanks, exactly what i needed
On Monday, June 22, 2015 at 1:01:30 AM UTC+3, Sean Corfield wrote:
How about this:
(defmacro matches [value pattern]
`(is (match ~value ~pattern true :else false)
(str (match ~value '~pattern
(let [a {:x 2}]
(matches a {:y _}))
; = FAIL
; = (match {:x 2} {:y _})
; = expected: (clojure.core.match/match a {:y _} true :else false)
; = actual: false
--
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.
Using core.match in tests?
It would be fun to use core.match to have an easier time testing results
that are hash-maps of different patterns. I'm just having a difficult time
to get failing cases' input values show up in test results:
(use 'clojure.test)
(require '[clojure.core.match :refer [match]])
(defmacro matches [value pattern]
`(match ~value
~pattern true
:else false))
(let [a {:x 2}]
(is (= a {:y 3})))
; = FAIL
; = expected: (= a {:y 3})
; = actual: (not (= {:x 2} {:y 3}))
(let [a {:x 2}]
(is (matches a {:y _})))
; = FAIL
; = expected: (matches a {:y _})
; = actual: false
What I would like is have more around
; = actual: (not (matches {:x 2} {:y _}))
if possible
--
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.7.0-beta1 released
On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Sorry, back to this stuff again. I tried using discard inside but #?(:clj #_'whatever) just throws CompilerException java.lang.RuntimeException: read-cond starting on line 32 requires an even number of forms when compiling on clojure. Would be nice to have a way to ignore reader conditional forms or the thingie things inside but there does not seem to be an easy way. -- 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.7.0-beta1 released
Sounds like you guys have it figured out; conditional reading forms cannot be ignored, only their results. Just wanted to make sure, had some bad times with it heh On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 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: [ANN] Boot 2.0.0-rc1 released
Not to mention how compact even interactive cljs development is in comparison. I made a small example on using om with the figwheel like cljs-reload. https://github.com/om-cookbook/om-cookbook/tree/master/recipes/boot-setup On Wednesday, December 17, 2014 7:31:52 PM UTC+2, Ivan L wrote: cljx support turns my head. I took like a week off and on to read up on all the cljx/cljs/lein documentation and to create the cljx-start template. When I was working on it, I kept asking myself, why is all this stuff necessary. That which is generated by a computer should not have to be. Boot looks a lot simpler by comparison which I'm drawn to. Will be following more closely, nice work. -- 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] Silk, an isomorphic routing library for Clojure and ClojureScript
Very nice one, Dom. Bidirectional routes are indeed especially important to render and dispatch routes in Om etc. In secretary its a bit awkward since you have to write stuff like (defroute front-page / [] :front-page) and then a separate thingie for matching the keywords back to the routes. On the other hand secretary will probably serve non-React apps well with its dispatch actions when you dont have React lifecycle methods. -- 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.
