glfw-b,bsl

Cannot load GLFW-b-0.1.0.4 into ghci on win7 x86-64 with GHC 7.6.1

Prelude Main> main
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package GLFW-b-0.1.0.4 ... linking ... ghc.exe: unable to load package `GLFW-b-0.1.0.4'
Prelude Main> :q
Leaving GHCi.
<interactive>: C:\Users\Dan\AppData\Roaming\cabal\GLFW-b-0.1.0.4\ghc-7.6.1\HSGLFW-b-0.1.0.4.o: unknown symbol `__imp_glGetString'

Will gladly provide more information.

Error building GLFW-b on OpenBSD

Hi,

I tried to build the bindings of GLFW for Haskell on my machine that run OpenBSD/amd64 v6.3, but I had troubles completing the procedure; here the log for bindings-GLFW:

$ cabal install bindings-GLFW
Resolving dependencies...
Downloading bindings-DSL-1.0.25...
Configuring bindings-DSL-1.0.25...
Building bindings-DSL-1.0.25...
Installed bindings-DSL-1.0.25
Downloading bindings-GLFW-3.2.1.1...
Configuring bindings-GLFW-3.2.1.1...
Building bindings-GLFW-3.2.1.1...
Failed to install bindings-GLFW-3.2.1.1
Build log (/home/manuel/.cabal/logs/ghc-8.2.2/bindings-GLFW-3.2.1.1-4CzYP9nlXrfJkw6ue0vpOp.log):
cabal: Entering directory '/home/manuel/.cabal/tmp/cabal-tmp-89533/bindings-GLFW-3.2.1.1'
Configuring bindings-GLFW-3.2.1.1...
Preprocessing library for bindings-GLFW-3.2.1.1..
dist/build/Bindings/GLFW_hsc_make.o: In function `main':
dist/build/Bindings/GLFW_hsc_make.c:(.text+0x1b2): warning: strcpy() is almost always misused, please use strlcpy()
Building library for bindings-GLFW-3.2.1.1..
[1 of 1] Compiling Bindings.GLFW ( dist/build/Bindings/GLFW.hs, dist/build/Bindings/GLFW.o )

In file included from glfw/src/context.c:28:0: error:

glfw/src/internal.h:33:11: error:
fatal error: 'glfw_config.h' file not found
#include "glfw_config.h"
^~~~~~~~~~~~~~~
|
33 | #include "glfw_config.h"
| ^
1 error generated.
cc' failed in phase C Compiler'. (Exit code: 1)
cabal: Leaving directory '/home/manuel/.cabal/tmp/cabal-tmp-89533/bindings-GLFW-3.2.1.1'
Updating documentation index /home/manuel/.cabal/share/doc/x86_64-openbsd-ghc-8.2.2/index.html
cabal: Error: some packages failed to install:
bindings-GLFW-3.2.1.1-4CzYP9nlXrfJkw6ue0vpOp failed during the building phase.
The exception was:
ExitFailure 1

I temporarily solved the above issue copying glfw_config.h from glfw/include/os/unix-like/ into glfw/include/GLFW inside the tarball, but I noticed inside bindings-GLFW.cabal that there is not support for OpenBSD (only Linux/FreeBSD), so I also want to request, please, if you can add support for OpenBSD to the GLFW bindings. But proceding to build GLFW-b I got this error:

$ cabal install GLFW-b
Resolving dependencies...
Downloading GLFW-b-3.2.1.0...
Configuring GLFW-b-3.2.1.0...
Building GLFW-b-3.2.1.0...
Failed to install GLFW-b-3.2.1.0
Build log (/home/manuel/.cabal/logs/ghc-8.2.2/GLFW-b-3.2.1.0-5DDe7ETkGHA7Z1dG5vqrBR.log ):
cabal: Entering directory '/home/manuel/.cabal/tmp/cabal-tmp-75226/GLFW-b-3.2.1.0'
Configuring GLFW-b-3.2.1.0...
Preprocessing library for GLFW-b-3.2.1.0..
Building library for GLFW-b-3.2.1.0..
[1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics/UI/GLFW/Types.hs, dist/build/Graphics/UI/GLFW/Types.o )
ghc: /home/manuel/.cabal/lib/x86_64-openbsd-ghc-8.2.2/bindings-GLFW-3.2.1.1-4CzYP9nlXrfJkw6ue0vpOp/HSbindings-GLFW-3.2.1.1-4CzYP9nlXrfJkw6ue0vpOp.o:
unknown symbol _glfwPlatformGetCurrentContext' ghc: unable to load package bindings-GLFW-3.2.1.1'
cabal: Leaving directory '/home/manuel/.cabal/tmp/cabal-tmp-75226/GLFW-b-3.2.1.0'
cabal: Error: some packages failed to install:
GLFW-b-3.2.1.0-5DDe7ETkGHA7Z1dG5vqrBR failed during the building phase. The
exception was:
ExitFailure 1

I don't know how to fix this "unknown symbol" error...

Also, not an issue just taking advantage of the situation, out of my curiosity and my ignorance...
I noticed the GLFW bindings come with a bundled copy of the sources of the official GLFW, may I ask why the need to include the sources (and to build the GLFW library with the bindings)?
Would this mean that the GLFW library will be statically compiled automatically and included in any Haskell application using it and one won't have to care about installing separately the library in every system the application will be deployed? Great for portability!

Thank you very much.

Segfault when calling init

When using GLFW-b-1.4.6, the following program will cause a segfault.

import qualified Graphics.UI.GLFW as G
main = G.init

Here’s a gdb backtrace.

#0  0x00000000004b8228 in _glfwPlatformInit ()
#1  0x00000000004b560b in glfwInit ()
#2  0x0000000000409440 in GLFWzmbzm1zi4zi6_GraphicsziUIziGLFW_init1_info ()
#3  0x0000000000000000 in ?? ()

Character Release Event

Let me start with the comment found in the bundled GLFW C-Library (glfw/lib/window.c _glfwInputChar):

    if( action != GLFW_PRESS )
    {
        // This intentionally breaks release notifications for Unicode
        // characters, partly to see if anyone cares but mostly because it's
        // a nonsensical concept to begin with
        //
        // It will remain broken either until its removal in the 3.0 API or
        // until someone explains, in a way that makes sense to people outside
        // the US and Scandinavia, what "Unicode character up" actually means
        //
        // If what you want is "physical key up" then you should be using the
        // key functions and/or the key callback, NOT the Unicode input
        //
        // However, if your particular application uses this misfeature for...
        // something, you can re-enable it by removing this if-statement
        return;
    }

As long as the GLFW-b bindings are bundled with this version (2.7) of the GLFW C-library I would like to have the above if-statement removed. As my argument I want to present the current bizarre sequence of events:

I register both char and key callbacks
I hold down the 'shift' key on my US Intl. Keyboard
While still holding down the 'shift' key, I press the '.'-button
The char callback mechanism passes "Char '<' True" to my registered char-callback function
I release the '.' button
The key callback mechanism passes "Char '.' False" to my registered key-callback function

When the above mentioned if-statement would be removed, I would at least get a corresponding "Char '<' False" event. Now it feels like the '.'-button is released without ever being pressed, and the '>'-char is never being released.

glEnable/glDisable support

The functions glEnable and glDisable are currently not supported. These calls enable and disable certain features and behaviours of GLFW. This can be found in section 3.11.1 of the GLFW reference version 2.7.

It may be worthwhile to wrap the available options as well, such as GLFW_AUTO_POLL_EVENTS, a setting that when disabled, prevents glfwSwapBuffers from implicitly calling glfwPollEvents.

can't static link on OSX

I don't know if I'm just being dense, but for the life of me, I can't get glfw-b-0.1.0.1 or glfw-b-0.1.0.2 to statically link into my executable. As far as I can tell, when the makefile was changed to only build the dylib, the generated .a is no longer valid for static linking. GCC's linker always chooses the dylib, which is a pain when I want to redistribute the binary with no special dependencies.

I successfully linked against 0.0.2.6, (pre 59d9fc0f48/Makefile) but all else equal, I'd prefer to be on the latest version.

IO exceptions in callbacks

The Haskell report, FFI addendum says:

"If an evaluation triggered by an external invocation of an exported Haskell value returns with an exception, the system behaviour is undefined. Thus, Haskell exceptions have to be caught within Haskell and explicitly marshalled to the foreign code."

In GHC, if a Haskell callback to C throws an exception, everything dies quite ungracefully.

In GLFW-b, I hit this behavior with a small program, and it puzzled me that my bracket finalizer didn't run.

This small program triggers the problem: http://lpaste.net/96989

A) It should be documented ("Don't have exceptions in callbacks")
B) Exceptions should be forwarded to the pollEvents or any other relevant Haskell invocation somehow, to avoid ungraceful crash but still allow termination of the mainloop
C) If pollEvents returned a list of events (with some event ADT) rather than IO callbacks this would also alleviate the problem while also being a more straight-forward API

1.4.7.1 broken

I updated GLFW-b, and now I got these errors:

Linking dist/build/initialrevision/initialrevision ...
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(context.o): In function `_glfwIsValidContext':
context.c:(.text+0x455): undefined reference to `_glfwPlatformGetCurrentContext'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(context.o): In function `glfwMakeContextCurrent':
context.c:(.text+0x501): undefined reference to `_glfwPlatformGetCurrentContext'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(context.o): In function `glfwSwapInterval':
context.c:(.text+0x5c0): undefined reference to `_glfwPlatformGetCurrentContext'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(context.o): In function `glfwExtensionSupported':
context.c:(.text+0x61c): undefined reference to `_glfwPlatformGetCurrentContext'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(context.o): In function `glfwGetProcAddress':
context.c:(.text+0x781): undefined reference to `_glfwPlatformGetCurrentContext'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(context.o):context.c:(.text+0x7d4): more undefined references to `_glfwPlatformGetCurrentContext' follow
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(x11_init.o): In function `_glfwCreateCursor':
x11_init.c:(.text+0x149): undefined reference to `XcursorImageCreate'
x11_init.c:(.text+0x1c6): undefined reference to `XcursorImageLoadCursor'
x11_init.c:(.text+0x1d1): undefined reference to `XcursorImageDestroy'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(x11_init.o): In function `_glfwPlatformInit':
x11_init.c:(.text+0x3a3): undefined reference to `XineramaQueryExtension'
x11_init.c:(.text+0x14ff): undefined reference to `XineramaIsActive'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(x11_monitor.o): In function `_glfwPlatformGetMonitors':
x11_monitor.c:(.text+0x51f): undefined reference to `XineramaQueryScreens'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(x11_window.o): In function `_glfwPlatformPollEvents':
x11_window.c:(.text+0x2598): undefined reference to `_glfwKeySym2Unicode'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(glx_context.o): In function `_glfwPlatformSwapInterval':
glx_context.c:(.text+0x8e4): undefined reference to `_glfwPlatformGetCurrentContext'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(glx_context.o): In function `_glfwInitContextAPI':
glx_context.c:(.text+0x9b7): undefined reference to `_glfwInitTLS'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(glx_context.o): In function `_glfwTerminateContextAPI':
glx_context.c:(.text+0x1): undefined reference to `_glfwTerminateTLS'
/home/phaazon/dev/initialrevision/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/bindings-GLFW-3.1.1/libHSbindings-GLFW-3.1.1.a(glx_context.o): In function `_glfwPlatformMakeContextCurrent':
glx_context.c:(.text+0x88f): undefined reference to `_glfwSetCurrentContext'
glx_context.c:(.text+0x8b4): undefined reference to `_glfwSetCurrentContext'
collect2: error: ld returned 1 exit status

