[HOpenGL] Haskell Types

Hi!

...

...

Adding support for OpenGL 4.0 to -Raw and generally improving it (this will also be a step to famliiarize myself with it). OpenGL 4 introduced around 110 new functions and some new flags and buffer modes. If you take the OpenGL 2 and 3 bindings as a base, it's not much work to build bindings for OpenGL 4.

...

...

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 ()". My bindings have always a raw version of a function and a haskell-type based function. You can access the raw version via glShaderSourceRaw.

...

...

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. I also worked on that. All client states are constructors, but I haven't converted all enums to constructors yet.

I am about to release my bindings this or next week. Greetings

...

Today's Topics:

1. Re: Hello HOpenGL (Alexander G?ransson) 2. Fwd: OpenGL 1 and 2 support (was RE: Hello HOpenGL) (Alexander G?ransson)

----------------------------------------------------------------------

Message: 1 Date: Thu, 16 Jun 2011 22:30:43 +0200 From: Alexander G?ransson Subject: Re: [HOpenGL] Hello HOpenGL To: hopengl@haskell.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1

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:

...

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

Apart 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

------------------------------

Message: 2 Date: Fri, 17 Jun 2011 00:45:01 +0200 From: Alexander G?ransson Subject: [HOpenGL] Fwd: OpenGL 1 and 2 support (was RE: Hello HOpenGL) To: hopengl@haskell.org Message-ID: Content-Type: text/plain; charset=windows-1252

shit... I *ALWAYS* miss checking where i'm sending my e-mails... This got sent directly to Sam and not to the list :/

// Alexander "t3h winrarz" G?ransson

---------- Forwarded message ---------- From: Alexander G?ransson Date: 2011/6/16 Subject: Re: [HOpenGL] OpenGL 1 and 2 support (was RE: Hello HOpenGL) To: Sam Martin

Ok, so right now it's going to look like this:

Say that X is the new namespace for OpenGL (will probably stay as Graphics.Rendering.OpenGL), then "Graphics.Rendering.OpenGL" will no longer be an importable module, instead you will have to choose a version. Provided modules (these will have sub-modules) will be

X.Core21 X.Core30 X.Core31 X.Core32 X.Core33 X.Core40 X.Core41

But Core21 and Core30 will *not* include any functions that were removed with Core31 (the version that said bye-bye to the fixed function pipeline). If you desire using any of those functions you can always use either OpenGLRaw (which will also expose a bunch more Core modules than before) or any old version of the OpenGL library. Also - none of these modules will actually require that you have their respective version available on your system. They will only require that you have support for the extensions that were promoted to Core for that module. This is good news for Mac users as well as *nix users not using any manufacturers binary driver.

?// Alexander

On 16 June 2011 10:59, Sam Martin wrote:

...

This was the only thing that jumped out at me in Alexander?s blog post.

...

...

Also I'm against dropping OpenGL 2.0 support, though that's a lesser problem if the new bindings is a different package. I don't remember getting any reply on that.

Having a new package that only focuses on more recent OpenGL support (i.e. 3 or 4) could well be a good idea. Having a smaller support window would, I imagine, allow the package to be more focused. Good things for those interested in working on high end graphics.

However, I?m definitely not in favour of seeing dropping OpenGL 1 or 2 support disappear entirely. These APIs will be significant for a number of years to come, particularly on mobile devices.

I?m not totally sure if this is what is on the cards though. Can anyone clarify?

Thanks, Sam

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

------------------------------

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

End of HOpenGL Digest, Vol 56, Issue 5 **************************************

------------------------------

Message: 2 Date: Fri, 17 Jun 2011 16:34:51 +0100 From: Hugo Gomes Subject: Re: [HOpenGL] Hello HOpenGL To: jesse@supremedeveloper.de Cc: hopengl@haskell.org Message-ID: Content-Type: text/plain; charset="utf-8"

Hi Jesse,

would you be interested in uploading your stuff to hackage ?

Thanks and keep up the good work :)

2011/6/17

...

Hi guys,

my name is Jesse Klugmann and I'm a young programmer and Haskell fanatic from Germany( I hope you can understand my english :P ) . I've created a small collection of different OpenGL bindings for Haskell in a small Lib called "LambdaGL". I've bindings for the following OpenGL versions:

