Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unable to obtain shading language version #69

Closed
elisehuard opened this issue Nov 4, 2014 · 6 comments
Closed

unable to obtain shading language version #69

elisehuard opened this issue Nov 4, 2014 · 6 comments

Comments

@elisehuard
Copy link

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
Copy link

schell commented Nov 4, 2014

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
Copy link
Author

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
Copy link
Member

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
Copy link

schell commented Nov 5, 2014

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

👍

@svenpanne
Copy link
Member

@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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants