[ANN] defn podcast ep.3 : A tour of REPLs feat. Mike Fikes :)

[Vijay Kiran]

Hello Everyone!

We published the third episode of defn yesterday in which we take a tour of 
REPLs in Clojure Land.

We are very grateful to Mike Fikes  
(Planck/Replete/Ambly fame) - who joined us  on the podcast to share his 
experience. We would love to hear your feedback if you got a chance to 
listen.

defn on soundcloud: https://soundcloud.com/defn-771544745/defn3-repls

Cheers!
Vijay & Ray 


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

Automatically upversioning a project in continuous integration?

['Simon Brooke' via Clojure]

Apologies if this is a FAQ, I have done a number of searches and not found 
anything.

I see that the Clojure project's internal Hudson CI server does automatic 
upversioning on release builds (see documentation here 
). It 
doesn't, however, say in that page whether the project.clj file also gets 
automatically upversioned, or whether an upversioned SNAPSHOT number is 
automatically inserted into the develop branch project.clj. It also doesn't 
say how the magic is done (although it looks from the documentation as if 
it is just a Maven level, so not very hard to understand).

Has anyone made automatic upversioning in project.clj on master builds on a 
CI server work, and if so how did you do it? Does your recipe also 
upversion the SNAPSHOT number in project.clj in the develop branch?

Any help gratefully received!

-- 
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: instrumenting clojure.core

[Alex Miller]

