Note, there are some issues, as this is a package in the Haskell Platform, to do with upgrading and dependent packages. We should talk first about issues there. On Wed, Apr 6, 2011 at 2:32 PM, Jason Dagit wrote:

No response yet from Sven after about a month and no one seems to have heard from him in over a year.

I'm going to take over for now under the assumption that Sven is missing. == My plans for moving forward ==   * Assemble an opengl taskforce, a few people have already mentioned an interest in being on the team   * clean up the current cabal files (I already wrote patches for that)   * put the repos on github to make team collaboration easier   * add the RULES that Andy Gill suggested for realToFrac   * look at adding instances for MArray so that GLfloat et al can be stored in IOUArrays   * add support for opengl 4.x   * look at adding deprecation pragmas for deprecated opengl calls   * new hackage releases   * anything else that comes up Thanks, Jason

On Sun, Mar 27, 2011 at 2:11 PM, Jason Dagit wrote:

...

I sent the message below to Haskell-Cafe about a week ago. I got one response saying that Sven has disappeared in the past but reappeared when updates were necessary.  I still haven't heard from Sven.  Now I'm widening my search.  My original email to Sven was on March 11th. It looks like the OpenGL packages on hackage[1,2,3,4] have not been updated in some time.  No updates later than Oct 2009.  I tried to email Sven directly using the email address listed on hackage but after over two weeks I still haven't heard from him.  I sent some patches to the opengl list about a week ago but I noticed that Sven hasn't posted on that list since Oct 2009 when he released the current version of OpenGLRaw.  None of the public darcs repos have patches newer than Oct 2009.  Also, the homepage url listed in the packages is a 404: http://www.haskell.org/HOpenGL/ My concern is that Sven has disappeared for some reason.  I hope he's well.  He has always done top notch work in the past maintaining these libraries.  Perhaps he's simply busy or lost interest? Does anyone know if he was looking for a new maintainer?  Perhaps you've heard from him more recently than Oct 2009? If a new maintainer is needed, I would consider nominating myself :) Thanks, Jason [1] http://hackage.haskell.org/package/OpenGLRaw [2] http://hackage.haskell.org/package/OpenGL [3] http://hackage.haskell.org/package/GLURaw [4] http://hackage.haskell.org/package/GLUT

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Taking the discussion back to the libraries@ list. The OpenGL packages weren't updated, as they added new dependent packages using funny parts of the top level namespace. In particular, StateVar took "Data.StateVar" -- which isn't necessarily something the HP wants to push on beginner Haskellers. Moving those modules under OpenGL.*.*.StateVar etc would remove the problems with upgrading to the HP. -- Don On Wed, Apr 6, 2011 at 2:45 PM, Jason Dagit wrote:

On Wed, Apr 6, 2011 at 2:35 PM, Don Stewart wrote:

...

Note, there are some issues, as this is a package in the Haskell Platform, to do with upgrading and dependent packages. We should talk first about issues there.

An older version is in the HP, but Johan pointed out to me in a private email that the latest version is not in the HP.  Here are the results of my research into that:

I'm not finding much in the way of reasons why the *Raw packages were not added or why OpenGL/GLUT were not updated. There are these: http://trac.haskell.org/haskell-platform/ticket/157 http://trac.haskell.org/haskell-platform/ticket/158 That's a request for the latest version of GLUT and OpenGL.  I found those via the archives but the threads are empty and no comments on the tickets. Magnus created those tickets as a result of this thread, I believe: http://projects.haskell.org/pipermail/haskell-platform/2011-February/001401.... Is that the thread in your memory?  Perhaps it was this one? http://www.haskell.org/pipermail/libraries/2009-June/011920.html That one turned into a discussion of the module system. I added a proposal to add OpenGLRaw, but no one commented on it: http://projects.haskell.org/pipermail/haskell-platform/2011-March/001506.htm... Based on that, it seems that Magnus wants the packages updated, and I'd like to see the *Raw packages added to the platform.  I don't see any dissenting public opinions on the libraries list or on the trac, other than tickets #57 and #58 that make a case for removing OpenGL and GLUT entirely from the platform.  Tickets #57 and #58 seem to be old though.

