Windows installer 2012.4.0.0 RC1

[Jason Dagit]

On Fri, Oct 26, 2012 at 1:53 PM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> Hi Jason,
>
> On Fri, Oct 26, 2012 at 8:24 PM, Jason Dagit <dagitj at gmail.com> wrote:
> >
> > If you test this, please let me know what you learn.
>
> OK.
>
> > It may be possible to backport this. Unfortunately, it's not as easy as
> it
> > should be. I believe the version of the OpenGL libraries in the platform
> are
> > before the low-level bindings were factored out of the high level
> packages.
> > This means that I don't know if the the release that needs the backport
> is
> > even in the repository history.
>
> Can you point me at the commit you're talking about? Maybe I can
> backport it myself.
>

https://github.com/haskell-opengl/OpenGL/commit/0de14b7378e3c3fde88b472bd21a80d61fd5ef48
But where will the modified source live? Only on hackage?


>
> > From my point of view, it would be ideal if the HP could use the most
> recent
> > versions of the OpenGL packages.
>
> I did not follow that discussion. What are the reasons not to ship the
> most recent versions?
>

One problem is that when the libraries were refactored they were split into
different packages. For example, we have OpenGL and OpenGLRaw now, with
OpenGLRaw containing the lowest level binding to the C api. The *Raw
packages are not yet in the HP. In addition to the *Raw packages, StateVar,
Tensor, and ObjectName were also factored out.

Basically, we would have to add the following packages to the platform if
we want to include the latest OpenGL packages:
  * OpenGLRaw
  * GLURaw
  * StateVar
  * ObjectName
  * Tensor

At least StateVar has been considered controversial in the past as it
introduces Data.StateVar as a module name, and that was seen as a bad
introduction to Haskell for beginners. While Data.StateVar could be moved
under the OpenGL module namespace (Graphics.Rendering.OpenGL.*) this would
do a disservice to all the bindings Sven Panne created (OpenGL, GLUT,
OpenAL, ALUT, to name a few). StateVar is a useful abstraction over
readIORef and writeIORef to work with the opaque handle types that
OpenGL/OpenAL uses. If the platform had some other abstraction for solving
this problem (maybe one of the lenses implementations would work here?),
then I could probably be persuaded to switch to it.

I hope that clarifies,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20121026/a22439f8/attachment.htm>