ANN: Haskell OpenGL package updates

Jason Dagit <dagitj <at> gmail.com>
2011-10-28 13:30:11 GMT

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/hopenglhttps://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.

Re: ANN: Haskell OpenGL package updates

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.

Re: [Haskell-cafe] ANN: Haskell OpenGL package updates

Jason Dagit <dagitj <at> gmail.com>
2011-10-28 23:09:31 GMT

On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <ekmett <at> 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

Re: [Haskell-cafe] ANN: Haskell OpenGL package updates

Edward Kmett <ekmett <at> gmail.com>
2011-10-30 16:18:34 GMT

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 <dagitj <at> gmail.com> wrote:> On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <ekmett <at> 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>