Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

On Wednesday, 13 January 2016 at 16:04:32 UTC, Dav1d wrote:
> On Wednesday, 13 January 2016 at 06:30:44 UTC, Jason Jeffory 
> wrote:
>> On Tuesday, 12 January 2016 at 20:48:37 UTC, Dav1d wrote:
>>> On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory 
>>> wrote:
>>>> [...]
>>>
>>> Yup, that's a little bit annoying on Windows (also as 
>>> mentioned before the deimos bindings weren't updated in a 
>>> while, might contribute to your issue).
>>>
>>>>[...]
>>>
>>> What does a debugger say? Where is it coming from?
>>
>>
>> It doesn't I put a break point on the glfwTerminate() and what 
>> visual studio/d shows is something in the "import 
>> derelict.glfw3.glfw3;" statement.
>>
>>
>> Well, a BP on on glfwTerminate is never reached. Hence it must 
>> be before that. The loop should work fine because it works 
>> already. One would think it is the while 
>> (!glfwWindowShouldClose(window)), but using just a global 
>> variable still causes the exception.
>>
>> Hence the logical place the except should be occurring is
>>
>> glfwPollEvents();
>>
>> If I remove it and just use a counter and exit after while, 
>> then there is no exception. Hence, it must be glfwPollEvents();
>>
>> But what can I do about that? Must be an issue with Derelict 
>> or glfw! Since Derelict is just bindings, it suggests glfw. 
>> But what possibly could be wrong?
>
> That's not correct.
> Build a debug build and check the stacktrace which should be 
> printed, if not open gdb or any other debugger and set a 
> breakpoint on the exception. Iirc you can break on _d_throw and 
> check the stacktrace, then you know where it actually is coming 
> from.

Either I don't get what you are talking about, or VS doesn't do 
what you think it does.

When I run the program, this is the stack trace. VS pops up with 
an "Exception has been thrown" window and it highlights the 
"import derelict.glfw3.glfw3;" line. I can't get any further than 
that. It is a debug build. But the except is not coming directly 
from the test.d code.

  	user32.dll!74d94790	
  	user32.dll!74d94527	
  	opengl32.dll!5946caa3	
  	user32.dll!74db4923	
  	user32.dll!74d94790	
  	user32.dll!74d94091	
  	user32.dll!74d93e50	
  	glfw3.dll!59525797	
  	glfw3.dll!5952792c	
  
	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() + 0x1b bytes	D
  	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv() + 
0x23 bytes	D
  	test.exe!__d_run_main() + 0x20c bytes	D
>	test.exe!__entrypoint.main() Line 7 + 0x11 bytes	D
  	test.exe!_mainCRTStartup() + 0xa9 bytes	D


I'm not sure what you are expecting to happen. I can't step in to 
anything to see more detail and the lines that VS is showing 
where the problem is, is not steppable. It maybe a weird issue 
with VisualD. I will try gbd for windows, but have to install it 
and learn how to use it.