4 ms·

Go-gl: Massive Overhaul

53 points by slimsag 12y ago

zellyn 12y ago
To save you the searching and reading, glfw is a lightweight cross-platform library for opening windows, and getting input: opengl specifies only rendering in framebuffers, so you need something else to open the windows and get input.
cdelsolar 12y ago
Wat
- slimsag 12y ago
  Basically: to make OpenGL apps in Go you used to have to install a bunch of headers and libraries, and it was a real pain. We fixed it a long time ago, but people used the old version so much we didn't want to break anything. We're finally forcing people onto the new code, and also ensuring we don't end up in this situation again.
  - pjtr 12y ago
    Why didnt' you simply put a big red flashy banner on the go-gl repo pointing to the preferred repo?
    - slimsag 12y ago
      It's explained pretty well in the doc -- but basically for consistency and ease of use for newcomers. No point in having a bunch of "DONT USE THIS CODE" repositories everywhere. Its confusing. Instead, we have a way going forward to have people see the latest and greatest code with minimal cruft.
  - lloeki 12y ago
    > to make OpenGL apps in Go you used to have to install a bunch of headers and libraries, and it was a real pain. Not quite the case (brew install glew glfw3 on OSX), but the problem is more that it requires cgo at all. One or two years ago I tried to use a package (I can't remember the name of and I'm at work) which was pure go for GL bindings, generated from the OpenGL specs, but it lacked a few wrappings and boxings here and there, making some calls particularly ugly and really not trivial, so I fell back to go-gl/gl (which requires glew). Of course you still need to link with something (such as glfw) that pops up a window, but that's one thing less to achieve cross-compilation. BTW with recent Go it works fine when built as a dylib, it's just tougher to distribute (on OS X at least, due to stored paths). From a more general dependency management PoV, I'm a bit anxious about how this is handled though, as this sets an uneasy precedent. "Forcing" the change is unwelcome this way as it significantly breaks the compatibility promise. Short of solutions like semantic versioning dependency management systems, the Go community has been idiomatically handling such incompatibilities at the library name level (foo, foo2, foo3 or bar.v1, bar.v2, bar.v3, or straight up another name). When handling such situations I'd rather have deprecation warnings on the README and when calling the code, pointing people to the new location, but keeping my current code working. Anyway, I'm really glad things have progressed on the pure Go front as this really makes things easier for everyone. Vendoring glfw 3.1 is an interesting strategy.
    - slimsag 12y ago
      > Not quite the case (brew install glew glfw3 on OSX) Sure, for OS X and Linux distros. What about Windows? No external dependencies is better all around. > but the problem is more that it requires cgo at all. You'll always be using CGO to make C calls, which OpenGL is. > One or two years ago I tried to use a package (I can't remember the name of and I'm at work) which was pure go for GL bindings, generated from the OpenGL specs, but it lacked a few wrappings and boxings here and there, making some calls particularly ugly and really not trivial, so I fell back to go-gl/gl (which requires glew). You'd be talking about Glow, most likely. For which the document outlines, is replacing go-gl/gl. It's gotten a lot nicer and works much better. > Of course you still need to link with something (such as glfw) that pops up a window, but that's one thing less to achieve cross-compilation. BTW with recent Go it works fine when built as a dylib, it's just tougher to distribute (on OS X at least, due to stored paths). You don't have to deal _at all anymore_ after this change! =) The Go tool builds the C sources directly, as it would Go source files. No external library installation needed: it's included. > From a more general dependency management PoV, I'm a bit anxious about how this is handled though, as this sets an uneasy precedent. "Forcing" the change is unwelcome this way as it significantly breaks the compatibility promise. Short of solutions like semantic versioning dependency management systems, the Go community has been idiomatically handling such incompatibilities at the library name level (foo, foo2, foo3 or bar.v1, bar.v2, bar.v3, or straight up another name). When handling such situations I'd rather have deprecation warnings on the README and when calling the code, pointing people to the new location, but keeping my current code working. I promise you personally that we are fully aware of the issues and breaking backwards compatibility with this change. For that exact reason we've announced it loud and clear. Myself and many other people whom I consider very smart were involved in this decision, which was not taken lightly. We chose what we believe to be the best path: breaking compatibility today, for a future where we will likely never have to again. I enjoyed reading your thoughts, and I think this will do you a lot of good should you try using the packages again =)
      - lloeki 12y ago
        > You'll always be using CGO to make C calls, which OpenGL is. you're right. > You'd be talking about Glow, most likely Found it! https://github.com/chsc/GoGL https://github.com/chsc/GoGL > breaking compatibility today, for a future where we will likely never have to again. I hope so! The new scheme looks solid enough not to have to change again. Great work. Thanks for your clear and supportive answers :-)
