Felix Krause

Great work! Probably better test code is the one with nodes which actually uses anchors & aliases – the code you posted only assures the cast compiles but never uses...

Fair enough. I'll reopen the issue. The error in your code is unrelated to `ref` types. Here's an edit that only calls the parser: ```nim when true: import yaml proc...

~~Blocked by nim-lang/Nim#4635~~ has been fixed

Blocked by nim-lang/Nim#4802 workaround in place. work on this continues.

It is not ideal to add an interface to GLFW functionality that downgrades that functionality (by supporting only a single image). Even if we consider that full functionality might be...

> My only concern is how strict the interface definition should be - for example, whether or not the width/height should be allowed to be 0. Well width/height of 0...

> Glfw expects the caller to pass an array of icons See the `Image_Data` type above. I was a bit careless and gave it the same name as the `Image_Data`...

The one-item `Set_Icon` is fine. Can you make `Images` of the imported function be `Image_Data_Array` since that's possible and safer than declaring it to be an address? > The only...

> Well, this would require the API to know about Image_Data, and, by extension. Pixel_Data_Ref (and Pixel_Data). Moving these types over to Glfw.API means the caller no longer sees Pixel_Data,...

> From what I can see, using an anonymous access type for the pixel data does not give us any benefits here. But perhaps I'm missing something? If we don't...