Window not closing on debian sid

Versions installed: 0.1.0.4

The callback gets called but hangs after returning True.

Any ideas?

GHCi Segmentation Fault on OS X (10.8)

Running GLFW applications from ghci fails with a segmentation fault, even with various combinations of -framework Carbon, -fno-ghci-sandbox and the enableGUI hack.

Here is a small test case that will cause the segmentation fault on OS X

import qualified Graphics.UI.GLFW as GLFW
import qualified Graphics.Rendering.OpenGL as GL

import EnableGUI

main = do
  _ <- GLFW.initialize
  _ <- GLFW.openWindow GLFW.defaultDisplayOptions

  putStrLn "Setting clear color"
  GL.clearColor GL.$= GL.Color4 0 0 0 1
  putStrLn "Done setting clear color"

  GLFW.sleep 10

  GLFW.closeWindow
  GLFW.terminate

In this case, it will segfaults when GL.clearColor is called

getJoystickName returns (Just "") when joystick is not present.

It seems that glfw-b is returning a name regardless of whether or not a joystick is connected (and if not that name is “”), which is odd because the type is IO (Maybe String):

    getAllJoystickNames :: IO (M.Map Joystick String)
    getAllJoystickNames = do
        let joysticks = [Joystick'1 .. Joystick'16]
        mNames <- forM joysticks $ \js -> ((js,) <$>) <$> getJoystickName js
        return $ M.fromList $ catMaybes mNames

    -- With one controller plugged in this returns:
    -- fromList [(Joystick'1,"Logitech Dual Action"),(Joystick'2,""),(Joystick'3,""),(Joystick'4,""),(Joystick'5,""),(Joystick'6,""),(Joystick'7,""),(Joystick'8,""),(Joystick'9,""),(Joystick'10,""),(Joystick'11,""),(Joystick'12,""),(Joystick'13,""),(Joystick'14,""),(Joystick'15,""),(Joystick'16,"")

    -- It seems it should return instead:
    -- fromList [(Joystick'1, "Logitech Dual Action")]

Failed build win7/64

Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bindings-DSL-1.0.22 ... linking ... done.
Loading package bindings-GLFW-3.1.1.2 ... linking ... ghc.exe: unable to load package bindings-GLFW-3.1.1.2' ghc.exe: warning: _vsnprintf from msvcrt is linked instead of __imp__vsnprintf ghc.exe: C:\Users\crimson\AppData\Roaming\cabal\x86_64-windows-ghc-7.8.3\bindings-GLFW-3.1.1.2\HSbindings-GLFW-3.1.1.2.o: unknown symbolstrdup'
cabal: Error: some packages failed to install:
GLFW-b-1.4.7.2 failed during the building phase. The exception was:
ExitFailure 1

Win7/64

GLFW 3.2 Support

Is GLFW version 3.2 in the pipeline? I am writing Vulkan API code, and at the moment the only function from 3.2 I would like is glfwCreateWindowSurface. This allows access to the framebuffer used by the display - otherwise only off-screen rendering is possible.

Andre

Can't terminate GLFW from ghci

Hi folks,

I'm trying to use GLFW from ghci, which is working excellently until it comes time to terminate the program. After calling GLFW.terminate, I'm left with a rogue GHC process that (from Sampling with Activity Monitor) seems deadlocked in some GHC threads.

I've narrowed it down to about as simple as it could be:

lukexi@LukeMBP:~$ ghci -fno-ghci-sandbox
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ: import qualified Graphics.UI.GLFW as GLFW
λ: GLFW.init >> GLFW.createWindow 100 100 "test" Nothing Nothing >> GLFW.pollEvents >> GLFW.terminate
Loading package bindings-DSL-1.0.22 ... linking ... done.
Loading package bindings-GLFW-3.1 ... linking ... done.
Loading package GLFW-b-1.4.6 ... linking ... done.
λ:

I'm then left with a generic "ghc" process that only goes away if I either Force-Quit it or kill ghci. Further calls to GLFW.init return False.

Here's the sample from Activity Monitor

Call graph:
    2742 Thread_1192120   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2742 start  (in ghc) + 52  [0x100001c34]
    +   2742 main  (in ghc) + 115  [0x1000ead73]
    +     2742 hs_main  (in libHSrts_thr-ghc7.8.3.dylib) + 138  [0x106a7271a]
    +       2742 scheduleWaitThread  (in libHSrts_thr-ghc7.8.3.dylib) + 167  [0x106a76547]
    +         2742 schedule  (in libHSrts_thr-ghc7.8.3.dylib) + 502  [0x106a76756]
    +           2742 yieldCapability  (in libHSrts_thr-ghc7.8.3.dylib) + 354  [0x106a65f82]
    +             2742 waitCondition  (in libHSrts_thr-ghc7.8.3.dylib) + 6  [0x106a8ccf6]
    +               2742 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fff8a9d0136]
    2742 Thread_1192121
    + 2742 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff9639641d]
    +   2742 _pthread_start  (in libsystem_pthread.dylib) + 176  [0x7fff963981e5]
    +     2742 _pthread_body  (in libsystem_pthread.dylib) + 131  [0x7fff96398268]
    +       2742 scheduleWorker  (in libHSrts_thr-ghc7.8.3.dylib) + 13  [0x106a770ed]
    +         2742 schedule  (in libHSrts_thr-ghc7.8.3.dylib) + 502  [0x106a76756]
    +           2742 yieldCapability  (in libHSrts_thr-ghc7.8.3.dylib) + 354  [0x106a65f82]
    +             2742 waitCondition  (in libHSrts_thr-ghc7.8.3.dylib) + 6  [0x106a8ccf6]
    +               2742 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fff8a9d0136]
    2742 Thread_1192122
    + 2742 ???  (in <unknown binary>)  [0x109a258eb]
    +   2742 poll  (in libsystem_kernel.dylib) + 10  [0x7fff8a9d15c2]
    2742 Thread_1192123
    + 2742 cbC6_info  (in libHSbase-4.7.0.1-ghc7.8.3.dylib) + 56  [0x10637c848]
    +   2742 kevent  (in libsystem_kernel.dylib) + 10  [0x7fff8a9d121a]
    2742 Thread_1192125
    + 2742 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff9639641d]
    +   2742 _pthread_start  (in libsystem_pthread.dylib) + 176  [0x7fff963981e5]
    +     2742 _pthread_body  (in libsystem_pthread.dylib) + 131  [0x7fff96398268]
    +       2742 scheduleWorker  (in libHSrts_thr-ghc7.8.3.dylib) + 13  [0x106a770ed]
    +         2742 schedule  (in libHSrts_thr-ghc7.8.3.dylib) + 502  [0x106a76756]
    +           2742 yieldCapability  (in libHSrts_thr-ghc7.8.3.dylib) + 354  [0x106a65f82]
    +             2742 waitCondition  (in libHSrts_thr-ghc7.8.3.dylib) + 6  [0x106a8ccf6]
    +               2742 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fff8a9d0136]
    2742 Thread_1192144   DispatchQueue_2: com.apple.libdispatch-manager  (serial)
    + 2742 _dispatch_mgr_thread  (in libdispatch.dylib) + 52  [0x7fff8b34aa6a]
    +   2742 kevent64  (in libsystem_kernel.dylib) + 10  [0x7fff8a9d1232]
    2742 Thread_1192197
    + 2742 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff9639641d]
    +   2742 _pthread_start  (in libsystem_pthread.dylib) + 176  [0x7fff963981e5]
    +     2742 _pthread_body  (in libsystem_pthread.dylib) + 131  [0x7fff96398268]
    +       2742 _NSEventThread  (in AppKit) + 137  [0x7fff89fee33b]
    +         2742 CFRunLoopRunSpecific  (in CoreFoundation) + 296  [0x7fff8ff54858]
    +           2742 __CFRunLoopRun  (in CoreFoundation) + 1371  [0x7fff8ff54ffb]
    +             2742 __CFRunLoopServiceMachPort  (in CoreFoundation) + 212  [0x7fff8ff55b34]
    +               2742 mach_msg  (in libsystem_kernel.dylib) + 55  [0x7fff8a9ca64f]
    +                 2742 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff8a9cb4de]
    2742 Thread_1192201: OGL Profiler
      2742 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff9639641d]
        2742 _pthread_start  (in libsystem_pthread.dylib) + 176  [0x7fff963981e5]
          2742 _pthread_body  (in libsystem_pthread.dylib) + 131  [0x7fff96398268]
            2742 glcDebugListener  (in OpenGL) + 336  [0x7fff940a89b5]
              2742 mach_msg  (in libsystem_kernel.dylib) + 55  [0x7fff8a9ca64f]
                2742 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff8a9cb4de]

