Version 2.0.0-alpha breaks interactive demo from GLVisualize

[Tyde]

Hi,

with the newest version I am not able anymore to use drag and drop in GLVisualize. (Example: https://github.com/JuliaGL/GLVisualize.jl/blob/master/examples/interactive/graph_editing.jl)

This results in the following error:

ERROR: LoadError: MethodError: no method matching (::GLWindow.##23#24{Reactive.Signal{Tuple{Int64,In
t64,Int64}}})(::GLFW.Window, ::Int32, ::GLFW.Action, ::Int32)
Closest candidates are:
  #23(::Any, ::Int32, ::Int32, ::Int32) at C:\Users\thiem\.julia\v0.6\GLWindow\src\callbacks.jl:65
Stacktrace:
 [1] _MouseButtonCallbackWrapper(::GLFW.Window, ::Int32, ::GLFW.Action, ::Int32) at C:\Users\thiem\.
julia\v0.6\GLFW\src\callback.jl:60
 [2] #renderloop#39(::Float64, ::GLWindow.##40#42, ::Function, ::GLWindow.Screen) at C:\Users\thiem\
.julia\v0.6\GLWindow\src\render.jl:45
 [3] renderloop(::GLWindow.Screen) at C:\Users\thiem\.julia\v0.6\GLWindow\src\render.jl:40

The error occurs when I start to Drag a circle in the demo. Pinning to v1.5.0 fixes the problem.

[SimonDanisch]

Can you try: https://github.com/JuliaGL/GLWindow.jl/pull/57

[SimonDanisch]

I still need to figure out what to do about: https://github.com/JuliaGL/GLWindow.jl/blob/afae01225eaa0f9a09622a1beb0eaaf57bd57c6f/src/screen.jl#L508 @jayschwa, how do we avoid segfaults with the new Window struct?

[Tyde]

The pull request seems to resolve the issue.

[jayschwa]

@SimonDanisch, I don't think I understand. What is segfaulting? In the code you linked to, the handle on the Window is being mutated, which is not supposed to happen. Window is intended to be immutable.

[SimonDanisch]

Well, setting it to C_NULL and then checking it for C_NULL before another destroy was the most reliable method for me to not destroy an already destroyed window (which segfaults).

[jayschwa]

The handle that GLFW returns is simply a pointer to some dynamically allocated internal struct. After calling DestroyWindow, the memory is freed, and any subsequent attempts to use it (e.g. a second DestroyWindow) is going to cause a segfault.

I guess GLFW.jl could make its Window object mutable so that the handle can be changed to NULL, but then NULL checks need to be added to every wrapper function. It sounds like a lot of boilerplate just to convert a segfault to an exception. Either way, code that uses GLFW.jl needs to be written to avoid further calls to a destroyed window.

[SimonDanisch]

Well, we could put code into GLFW to make this easier, e.g. by having a destroy that sets the pointer to C_NULL and then have something like isopen or is_destroyed that checks for C_NULL ;)