HOpenGL is in remarkably good shape for being unmaintained for several years. I think the quiet on the HOpenGL mailing list speaks positively to the quality of the library. Perhaps those of us who have an interest in HOpenGL can arrange to work as comaintainers. I think I could be bothered to do weekly builds against GHC to make sure we stay up to date. I'll set that up in the next month or so. Jeff, please point me to your bug. I'd like to take a look. --Lane On Fri, 25 Jul 2008, Jefferson Heard wrote:

I don't know how much I can do to keep them in sync, as I don't know anything about the HLP, however, I'm actively using OpenGL 2.1 in Haskell for research and prototyping and the inclusion of OpenGL in Haskell has been central to my case for using it in my workplace. I don't know what I can do to help, but if anyone will point me in the right direction, I'll try to throw some inertia at it...

-- Jeff

Well, since HOpenGL seems to support practically all of OpenGL 2.1, I don't see that there's much to maintain, except compatibility with upcoming releases of GHC and possibly some optimization. Maybe I'm missing something, though. Is there a list of outstanding bugs somewhere? I personally know of one bug that I found some time ago, which I simply worked around, but a comprehensive list, I'm not aware of. -- Jeff On Fri, Jul 25, 2008 at 1:27 PM, Don Stewart wrote:

claus.reinke:

...

FYI: Haskell's OpenGL binding has just been dropped from GHC's extralibs, which means that it will no longer be kept in sync with GHC development, at least not by GHC HQ.

GHC HQ has its hands full and -generally speaking - extralibs are to be replaced by H(L)P, the Haskell (Library) Platform:

http://haskell.org/haskellwiki/Haskell_Platform

so this part is understandable. But OpenGL has been dropped before H(L)P is ready to take over from extralibs, and at the recent GHC Irc meeting on the topic

http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-2008-07...

the mood seemed to favour not including OpenGL&co in the initial versions of H(L)P. Sven put a lot of good work into these libraries, but he is often not around for a long time, and it would be a shame if these gems were orphaned and went out of sync in the meantime.

While I haven't used OpenGL in a while, I've always hoped to come back to that, not to mention Sven's spatial audio binding additions. And if I'm not mistaken, there are other community members who are using these libs right now for research, possibly even prototyping in connection with a startup?

So, if one of you wanted to step forward and offer to keep these Haskell bindings for OpenGL&co maintained, perhaps steward them into the H(L)P, now would probably be a good time.

Just thought I'd forward this, for those not following cvs-ghc, Claus

Note the OpenGL are still just as maintained as they used to be -- that is, it hasn't had a maintainer for several years.

The only change is that the GHC developers don't put them in a tarball on haskell.org/ghc prior to releasing GHC itself.

-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards

...

So, if one of you wanted to step forward and offer to keep these Haskell bindings for OpenGL&co maintained, perhaps steward them into the H(L)P, now would probably be a good time.

Just thought I'd forward this, for those not following cvs-ghc, Claus

Note the OpenGL are still just as maintained as they used to be -- that is, it hasn't had a maintainer for several years.

Some people post the funniest rumours as if they were facts. $ ghc-pkg field OpenGL maintainer maintainer: sven.panne@aedion.de At the end of this message, I also append the output of darcs changes since OpenGL 2.1 was supported, for those interested in what might be involved in maintainance: Fri Nov 10 10:14:54 GMT Standard Time 2006 sven.panne@aedion.de * Updated Haddock module headers (now OpenGL 2.1 support, API is stable) It just so happens that the library is very stable (unlike other libraries I could think of;-) - Sven's last bug-fix patch was in March 2007, the patches since then have been build system evolution/maintainance. So the problem is not with the library, but with the environment - since its creation, the library has seen FFI tools appear and disappear, FFI spec and library hierarchy take shape, darcs appear and be taken on, Cabal appear and be taken on, packages and tools move on, split up, change their API, etc. - thanks to Sven and others, the binding has weathered all that, without making a lot of noise. And now, there is another enviroment change, with extralibs going and the Haskell Platform aiming to improve the Haskell installation experience. And new quality criteria will be prescribed that this old library will have to meet to be allowed in with the new kids on the block.

The only change is that the GHC developers don't put them in a tarball on haskell.org/ghc prior to releasing GHC itself.

