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, t
| 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 fu
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 rep
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"
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 w
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 def
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,
> 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 mo
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:
>
> f
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
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 for
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 :
> Hi everyone,
>
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, September
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 to upgrade and release my li
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 #{})]
#_=> (clojure.wal
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) a
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
Fro
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
https://groups.google.com/d/msg/clojure/mIlKaO
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 a
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 t
> 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 dependency on pedest
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:
https://www.eventbri
> 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 ha
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 a
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 `s/
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 has been quite stabl
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... Its almost like a w
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 appl
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 fails
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 test
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 exceptio
31 matches
Mail list logo