haskell-opengl / OpenGL

Haskell bindings to OpenGL
http://www.haskell.org/haskellwiki/OpenGL
BSD 3-Clause "New" or "Revised" License
147 stars 26 forks source link

unable to obtain shading language version #69

Closed elisehuard closed 10 years ago

elisehuard commented 10 years ago

following statements in ghci don't work: Main> import Graphics.Rendering.OpenGL Main Graphics.Rendering.OpenGL> get shadingLanguageVersion >>= putStrLn This ends the ghci session.

Putting this in a program doesn't change anything, it also seems to just end the program without any error messages (nor any other putStrLn added before or after).

System: Mac OS X 10.9.5 Haskell: The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 OpenGL: OpenGL-2.9.2.0

schell commented 10 years ago

Hi @elisehuard - I can confirm I'm running into this problem as well:

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.
Prelude> :m Graphics.Rendering.OpenGL
Prelude Graphics.Rendering.OpenGL> get shadingLanguageVersion >>= putStrLn
Loading package OpenGLRaw-1.5.0.0 ... linking ... done.
Loading package GLURaw-1.4.0.1 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package text-1.1.1.3 ... linking ... done.
Loading package OpenGL-2.9.2.0 ... linking ... done.
fish: Job 1, 'ghci' terminated by signal SIGSEGV (Address boundary error)

But I'll add that this seems to happen with any OpenGL operation:

Prelude Graphics.Rendering.OpenGL> x <- genObjectName :: IO BufferObject 
Loading package OpenGLRaw-1.5.0.0 ... linking ... done.
Loading package GLURaw-1.4.0.1 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package text-1.1.1.3 ... linking ... done.
Loading package OpenGL-2.9.2.0 ... linking ... done.
fish: Job 1, 'ghci' terminated by signal SIGSEGV (Address boundary error)

Possibly this is an issue with linking shared libraries in ghci or something? I'm on OS X 10.10.

elisehuard commented 10 years ago

HI @schell , I should have been clearer: when I said I 'ran it in a program' I meant I ran this command in a program with main etc, and it still didn't work ...

svenpanne commented 10 years ago

This is expected to be non-working. :-)

An OpenGL context is basically a huge state machine, bound to a thread-local variable, avoiding the need to pass the context to each and every OpenGL call. Not a great design decision in retrospect, but that's how it is. How exactly such a context is created and bound to the thread-local variable is outside the scope of OpenGL, on e.g. *nices with X11 it's normally done via GLX. Note that you could have several different context at the same time (different graphics cards from different vendors with different drivers and capabilities), but at most one could be current.

In your example, there is no context yet, so the question which shading language version is supported doesn't make sense. OTOH, this GLUT example works:

main :: IO ()
main = do
   getArgsAndInitialize
   createWindow "foo"
   get shadingLanguageVersion >>= putStrLn

createWindow binds the context to the TLS, so if you comment out that line, you should get an empty version string. The OpenGL bindings explicitly check for NULL, so the problem is probably that OS X is more picky when there is no current context (an API usage error!) and crashes within glGetString.

schell commented 10 years ago

@svenpanne oh yeah, lol, there's no opengl context! Sorry - I should have caught that - I've made that mistake many times now.

:+1:

svenpanne commented 10 years ago

@shell Making it easy to make such mistakes was exactly my point when saying that using TLS in an API is "not a great design decision". :-) In addition, this leads to complications like bound threads in the FFI etc.

elisehuard commented 10 years ago

Maybe a clear error message would be a possible nice-to-have? Thanks for the explanation anyhow!