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