-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Remove quadgk and friends from Base #19741
Conversation
If I recall, @vtjnash had expressed concern over not having |
The package will get tested nightly on PkgEval. I don't think I've ever seen the quadgk test fail myself, but maybe that only happens early in big inference refactorings. Since those are relatively rare, we should make it easier to run PkgEval on-demand for that kind of PR, like we do with nanosoldier for benchmarking. There's some work underway to make that possible. |
It tests one aspect of convergence speed. Without specific tuning in inference, this code can take anywhere from several days (or weeks?) to infer, vs. computing the same answer in a fraction of a second. |
It's true that this is a good inference test case, but good test cases might be found anywhere in the ecosystem. I don't think that can be a factor in deciding where code lives. A good approach would be either PkgEval, or making a reduced version of this to copy into the inference test suite. After all, it's also possible the quadgk code would be updated to become a less-good inference test case. |
On 0.5 I was
Fixed by importing the quadgk function explicitly.
Just thought I'd leave this here as a quick fix for anyone else who suddenly had their code break on 0.5 -> 0.6! Some kind of guidance in the error message would be useful, particularly if these errors will become the new normal as core Julia slims down. |
Hey @jarvist, thanks for the report. Issues with particular packages should be reported on the package's repo. If you could open an issue at https://github.com/JuliaMath/QuadGK.jl, that would be great. |
OK, can do - but I think the key issue is that the deprecation warning:
Is misleading, as:
I assume that's because it's clashing with the deprecation warning itself? |
The handling of the exporting is an issue with the package. |
Yes it looks like it's clashing with the deprecation definition. Unfortunate, but we can probably only fix this completely when the deprecation is removed. |
The deprecation message could be changed to:
|
This PR removes
quadgk
as well as theBase.QuadGK
submodule, now that QuadGK.jl is its own registered package. The approach taken here is mirrored after the approach taken for removing the primality functions.cc @stevengj and @tkelman