[HOpenGL] Haskell Types

[jesse at supremedeveloper.de]

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