Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Brian Gerstle
@bgerstle
and changing the number of allowed discarded tests
Robert Widmann
@CodaFi
Mhm. Then there isn't a combinator for that explicitly.
By the way, I believe fixed your issue here typelift/SwiftCheck#159
Brian Gerstle
@bgerstle
lgtm :+1:
btw, i couldn't get the discard approach to work, it never seemed to fail no matter how low i set max allowable discards
Robert Widmann
@CodaFi
Another bug! That one, I don't believe we have unit tests for. Should be easy to reproduce.
Oh wait, not a bug "Discarded tests (i.e. ones with a false precondition) do not affect coverage."
We need a new combinator!
Robert Widmann
@CodaFi
So, wait, did you try something like
let p = //... Some property
return p ^&&^ p.cover(/**/)
Brian Gerstle
@bgerstle
i think so... sorry in the middle of something else atm :-/
Brian Gerstle
@bgerstle
not sure i follow how that would work in my case. basically i'm testing that different objects should (mostly) have different hashes. w/o worrying about cover or any of that, it looks like this:
forAll { a, b in 
  return (a != b) ==> (a.hash != b.hash)
}
now, this isn't true all the time (you can't have a perfect hash algorithm), in fact, I hit a falsifiable case
so, i wanted to say that the part after ==> only needs to be true about 95% of the time (arbitrary percentage, just shouldn't be too bad for performance reasons)
one way to do that is to always return true, and just require that certain the a.hash != b.hash component is "covered" 95% of the time
e.g. return (a != b) => (true.cover(a.hash != b.hash, percentage: 95, label: "hashes are different))
this means the always passes unless coverage isn't satisfied (i.e. fewer than 95% of the hashes were different when the values were different)
but i ran into the bug which you fixed earlier, that failed coverage didn't report replay values
if that's fixed i'm satisfied w/ my above workaround
Brian Gerstle
@bgerstle
confirmed:
*** Insufficient coverage after 1000 tests
(only 99% hashes are different, not 100%)
[redacted]
error: [redacted]: failed - Property coverage insufficient.  Replay with 219013233 7406 and size 0
Robert Widmann
@CodaFi
That's an interesting workaround. Actually, I'd like to preserve it somewhere like the testing suite if you wouldn't mind.
Brian Gerstle
@bgerstle
of course not
i've got something else for you, PR incoming shortly..
Brian Gerstle
@bgerstle
whoops added something else in there by accident, rebasing..
@CodaFi i also have some generators that others may find useful, e.g. for CoreGraphics & UIKit types
would you be interested in a PR which puts them in a separate folder, so users can integrate via CocoaPods subspecs as needed?
e.g. CGRect, CGVector, etc.
Robert Widmann
@CodaFi
I am wary of doing this in general right now, only because the new Foundation changes are going to break a lot of work very soon
Adam Kuipers
@adamkuipers
Why is >>- used over the canonical >>=. Is it because >>= is already used for an in-place bit shift by the stdlib?
Robert Widmann
@CodaFi
Yep. We need control over precedence and associativity.
Adam Kuipers
@adamkuipers
Is there a practical limitation I'm not thinking of to type inference that the type checker can't infer that .zip(stringGen1, stringGen2) is a type method of Gen<(String, String)>?
Robert Widmann
@CodaFi
The typechecker is unidirectional (forward) unless you're in an anonymous closure. It sees Gen<(τ_0_0, τ_0_1)> before it sees the calls that would unify the τ's.
I really wish it were better at being bidirectional. It certainly seems like that's the preferred method of writing type checkers these days.
Adam Kuipers
@adamkuipers
Has there been any benchmarking done on the performance of immutable reference types vs immutable value types?
Seems like both have advantages, where reference types only pass a single register but have unwrapping overhead.
Adam Kuipers
@adamkuipers
Another advantage of reference types is that you can have benign effects. Otherwise you'd require the client to mark the value mutable.
Robert Widmann
@CodaFi
We have done exactly zero benchmarks. The code is just inefficient in general. If you want to be the one to take this on, it'd be huge.
going to try out the new monoidal syntax soon
has anyone looked into extending SwiftCheck to support Testable functions that raise XCTest failures? e.g. by using assertions like XCTAssert or matcher frameworks like Nimble?
Brian Gerstle
@bgerstle
i saw something like ==== which prints a verbose description when it fails, but would be nice to be able to use a fully-fledged matching framework to get even more descriptive messages
Robert Widmann
@CodaFi
XCTest methods are all marked Void. We'd have to hook in pretty deep to get that to work.
Adam Kuipers
@adamkuipers
It'd be great if there was something like Nimble without the complex DSL they dragged into it.
Robert Widmann
@CodaFi
I'd love something like that too, but it seems to be useful you'd have to have a QUOTE feature at he language level.
Adam Kuipers
@adamkuipers
Is there any way to use SwiftCheck (or any other library that's been migrated to Swift 3) with Xcode 8 using spm? It doesn't look like spm supports different git branches.
Jose Luis
@josete89
Hi, is possible build Swfitz using swift 3?
I’m getting this errors /Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Carthage/Checkouts/Swiftx/Sources/Combinators.swift:128:49: error: @escaping may only be applied to parameters of function type
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Carthage/Checkouts/Swiftx/Sources/Combinators.swift:128:49: error: @escaping may only be applied to parameters of function type
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Carthage/Checkouts/Swiftx/Sources/Combinators.swift:128:49: error: @escaping may only be applied to parameters of function type
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Swiftz/ArrowExt.swift:13:11: error: generic parameter 'Self' could not be inferred
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Swiftz/ArrowExt.swift:18:11: error: generic parameter 'Self' could not be inferred
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Swiftz/ArrowExt.swift:38:16: error: closure use of non-escaping parameter 'f' may allow it to escape
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Swiftz/ArrowExt.swift:38:21: error: closure use of non-escaping parameter 'g' may allow it to escape
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Swiftz/ArrowExt.swift:48:16: error: closure use of non-escaping parameter 'k' may allow it to escape
/Users/alcaljos/Pers/locate-ios/Carthage/Checkouts/Swiftz/Swiftz/ArrowExt.swift:48:18: error: closure use of non-escaping parameter 'f' may allow it to escape
Robert Widmann
@CodaFi
@adamkuipers I just pushed the Swift 3.0 branch along with SwiftPM support today. Let me know if it doesn't work.