This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-21
Channels
- # admin-announcements (2)
- # aws-lambda (2)
- # beginners (26)
- # boot (179)
- # cider (36)
- # cljs-dev (118)
- # cljsrn (23)
- # clojure (150)
- # clojure-android (1)
- # clojure-austin (7)
- # clojure-austria (3)
- # clojure-canada (1)
- # clojure-dev (7)
- # clojure-dusseldorf (4)
- # clojure-germany (3)
- # clojure-greece (34)
- # clojure-nl (4)
- # clojure-quebec (9)
- # clojure-russia (30)
- # clojure-spec (38)
- # clojure-uk (3)
- # clojurescript (46)
- # clr (1)
- # core-async (2)
- # css (2)
- # cursive (17)
- # datomic (12)
- # devcards (8)
- # dirac (1)
- # docker (2)
- # hoplon (216)
- # jobs (2)
- # kekkonen (1)
- # lein-figwheel (18)
- # leiningen (2)
- # luminus (1)
- # mount (4)
- # off-topic (2)
- # om (15)
- # onyx (1)
- # parinfer (1)
- # pedestal (2)
- # planck (26)
- # reagent (98)
- # spacemacs (6)
- # specter (19)
- # spirituality-ethics (54)
- # untangled (22)
- # vim (24)
- # yada (4)
@borkdude: nil is the empty sequence 🙂 I think it should be possible to write a spec for get-in
.
Is there any chance of opts being added to clojure.spec.test/run-(all-)tests
? I have a couple of functions that exceed the GC limit if I run 100 tests against them. 25 or 50 is fine, so I'd like to set :num-tests
globally instead of having to use check-var
for every single function I want to test.
@jannis why are your functions are so memory hungry? do they have side effects or are the inputs to big? for the latter, I would rather optimize the generators.
That's the function: https://github.com/workfloapp/macros/blob/jannis/clojure-spec/src/main/workflo/macros/props.cljc#L324 and this is the generator: https://github.com/workfloapp/macros/blob/jannis/clojure-spec/src/main/workflo/macros/props.cljc#L90
such-thats are a good thing to look out for.
I have overriden almost all generators because my data specs seem to be too complex to use the default generators.
One thing we ran into was the following:
If there's a significant distance between your generator and your validation predicate that generator tends to perform poorly.
Of course, that makes sense. That's why I overrode most of the generators so that they don't have to be tried a lot to have conforming data generated.
I haven't tried it, but does increasing the heap size help?
Without knowing much about it, GC limit exceeded to me sounds like it's generating too much data too quickly for GC to catch up. Let me re-run the tests with a heap size of 2GB.
GC Limit exceeded usually means that the ratio of GC pauses to 'useful' computation is quite high.
So more heap space can reduce pauses.
It's also a test performance issue by the way. With 100 tests, that single function test runs for ~5-10 minutes until it errors out with the GC limit. I'm aiming for a fast test suite, so being able to reduce the number of tests globally - or for this function - would help.
Increasing the heap size avoids it failing after 5-10 minutes. Instead it has now been running for more than half an hour. 😉
@jannis I have you source code open. But I never used boot before and I’m using cursive - so its not so easy for me to get it running.
@jannis: the generator of ::property-spec
is already very slow. Try (s/exercise ::properties-spec 15)
and than with 20. The thing is that generated samples become bigger and bigger if you generate more. test.check has some internal size thing. You have to improve the generator.
Is there any particular reason that the sequence regex ops do not recognize strings as seqable
s of char
s? For instance, ”ab”
does not conform to (s/cat :a #(= % \a), :b #(= % \b))
, while [\a \b]
does.
In addition, are there plans for negative-lookahead regex ops, like those from &
? For instance, in PEGs / parsing expression grammars, &
has a negative counterpart called !
.
In particular, an end-of-sequence regex op would be very useful—it could be called ::end
, and it could be equivalent to (! ::any)
. As far as I can tell, this isn’t currently possible.
@cigitia: you're posting news links again
@cigitia There are good tools for string regex. Spec is never going to be great for that and there are no plans to use it for that
No plans for negative look ahead ops
They are generally not needed for the kinds of things we expect you to do with spec regex
I had actually been working on a PEG library that could create grammars for generic EDN data, including but not limited to strings, before Spec was announced