-
Notifications
You must be signed in to change notification settings - Fork 37
[Merged by Bors] - fix partial missing bug #191
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
Conversation
devmotion
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't the suggestion to not always deepcopy? Please also add a test for this (without using Turing preferably) and bump the version.
|
I added a test but had to move some |
ColPrac (and the protection of the master branch) require the version to be incremented in PRs. |
torfjelde
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Other than the version-bump I'd recommend adding in some tests for the behavior that made us discover this bug, to ensure that it doesn't happen in the future.
|
@devmotion @mohamed82008 Are we waiting for TuringLang/Turing.jl#1465 before merging this? |
|
We mainly wait for the comments to be addressed and the PR to be rebased or updated. However, IMO it is unfortunate that this requires changes in Turing - the fix does not need it so it would be nice to leave this out of the PR. |
|
The main annoyance of the Turing changes is that they require us to drop support for all current versions of DynamicPPL. |
But given @mohamed82008 's absence, can we/I just go ahead and make the changes to get it merged?
Hmm, how can we do this without removing the changes in Turing? Seems like there's no way around it since we want to add default behavior of a particular method which Turing currently has a wrong implementation for.
Fair point, but there's not going to be a way to circumvent this, right? Or are you suggesting that we instead only make the changes in Turing and leave DPPL without a proper implementation? |
|
Yes, I think we should go ahead, apply the suggested changes, bump the version (and the bounds in Turing) and release everything. These methods actually belong in DynamicPPL and not in Turing, so at some point we would have to move them anyway. |
Co-authored-by: Tor Erlend Fjelde <[email protected]>
61f9a55 to
bf3e7d6
Compare
devmotion
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
torfjelde
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 2.
|
bors r+ |
This PR fixes TuringLang/Turing.jl#1464. Co-authored-by: David Widmann <[email protected]>
This PR fixes TuringLang/Turing.jl#1464.