Re: [core.spec] Stricter map validations?

Yesterday, I was checking a map of info submitted via web before putting its contents into a database. To prevent people from spamming the database, it's necessary to make sure there aren't additional keys thrown into the map. It would be nice to have a *convenient *way to express this in spec,

Re: [core.spec] Stricter map validations?

| we have experienced on virtually every consulting project we'd done including spec at Cognitect I'm sure this is sometimes true, but I can't think of how that would happen. Could you detail it a little? For me, whenever I needed to add more keys, it was simple to evolve the spec with the

Re: Help ship Clojure 1.9!

On Monday, October 2, 2017 at 3:16:55 PM UTC-5, Rob Nikander wrote: > > I get this when I switch from 1.8 to 1.9 beta, but maybe it's an issue > with the `core.match` library? > > WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: > clojure.tools.analyzer.utils, being

Re: Clojurecademy: Learning Clojure Made Easy

Terms of service prevent me from helping. I'm not willing to write things for the site and then have you own them like it says. That said, good luck. It does look guise nice from looking at your GitHub. Sam -- You received this message because you are subscribed to the Google Groups "Clojure"

Re: [core.spec] Stricter map validations?

On Monday, October 2, 2017 at 12:30:57 PM UTC-5, Leon Grapenthin wrote: > > I second this from my experience, using spec quite extensively since its > release. > > We already had some invalid data passing silently because of this. It can > easily happen if you have a typo in the spec. > > Also

Re: [core.spec] Stricter map validations?

On Monday, October 2, 2017 at 10:37:31 AM UTC-5, Yuri Govorushchenko wrote: > > Hi! > > I have some noobie questions for which I couldn't google the compelling > answers. > > 1) Is there any way to ensure that the keys I used in `s/keys` have the > associated specs defined? > Specs can be

Re: Clojurecademy: Learning Clojure Made Easy

Hi Bost, It's important for courses, I mean once your course get updated you will be notified, also you can continue to a course where you left off etc. Of course this site is not the only platform that you can learn Clojure, it just has different approach. Also it is not just learning Clojure,

Re: How to try/catch Let bindings?

> Even in an impure language such as Common Lisp we frown on such LET forms True, but as far as I know, in Common Lisp, the condition handler is always in scope of where the error happened, so I wouldn't face this problem. I also struggle to split this up into functions without making it even

Re: [core.spec] Stricter map validations?

Thank you the pointers! So far I ended up with writing a small `map` macro which is similar to `s/keys` but checks that keys are already in the registry: https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 On Monday, October 2, 2017 at 10:03:57 PM UTC+3, Beau Fabry wrote: > >

Re: How to try/catch Let bindings?

On Saturday, September 30, 2017 at 6:14:33 PM UTC-4, Didier wrote: > > I'm curious how others handle this use case, which I feel should be pretty > common. > > Given you have a series of business process steps, where the flow is too > complex for the arrow macros, and you also like to name the

Re: [core.spec] Stricter map validations?

I vote for strict validation also. It's a security threat on most applications not to strictly validate inputs and outputs. I would rather Clojure defaults to be secure, and people needing to implement their own less strict validation consciously. I'm afraid a lot of people will rely on spec

Re: Clojurecademy: Learning Clojure Made Easy

It looks like I can't learn clojure using your site unless I sign up with my email and such. Hmm... Until now I went pretty far with learning clojure without signing up anywhere. So what are your reasons for demanding a sign up? Thanks. 2017-10-02 18:47 GMT+02:00 Ertuğrul Çetin

Re: Help ship Clojure 1.9!

I get this when I switch from 1.8 to 1.9 beta, but maybe it's an issue with the `core.match` library? WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/boolean? Rob On Thursday,

Re: Help ship Clojure 1.9!

On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway wrote: > Hi David, > > Spec will be in alpha for a while. That is part of the point of it being a > separate library. Can you say more about what problems this is causing? > > Stu > > As a library maintainer, I am forced

Re: [core.spec] Stricter map validations?

fwiw, I vote for leaving it. It's extra flexibility and is afaict a fairly easy error to catch. Here's a function that I think should give you every qualified keyword that is used in a spec but that does not have a spec defined for it: boot.user=> (let [kws (atom #{})] #_=>

Re: Help ship Clojure 1.9!

Hello Stu, On 02/10/17 16:55, Stuart Halloway wrote: > Spec will be in alpha for a while. That is part of the point of it being > a separate library. Can you say more about what problems this is causing? I don’t have any stakes in this so it’s better if I withdraw my question. I was (still am)

RE: Help ship Clojure 1.9!

I would perhaps prevail on those library maintainers to clarify such statements…? 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

Re: Help ship Clojure 1.9!

Since spec is mainly a dependency of 1.9. to improve error reporting over 1.8 (correct me if I'm wrong), I'd like to point out this ticket again: https://dev.clojure.org/jira/browse/CLJ-2013 It solves what I determined the root cause of this report

Re: [core.spec] Stricter map validations?

I second this from my experience, using spec quite extensively since its release. We already had some invalid data passing silently because of this. It can easily happen if you have a typo in the spec. Also we never experienced benefits from being able to not spec keys required in s/keys. It

Clojurecademy: Learning Clojure Made Easy

Hi everyone, I've created site called Clojurecademy which seems like Codecademy for Clojure with powerful DSL to create courses. Feel free to provide feedback so we can improve Clojure adoption together! Link: https://clojurecademy.com -- You received this message because you are subscribed

Re: How to try/catch Let bindings?

> On Oct 1, 2017, at 9:21 PM, Didier wrote: > > I can't emphasize enough the utility of the interceptor chain pattern, as > employed heavily in pedestal. > > Interesting... Its almost like a workflow framework, but for simpler in code > workflows. I'm reluctant to have a

[CfP] :clojureD 2018

Dear Clojure-Community, The call for proposal for the next :clojureD is open: http://clojured.de/call-for-proposals/ We'd love to drown in your submissions so that we can deliver a conference programme just as excellent as 2017. :-) Oh, and ticket sale has started, too:

Re: [core.spec] Stricter map validations?

> 1) Is there any way to ensure that the keys I used in `s/keys` have the associated specs defined? I think you should be able to do this by writing a function that uses s/registry s/form and s/get-spec On Monday, October 2, 2017 at 8:37:31 AM UTC-7, Yuri Govorushchenko wrote: > > Hi! > > I

Re: Clarification on how Clojure libraries can be included in other software

My understanding from a general sense is that the EPL and GPL are incompatible, but I would suggest googling "epl gpl compatibility" and looking through some of those links for deeper analyses. On Friday, September 29, 2017 at 8:00:32 AM UTC-5, Jeronimo Pellegrini wrote: > > Hello, > > I have

[core.spec] Stricter map validations?

Hi! I have some noobie questions for which I couldn't google the compelling answers. 1) Is there any way to ensure that the keys I used in `s/keys` have the associated specs defined? At compile time or at least at runtime. Maybe via an additional library? I could imagine a macro (smt. like

Re: Help ship Clojure 1.9!

Hi David, Spec will be in alpha for a while. That is part of the point of it being a separate library. Can you say more about what problems this is causing? Stu On Sat, Sep 30, 2017 at 4:52 AM, David Bürgin wrote: > On 28/09/17 16:00, Stuart Halloway wrote: > > Clojure 1.9

Re: How to try/catch Let bindings?

Didier, I've done something similar a few times just using core.async -- no extra deps required ;-) d On 1 October 2017 at 23:21, Didier wrote: > I can't emphasize enough the utility of the interceptor chain pattern, as >> employed heavily in pedestal. >> > > Interesting...

Re: Clarification on how Clojure libraries can be included in other software

My reading of this is slightly different. As far as I can tell, it is possible to use Clojure within GPL libraries or applications, as Clojure would fall under the definition of "System Library" implementing the "Standard Interface". It's the same clause in GPL which allows, for example, GPL

Re: Is there a way to use spec/fdef function specs with clojure.test ?

I created https://dev.clojure.org/jira/browse/CLJ-2246 since I'm pretty sure there's a bug. On Monday, October 2, 2017 at 10:15:53 AM UTC+2, Khalid Jebbari wrote: > > Thanks for the link. It almost works ! The problem I have is that > stest/check returns a map with [:failure false] when it

Re: Is there a way to use spec/fdef function specs with clojure.test ?

Thanks for the link. It almost works ! The problem I have is that stest/check returns a map with [:failure false] when it fails, which seems weird and prevent stest/abbrev-result to add meaningful data to the reporting. Not sure if it's a bug in spec. Just to make things clear : - Passing

Re: How to try/catch Let bindings?

Hi Didier The interceptor pattern is pretty tiny, certainly small enough to copy from project to project if you wanted. You can see re-frame's implementation here: https://github.com/Day8/re-frame/blob/master/src/re_frame/interceptor.cljc which is only around 100 SLOC. That doesn't handle