peterwaller 12y ago
I started go-gl (the github organisation) with the intent of things never breaking underfoot. I'm really proud of what other people in the community have subsequently brought to the table over the last three years. It was not a decision taken lightly and these changes had wide agreement from all of the maintainers of the go-gl projects old and new. Sadly this big change causes some temporary breakage for code in the wild (you just need to change /go-gl/ to /go-gl-legacy/ in the import path), but it's for the benefit of all future code. Hopefully it won't be necessary again for a long while.
tree_of_item 12y ago
Is there any planned interaction between go-gl and https://github.com/golang/mobile/ https://github.com/golang/mobile/ ? The Go developers seem to have written some useful OpenGL related libraries, particularly http://godoc.org/golang.org/x/mobile/sprite http://godoc.org/golang.org/x/mobile/sprite .
- shurcooL 12y ago
  There is ongoing work, first we want to tackle golang.org/x/mobile/f32 and github.com/go-gl/mathgl, after that we can start thinking about GL bindings. There is an open CL about it, but it's moving along very very slowly. :(
rhodysurf 12y ago
I understand the change from methods to functions to match OpenGL, but the old bindings (go-gl/gl) were easy to use and much better than writing C. I just dont see why I'd use Go over C for this now the syntax is pretty much exactly the same.

53 points by slimsag 12y ago

To save you the searching and reading, glfw is a lightweight cross-platform library for opening windows, and getting input: opengl specifies only rendering in framebuffers, so you need something else to open the windows and get input.

cdelsolar 12y ago

Wat

slimsag 12y ago
Basically: to make OpenGL apps in Go you used to have to install a bunch of headers and libraries, and it was a real pain. We fixed it a long time ago, but people used the old version so much we didn't want to break anything. We're finally forcing people onto the new code, and also ensuring we don't end up in this situation again.
- pjtr 12y ago
  Why didnt' you simply put a big red flashy banner on the go-gl repo pointing to the preferred repo?
  - slimsag 12y ago
    It's explained pretty well in the doc -- but basically for consistency and ease of use for newcomers. No point in having a bunch of "DONT USE THIS CODE" repositories everywhere. Its confusing. Instead, we have a way going forward to have people see the latest and greatest code with minimal cruft.
