Re: [HOpenGL] Hello HOpenGL

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

...

(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