[HOpenGL] Hello HOpenGL

[Alexander Göransson]

Apparently sent this to only Balazs yesterday by mistake. Here's my proposal.

 // A

2011/6/15 Alexander Göransson <alexander.goransson at gmail.com>:
> Hi!
>
> I almost never read reddit comments (don't have an account) so I
> missed that. Anyway, here's my proposal that Jason managed to dig up
> (I can't even access it myself anymore). Mind you that the general
> plan has sort of deviated since writing this (as i learned more and
> more about OpenGL). The final version will indeed depend on OpenGL
> 2.1. I've thought out a versioning schema that works like the modules
> Core31 and Core32 works in OpenGLRaw at the moment.
>
> ////////////////////////////////////////////////////////////////////////
>
> Haskell OpenGL bindings
> Motivation
>
> As of now the Haskell OpenGL bindings are in great need of updates.
> The current maintainer (Sven Panne) has gone missing - not replying to
> e-mails (more than one month has passed since contact attempts
> started) and the last update to either library was in september 2009.
> Considering that OpenGL (and OpenGLRaw) is part of the "Haskell
> Platform", this is a big problem.
>
> The current version of "OpenGL" (
> http://hackage.haskell.org/package/OpenGL ) still has bindings to
> functions using the fixed function pipeline. Open GL 3.1, which
> removed all fixed function options and direct modes, was released in
> March 2009. This simplification of the C API has yet to be visible in
> haskell.
>
> Something else that needs fixing is removing as much of the
> statefulness of the library "OpenGL" as possible. OpenGL applications
> are also prone to programmer mistakes which might cause crashes.
> Haskell programs shouldn't crash (they should only eloquently nag you
> about doing things the wrong way).
>
> Proposal
>
> A new API.
>
> This would be a new major version of the hackage package "OpenGL",
> leaving everything that got deprecated with 3.0 behind ("fixed
> function" functionality, such as primitive mode or display lists) and
> fully focusing on programming with shaders. Benefits of dropping the
> old API would be having a more uniform way to do rendering, with
> redundant legacy mechanisms removed.
>
> I aim to make abstractions hiding the statefulness of OpenGL as much
> as possible. The API should also be a safe one - writing incorrect
> programs should be prevented as much as possible.
>
> The new API will also be much more open than the previous version -
> exposing internal modules and hiding as few implementations as
> possible.
>
> What to deliver
>
> Improved OpenGLRaw bindings
>
> Adding support for OpenGL 4.0 to -Raw and generally improving it (this
> will also be a step to famliiarize myself with it).
>
> Intermediate/nice library
>
> A library with more haskell-y types ("OpenGLRawNice"?), which would
> essentially be OpenGLRaw but with more type safety. One example is
>
> "glShaderSource :: GLuint -> GLsizei -> Ptr (Ptr GLchar) -> Ptr GLint -> IO ()"
>
> which could be
>
> "glShaderSource :: GLuint -> Int -> [String] -> Int -> IO ()".
>
> Other things that should be done in this library is creating
> constructors for all the enum-like constructors that exists in OpenGL,
> like bitmasks. Lots of code from the current version of "OpenGL" can
> be used for this.
>
> User friendly library
>
> This would be the new major version of OpenGL which only supports
> programmable shading. This library will be very type safe (unlike
> Raw/Nice). Support for common actions, like projections, will be added
> through bindings to a suitable library (hmatrix seems appropriate).
>
> To abstract away the stateful nature of OpenGL the API could expose a
> lot of 'with*' functions, similar to functions like 'withBinaryFile ::
> FilePath -> IOMode -> (Handle -> IO r) -> IO r'. Something like
> 'withVertexShader :: BufferObject VertexShader -> Shader a -> IO ()'
> could be created (here 'Shader' would be a DSL for describing
> interactions with a shader program).
>
>
>
> Community Support
>
> I have received positive feedback for this proposal by Jason Dagit
> (who, I hope, will be my mentor) and Conal Elliott. Conal Elliott has
> expressed interest in consulting with me in this project.
>
> ////////////////////////////////////////////////////////////////////////
>
> On 15 June 2011 22:18, Balazs Komuves <bkomuves at gmail.com> wrote:
>>
>> Hi,
>>
>> First of all, let me be clear in that I don't think the maintenance politics
>> is the most important thing here; however I'm all for more transparency,
>> and more public feedback before sudden ad-hoc changes (especially
>> when they go against my subjective tastes).
>>
>> I think the not very transparent part was declaring yourself the maintainer
>> without having any public feedback. Also, the summer of code project
>> application was completely opaque, I've yet to see even the proposal,
>> and I'm here, on the libraries list, on reddit, I read the cafe archives,
>> tried to google it, and even asked for it explicitly on reddit.
>>
>> Anyway, we should probably focus our energies on more meaningful stuff.
>>
>>
>>> Maybe we can get your frame buffer objects in to the newer bindings?
>>
>> Yes, of course I'm happy to help with it. However the patch was written
>> back before the OpenGL / OpenGLRaw split, so it's probably needs
>> some extra work to make it work with the current bindings, and I'm not
>> familiar with the new code base.
>>
>> The patches are in this darcs patch file, the ones with "FBO" in the
>> description:
>> http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch
>>
>>
>>>  * Putting the repos on github
>>>  * Updating the Haskell wiki to point to github
>>>  * Creating a haskell-opengl organization on github to organize the
>>> development efforts
>>
>> I'm not familiar with either git or github. Was the switch from darcs was
>> really justified at this point? I know that many people consider git/github
>> the best thing since sliced bread, but I fail to get the hype at the moment.
>>
>> Furthermore, the haskell community server should have infrastructure
>> like bug-tracker etc already in place (or at least that was the case
>> before the server migration saga).
>>
>> Balazs
>>
>>
>>>
>>> >> Sven is no longer the maintainer, so we don't have to think too hard
>>> >> about
>>> >> what he would do. We can make all the necessary decisions ourselves.
>>> >
>>> > Well, they way this change happened is arguably not completely
>>> > transparent...
>>>
>>> I did my best to be transparent about it.  I made sure to email this
>>> list, haskell-cafe, haskell, and the libraries list asking if anyone
>>> had heard from Sven.  I waited about a month before taking action.  He
>>> still hasn't reappeared.
>>>
>>> I have no desire to take control by force but I do think Sven has
>>> effectively stopped maintaining these libraries and I don't want to
>>> see them disappear.  Do you have advice on what I should have done
>>> differently?
>>>
>>> The only actions I've taken at this point are:
>>>  * Declaring myself maintainer
>>>  * Putting the repos on github
>>>  * Updating the Haskell wiki to point to github
>>>  * Creating a haskell-opengl organization on github to organize the
>>> development efforts
>>>
>>> The Haskell-opengl org is here, if anyone on this list wants to join
>>> please send me an email:
>>> https://github.com/haskell-opengl
>>>
>>> One of the things I have NOT done yet is to upload new versions of the
>>> libraries to hackage.  I thought I would wait a bit longer than just a
>>> month before doing that in case announcing a new maintainer prompted
>>> Sven to reappear.  It would be good to upload some bug fixes soon-ish
>>> though.
>>>
>>> >
>>> > Anyway, there are objective reasons to make a different package: Apart
>>> > from
>>> > those I mentioned
>>> > in my last email, we actually have hands-on experience what happens when
>>> > a
>>> > big rewrite
>>> > happens the way you suggest, namely the parsec package, which still
>>> > causes
>>> > serious pains
>>> > years later. We have parsec v2.x, parsec v3.x, parsec1, parsec2 and
>>> > parsec3
>>> > on Hackage;
>>> > that's five versions in four packages with different maintainers, all
>>> > because of one wrong decision.
>>> > And arguably parsec2 vs. parsec3 is a much smaller change than what you
>>> > plan.
>>> >
>>> > Furthermore, let's suppose the completely realistic situation one would
>>> > like
>>> > to use both the
>>> > old and the new versions of the OpenGL package. This is
>>> > next-to-impossible
>>> > when it is the
>>> > same package (and painful in any case), since other libraries you want
>>> > to
>>> > use but depend
>>> > on OpenGL have to be recompiled each time. I again have hands-on
>>> > experience
>>> > with this,
>>> > as I maintain a private branch the (very) old (before OpenGLRaw) OpenGL
>>> > binding since I use
>>> > frame buffer objects and other functionality not in the official
>>> > package.
>>> > Arguably, this is an
>>> > issue of Cabal, but I have no high hopes for Cabal to solve this in the
>>> > near
>>> > future, and anyway,
>>> > we should make life more painful just because.
>>>
>>> Maybe we can get your frame buffer objects in to the newer bindings?
>>>
>>> Thanks,
>>> Jason
>>
>>
>