(I'm not actually sure where the extra GHC threads are coming from yet...)

Is anyone doing this successfully?

Provide API to query window hints

Older versions of GLFW-b used to provide a getWindowValue function to query things like alpha bits, stencil bits, aux buffers, etc. (i.e. basically everything that the new API calls WindowHints). Right now it seems like you can only set these options but you can no longer query them and I wanted to ask if you could provide an API for querying them.

I ran into this issue when trying to fix gloss to build against newer versions of GLFW-b

Upgrade to 3.3

GLFW-3.3 was released this Wednesday. We should upgrade our bindings to match. To do so, we must first address the lower-level bindings in bindings-GLFW. Once those are in place, we can add the relevant features here. In particular we will need to address the following from the release notes:

Building in windows with stack

Hi,
I am having problems building the GLFW-b via stack in Windows. It builds just fine on Linux machine.
I am not entirely sure this is a GLFW-b problem, but any help or guidance in the right direction is very appreciated.

The log is a screenshot because its running in VM

Failure to init/createWindow after a previous session

Summary

If GLFW-b is stood up and torn down on the same main-thread multiple times it may fail to create windows. The issue seems to be connected to event handling.

Repro

Write a program which initializes and deinitializes GLFW-b multiple times on the same thread. For extra reproducability, try posting and waiting on events a lot.

Add this test to your local branch
Build and run the test with stack

$ stack test GLFW-b:two
GLFW-b-1.4.8.1: test (suite: two)

Testing multiple initializations of GLFW-b
Set up and tore down GLFW-b once
two: GlfwCreateWindowException

Test suite failure for package GLFW-b-1.4.8.1
    two:  exited with: ExitFailure 1
Logs printed to console

Expected behavior

GLFW initializes, creates a window, destroys the window, and deinitializes.
GLFW again initializes, creates a window, destroys the window, and deinitializes.

Actual behavior

GLFW fails to return a result from createWindow on the second call.

Details

I'm using stack, and the stack.yaml on master hasn't been updated in a year.
My test machine is running OSX on a mid 2015 MacbookPro with two graphics cards.

Hackage documentation missing

The haddocks on Hackage seem to be missing. If I go here:

http://hackage.haskell.org/package/GLFW-b-1.4.1

... and click on the Graphics.UI.GLFW module to go here:

http://hackage.haskell.org/package/GLFW-b-1.4.1/docs/Graphics-UI-GLFW.html

... I get a "Page not found" error. The latest version of the library that still works is 1.2.1.

Update to allow base 5?

We also need to update bindings-GLFW for this if we want base 5.

Every Key event is Key'UnknownKey

I set a callback using setKeyCallback function but every key press is just Key'UnknownKey. For instance if I press Escape the Key would be Key'UnknownKey and scancode would be 9. Any ideas why the keys are not recognized? Maybe I’m missing some dependencies like Xkb to map some layouts or something?

not working in Mac OS X ghci

HUnit 1.3 support

The latest (HUnit-1.3.1.1) is not supported by the GLFW-b test-suite so it has been disabled in stackage. When a fix is published to hackage please send a PR to re-enable this to stackage (it's in the skipped-tests section) or ping me.

New hackage and stackage version?

A lot of documentation got added, but that update hasn't been pushed to Hackage or Stackage in a few months. Any chance we could get that put up as a version 1.4.8.2 (current is 1.4.8.1)

Bounded instance for the Key data type

The Key data type is both Enum and Ord, so why not also Bounded?

createWindow doesn't handle non-ascii characters on windows

The code

createWindow 1024 768 "λ 3D" Nothing Nothing

produces a window with the title " 3D"

glfwPostEmptyEvent added in GLFW 3.1 would be really handy

Shouldn't be hard to add to the bindings. This command would be useful to let a thread wake up the main thread which is blocked indefinitely waiting for events. Polling reduces responsiveness and wastes CPU.

getJoystickButtons and getJoystickAxes are returning Nothing while joystick is present.

It seems that I cannot get any joystick input other than name while my controller is present.

    printJoystick :: Joystick -> IO ()
    printJoystick js = do
        present  <- joystickPresent js
        mname    <- getJoystickName js
        mbuttons <- getJoystickButtons js
        maxes    <- getJoystickAxes js
        print $ "Joystick: " ++ show js
        print (present,mname,mbuttons,maxes)

    -- "Joystick: Joystick'1"
    -- (True,Just "Logitech Dual Action",Nothing,Nothing)

Perhaps this is not a glfw-b issue but is instead my fault for not using glfw correctly but after looking at glfw's documentation I can't find any obvious problem with the code above.

waitEventsTimeout on OpenBSD behaves like pollEvents

I've noticed the value I set on waitEventsTimeout is completely ignored, and the function returns immediately, irrespectively of any input, just like pollEvents. I can't install an updated version of GLFW or use an update version of GLFW-b because at the moment there is no GLFW 3.3.0 port for OpenBSD. Has the issue already been fixed? If so, can the fix be backported to GLFW-b v3.2.1.1?
Thank you.

Haskell bindings: GLFW-b v3.2.1.1
Operating System: OpenBSD/amd64 v6.7
GLFW library: GLFW v3.2.1 (2016-08-18)

crash on macOS when calling "terminate"

Before exiting, according to the glfw docs I should call terminate. On macOS this crashes, with two different messages:

$ ./glfw_crash 
calling terminate
Segmentation fault: 11

and

$ ./glfw_crash 
calling terminate
glfw_crash: internal error: stg_ap_p_ret
    (GHC version 8.0.2 for x86_64_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort trap: 6

macOS version: 10.13.2
GLFW-b version: 3.2.1.0
GHC version: 8.0.2

If I leave out the call to terminate, it seems to work ok. On Windows 7 and GHC 8.2.1 calling terminate works fine.

Small example program reproducing the issue on my system is attached.

glfw_crash.hs.txt

Does not link correctly on 64bit mac

I tried to build a GLFW-b example on 64bit osx and noticed that it failed. The problem is that the makefile explicitly asks for -m32. We may need some logic in the makefile to detect how GHC is installed (32bit or 64bit). I'm not sure how to do that.

GL_SHADING_LANGUAGE_VERSION glGetString

Hello,

Just want to check on how to do this when using GLFW-b? I could find getVersion and getVersionString. But, nothing for getting the Shading Language version.

printf("Supported GLSL is %s\n", (const char*)glGetString(GL_SHADING_LANGUAGE_VERSION));

Thanks

Proposal : use strict data fields

Looking at Graphics.UI.GLFW.Types, I see that every data has lazy fields.

My understanding of performance optimization wrt lazy / strict fields is that if the field is cheap to compute, then it's best to use a strict field, because it won't be slower, less memory will be used, also because we can possibly pack it in the structure.

I think many datas could benefit from having strict fields because the fields fall in the "cheap to compute / can be unpacked" category.

Or is there a reason why we specifically need lazyness in some of them?

Windows build broken since 0.0.2.7

0.0.2.7 broke linking on Windows. cabal compiles package just fine but
everything linked to it fails with:

C:\Users\Marek\AppData\Roaming\cabal\GLFW-b-0.0.2.7\ghc-7.0.4/libHSGLFW-b-0.0.2.7.a(GLFW_stub.o):GLFW_stub.c:(.text+0x3b
): undefined reference to `_imp__stable_ptr_table'

That's probably related to -fPIC or static/dynamic. It applies both to
GHC and GHCi.

Building glfw-b also fails on Windows with --enable-shared:

C:>cabal install --reinstall --enable-shared glfw-b
Resolving dependencies...
[1 of 1] Compiling Main ( C:\Users\Marek\AppData\Local\Temp\GLFW-b-0
.0.2.728636\GLFW-b-0.0.2.7\Setup.hs, C:\Users\Marek\AppData\Local\Temp\GLFW-b-0.
0.2.728636\GLFW-b-0.0.2.7\dist\setup\Main.o )
Linking C:\Users\Marek\AppData\Local\Temp\GLFW-b-0.0.2.728636\GLFW-b-0.0.2.7\dis
t\setup\setup.exe ...
Configuring GLFW-b-0.0.2.7...
Preprocessing library GLFW-b-0.0.2.7...
Building GLFW-b-0.0.2.7...
[1 of 1] Compiling Graphics.UI.GLFW ( dist\build\Graphics\UI\GLFW.hs, dist\build
\Graphics\UI\GLFW.o )
[1 of 1] Compiling Graphics.UI.GLFW ( dist\build\Graphics\UI\GLFW.hs, dist\build
\Graphics\UI\GLFW.dyn_o )
Creating library file: dist\build\libHSGLFW-b-0.0.2.7-ghc7.0.4.dll.a
Registering GLFW-b-0.0.2.7...
Installing library in
C:\Users\Marek\AppData\Roaming\cabal\GLFW-b-0.0.2.7\ghc-7.0.4
setup.exe:
C:\Users\Marek\AppData\Roaming\cabal\GLFW-b-0.0.2.7\ghc-7.0.4.copyFile28492.tmp
:
permission denied
cabal: Error: some packages failed to install:
GLFW-b-0.0.2.7 failed during the final install step. The exception was:
ExitFailure 1

Crash when running a sample program in ghci on OSX

The following program, translated from a GLFW sample program here crashes on OSX 10.9.5, with ghc version 7.8.3 (run with cabal repl) installed from Haskell Platform, GLFW-b 1.4.7.2

{-# LANGUAGE ScopedTypeVariables, RecordWildCards #-}
{-# OPTIONS_GHC -Wall
      -fwarn-type-defaults
      -fno-warn-name-shadowing
      -fwarn-missing-signatures
      -fwarn-hi-shadowing
      -fwarn-orphans
      -fwarn-unused-do-bind
      -fno-warn-unused-imports #-}

module EnvelopesGLFW where

-- {{{ Imports

import Data.Char
import Data.Either
import Data.Function
import Data.Functor
import Data.List
import Data.Maybe
import Data.Monoid
import Data.Ord
import Control.Applicative
import Control.Monad

import Graphics.Rendering.OpenGL as GL
import Graphics.UI.GLFW as GLFW
import Graphics.Rendering.OpenGL (($=))
import Data.IORef
import System.Environment (getArgs, getProgName)

-- }}}
-- {{{ main

require :: String -> Bool -> IO ()
require message success = when (not success) (error message)

main :: IO ()
main = do
  GLFW.init >>= require "GLFW.initialize"
  window <- GLFW.createWindow 800 800 "EnvelopesGLFW.hs" Nothing Nothing >>= \ w ->
           case w of Just w -> return w; Nothing -> do GLFW.terminate; error "GLFW.createWindow"

  GLFW.makeContextCurrent (Just window)
  GLFW.swapInterval 1
  GL.clearColor $= Color4 0 0 0 1

  untilM (GLFW.windowShouldClose window) $ do
    (width, height) <- GLFW.getFramebufferSize window
    GL.viewport $= (GL.Position 0 0, GL.Size (fromIntegral width) (fromIntegral height))
    GL.clear [ColorBuffer]
    GLFW.swapBuffers window
    GLFW.waitEvents

  GLFW.destroyWindow window
  GLFW.terminate

-- }}}
-- {{{ Misc

unlessM :: Monad m => m Bool -> m () -> m ()
unlessM predicate work = do x <- predicate; unless x work

untilM :: Monad m => m Bool -> m () -> m ()
untilM predicate work = loop
  where loop = do x <- predicate; unless x $ work >> loop

-- }}}

The failure looks a bit mysterious to me, I'm not sure what leads to it. This is the output:

ghci> EnvelopesGLFW.main
2015-05-05 20:26:42.484 ghc[44787:1203] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1056.17/Misc.subproj/NSUndoManager.m:328
2015-05-05 20:26:43.211 ghc[44787:1203] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2015-05-05 20:26:44.407 ghc[44787:1203] (
        0   CoreFoundation                      0x00007fff8cdc825c __exceptionPreprocess + 172
        1   libobjc.A.dylib                     0x00007fff8ad0de75 objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff8cdc8038 +[NSException raise:format:arguments:] + 104
        3   Foundation                          0x00007fff8d3b6361 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
        4   Foundation                          0x00007fff8d3208ac +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 156
        5   AppKit                              0x00007fff83c20a23 -[NSApplication run] + 688
        6   libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib 0x000000010e135dce _glfwPlatformCreateWindow + 1406
        7   libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib 0x000000010e131215 glfwCreateWindow + 597
        8   libHSGLFW-b-1.4.7.2-ghc7.8.3.dylib  0x000000010e187ac9 c26bN_info + 193
)
2015-05-05 20:26:44.408 ghc[44787:1203] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1056.17/Misc.subproj/NSUndoManager.m:328
2015-05-05 20:26:44.410 ghc[44787:1203] An uncaught exception was raised
2015-05-05 20:26:44.410 ghc[44787:1203] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2015-05-05 20:26:44.411 ghc[44787:1203] (
        0   CoreFoundation                      0x00007fff8cdc825c __exceptionPreprocess + 172
        1   libobjc.A.dylib                     0x00007fff8ad0de75 objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff8cdc8038 +[NSException raise:format:arguments:] + 104
        3   Foundation                          0x00007fff8d3b6361 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
        4   Foundation                          0x00007fff8d3208ac +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 156
        5   AppKit                              0x00007fff83c20acd -[NSApplication run] + 858
        6   libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib 0x000000010e135dce _glfwPlatformCreateWindow + 1406
        7   libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib 0x000000010e131215 glfwCreateWindow + 597
        8   libHSGLFW-b-1.4.7.2-ghc7.8.3.dylib  0x000000010e187ac9 c26bN_info + 193
)
2015-05-05 20:26:44.412 ghc[44787:1203] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.'
*** First throw call stack:
(
        0   CoreFoundation                      0x00007fff8cdc825c __exceptionPreprocess + 172
        1   libobjc.A.dylib                     0x00007fff8ad0de75 objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff8cdc8038 +[NSException raise:format:arguments:] + 104
        3   Foundation                          0x00007fff8d3b6361 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
        4   Foundation                          0x00007fff8d3208ac +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 156
        5   AppKit                              0x00007fff83c20acd -[NSApplication run] + 858
        6   libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib 0x000000010e135dce _glfwPlatformCreateWindow + 1406
        7   libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib 0x000000010e131215 glfwCreateWindow + 597
        8   libHSGLFW-b-1.4.7.2-ghc7.8.3.dylib  0x000000010e187ac9 c26bN_info + 193
)
libc++abi.dylib: terminating with uncaught exception of type NSException

and this is the stack trace in lldb:

Process 44787 stopped
* thread #4: tid = 0x334295, 0x00007fff83b3a866 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    frame #0: 0x00007fff83b3a866 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill + 10:
-> 0x7fff83b3a866:  jae    0x7fff83b3a870            ; __pthread_kill + 20
   0x7fff83b3a868:  movq   %rax, %rdi
   0x7fff83b3a86b:  jmp    0x7fff83b37175            ; cerror_nocancel
   0x7fff83b3a870:  retq
(lldb) bt
* thread #4: tid = 0x334295, 0x00007fff83b3a866 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
  * frame #0: 0x00007fff83b3a866 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff862ca35c libsystem_pthread.dylib`pthread_kill + 92
    frame #2: 0x00007fff8d13ab1a libsystem_c.dylib`abort + 125
    frame #3: 0x00007fff8d5bff31 libc++abi.dylib`abort_message + 257
    frame #4: 0x00007fff8d5e5952 libc++abi.dylib`default_terminate_handler() + 264
    frame #5: 0x00007fff8ad0e30d libobjc.A.dylib`_objc_terminate() + 103
    frame #6: 0x00007fff8d5e31d1 libc++abi.dylib`std::__terminate(void (*)()) + 8
    frame #7: 0x00007fff8d5e2c5b libc++abi.dylib`__cxa_throw + 124
    frame #8: 0x00007fff8ad0dfa1 libobjc.A.dylib`objc_exception_throw + 343
    frame #9: 0x00007fff8cdc8038 CoreFoundation`+[NSException raise:format:arguments:] + 104
    frame #10: 0x00007fff8d3b6361 Foundation`-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
    frame #11: 0x00007fff8d3208ac Foundation`+[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 156
    frame #12: 0x00007fff83c20acd AppKit`-[NSApplication run] + 858
    frame #13: 0x000000010e135dce libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib`_glfwPlatformCreateWindow + 1406
    frame #14: 0x000000010e131215 libHSbindings-GLFW-3.1.1.3-ghc7.8.3.dylib`glfwCreateWindow + 597
    frame #15: 0x000000010e187ac9 libHSGLFW-b-1.4.7.2-ghc7.8.3.dylib`c26bN_info + 193

Ideally running a GLFW program in ghci should be possible (it's really convenient), but I don't know how ghci might interfere with GLFW. I know that Julia's GLFW bindings don't have this problem.

Use of (<$>) without importing Applicative implies base >= 4.8.0.0

Graphics.UI.GLFW uses (<$>) without importing Applicative. This causes compilation of GLFW-b >= 1.4.8.0 to fail with base <= 4.7.0.2, from before Monad was a subclass of Applicative:

https://hackage.haskell.org/package/base-4.7.0.2/docs/Prelude.html#t:Monad

Documentation

Most callback types and their setter functions lack documentation.

Wrong install-name path for libglfw.dylib on OS X using GHC-HEAD

Hi,

First of all: I have no idea if this is a GHC or an GLFW-b problem.

Context:
ghc-HEAD (7.7.20121111) will have dynamic/shared-by-default installs on OS X.

Problem/Bug:
The dynamicly linked GLFW-b library gets the wrong install-name for libgflw.dylib:

~/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111 $ otool -L ~/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib 
/Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib:
    /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    build/libglfw.dylib (compatibility version 1.0.0, current version 1.0.0)
    /opt/ghc/HEAD-typenats-orig/src/ghc-HEAD-typenats-orig/libraries/base/dist-install/build/libHSbase-4.6.0.0-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /opt/ghc/HEAD-typenats-orig/src/ghc-HEAD-typenats-orig/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.0.0-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/ghc/HEAD-typenats-orig/src/ghc-HEAD-typenats-orig/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.0.0-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

As you can see, the libglfw.dylib gets a relative path to the location where the shared library was originally build, as opposed to where it is installed.

By running:

~/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111 $ install_name_tool -change build/libglfw.dylib /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libglfw.dylib libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib

Everything is fixed:

~/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111 $ otool -L ~/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib 
/Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib:
    /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libglfw.dylib (compatibility version 1.0.0, current version 1.0.0)
    /opt/ghc/HEAD-typenats-orig/src/ghc-HEAD-typenats-orig/libraries/base/dist-install/build/libHSbase-4.6.0.0-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /opt/ghc/HEAD-typenats-orig/src/ghc-HEAD-typenats-orig/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.0.0-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/ghc/HEAD-typenats-orig/src/ghc-HEAD-typenats-orig/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.0.0-ghc7.7.20121111.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

So now I wonder if the install_name_tool -change command should be run in the post-install hooks of the setup script?
Or that something should be changed w.r.t. to the other install/build hooks?

Compilation Hangs

I can't build GLFW-b on my linux machine. The cabal output looks like:

/opt/ghc/7.8.4/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package-name GLFW-b-1.4.7.2 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -package-id bindings-GLFW-3.1.1.2-18847f4840118bbdeaebf04bfd78f741 -XHaskell2010 Graphics.UI.GLFW Graphics.UI.GLFW.C Graphics.UI.GLFW.Types -Wall -fwarn-tabs
[1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics/UI/GLFW/Types.hs, dist/build/Graphics/UI/GLFW/Types.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bindings-DSL-1.0.22 ... linking ... done.
Loading package bindings-GLFW-3.1.1.2 ... ```
while the last line hangs forever.

I suspect there is an issue with dynamic linking or something.
My configuration is:
```% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
% cabal --version
cabal-install version 1.20.0.3
using version 1.20.0.0 of the Cabal library 
% uname -r
3.13.0-37-generic

Any ideas on this?

crash using stdout after GLFW.terminate "<stdout>: commitBuffer: invalid argument (Bad file descriptor)"

this program crashes when the last line, contaning print, is evaluated

import qualified Graphics.UI.GLFW as GLFW

main :: IO ()
main = do
    GLFW.init >>= print
    print "inited"

    GLFW.terminate
    print "terminated"

the program output looks like this:

True
"inited"
Main2: <stdout>: commitBuffer: invalid argument (Bad file descriptor)

a similar program, written in C, doesn't crash

#include <GLFW/glfw3.h>
#include <stdio.h>

int main(void)
{
    printf("%d\n", glfwInit());
    printf("inited\n");

    glfwTerminate();
    printf("terminated\n");
}

the c program output looks like this:

1
inited
terminated

i've done some preliminary messing around and found

if you write to Sysetm.IO.stdout using System.IO.hPrint, it crashes with the same message
if you examine System.IO.stdout using System.IO.{hIsOpen,hIsClosed,hIsReadable,hIsWritable,hIsSeekable before ande after calling GLFW.terminate, the descriptor reports that is is okay

my versions, etc..

system
- ArchLinux, kernel 4.0.6-1-ARCH
haskell
- GHC 7.8.4-1
- cabal-install version 1.22.2.0 using version 1.22.2.0 of the Cabal library
- GLFW-b-1.4.7.2
- bindings-GLFW-3.1.1.3
C code
- gcc (GCC) 5.1.0
- glfw 3.1.1-1 (installed on archlinux via pacman)

Wish: Add support for glfwOpenWindowHint

On my mac I appear to be getting an old version of opengl. I would like to request a minimum version of 3.0. To do this it appears I need access to glfwOpenWindowHint so that I can do the Haskell equivalent of the following:

  glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3);
  glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 0);

Support for additions in 3.1

The additions listed in bsl/bindings-GLFW#19 need to be added once that ticket is resolved.

Question about package distribution

May I ask you a question?
I have c library named "viewer" which depends glfw's includer file and other opengl basic libraries. In generally It works with other libraries such as glfw for visualization.
I want create a package on haskell, but I don't konw how to write the .cabal file.
Of course，I can distribute the library ”viewer“ whick is written by c. but users have to download glfw of c language to use it.
Do you have any good suggestions ？

Crash with multiple windows

When more than one window is created it seems the framebuffer resize callback (and possibly others) of the first window is somehow invalidated upon setting that of the second. The following program creates two windows and sets the framebuffer resize callback of both. Resizing the second window works as expected. Resizing the first produces a segmentation fault.

import Control.Monad
import Graphics.UI.GLFW as GLFW
import Graphics.Rendering.OpenGL.GL as GL

resizeCb win w h = do
    print ("resize",w,h)
    GLFW.makeContextCurrent $ Just win
    viewport $= (Position 0 0, Size (fromIntegral w) (fromIntegral h))
    print ("done",w,h)

main = do
    GLFW.init
    Just win1 <- GLFW.createWindow 400 300 "Resize me and I'll crash" Nothing Nothing
    GLFW.setFramebufferSizeCallback win1 $ Just resizeCb
    Just win2 <- GLFW.createWindow 400 300 "Hello, I can be resized" Nothing Nothing
    GLFW.setFramebufferSizeCallback win2 $ Just resizeCb
    forever $ GLFW.waitEvents

Build support on FreeBSD

FreeBSD isn't supported by GLFW-b.cabal, thus building fails. Changing os(linux) to
os(linux) || os(freebsd) fixes the build issue -- I haven't done any real test of the library yet. (Maybe it just works because it's X11 that matters?)

Thanks!

ominous warning messages

[1 of 1] Compiling Main ( Setup.hs, dist/setup/Main.o )
Linking ./dist/setup/setup ...
Configuring GLFW-b-0.1.0.5...
Building GLFW-b-0.1.0.5...
Preprocessing library GLFW-b-0.1.0.5...
[1 of 1] Compiling Graphics.UI.GLFW ( dist/build/Graphics/UI/GLFW.hs, dist/build/Graphics/UI/GLFW.o )
glfw/lib/window.c: In function ‘glfwOpenWindow’:

glfw/lib/window.c:558:5:
warning: implicit declaration of function ‘_glfwRefreshContextParams’ [-Wimplicit-function-declaration]
glfw/lib/x11/x11_window.c: In function ‘translateKey’:

glfw/lib/x11/x11_window.c:238:5:
warning: ‘XKeycodeToKeysym’ is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarati
ons]

glfw/lib/x11/x11_window.c:260:5:
warning: ‘XKeycodeToKeysym’ is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarati
ons]

Haddock documentation doesn't appear to be working

The landing page for this package on hackage does not seem to include any documentation.

https://hackage.haskell.org/package/GLFW-b

Spurious events?

Hello,

Thanks for sharing the GLFW-b.

I am trying to figure out why I am getting spurious events when I run the GLFW-b-demo. The issue seems to be with GLFW-b. But, I am not sure about it and hence want to get some expert opinion about it.

With this patch to the Main.hs, I am expecting the message "received GLFW event" to be fired only when there is an actual event.

git diff
diff --git a/src/Main.hs b/src/Main.hs
index 89799f4..fcb2b56 100644
--- a/src/Main.hs
+++ b/src/Main.hs
@@ -210,7 +210,9 @@ run = do
     liftIO $ do
         GLFW.swapBuffers win
         GL.flush  -- not necessary, but someone recommended it
-        GLFW.pollEvents
+--         GLFW.pollEvents
+        GLFW.waitEvents
+        liftIO (putStrLn "received GLFW event")
     processEvents

     state <- get

But, for some reason, I keep getting the message "received GLFW event" almost as if it is running in an endless loop. I tested the events behaviour using the tests/events.c of the glfw github master branch and it works fine.

TMPDIR=/tmp/ghc stack exec GLFW-b-demo
    ------------------------------------------------------------
    '?': Print these instructions
    'i': Print GLFW information

    * Mouse cursor, keyboard cursor keys, and/or joystick
      control rotation.
    * Mouse scroll wheel controls distance from scene.
    ------------------------------------------------------------
received GLFW event
window refresh:
window iconify: IconifyState'NotIconified
framebuffer size: 836 513
window size: 836 513
window pos: 0 17
window iconify: IconifyState'NotIconified
window focus: FocusState'Focused
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
key: Key'X 53 KeyState'Pressed [mod keys: none]
char: 'q'
key: Key'X 53 KeyState'Released [mod keys: none]
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
received GLFW event
key: Key'Escape 9 KeyState'Pressed [mod keys: none]
GLFW-b-demo: <stdout>: commitBuffer: invalid argument (Bad file descriptor)
-

Thanks

GLFW-b-1.4.7.1 test suite failure

Citing from http://hydra.cryp.to/build/618569/log/raw:

Running 1 test suites...
Test suite main: RUNNING... 
main: user error (Pattern match failure in do expression at Test.hs:27:5-8)
Test suite main: FAIL

macOS 11.0.1 "Big Sur" compilation problem

On macOS "Big Sur", I'm seeing the following issue when compiling GLFW-b:

$ sw_vers
ProductName:	macOS
ProductVersion:	11.0.1
BuildVersion:	20B29

$ cabal build
Build profile: -w ghc-8.10.2 -O1
In order, the following will be built (use -v for more details):
 - GLFW-b-3.3.0.0 (lib) (first run)
Preprocessing library for GLFW-b-3.3.0.0..
Building library for GLFW-b-3.3.0.0..
[1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics/UI/GLFW/Types.hs, /Users/jsm/workspace/GLFW-b/dist-newstyle/build/x86_64-osx/ghc-8.10.2/GLFW-b-3.3.0.0/build/Graphics/UI/GLFW/Types.o, /Users/jsm/workspace/GLFW-b/dist-newstyle/build/x86_64-osx/ghc-8.10.2/GLFW-b-3.3.0.0/build/Graphics/UI/GLFW/Types.dyn_o )
<command line>: can't load framework: AGL (not found)

My first thought was that perhaps AGL had been removed from "Big Sur", but:

$ ls -l /System/Library/Frameworks | grep AGL
drwxr-xr-x  4 root  wheel  128  1 Jan  2020 AGL.framework

This has also shown up in recent builds of ad-si/Perspec; eg: https://github.com/ad-si/Perspec/runs/1412857351?check_suite_focus=true

bsl / glfw-b Goto Github PK

glfw-b's People

Contributors

Stargazers

Watchers

Forkers

glfw-b's Issues

Summary

Repro

Expected behavior

Actual behavior

Details

Recommend Projects

Recommend Topics

Recommend Org