[HOpenGL] Hello HOpenGL

[Balazs Komuves]

On Thu, May 19, 2011 at 1:32 PM, Jason Dagit <dagitj at gmail.com> wrote:

>
> On May 19, 2011 5:02 AM, "Balazs Komuves" <bkomuves at gmail.com> wrote:
> >
> >
> > Hi,
> >
> > I see you plan a complete rewrite, and removing the deprecated
> functionality.
> > In this case I suggest to make a new package instead of a new version of
> the old
> > OpenGL package, since it will actually be a very different package,
> 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
> supported indefinitely
> > 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
> 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 <alexander.goransson at gmail.com>
> >>
> >> 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 at haskell.org
> >> http://www.haskell.org/mailman/listinfo/hopengl
> >>
> >
> >
> > _______________________________________________
> > 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/20110519/5682ccad/attachment.htm>