This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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
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
I have overriden almost all generators because my data specs seem to be too complex to use the default generators.
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.
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.
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
chars? 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 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
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
Once Spec was announced, it seemed like there wasn't much room for such a library anymore, and so I thought about instead making a library that would utilize specs and convert them into parser transducers