Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Magnus
    @evnu
    @alfert would be nice to have a release soonish to get rid of the __STACKTRACE__ warnigns
    Klaus Alfert
    @alfert
    @evnu I thought about a minor release to move forward to Elixir 1.7 and above. That would eliminate the __STACKTRACE__ warning but does not too well under OTP 23. Removing that :poison issue is a good idea.
    Magnus
    @evnu
    I don't understand yet what the issue with OTP 23 is; I have been running OTP 23 with PropCheck for quite some time without any issues
    Klaus Alfert
    @alfert
    Hmm, I should give it a try. I was commenting on #180 but until now I am somewhat behind Elixir and Erlang versions.
    PropCheck 1.3.0 is released now.
    Klaus Alfert
    @alfert
    @evnu do you have an idea why the Github Actions are ok under Checks Tab but seem to be doubled at the Conversation Tab with the half of them failing? And what to do against it? I am completely puzzled.
    Magnus
    @evnu
    @alfert where should I look?

    PropCheck 1.3.0 is released now.

    thx!

    Klaus Alfert
    @alfert
    Sorry, I am just recognising your answer. But just take any recent pull request. It says six or seven checks which run through and 9 other things which don't work. But these 9 are nowhere defined, at least I do not know where. But they prevent merging of PRs without administrative override. That is not deal breaker but very annoying.
    Magnus
    @evnu
    ok, got it. I'll try to debug it. don't mind the draft PR for now, I need a test vehicle..
    alfert/propcheck#183 I removed all jobs except for a dummy; no job was run at all, the zombie jobs still exist
    You can remove the outdated check in the protected branch settings of the repository settings.
    @alfert if this is not the issue, I can try to debug this further.
    Klaus Alfert
    @alfert
    @evnu thanks, the 18001 will be the issue or at least one of them.
    Klaus Alfert
    @alfert
    I closed our PR since you find the solution and it cannot be made in the PR. Thanks a lot!
    Magnus
    @evnu
    :+1:
    Magnus
    @evnu

    Hm, it seems that stacktraces are somehow broken (maybe due to OTP 23?). With verbose:

    Failed: The input fails the test.
    An exception was raised:
    ** (FunctionClauseError) no function clause matching in DateTime.to_unix/2
    Stacktrace:

    The actual stacktrace is not being written. PropCheck as of v1.3.0.

    I can work around this using PROPCHECK_DETECT_EXCEPTIONS=1; with that, the exception is output in red.
    Magnus
    @evnu
    Hm, I did not yet find a minimal example to reproduce this.
    Klaus Alfert
    @alfert
    Hi Magnus, you could use PropCheck v1.3 from github ({:propcheck, "~> 1.3", github: "alfert/propcheck", only: [:dev, :test]}). That should help, but relies on a non-released proper
    Magnus
    @evnu
    Ah, I read that in the README, but didn't draw the connection.
    I hope kostis releases a new version of propcheck sometime in the near future :)
    Klaus Alfert
    @alfert
    yes, that would be great
    Magnus
    @evnu
    @alfert alfert/propcheck#192 CI is/was broken, action/setup-elixir is unmaintained
    Klaus Alfert
    @alfert
    @evnu are you interested in getting write access to the propcheck repo?
    Magnus
    @evnu
    ah, sorry for getting back to you only now! I seem to miss notifications for gitter. I guess write access would make sense, if that also makes life easier for you :)
    Klaus Alfert
    @alfert
    Never done this before, but I would guess that it would make the bug fixing process easier / quicker. Beside from this, you have shown dedicated interest and activities with PropCheck over the years.
    So welcome as a collaborator @evnu!
    Magnus
    @evnu
    Thanks! :)
    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
    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
    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.