- HOpenGL - Haskell.org

Haskell Types
by jesse＠supremedeveloper.de 20 Jun '11

20 Jun '11

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 <alexander.goransson(a)gmail.com> >> Subject: Re: [HOpenGL] Hello HOpenGL >> To: hopengl(a)haskell.org >> Message-ID: <BANLkTimJtdASk8YgwdAuaSRzhpJVi_dusw(a)mail.gmail.com> >> 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 <alexander.goransson(a)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(a)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 >>>> >>>> >>> >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 17 Jun 2011 00:45:01 +0200 >> From: Alexander G?ransson <alexander.goransson(a)gmail.com> >> Subject: [HOpenGL] Fwd: OpenGL 1 and 2 support (was RE: Hello >> HOpenGL) >> To: hopengl(a)haskell.org >> Message-ID: <BANLkTimD0+R-ehyhV6s6q-b3u6TmOh5V=g(a)mail.gmail.com> >> 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 <alexander.goransson(a)gmail.com> >> Date: 2011/6/16 >> Subject: Re: [HOpenGL] OpenGL 1 and 2 support (was RE: Hello HOpenGL) >> To: Sam Martin <sam.martin(a)geomerics.com> >> >> >> 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 <sam.martin(a)geomerics.com> 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(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/hopengl >>> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> HOpenGL mailing list >> HOpenGL(a)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 <mr.hugo.gomes(a)gmail.com> > Subject: Re: [HOpenGL] Hello HOpenGL > To: jesse(a)supremedeveloper.de > Cc: hopengl(a)haskell.org > Message-ID: <BANLkTin+8tO0Fixbc2hJnQPDB=Virbo=4g(a)mail.gmail.com> > 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 <jesse(a)supremedeveloper.de> > >> 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(a)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(a)haskell.org >> > >> > You can reach the person managing the list at >> > hopengl-owner(a)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 <alexander.goransson(a)gmail.com> >> > Subject: Re: [HOpenGL] Hello HOpenGL >> > To: hopengl(a)haskell.org >> > Message-ID: <BANLkTimJtdASk8YgwdAuaSRzhpJVi_dusw(a)mail.gmail.com> >> > 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 <alexander.goransson(a)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(a)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 >> >>> >> >>> >> >> >> > >> > >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Fri, 17 Jun 2011 00:45:01 +0200 >> > From: Alexander G?ransson <alexander.goransson(a)gmail.com> >> > Subject: [HOpenGL] Fwd: OpenGL 1 and 2 support (was RE: Hello >> > HOpenGL) >> > To: hopengl(a)haskell.org >> > Message-ID: <BANLkTimD0+R-ehyhV6s6q-b3u6TmOh5V=g(a)mail.gmail.com> >> > 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 <alexander.goransson(a)gmail.com> >> > Date: 2011/6/16 >> > Subject: Re: [HOpenGL] OpenGL 1 and 2 support (was RE: Hello HOpenGL) >> > To: Sam Martin <sam.martin(a)geomerics.com> >> > >> > >> > 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 <sam.martin(a)geomerics.com> 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(a)haskell.org >> >> http://www.haskell.org/mailman/listinfo/hopengl >> >> >> > >> > >> > >> > ------------------------------ >> > >> > _______________________________________________ >> > HOpenGL mailing list >> > HOpenGL(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/hopengl >> > >> > >> > End of HOpenGL Digest, Vol 56, Issue 5 >> > ************************************** >> > >> >> >> >> >> >> _______________________________________________ >> HOpenGL mailing list >> HOpenGL(a)haskell.org >> http://www.haskell.org/mailman/listinfo/hopengl >> >

1 0

My thoughts/problem while coding
by L Corbijn 19 Jun '11

19 Jun '11

Hello, In my not so recent coding for the OpenGL library I’ve met a few difficulties and questions. The most important one is that the current implementation for textures is not scalable. It relies on the assumption that there are only certain amount of texture targets for each dimension (only one for 1D and 3D). As OpenGL 3.0 adds a few targets this would introduce some extra targets this would lead to breaking the api. It's probably best to introduce it in the 'summer release', though earlier might also be possible in some opt in way (extra import?). My proposal for the new implementation of texture target is at the bottom of this email, as I wasn't sure whether or not attachments would work with the mailing list. Working with the texture targets I saw the constructor 'TextureRectangle', which to my knowledge is part of an extension. This lead to wonder what should we do with extensions, should their enumeration values and functions be included in the OpenGL package or should the be implemented in another separate package (or where you need them)? The current implementation makes the second possibility nearly impossible, try for example adding an extra InternalFormat (without editing OpenGL). Furthermore, I was asking myself why there isn't any type class GLMarshalable for all those (frustratingly long named) marshal functions, that would lead to some nice utility functions that would make some implantations nicer/easier. If people want to know more about this send an email (it will probably quite a long message). As would I like if there are some negative sides too using typeclasses (less performace/optimization?). Greetings, Lars Corbijn module Graphics.Rendering.OpenGL.GL.Texturing.NewTextureTarget where class TextureTarget t where marshal :: t -> GLenum marshalProxy :: Proxy -> t -> GLenum -- just one example, more for each target data TextureTarget2D = Texture2D | TextureCubeMap CubeMapTarget -- definition is at the end | Texture1Darray -- the new one | TextureRectangle -- As far as I see this is never used in any of the texImage, copy or subData functions. It's part of the TEXTURE_RECTANGLE_ARB deriving ( Eq, Ord, Show ) -- the normal implementation instance TextureTarget TextureTarget2D where marshal = undefined marshalProxy = undefined -- and then what it's all about, for the current function see below texImage2D :: TextureTarget2D -> Proxy -> Level -> PixelInternalFormat -> TextureSize2D -> Border -> PixelData a -> IO () texImage2D tt proxy level int (TextureSize2D w h) border pd = withPixelData pd $ glTexImage2D (marshalProxy proxy tt) level (marshalPixelInternalFormat int) w h border -- one of the reasons for the TextureTarget typeclass, for the current function see below getTexImage :: TextureTarget -> Level -> PixelData a -> IO () getTexImage t level pd = withPixelData pd $ glGetTexImage (marshal t) level -------------------- -- for refference -- -------------------- --The current implementation, it's the worst of the tree (1D, 2D and 3D) texImage2D :: Maybe CubeMapTarget -> Proxy -> Level -> PixelInternalFormat -> TextureSize2D -> Border -> PixelData a -> IO () texImage2D mbCubeMap proxy level int (TextureSize2D w h) border pd = withPixelData pd $ glTexImage2D (maybe (marshalProxyTextureTarget proxy Texture2D) (\c -> if proxy == Proxy then marshalProxyTextureTarget Proxy TextureCubeMap else marshalCubeMapTarget c) mbCubeMap) level (marshalPixelInternalFormat int) w h border -- The current implemtation getTexImage :: Either TextureTarget CubeMapTarget -> Level -> PixelData a -> IO () getTexImage t level pd = withPixelData pd $ glGetTexImage (either marshalTextureTarget marshalCubeMapTarget t) level data CubeMapTarget = TextureCubeMapPositiveX | TextureCubeMapNegativeX | TextureCubeMapPositiveY | TextureCubeMapNegativeY | TextureCubeMapPositiveZ | TextureCubeMapNegativeZ deriving ( Eq, Ord, Show )

2 2

Hello HOpenGL
by jesse＠supremedeveloper.de 17 Jun '11

17 Jun '11

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(a)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(a)haskell.org > > You can reach the person managing the list at > hopengl-owner(a)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 <alexander.goransson(a)gmail.com> > Subject: Re: [HOpenGL] Hello HOpenGL > To: hopengl(a)haskell.org > Message-ID: <BANLkTimJtdASk8YgwdAuaSRzhpJVi_dusw(a)mail.gmail.com> > 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 <alexander.goransson(a)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(a)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 >>> >>> >> > > > > ------------------------------ > > Message: 2 > Date: Fri, 17 Jun 2011 00:45:01 +0200 > From: Alexander G?ransson <alexander.goransson(a)gmail.com> > Subject: [HOpenGL] Fwd: OpenGL 1 and 2 support (was RE: Hello > HOpenGL) > To: hopengl(a)haskell.org > Message-ID: <BANLkTimD0+R-ehyhV6s6q-b3u6TmOh5V=g(a)mail.gmail.com> > 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 <alexander.goransson(a)gmail.com> > Date: 2011/6/16 > Subject: Re: [HOpenGL] OpenGL 1 and 2 support (was RE: Hello HOpenGL) > To: Sam Martin <sam.martin(a)geomerics.com> > > > 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 <sam.martin(a)geomerics.com> 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(a)haskell.org >> http://www.haskell.org/mailman/listinfo/hopengl >> > > > > ------------------------------ > > _______________________________________________ > HOpenGL mailing list > HOpenGL(a)haskell.org > http://www.haskell.org/mailman/listinfo/hopengl > > > End of HOpenGL Digest, Vol 56, Issue 5 > ************************************** >

2 1

Fwd: OpenGL 1 and 2 support (was RE: Hello HOpenGL)
by Alexander Göransson 16 Jun '11

16 Jun '11

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 <alexander.goransson(a)gmail.com> Date: 2011/6/16 Subject: Re: [HOpenGL] OpenGL 1 and 2 support (was RE: Hello HOpenGL) To: Sam Martin <sam.martin(a)geomerics.com> 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 <sam.martin(a)geomerics.com> 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(a)haskell.org > http://www.haskell.org/mailman/listinfo/hopengl >

1 0

Re: [HOpenGL] Hello HOpenGL
by Alexander Göransson 16 Jun '11

16 Jun '11

Apparently sent this to only Balazs yesterday by mistake. Here's my proposal. // A 2011/6/15 Alexander Göransson <alexander.goransson(a)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(a)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 >> >> >

1 0

Hello HOpenGL
by Alexander Göransson 16 Jun '11

16 Jun '11

Hi! I'm the person who will be working on the libraries this summer. I've been very busy with school lately (and still am), but I've written a blog post with some thoughts on the project: http://unsafeperformpastorn.blogspot.com/ I will keep posting stuff there, on a weekly basis, throughout the summer. // Alexander

6 11

Re: [HOpenGL] [Haskell-cafe] Haskell School of Expression (graphics)
by Jason Dagit 01 Jun '11

01 Jun '11

On Mon, May 30, 2011 at 1:19 AM, Jerzy Karczmarczuk <jerzy.karczmarczuk(a)unicaen.fr> wrote: > Henk-Jan van Tuyl commenting Andrew Coppin >> >> ... (about HOpenGL and H.Platform) ... >>> >>> Uh... yes, you might be right about that. However, AFAIK you still need >>> something with which to create a rendering surface in the first place. (Not >>> sure if HP includes GLUT...) >> >> >> As you can see in the HP documentation at >> http://lambda.haskell.org/hp-tmp/docs/2011.2.0.0/index.html >> , both OpenGL and GLUT are present. >> > Or simply download and execute the examples before raising doubts... (the > Haskell translation of the NeHe tutorials, etc.) No need for speculation. > > Now, I have a personal pedagogical comment. Wow, this is great feedback! Thank you. I'm CC'ing the opengl list. > A few months ago I gave to some 30 students an assignment (a family of, with > freely chosen variants). A long one, to complete in 2 months or more, and > the subject was - the implementation, coding and running some nice 3D scenes > with HOpenGL. I teach Haskell for years, usually the projects, which should > be "applied" are devoted to some exercices in AI / games, compilation, text > processing, graph manipulation, lazy numerics, etc., you know the song. This > time I decided to propose something more visual. > > The results? A true DISASTER! > They did "something", all of them, and all their realisations were the nec > plus ultra of mediocrity... Since my students were as clever and laborious > as always, and I didn't drink much vodka during this process, I asked them > what happened? The short "standard" assignments went smoothly as always... > > The answers (concentrated) were as follows: > > The OpenGL bindings in Haskell are hardly "functional". You make us sweat > with generic functional patterns, laziness, exquisite typing, > non-determinism monad, parsing tools, etc., and then you throw us into this > ugly imperativism ! Nobody liked your assignment, it was no pleasure for us, > and our results are the consequence thereof. Where is Haskell?? Of course, > we had to execute the typical syntactic gymnastics, but without > understanding the functioning of all those "variables", and other stuff > relevant to the stateful OpenGL engine. Perhaps, if we had before a semester > of OpenGL, and at least two months of a true course/tutorial (not your > pseudo-tutorial on the Web...) we could be more productive. I think the opengl bindings themselves should be have a level that closely matches the C API so that people can use famous books like the redbook to learn it. I wouldn't really expect us Haskellers to stop there though, as that's the OpenGLRaw library. I think we need something a bit higher level on top that lets you use non-FFI types. That's the OpenGL library. Then we need something that Haskellers *actually* use that provides resource loading, management, type typing etc. I think we need scene graphs and what have you. There is a summer of code student working on the OpenGL library part of it, or HGL as he likes to call it. I know someone else has been working on a scene graph / scene management library. I don't think the opengl creators meant for people to develop at that level. I think they really did mean for people to build "middleware" on top of it and I think that's what we in the Haskell community need to do. By the way, did you show your students gloss? http://hackage.haskell.org/package/gloss Thanks, Jason

1 0

Re: [HOpenGL] Haskell or C First?
by Danny Charbonneau 29 May '11

29 May '11

I want to make a CAD application. On Sun, May 29, 2011 at 12:55 AM, Danny Charbonneau < novo.charbonneau75(a)gmail.com> wrote: > I want to make a CAD application. > > > On Sun, May 29, 2011 at 12:37 AM, Isaac Dupree < > ml(a)isaac.cedarswampstudios.org> wrote: > >> The Haskell OpenGL binding is one of the best OpenGL bindings around... I >> find it slightly nicer to use than the native C bindings, and with no loss >> of power (it's a pretty direct mapping to OpenGL; just a few things like >> glBegin()/glEnd() are made more Haskell-idiomatic IIRC). >> >> What kind of application though? That probably makes more difference in >> this case than the OpenGL. >> >> -Isaac >> >> >> On 05/29/11 00:57, Danny Charbonneau wrote: >> >>> I have an ambition to eventually create a large graphics application >>> dependent on OpenGL I don't have much experience with C or Haskell, >>> though I >>> feel somewhat comfortable around C code. Should I devote some time to >>> learning C and going through the red book or the opengl bible, or is it >>> possible that I could learn Haskell and have no trouble creating and >>> manipulating objects with the bindings offered? >>> >>> >>> >>> >>> _______________________________________________ >>> HOpenGL mailing list >>> HOpenGL(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/hopengl >>> >> >> >> _______________________________________________ >> HOpenGL mailing list >> HOpenGL(a)haskell.org >> http://www.haskell.org/mailman/listinfo/hopengl >> > >

2 1

Haskell or C First?
by Danny Charbonneau 29 May '11

29 May '11

I have an ambition to eventually create a large graphics application dependent on OpenGL I don't have much experience with C or Haskell, though I feel somewhat comfortable around C code. Should I devote some time to learning C and going through the red book or the opengl bible, or is it possible that I could learn Haskell and have no trouble creating and manipulating objects with the bindings offered?

2 1

New programmer => some comments/suggestions
by L Corbijn 07 May '11

07 May '11

Hi everyone, I was wondering if anyone is working on improving the OpenGL package. As the git repository [1] on github looks rather quiet, beside my (Laar, not my real name) casual editing. In that process of adding extra functions to improve the library to some higher version of OpenGL I ran into some structural inconveniences. But as I'm not that experienced with Haskell nor with collaborating in open source projects. The major problem in my opinion is the boat load of deprecated functions and objects that make finding and having an overview of the code rather difficult. This is not helped by the fact that there are a lot of files that could be marked as deprecated. Therefore I think that something more serious should be done than only adding deprecated pragma's as Jason Dagit suggests in [2]. I think it should improve the overview of the code if all deprecated functions/code/etc. are move to a different namespace, say ...OpenGL.GL.Deprecated. This would help a lot as with coding new stuff the files would be quite a bit smaller as you wouldn't see the deprecated stuff. Though this will probably be quite a hard break with older code. Though quite a lot of code to refactor I think it would lead to a better structured project that is easier to maintain. Furthermore in it's current state importing ...OpenGL.GL does import everything, whether it's deprecated, usefull or even only usable for higher versions of OpenGL-contexts than you use. Although the exported functions/Types wouldn't lead to clashes it would be nice to have modules that only export the stuff that is usable for a certain OpenGL-context (e.g. importing ...Core31 or ...Core31Compatibility). This would lead to a compile error when using unsupported functions, which is a lot more pleasant than having to debug why code doesn't work (talking from experience). And if the future brings better auto-complete for Haskell it might lead to better suggestions (all the unused stuff out). Greetings, L Corbijn [1] https://github.com/dagit/OpenGL/network [2] http://www.haskell.org/pipermail/hopengl/2011-April/001002.html

2 3