Fork me on GitHub

makes me wonder about the spec for get-in: (get-in {:a "lol"} nil) ;;=> {:a "lol"}


I guess it could be correct if nil is regarded as the empty sequence


@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.


An alternative idea would be per-`fdef` opts perhaps?


Or a way to exclude specific functions from run-(all-)tests?


@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.


Good point, it's probably the generators generating big inputs. I'll double-check.


Although... the generator is already generating relatively small data.


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.


@akiel: Once you have boot installed, all you should need is boot test-once


@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.


@akiel: Cool, thanks for investigating. I'll see what I can do. 🙂


Is there any particular reason that the sequence regex ops do not recognize strings as seqables of 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.


lol, @cigitia your slack-fu is struggling

Alex Miller (Clojure team)22:06:42

@cigitia: you're posting news links again


Argh, sorry

Alex Miller (Clojure team)22:06:33

@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

Alex Miller (Clojure team)22:06:07

No plans for negative look ahead ops


Okay, thanks

Alex Miller (Clojure team)22:06:38

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


Maybe there's still room for the first idea, though, then, hm