GLVisualize.jl
GLVisualize.jl copied to clipboard
JuliaGL
Travis build
I am developing a package that depends on GLVisualize.
However, as you can see here, I fail on travis on Linux because I require GLVisualize (on MAC it works fine though).
On Linux, it says X11: The DISPLAY environment variable is missing :(
How can we fix that ? Defining the DISPLAY variable on travis ?
I understand that graphical tests should not be run on travis but here it is only the Pkg.add("GLVisualize") that fails, not the using GLVisualize.
Also on the .travis.yml of GLVisualize, I think we can get rid of the Pkg.checkout's commands. Pkg.checkout("GeometryTypes", "sd/typealias") even makes travis fail on MAC.
See https://github.com/JuliaLang/Gtk.jl/blob/master/.travis.yml for some hints, particularly regarding xvfb.
Note that this isn't something that can be fixed in GLVisualize and then magically work for all packages that use GLVisualize; every package that wants Travis testing needs to install xvfb in its own .travis.yml file.
Huh this is more complicated than expected :(
https://travis-ci.org/JuliaGL/GLVisualize.jl/builds/113635293
Seems like either we need virtual input devices, or need to prevent GLFW from calling the __init__ function...
Dunno, but perhaps you could have the travis script check isdir("/dev/input") and create it if not. (Would need sudo privileges, so that would be better done from the shell.)
But this may not work: I just tested this on an Ubuntu 14.04 machine (Travis is 12.04), and got this:
tim@cannon:~$ xvfb-run julia -e "using GLFW"
Xlib: extension "GLX" missing on display ":99".
ERROR: InitError: GLX: GLX extension not found
in error at ./error.jl:21
in anonymous at /home/tim/.julia/v0.4/GLFW/src/GLFW.jl:26
in ##ErrorCallbackWrapper#7031 at /home/tim/.julia/v0.4/GLFW/src/callback.jl:50
in Init at /home/tim/.julia/v0.4/GLFW/src/glfw3.jl:297
in __init__ at /home/tim/.julia/v0.4/GLFW/src/GLFW.jl:27
in _require_from_serialized at loading.jl:84
in require at ./loading.jl:251
in process_options at ./client.jl:257
in _start at ./client.jl:378
during initialization of module GLFW
So you might fix one problem and be bitten by the next.
BUT, see the first answer here.
OT, but I do a lot of work on a remote server; one of the concerns I have about switching to GLPlot is whether we need a non-GL fallback with the same API.
EDIT: I should play with VirtualGL.
there is also: http://www.mesa3d.org/llvmpipe.html And obviously: implement a software rasterizer in Julia and as soon as Julia can target SPIR-V make it as fast as OpenGL :) Easy!
Okay I give up for now... current state can be found here: https://github.com/JuliaGL/GLVisualize.jl/pull/69 Sorry @blegat .... Seems like you already factored out the visualization code anyways ;)
By the way, the best way to integrate this into GLVisualize would be, to define the correct decompose methods in GeometryTypes so that the Mesh conversion works and then GLVisualize should theoretically be able to do the conversion automatically(If Polyhedron would be a subtype of GeometryPrimitive)
Yes as advised by @tkelman, I have splitted Polyhedra.jl in two. Thanks a lot for trying to make travis work. It indeed doesn't seem easy. I will try to improve the way Polyhedron use GeometryTypes.
It's not a bad idea anyways :) Maybe it's a good thing that GLVisualize breaks travis :D
You were right, being a subtype of GeometryPrimitive and implementing decompose and isdecomposable is a lot cleaner and everything just works :)
I have deleted PolyhedraVisualize.jl, now everything is in Polyhedra.jl. I don't need to add GLVisualize in REQUIRE anymore :)
Great, good to hear! It's not really well tested so far, but I hope this kind of pattern will get better in the future! (First thing would probably be documenting it...)