Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CompatHelper: bump compat for AbstractPPL to 0.6, (keep existing compat) #440

Conversation

github-actions[bot]
Copy link
Contributor

This pull request changes the compat entry for the AbstractPPL package from 0.5.1 to 0.5.1, 0.6.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

@yebai
Copy link
Member

yebai commented Dec 19, 2022

bors r+

bors bot pushed a commit that referenced this pull request Dec 19, 2022
…at) (#440)

This pull request changes the compat entry for the `AbstractPPL` package from `0.5.1` to `0.5.1, 0.6`.
This keeps the compat entries for earlier versions.



Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.
@bors
Copy link
Contributor

bors bot commented Dec 19, 2022

Build failed:

@yebai yebai requested a review from phipsgabler December 19, 2022 15:56
@bgroenks96
Copy link
Collaborator

Could we please try to get this merged? This is currently causing a hard conflict for my package because of the Setfield compat requirements of AbstractPPL 0.5.2.

@yebai
Copy link
Member

yebai commented Dec 28, 2022

bors try

bors bot added a commit that referenced this pull request Dec 28, 2022
@bors
Copy link
Contributor

bors bot commented Dec 28, 2022

try

Build failed:

@torfjelde
Copy link
Member

It's failing because after [email protected] (more specifically, after TuringLang/AbstractPPL.jl#43) it seems we need to explicitly require concretization when calling varname

@torfjelde
Copy link
Member

It seems to me that we should just make concretize=true by default for @varname and varname. This way we preserve the current behavior. I'll make a PR.

@torfjelde
Copy link
Member

See TuringLang/AbstractPPL.jl#75

bors bot pushed a commit to TuringLang/AbstractPPL.jl that referenced this pull request Dec 29, 2022
Use `Setfield.need_dynamic_lens` as the default value for `concretize` in `varname`. This way we preserve pre-0.6 behavior, thus not make the 0.6-release "less" breaking.

Ref: TuringLang/DynamicPPL.jl#440

Co-authored-by: Hong Ge <[email protected]>
@yebai
Copy link
Member

yebai commented Dec 29, 2022

bors try

bors bot added a commit that referenced this pull request Dec 29, 2022
@bors
Copy link
Contributor

bors bot commented Dec 29, 2022

try

Build failed:

…eep existing compat) (#469)

* Fixed a typo in tutorial (#451)

* CompatHelper: bump compat for Turing to 0.24 for package turing, (keep existing compat) (#450)

This pull request changes the compat entry for the `Turing` package from `0.21` to `0.21, 0.24` for package turing.
This keeps the compat entries for earlier versions.



Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

Co-authored-by: Hong Ge <[email protected]>

* Some minor utility improvements (#452)

This PR does the following:
- Moves the `varname_leaves` from `TestUtils` to main module.
  - It can be very useful in Turing.jl for constructing `Chains` and the like, so I think it's a good idea to make it part of the main module rather than keeping it "hidden" there.
- Makes the default `varinfo` in the constructor of `LogDensityFunction` be `model.context` rather than a new `DynamicPPL.DefaultContext`.
  - The `context` pass to `evaluate!!` will override the leaf-context in `model.context`, and so the current default constructor always uses `DefaultContext` as the leaf-context, even if the `Model` has been `contextualize`d with some other leaf-context, e.g. `PriorContext`. This PR fixes this issue.

* Always run CI  (#453)

I find the current `bors` workflow a bit tedious. Most of the time, I summon `bors` to see the CI results (see e.g. #438). Given that most `CI` tests are quick (< 10mins), we can always run them by default. 

The most time-consuming `IntegrationTests` is still run by `bors` to avoid excessive CI runs.

* Compat with new Bijectors.jl (#454)

This PR makes DPPL compatible with the changes to come in TuringLang/Bijectors.jl#214.

Tests are passing locally.

Closes #455 Closes #456

* Another Bijectors.jl compat bound bump (#457)

* CompatHelper: bump compat for MCMCChains to 6 for package test, (keep existing compat) (#467)

This pull request changes the compat entry for the `MCMCChains` package from `4.0.4, 5` to `4.0.4, 5, 6` for package test.
This keeps the compat entries for earlier versions.



Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

Co-authored-by: Hong Ge <[email protected]>

* CompatHelper: bump compat for AbstractPPL to 0.6 for package test, (keep existing compat)

---------

Co-authored-by: Hong Ge <[email protected]>
Co-authored-by: github-actions[bot] <[email protected]>
Co-authored-by: Tor Erlend Fjelde <[email protected]>
@sunxd3
Copy link
Member

sunxd3 commented Jun 15, 2023

bors try

@bors
Copy link
Contributor

bors bot commented Jun 15, 2023

try

Configuration problem:
bors.toml: not found

@torfjelde
Copy link
Member

torfjelde commented Jun 15, 2023

Bors isn't used any more @sunxd3 We use merge queues, which effectively means that once the tests pass it can be put into the queue. Testst aren't passing here though, so can't do that yet.

@sunxd3
Copy link
Member

sunxd3 commented Jun 15, 2023

I realized that, so I trigger the CI to run again. Let me see what the test error says

@yebai yebai closed this in #494 Jul 21, 2023
@yebai yebai deleted the compathelper/new_version/2022-12-10-00-09-02-297-02894846605 branch July 21, 2023 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants