Re: [Haskell-cafe] ANN: Haskell OpenGL package updates
The biggest problem with the RULES based approach is that if you are in a
context where the RULES don't or can't fire, then your semantics silently
change. This leads to subtle bugs which only show up in ghci, etc.
On Friday, October 28, 2011, Jason Dagit dag...@gmail.com wrote:
On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett ekm...@gmail.com wrote:
Jason,
Thank you for taking ownership of HOpenGL!
Thanks!
I would like to make a formal request for there to be some way to get
access
to either
Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal
or that
Graphics.Rendering.OpenGL.Raw.Core31.Types
re-export the newtype wrappers it places around CDouble and CFloat.
As things stand the only way to work with them is to pointlessly
round-trip
through rational or pray that GHC is smart enough to automatically
convert
once it sees through the newtype, which it isn't, potentially costing me
orders of magnitude of performance in tight loops in exchange for
implementation freedom the current OpenGL bindings do not use on any
platform.
Yes, it's a real problem. I think there are a couple directions we
could move in (and some may not even be mutually exclusive).
Andy Gill created this workaround:
{-# RULES realToFrac/a-GLfloat realToFrac = \x - GLfloat (realToFrac
x)
#-}
{-# RULES realToFrac/GLfloat-a realToFrac = \(GLfloat x) - realToFrac
x
#-}
That one helps a lot for most people.
Someone made a libraries proposal that also helps the conversion
situation but I don't have the details handy at the moment.
If you read here, I'd like to get some MArray support in and I think
it's possible, although I haven't the idea I proposed yet:
http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html
Another thing we could do is find a different balance between newtypes
and the C types.
I'm totally onboard with exposing all of OpenGLRaw. I think we just
need to sufficiently document the internal bits so that only people
who absolutely need them will use them. That's how I see ByteString
and it seems to be working there.
Thanks for your suggestion (and your pull request on github, yay for
collaborative tools!).
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Haskell OpenGL package updates
Several months ago I announced my intent to take over maintainership of the Haskell OpenGL bindings and associated packages. Today I have pushed new minor revisions to hackage. I have updated the following packages: * OpenGL * OpenGLRaw * GLURaw * GLUT The change log is very minor for each of these. For my first release as the new maintainer I opted to be very conservative about changes. Consider this a bug fix release with updated metadata. Please report bugs to either the Haskell OpenGL mailing list or the appropriate issue tracker on the github page: http://www.haskell.org/mailman/listinfo/hopengl https://github.com/haskell-opengl I would like to give a big thank you to the following individuals: Sven Panne Lars Corbjin Dylan Simon Alexey Karakulov Balazs Komuves If you contributed to this release by giving advice, filing a bug report, sending a patch, or in some other way, and I've not listed your name then I apologize for the omission. Going forward I could use help with testing, development, and documentation so if you're interested in OpenGL and Haskell let me know and also keep your eyes out for calls for volunteers. Thank you! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell OpenGL package updates
Jason, Thank you for taking ownership of HOpenGL! I would like to make a formal request for there to be *some* way to get access to either Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal or that Graphics.Rendering.OpenGL.Raw.Core31.Types re-export the newtype wrappers it places around CDouble and CFloat. As things stand the only way to work with them is to pointlessly round-trip through rational or pray that GHC is smart enough to automatically convert once it sees through the newtype, which it isn't, potentially costing me orders of magnitude of performance in tight loops in exchange for implementation freedom the current OpenGL bindings do not use on any platform. -Edward On Fri, Oct 28, 2011 at 9:30 AM, Jason Dagit dag...@gmail.com wrote: Several months ago I announced my intent to take over maintainership of the Haskell OpenGL bindings and associated packages. Today I have pushed new minor revisions to hackage. I have updated the following packages: * OpenGL * OpenGLRaw * GLURaw * GLUT The change log is very minor for each of these. For my first release as the new maintainer I opted to be very conservative about changes. Consider this a bug fix release with updated metadata. Please report bugs to either the Haskell OpenGL mailing list or the appropriate issue tracker on the github page: http://www.haskell.org/mailman/listinfo/hopengl https://github.com/haskell-opengl I would like to give a big thank you to the following individuals: Sven Panne Lars Corbjin Dylan Simon Alexey Karakulov Balazs Komuves If you contributed to this release by giving advice, filing a bug report, sending a patch, or in some other way, and I've not listed your name then I apologize for the omission. Going forward I could use help with testing, development, and documentation so if you're interested in OpenGL and Haskell let me know and also keep your eyes out for calls for volunteers. Thank you! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell OpenGL package updates
On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett ekm...@gmail.com wrote:
Jason,
Thank you for taking ownership of HOpenGL!
Thanks!
I would like to make a formal request for there to be some way to get access
to either
Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal
or that
Graphics.Rendering.OpenGL.Raw.Core31.Types
re-export the newtype wrappers it places around CDouble and CFloat.
As things stand the only way to work with them is to pointlessly round-trip
through rational or pray that GHC is smart enough to automatically convert
once it sees through the newtype, which it isn't, potentially costing me
orders of magnitude of performance in tight loops in exchange for
implementation freedom the current OpenGL bindings do not use on any
platform.
Yes, it's a real problem. I think there are a couple directions we
could move in (and some may not even be mutually exclusive).
Andy Gill created this workaround:
{-# RULES realToFrac/a-GLfloat realToFrac = \x - GLfloat (realToFrac x)
#-}
{-# RULES realToFrac/GLfloat-a realToFrac = \(GLfloat x) - realToFrac x
#-}
That one helps a lot for most people.
Someone made a libraries proposal that also helps the conversion
situation but I don't have the details handy at the moment.
If you read here, I'd like to get some MArray support in and I think
it's possible, although I haven't the idea I proposed yet:
http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html
Another thing we could do is find a different balance between newtypes
and the C types.
I'm totally onboard with exposing all of OpenGLRaw. I think we just
need to sufficiently document the internal bits so that only people
who absolutely need them will use them. That's how I see ByteString
and it seems to be working there.
Thanks for your suggestion (and your pull request on github, yay for
collaborative tools!).
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