- lloeki 12y ago
  > to make OpenGL apps in Go you used to have to install a bunch of headers and libraries, and it was a real pain. Not quite the case (brew install glew glfw3 on OSX), but the problem is more that it requires cgo at all. One or two years ago I tried to use a package (I can't remember the name of and I'm at work) which was pure go for GL bindings, generated from the OpenGL specs, but it lacked a few wrappings and boxings here and there, making some calls particularly ugly and really not trivial, so I fell back to go-gl/gl (which requires glew). Of course you still need to link with something (such as glfw) that pops up a window, but that's one thing less to achieve cross-compilation. BTW with recent Go it works fine when built as a dylib, it's just tougher to distribute (on OS X at least, due to stored paths). From a more general dependency management PoV, I'm a bit anxious about how this is handled though, as this sets an uneasy precedent. "Forcing" the change is unwelcome this way as it significantly breaks the compatibility promise. Short of solutions like semantic versioning dependency management systems, the Go community has been idiomatically handling such incompatibilities at the library name level (foo, foo2, foo3 or bar.v1, bar.v2, bar.v3, or straight up another name). When handling such situations I'd rather have deprecation warnings on the README and when calling the code, pointing people to the new location, but keeping my current code working. Anyway, I'm really glad things have progressed on the pure Go front as this really makes things easier for everyone. Vendoring glfw 3.1 is an interesting strategy.
  - slimsag 12y ago
    > Not quite the case (brew install glew glfw3 on OSX) Sure, for OS X and Linux distros. What about Windows? No external dependencies is better all around. > but the problem is more that it requires cgo at all. You'll always be using CGO to make C calls, which OpenGL is. > One or two years ago I tried to use a package (I can't remember the name of and I'm at work) which was pure go for GL bindings, generated from the OpenGL specs, but it lacked a few wrappings and boxings here and there, making some calls particularly ugly and really not trivial, so I fell back to go-gl/gl (which requires glew). You'd be talking about Glow, most likely. For which the document outlines, is replacing go-gl/gl. It's gotten a lot nicer and works much better. > Of course you still need to link with something (such as glfw) that pops up a window, but that's one thing less to achieve cross-compilation. BTW with recent Go it works fine when built as a dylib, it's just tougher to distribute (on OS X at least, due to stored paths). You don't have to deal _at all anymore_ after this change! =) The Go tool builds the C sources directly, as it would Go source files. No external library installation needed: it's included. > From a more general dependency management PoV, I'm a bit anxious about how this is handled though, as this sets an uneasy precedent. "Forcing" the change is unwelcome this way as it significantly breaks the compatibility promise. Short of solutions like semantic versioning dependency management systems, the Go community has been idiomatically handling such incompatibilities at the library name level (foo, foo2, foo3 or bar.v1, bar.v2, bar.v3, or straight up another name). When handling such situations I'd rather have deprecation warnings on the README and when calling the code, pointing people to the new location, but keeping my current code working. I promise you personally that we are fully aware of the issues and breaking backwards compatibility with this change. For that exact reason we've announced it loud and clear. Myself and many other people whom I consider very smart were involved in this decision, which was not taken lightly. We chose what we believe to be the best path: breaking compatibility today, for a future where we will likely never have to again. I enjoyed reading your thoughts, and I think this will do you a lot of good should you try using the packages again =)
    - lloeki 12y ago
      > You'll always be using CGO to make C calls, which OpenGL is. you're right. > You'd be talking about Glow, most likely Found it! https://github.com/chsc/GoGL https://github.com/chsc/GoGL > breaking compatibility today, for a future where we will likely never have to again. I hope so! The new scheme looks solid enough not to have to change again. Great work. Thanks for your clear and supportive answers :-)

peterwaller 12y ago

I started go-gl (the github organisation) with the intent of things never breaking underfoot. I'm really proud of what other people in the community have subsequently brought to the table over the last three years. It was not a decision taken lightly and these changes had wide agreement from all of the maintainers of the go-gl projects old and new. Sadly this big change causes some temporary breakage for code in the wild (you just need to change /go-gl/ to /go-gl-legacy/ in the import path), but it's for the benefit of all future code. Hopefully it won't be necessary again for a long while.

tree_of_item 12y ago

Is there any planned interaction between go-gl and https://github.com/golang/mobile/ https://github.com/golang/mobile/ ? The Go developers seem to have written some useful OpenGL related libraries, particularly http://godoc.org/golang.org/x/mobile/sprite http://godoc.org/golang.org/x/mobile/sprite .

shurcooL 12y ago
There is ongoing work, first we want to tackle golang.org/x/mobile/f32 and github.com/go-gl/mathgl, after that we can start thinking about GL bindings. There is an open CL about it, but it's moving along very very slowly. :(

rhodysurf 12y ago

I understand the change from methods to functions to match OpenGL, but the old bindings (go-gl/gl) were easy to use and much better than writing C. I just dont see why I'd use Go over C for this now the syntax is pretty much exactly the same.