[Haskell-cafe] GLFW-0.5.0.0 is released
ninegua at gmail.com
Sat Jan 21 13:32:34 CET 2012
There is now a new GLFW package on hackage with version number
0.5.0.0. Maintainers of packages that depend on GLFW may want to
update your packages since (1) GLFW-0.4.2 is mostly broken on OS X
Lion (10.7); (2) there are incompatible API changes.
Notable changes include (but not limited to):
1. It now uses GLFW C library version 2.7.2 on all platforms.
2. It still tries to compile and build a static version of the C
library on all platforms. If this is not what you want, use '--flags
dynamic' to dynamically link to pre-installed glfw C library on your
3. It nows does a much better job at configuring itself on Linux and FreeBSD.
4. There is an outstanding bug preventing GLFW programs to be invoked
from GHCi on OS X. One has to compile before running GLFW programs.
5. Documentation has been improved, and there are also API changes
affecting window params and hints. See the hackage documentation for
6. An example program and detail change log are included if you unpack
Many thanks to Marc Sunet and a lot of other people for sending in bug
reports and helping out with this upgrade. Marc is now also a
maintainer of this package. Please send your bug report to either of
us or to the GLFW mailing list <glfw at projects.haskell.org>.
For new users to GLFW or GLFW-b, there are some style and API
differences between these two packages (see
https://github.com/bsl/GLFW-b/blob/master/README.md), and in
particular, GLFW includes some basic texture support and a
"quick-and-dirty" font rendering hack (not found in GLFW C library).
Now, more on the outstanding bug with GHCi on OS X. Here is what
happens when invoking initialize from GHCi on OS X:
Prelude> import Graphics.UI.GLFW
Prelude Graphics.UI.GLFW> initialize
Loading package OpenGLRaw-22.214.171.124 ... linking ... done.
Loading package GLURaw-126.96.36.199 ... linking ... done.
Loading package ObjectName-188.8.131.52 ... linking ... done.
Loading package StateVar-184.108.40.206 ... linking ... done.
Loading package Tensor-220.127.116.11 ... linking ... done.
Loading package OpenGL-18.104.22.168 ... linking ... done.
Loading package GLFW-0.5.0.0 ... linking ... done.
objc: Object 0x105e00a70 of class __NSCFString autoreleased
with no pool in place - just leaking - break on
objc_autoreleaseNoPool() to debug
2012-01-21 03:23:58.574 ghc[18039:1303] -[NSAutoreleasePool init]:
unrecognized selector sent to instance 0x105e00740
2012-01-21 03:23:58.577 ghc[18039:1303] *** Terminating app due to
uncaught exception 'NSInvalidArgumentException', reason:
'-[NSAutoreleasePool init]: unrecognized selector sent to instance
On the other hand, if GLFW is installed with the dynamic flag to link
to a pre-installed system libglfw.dylib, then initialize would work
fine but again GLFW applications still fail to run properly as the
window fails to receive user input and seems to hang. The enableGUI
hack wouldn't help either (and is broken on 10.7). I believe this
situation is the same when running GLFW-b applications from GHCi on OS
X, since it builds and installs dynamic library on OS X too. Compiled
applications are not affected by this bug.
Any help is greatly appreciated! Thanks!
More information about the Haskell-Cafe