If you have more information or I overlooked something, please let me know :) Thanks, Jason

...

On Wed, Apr 6, 2011 at 2:32 PM, Jason Dagit wrote:

...

No response yet from Sven after about a month and no one seems to have heard from him in over a year.

I'm going to take over for now under the assumption that Sven is missing. == My plans for moving forward ==   * Assemble an opengl taskforce, a few people have already mentioned an interest in being on the team   * clean up the current cabal files (I already wrote patches for that)   * put the repos on github to make team collaboration easier   * add the RULES that Andy Gill suggested for realToFrac   * look at adding instances for MArray so that GLfloat et al can be stored in IOUArrays   * add support for opengl 4.x   * look at adding deprecation pragmas for deprecated opengl calls   * new hackage releases   * anything else that comes up Thanks, Jason

On Sun, Mar 27, 2011 at 2:11 PM, Jason Dagit wrote:

...

I sent the message below to Haskell-Cafe about a week ago. I got one response saying that Sven has disappeared in the past but reappeared when updates were necessary.  I still haven't heard from Sven.  Now I'm widening my search.  My original email to Sven was on March 11th. It looks like the OpenGL packages on hackage[1,2,3,4] have not been updated in some time.  No updates later than Oct 2009.  I tried to email Sven directly using the email address listed on hackage but after over two weeks I still haven't heard from him.  I sent some patches to the opengl list about a week ago but I noticed that Sven hasn't posted on that list since Oct 2009 when he released the current version of OpenGLRaw.  None of the public darcs repos have patches newer than Oct 2009.  Also, the homepage url listed in the packages is a 404: http://www.haskell.org/HOpenGL/ My concern is that Sven has disappeared for some reason.  I hope he's well.  He has always done top notch work in the past maintaining these libraries.  Perhaps he's simply busy or lost interest? Does anyone know if he was looking for a new maintainer?  Perhaps you've heard from him more recently than Oct 2009? If a new maintainer is needed, I would consider nominating myself :) Thanks, Jason [1] http://hackage.haskell.org/package/OpenGLRaw [2] http://hackage.haskell.org/package/OpenGL [3] http://hackage.haskell.org/package/GLURaw [4] http://hackage.haskell.org/package/GLUT

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hi, Am Mittwoch, den 06.04.2011, 14:32 -0700 schrieb Jason Dagit:

I'm going to take over for now under the assumption that Sven is missing.

== My plans for moving forward == * Assemble an opengl taskforce, a few people have already mentioned an interest in being on the team * clean up the current cabal files (I already wrote patches for that) * put the repos on github to make team collaboration easier * add the RULES that Andy Gill suggested for realToFrac * look at adding instances for MArray so that GLfloat et al can be stored in IOUArrays * add support for opengl 4.x * look at adding deprecation pragmas for deprecated opengl calls * new hackage releases * anything else that comes up

from the distributors site one comment: We have a rather large per-package overhead. So 10 modules in one package is roughly 10% of the work of 1 module in 10 packages. The new OpenGL packages have split out lots of small packages (OpenGLRaw, StateVar, Tensor, ObjectName). Please review this and see if you can somehow lessen the package number inflation before your version enters the platform. Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de

It would need to be proposed to join the HP standard library set -- at the moment, it has no other users, and a surprising top level name. My proposal would be to move those packages under the Graphics.* namespace, and, optionally, merge (some) of them back into OpenGL, to reduce maintainance burden. I don't buy the argument that the StateVar interface should be widely exposed and encouraged. Jason is the maintainer though. On Sun, Apr 17, 2011 at 10:37 AM, Felipe Almeida Lessa wrote:

On Sun, Apr 17, 2011 at 12:53 PM, Joachim Breitner wrote:

...

work of 1 module in 10 packages. The new OpenGL packages have split out lots of small packages (OpenGLRaw, StateVar, Tensor, ObjectName). Please review this and see if you can somehow lessen the package number inflation before your version enters the platform.

At least StateVar is very useful outside OpenGL.

Thanks,

-- Felipe.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Something under Foreign, then, if it is an abstraction for pointers. Take a proposal to the libraries@ list. -- Don On Sun, Apr 17, 2011 at 12:32 PM, Jason Dagit wrote:

On Sun, Apr 17, 2011 at 10:43 AM, Don Stewart wrote:

...

It would need to be proposed to join the HP standard library set -- at the moment, it has no other users, and a surprising top level name.

The top level name for StateVar is Data.StateVar.  It is a pretty general api that has some handy uses.  The best parts being, turning Ptrs into something that behaves like an IORef and splitting read and write capabilities.

...

My proposal would be to move those packages under the Graphics.* namespace, and, optionally, merge (some) of them back into OpenGL, to reduce maintainance burden. I don't buy the argument that the StateVar interface should be widely exposed and encouraged.

Where it's useful is that it provides an api that unifies access to IORefs and Ptrs and it separates read/write capabilities.  For something like the opengl package that exposes the OpenGL state machine via Ptrs and higher level state via IORefs this makes some sense as a way to hide implementation details and provide a more haskell-friendly api.  Outside of Haskell bindings for stateful C apis, it's probably not that useful. Due to how it's implemented (IORefs, Ptr and Storable), I think this is something that should possibly be in an FFI related module, if it were to live separate from the opengl package.  It does get used for opengl, openal, himpunk and a few other things so I can see why Sven separated it from OpenGL: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/StateVa... My main goal though is to balance the concerns people have so that we can move forward using it and bundling it with the HP.  If being a top level name (Data.StateVar) means people don't want it in the platform then I'm happy to compromise on that. Graphics.StateVar is fine with me in that sense of compromise for opengl, but then it will look kind of funny when OpenAL imports something from the graphics hierarchy just to get access to its state variables.  So for that reason, I would prefer a name like, Foreign.State or Foreign.StateVar.  Would that be acceptable?  Which parts of the module name space can I use for something like this?  Suggestions? Jason

There is a good social reason not to add it to Base - Base is already a significant maintenance effort for the people who actually work on it (notably Ian Lynagh and Ross Paterson). Maybe there is a case for a "Bigger Base" as part of the Platform instead?

Hi, Am Sonntag, den 17.04.2011, 14:37 -0300 schrieb Felipe Almeida Lessa:

On Sun, Apr 17, 2011 at 12:53 PM, Joachim Breitner wrote:

...

work of 1 module in 10 packages. The new OpenGL packages have split out lots of small packages (OpenGLRaw, StateVar, Tensor, ObjectName). Please review this and see if you can somehow lessen the package number inflation before your version enters the platform.

At least StateVar is very useful outside OpenGL.

I’m not saying it is not useful. But there is very little code and most of it is rather, well, trivial. So if you need the functionality in one of your packages only, then you can put it there. If you need it in on collection of multiple packages with one package dominating the dependency tree, then put it there. A package of its own for these few lines is only required if * Package A and package B provide an _interface_ in terms of StateVar * Neither A depends on B nor B depends on A * There will be a package C that not only uses the interface of both A and B but also combines them, e.g. really requires that the same type is used in both the interfaces. Also, small packages without external dependencies can be combined in one package without much loss. E.g. a package opengl-utils (or some better name) that provides all of StateVar, Tensor, ObjectName would do the job equally well. I know that its tempting to have very fine-grained Cabal packages, because its so cheap to put them on Hackage and leave it to cabal-install to install take care of them. Unfortunately, it doesn’t scale on the Distribution side very well – and we are already trying hard to keep the per-package maintenance cost down. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de