Re: Clojure community survey 2016 results

[Mars0i]

Thanks for the survey!

I think the size distribution for the academic and government/military 
categories might be due to different respondents deciding how to 
disambiguate the question in different ways.  For example, everyone who 
works for the U.S. government works in an organization of the same size, 
but some might view their organization instead as a government department 
or an entity within a department, or a research team within a larger 
entity, etc.  So you might say that you work in an organization of size 
1-10 even if you work for the U.S. government.  If this is correct, the 
distribution for these categories isn't meaningful except as information 
about what people think of as their "organization" when they are forced to 
decide.

By contrast, in business, respondents might make similar decisions, but I 
suspect that's it's most common to view the organization as a "company", 
whether that's merely the smallest company for which one works, or instead 
a parent company that owns a smaller company for which one works, etc.  My 
intuition is that most people won't say they work for an organization of 
size 1-10 unless the smallest company they work for has no more than 10 
employees.

-- 
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: A problem about position of function used by binding

[guid]

 @Matching Socks, thank you very much.

-- 
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: A problem about position of function used by binding

[Matching Socks]

There is a manual! https://clojure.org/reference/documentation - see 
especially under Vars and Compilation.

-- 
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: When did this start? java.lang.IllegalAccessError cond* does not exist nippy

[Laws]

> I strongly recommend disabling aot compilation entirely, and if you are 
> going to aot compile, regularly delete target/.

Thank you. I've done so and that seems to help.




