Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Magnus
    @evnu
    https://github.com/alfert/propcheck/pull/189/checks?check_run_id=2398658517 tests are quite noisy; which test failed in that run?
    Klaus Alfert
    @alfert
    I have no clue after scrolling twice about the log :-(
    Magnus
    @evnu
    @alfert something is off with caching dialyzer PLTs in CI. I removed it in https://github.com/alfert/propcheck/pull/195/commits/25a04723c0f253b5a918b89489408265ce962afa, dialyzer seems to work just fine then. I would just remove it for now, as we do not run CI that often anyways, so waiting a little bit for it doesn't really hurt
    Magnus
    @evnu
    See alfert/propcheck#195
    Klaus Alfert
    @alfert
    @evnu I'll try to catch up during the weekend. Under the week there is too much regular work going on.
    Magnus
    @evnu
    @alfert no worries :)
    Magnus
    @evnu
    @alfert can alfert/propcheck#196 be closed due to alfert/propcheck#197
    Magnus
    @evnu
    @alfert https://github.com/alfert/propcheck/issues/190#issuecomment-831346878 time to release?
    Klaus Alfert
    @alfert
    If we would do a release, would we go back to PropEr 1.3 or do we stick with the current master of PropEr? There is still no release since 2018 of PropEr.
    Magnus
    @evnu
    Hm, Kostis is really in no hurry to release it seems.. I think we should release with PropEr 1.3. The current version of PropCheck is also based on PropEr 1.3, right? So we would at least not lose something compared to the current version.
    Klaus Alfert
    @alfert
    That's true.
    But what's irritates me is that we don't have any serious new features: We only do some CI stuff, fix the ex_doc version and fix some typoos in the Readme. What would change?
    Klaus Alfert
    @alfert
    Ah, silly me: we have the solved issue with umbrella projects.
    Magnus
    @evnu
    Yeah, the release is "only" about the umbrella fix.
    so a patch version would be fine I guess.
    Klaus Alfert
    @alfert
    Arghh. The API for Targeted PBT changed sometime ago on master of PropEr. All or almost all TPBT tests fail with PropEr 1.3.0. This is nasty. I guess that pointing to a dedicated git-sha is not a very good option. What do you think?
    Klaus Alfert
    @alfert
    alfert/propcheck#179 is the problematic PR introducing support for OTP23 and fixing the the changed API of post PropEr 1.3.0 .
    Magnus
    @evnu
    Oh, what a pain :-/

    I guess that pointing to a dedicated git-sha is not a very good option. What do you think?

    You mean pointing to a git revision within the published version of PropCheck? I don't know if this is something that is frowned upon.. How about this: We point to PropEr's git revision, but only release a RC candidate. With that, the update of PropCheck should not automatically propagate to users, unless they explicitly switch to the RC version.

    we can then bump to a PropEr release version later on (hopefully Kostis doesn't take all year to release a new version :-/)
    Magnus
    @evnu
    But I am not sure if mix excludes pre-versions by default..
    iex(1)> Version.match?("1.1.1-rc", "~> 1.1")
true
iex(2)> Version.match?("1.1.1-rc", "~> 1.1", allow_pre: false)
false
    Magnus
    @evnu
    https://github.com/hexpm/hex/blob/main/lib/hex/version.ex#L47 I think hex does not update to pre versions automatically, unless explicitly allowed
    @alfert what do you think, lets go with RC?
    Klaus Alfert
    @alfert
    @evnu Good idea with the rc version. I will do that on the weekend.
    Klaus Alfert
    @alfert
    It becomes worse. Hex does not like dependencies with git version identifiers: 
    ** (Mix) Stopping package build due to errors.
Dependencies excluded from the package (only Hex packages can be dependencies): proper
    I asked kostis for his release plans in proper-testing/proper#257 Depending from his answer we either wait a little more or need to do some git magic for changing the history of propcheck (.e. rolling back the API in #179 ).
    Magnus
    @evnu
    Hm, that's frustrating. Well, lets see what Kostis says. I would hope that he is able to "simply" release soonish, that would be the best case. If that doesn't work or cannot happen in a timely matter, we could branch from 1.3 and cherry-pick only the bug fix for the configuration issue.
    Klaus Alfert
    @alfert
    Kostis is actively discussion tickets but not my comment. I take this as an indicator, that he either does not want to release soonish or does not want to interact with downstream dependencies. I prepare now 1.3.1-rc1 on its own release-branch.
    Magnus
    @evnu
    Yes, makes sense.
    Magnus
    @evnu
    https://github.com/proper-testing/proper/issues/257#issuecomment-841844870 seems like Kostis wants to release!
    Magnus
    @evnu
    alfert/propcheck#200 I created a PR to run CI against the current PropEr HEAD
    Magnus
    @evnu
    Judging from CI, we should be all-right w.r.t. the next PropEr release
    Klaus Alfert
    @alfert
    Yeah, I saw it also and look forward to the new Proper release! There are some new feature that we should support - at least for OTP24
    Klaus Alfert
    @alfert
    In proper-testing/proper#272 there are new types and thus generators for OTP24. I am thinking of introducing these types but only if you are compiling under OTP24. Does that makes sense? Or do we need a new minimal supported OTP variant?
    Magnus
    @evnu
    PropCheck does not create generators from types, so I think it should not hurt to have those generators for OTP < 24 as well, right?
    Klaus Alfert
    @alfert
    So we would simply provide generators nonempty_bitstring()and nonempty_binary() pointing to the new implementations? To be honest, I did not really understand if the generators are new or if it is only the generator for type specification, so we don't care.
    Magnus
    @evnu
    As PropEr supports OTP 20-24, I think simply adding those generators should be fine for us.
    Ah, but I think you are right.. Maybe those generators come into use when deriving generators from types.
    Maybe we should just do nothing then? PropCheck does not implement other type-specific generators such as nonempty_list() or maybe_improper_list() and so on either.
    Klaus Alfert
    @alfert
    That's a good point. And it would explain, why I was so confused yesterday evening while checking the diffs from proper-testing/proper#272 So let's not do anything for that.
    Magnus
    @evnu
    alfert/propcheck#200 Would you like that to be merged, or should we close and simply update to the new PropEr release when it is released?
    Klaus Alfert
    @alfert
    I have now also found that nonempty_binary() is a new type introduced in the type specs for OTP24

    alfert/propcheck#200 Would you like that to be merged, or should we close and simply update to the new PropEr release when it is released?

    I guess we don't need to merge, we simply wait for the release, upgrade then the dependencies and release PropCheck 1.4

    Magnus
    @evnu
    Can't wait for it, the broken stacktraces with OTP 23 bug me a lot :D
    Klaus Alfert
    @alfert
    Next week all should be good again :-)
    Klaus Alfert
    @alfert
    Proper 1.4 is there
    Magnus
    @evnu
    that was fast! Thanks! :)
    Klaus Alfert
    @alfert
    But my release was mixconfigured. Grrrr. Wait for 30 minutes
    Magnus
    @evnu
    Ok! Did you yank the version?
    Klaus Alfert
    @alfert
    Somewhere was a -dev to much in the configs. I will revert the published hex package and do it again.