Fix deprecation warnings on v0.6#6
Conversation
Codecov Report
@@ Coverage Diff @@
## master #6 +/- ##
==========================================
+ Coverage 52.7% 58.08% +5.38%
==========================================
Files 3 3
Lines 148 136 -12
==========================================
+ Hits 78 79 +1
+ Misses 70 57 -13
Continue to review full report at Codecov.
|
| Base.:*(A::ArrayPartition, B::Number) = ArrayPartition((x .* B for x in A.x)...) | ||
| Base.:/(A::ArrayPartition, B::Number) = ArrayPartition((x ./ B for x in A.x)...) | ||
| Base.:\(A::Number, B::ArrayPartition) = ArrayPartition((x ./ A for x in B.x)...) | ||
| import Base: +, -, *, /, \ |
There was a problem hiding this comment.
No, I prefer the other way these days. I seems less prone to shadowing errors.
|
Can you re-enable nightlies on Travis / AppVeyor (keep it allowed failure though). I'd like to see this does get rid of the depwarns. |
ecd60d5 to
04ec67a
Compare
| Base.:./(A::ArrayPartition, B::Number) = ArrayPartition((x ./ B for x in A.x)...) | ||
| Base.:.\(A::Number, B::ArrayPartition) = ArrayPartition((x ./ A for x in B.x)...) | ||
| end | ||
| VERSION < v"0.6.0-dev.1614" && include_string(""" |
There was a problem hiding this comment.
I think this can be done with @static if rather than include_string(), right?
There was a problem hiding this comment.
No, even with @static it has to be parsed, and these warnings are coming directly from the Scheme parsing code, not from deprecations.jl.
(that was actually the first thing I tried ;-) )
There was a problem hiding this comment.
Yeah, that's what I thought too. Have you actually tried it? Adding @static consistently stops the deprecation warnings in v0.6 for me.
There was a problem hiding this comment.
Err, didn't notice that you said you tried it, sorry!
Then I'm super confused, because I just tried it now and it worked.
There was a problem hiding this comment.
Specifically, I changed the code to:
@static if VERSION < v"0.6-"
Base.:.+(A::ArrayPartition, B::ArrayPartition) = ArrayPartition((x .+ y for (x,y) in zip(A.x,B.x))...)
<other methods omitted>
endand got no deprecation warnings after changing the code and re-importing it in a new Julia session.
There was a problem hiding this comment.
Wait, so is the include_string necessary? I'd like to hear back from @ScottPJones first before merging. I would've assumed it wasn't necessary, and can't find a simple test where it is.
There was a problem hiding this comment.
as far as I can tell, it's not necessary, but yeah, I'm curious why @ScottPJones and I are getting different results
There was a problem hiding this comment.
It didn't work for me (on Travis) without using include_string. (I wouldn't have gone to such a convoluted method if it had worked on Travis). In the past, I'd had to use the technique of including a small file that had only the v0.5 or v0.6 specific code, Tim Holy suggested using include_string here.
There was a problem hiding this comment.
Note: it had seemed to work for me also, just using @static, but then I still got the warnings on Travis.
There was a problem hiding this comment.
Yeah, I see that
https://travis-ci.org/JuliaDiffEq/RecursiveArrayTools.jl/jobs/230412103
Not sure why. Odd that it worked locally but not on Travis. While this is slightly more convoluted, it's harmless.
|
(everything was passing, just rebased to pick up rdeits changes for my testing) |
No description provided.