Re: [HOpenGL] Hello HOpenGL

Apparently sent this to only Balazs yesterday by mistake. Here's my proposal. // A 2011/6/15 Alexander Göransson :

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 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