Re: An Error spec?
How about using exception instances as errors? That plays pretty nicely with ex-info and (try ... (catch Exception e e)). I've built https://github.com/dawcs/flow on top of that approach and that seems like pretty good abstraction. Despite I'm not sure about CLJS. Anomalies are also great and you may check out https://github.com/dawcs/anomalies-tools for some tooling around it. But you may still need a bridge to convert exceptions caught from 3rd-party java libs into anomalies structure. And despite Cognitect roots, it doesn't feel like "official standard". пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал: > > I've started to see a pattern in my spec like this: > > (s/or :success string? > :error ::error) > > And I've been tempted to create my own spec macro for this. But I also > thought, maybe Spec itself should have such a spec. > > (s/error ) > > What do people think? > -- 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] 1.10.0-beta5
On Wednesday, November 7, 2018 at 3:19:27 AM UTC-6, Khalid Jebbari wrote: > > Example usage of tap: > https://quanttype.net/posts/2018-10-18-how-i-use-tap.html > > I've also briefly read the source code of the datafy namespace (short and > easy to understand), and my understanding is that it's currently for > one-way transformation of Java Objects into Clojure data through the > Datafiable protocol but it will attach the original object as a metadata to > the Clojure data produced. My feeling tells me that datafy will be used to > transform a clojure.spec object into data... (to avoid breaking the current > spec API). I haven't understood the nav function and associated Navigable > protocol yet though. > That's a good summary. Wasn't really created for spec, but that is one possible use of it, still TBD. -- 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] 1.10.0-beta5
On Wednesday, November 7, 2018 at 2:12:44 AM UTC-6, Khalid Jebbari wrote: > > Alex, it's funny that the example you showed about using the new extension > mechanism looks very much like implementing lifecycle hooks in React.js > (and the various CLJ/CLJS wrappers). > > Indeed having value-based extension makes it much more flexible than > having to use deftype/defrecord. My understanding is that since it's based > on metadata, one could extend after the fact with > `reset-meta!`/`alter-meta!` right? > Yep. > -- 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: What if ^:const could inline everything before macroexpanssion?
Ah right, I see now.
Ya, so it seems macros are fully expanded first, and then constant are
inlined, and then code is evaled.
So there's really no way to specify a global to be used within a macro
itself, unless you resolve it explicitly within your macro, using resolve
or eval, or if you use the reader eval when calling you macro.
On Wednesday, 7 November 2018 02:20:06 UTC-8, juan.facorro wrote:
>
> Sorry, I now understand what you mean.
>
> The unfolding logic that I proposed before was completely missing the fact
> that the foo macro is not:
>
> (defmacro foo
> [x]
> `(+ 10 ~x))
>
> But:
>
> (defmacro foo
> [x]
> (+ 10 x))
>
> The following assertion from the previous post is blatantly wrong with the
> correct macro definition above:
>
>> This tries to macroexpand the expression, which in this case will result in
>> `(foo bar)` being expanded into `(+ 10 foo)`.
>
> So when evaluating (foo bar) we do get the exception you mention, of
> course, since on macroexpansion we are trying to add 10 and the symbol bar
> .
>
> It is still the case as before though that the macroexpansion of (foo
> bar)happens
> before the symbol bar is resolved and analyzed as a constant expression.
>
> Sorry for the mess and confusion.
>
> On Wednesday, November 7, 2018 at 11:04:27 AM UTC+1, juan.facorro wrote:
>>
>> That's strange, this is what I get in the REPL when evaluating that
>> expression:
>>
>> $ clj
>> Clojure 1.9.0
>> user=> (. clojure.lang.Numbers (add 10 100))
>> 110
>> user=>
>>
>>
>>
>> On Wednesday, November 7, 2018 at 10:01:20 AM UTC+1, Didier wrote:
>>>
>>> Hey, thanks for the deep dive, but I'm not sure I either understand, or
>>> that it is correct.
>>>
>>> So what we end up with is the equivalent to analyzing the expression `(.
clojure.lang.Numbers (add 10 100))`.
>>>
>>> When I run my example, I get:
>>>
>>> ClassCastException clojure.lang.Symbol cannot be cast to java.lang.
>>> Number clojure.lang.Numbers.add
>>>
>>> When I macroexpand-1 my example, I also get the same ClassCastException.
>>>
>>> But if we follow your step by step, you make it sound like it would work
>>> and return 110.
>>>
>>> So at which step would this exception be thrown? And why?
>>>
>>>
>>> On Thursday, 15 March 2018 11:11:24 UTC-7, Didier wrote:
I was hoping that ^:const would be able to inline any symbol value and
that it would do so before macroexpanssion so that:
(def ^:const bar {:a 100})
(defmacro foo
[x]
(:a x))
(foo bar)
Would return:
100
The same way that:
(foo {:a 100})
does.
Then I read that ^:const only inlines primitive values (which
disappointed me), but so I thought that this would work:
(def ^:const bar 100)
(defmacro foo
[x]
(+ 10 x))
(foo bar)
but that also doesn't work.
So now I believe that ^:const inlines after macroexpanssion.
I feel it would be really cool to be able to factor some input to
macros into constants, is this something I could open a ticket for, to
extend ^:const so it can inline all literal values and also does the
inlining before macroexpanssion so that the above would 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: What's the end goal for tools.deps?
Sean, your deps.edn is a golden mine. Thanks a lot for sharing it. On Sunday, November 4, 2018 at 4:46:45 AM UTC+1, Didier wrote: > > I read the rationale, and I understand that we needed a way to bundle > depencies for clj and clojure cli. But in practice, I'm seeing a lot of > people move to it, away from boot or lein, and I fail to see what the end > goal really is? > > Any serious work will need a build tool of some sort. If you use lein, it > comes with its own dependency management and config. Same for boot (as far > as I know). So in practice, if I use tools.deps, I've now doubled the > number of tools I depend on. I need lein and tools.deps. > > For me, it seems the benefit would be around unified dependency config > format and maybe reuse of the resolver logic. Like say Lein and Boot and > all tools needing to specify dependencies adopted the format of tools.deps. > This would be nice, especially for source based dependencies, and dealing > with transitive dependencies in such case. > > So, is there any hope/work to adopt the format in Lein and Boot? Or what > is the end goal otherwise? > > Regards > -- 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: What if ^:const could inline everything before macroexpanssion?
Sorry, I now understand what you mean.
The unfolding logic that I proposed before was completely missing the fact
that the foo macro is not:
(defmacro foo
[x]
`(+ 10 ~x))
But:
(defmacro foo
[x]
(+ 10 x))
The following assertion from the previous post is blatantly wrong with the
correct macro definition above:
> This tries to macroexpand the expression, which in this case will result in
> `(foo bar)` being expanded into `(+ 10 foo)`.
So when evaluating (foo bar) we do get the exception you mention, of
course, since on macroexpansion we are trying to add 10 and the symbol bar.
It is still the case as before though that the macroexpansion of (foo
bar)happens
before the symbol bar is resolved and analyzed as a constant expression.
Sorry for the mess and confusion.
On Wednesday, November 7, 2018 at 11:04:27 AM UTC+1, juan.facorro wrote:
>
> That's strange, this is what I get in the REPL when evaluating that
> expression:
>
> $ clj
> Clojure 1.9.0
> user=> (. clojure.lang.Numbers (add 10 100))
> 110
> user=>
>
>
>
> On Wednesday, November 7, 2018 at 10:01:20 AM UTC+1, Didier wrote:
>>
>> Hey, thanks for the deep dive, but I'm not sure I either understand, or
>> that it is correct.
>>
>> So what we end up with is the equivalent to analyzing the expression `(.
>>> clojure.lang.Numbers (add 10 100))`.
>>>
>>
>> When I run my example, I get:
>>
>> ClassCastException clojure.lang.Symbol cannot be cast to java.lang.Number
>> clojure.lang.Numbers.add
>>
>> When I macroexpand-1 my example, I also get the same ClassCastException.
>>
>> But if we follow your step by step, you make it sound like it would work
>> and return 110.
>>
>> So at which step would this exception be thrown? And why?
>>
>>
>> On Thursday, 15 March 2018 11:11:24 UTC-7, Didier wrote:
>>>
>>> I was hoping that ^:const would be able to inline any symbol value and
>>> that it would do so before macroexpanssion so that:
>>>
>>> (def ^:const bar {:a 100})
>>>
>>> (defmacro foo
>>> [x]
>>> (:a x))
>>>
>>> (foo bar)
>>>
>>> Would return:
>>>
>>> 100
>>>
>>> The same way that:
>>>
>>> (foo {:a 100})
>>>
>>> does.
>>>
>>> Then I read that ^:const only inlines primitive values (which
>>> disappointed me), but so I thought that this would work:
>>>
>>> (def ^:const bar 100)
>>>
>>> (defmacro foo
>>> [x]
>>> (+ 10 x))
>>>
>>> (foo bar)
>>>
>>> but that also doesn't work.
>>>
>>> So now I believe that ^:const inlines after macroexpanssion.
>>>
>>> I feel it would be really cool to be able to factor some input to macros
>>> into constants, is this something I could open a ticket for, to extend
>>> ^:const so it can inline all literal values and also does the inlining
>>> before macroexpanssion so that the above would 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: What if ^:const could inline everything before macroexpanssion?
That's strange, this is what I get in the REPL when evaluating that
expression:
$ clj
Clojure 1.9.0
user=> (. clojure.lang.Numbers (add 10 100))
110
user=>
On Wednesday, November 7, 2018 at 10:01:20 AM UTC+1, Didier wrote:
>
> Hey, thanks for the deep dive, but I'm not sure I either understand, or
> that it is correct.
>
> So what we end up with is the equivalent to analyzing the expression `(.
>> clojure.lang.Numbers (add 10 100))`.
>>
>
> When I run my example, I get:
>
> ClassCastException clojure.lang.Symbol cannot be cast to java.lang.Number
> clojure.lang.Numbers.add
>
> When I macroexpand-1 my example, I also get the same ClassCastException.
>
> But if we follow your step by step, you make it sound like it would work
> and return 110.
>
> So at which step would this exception be thrown? And why?
>
>
> On Thursday, 15 March 2018 11:11:24 UTC-7, Didier wrote:
>>
>> I was hoping that ^:const would be able to inline any symbol value and
>> that it would do so before macroexpanssion so that:
>>
>> (def ^:const bar {:a 100})
>>
>> (defmacro foo
>> [x]
>> (:a x))
>>
>> (foo bar)
>>
>> Would return:
>>
>> 100
>>
>> The same way that:
>>
>> (foo {:a 100})
>>
>> does.
>>
>> Then I read that ^:const only inlines primitive values (which
>> disappointed me), but so I thought that this would work:
>>
>> (def ^:const bar 100)
>>
>> (defmacro foo
>> [x]
>> (+ 10 x))
>>
>> (foo bar)
>>
>> but that also doesn't work.
>>
>> So now I believe that ^:const inlines after macroexpanssion.
>>
>> I feel it would be really cool to be able to factor some input to macros
>> into constants, is this something I could open a ticket for, to extend
>> ^:const so it can inline all literal values and also does the inlining
>> before macroexpanssion so that the above would 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] 1.10.0-beta5
Example usage of
tap: https://quanttype.net/posts/2018-10-18-how-i-use-tap.html
I've also briefly read the source code of the datafy namespace (short and
easy to understand), and my understanding is that it's currently for
one-way transformation of Java Objects into Clojure data through the
Datafiable protocol but it will attach the original object as a metadata to
the Clojure data produced. My feeling tells me that datafy will be used to
transform a clojure.spec object into data... (to avoid breaking the current
spec API). I haven't understood the nav function and associated Navigable
protocol yet though.
On Wednesday, November 7, 2018 at 9:40:28 AM UTC+1, Didier wrote:
>
> Hum, just noticed tap. Seems really interesting. I'm not thinking of any
> concrete usage for now, but I like it!
>
> Also, is the object in the datafy description referring to a Java object?
> If so, is it a way to transform nested Java objects into Clojure data, and
> possibly back?
>
> On Wednesday, 7 November 2018 00:12:44 UTC-8, Khalid Jebbari wrote:
>>
>> Alex, it's funny that the example you showed about using the new
>> extension mechanism looks very much like implementing lifecycle hooks in
>> React.js (and the various CLJ/CLJS wrappers).
>>
>> Indeed having value-based extension makes it much more flexible than
>> having to use deftype/defrecord. My understanding is that since it's based
>> on metadata, one could extend after the fact with
>> `reset-meta!`/`alter-meta!` right?
>>
>> On Tuesday, November 6, 2018 at 2:42:45 PM UTC+1, Alex Miller wrote:
>>>
>>> 1.10.0-beta5 is now available.
>>>
>>> You can try it with clj using:
>>>
>>> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
>>> "1.10.0-beta5"}}}'
>>>
>>> Changes in 1.10.0-beta5:
>>>
>>>
>>>- In addition to prior methods of extension, values can now extend
>>>protocols by adding metadata where keys are fully-qualified symbols
>>> naming
>>>protocol functions and values are function implementations. Protocol
>>>implementations are checked first for direct definitions (defrecord,
>>>deftype, reify), then metadata definitions, then external extensions
>>>(extend, extend-type, extend-protocol). datafy has been updated to use
>>> this
>>>mechanism.
>>>- `symbol` can now be passed vars or keywords to obtain the
>>>corresponding symbol
>>>- CLJ-2420 error
>>>reporting enhancements - more refined phase reporting, new
>>>clojure.main/ex-triage split out of clojure.main/ex-str, execution
>>> errors
>>>now report the top *user* line in the stack trace omitting frames from
>>>core, enhancements to providing file and line via meta on a form
>>>- CLJ-2425 add java
>>>11 javadoc url
>>>- CLJ-2424 fix test
>>>bug from CLJ-2417
>>>
>>> You can read the full 1.10 changelog here:
>>> https://github.com/clojure/clojure/blob/master/changes.md
>>>
>>
--
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: What if ^:const could inline everything before macroexpanssion?
Hey, thanks for the deep dive, but I'm not sure I either understand, or
that it is correct.
So what we end up with is the equivalent to analyzing the expression `(.
> clojure.lang.Numbers (add 10 100))`.
>
When I run my example, I get:
ClassCastException clojure.lang.Symbol cannot be cast to java.lang.Number
clojure.lang.Numbers.add
When I macroexpand-1 my example, I also get the same ClassCastException.
But if we follow your step by step, you make it sound like it would work
and return 110.
So at which step would this exception be thrown? And why?
On Thursday, 15 March 2018 11:11:24 UTC-7, Didier wrote:
>
> I was hoping that ^:const would be able to inline any symbol value and
> that it would do so before macroexpanssion so that:
>
> (def ^:const bar {:a 100})
>
> (defmacro foo
> [x]
> (:a x))
>
> (foo bar)
>
> Would return:
>
> 100
>
> The same way that:
>
> (foo {:a 100})
>
> does.
>
> Then I read that ^:const only inlines primitive values (which disappointed
> me), but so I thought that this would work:
>
> (def ^:const bar 100)
>
> (defmacro foo
> [x]
> (+ 10 x))
>
> (foo bar)
>
> but that also doesn't work.
>
> So now I believe that ^:const inlines after macroexpanssion.
>
> I feel it would be really cool to be able to factor some input to macros
> into constants, is this something I could open a ticket for, to extend
> ^:const so it can inline all literal values and also does the inlining
> before macroexpanssion so that the above would 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] 1.10.0-beta5
Hum, just noticed tap. Seems really interesting. I'm not thinking of any
concrete usage for now, but I like it!
Also, is the object in the datafy description referring to a Java object?
If so, is it a way to transform nested Java objects into Clojure data, and
possibly back?
On Wednesday, 7 November 2018 00:12:44 UTC-8, Khalid Jebbari wrote:
>
> Alex, it's funny that the example you showed about using the new extension
> mechanism looks very much like implementing lifecycle hooks in React.js
> (and the various CLJ/CLJS wrappers).
>
> Indeed having value-based extension makes it much more flexible than
> having to use deftype/defrecord. My understanding is that since it's based
> on metadata, one could extend after the fact with
> `reset-meta!`/`alter-meta!` right?
>
> On Tuesday, November 6, 2018 at 2:42:45 PM UTC+1, Alex Miller wrote:
>>
>> 1.10.0-beta5 is now available.
>>
>> You can try it with clj using:
>>
>> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
>> "1.10.0-beta5"}}}'
>>
>> Changes in 1.10.0-beta5:
>>
>>
>>- In addition to prior methods of extension, values can now extend
>>protocols by adding metadata where keys are fully-qualified symbols
>> naming
>>protocol functions and values are function implementations. Protocol
>>implementations are checked first for direct definitions (defrecord,
>>deftype, reify), then metadata definitions, then external extensions
>>(extend, extend-type, extend-protocol). datafy has been updated to use
>> this
>>mechanism.
>>- `symbol` can now be passed vars or keywords to obtain the
>>corresponding symbol
>>- CLJ-2420 error
>>reporting enhancements - more refined phase reporting, new
>>clojure.main/ex-triage split out of clojure.main/ex-str, execution errors
>>now report the top *user* line in the stack trace omitting frames from
>>core, enhancements to providing file and line via meta on a form
>>- CLJ-2425 add java 11
>>javadoc url
>>- CLJ-2424 fix test
>>bug from CLJ-2417
>>
>> You can read the full 1.10 changelog here:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>
--
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] 1.10.0-beta5
Alex, it's funny that the example you showed about using the new extension
mechanism looks very much like implementing lifecycle hooks in React.js
(and the various CLJ/CLJS wrappers).
Indeed having value-based extension makes it much more flexible than having
to use deftype/defrecord. My understanding is that since it's based on
metadata, one could extend after the fact with `reset-meta!`/`alter-meta!`
right?
On Tuesday, November 6, 2018 at 2:42:45 PM UTC+1, Alex Miller wrote:
>
> 1.10.0-beta5 is now available.
>
> You can try it with clj using:
>
> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
> "1.10.0-beta5"}}}'
>
> Changes in 1.10.0-beta5:
>
>
>- In addition to prior methods of extension, values can now extend
>protocols by adding metadata where keys are fully-qualified symbols naming
>protocol functions and values are function implementations. Protocol
>implementations are checked first for direct definitions (defrecord,
>deftype, reify), then metadata definitions, then external extensions
>(extend, extend-type, extend-protocol). datafy has been updated to use
> this
>mechanism.
>- `symbol` can now be passed vars or keywords to obtain the
>corresponding symbol
>- CLJ-2420 error
>reporting enhancements - more refined phase reporting, new
>clojure.main/ex-triage split out of clojure.main/ex-str, execution errors
>now report the top *user* line in the stack trace omitting frames from
>core, enhancements to providing file and line via meta on a form
>- CLJ-2425 add java 11
>javadoc url
>- CLJ-2424 fix test bug
>from CLJ-2417
>
> You can read the full 1.10 changelog here:
> https://github.com/clojure/clojure/blob/master/changes.md
>
--
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.
