-
-
Notifications
You must be signed in to change notification settings - Fork 55
Improve test coverage #238
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
Do we actually have codecov enabled on this repo? Should we do that, if the coverage is now worth showing off? :D |
We do, it just doesn't run in prs |
Well it does, it just errors |
src/boundingboxes.jl
Outdated
function Rect{N, T}(geom::AbstractGeometry) where {N, T <: Number} | ||
if applicable(Rect{T}, geom) | ||
@warn "`Rect{T}(geom)` is deprecated as the final boundingbox method. Define `Rect{N, T}(geom)` instead." | ||
return Rect{T}(geom) | ||
else | ||
return Rect{N, T}(coordinates(geom)) | ||
end | ||
end |
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.
I don't think there is much of a point to making a user facing depwarn here, because on master Rect{T}(geom)
only works if T matches the input eltype. I therefore doubt anyone relied on it. It also throws an ArgumentError lower down the line (and would create a stackoverflow with this dep warning.)
For devs I think it makes more sense, because I think it's fairly likely someone would copy the syntax from GeometryBasics. And without a warning, their implementation would silently be ignored.
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.
nvm, doesn't work. I thought for a second that N <: Val
was working for catching literals but I don't think it actually does. Without type specifity on Rect{N}(...)
this will always call the applicable branch and loop.
Fixes #155 (if it's not already fixed on master) |
Fixes #207 |
This pr aims to increase test coverage and fix problems I hit along the way. WIP for now.
Questions:
Rect()
default toRect(NaN..., 0...)
instead ofRect(Inf..., -Inf...)
? Otherwise, how should utility functions treat infinite Rects? E.g. should volume return NaN? minimum and maximum? Should we consider-Inf
widths as invalid?mat[Rect2i(1, 1, 2, 2)]
to index[2:3, 2:3]
, i.e. be zero based?(Significant) (Code) Changes:
euclidean_distance
,update
to acceptVecTypes
strictly_equal_face_vertices()
for comparing the result ofsplit_mesh
with pre-merge meshes. This considers two meshes to be equal ifa.vertex_data[a.face] == b.vertex_data[b.face]
holds for every face and every vertex attribute.merge_vertex_indices(faces...[, index_counter])
method which I added as an alternative tomerge_vertex_indices(tuple_of_face_arrays[, index_counter])
but never used. This function is internal with the (more) public interface beingexpand_faceviews()
, so this should not be breaking. (It's also not used in MeshIO or Makie)Rect{T}(obj)
constructor for boundignboxes as it clashes with theRect{N, T}
definition of the type. The implementations now useRect{N, T}(obj)
with other methods funneling into that one. This enablesRect{N}(obj)
andRectT{T}(obj)
analogous to other Rect constructors.maybe breakingreworkedself_intersections()
to allow a segment to intersect with multiple other segments.For this, the format of the returned indices changed fromThis is now an internal change. Also did some low hanging performance optimizations (skip redundant half of the loop)Vector{Int}
toVecto{Tuple{Int, Int}}
.Test TODO;