Make sure that these modules actually compile

[lizmat]

A ticket was created for your module for today's Squashathon. I looked at the code and fixed the syntax errors so that the modules actually compile. But since there are no tests, I have no idea if they actually work or not.

[YellowApple]

Thanks! The semicolon edits should be fine. Removing the our declarators will have implications for how those subs are exported (i.e. they won't be until I shove is export in there), but that's obviously better than not compiling at all. Merging :)

Yeah, there aren't any tests yet. I haven't figured out a good way to actually test something designed to create desktop windows with 3D graphics, but as soon as I do there will eventually be tests.

I replied to the ecosystem-unbitrot issue with some info on the native dependency on GLFW. I'll see about getting that in README.md; I was operating under the assumption that anyone wanting to install this already knows what GLFW is/does and would therefore have it already installed, but obviously that doesn't apply for whole-ecosystem testing projects :)

[AlexDaniel]

Yeah, there aren't any tests yet. I haven't figured out a good way to actually test something designed to create desktop windows with 3D graphics, but as soon as I do there will eventually be tests.

What about headless rendering and then perhaps writing the view to an image and saving it (so that it can be compared in tests)?

[YellowApple]

What about headless rendering

The issue is that GLFW is specifically intended to handle creating windows for OpenGL (or Vulkan) contexts. I suppose it's indeed possible to write tests for the 3D rendering itself, but I reckon that'd be out of scope for this particular package (I've been working on p6-GL and p6-Vulkan packages to that effect, and those would be better places for those particular tests).

I guess the relevant tests here would be along the lines of the following:

• Does the test program (doc/examples/test.pl6, or perhaps a more comprehensive replacement) run with a zero exit code (i.e. it doesn't crash or throw some other kind of error)?

• Does the test program obtain an OpenGL context on systems which support OpenGL?

• Does the test program obtain an OpenGL ES context on systems which support OpenGL ES?

• Does the test program obtain a Vulkan context on systems which support Vulkan?

• Does the test program display a window?

• Does the test program's displayed window correspond to the OpenGL (ES) or Vulkan context being tested (as described above)?

• Does the test program's window display the right things (this would be where 3D rendering would be relevant)?

• Does the test program's window respond correctly to inputs?

• Does the test program detect window closure?

• Etc...

The main theme here is that we'd need to create a window and run the tests against that. I know it's technically possible; I just haven't built it yet :)

Either way, I suspect a graphical environment is effectively a dependency for this package (by way of GLFW itself), so any test rig y'all are using would in turn need to support a GUI of some kind (whether it's a Windows/macOS desktop or a traditional Unix/Linux box with X11). Even that first test (does the test program even run) will likely fail without a graphical environment. The subsequent tests might be possible with "just" OpenGL or Vulkan, but the contexts GLFW creates tend to be geared toward desktop windows instead of things like GPU computing or headless rendering.

[AlexDaniel]

@YellowApple it's also an option to write some tests that don't run by default (and only run if AUTHOR_TESTING is set).