On Fri, Oct 26, 2012 at 1:53 PM, Mikhail Glushenkov < the.dead.shall.r...@gmail.com> wrote:
> Hi Jason, > > On Fri, Oct 26, 2012 at 8:24 PM, Jason Dagit <dag...@gmail.com> wrote: > > > > If you test this, please let me know what you learn. > > OK. > > > It may be possible to backport this. Unfortunately, it's not as easy as > it > > should be. I believe the version of the OpenGL libraries in the platform > are > > before the low-level bindings were factored out of the high level > packages. > > This means that I don't know if the the release that needs the backport > is > > even in the repository history. > > Can you point me at the commit you're talking about? Maybe I can > backport it myself. > https://github.com/haskell-opengl/OpenGL/commit/0de14b7378e3c3fde88b472bd21a80d61fd5ef48 But where will the modified source live? Only on hackage? > > > From my point of view, it would be ideal if the HP could use the most > recent > > versions of the OpenGL packages. > > I did not follow that discussion. What are the reasons not to ship the > most recent versions? > One problem is that when the libraries were refactored they were split into different packages. For example, we have OpenGL and OpenGLRaw now, with OpenGLRaw containing the lowest level binding to the C api. The *Raw packages are not yet in the HP. In addition to the *Raw packages, StateVar, Tensor, and ObjectName were also factored out. Basically, we would have to add the following packages to the platform if we want to include the latest OpenGL packages: * OpenGLRaw * GLURaw * StateVar * ObjectName * Tensor At least StateVar has been considered controversial in the past as it introduces Data.StateVar as a module name, and that was seen as a bad introduction to Haskell for beginners. While Data.StateVar could be moved under the OpenGL module namespace (Graphics.Rendering.OpenGL.*) this would do a disservice to all the bindings Sven Panne created (OpenGL, GLUT, OpenAL, ALUT, to name a few). StateVar is a useful abstraction over readIORef and writeIORef to work with the opaque handle types that OpenGL/OpenAL uses. If the platform had some other abstraction for solving this problem (maybe one of the lenses implementations would work here?), then I could probably be persuaded to switch to it. I hope that clarifies, Jason
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
