Test errors and failures

[swt30]

I am getting test errors like this on 0.4:

VoronoiDelaunay tests: Error During Test
  Test threw an exception of type UndefVarError
  Expression: incircle(t,p) <= 0
  UndefVarError: incircle not defined
   in anonymous at /home/sthomas/.julia/v0.4/BaseTestNext/src/BaseTestNext.jl:160
   in do_test at /home/sthomas/.julia/v0.4/BaseTestNext/src/BaseTestNext.jl:181
   [inlined code] from /home/sthomas/.julia/v0.4/VoronoiDelaunay/test/runtests.jl:249
   in anonymous at no file:0
   in include at ./boot.jl:261
   in include_from_node1 at ./loading.jl:320
   in process_options at ./client.jl:280
   in _start at ./client.jl:378

and test failures like this on 0.5 (won't run on Travis until a new version of GeometricalPredicates is tagged):

VoronoiDelaunay tests: Test Failed
  Expression: getc(tess._trigs[3]) == p2
   Evaluated: GeometricalPredicates.Point2D(1.1,1.1) == GeometricalPredicates.Point2D(1.9,1.9)
 in record(::Base.Test.DefaultTestSet, ::Base.Test.Fail) at ./test.jl:428
 in do_test(::Base.Test.Returned, ::Expr) at ./test.jl:281
 in macro expansion; at /home/sthomas/.julia/v0.5/VoronoiDelaunay/test/runtests.jl:209 [inlined]
 in macro expansion; at ./test.jl:672 [inlined]
 in anonymous at ./<missing>:?
 in include_from_node1(::String) at ./loading.jl:426
 in process_options(::Base.JLOptions) at ./client.jl:262
 in _start() at ./client.jl:318

This may be different manifestations of some kind of scoping bug in @testsets, given that the only change was that I wrapped the entire set of tests in @testset begin ... end. I'm looking into it.

[swt30]

May be related to https://github.com/JuliaLang/julia/issues/17170

[swt30]

Actually I think it's https://github.com/JuliaLang/julia/issues/17908 because there are continue statements in these tests.

[swt30]

The PR fixes the 0.4 issues, but I have some tests returning different results or hanging on julia 0.5. This example causes my machine to hang on julia 0.5 but not julia 0.4:

using VoronoiDelaunay

function test()
  tess = DelaunayTessellation()
  push!(tess, Point(min_coord, min_coord))
  push!(tess, Point(1.33, min_coord))
  push!(tess, Point(1.66, max_coord))
  push!(tess, Point(max_coord, max_coord))
end

test()

[swt30]

OK, it's because there's something in julia 0.5 which is resulting in incorrect triangulations. Here's random points added to a tessellation. v0.4 does not have this issue. Wonder what it could be?

[swt30]

If you would like to reproduce this, try running the following on julia 0.4 and 0.5. On 0.4 everything is fine; on 0.5 it will botch the triangulation and then hang after a few points.

using Plots
pyplot(show=true)
using VoronoiDelaunay

"Recipe to plot a Delaunay mesh"
@recipe function plot(tess::DelaunayTessellation2D)
  seriestype := :path
  legend := false
  markershape := :circle
  markersize := 3
  grid := false
  xlims := (1, 2)
  ylims := (1, 2)

  x, y = getplotxy(delaunayedges(tess))
end

"Generate a random point in the domain"
function Base.rand(::Type{Point2D})
  x = min_coord + (max_coord - min_coord) * rand()
  y = min_coord + (max_coord - min_coord) * rand()
  Point2D(x, y)
end

function main()
  # make the points that we are going to triangulate
  srand(99)
  N = 20
  points = [rand(Point2D) for i=1:N]

  # triangulate
  tess = DelaunayTessellation(N)
  for p in points
    push!(tess, p)
    plot(tess)
    sleep(0.2)
  end
end

main()

[swt30]

This is a very elusive bug. I have pinned it down to deep within the behaviour of push!, more specifically in the _flip functions. Some triangles are ending up with coincident points once _restoredelaunayhood! is called, and this is ruining the tessellation. However, when I enter the method with the Gallium debugger, I get different results, which is confusing me to no end.

[swt30]

The problem turned out to be in lines like this:

setabc(ot2, geta(ot1), old_ot1_geom_b, geta(ot2))

It looks like there was some kind of weird inlining behaviour where geta(ot2) was not evaluated first like you might expect, but instead was evaluated after ot2._a had already changed. This caused the a and c points to become the same for some triangles. I worked around this by doing geta(ot2) on the previous line instead.

I assume the behaviour disappeared when running the debugger because it disabled inlining or somehow changed the order of evaluation.

[skariel]

closed by mistake

[skariel]

ahh sorry. Its good that I closed it