Re: Hello HOpenGL

Hi Jesse,

would you be interested in uploading your stuff to hackage ?

Thanks and keep up the good work :)



2011/6/17 <[email protected]>

> 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
> >       [email protected]
> >
> > 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
> >       [email protected]
> >
> > You can reach the person managing the list at
> >       [email protected]
> >
> > 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 <[email protected]>
> > Subject: Re: [HOpenGL] Hello HOpenGL
> > To: [email protected]
> > Message-ID: <[email protected]>
> > 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 <[email protected]>:
> >> 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 <[email protected]> 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 <[email protected]>
> > Subject: [HOpenGL] Fwd:  OpenGL 1 and 2 support (was RE: Hello
> >       HOpenGL)
> > To: [email protected]
> > Message-ID: <[email protected]>
> > 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 <[email protected]>
> > Date: 2011/6/16
> > Subject: Re: [HOpenGL] OpenGL 1 and 2 support (was RE: Hello HOpenGL)
> > To: Sam Martin <[email protected]>
> >
> >
> > 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 <[email protected]> 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
> >> [email protected]
> >> http://www.haskell.org/mailman/listinfo/hopengl
> >>
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > HOpenGL mailing list
> > [email protected]
> > http://www.haskell.org/mailman/listinfo/hopengl
> >
> >
> > End of HOpenGL Digest, Vol 56, Issue 5
> > **************************************
> >
>
>
>
>
>
> _______________________________________________
> HOpenGL mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/hopengl
>

_______________________________________________
HOpenGL mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/hopengl