FYI: Haskell Platform release candidates
Having stumbled over recent activities on the long-silent Haskell Platform mailing list, I have noticed few OpenGL voices. So, for those here who haven't yet seen the Haskell Platform (HP) discussions: - now is the time to make sure that using OpenGL with Haskell will once again be as easy on all platforms as it used to be before GHC dropped the ball. This is what your clients will use to run your code (at least those clients who don't install OpenGL/GLUT themselves just to try out your code), so it might be a good idea to check that it works on your platforms. - initial release appears imminent, so it is too late to get bug fixes in now, but you could test the installer release candidates. - a bug fix release of the HP seems planned within a few weeks, and Sven is obviously working through old emails/bug reports, prompted by the surprising change in gear for the HP, so this would be a good time to bring out any hidden bug reports, or OpenGL issues with the HP (I understand that Sven's recent patches will be in the first bug fix release of the HP, not in the initial release - HP policy arguments). - I'm not sure whether the HP policy arguments would affect Sven's recent feature additions - they won't be in the initial HP release, but the question is whether they'll be in the planned bug-fix release, soon, or in the next major HP release, which is nowhere near. OpenAL/ALUT seem to be in the latter category, if at all: http://projects.haskell.org/pipermail/haskell-platform/2009-April/000120.htm... http://projects.haskell.org/pipermail/haskell-platform/2009-April/000140.htm... Just thought you might want to know, Claus http://www.haskell.org/haskellwiki/Haskell_Platform http://trac.haskell.org/haskell-platform/wiki/Library/VersionMatrix http://trac.haskell.org/haskell-platform/ Release dates: http://projects.haskell.org/pipermail/haskell-platform/2009-April/000123.htm... Mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Windows installer RC (does *not* include glut32.dll): http://projects.haskell.org/pipermail/haskell-platform/2009-May/000147.html
Am Samstag, 2. Mai 2009 17:58:23 schrieb Claus Reinke:
[...] so it might be a good idea to check that it works on your platforms.
Exactly. Of course reports about problems and suggestions for improvements are always welcome, but I wouldn't mind reports about working platforms, too. Currently I don't have a clear picture which package works where...
- initial release appears imminent, so it is too late to get bug fixes in now, but you could test the installer release candidates. [...]
Regarding the OpenGL/GLUT packages I would consider the upcoming HP release alpha quality only, because all the recent bug fixes will *not* be included. Nevertheless, give it a try to see if the installer/RPM/whatever works and for serious work, wait for the next minor release of the HP. This raises a point which is a bit unclear, at least for me: Where do users of the HP report a bug? It can be a bit tricky to decide if it's only a packaging bug, which I can't fix, or a real bug in the OpenGL/GLUT binding. Has this been discussed in the "HP inner circle"?
- I'm not sure whether the HP policy arguments would affect Sven's recent feature additions - they won't be in the initial HP release, but the question is whether they'll be in the planned bug-fix release, soon, or in the next major HP release, which is nowhere near. [...]
I really, really hope that the minor HP release will allow feature additions where the major version number of the package stays the same. Everything else would bring down distribution of much-wanted features to a crawl and force people to install the packages by hand once again. But again, I don't have a clue what the HP people decided about this...
Windows installer RC (does *not* include glut32.dll): http://projects.haskell.org/pipermail/haskell-platform/2009-May/000147.html
Personally I hope this will get fixed for the initial release, otherwise the HP will be only semi-functional out-of-the-box. Cheers, S.
Exactly. Of course reports about problems and suggestions for improvements are always welcome, but I wouldn't mind reports about working platforms, too. Currently I don't have a clear picture which package works where...
I've installed OpenGL-2.2.1.1 and GLUT-2.1.1.2 with ghc-6.11.20090320, on windows xp, using cygwin&mingw, though I had to add a configure option:-( cabal install opengl --configure-option="--host=i386-unknown-mingw32" cabal install glut --configure-option="--host=i386-unknown-mingw32" (that is with "GLUT for Win32 version 3.7.3 as of October 2nd 2000").
This raises a point which is a bit unclear, at least for me: Where do users of the HP report a bug? It can be a bit tricky to decide if it's only a packaging bug, which I can't fix, or a real bug in the OpenGL/GLUT binding. Has this been discussed in the "HP inner circle"?
I'm a square, I belong to no circles!-) You'd need to ask on the HP list. But OpenGL/GLUT don't have a trac instance yet, and I've had little success in the past with cc-ing you on issue reports, so having all OpenGL/GLUT reports on the HP trac, in a OpenGL/GLUT component, wouldn't be a bad start, would it? Of course, you could add an OpenGL/GLUT trac on trac.haskell.org: http://community.haskell.org/ and then there'd be the question of which trac to use for what.. I'd expect bugs to be reported on either trac, then forwarded to the other one if necessary. The same as currently happens with ghc vs hackage/cabal vs haddock tickets.
I really, really hope that the minor HP release will allow feature additions where the major version number of the package stays the same. Everything else would bring down distribution of much-wanted features to a crawl and force people to install the packages by hand once again. But again, I don't have a clue what the HP people decided about this...
OpenGL/GLUT is a special case, because it was dropped from extralibs so long before HP had code associated with it. If not for that gap, the time-based HP releases might work (HP is about easy access to stable reference sets of packages, not about the latest versions). So I agree that there should be an exception to the general HP policies to get OpenGL/GLUT off to a good start again. But that's just me (I also argued against dropping OpenGL/GLUT from extralibs) - if there are only one or two people affected, there's no reason for action, and if there are more people affected, they should make themselves heard in the appropriate forums. On windows, OpenGL/GLUT does seem to install fairly easily using cabal, provided one has msys or cygwin, and glut.. It can only be easier on other systems, right?-) The problem is that the Haskell binding would allow people to use OpenGL/GLUT who do not usually dabble in C or msys, so having a binary tarball (or an uptodate HP installer) helps a lot. Not to mention users who can't install stuff, let alone msys, on the machines they want to use for OpenGL/GLUT hacking. Unfortunately, with OpenGL/GLUT no longer in extralibs, the existing machinery for daily binary snapshots of the latest package version (via ghc snapshots) is gone, and the hackage server probably can't build windows binaries. But someone else could set up a weekly build of OpenGL/GLUT on a spare windows desktop. Or the situation with msys or cygwin installation to support cabal install could be cleaned up to get rid of this issue once and for all.. The question is how many potential OpenGL/GLUT users are still affected by this, ie, not served by 'cabal install'?
Windows installer RC (does *not* include glut32.dll): http://projects.haskell.org/pipermail/haskell-platform/2009-May/000147.html
Personally I hope this will get fixed for the initial release, otherwise the HP will be only semi-functional out-of-the-box.
If anyone else wants to chime in, the haskell platform mailing list is the place to go. Claus
participants (2)
-
Claus Reinke -
Sven Panne