GLFW-0.5.0.0 is released
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 system. 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 details. 6. An example program and detail change log are included if you unpack the source. 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@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-1.1.0.1 ... linking ... done. Loading package GLURaw-1.1.0.0 ... linking ... done. Loading package ObjectName-1.0.0.0 ... linking ... done. Loading package StateVar-1.0.0.0 ... linking ... done. Loading package Tensor-1.0.0.1 ... linking ... done. Loading package OpenGL-2.4.0.1 ... linking ... done. Loading package GLFW-0.5.0.0 ... linking ... done. objc[18039]: 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 0x105e00740' 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! -- Regards, Paul Liu
On Sat, Jan 21, 2012 at 4:32 AM, Paul Liu <ninegua@gmail.com> wrote:
There is now a new GLFW package on hackage with version number 0.5.0.0.
Congrats! [snip]
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.
Does it still happen with -fno-ghci-sandbox? That fixes these sort of bugs with GLFW-b (and other libraries). If so, then the cause of the problem is the use of thread local storage in the vendor APIs (OpenGL on OSX is an example). I hope that helps, Jason
On Sat, Jan 21, 2012 at 2:05 PM, Jason Dagit <dagitj@gmail.com> wrote:
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.
Does it still happen with -fno-ghci-sandbox? That fixes these sort of bugs with GLFW-b (and other libraries). If so, then the cause of the problem is the use of thread local storage in the vendor APIs (OpenGL on OSX is an example).
Thanks for the tips! As I'm testing now, ghci -fno-ghci-sandbox only seems to work with dynamically linked libraries, i.e., with GLFW-b, or GLFW installed with "--flags dynamic". Statically compiled GLFW C library would still give the "__NSCFString autoreleased with no pool in place" error. -- Regards, Paul Liu
participants (2)
-
Jason Dagit -
Paul Liu