I was suggesting that you could do something like this (although I'm pretty 
sure this doesn't work right now):

(s/fdef map
  :args (s/cat :f (s/fspec :args (s/+ ::s/any))
   :colls (s/* seqable?))
  :ret (s/or :seq seqable? :transducer ifn?)
  :fn #(if (zero? (count (-> % :args :colls)))
 ;; transducer
 (ifn? (-> % :ret))
 ;; lazy seq
 (and (seqable? (-> % :ret))
  (= (count (-> % :args :f :args))
 (count (-> % :args :colls))



In the map :args, spec the mapping function as well, then use :fn which can 
either relate the args and ret of the main function OR relationships 
between the args, as I'm doing at the very end. The input to :fn is the 
conformed output of the :args and :ret specs. 

But like I said, there are several problems with this right now and I need 
to discuss more with Rich whether something like this should be possible 
(mostly the args fspec is where I'm seeing issues.


On Monday, June 13, 2016 at 7:57:16 PM UTC-5, Alistair Roche wrote:
>
> Oh, I see what you mean now, Leon. Apologies for not reading more closely! 
> Yours is a much more interesting puzzle.
>
> Here's an attempt I made 
> , 
> groping towards it using reflection, but I couldn't even get that to work. 
> Would be curious to see what the solution is there, and even more so (like 
> you) to see if it can be done without reflection.
>
> On 13 June 2016 at 17:21, Leon Grapenthin  
> wrote:
>
>> Thank Alistair, but that does not really address my question. Alex 
>> suggested using :fn of fspec to check arity of a higher-order argument.
>>
>> But I could not find a tool to check function arity. Also I doubt :fn is 
>> going to work since I'd expect it to be invoked /after/ the call - i. e. 
>> the call would fail before the arity check.
>>
>> Note that in your example you can only use spec/generic testing to check 
>> arity because you know the argument types. You can't test a generic higher 
>> order fn for just arity like this because the generator won't know the 
>> correct types to generate.
>>
>>
>> On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:
>>>
>>> Hi Leon,
>>>
>>> I think you're looking for fspec 
>>> ,
>>>  
>>> unless I'm misunderstanding something. I wrote up an example 
>>>  that 
>>> might be helpful.
>>>
>>> @Ryan thanks for starting this thread, and @Alex thanks for responding. 
>>> It's been an interesting discussion!
>>>
>>> Cheers,
>>>
>>>
>

-- 
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: Automatically upversioning a project in continuous integration?

[Alex Miller]

On Tuesday, June 14, 2016 at 5:21:04 AM UTC-5, Simon Brooke wrote:
>
> Apologies if this is a FAQ, I have done a number of searches and not found 
> anything.
>
> I see that the Clojure project's internal Hudson CI server does automatic 
> upversioning on release builds (see documentation here 
> ). It 
> doesn't, however, say in that page whether the project.clj file also gets 
> automatically upversioned, or whether an upversioned SNAPSHOT number is 
> automatically inserted into the develop branch project.clj. It also doesn't 
> say how the magic is done (although it looks from the documentation as if 
> it is just a Maven level, so not very hard to understand).
>

First note that Clojure contrib builds on Hudson use only Maven, not 
Leiningen, so the project.clj files (if they exist) are not used. 
Everything you see happening is standard Maven snapshot release stuff. The 
version stays at x.y.z-SNAPSHOT (no change is committed to the repo on a 
snapshot build). A SNAPSHOT version is effectively a "virtual" version 
number. The release plugin will generate a SNAPSHOT release and set the 
version number to include a timestamp and a build number and that's what 
gets published to the maven snapshot repo (see here 

 
for example). When retrieving a SNAPSHOT, Maven knows how to find, 
download, and use the newest version of a SNAPSHOT.

There are additionally some plugins that automatically do version number 
updating (for released versions), 
notably http://www.mojohaus.org/versions-maven-plugin/.
 

> Has anyone made automatic upversioning in project.clj on master builds on 
> a CI server work, and if so how did you do it? Does your recipe also 
> upversion the SNAPSHOT number in project.clj in the develop branch?
>

For leiningen, I'm not quite as familiar. I would hope the Leiningen 
support for publishing snapshots would follow the same process as expected 
for Maven snapshot releases and thus would work the same way - generating 
and publishing timestamped snapshot releases. Seems like Leiningen "release 
tasks" is what you want to look at as well re automatic bumping for 
releases.
 

>
> Any help gratefully received!
>

-- 
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: instrumenting clojure.core

[Francesco Bellomi]

I think map is a good example where the different arities have very 
different semantics, and maybe it would be practical to specify a separate 
spec for each arity.

In the unified spec, both :args and :ret have to resort to (more or less 
explicit) unions in order to express the sum of the separate cases, and :fn 
is complicated in order to disallow the undesired combinations.

Francesco 

On Tuesday, June 14, 2016 at 1:22:23 PM UTC+2, Alex Miller wrote:
>
> I was suggesting that you could do something like this (although I'm 
> pretty sure this doesn't work right now):
>
> (s/fdef map
>   :args (s/cat :f (s/fspec :args (s/+ ::s/any))
>:colls (s/* seqable?))
>   :ret (s/or :seq seqable? :transducer ifn?)
>   :fn #(if (zero? (count (-> % :args :colls)))
>  ;; transducer
>  (ifn? (-> % :ret))
>  ;; lazy seq
>  (and (seqable? (-> % :ret))
>   (= (count (-> % :args :f :args))
>  (count (-> % :args :colls))
>
>
>
> In the map :args, spec the mapping function as well, then use :fn which 
> can either relate the args and ret of the main function OR relationships 
> between the args, as I'm doing at the very end. The input to :fn is the 
> conformed output of the :args and :ret specs. 
>
> But like I said, there are several problems with this right now and I need 
> to discuss more with Rich whether something like this should be possible 
> (mostly the args fspec is where I'm seeing issues.
>
>
> On Monday, June 13, 2016 at 7:57:16 PM UTC-5, Alistair Roche wrote:
>>
>> Oh, I see what you mean now, Leon. Apologies for not reading more 
>> closely! Yours is a much more interesting puzzle.
>>
>> Here's an attempt I made 
>> , 
>> groping towards it using reflection, but I couldn't even get that to work. 
>> Would be curious to see what the solution is there, and even more so (like 
>> you) to see if it can be done without reflection.
>>
>> On 13 June 2016 at 17:21, Leon Grapenthin > > wrote:
>>
>>> Thank Alistair, but that does not really address my question. Alex 
>>> suggested using :fn of fspec to check arity of a higher-order argument.
>>>
>>> But I could not find a tool to check function arity. Also I doubt :fn is 
>>> going to work since I'd expect it to be invoked /after/ the call - i. e. 
>>> the call would fail before the arity check.
>>>
>>> Note that in your example you can only use spec/generic testing to check 
>>> arity because you know the argument types. You can't test a generic higher 
>>> order fn for just arity like this because the generator won't know the 
>>> correct types to generate.
>>>
>>>
>>> On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:

 Hi Leon,

 I think you're looking for fspec 
 ,
  
 unless I'm misunderstanding something. I wrote up an example 
  
 that might be helpful.

 @Ryan thanks for starting this thread, and @Alex thanks for responding. 
 It's been an interesting discussion!

 Cheers,


>>

-- 
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: Automatically upversioning a project in continuous integration?

['Simon Brooke' via Clojure]

Many thanks, googling 'leiningen release tasks' has certainly found me 
interesting things to read and digest.

On Tuesday, 14 June 2016 12:35:57 UTC+1, Alex Miller wrote:
>
>
>
> On Tuesday, June 14, 2016 at 5:21:04 AM UTC-5, Simon Brooke wrote:
>>
>> Apologies if this is a FAQ, I have done a number of searches and not 
>> found anything.
>>
>> I see that the Clojure project's internal Hudson CI server does automatic 
>> upversioning on release builds (see documentation here 
>> ). It 
>> doesn't, however, say in that page whether the project.clj file also gets 
>> automatically upversioned, or whether an upversioned SNAPSHOT number is 
>> automatically inserted into the develop branch project.clj. It also doesn't 
>> say how the magic is done (although it looks from the documentation as if 
>> it is just a Maven level, so not very hard to understand).
>>
>
> First note that Clojure contrib builds on Hudson use only Maven, not 
> Leiningen, so the project.clj files (if they exist) are not used. 
> Everything you see happening is standard Maven snapshot release stuff. The 
> version stays at x.y.z-SNAPSHOT (no change is committed to the repo on a 
> snapshot build). A SNAPSHOT version is effectively a "virtual" version 
> number. The release plugin will generate a SNAPSHOT release and set the 
> version number to include a timestamp and a build number and that's what 
> gets published to the maven snapshot repo (see here 
> 
>  
> for example). When retrieving a SNAPSHOT, Maven knows how to find, 
> download, and use the newest version of a SNAPSHOT.
>
> There are additionally some plugins that automatically do version number 
> updating (for released versions), notably 
> http://www.mojohaus.org/versions-maven-plugin/.
>  
>
>> Has anyone made automatic upversioning in project.clj on master builds on 
>> a CI server work, and if so how did you do it? Does your recipe also 
>> upversion the SNAPSHOT number in project.clj in the develop branch?
>>
>
> For leiningen, I'm not quite as familiar. I would hope the Leiningen 
> support for publishing snapshots would follow the same process as expected 
> for Maven snapshot releases and thus would work the same way - generating 
> and publishing timestamped snapshot releases. Seems like Leiningen "release 
> tasks" is what you want to look at as well re automatic bumping for 
> releases.
>  
>
>>
>> Any help gratefully received!
>>
>

-- 
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: instrumenting clojure.core

[Leon Grapenthin]

Thanks Alex, I was experimenting along similar lines. It might work since 
the lazy seq is not realized at this point and :f might not have been 
called. Otherwise the last clause would always hold true or never be called 
(due to earlier ArityException). It covers more of a test for map itself 
(how does map invoke the lambda?) than that it spec's maps arguments.

I have tried various other ways like conformers etc. and have the 
impression that if checking and reporting on correct arity of lambdas 
before invocation is going to become a concern of spec it would appear that 
a new function like "arities f -> set of numbers" as a language feature 
would be truly helpful.

It is certainly going to be interesting where the line to a type system 
will be drawn. For instance generating and checking (in worst case only a 
subset of) required types for :f is only possible if one takes samples from 
the passed colls dynamically which I am not sure spec is capable of or 
designed for. 

Looking forward to further developments of spec :)

On Tuesday, June 14, 2016 at 1:22:23 PM UTC+2, Alex Miller wrote:
>
> I was suggesting that you could do something like this (although I'm 
> pretty sure this doesn't work right now):
>
> (s/fdef map
>   :args (s/cat :f (s/fspec :args (s/+ ::s/any))
>:colls (s/* seqable?))
>   :ret (s/or :seq seqable? :transducer ifn?)
>   :fn #(if (zero? (count (-> % :args :colls)))
>  ;; transducer
>  (ifn? (-> % :ret))
>  ;; lazy seq
>  (and (seqable? (-> % :ret))
>   (= (count (-> % :args :f :args))
>  (count (-> % :args :colls))
>
>
>
> In the map :args, spec the mapping function as well, then use :fn which 
> can either relate the args and ret of the main function OR relationships 
> between the args, as I'm doing at the very end. The input to :fn is the 
> conformed output of the :args and :ret specs. 
>
> But like I said, there are several problems with this right now and I need 
> to discuss more with Rich whether something like this should be possible 
> (mostly the args fspec is where I'm seeing issues.
>
>
> On Monday, June 13, 2016 at 7:57:16 PM UTC-5, Alistair Roche wrote:
>>
>> Oh, I see what you mean now, Leon. Apologies for not reading more 
>> closely! Yours is a much more interesting puzzle.
>>
>> Here's an attempt I made 
>> , 
>> groping towards it using reflection, but I couldn't even get that to work. 
>> Would be curious to see what the solution is there, and even more so (like 
>> you) to see if it can be done without reflection.
>>
>> On 13 June 2016 at 17:21, Leon Grapenthin > > wrote:
>>
>>> Thank Alistair, but that does not really address my question. Alex 
>>> suggested using :fn of fspec to check arity of a higher-order argument.
>>>
>>> But I could not find a tool to check function arity. Also I doubt :fn is 
>>> going to work since I'd expect it to be invoked /after/ the call - i. e. 
>>> the call would fail before the arity check.
>>>
>>> Note that in your example you can only use spec/generic testing to check 
>>> arity because you know the argument types. You can't test a generic higher 
>>> order fn for just arity like this because the generator won't know the 
>>> correct types to generate.
>>>
>>>
>>> On Monday, June 13, 2016 at 4:00:30 AM UTC+2, Alistair Roche wrote:

 Hi Leon,

 I think you're looking for fspec 
 ,
  
 unless I'm misunderstanding something. I wrote up an example 
  
 that might be helpful.

 @Ryan thanks for starting this thread, and @Alex thanks for responding. 
 It's been an interesting discussion!

 Cheers,


>>

-- 
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] cljsee 0.1.0

[Herwig Hochleitner]

+1 thanks for releasing that.

I've been thinking about doing this also as a maven plugin. That might help
finally getting .cljc accepted in contrib projects.
​

-- 
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] Clojure 1.9.0-alpha6

[Alex Miller]

Clojure 1.9.0-alpha6 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha6
- Leiningen: [org.clojure/clojure "1.9.0-alpha6"]

1.9.0-alpha6 includes the following changes since 1.9.0-alpha5:

- & regex op now fails fast when regex passes but preds do not
- returns from alt/or are now map entries (supporting key/val) rather than 
2-element vector
- [BREAKING] fn-specs was renamed to fn-spec and returns either the 
registered fspec or nil
- fspec now accepts ifn?, not fn?
- fspec impl supports keyword lookup of its :args, :ret, and :fn specs
- fix fspec describe which was missing keys and improve describe of 
:args/ret/fn specs
- instrument now checks *only* the :args spec of a var - use the 
clojure.spec.test functions to test :ret and :fn specs
- Added generator support for bytes? and uri? which were accidentally left 
out in alpha5

-- 
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] New clojure.org!

[Alan Thompson]

Alex - I could not find a link to the Clojure.org github project on the 
clojure.org site. Should one be added under "Contributing" somewhere?
Alan

On Thursday, January 14, 2016 at 7:45:06 AM UTC-8, Alex Miller wrote:
>
> The new http://clojure.org is alive!
>
> Most of the content on the site is the same content as before (but in a 
> new shinier package). However, the site is now sourced from the public repo 
> at https://github.com/clojure/clojure-site and is open for contribution. 
> Contributions (via pull request) require a signed Clojure Contributor 
> Agreement, just as with Clojure itself - if you've already signed it, then 
> you don't need to do anything additional.
>
> We have been working on several new guides for the new Guides section and 
> you can see things in process at 
> https://github.com/clojure/clojure-site/issues - feel free to discuss on 
> issues there or threads here with a [DOC] indicator. Or on the #docs 
> channel on Slack.
>
> Big thanks to Tom Hickey on the design for the new site! As always, he was 
> a pleasure to work with.
>
> Alex
>

-- 
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] New clojure.org!

[Alex Miller]

Well there's a whole page about it at the link mentioned in the message 
below - https://github.com/clojure/clojure-site

I also have an outstanding ticket to add a link from every page to the 
source file in the footer. I think that will be sufficient.
 

On Tuesday, June 14, 2016 at 4:24:59 PM UTC-5, Alan Thompson wrote:
>
> Alex - I could not find a link to the Clojure.org github project on the 
> clojure.org site. Should one be added under "Contributing" somewhere?
> Alan
>
> On Thursday, January 14, 2016 at 7:45:06 AM UTC-8, Alex Miller wrote:
>>
>> The new http://clojure.org is alive!
>>
>> Most of the content on the site is the same content as before (but in a 
>> new shinier package). However, the site is now sourced from the public repo 
>> at https://github.com/clojure/clojure-site 
>> 
>>  
>> and is open for contribution. Contributions (via pull request) require a 
>> signed Clojure Contributor Agreement, just as with Clojure itself - if 
>> you've already signed it, then you don't need to do anything additional.
>>
>> We have been working on several new guides for the new Guides section and 
>> you can see things in process at 
>> https://github.com/clojure/clojure-site/issues - feel free to discuss on 
>> issues there or threads here with a [DOC] indicator. Or on the #docs 
>> channel on Slack.
>>
>> Big thanks to Tom Hickey on the design for the new site! As always, he 
>> was a pleasure to work with.
>>
>> Alex
>>
>

-- 
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] cljsee 0.1.0

[Daniel Compton]

Awesome work Alex. If you wanted, you could add a PR to update
http://clojure.org/guides/reader_conditionals#_backwards_compatibility with
your plugin?

On Wed, Jun 15, 2016 at 1:24 AM Herwig Hochleitner 
wrote:

> +1 thanks for releasing that.
>
> I've been thinking about doing this also as a maven plugin. That might
> help finally getting .cljc accepted in contrib projects.
> ​
>
> --
> 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.
>
-- 
—
Daniel

-- 
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] New clojure.org!

[Alex Miller]

Shoot, that was not the link I meant. I 
meant: http://clojure.org/community/contributing_site

On Tuesday, June 14, 2016 at 4:33:14 PM UTC-5, Alex Miller wrote:
>
> Well there's a whole page about it at the link mentioned in the message 
> below - https://github.com/clojure/clojure-site
>
> I also have an outstanding ticket to add a link from every page to the 
> source file in the footer. I think that will be sufficient.
>  
>
> On Tuesday, June 14, 2016 at 4:24:59 PM UTC-5, Alan Thompson wrote:
>>
>> Alex - I could not find a link to the Clojure.org github project on the 
>> clojure.org site. Should one be added under "Contributing" somewhere?
>> Alan
>>
>> On Thursday, January 14, 2016 at 7:45:06 AM UTC-8, Alex Miller wrote:
>>>
>>> The new http://clojure.org is alive!
>>>
>>> Most of the content on the site is the same content as before (but in a 
>>> new shinier package). However, the site is now sourced from the public repo 
>>> at https://github.com/clojure/clojure-site 
>>> 
>>>  
>>> and is open for contribution. Contributions (via pull request) require a 
>>> signed Clojure Contributor Agreement, just as with Clojure itself - if 
>>> you've already signed it, then you don't need to do anything additional.
>>>
>>> We have been working on several new guides for the new Guides section 
>>> and you can see things in process at 
>>> https://github.com/clojure/clojure-site/issues - feel free to discuss 
>>> on issues there or threads here with a [DOC] indicator. Or on the #docs 
>>> channel on Slack.
>>>
>>> Big thanks to Tom Hickey on the design for the new site! As always, he 
>>> was a pleasure to work with.
>>>
>>> Alex
>>>
>>

-- 
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: Qualified keys, Clojure records, Spec

[Mike Rodriguez]

Thanks for the response and giving me some understanding in the thought 
process behind this!

I'm happy that Spec is still offering support for unqualifed keys to fit 
use-cases like this in records.  I do think it would be cool to see 
something come out of the "implicit" namespace already associated to a 
record so that the keywords could be used in a qualified way, but obviously 
we'll have to wait and see how that one may or may not play out.  

It's good to hear that the thought has came up though!

On Saturday, June 11, 2016 at 11:57:38 AM UTC-5, Alex Miller wrote:
>
> This is a good question and one we've discussed a bit. You can use the 
> existing s/keys with :req-un and :opt-un to spec the (unqualified) keys of 
> a record - there's an example of this in the guide at 
> http://clojure.org/guides/spec. So that's the short-term current answer.
>
> However, there are potentially other things that could be done, either to 
> make working with unqualified keys easier (for example in the case where 
> spec names and unqualified key names didn't match) or in leveraging the 
> (implicit) namespace already associated with a record via the record class 
> itself. So, this is an area still potentially open for more work.
>
> I think deftype is not an issue as you don't generally have keyword field 
> access in deftype like you do with defrecord.
>
>
> On Saturday, June 11, 2016 at 11:02:57 AM UTC-5, Mike Rodriguez wrote:
>>
>> I know that Spec and the changes coming to Clojure 1.9 I see that 
>> namespace qualified keys have gained some focus. I understand the 
>> motivations for this and support it.  
>>
>> The one barrier that is coming up for me is in the use of Clojure records 
>> (and perhaps deftype types too). We use records fairly heavily in some of 
>> our applications for a few reasons.  
>>
>> (Some of this is for performance, some for instanceof support for some 
>> Java-style libraries we use, some is for better documentation of expected 
>> fields used repeatedly, and also we have used them to extend different 
>> protocol implementations to.) 
>>
>> I believe in some older talks a selling point of records, which I agree 
>> with, is they could be added later with not much change if you were already 
>> using maps throughout with those keys. This is due to record participating 
>> in the map abstractions.  
>>
>> So how can namespace qualified keys and the use of records intermix? Even 
>> if I am using maps combined with records where the record and maps share 
>> some common keys/fields, if the maps were qualified, they'd be incompatible 
>> I believe. If records keys were qualified it would obviously raise a little 
>> question on how they blend with the emitted Java class field names  
>>
>> I'd be curious to hear if there is any work or thought on this. Or maybe 
>> I can qualify keys and interoperate with records already and I just haven't 
>> noticed? 
>
>

-- 
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] defn podcast ep.3 : A tour of REPLs feat. Mike Fikes :)

[Jason Gilman]

Thanks for starting a new Clojure podcast! It's nice to see that the active 
count of Clojure podcasts has grown to 2. I had one small note about the 
Atom REPL you mentioned around 43 minutes in. You called it the "Atom Ink" 
REPL on the podcast. The REPL for Atom is called Proto REPL 
. There's a plugin called Atom 
ink that plays a small role in how it displays a nested tree of values. I'd 
love to hear more discussion of different development environments and 
using visualizations to help understand the code we're writing. Another one 
in that vein is Gorilla REPL which inspired some of the visualization 
aspects of Proto REPL.

Thanks, Jason Gilman

On Tuesday, June 14, 2016 at 4:12:25 AM UTC-4, Vijay Kiran wrote:
>
> Hello Everyone!
>
> We published the third episode of defn yesterday in which we take a tour 
> of REPLs in Clojure Land.
>
> We are very grateful to Mike Fikes  
> (Planck/Replete/Ambly fame) - who joined us  on the podcast to share his 
> experience. We would love to hear your feedback if you got a chance to 
> listen.
>
> defn on soundcloud: https://soundcloud.com/defn-771544745/defn3-repls
>
> Cheers!
> Vijay & Ray 
>
>
>

-- 
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.spec regression bug for 1.9.0-alpha6

[Alan Thompson]

Hi - Just noticed that the :ret function in fdef seems to be ignored in
1.9.0-alpha6:

user=> (require '[clojure.spec :as s])
user=> (defn dummy [x] (if x "yes" "no"))
user=> (s/fdef dummy
  #_=>   :args (s/cat :x integer?)
  #_=>   :ret  integer?)
user=> (s/instrument #'dummy)
user=> (dummy 3) (println *clojure-version*)
ExceptionInfo Call to #'user/dummy did not conform to spec:
val: "yes" fails at: [:ret] predicate: integer?
:clojure.spec/args  (3)
  clojure.core/ex-info (core.clj:4703)
{:major 1, :minor 9, :incremental 0, :qualifier alpha5}

;---

user=> (dummy 3) (println *clojure-version*)
"yes"
{:major 1, :minor 9, :incremental 0, :qualifier alpha6}

-- 
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 regression bug for 1.9.0-alpha6

[Alex Miller]

As noted in the alpha change list, this was an intentional change in what 
instrument does. Instrument is intended to be used to verify that other 
callers have invoked a function correctly. Checking that the function works 
(by verifying that :ret and :fn return valid results) should be done using 
one of the spec.test functions during testing.

Some other spec features are still to be added as well that relate to this 
change.

On Tuesday, June 14, 2016 at 7:01:09 PM UTC-5, Alan Thompson wrote:
>
> Hi - Just noticed that the :ret function in fdef seems to be ignored in 
> 1.9.0-alpha6:
>
> user=> (require '[clojure.spec :as s])
> user=> (defn dummy [x] (if x "yes" "no"))
> user=> (s/fdef dummy
>   #_=>   :args (s/cat :x integer?)
>   #_=>   :ret  integer?)
> user=> (s/instrument #'dummy)
> user=> (dummy 3) (println *clojure-version*)
> ExceptionInfo Call to #'user/dummy did not conform to spec:
> val: "yes" fails at: [:ret] predicate: integer?
> :clojure.spec/args  (3)
>   clojure.core/ex-info (core.clj:4703)
> {:major 1, :minor 9, :incremental 0, :qualifier alpha5}
>
> ;---
>
> user=> (dummy 3) (println *clojure-version*)
> "yes"
> {:major 1, :minor 9, :incremental 0, :qualifier alpha6}
>

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

GMail code formatter

[Alan Thompson]

Just discovered a cool Chrome extension so that you can get proper syntax
highlighting when pasting code into your email.  It turns plain-old code
into something nice to read:

*Plain:*

(defn truthy?
  "Returns true if arg is logical true (neither nil nor false); otherwise
returns false."
  [arg]
  (if arg true false) )
(s/fdef truthy?
  :args ::s/any
  :ret boolean?)

*Nice:*


(defn truthy?
  "Returns true if arg is logical true (neither nil nor false); otherwise
returns false."
  [arg]
  (if arg true false) )
(s/fdef truthy?
  :args ::s/any
  :ret boolean?)


Find it in the Google Chrome web store:
https://chrome.google.com/webstore/detail/gmail-syntax-highlighting/pcipmnfalbiopheelcmpllcjciifkaeh

Alan

-- 
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.spec(1.9.0-alpha6): Is this the expected return value from (s/gen (s/alt ...)) ?

[Joseph Wayne Norton]

Is this the expected return value?

=> (gen/sample (s/gen (s/alt :s string? :b boolean?)))
> ([""] [true] [""] ["v6n"] [true] ["q7p7"] ["310"] [true] ["FSmdw"] 
> ["809Gvz5"])


I am not expecting a vector to wrap each of the sample return values.

Best regards,

Joe N.

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

GMail code formatter

[Colin Taylor]

Even easier, just copy and paste from Cursive :)

-- 
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(1.9.0-alpha6): Is this the expected return value from (s/gen (s/alt ...)) ?

[Alex Miller]

It is. By using s/alt, you are inherently matching a sequential collection. 
You probably want s/or in this case instead.

On Tuesday, June 14, 2016 at 11:15:40 PM UTC-5, Joseph Wayne Norton wrote:
>
> Is this the expected return value?
>
> => (gen/sample (s/gen (s/alt :s string? :b boolean?)))
>> ([""] [true] [""] ["v6n"] [true] ["q7p7"] ["310"] [true] ["FSmdw"] 
>> ["809Gvz5"])
>
>
> I am not expecting a vector to wrap each of the sample return values.
>
> Best regards,
>
> Joe N.
>

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

spec.gen for uri?

[Erik Assum]

Just saw a tweet from Stuart Halloway pointing to the function which generates 
ramsom uri's, 
https://github.com/clojure/clojure/commit/1109dd4eafd95c169add38dd0051be413d9e49d0
I would argue that this function does not generate random-enough values:
1) you only generate urls using the http-protocol
2) you only generate urls with the most common three-letter tld
3) you do not generate urls with subdomains
4) there is no path on the url, only a domain name. 

I understand that I'm at liberty to write my own generator for uri's, but I 
would suggest that the standard implementation generate something a bit more 
random than

http://gshhs-udus-kshhs-zush.com

Erik. 
-- 
i farta

-- 
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: why is it so annoying to run clojure code

[James Gatannah]

I *totally* understand your (and pretty much every other responder's) 
frustration.

You're approaching it wrong.

Most python/ruby programmers get this wrong, also. It's OK. I did this 
wrong for
*years* in lots of different languages. (I blame my C++ background for how 
long
it's taking this to sink in for me).

One of the keys to "getting" lisp is to embrace the REPL. Start your 
environment
up. And let it run. It isn't a living, breathing entity, but it's easy to 
forget that after
a short while.

Python's interactive shell covers the same idea. I think ruby has IRB to do 
the
same sort of thing. But those are just kind-a sort-a "See? We can do the 
same
thing lisp does" wannabes.

I don't want to trash talk ruby or python. They're both great languages for 
what
they do.

But they're designed for solving different, easier problems. And they're 
built for
coping with those problems in ways that are horribly more complicated.

I came to clojure from a python/common lisp background (and I came to them
from a C++ background). I spent years hating everything different about it, 
and I was totally wrong.

Long startup time? Totally worth it. I go through it a few times when I get 
my
basic system defined. (People have already recommended Stuart Sierra's
Component architecture in this thread, haven't they?)

And then my entire system is defined and works. I don't ever need to restart
until I bring in a new dependency.

When I work in python, I have to restart everything under the sun every time
I screw up the arguments to a printf.

Immutable data structures? This is the paydirt, darling. I thought that 
this was
the most horrible part of clojure, and I wasted reams of imagination trying 
to
figure out ways around it.

And I was wrong.

Unless you're writing an OS kernel, you should probably be using immutable
data structures. Even if you're genius enough to track all the ways that 
your
mutable data structure could possibly be mangled, the next person to come
along and deal with it won't be as smart as you.

That "next person" is usually you 6 months in the future. Don't screw 
yourself
over.

And then there's the JVM.

I used to think I was safer from hackers because the JVM gets hacked
20,000 times a day and "my" platform *never* got hacked.

Then someone pointed out that the JVM gets attacked 20 bazillion times a
second, whereas "my" platform would never get attacked until/unless I
actually created something successful on it.

Just learn how to use lein and/or boot. It *is* annoying, but a good
investment.


On Thursday, June 9, 2016 at 11:08:39 AM UTC-5, Jiacai Liu wrote:
>
> I  started learning clojure recently, and I am annoyed at the way to run 
> it (aka. lein run). why clojure script can't be run like python,ruby or 
> scala, like python .py
>

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