It isn't the tarballing, it is (a) whether the library is run in the HEAD buildbots to flush out breaking changes to the environment early (b) whether enviroment changes are reflected in the library to unbreak its build before user installations are affected (c) whether the library can be relied on as being available on default Haskell installations (this would seem to be less of a problem with Cabal/hackage and user installs, but not all clients have install privileges/tools - OpenGL building uses configure, which in itself might not be installed on Windows; and in some University contexts, installation for public PCs is on a centralised, yearly basis, not per student; etc.; adding the GLUT dll has been a popular request ever since GHC had Windows installers, meaning that every single time someone forgets to put that dll in the installer, someone has reported it as a bug/feature request) I'm not aware of any urgent breakage in the OpenGL binding, nor is the current source going away, and as Duncan says, he expects OpenGL to reappear in the Haskell Platform later on. But neither do I believe the rumour that OpenGL isn't much used, and forwarding the removal notice gives those users the opportunity to speak up now if they prefer no gaps in OpenGL presence, or forever to hold their peace, as they say. Unless Sven wants to do the job himself, a maintainer would mainly have to adapt the library to the Haskell Platform criteria, keep up with the forever changing build environments, and counter rumours about the OpenGL binding being unmaintained or unused. Claus $ darcs changes --from-patch=stable Thu Jun 19 13:43:50 GMT Daylight Time 2008 Ian Lynagh <igloo> tagged GHC 6.8.3 release Fri Jun 6 00:56:57 GMT Daylight Time 2008 Ian Lynagh <igloo> tagged 2008-06-06 Sat Nov 10 01:11:04 GMT Standard Time 2007 Ian Lynagh <igloo> tagged GHC 6.8.1 release Sat Nov 10 01:09:54 GMT Standard Time 2007 Ian Lynagh <igloo> tagged 2.2.1.1 release Sat Oct 27 13:48:05 GMT Daylight Time 2007 Ian Lynagh <igloo> * Bump version number Thu Oct 18 18:31:37 GMT Daylight Time 2007 Duncan Coutts <duncan> * Specify build-type: Configure Mon Jun 4 12:59:36 GMT Daylight Time 2007 Ross Paterson <ross> * --configure-option and --ghc-option are now provided by Cabal Thu May 24 15:56:14 GMT Daylight Time 2007 Ian Lynagh <igloo> * Remove Makefile and package.conf.in (used in the old GHC build system) Thu May 17 10:49:12 GMT Daylight Time 2007 Simon Marlow <simonmar> * add includes: field Mon Apr 30 12:17:32 GMT Daylight Time 2007 Ian Lynagh <igloo> * Make configure fail if the package cannot be built Sat Apr 28 20:58:51 GMT Daylight Time 2007 Ian Lynagh <igloo> tagged GHC 6.6.1 release Sat Apr 28 20:56:55 GMT Daylight Time 2007 Ian Lynagh <igloo> tagged 2.2.1 release Tue Apr 24 12:39:29 GMT Daylight Time 2007 Ian Lynagh <igloo> tagged GHC 6.6.1 release Tue Apr 24 12:38:31 GMT Daylight Time 2007 Ian Lynagh <igloo> tagged Version 2.2.1 Sun Apr 22 20:50:57 GMT Daylight Time 2007 Ian Lynagh <igloo> * Bump version to 2.2.1 Wed Apr 18 13:13:30 GMT Daylight Time 2007 Ian Lynagh <igloo> * Follow Cabal changes in Setup.*hs Wed Apr 11 02:22:21 GMT Daylight Time 2007 Ian Lynagh <igloo> * Fix -Wall warnings Sat Apr 7 18:41:16 GMT Daylight Time 2007 Ian Lynagh <igloo> * Make Setup.hs suitable for building in a GHC tree Tue Mar 13 17:46:09 GMT Standard Time 2007 sven.panne> * README about building from darcs Mon Jan 1 12:50:21 GMT Standard Time 2007 sven.panne>

Don Stewart wrote:

claus.reinke:

...

But neither do I believe the rumour that OpenGL isn't much used, and forwarding the removal notice gives those users the opportunity to speak up now if they prefer no gaps in OpenGL presence, or forever to hold their peace, as they say.

I for one have noticed this library *is* actively used. Many of the fun new games that have appeared are using it, in particular.

