On May 19, 2011 5:02 AM, "Balazs Komuves" wrote:

Hi,

I see you plan a complete rewrite, and removing the deprecated

In this case I suggest to make a new package instead of a new version of

OpenGL package, since it will actually be a very different package,

functionality. the old presumably

with different APIs, etc (and I don't think Sven actually agreed to replace it, since we cannot seem to reach him).

I have to keep my reply short because I'm traveling, but two comments. 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. By following the hackage package version policy, we should be free to make major modifications to the existing API. If the gsoc work becomes the new version the opengl library, then it will be version 3.x or later. You should be able to author your package dependencies accordingly. We should be sure to release any bug fixes that we can for the current version as we find them. Basically, lets free ourselves to make changes, and them figure out how to do so in a polite way. That is my opinion anyway :) Your feedback is welcome of course.

Furthermore, "deprecated" (2.0) functionality will be most probably

in the future. At least NVidia (~half of the market) stated that they will fully support it; and there is a HUGE amount of existing software out there depending on the deprecated OpenGL functionality, which makes it economically irrational not to support it.

Another reason is that only new hardware supports OpenGL 3.0. For example I own two computers, a laptop and a desktop, and neither hardware support OpenGL 3.0 (it is actually not possible to buy a video card compatible with my motherboard which supports 3.0...)

Lastly, for a new user and also for quick hacks, the glBegin/glEnd route is much easier.

Apart from this, since I care a lot about Haskell OpenGL support, I volunteer to review your work (read: give you my subjective but detailed opinion and suggestions). You can reach me at this email address if you are interested in discussing stuff.

Balazs

ps. I have a low dimensional linear algebra library which should have all

(and some more) needed to do graphics with OpenGL even in the

supported indefinitely the functionality post-3.0-era:

http://hackage.haskell.org/package/vect http://hackage.haskell.org/package/vect-opengl http://code.haskell.org/~bkomuves/projects/vect/ (the development branch has some quaternions, too)

I'm open to suggestions regarding the organization and API of this

library.

2011/5/19 Alexander Göransson

...

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

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

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

Hi, Nice to hear that there is to be some 'native' support for matrices and that the documentation is updated. Though I've some comments too. Firstly, I would prefer the move to another namespace for the deprecated functionality, not only because it will be supported/used for quite some time. It is also useful to be able to make a gentle transistion to 'non deprecated code'. I think the amount of work is quite doable as quite a few of the modules are in essence deprecated in total, the opengl specs 3.1 and after would make this work quite a bit easier as they exclude the deprecated functions. I think there is also a version of the spec where the deprecated functions are marked in the sideline. Secondly, the way you're depicting the OpenGL-raw library seems to be as a library to make the opengl functions easier to use. Though this seems to me as what the current OpenGL library is doing, wrapping all the objects in nice new/data types and changing the functions in order to make them more usable. So what is in your proposal to be difference between the proposed OpenGL-Raw-Nice and the current OpenGL. Because if it were minimal it would be quite a reason to add a 'layer' around what is currently OpenGL. For the dependency on OpenGL itself, might it be an idea that as in the current package everything is exported and you can only use the functions available on your machine? I don't know much about OpenGL extensions but might there not be a way to specify that there are two 'equivalent' functions, one in the higher OpenGL version and one in a extension. On invoking trying to invoke such function it would pick the appropriate option, and thus it would prevent making a hard deprecation on a specific version of OpenGL. Furthermore It might be an idea to make part of the OpenGL library 'generatable', that is that the source code is generated from some sort of specification file. That would for example make creating those functions for getting limits (e.g. max texture units) quite a bit easier. There is quite somethings more I would like to change in the library to make it nicer (at least in my opinion), but that would make this email too long, and you've probably also quite a lot of ideas your self. I'm currently busy with implementing some OpenGL 3.0 functionalities, some are already done. But work i progressing slowly as I'm using quite some time for school and other activities. Lars P.S. I think the framebuffer ticket (#7, https://github.com/haskell-opengl/OpenGL/issues/7) on github should be reopened as I can't find them in the source code. On Thu, May 19, 2011 at 2:02 PM, Balazs Komuves wrote:

On Thu, May 19, 2011 at 1:32 PM, Jason Dagit wrote:

...

On May 19, 2011 5:02 AM, "Balazs Komuves" wrote:

...

Hi,

I see you plan a complete rewrite, and removing the deprecated

...

In this case I suggest to make a new package instead of a new version of

...

OpenGL package, since it will actually be a very different package,

functionality. the old presumably

...

with different APIs, etc (and I don't think Sven actually agreed to replace it, since we cannot seem to reach him).

I have to keep my reply short because I'm traveling, but two comments.

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...

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.

I believe each of these reasons is enough *in alone* to motivate a separate package, and together they form a very strong argument; and I hope you take this into account in a rational manner, notwithstanding what PVP allows or not. Face it, you plan to make a completely new package. It doesn't make sense to sell it as a new version of a different package.

Whether we should rename it later to "OpenGL" and rename the old one to "OpenGL-old" or something like that is a separate question which can be dealt with when it becomes a problem.

Balazs

...

By following the hackage package version policy, we should be free to make major modifications to the existing API. If the gsoc work becomes the new version the opengl library, then it will be version 3.x or later. You should be able to author your package dependencies accordingly. We should be sure to release any bug fixes that we can for the current version as we find them.

Basically, lets free ourselves to make changes, and them figure out how to do so in a polite way.

That is my opinion anyway :)

Your feedback is welcome of course.

...

Furthermore, "deprecated" (2.0) functionality will be most probably

...

in the future. At least NVidia (~half of the market) stated that they will fully support it; and there is a HUGE amount of existing software out there depending on the deprecated OpenGL functionality, which makes it economically irrational not to support it.

Another reason is that only new hardware supports OpenGL 3.0. For example I own two computers, a laptop and a desktop, and neither hardware support OpenGL 3.0 (it is actually not possible to buy a video card compatible with my motherboard which supports 3.0...)

Lastly, for a new user and also for quick hacks, the glBegin/glEnd route is much easier.

Apart from this, since I care a lot about Haskell OpenGL support, I volunteer to review your work (read: give you my subjective but detailed opinion and suggestions). You can reach me at this email address if you are interested in discussing stuff.

Balazs

ps. I have a low dimensional linear algebra library which should have all the functionality (and some more) needed to do graphics with OpenGL even in the

supported indefinitely post-3.0-era:

...

http://hackage.haskell.org/package/vect http://hackage.haskell.org/package/vect-opengl http://code.haskell.org/~bkomuves/projects/vect/ (the development branch has some quaternions, too)

I'm open to suggestions regarding the organization and API of this

library.

...

2011/5/19 Alexander Göransson

...

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

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

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

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

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

...

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

...

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

from parsec3 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

On Wed, Jun 15, 2011 at 1:18 PM, Balazs Komuves wrote:

Hi,

First of all, let me be clear in that I don't think the maintenance politics is the most important thing here; however I'm all for more transparency, and more public feedback before sudden ad-hoc changes (especially when they go against my subjective tastes).

We can talk about those issues separately then.

I think the not very transparent part was declaring yourself the maintainer without having any public feedback.

Someone needs to be the active maintainer. I asked advice from a few people in the open source community and their advice was to just take over. I'm sorry that part was not more democratic. Would you like to be the maintainer? I mean that sincerely. I don't need to be the maintainer, but I do want to see the library continue and improve. I plan to hand the reigns over in the future and I believe you know opengl and the haskell opengl well enough to fill that role.

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.

I've asked Alexander to share his proposal many times. I'm not sure why that hasn't happened yet. For what it's worth, the proposal was reviewed by the Haskell.org GSoC mentors. Conal Elliot helped Alexander put it together. I agree that's is not fair that you haven't seen it. Let's work on fixing that. Alexander, could you please post your proposal (minus the timeline) on this list?

Anyway, we should probably focus our energies on more meaningful stuff.

Agreed, although I would like to right the wrongs which can still be righted. I know you've published quite a few useful libraries on Hackage for opengl related work and I want/need your support. We might disagree about some details but I am trying to listen with an open mind :)

...

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.

I helped out with darcs development for a few years, so I know it well and I know the Haskell community historically supported it. I also know that this summer it will be gaining a darcs to git bridge, making it easier to be a darcs user while interacting with a git world. My decision to go with git here is more social than technical.

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).

I don't think haskell.org has a good track record for running project hosting, and I even think h.o should get out of the project hosting business. Git has a terrible ui, but github makes up for it in providing solid hosting and by enhancing collaboration (code review is easy, visibility into what people are doing is easy, forking and playing around is easy, viewing diffs is easy, convenient dashboard view, etc). As a long time darcs user, the switch to github has not been easy for me but it has been worth it. I wanted darcs to succeed for a long time, but these days I see instead the value provided by the high quality hosting github provides and especially the collaboration features they provide. Thanks, Jason

On Wed, Jun 15, 2011 at 2:13 PM, Balazs Komuves wrote:

...

Someone needs to be the active maintainer.  I asked advice from a few people in the open source community and their advice was to just take over.  I'm sorry that part was not more democratic.  Would you like to be the maintainer?  I mean that sincerely.  I don't need to be the maintainer, but I do want to see the library continue and improve.  I plan to hand the reigns over in the future and I believe you know opengl and the haskell opengl well enough to fill that role.

I'm not against you being the maintainer, and I think I already stated in a private mail that I do not wish to be the maintainer (maybe I would volunteer to be a co-maintainer, but I don't have time to do even that at the moment). However, I'm involved with Haskell and OpenGL deeply enough that I care a lot about what happens, and I want to ensure that there is at minimum a public discussion about issues on which I disagree with the maintainer.

But seriously, we should just focus on the actual issues instead of politics.

For example I think I listed more than 5 independent reasons for having a different package (instead of just a new version) in case of large/incompatible changes. 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.

My plan was to reply to those issues in a later email. I should have said so but I forgot to mention it in my email. Sorry! I am thinking about those things and I was even discussing some of the options over lunch today with one of my co-workers. It's possibly something worth asking for advice about on Haskell-Cafe where there is a wider audience. So, in other words, I heard you and I'm not sure yet what I want to say. To me the more urgent issue is the improvement work and the consensus for that. How we package it can be deferred, at least at the time being. I promise to bring it up again and try for consensus before posting new releases to hackage that are more than simply bug fixes. Jason