* Version 2.1 * Version 3.3 * Version 4.1 * ES

LambdaGL is only a low level binding for Haskell and has no further features like monadic textures or state changes. I've used c2hs for all the binding stuff. My second big project( called FooFX ) is a general-purpose graphics library based on a monadic abstraction layer which includes a "GL Monad" and specified monads for textures, shaders, movements and buffers.

I've planned to build different GL monads with different purposes. On the one side I have a GL monad build for GL 4.1 and based on multithreading and on the other side I've a GL monad for older GL versions and for lower hardware specs. The user itself doesn't call any direct OpenGL functions, the user uses only a collection of specified monads and typeclasses.

All FooFX based programs are able to run their graphics computations completely multithreaded.

I'm very interested in building a new graphics infrastructure for Haskell. :)

Greetings, Jesse

...

Send HOpenGL mailing list submissions to hopengl@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/hopengl or, via email, send a message with subject or body 'help' to hopengl-request@haskell.org

You can reach the person managing the list at hopengl-owner@haskell.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of HOpenGL digest..."

Today's Topics:

1. Re: Hello HOpenGL (Alexander G?ransson) 2. Fwd: OpenGL 1 and 2 support (was RE: Hello HOpenGL) (Alexander G?ransson)

----------------------------------------------------------------------

Message: 1 Date: Thu, 16 Jun 2011 22:30:43 +0200 From: Alexander G?ransson Subject: Re: [HOpenGL] Hello HOpenGL To: hopengl@haskell.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1

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

// A

...

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

...

...

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

...

...

...

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

...

...

...

libraries to hackage. ?I thought I would wait a bit longer than just a month before doing that in case announcing a new maintainer

2011/6/15 Alexander G?ransson : proposal, this the 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

------------------------------

Message: 2 Date: Fri, 17 Jun 2011 00:45:01 +0200 From: Alexander G?ransson Subject: [HOpenGL] Fwd: OpenGL 1 and 2 support (was RE: Hello HOpenGL) To: hopengl@haskell.org Message-ID: Content-Type: text/plain; charset=windows-1252

shit... I *ALWAYS* miss checking where i'm sending my e-mails... This got sent directly to Sam and not to the list :/

// Alexander "t3h winrarz" G?ransson

---------- Forwarded message ---------- From: Alexander G?ransson Date: 2011/6/16 Subject: Re: [HOpenGL] OpenGL 1 and 2 support (was RE: Hello HOpenGL) To: Sam Martin

Ok, so right now it's going to look like this:

Say that X is the new namespace for OpenGL (will probably stay as Graphics.Rendering.OpenGL), then "Graphics.Rendering.OpenGL" will no longer be an importable module, instead you will have to choose a version. Provided modules (these will have sub-modules) will be

X.Core21 X.Core30 X.Core31 X.Core32 X.Core33 X.Core40 X.Core41

But Core21 and Core30 will *not* include any functions that were removed with Core31 (the version that said bye-bye to the fixed function pipeline). If you desire using any of those functions you can always use either OpenGLRaw (which will also expose a bunch more Core modules than before) or any old version of the OpenGL library. Also - none of these modules will actually require that you have their respective version available on your system. They will only require that you have support for the extensions that were promoted to Core for that module. This is good news for Mac users as well as *nix users not using any manufacturers binary driver.

?// Alexander

...

This was the only thing that jumped out at me in Alexander?s blog

On 16 June 2011 10:59, Sam Martin wrote: post.

...

...

...

Also I'm against dropping OpenGL 2.0 support, though that's a lesser problem if the new bindings is a different package. I don't remember getting any reply on that.

Having a new package that only focuses on more recent OpenGL support (i.e. 3 or 4) could well be a good idea. Having a smaller support window would, I imagine, allow the package to be more focused. Good things for those interested in working on high end graphics.

However, I?m definitely not in favour of seeing dropping OpenGL 1 or 2 support disappear entirely. These APIs will be significant for a number of years to come, particularly on mobile devices.

I?m not totally sure if this is what is on the cards though. Can anyone clarify?

Thanks, Sam

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

------------------------------

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

End of HOpenGL Digest, Vol 56, Issue 5 **************************************

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl