August 2009 - HOpenGL

Re: [HOpenGL] Re: Fwd: OpenGLRaw
by Andy Gill 18 Aug '09

18 Aug '09

Hi Sven, After comparing the 'ghc-pkg describe' for GLUT 2.2.0.0 and GLUT 2.2.1.0, on my OSX 10.5, this works for me: if os(windows) && flag(UseNativeWindowsLibraries) cpp-options: "-DCALLCONV=stdcall" extra-libraries: glut32 cc-options: "-DUSE_GETPROCADDRESS" else cpp-options: "-DCALLCONV=ccall" cc-options: "-DUSE_DLSYM" if os(darwin) frameworks: GLUT else extra-libraries: glut So a) + b). Other combinations (i've just tried them) do not work. Also, USE_NSADDRESSOFSYMBOL seems deprecated (ld gives link warnings), but -USE_DLSYM works, so I've also changed this. Please let me know how this works out. Andy On Aug 16, 2009, at 10:25 AM, Sven Panne wrote: > Am Montag, 10. August 2009 20:03:53 schrieb Sven Panne: >> Am Montag, 10. August 2009 19:55:24 schrieb Sven Panne: >>> [...] >>> Is this generally the case for Mac OS X users? If yes, the >>> extra-libraries line should be excluded in the Cabal file for this >>> platform. Have others experienced the same problem? Reports would be >>> nice, regardless if things work or not... >> >> Just another idea from a different email: Perhaps "-framework >> OpenGL" is >> missing for Mac OS X? It would be nice to hear what the right fix >> is, I >> don't have access to any Macs... > > Hmmm, no replies yet... So I'd like to The OpenGLRaw.cabal obviously > needs > some tweaks on Mac OS X, but it is not clear for me what to do. Should > > a) the "extra-libraries: GL" line be removed for the "os(darwin)" > case? > > b) a "frameworks: OpenGL" line be added? > > What is the right way to fix things? a) alone? b) alone? Or both a) > and b)? > Feedback would be highly appreciated, because I don't have access to > Macs. > > Cheers, > S. > > > Andy Gill, <andygill(a)ku.edu> Assistant Professor The University of Kansas, EECS Department Information and Telecommunication Technology Center

2 1

Re: Fwd: OpenGLRaw
by Sven Panne 17 Aug '09

17 Aug '09

[Forwarded to the HOpenGL list, because it might be of general interest] Am Friday 07 August 2009 08:06:04 schrieben Sie: > Sven, > > I got this working by *removing* GL from the line > extra-libraries: GL > in the *cabal file. > > It seems to work with this change. Perhaps GL is needed for another > build method? > > Thank you for doing the hard work with OpenGL and OpenGLRaw, that lets > us experiment with our ChalkBoard accelerator. > > Andy > > Begin forwarded message: > > From: Andy Gill <andygill(a)ku.edu> > > Date: August 6, 2009 10:53:37 PM CDT > > To: Sven Panne <Sven.Panne(a)aedion.de> > > Cc: Kevin Matlage <kmatlage(a)ittc.ku.edu> > > Subject: OpenGLRaw > > > > Hi Sven, > > > > I get the following error when trying to include OpenGLRaw, as build > > out of the box. > > > > $ cat Main.hs > > import Graphics.Rendering.OpenGL.Raw > > > > main = print "Hello" > > $ ghc --make Main.hs > > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Linking Main ... > > ld: library not found for -lGL > > collect2: ld returned 1 exit status > > > > *Any* ideas? I'm stuck. I've got a OSX 10.5. Are there any gotyas I > > should know about? > > > > Andy Gill > > Andy Gill, <andygill(a)ku.edu> > Assistant Professor > The University of Kansas, EECS Department > Information and Telecommunication Technology Center Is this generally the case for Mac OS X users? If yes, the extra-libraries line should be excluded in the Cabal file for this platform. Have others experienced the same problem? Reports would be nice, regardless if things work or not... Cheers, S.

2 4

Re: [Haskell] ANNOUNCE: GLUT 2.2.1.0
by Sven Panne 17 Aug '09

17 Aug '09

Am Sonntag, 16. August 2009 22:10:23 schrieb Rafael Gustavo da Cunha Pereira Pinto: > BTW, as an enhancement for 2.2.2.0, you could treat unnamed mouse buttons. > Mouses with more axis and more buttons are becoming increasingly common, > and "unmarshalMouseButton" is not prepared to accept them!! > > Here are exceptions I caught, playing with my Genius Traveler 515 mouse: > > unmarshalMouseButton: illegal value 5 > unmarshalMouseButton: illegal value 6 > unmarshalMouseButton: illegal value 7 > unmarshalMouseButton: illegal value 8 Good point, I had similar reports already, but I simply forgot to handle this in yesterday's release. The right way to handle this would probably be extending the MouseButton data type with an 'AdditionalButton Int' constructor and simply pass the unknown button numbers via this case. I am not so sure about a nice name for this constructor: AdditionalButton? GenericButton? Or simply MouseButton, just like the type itself? Cheers, S.

1 0

ANNOUNCE: GLUT 2.2.1.0
by Sven Panne 16 Aug '09

16 Aug '09

A new version of the GLUT package has been uploaded to Hackage. * The package is now autoconf-free. API entries are resolved dynamically at runtime, just like the OpenGLRaw and GLURaw packages. * Support for sRGB framebuffers has been added, just use SRGBMode with initialDisplayMode. To use this functionality, you need the upcoming freeglut 2.6.0 library, older versions and "classic" GLUT do not support this feature. * Support for context profiles has been added via initialContextProfile. Again, this works with the upcoming freeglut 2.6.0 library only. Cheers, S.

1 0

Re: [Haskell] ANNOUNCE: OpenGL 2.3.0.0
by Sven Panne 10 Aug '09

10 Aug '09

Am Sonntag, 2. August 2009 13:50:08 schrieb Paul L: > Thanks for the reply. If the issue was caused by an "API bug", I'm > actually not sure if this "API bug" has been fixed. Compare > > http://hackage.haskell.org/packages/archive/OpenGL/2.2.3.0/doc/html/Graphic >s-Rendering-OpenGL-GL-VertexSpec.html#t%3AVertexComponent > > to > > http://hackage.haskell.org/packages/archive/OpenGL/2.3.0.0/doc/html/Graphic >s-Rendering-OpenGL-GL-VertexSpec.html#t%3AVertexComponent > > You can see that either Int16/Int32/Float/Double (in older versions) > or CShort/CInt/CFloat/CDouble (in the new version) are listed as > instances, not GLshort/GLint/GLfloat/GLdouble. > > This is less of a "real" bug, but it's certainly misleading. Maybe you > can get it fixed by using -XTypeSynonymInstances. I am well aware of the fact the documentation is not optimal at the moment, but I am not willing to sacrifice portability for this tiny issue, so the flag you mention is not an option. In former releases I used an ugly CPP hack to improve the documentation a bit, but this feels wrong IMHO. The recent change from the sized Int/Word types to the C types was a consequence of removing autoconf, the next step will be using the C types wrapped in newtypes. This is the right way to do it, and it will fix the documentation, too. If you do not make any assumptions about the actual representations (i.e. use fromIntegral and friends when needed), this further change will not affect any portable code. Cheers, S.

1 0

Windows and Hopegenl/Hglut
by Zach Kozatek 09 Aug '09

09 Aug '09

I have tried glut 3.7 and free glut I have the mingw and msys toolchain I have cabal working With ghc 6.10>= I can not get my opengl/glut programs working I have them compile and linked when they run with glut 3.7 I get a runtime error of the nature: logo.exe - Entry Point Not Found The procedure entry point glutAddmenuEntry@8 could not be located in the dynamic link library My programs work fine with ghc 6.8.3 but then i can not cabal install the latest libraries Any help would be appreciated, Zach Kozatek

1 0

Split package organization (AntTweakBar, Cabal, darcs)
by Gregory D. Weber 04 Aug '09

04 Aug '09

I'm working on a Haskell binding for AntTweakBar, a light user interface for OpenGL applications (http://www.antisphere.com/Wiki/tools:anttweakbar) I have three questions about how to organize it as a Haskell package or packages, Cabal, and darcs. First, since AntTweakBar provides support for handling events from GLUT, GLFW, and SDL, as well as customizable event handling from other sources, would it be best to divide it into four packages -- AntTweakBar (core), AntTweakBar-GLUT, AntTweakBar-GLFW, and AntTweakBar-SDL? A few other "package groups" on Hackage have taken this approach of splitting according to the user interface: for example, grapefruit-ui-gtk, reactive-glut, though not on such a large scale as I am proposing. Advantages of four packages rather than one: -- Fewer build dependencies, for example, for users who want to use just SDL and not have to install GLUT or GLFW. -- If one of the build dependencies is broken (as for example GLFW is just at the moment with the latest OpenGL), users could still build the other AntTweakBar-* packages. Disadvantages: -- More packages to install, for those who want it all. -- I might seem to be grabbing an undue share of the package namespace. And it could get way out of hand if I further split the examples from the library, making AntTweakBar-(base|GLUT|GLFW|SDL)-(lib|examples) = 8 packages! Would that be a problem? -- Possible inconvenience for the developer (see second question). Second question, assuming the four-way split is the best way to package this: my impression is that a directory can have only one cabal package file and one Setup.hs file. (http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.h…, "Creating a Package") So for example I could not have, in the same directory, AntTweakBar.cabal, AntTweakBar-GLUT.cabal, etc. That means the four packages would each have to have their own directories, and it is sometimes inconvenient to be jumping back and forth between them. Any good way around that? Third question, assuming four separate directories for the four Cabal package files. Putting all four into one darcs repo (i.e., the darcs repo would have one main directory and a subdirectory for each package) seems to make it easier to coordinate development of the related packages -- for example, a single 'darcs rec -a' takes care of recording the related changes in all four subdirectories. Any reason not to do it that way? -- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550

1 0

problems running SmoothOpenGL3
by Michael [Plouj] Ploujnikov 01 Aug '09

01 Aug '09

Hi, I wanted to give the new SmoothOpenGL3.hs example a try, but I ran into a strange problem with it. Prior to trying this example, I unregistered the old OpenGL and GLUT packages and installed new ones with cabal. Below is a list of all the Haskell packages on my system: $ ghc-pkg list /usr/lib64/ghc-6.10.3/./package.conf: Cabal-1.6.0.3, HUnit-1.2.0.3, QuickCheck-1.2.0.0, X11-1.4.5, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3), ghc-prim-0.1.0.0, haddock-2.4.2, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.3, unix-2.3.2.0, xhtml-3000.2.0.1, xmonad-0.8.1 /home/plouj/.ghc/x86_64-linux-6.10.3/package.conf: GLURaw-1.0.0.0, GLUT-2.2.0.0, ObjectName-1.0.0.0, OpenGL-2.3.0.0, OpenGLRaw-1.0.1.0, SDL-0.5.5, StateVar-1.0.0.0, Tensor-1.0.0.1, X11-xft-0.3, hinotify-0.2, utf8-string-0.3.5, xmonad-contrib-0.8.1 I copied SmoothOpenGL3.hs from the GLUT-2.2.0.0.tar.gz tarball into the current directory and here is what happened when I tried running it with runghc: $ runghc SmoothOpenGL3.hs SmoothOpenGL3.hs: /home/plouj/.cabal/lib/GLUT-2.2.0.0/ghc-6.10.3/HSGLUT-2.2.0.0.o: unknown symbol `glutGet' SmoothOpenGL3.hs: SmoothOpenGL3.hs: unable to load package `GLUT-2.2.0.0' $ ghc-pkg list|grep GLUT GLURaw-1.0.0.0, GLUT-2.2.0.0, ObjectName-1.0.0.0, OpenGL-2.3.0.0, $ nm /home/plouj/.cabal/lib/GLUT-2.2.0.0/ghc-6.10.3/HSGLUT-2.2.0.0.o|grep glutGet 0000000000007720 D GLUTzm2zi2zi0zi0_GraphicsziUIziGLUTziState_ptrzuglutGetModeValues_closure 0000000000045060 T GLUTzm2zi2zi0zi0_GraphicsziUIziGLUTziState_ptrzuglutGetModeValues_info U glutGet U glutGetColor U glutGetMenu U glutGetModifiers U glutGetProcAddress U glutGetWindow I get a similar problem in ghci: $ ghci GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :l SmoothOpenGL3.hs [1 of 1] Compiling Main ( SmoothOpenGL3.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package OpenGLRaw-1.0.1.0 ... linking ... done. Loading package GLURaw-1.0.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.3.0.0 ... linking ... done. Loading package GLUT-2.2.0.0 ... linking ... <interactive>: /home/plouj/.cabal/lib/GLUT-2.2.0.0/ghc-6.10.3/HSGLUT-2.2.0.0.o: unknown symbol `glutGet' ghc: unable to load package `GLUT-2.2.0.0' Finally, this is what I get if I try to compile with 'ghc --make': $ ghc --make -lglut SmoothOpenGL3.hs # the linker fails without -lglut similar to this: http://www.haskell.org/pipermail/hopengl/2008-September/000756.html [1 of 1] Compiling Main ( SmoothOpenGL3.hs, SmoothOpenGL3.o ) Linking SmoothOpenGL3 ... $ ./SmoothOpenGL3 SmoothOpenGL3: user error (unknown GLUT call glutInitContextVersion, check for freeglut) $ ldd ./SmoothOpenGL3 linux-vdso.so.1 => (0x00007fffd25ff000) libglut.so.3 => /usr/lib64/libglut.so.3 (0x000000323c000000) libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000003242000000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x0000003241c00000) libm.so.6 => /lib64/libm.so.6 (0x0000003239400000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x000000323bc00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003239800000) librt.so.1 => /lib64/librt.so.1 (0x000000323a400000) libc.so.6 => /lib64/libc.so.6 (0x0000003239000000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x000000323b400000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x000000323a800000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x0000003248a00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003243e00000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003241000000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x000000323ec00000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x000000323cc00000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x0000003242400000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003239c00000) /lib64/ld-linux-x86-64.so.2 (0x0000003238c00000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x000000323ac00000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x000000323b000000) I'm not sure if this problem is specific to my setup or if it's a bug in the new GLUT/OpenGL packages. I would appreciate any help either way. -- http://plouj.com/

2 2

Re: [Haskell] ANNOUNCE: OpenGL 2.3.0.0
by Sven Panne 01 Aug '09

01 Aug '09

[ Thread moved to HOpenGL mailing list ] Am Freitag, 31. Juli 2009 22:43:14 schrieb Paul L: > [...] > I've also noticed that the decision was made to use solely C types as > instances for VertexComponent, ColorComponent, etc. I'm not sure I > understand this change because: First of all I have to admit that I'm guilty of leaving out this change from the change notes, sorry for that. > 1. There was no default type for things like GL.Vertex3, and one had > to explicitly annotate the type. Removing Int, Float from the > Component classes would surely break A LOT OF existing code. Strictly speaking, it breaks only code which was wrong, anyway. The OpenGL spec itself makes e.g. only assumptions about minimum sizes of the types, but prescribes no specific mapping. Granted, GLfloat e.g. has been a type synonym for Float, but there was never a guarantee for that and I consider the usage of type synonyms for this an API bug in previous versions of my package. Fixing code which breaks is quite trivial and those fixes will make any non- portable assumptions explicit (via fromIntegral, realToFrac or castPtr), which is a good thing, and the way it should have always been. In your example above, the type annotation should be ':: GLfloat', not ':: Float', which worked only by accident. If you have a 'Vertex3 Float', use 'fmap realToFrac' to get a 'Vertex3 GLfloat'. > 2. I don't see a problem adding back Int, Float, Double, etc. as > instances of those Component classes along side of C types. What GL type should be used for Int? Answer: We don't know, and perhaps there isn't even one. Same for the other types... > On the other hand, I'm comfortable with changing types like GLint to C > types, as existing code should have used GLint instead of Int. I want to go even one step further and change the GL type synonyms into data type renamings, including their common instances (Num, Ord, etc.), of course. This is the cleanest way of handling things, and it is easily possible to write code that works with the old type synonyms of Int32 and friends, the current synonyms for CInt and friends, and the future newtypes. Just make any assumptions explicit via fromIntegral/realToFrac/castPtr/... I'm sorry for any code breakage, but I feel that this is the right way to go, and I hope that other people will agree. Anyway, I'm open for discussions... Cheers, S.

1 0