add a test for the recent glew accessor functionality

[wchristian]

I can't test this usefully myself, but this adds a test for your recent glew accessor work and, if run on a non-4.5 machine, should be able to verify whether #38 is fixed.

[wchristian]

Are unprovided versions supposed to die like this, and not return 0 instead?

GLEW_VERSION_4_1 not available on this machine at t/02_glew_version_accessors.t line 16.

[devel-chm]

I found that this AM. It is fixed in git and a new developers release has been uploaded to CPAN.

On 2/20/2017 08:51, Christian Walde (Mithaldu) wrote:

Are unprovided versions supposed to die like this, and not return 0 instead?

|GLEW_VERSION_4_1 not available on this machine at t/02_glew_version_accessors.t line 16. |

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/devel-chm/OpenGL-Modern/pull/42#issuecomment-281084115, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwNeQVs1PQ0jIe19SI0zaWPBEXjfyQgks5reZpEgaJpZM4MGIKY.

[wchristian]

Ah, cool. :) Changed the test and pushed, let's see what Travis thinks.

[wchristian]

Looks like the most recent change doesn't quite do it:

ok 1 - glew version 1.1 reported correctly as 1 for 2.1
ok 2 - glew version 1.2 reported correctly as 1 for 2.1
ok 3 - glew version 1.3 reported correctly as 1 for 2.1
ok 4 - glew version 1.4 reported correctly as 1 for 2.1
ok 5 - glew version 1.5 reported correctly as 1 for 2.1
ok 6 - glew version 2.0 reported correctly as 1 for 2.1
ok 7 - glew version 2.1 reported correctly as 1 for 2.1
not ok 8 - glew version 3.0 reported correctly as 0 for 2.1
#   Failed test 'glew version 3.0 reported correctly as 0 for 2.1'
#   at t/02_glew_version_accessors.t line 39.
#          got: '1'
#     expected: '0'
not ok 9 - glew version 3.1 reported correctly as 0 for 2.1
#   Failed test 'glew version 3.1 reported correctly as 0 for 2.1'
#   at t/02_glew_version_accessors.t line 39.
#          got: '1'
#     expected: '0'
not ok 10 - glew version 3.2 reported correctly as 0 for 2.1
#   Failed test 'glew version 3.2 reported correctly as 0 for 2.1'
#   at t/02_glew_version_accessors.t line 39.
#          got: '1'
#     expected: '0'
not ok 11 - glew version 3.3 reported correctly as 0 for 2.1
#   Failed test 'glew version 3.3 reported correctly as 0 for 2.1'
#   at t/02_glew_version_accessors.t line 39.
#          got: '1'
#     expected: '0'
not ok 12 - glew version 4.0 reported correctly as 0 for 2.1
#   Failed test 'glew version 4.0 reported correctly as 0 for 2.1'
#   at t/02_glew_version_accessors.t line 39.
#          got: '1'
#     expected: '0'
ok 13 - glew version 4.1 reported correctly as 0 for 2.1
ok 14 - glew version 4.2 reported correctly as 0 for 2.1
ok 15 - glew version 4.3 reported correctly as 0 for 2.1
ok 16 - glew version 4.4 reported correctly as 0 for 2.1
not ok 17 - glew version 4.5 reported correctly as 0 for 2.1
#   Failed test 'glew version 4.5 reported correctly as 0 for 2.1'
#   at t/02_glew_version_accessors.t line 39.
#          got: '1'
#     expected: '0'

[devel-chm]

The code for all the GLEW_* accessors is identical. My guess is the answer depends on what type of context you requested. The default is back compatible but that may not be compatible with the latest core functionality. I'll continue to investigate here.

[devel-chm]

@wchristian: Could you please clarify---for the incorrectly reported GLEW_VERSION_M_N, does the functionality actually work even though the state variable is claiming not?

[wchristian]

What happens is that the gl version is 2.1, so i'd expect only things below that to be there. However surprisingly for 3.1 - 4.0 it gets 1 from the GLEW calls, unexpectedly, then the 4.1 - 4.4 ones behave as expected and return 0, and the 4.5 call again returns 1; despite the GL version being only 2.1.

[wchristian]

That aside i'm not sure what you mean with "functionality works". If you look at the test code it only calls the GLEW version calls and compares their output.

[devel-chm]

This may have to do with the use of the glewExperimental = GL_TRUE for the glewInit call. What happens if you change that to GL_FALSE and rebuild?

[wchristian]

Ok, tried deleting the line to see if it helps, didn't, just now pushed a branch where it's explicitly set to GL_FALSE, maybe that helps.

[wchristian]

No change in outcome.

[devel-chm]

Thanks for the followup. On my machine, the results are the same as from the glewinfo program that comes with the GLEW distribution. Since I'm not in a position to check the GLEW_VERSION_N_M result with attempts to use the relevant OpenGL API functions, I'm going to assume this is a potential issue that appears to come from the GLEW sources and not from our bindings.

[wchristian]

I'm not even sure if it's incorrect though. Maybe some higher version subsets can be available despite low gl version?

[wchristian]

I asked a friend with some experience with GL and it seems like the version is just a bound on what's guaranteed, but not a limit of what's not provided. So i guess i'll just have to have the test check all the variables below the version for 1, and the ones above for "not a crash".

I'll make the appropiate changes tomorrow.

[wchristian]

Ok, fixed it up and the test should have some use now at least.

[devel-chm]

Is this request still valid? My understanding is that checking the specific numbers is not 100% reliable. A test that the GLEW_* accessors return values is probably sufficient for a test (sort of an existence proof test).

[wchristian]

It is, see my last two messages before yours, also the changes i made to the code since. :)

[devel-chm]

Sorry, the test generation code wasn't clear as to whether it was fixed or not.

[wchristian]

Want me to add some comments to explain what it's doing?

[devel-chm]

Nope, still fails which doesn't mean the code is broken, just that the OpenGL context/implementation is not reporting things correctly. How about wrapping the whole thing in a TODO block so we can monitor the success or failure without generating false fails from CPAN Testers?

[wchristian]

Paste the fail here please for future reference. And sure, TODO wrapping should be interesting. Want me to do it?

[devel-chm]

make test Running Mkbootstrap for OpenGL::Modern () chmod 644 "Modern.bs" PERL_DL_NONLAZY=1 "/usr/bin/perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/.t t/00_basic.t ................... ok
t/01_context.t ................. ok
t/02_glew_version_accessors.t .. 1\/? # Failed test 'glew version 4.5 reported as 1 for 4.5' # at t/02_glew_version_accessors.t line 41. # got: '0' # expected: '1' # Looks like you failed 1 test of 17. t/02_glew_version_accessors.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1\/17 subtests t/02_glGetShaderInfoLog.t ...... ok
t/0999_tidy.t .................. ok

Test Summary Report ------------------- t/02_glew_version_accessors.t (Wstat: 256 Tests: 17 Failed: 1) Failed test: 17 Non-zero exit status: 1 Files=5, Tests=26, 3 wallclock secs ( 0.03 usr 0.05 sys + 1.65 cusr 0.68 csys = 2.41 CPU) Result: FAIL Failed 1\/5 test programs. 1\/26 subtests failed. make: *** [Makefile:1058: test_dynamic] Error 255

[devel-chm]

I would appreciated it.

[wchristian]

Added comments and marked the tests todo.

[devel-chm]

Is there a reason the test number begins with 02 instead of 03?

[wchristian]

The numbers just specify phasing, outside of being run after the context check i don't particularly care in which order they're run. Feel free to modify if you have an opinion on the order. :)