It's time to get Clojure ready for Google Summer of Code 2017!

Hello, all, There is just under a week left for us to apply to participate in Google Summer of Code 2017 as a mentoring organisation. This is a fantastic program that helps grow open source communities by paying students from around the world to work on

Re: Clojure.spec, maps, restrict valid keywords, easier way?

What would be the Right Way to deal with typos like (fetch-important-data {:encypt true}), where the :encrypt key is optional? Timothy mentions auto-complete, which is better than nothing but doesn't feel like a real solution (especially to those who don't use auto-complete). > On Feb 2, 2017,

Re: spec and à la carte conformance of map vals (and maybe a bug)

Sean, Thank you for sharing your input and code! Although I am interested by what you shared about your team’s usage of spec, I don’t believe it addresses my original problem of wanting to omit conformers when registering specs, yet later opt in to use a conformer when *consuming* the specs.

Re: Clojure.spec, maps, restrict valid keywords, easier way?

A good editor should auto-complete your keywords for you. Since using this feature in Cursive (same sort of thing is available in other editors) the cases where I've mis-spelled a keyword have dropped dramatically. It's a lot harder to mis-spell a keyword when you can just do: :egg/th and the rest

Re: Clojure.spec, maps, restrict valid keywords, easier way?

Ugh, don't do that. Introducing layers that add no value is a bad idea. Just use the keyword directly. -- 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

Re: Clojure.spec, maps, restrict valid keywords, easier way?

Keyword literals are inherently misspellable and trying to solve that problem with Spec does not really hit the nail on the head. But there is a solution: You do not have to use keyword literals very much! Instead of using, say, :egg/thunder throughout your program, def a var as :egg/thunder

Re: What’s next for Clojars in 2017?

How is your signing proposal different than the signing process already available in Maven and in use in (for example) Maven Central repository (and in use for Clojure itself and contrib releases)? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To

Re: Clojure.spec, maps, restrict valid keywords, easier way?

Hello Alex, The idea is (as I understand it) that every function should accept any map and pick keys which it understands. If some keys are critical, then they should be marked as such in the spec. Function might iterate over keys and raise an error if there are keys which belong to the

Re: (System/console) is nil?

(System/console) is only available when you run the compiled app or when using "lein trampoline run". On Thursday, February 2, 2017 at 11:48:14 AM UTC+13, Mark Reed wrote: > > Trying to write a CLI that will prompt for a password, and it's failing > because (System/console) always returns nil

What’s next for Clojars in 2017?

Hi folks In 2016, thanks to the generous sponsors on our Bountysource program and open source contributors, Clojars was able to: * Move our hosting from Linode to servers sponsored by Rackspace * Define the server on Rackspace with Ansible so it is easy to rebuild * Validate deploys are correct

Re: Clojure.spec, maps, restrict valid keywords, easier way?

On Thursday, February 2, 2017 at 10:07:31 AM UTC-5, Alex Miller wrote: > > We don't encourage you to do this, but I don't have an easier solution > than this. > Yes, and from the general standpoint of map handling I understand that. >From the standpoint of functions that take options and don't

Re: Documentation for namespace aliased keywords (particularly relevant for clojure.spec use)

On Wednesday, February 1, 2017 at 6:12:35 PM UTC-6, Dave Tenny wrote: > > Looking at the documentation for keywords under > https://clojure.org/reference/reader#_literals > there is no mention for the syntax for namespace aliased keywords, and > this is very important it you want to manage

Re: Clojure.spec, maps, restrict valid keywords, easier way?

We don't encourage you to do this, but I don't have an easier solution than this. On Thursday, February 2, 2017 at 7:05:37 AM UTC-6, Dave Tenny wrote: > > I want to specify in clojure spec that only declared keywords are > permitted in function calls. > This is to catch what are usually

Clojure.spec, maps, restrict valid keywords, easier way?

I want to specify in clojure spec that only declared keywords are permitted in function calls. This is to catch what are usually mis-spelled or mis-cased keywors passed via option maps in function calls. In the fdefs below, the second fdef will catch an invalid call, e.g. (f 1 {:a 2 :B 3}) but

Re: Documentation for namespace aliased keywords (particularly relevant for clojure.spec use)

I also have to wonder why keyword namespaces aren't processed like other symbol namespaces, that is, to interpret the namespace portion before a '/' with alias consideration. No doubt there's a good answer, but it seems anachronistic that keywords need special syntax contortions to recognize