On Tuesday, February 7, 2017 at 5:44:50 PM UTC-5, red...@gmail.com wrote:
>
> definitely turn on 
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L81 
> :pedantic? :abort and resolve the issues lein deps :tree shows you. 
>
> given that you are aot compiling, but have implicit clean disabled, my 
> guess is you compiled the project once using a version of some library 
> where cond* was present and nippy could use it, made some changes to the 
> versions you were using, but didn't blow away the compiled class files, 
> so nippy was never compiled again, so there was never an error about the 
> missing cond* macro. So the error was never noticed when it was 
> introduced, and now some time later for whatever nippy is being compiled 
> again (fresh checkout, run lein clean, dunno) and versions conflict and 
> the macro is missing. 
>
> This is just a theory, could be all kinds of stuff. 
>
> I strongly recommend disabling aot compilation entirely, and if you are 
> going to aot compile, regularly delete target/. AOT compilation can be a 
> reliable source of bugs that break things at a large distance from the 
> cause. If you are aot compiling only to get a nice launcher for your 
> program, it is not worth it. I have a guide I am trying to contribute to 
> the official docs on how to launch a clojure program without using aot, 
> you can see it here 
>
> https://github.com/hiredman/clojure-site/blob/df56aef005d5d867213a51c2d3bbec5a86b0acad/content/guides/running_a_clojure_program.adoc,
>  
>
> https://github.com/clojure/clojure-site/pull/141 is the pr. 
>
> On 02/07/2017 02:32 PM, Laws wrote: 
> > Sorry about that. Here is the whole of my project.clj. It is a fairly 
> > small app. 
> > 
> > (defproject csv-to-dynamodb "1.0" 
> >   :description "Takes a Super company import file, of CSV format, and 
> > stores the data in DynamoDB, using the company_name as the sharding key" 
> >   :url "https://bitbucket.org/super/poi; 
> >   :license {:name "Copyright Super 2016" 
> > :url "http://www.super.com/"} 
> >   :dependencies [ 
> >  [org.clojure/clojure "1.7.0"] 
> >  [org.clojure/test.check "0.9.0"] 
> >  [org.clojure/data.json "0.2.6"] 
> >  [defun "0.3.0-RC1"] 
> >  [http-kit "2.2.0"] 
> >  [com.taoensso/timbre "4.3.1"] 
> >  [dire "0.5.4"] 
> >  [slingshot "0.12.2"] 
> >  [me.raynes/fs "1.4.4"] 
> >  [clj-stacktrace "0.2.7"] 
> >  [overtone/at-at "1.2.0"] 
> >  [com.taoensso/faraday "1.9.0"] 
> >  ] 
> >   :disable-implicit-clean true 
> >   :warn-on-reflection true 
> >   :source-paths  ["src/clojure"] 
> >   :java-source-paths ["src/java"] 
> >   :main csv-to-dynamodb.core 
> >   :aot :all 
> >   :jvm-opts ["-Xms50m" "-Xmx50m" "-XX:-UseCompressedOops"]) 
> > 
> > 
> > 
> > And this: 
> > 
> > lein deps :tree 
> > 
> > shows me: 
> > 
> > [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
> > [com.taoensso/encore "2.67.1"] 
> > 
> > 
> > The full output: 
> > 
> > lein deps :tree 
> > 
> > Possibly confusing dependencies found: 
> > 
> > [lein-checkall "0.1.1"] -> [jonase/eastwood "0.0.2"] -> 
> > [org.clojure/tools.namespace "0.1.2"] 
> >  overrides 
> > [lein-checkall "0.1.1"] -> [lein-kibit "0.0.8"] -> [jonase/kibit 
> > "0.0.8"] -> [org.clojure/tools.namespace "0.2.1"] 
> >  and 
> > [lein-checkall "0.1.1"] -> [lein-bikeshed "0.1.3"] -> 
> > [org.clojure/tools.namespace "0.2.3"] 
> > 
> > Consider using these exclusions: 
> > [lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]] 
> > [lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]] 
> > 
> > Possibly confusing dependencies found: 
> > [org.clojure/clojure "1.7.0"] 
> >  overrides 
> > [defun "0.3.0-RC1"] -> [org.clojure/clojure "1.8.0"] 
> > 
> > Consider using these exclusions: 
> > [defun "0.3.0-RC1" :exclusions [org.clojure/clojure]] 
> > 
> > [com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"] 
> >  overrides 
> > [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
> > [com.taoensso/encore "2.67.1"] 
> >  and 
> > [com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"] 
> > 
> > Consider using these exclusions: 
> > [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]] 
> > [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]] 
> > 
> > [com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"] -> 
> > [com.taoensso/truss "1.1.1"] 
> >  overrides 
> > [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
> > [com.taoensso/encore "2.67.1"] -> [com.taoensso/truss "1.3.3"] 
> >  and 
> > 

Re: When did this start? java.lang.IllegalAccessError cond* does not exist nippy

[Laws]

> I’ll note that if you’re using the com.taoensso libraries, it pays to 
make sure you keep them 
> all in sync because they change a lot

H. 

First of all, this worked, so you are right. Second of all, I am not sure I 
understand why this worked. 

I have run into this problem with Ruby and Bundler, when I have open-ended 
version ranges, such as: 

1.9 ~>

Meaning, any version over 1.9. That can lead to problems. 

But in my project.clj I have everything locked down to specific versions, 
so I don't see how version conflicts can arise. If it's the same versions 
now as a few months ago, I'm not clear how I got a version conflict. 

But it worked, so thank you. 






On Tuesday, February 7, 2017 at 5:58:02 PM UTC-5, Sean Corfield wrote:
>
> Kevin’s provided some solid advice on the AOT stuff.
>
>  
>
> I’ll note that if you’re using the com.taoensso libraries, it pays to make 
> sure you keep them all in sync because they change a lot (that’s both good 
> and bad), and it’s definitely worth using :exclusions fairly liberally to 
> avoid transient dependencies, so you have much more control over the actual 
> versions you pull in. We tend to exclude nearly all of the com.taoensso 
> libraries and then explicitly specify known compatible versions. At the 
> very least, you’re likely to need a more up to date timbre version.
>
>  
>
> 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 2/7/17, 2:32 PM, "Laws"  behalf of smashco...@gmail.com > wrote:
>
>  
>
> Sorry about that. Here is the whole of my project.clj. It is a fairly 
> small app. 
>
>  
>
> (defproject csv-to-dynamodb "1.0"
>
>   :description "Takes a Super company import file, of CSV format, and 
> stores the data in DynamoDB, using the company_name as the sharding key"
>
>   :url "https://bitbucket.org/super/poi;
>
>   :license {:name "Copyright Super 2016"
>
> :url "http://www.super.com/"}
>
>   :dependencies [
>
>  [org.clojure/clojure "1.7.0"]
>
>  [org.clojure/test.check "0.9.0"]
>
>  [org.clojure/data.json "0.2.6"]
>
>  [defun "0.3.0-RC1"]
>
>  [http-kit "2.2.0"]
>
>  [com.taoensso/timbre "4.3.1"]
>
>  [dire "0.5.4"]
>
>  [slingshot "0.12.2"]
>
>  [me.raynes/fs "1.4.4"]
>
>  [clj-stacktrace "0.2.7"] 
>
>  [overtone/at-at "1.2.0"]
>
>  [com.taoensso/faraday "1.9.0"]
>
>  ]
>
>   :disable-implicit-clean true
>
>   :warn-on-reflection true
>
>   :source-paths  ["src/clojure"]
>
>   :java-source-paths ["src/java"]
>
>   :main csv-to-dynamodb.core
>
>   :aot :all
>
>   :jvm-opts ["-Xms50m" "-Xmx50m" "-XX:-UseCompressedOops"])
>
>  
>
>  
>
>  
>
> And this:
>
>  
>
> lein deps :tree
>
>  
>
> shows me: 
>
>  
>
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
> [com.taoensso/encore "2.67.1"]
>
>  
>
>  
>
> The full output: 
>
>  
>
> lein deps :tree
>
>  
>
> Possibly confusing dependencies found:
>
>  
>
> [lein-checkall "0.1.1"] -> [jonase/eastwood "0.0.2"] -> 
> [org.clojure/tools.namespace "0.1.2"]
>
>  overrides
>
> [lein-checkall "0.1.1"] -> [lein-kibit "0.0.8"] -> [jonase/kibit "0.0.8"] 
> -> [org.clojure/tools.namespace "0.2.1"]
>
>  and
>
> [lein-checkall "0.1.1"] -> [lein-bikeshed "0.1.3"] -> 
> [org.clojure/tools.namespace "0.2.3"]
>
>  
>
> Consider using these exclusions:
>
> [lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]
>
> [lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]
>
>  
>
> Possibly confusing dependencies found:
>
> [org.clojure/clojure "1.7.0"]
>
>  overrides
>
> [defun "0.3.0-RC1"] -> [org.clojure/clojure "1.8.0"]
>
>  
>
> Consider using these exclusions:
>
> [defun "0.3.0-RC1" :exclusions [org.clojure/clojure]]
>
>  
>
> [com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"]
>
>  overrides
>
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
> [com.taoensso/encore "2.67.1"]
>
>  and
>
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"]
>
>  
>
> Consider using these exclusions:
>
> [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]
>
> [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]
>
>  
>
> [com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"] -> 
> [com.taoensso/truss "1.1.1"]
>
>  overrides
>
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
> [com.taoensso/encore "2.67.1"] -> [com.taoensso/truss "1.3.3"]
>
>  and
>
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"] -> 
> [com.taoensso/truss "1.3.3"]
>
>  
>
> Consider using these exclusions:
>
> [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/truss]]
>
> 

Re: When did this start? java.lang.IllegalAccessError cond* does not exist nippy

[Sean Corfield]

Kevin’s provided some solid advice on the AOT stuff.

 

I’ll note that if you’re using the com.taoensso libraries, it pays to make sure 
you keep them all in sync because they change a lot (that’s both good and bad), 
and it’s definitely worth using :exclusions fairly liberally to avoid transient 
dependencies, so you have much more control over the actual versions you pull 
in. We tend to exclude nearly all of the com.taoensso libraries and then 
explicitly specify known compatible versions. At the very least, you’re likely 
to need a more up to date timbre version.

 

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 2/7/17, 2:32 PM, "Laws"  wrote:

 

Sorry about that. Here is the whole of my project.clj. It is a fairly small 
app. 

 

(defproject csv-to-dynamodb "1.0"

  :description "Takes a Super company import file, of CSV format, and stores 
the data in DynamoDB, using the company_name as the sharding key"

  :url "https://bitbucket.org/super/poi;

  :license {:name "Copyright Super 2016"

:url "http://www.super.com/"}

  :dependencies [

 [org.clojure/clojure "1.7.0"]

 [org.clojure/test.check "0.9.0"]

 [org.clojure/data.json "0.2.6"]

 [defun "0.3.0-RC1"]

 [http-kit "2.2.0"]

 [com.taoensso/timbre "4.3.1"]

 [dire "0.5.4"]

 [slingshot "0.12.2"]

 [me.raynes/fs "1.4.4"]

 [clj-stacktrace "0.2.7"] 

 [overtone/at-at "1.2.0"]

 [com.taoensso/faraday "1.9.0"]

 ]

  :disable-implicit-clean true

  :warn-on-reflection true

  :source-paths  ["src/clojure"]

  :java-source-paths ["src/java"]

  :main csv-to-dynamodb.core

  :aot :all

  :jvm-opts ["-Xms50m" "-Xmx50m" "-XX:-UseCompressedOops"])

 

 

 

And this:

 

lein deps :tree

 

shows me: 

 

[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[com.taoensso/encore "2.67.1"]

 

 

The full output: 

 

lein deps :tree

 

Possibly confusing dependencies found:

 

[lein-checkall "0.1.1"] -> [jonase/eastwood "0.0.2"] -> 
[org.clojure/tools.namespace "0.1.2"]

 overrides

[lein-checkall "0.1.1"] -> [lein-kibit "0.0.8"] -> [jonase/kibit "0.0.8"] -> 
[org.clojure/tools.namespace "0.2.1"]

 and

[lein-checkall "0.1.1"] -> [lein-bikeshed "0.1.3"] -> 
[org.clojure/tools.namespace "0.2.3"]

 

Consider using these exclusions:

[lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]

[lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]

 

Possibly confusing dependencies found:

[org.clojure/clojure "1.7.0"]

 overrides

[defun "0.3.0-RC1"] -> [org.clojure/clojure "1.8.0"]

 

Consider using these exclusions:

[defun "0.3.0-RC1" :exclusions [org.clojure/clojure]]

 

[com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"]

 overrides

[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[com.taoensso/encore "2.67.1"]

 and

[com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"]

 

Consider using these exclusions:

[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]

[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]

 

[com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"] -> 
[com.taoensso/truss "1.1.1"]

 overrides

[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[com.taoensso/encore "2.67.1"] -> [com.taoensso/truss "1.3.3"]

 and

[com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"] -> 
[com.taoensso/truss "1.3.3"]

 

Consider using these exclusions:

[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/truss]]

[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/truss]]

 

[me.raynes/fs "1.4.4"] -> [org.apache.commons/commons-compress "1.4"] -> 
[org.tukaani/xz "1.0"]

 overrides

[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[org.tukaani/xz "1.5"]

 

Consider using these exclusions:

[com.taoensso/faraday "1.9.0" :exclusions [org.tukaani/xz]]

 

 [clj-stacktrace "0.2.7"]

 [clojure-complete "0.2.4" :exclusions [[org.clojure/clojure]]]

 [com.taoensso/faraday "1.9.0"]

   [com.amazonaws/aws-java-sdk-dynamodb "1.10.49" :exclusions [[joda-time]]]

 [com.amazonaws/aws-java-sdk-core "1.10.49"]

   [com.fasterxml.jackson.core/jackson-databind "2.5.3"]

 [com.fasterxml.jackson.core/jackson-annotations "2.5.0"]

 [com.fasterxml.jackson.core/jackson-core "2.5.3"]

   [commons-logging "1.1.3"]

   [org.apache.httpcomponents/httpclient "4.3.6"]

 [commons-codec "1.6"]

 [org.apache.httpcomponents/httpcore "4.3.3"]

 [com.amazonaws/aws-java-sdk-s3 "1.10.49"]

   [com.amazonaws/aws-java-sdk-kms 

Re: When did this start? java.lang.IllegalAccessError cond* does not exist nippy

[Kevin Downey]

definitely turn on
https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L81
:pedantic? :abort and resolve the issues lein deps :tree shows you.

given that you are aot compiling, but have implicit clean disabled, my
guess is you compiled the project once using a version of some library
where cond* was present and nippy could use it, made some changes to the
versions you were using, but didn't blow away the compiled class files,
so nippy was never compiled again, so there was never an error about the
missing cond* macro. So the error was never noticed when it was
introduced, and now some time later for whatever nippy is being compiled
again (fresh checkout, run lein clean, dunno) and versions conflict and
the macro is missing.

This is just a theory, could be all kinds of stuff.

I strongly recommend disabling aot compilation entirely, and if you are
going to aot compile, regularly delete target/. AOT compilation can be a
reliable source of bugs that break things at a large distance from the
cause. If you are aot compiling only to get a nice launcher for your
program, it is not worth it. I have a guide I am trying to contribute to
the official docs on how to launch a clojure program without using aot,
you can see it here
https://github.com/hiredman/clojure-site/blob/df56aef005d5d867213a51c2d3bbec5a86b0acad/content/guides/running_a_clojure_program.adoc,
https://github.com/clojure/clojure-site/pull/141 is the pr.

On 02/07/2017 02:32 PM, Laws wrote:
> Sorry about that. Here is the whole of my project.clj. It is a fairly
> small app. 
> 
> (defproject csv-to-dynamodb "1.0"
>   :description "Takes a Super company import file, of CSV format, and
> stores the data in DynamoDB, using the company_name as the sharding key"
>   :url "https://bitbucket.org/super/poi;
>   :license {:name "Copyright Super 2016"
> :url "http://www.super.com/"}
>   :dependencies [
>  [org.clojure/clojure "1.7.0"]
>  [org.clojure/test.check "0.9.0"]
>  [org.clojure/data.json "0.2.6"]
>  [defun "0.3.0-RC1"]
>  [http-kit "2.2.0"]
>  [com.taoensso/timbre "4.3.1"]
>  [dire "0.5.4"]
>  [slingshot "0.12.2"]
>  [me.raynes/fs "1.4.4"]
>  [clj-stacktrace "0.2.7"] 
>  [overtone/at-at "1.2.0"]
>  [com.taoensso/faraday "1.9.0"]
>  ]
>   :disable-implicit-clean true
>   :warn-on-reflection true
>   :source-paths  ["src/clojure"]
>   :java-source-paths ["src/java"]
>   :main csv-to-dynamodb.core
>   :aot :all
>   :jvm-opts ["-Xms50m" "-Xmx50m" "-XX:-UseCompressedOops"])
> 
> 
> 
> And this:
> 
> lein deps :tree
> 
> shows me: 
> 
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] ->
> [com.taoensso/encore "2.67.1"]
> 
> 
> The full output: 
> 
> lein deps :tree
> 
> Possibly confusing dependencies found:
> 
> [lein-checkall "0.1.1"] -> [jonase/eastwood "0.0.2"] ->
> [org.clojure/tools.namespace "0.1.2"]
>  overrides
> [lein-checkall "0.1.1"] -> [lein-kibit "0.0.8"] -> [jonase/kibit
> "0.0.8"] -> [org.clojure/tools.namespace "0.2.1"]
>  and
> [lein-checkall "0.1.1"] -> [lein-bikeshed "0.1.3"] ->
> [org.clojure/tools.namespace "0.2.3"]
> 
> Consider using these exclusions:
> [lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]
> [lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]
> 
> Possibly confusing dependencies found:
> [org.clojure/clojure "1.7.0"]
>  overrides
> [defun "0.3.0-RC1"] -> [org.clojure/clojure "1.8.0"]
> 
> Consider using these exclusions:
> [defun "0.3.0-RC1" :exclusions [org.clojure/clojure]]
> 
> [com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"]
>  overrides
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] ->
> [com.taoensso/encore "2.67.1"]
>  and
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"]
> 
> Consider using these exclusions:
> [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]
> [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]
> 
> [com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"] ->
> [com.taoensso/truss "1.1.1"]
>  overrides
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] ->
> [com.taoensso/encore "2.67.1"] -> [com.taoensso/truss "1.3.3"]
>  and
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"] ->
> [com.taoensso/truss "1.3.3"]
> 
> Consider using these exclusions:
> [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/truss]]
> [com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/truss]]
> 
> [me.raynes/fs "1.4.4"] -> [org.apache.commons/commons-compress "1.4"] ->
> [org.tukaani/xz "1.0"]
>  overrides
> [com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] ->
> [org.tukaani/xz "1.5"]
> 
> Consider using these exclusions:
> [com.taoensso/faraday "1.9.0" :exclusions [org.tukaani/xz]]
> 

Re: When did this start? java.lang.IllegalAccessError cond* does not exist nippy

[Laws]

Sorry about that. Here is the whole of my project.clj. It is a fairly small 
app. 

(defproject csv-to-dynamodb "1.0"
  :description "Takes a Super company import file, of CSV format, and 
stores the data in DynamoDB, using the company_name as the sharding key"
  :url "https://bitbucket.org/super/poi;
  :license {:name "Copyright Super 2016"
:url "http://www.super.com/"}
  :dependencies [
 [org.clojure/clojure "1.7.0"]
 [org.clojure/test.check "0.9.0"]
 [org.clojure/data.json "0.2.6"]
 [defun "0.3.0-RC1"]
 [http-kit "2.2.0"]
 [com.taoensso/timbre "4.3.1"]
 [dire "0.5.4"]
 [slingshot "0.12.2"]
 [me.raynes/fs "1.4.4"]
 [clj-stacktrace "0.2.7"] 
 [overtone/at-at "1.2.0"]
 [com.taoensso/faraday "1.9.0"]
 ]
  :disable-implicit-clean true
  :warn-on-reflection true
  :source-paths  ["src/clojure"]
  :java-source-paths ["src/java"]
  :main csv-to-dynamodb.core
  :aot :all
  :jvm-opts ["-Xms50m" "-Xmx50m" "-XX:-UseCompressedOops"])



And this:

lein deps :tree

shows me: 

[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[com.taoensso/encore "2.67.1"]


The full output: 

lein deps :tree

Possibly confusing dependencies found:

[lein-checkall "0.1.1"] -> [jonase/eastwood "0.0.2"] -> 
[org.clojure/tools.namespace "0.1.2"]
 overrides
[lein-checkall "0.1.1"] -> [lein-kibit "0.0.8"] -> [jonase/kibit "0.0.8"] 
-> [org.clojure/tools.namespace "0.2.1"]
 and
[lein-checkall "0.1.1"] -> [lein-bikeshed "0.1.3"] -> 
[org.clojure/tools.namespace "0.2.3"]

Consider using these exclusions:
[lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]
[lein-checkall "0.1.1" :exclusions [org.clojure/tools.namespace]]

Possibly confusing dependencies found:
[org.clojure/clojure "1.7.0"]
 overrides
[defun "0.3.0-RC1"] -> [org.clojure/clojure "1.8.0"]

Consider using these exclusions:
[defun "0.3.0-RC1" :exclusions [org.clojure/clojure]]

[com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"]
 overrides
[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[com.taoensso/encore "2.67.1"]
 and
[com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"]

Consider using these exclusions:
[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]
[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/encore]]

[com.taoensso/timbre "4.3.1"] -> [com.taoensso/encore "2.36.2"] -> 
[com.taoensso/truss "1.1.1"]
 overrides
[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[com.taoensso/encore "2.67.1"] -> [com.taoensso/truss "1.3.3"]
 and
[com.taoensso/faraday "1.9.0"] -> [com.taoensso/encore "2.67.2"] -> 
[com.taoensso/truss "1.3.3"]

Consider using these exclusions:
[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/truss]]
[com.taoensso/faraday "1.9.0" :exclusions [com.taoensso/truss]]

[me.raynes/fs "1.4.4"] -> [org.apache.commons/commons-compress "1.4"] -> 
[org.tukaani/xz "1.0"]
 overrides
[com.taoensso/faraday "1.9.0"] -> [com.taoensso/nippy "2.12.0"] -> 
[org.tukaani/xz "1.5"]

Consider using these exclusions:
[com.taoensso/faraday "1.9.0" :exclusions [org.tukaani/xz]]

 [clj-stacktrace "0.2.7"]
 [clojure-complete "0.2.4" :exclusions [[org.clojure/clojure]]]
 [com.taoensso/faraday "1.9.0"]
   [com.amazonaws/aws-java-sdk-dynamodb "1.10.49" :exclusions [[joda-time]]]
 [com.amazonaws/aws-java-sdk-core "1.10.49"]
   [com.fasterxml.jackson.core/jackson-databind "2.5.3"]
 [com.fasterxml.jackson.core/jackson-annotations "2.5.0"]
 [com.fasterxml.jackson.core/jackson-core "2.5.3"]
   [commons-logging "1.1.3"]
   [org.apache.httpcomponents/httpclient "4.3.6"]
 [commons-codec "1.6"]
 [org.apache.httpcomponents/httpcore "4.3.3"]
 [com.amazonaws/aws-java-sdk-s3 "1.10.49"]
   [com.amazonaws/aws-java-sdk-kms "1.10.49"]
   [com.taoensso/nippy "2.12.0"]
 [net.jpountz.lz4/lz4 "1.3"]
 [org.iq80.snappy/snappy "0.4"]
   [joda-time "2.9.4"]
 [com.taoensso/timbre "4.3.1"]
   [com.taoensso/encore "2.36.2"]
 [com.taoensso/truss "1.1.1"]
 [org.clojure/tools.reader "0.10.0"]
   [io.aviso/pretty "0.1.23"]
 [defun "0.3.0-RC1"]
   [org.clojure/core.match "0.3.0-alpha4"]
 [org.clojure/tools.analyzer.jvm "0.6.5"]
   [org.clojure/core.memoize "0.5.6"]
 [org.clojure/core.cache "0.6.3"]
   [org.clojure/data.priority-map "0.0.2"]
   [org.clojure/tools.analyzer "0.6.4"]
   [org.ow2.asm/asm-all "4.2"]
   [org.clojure/tools.macro "0.1.2"]
 [dire "0.5.4"]
   [org.clojure/core.incubator "0.1.3"]
   [robert/hooke "1.3.0"]
 [expectations "2.0.9"]
   [junit "4.8.1"]
 [http-kit "2.2.0"]
 [me.raynes/fs "1.4.4"]
   [org.apache.commons/commons-compress "1.4"]
 [org.tukaani/xz "1.0"]
 [org.clojure/clojure "1.7.0"]
 [org.clojure/data.json "0.2.6"]
 

Re: When did this start? java.lang.IllegalAccessError cond* does not exist nippy

[Sean Corfield]

You’ll need to provide a bit more detail than that – what are your project’s 
dependencies, for example?

 

(if you’re depending on any snapshots or generic “RELEASE” / “LATEST” versions, 
those could give you different versions)

 

Sean

 

On 2/7/17, 1:31 PM, "Laws"  wrote:

 

Two months ago I could run "lein uberjar" and my project compiled. Then I had 
to focus on other things for 2 months. Then today I come back to it, change one 
line of code, and run "lein uberjar". I get:

 

java.lang.IllegalAccessError: cond* does not exist, compiling:(nippy.clj:1:1)

Exception in thread "main" java.lang.IllegalAccessError: cond* does not exist, 
compiling:(nippy.clj:1:1)

    at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3628)

    at clojure.lang.Compiler.compile1(Compiler.java:7323)

    at clojure.lang.Compiler.compile1(Compiler.java:7313)

    at clojure.lang.Compiler.compile(Compiler.java:7390)

    at clojure.lang.RT.compile(RT.java:399)

    at clojure.lang.RT.load(RT.java:444)

 

Uh, what? Did something with Nippy change? Clojars? 

 

 

-- 

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

When did this start? java.lang.IllegalAccessError cond* does not exist nippy

[Laws]

Two months ago I could run "lein uberjar" and my project compiled. Then I 
had to focus on other things for 2 months. Then today I come back to it, 
change one line of code, and run "lein uberjar". I get:

java.lang.IllegalAccessError: cond* does not exist, 
compiling:(nippy.clj:1:1)
Exception in thread "main" java.lang.IllegalAccessError: cond* does not 
exist, compiling:(nippy.clj:1:1)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3628)
at clojure.lang.Compiler.compile1(Compiler.java:7323)
at clojure.lang.Compiler.compile1(Compiler.java:7313)
at clojure.lang.Compiler.compile(Compiler.java:7390)
at clojure.lang.RT.compile(RT.java:399)
at clojure.lang.RT.load(RT.java:444)

Uh, what? Did something with Nippy change? Clojars? 


-- 
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 community survey 2016 results

[Sean Corfield]

On 2/7/17, 11:01 AM, "Erik Assum"  wrote:
> You say 2,420 people took the survey this year. How does that compare to 
> previous years?
 
The blog post says “This year we held steady in our response rate as 2,420 of 
you took the time and effort to weigh in on your experience” and 
http://blog.cognitect.com/blog/2016/1/28/state-of-clojure-2015-survey-results 
shows 2,445 responses last year.

Previous year was 1,339.

Sean




-- 
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 community survey 2016 results

[Erik Assum]

Thanks!

You say 2,420 people took the survey this year. How does that compare to 
previous years?

Erik. 
-- 
i farta

> Den 7. feb. 2017 kl. 19.05 skrev Alex Miller :
> 
> Results and analysis are available here:
> 
> http://blog.cognitect.com/blog/2017/1/31/state-of-clojure-2016-results
> 
> Many thanks to all that responded!
> 
> 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.

-- 
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 community survey 2016 results

[Alex Miller]

Results and analysis are available here:

http://blog.cognitect.com/blog/2017/1/31/state-of-clojure-2016-results

Many thanks to all that responded!

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: clojure.spec s/keys map key with alternative definitions in same namespace

[Dave Tenny]

>From my perspective, there are two specs.  I'm not trying to mash them
together, however I would like to use the appropriate spec with the same
keyword in maps, in different contexts.

It wouldn't be an issue if the contexts were in separate namespaces.  It's
only an issue because the two specs are in the same namespace, and I want
to use them in different places with the same map key.

(Or so it seems to me, still wrapping my head around spec).

On Tue, Feb 7, 2017 at 11:10 AM, Alex Miller  wrote:

> Spec names are intended to have enduring global semantics. So the notion
> of the same spec name having different semantics at different times seems
> to be at odds with that.
>
> In general, it's often helpful to think about all the possible values that
> an attribute will have - that's the true spec. In this case, it seems like
> what you have for ::coercible-job-type is the true spec - it can be either
> a string or other named value.
>
> And then think about the places where you need to add additional
> constraints to your ::job-record spec to narrow it. Like maybe here:
>
> (s/fdef ... :ret (s/and ::job-record #(-> % ::job-type string?)))
>
> You're on the brink of suggesting subtypes and covariant / contravariants,
> etc and that's a path spec is not going down.
>
>
> On Tuesday, February 7, 2017 at 9:40:24 AM UTC-6, Dave Tenny wrote:
>>
>> Let's say I have these definitions for a "job" record I'm managing,
>> perhaps in a database.
>>
>> (s/def ::job-status #{:in-progress :completed})
>> (s/def ::user-id (s/and integer? #(>= % 0)))
>> (s/def ::job-id integer?)
>>
>> (s/def ::coercible-job-type (s/and named? #(not (empty? (name %)
>> (s/def ::job-type (s/and string? #(not (empty? %
>>
>> So we have a job status which can be any of a limited set of keywords,
>> integer user and job ID's.
>>
>> Then there's job type and my issue.  Depending on the context I want
>> either to insist that job type will be purely a non-empty string, or that
>> it may also be a 'named?' object,
>> i.e. something for which the clojure.core/name function will work.
>>
>> If I'm just returning a pure job record, my definition would look like
>> this:
>>
>> (s/def ::job-record
>>   (s/keys :req-un [::job-id ::user-id ::job-type ::job-status]))
>>
>> So a map with all those keys and type definitions. And that's great.  I
>> define functions that return these
>> maps and so there's an (s/fdef ... :ret ::job-record).
>>
>> Now let's say I have an update! function that can take a map of optional
>> fields and update the record in the database with the fields that were
>> specified.
>>
>> (s/def ::field-options (s/keys :opt-un [::job-id ::user-id ::job-type
>> ::job-status]))
>> (s/fdef update! :args (s/cat ::field-map ::field-options) ...)
>> (defn update! [field-map] ... (:job-type field-map) ...)
>>
>> So far, so good. I have a parameter 'field-map' that can take optional
>> map keys, validate map arguments if the testing instrumentation is enabled,
>> etc.
>>
>> Here is my problem.  There appears to be no way for me to define, in this
>> namespace, map specs with a :job-type key, but that will have
>> :coercible-job-type semantics,
>> for my update! function. Or at least I don't see an easy way short of
>> writing a function to do everything that the existing machinery is doing
>> with respect to key and value validation,
>> which is a lot of work to handle this tiny thing, basically the ability
>> to have map keys and spec semantics bound to different names in s/keys
>> specs.
>>
>> For example, the following pseudo-spec might let me define a map key
>> :job-type whose semantics were specified by the ::coercible-job-type
>> definition.
>> Or inlining of definitions which the spec guide says was omitted on
>> purpose.
>>
>> (s/def ::field-map (s/keys :opt-un [... [::coercible-job-type :as ::job-
>> type]]))
>>
>> I want the map key to be ":job-type", but the clojure.spec semantics for
>> that field, *in selective module definitions*, to have ::coercible-job-type
>> behavior.
>>
>> So... am I missing something?
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/ioR4875rRxU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google

Re: clojure.spec s/keys map key with alternative definitions in same namespace

[Alex Miller]

Spec names are intended to have enduring global semantics. So the notion of 
the same spec name having different semantics at different times seems to 
be at odds with that.

In general, it's often helpful to think about all the possible values that 
an attribute will have - that's the true spec. In this case, it seems like 
what you have for ::coercible-job-type is the true spec - it can be either 
a string or other named value.

And then think about the places where you need to add additional 
constraints to your ::job-record spec to narrow it. Like maybe here:

(s/fdef ... :ret (s/and ::job-record #(-> % ::job-type string?)))

You're on the brink of suggesting subtypes and covariant / contravariants, 
etc and that's a path spec is not going down. 


On Tuesday, February 7, 2017 at 9:40:24 AM UTC-6, Dave Tenny wrote:
>
> Let's say I have these definitions for a "job" record I'm managing, 
> perhaps in a database.
>
> (s/def ::job-status #{:in-progress :completed})
> (s/def ::user-id (s/and integer? #(>= % 0)))
> (s/def ::job-id integer?)
>
> (s/def ::coercible-job-type (s/and named? #(not (empty? (name %)
> (s/def ::job-type (s/and string? #(not (empty? %
>
> So we have a job status which can be any of a limited set of keywords,
> integer user and job ID's.  
>
> Then there's job type and my issue.  Depending on the context I want 
> either to insist that job type will be purely a non-empty string, or that 
> it may also be a 'named?' object, 
> i.e. something for which the clojure.core/name function will work.
>
> If I'm just returning a pure job record, my definition would look like 
> this:
>
> (s/def ::job-record 
>   (s/keys :req-un [::job-id ::user-id ::job-type ::job-status]))
>
> So a map with all those keys and type definitions. And that's great.  I 
> define functions that return these
> maps and so there's an (s/fdef ... :ret ::job-record).
>
> Now let's say I have an update! function that can take a map of optional 
> fields and update the record in the database with the fields that were 
> specified.
>
> (s/def ::field-options (s/keys :opt-un [::job-id ::user-id ::job-type 
> ::job-status]))
> (s/fdef update! :args (s/cat ::field-map ::field-options) ...)
> (defn update! [field-map] ... (:job-type field-map) ...)
>
> So far, so good. I have a parameter 'field-map' that can take optional map 
> keys, validate map arguments if the testing instrumentation is enabled, etc.
>
> Here is my problem.  There appears to be no way for me to define, in this 
> namespace, map specs with a :job-type key, but that will have 
> :coercible-job-type semantics,
> for my update! function. Or at least I don't see an easy way short of 
> writing a function to do everything that the existing machinery is doing 
> with respect to key and value validation,
> which is a lot of work to handle this tiny thing, basically the ability to 
> have map keys and spec semantics bound to different names in s/keys specs.
>
> For example, the following pseudo-spec might let me define a map key 
> :job-type whose semantics were specified by the ::coercible-job-type 
> definition.
> Or inlining of definitions which the spec guide says was omitted on 
> purpose.
>
> (s/def ::field-map (s/keys :opt-un [... [::coercible-job-type :as ::job-
> type]]))
>
> I want the map key to be ":job-type", but the clojure.spec semantics for 
> that field, *in selective module definitions*, to have ::coercible-job-type 
> behavior.
>
> So... am I missing something?
>
>

-- 
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: named? predicate?

[Alex Miller]

In 1.9 there is a new ident? function which covers keywords and symbols. If 
you want to include strings, you would have to make that yourself though. 

On Tuesday, February 7, 2017 at 9:44:55 AM UTC-6, Dave Tenny wrote:
>
> I've occasionally wanted this and haven't found it.
>
> (defn named?
>   "True if object is compatible with the 'name' function.
>   There must be a clojure built-in to do this but I haven't figured it out 
> yet."
>   [x]
>   (or (string? x)
>   (keyword? x)
>   (symbol? x)))
>
>
> Note that simply doing (instance? clojure.lang.Named x) won't work for 
> strings, but the (name) function does.
>
> Anyway, I'm thinking there's a built in way to do this without defining 
> the above function.  Suggestions?
>
> My use case is simply that I want to call the name function for objects 
> that support it in a translation function.
>

-- 
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 s/keys map key with alternative definitions in same namespace

[Dave Tenny]

Let's say I have these definitions for a "job" record I'm managing, perhaps 
in a database.

(s/def ::job-status #{:in-progress :completed})
(s/def ::user-id (s/and integer? #(>= % 0)))
(s/def ::job-id integer?)

(s/def ::coercible-job-type (s/and named? #(not (empty? (name %)
(s/def ::job-type (s/and string? #(not (empty? %

So we have a job status which can be any of a limited set of keywords,
integer user and job ID's.  

Then there's job type and my issue.  Depending on the context I want either 
to insist that job type will be purely a non-empty string, or that it may 
also be a 'named?' object, 
i.e. something for which the clojure.core/name function will work.

If I'm just returning a pure job record, my definition would look like this:

(s/def ::job-record 
  (s/keys :req-un [::job-id ::user-id ::job-type ::job-status]))

So a map with all those keys and type definitions. And that's great.  I 
define functions that return these
maps and so there's an (s/fdef ... :ret ::job-record).

Now let's say I have an update! function that can take a map of optional 
fields and update the record in the database with the fields that were 
specified.

(s/def ::field-options (s/keys :opt-un [::job-id ::user-id ::job-type 
::job-status]))
(s/fdef update! :args (s/cat ::field-map ::field-options) ...)
(defn update! [field-map] ... (:job-type field-map) ...)

So far, so good. I have a parameter 'field-map' that can take optional map 
keys, validate map arguments if the testing instrumentation is enabled, etc.

Here is my problem.  There appears to be no way for me to define, in this 
namespace, map specs with a :job-type key, but that will have 
:coercible-job-type semantics,
for my update! function. Or at least I don't see an easy way short of 
writing a function to do everything that the existing machinery is doing 
with respect to key and value validation,
which is a lot of work to handle this tiny thing, basically the ability to 
have map keys and spec semantics bound to different names in s/keys specs.

For example, the following pseudo-spec might let me define a map key 
:job-type whose semantics were specified by the ::coercible-job-type 
definition.
Or inlining of definitions which the spec guide says was omitted on purpose.

(s/def ::field-map (s/keys :opt-un [... [::coercible-job-type :as ::job-type
]]))

I want the map key to be ":job-type", but the clojure.spec semantics for 
that field, *in selective module definitions*, to have ::coercible-job-type 
behavior.

So... am I missing something?

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

named? predicate?

[Dave Tenny]

I've occasionally wanted this and haven't found it.

(defn named?
  "True if object is compatible with the 'name' function.
  There must be a clojure built-in to do this but I haven't figured it out 
yet."
  [x]
  (or (string? x)
  (keyword? x)
  (symbol? x)))


Note that simply doing (instance? clojure.lang.Named x) won't work for 
strings, but the (name) function does.

Anyway, I'm thinking there's a built in way to do this without defining the 
above function.  Suggestions?

My use case is simply that I want to call the name function for objects 
that support it in a translation function.

-- 
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, maps, restrict valid keywords, easier way?

[Erik Assum]

Bruce Hauman has done some work in this area both in figwheel and in a branch 
of leiningen. 

Basically, if I understand correctly, he looks for misspelled keywords in 
configuration maps by taking the levenstein distance between expected, valid, 
keywords and non-matching keywords in the configuration. 

Erik. 
-- 
i farta

> Den 4. feb. 2017 kl. 12.48 skrev Dave Tenny :
> 
> I have found eastwood to be useful for a number of things, however on keyword 
> checking it failed terribly on our code base, though perhaps there have been 
> updates since I last tried it.
> 
> Thanks for the suggestion though.
> 
>> On Friday, February 3, 2017 at 7:26:01 PM UTC-5, Ben Brinckerhoff wrote:
>> The eastwood linter can also be configured to look for possibly misspelled 
>> keyword typos
>> 
>> https://github.com/jonase/eastwood#keyword-typos
 
> 
> -- 
> 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.