I'm (still) building the up-to-date opengl binding for Racket. It's substantially more difficut than I thought.
As some of you know, the existing OpenGL binding is generated from files supplied by the standards orgaisation Khronos. Being automatically gnerated, it was quite complete. However, it is obsolete. Even the first simple exercises from the authoritative so-called Red Book can no longer be translated into Racket. I undertook to update it, planning to simply rerun the same code on the current version of the Khronos files. Didn't work, because those files have not been updated. Instead they have been replaced with new files satisfying the same purpose, but in a completely different file format -- xml. The old code no longer works on the new files. Since I really wanted to use up-to-date OpenGL, I resolved to write a new transpiler, from the new Khronos file format to the same old Racket language. I thought I would just have to replace the parser in the previus opengl version. I expected that debugging would be feasible by comparing the files I generate with the files generated by the old opengl package. Most of the content should be identical. (this last generated bit at least, has turned out to be true!) I was faced with several challenges: * Really learning Racket. Up to now I've just been coding around the edges of Racket so to speak. I like the language. And despite running in an interpreter, that's Ok for computation-intensive graphics work because most of the computation gets passed off to a separate processor, the GPU. * Figuring out the poorly documented code in the otherwise excellent original version of the transpiler. * learning OpenGL. I've used it before, but the arrival of shaders has completely turned it inside-out. * Deciphering the Khronos files. The XML isn't much of a barrier -- Racket's sxml package does the heavy lifting. However, Khronos's use of xml doesn't have much to do with *any* current undersanding of programming language semantics. Its xml syntax doesn't, for example, understand that functions have function types. Instead, the declaration of a function is split into two separate parts: a prototype and some parameters. The prototype contains the function name and its return type, together with a few random extras such as asterisks. An asterisk is there to indicate that the function doesn't return the indicated type, but a pointer to it. But there's no syntactic understanding that there's such a thing as a pointer type, and that the abstract syntax for a pointer type should contain the thye of the thing pointed to. Similarly, there's no concept of a function type. It's kind of a transcription of C. --- So, given all that, I've been flailing around with my code, managing to produce a lot of mostly correct binding. That's, of course, not good enough. What has happened is that I'm starting to understand the obstacles that have to be overcome. And that's a huge help in figuring out the original versino of the transpiler. My original plan of replacing the parser in the original version is starting to seem feasible now. However, properties of the original syntax reach far into the innards of its code generator. I'm not giving up. I will proceed. What I'll likely end up with is some kind of amalgam of the old code and parts of the new code I've already written. There will be success, unless I come down with coronavirus and die first. -- hendrik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20200411153018.jju2lwh5fsgsmust%40topoi.pooq.com.