Such as:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/frag http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Monadius http://hackage.haskell.org/cgi-bin/hackage-scripts/package/roguestar-gl http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rsagl http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shu-thing http://hackage.haskell.org/cgi-bin/hackage-scripts/package/topkata

The tutorial was also translated to the wiki last week,

http://haskell.org/haskellwiki/Opengl

It's a good, reliable package, in active use, widely ported.

I'd just like to say that HOpenGL is essential for me. It is one of the reasons why I finally decided to use Haskell for all my work... Alberto

There is a section "Projects using the OpenGL bindings" (http://www.haskell.org/haskellwiki/OpenGL) on the wiki that is pretty bare. A quick search of HCAR lists five projects using OpenGL. --L On Sat, 26 Jul 2008, Jefferson Heard wrote:

It would be nice to know, though, how many people are using it and what they're using it for. I'm using it for information visualization, and slowly evolving/cribbing together something like the Processing (http://www.processing.org) framework for Haskell as I do more things.

scodil wrote:

I'll chime in with a "me too". I use Haskell and OpenGL for prototyping scientific visualization software, 3D models and such. Not that I think it couldn't be used for production software, its just that I just don't produce much :)

The library really is fantastic. I don't think it gets enough fanfare. The only other GL API that rivals it is the C API itself. Most other languages provide a shoddy & incomplete interface to that, instead of an idiomatic interpretation of the OpenGL spec. I can't think of a single language, not even python, whose OpenGL bindings come close.

I get the impression (from a inadequate sample of irc logs and list chatter) that many Haskellers see HOpenGL as 'just an OpenGL binding', like it was readline or curses or something. It just plugs a hole in the Haskell/OS interface, and its worth is merely a function of the size and importance of that hole. Instead I advocate, as Claus and others have done, that it's a shining example of how to write a Haskell interface to a well known API.

If you never used C OpenGL and learned GL using Haskell, you might not notice anything special about it. But that's kind of my point, its just so damn good it blends into the background. The only people who notice this, I think, are experienced C OpenGL programmers, and the overlap between them and the Haskell community in general is small I bet. Their voice in that community smaller still.

This probably has little bearing on the issue of whether to keep or drop HOpenGL in the near future, but I think that if 'the community' (or whoever has a say in these things) like the style of HOpenGL, and want to encourage bindings to be written in that style, they should place the library prominently in the pantheon of Haskell libs. Demoting it has the opposite effect.

Anyway, I just wanted to take advantage of a rare opportunity to sing its praise.

I have nothing to add except... what a great post. Thanks for being both enlightening and eloquent. Simon

Scott, I couldn't have said it better. My impression has always been that HOpenGL looks like OpenGL would have looked like if they'd had a flexible language to work with when they desgned it. My only quibble would be with the documentation. Is there any way out there for haddock to produce a linked and indexed PDF, so that I can better guess where one function will be relative to another that feels like it ought to be related?

It is probably a bit obscured in the alphabetically sorted Haddock main contents listing, but if you look at something like http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Render... http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT.... you'll find that the layout closely follows the relevant specs (at least, it used to). So you can use the PDF files for the official specs to find what you need, and then those doc layout pages to translate to HOpenGL. Just as the examples follow the red book, to make translation easy. Do I need to mention that I agree with Scott?-) Claus

On Mon, Jul 28, 2008 at 11:42 PM, scodil wrote:

...

I'll chime in with a "me too". I use Haskell and OpenGL for prototyping scientific visualization software, 3D models and such. Not that I think it couldn't be used for production software, its just that I just don't produce much :)

The library really is fantastic. I don't think it gets enough fanfare. The only other GL API that rivals it is the C API itself. Most other languages provide a shoddy & incomplete interface to that, instead of an idiomatic interpretation of the OpenGL spec. I can't think of a single language, not even python, whose OpenGL bindings come close.

I get the impression (from a inadequate sample of irc logs and list chatter) that many Haskellers see HOpenGL as 'just an OpenGL binding', like it was readline or curses or something. It just plugs a hole in the Haskell/OS interface, and its worth is merely a function of the size and importance of that hole. Instead I advocate, as Claus and others have done, that it's a shining example of how to write a Haskell interface to a well known API.

If you never used C OpenGL and learned GL using Haskell, you might not notice anything special about it. But that's kind of my point, its just so damn good it blends into the background. The only people who notice this, I think, are experienced C OpenGL programmers, and the overlap between them and the Haskell community in general is small I bet. Their voice in that community smaller still.

This probably has little bearing on the issue of whether to keep or drop HOpenGL in the near future, but I think that if 'the community' (or whoever has a say in these things) like the style of HOpenGL, and want to encourage bindings to be written in that style, they should place the library prominently in the pantheon of Haskell libs. Demoting it has the opposite effect.

Anyway, I just wanted to take advantage of a rare opportunity to sing its praise.

Scott

...

Yes, same here; don't worry, it's not going away. It would be nice to know, though, how many people are using it and what they're using it for. I'm using it for information visualization, and slowly evolving/cribbing together something like the Processing (http://www.processing.org) framework for Haskell as I do more things.

On Sat, Jul 26, 2008 at 5:46 AM, Alberto Ruiz wrote:

...

Don Stewart wrote:

...

claus.reinke:

...

But neither do I believe the rumour that OpenGL isn't much used, and forwarding the removal notice gives those users the opportunity to speak up now if they prefer no gaps in OpenGL presence, or forever to hold their peace, as they say.

I for one have noticed this library *is* actively used. Many of the fun new games that have appeared are using it, in particular.

Such as:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/frag http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Monadius

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/roguestar-gl http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rsagl http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shu-thing http://hackage.haskell.org/cgi-bin/hackage-scripts/package/topkata

The tutorial was also translated to the wiki last week,

http://haskell.org/haskellwiki/Opengl

It's a good, reliable package, in active use, widely ported.

I'd just like to say that HOpenGL is essential for me. It is one of the reasons why I finally decided to use Haskell for all my work...

Alberto _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Fw%3A-patch-applied-%28ghc%29%3A-Remove-the-OpenGL-fam... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, 2008-07-28 at 11:11 +0100, Malcolm Wallace wrote:

...

FYI: Haskell's OpenGL binding has just been dropped from GHC's extralibs, which means that it will no longer be kept in sync with GHC development, at least not by GHC HQ.

GHC HQ has its hands full and -generally speaking - extralibs are to be replaced by H(L)P, the Haskell (Library) Platform:

As someone who uses HOpenGL as a component for my own research, I must say that I don't entirely follow the logic of dropping it from extralibs.

I mean, I fully appreciate that ghc-HQ wants to remove extralibs from its sphere of responsibility. And I also very much support the new Haskell Platform idea.

But I did also get the impression that the HP was going to start from extralibs and build outwards. I can't see how dropping existing working and tested libraries from a mini-platform, is any help at all to the new maintainers of HP.

I think there's been a bit too much ho ha over this. For one thing it was only a suggestion to reduce work and for another we've not even got the infrastructure set up so we don't know how much work it's going to be. If someone wants to do the work (of the maintainer) then I'm sure it'll happen, and judging by the number of responses that would seem likely.

It is only likely to give grief to users who expect HOpenGL to be part of HP, and then later more grief to the HP maintainers when they try to re-integrate it, after allowing it to suffer a period of bit-rot.

I don't think that's right. The HP maintainers are not (and cannot be) the maintainers of each individual package. That just does not scale. If a package is suffering bit rot then it's the responsibility of the package maintainer(s) to sort out. Also, something not being in the platform does not at all imply bit rot. Lack of a maintainer tends to imply bit rot. It's still on hackage and has its existing users who would hopefully contribute fixes if the maintainer was not to be found. Duncan

Malcolm Wallace wrote:

As a package author (rather than a user), I would see this as a primary benefit of having my packages added to the Platform. And as a package user (rather than author), there is the corresponding antibenefit of removing a package like HOpenGL from the Platform: a diminished likelihood of the maintainer being already aware of packaging flaws.

perhaps we can work on getting set up automatic testing etc. with a relatively basic Haskell Platform. If that turns out to be easily done, we can look at making a facility for all package authors (at least, ones on Hackage) to volunteer to have their packages automatically checked for such breakages. Sure, it could still help a little to be part of an official Haskell Platform, but there are reasons we're trying to designate a Haskell Platform smaller than Hackage. -Isaac