From claus.reinke at talk21.com Sat Jul 14 18:53:47 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Jul 14 18:47:08 2007 Subject: [HOpenGL] Re: [Haskell-cafe] Looking for final year project - using Haskell, or another functional language References: <837db430707101345x2a9a6857xb706cbb639b7bbf5@mail.gmail.com><032d01c7c4db$989c71e0$9c297ad5@cr3lt><837db430707132318ned8c7c0veb2b7dde834229c2@mail.gmail.com> <20070714062900.GA6908@localhost.localdomain> Message-ID: <052c01c7c669$d80e4cb0$a3428351@cr3lt> >I've already sent an email to the haskell.org admin requesting that >/HOpenGL be made publically unviewable. > >Stefan in the interim, there's now a bare-bones wiki page: http://www.haskell.org/haskellwiki/Opengl quite dreary, but at least visitors will no longer thing that the binding should be "upgraded" to OpenGL 1.3, or wonder where the sources are, or whether there are any examples that build with those sources.. while Sven keeps improving the implementation, perhaps others can help out improving that entry page. some fancy success stories, up-to-date tutorials, applications, libraries (a binding for text perhaps?-). claus From hiben at informatik.uni-bremen.de Fri Jul 20 02:44:54 2007 From: hiben at informatik.uni-bremen.de (Hendrik Iben) Date: Fri Jul 20 02:38:02 2007 Subject: [HOpenGL] Segfaults on MouseWheel Message-ID: <46A059E6.3010005@informatik.uni-bremen.de> Hi, I've been experimenting some time with the OpenGL and GLUT bindings and there is one thing I do not understand. While I've read trough the archive and understand that the GLUT binding cannot handle more than the standard Mouse-buttons I thought handling the MouseWheel-buttons should work. However, regardless of whether I actually want to know about Mouse-Buttons my applications segfault when I trigger the WheelUp-Button. WheelDown works as expected (They are reported as button 4 and 5 in X). I don't know where that behaviour comes from - other buttons at least give an error message about the missing marshalling. I guess something is wrong with my setup as I could not find any similar error report (AMD64, linux kernel 2.6.19 (64bit), X.org 7.2, GHC 6.6.1, GLUT 2.1.1, OpenGL-2.2.1). Any suggestions how to further investigate this ? I'm willing to add hooks to the GLUT (?) package if someone can point me to the right direction... This is the output from doing a backtrace on the dumped core - not very informative... : #0 0x0000000000000000 in ?? () #1 0x00002b6f40ccd172 in __glutRegisterEventParser () from /usr/lib/libglut.so.3 #2 0x00002b6f40ccdeb2 in glutMainLoop () from /usr/lib/libglut.so.3 #3 0x0000000000411c08 in GLUTzm2zi1zi1_GraphicsziUIziGLUTziBegin_mainLoop_info () #4 0x000000000057b498 in stg_ap_0_fast () #5 0x0000000000529b98 in s5YF_info () #6 0x00002aaaaac8eaf8 in ?? () #7 0x00000000007c89d0 in ?? () #8 0x0000000000000000 in ?? () Best regards, Hendrik From hughperkins at gmail.com Sat Jul 21 07:16:03 2007 From: hughperkins at gmail.com (Hugh Perkins) Date: Sat Jul 21 07:08:59 2007 Subject: [HOpenGL] "can't load .so/.dll for: glut32 (addDll: unknown error)" Message-ID: <837db430707210416x2aa1428fi1d701e756d8e8e19@mail.gmail.com> Hi, Kindof a dumb question I know, what do I need to do to avoid getting the following message when I try loading GLUT? J:\dev\haskell>ghci -fglasgow-exts Teapots.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> main Loading package OpenGL-2.2.1 ... linking ... done. Loading package GLUT-2.1.1 ... can't load .so/.DLL for: glut32 (addDLL: unknown error) As you can see, running ghc 6.6.1, on Windows. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hopengl/attachments/20070721/d9aedf48/attachment.htm From hiben at informatik.uni-bremen.de Sat Jul 21 08:42:10 2007 From: hiben at informatik.uni-bremen.de (Hendrik Iben) Date: Sat Jul 21 08:35:13 2007 Subject: [HOpenGL] Segfaults on MouseWheel In-Reply-To: <46A059E6.3010005@informatik.uni-bremen.de> References: <46A059E6.3010005@informatik.uni-bremen.de> Message-ID: <46A1FF22.2090406@informatik.uni-bremen.de> Hendrik Iben schrieb: > Hi, > > I've been experimenting some time with the OpenGL and GLUT bindings and > there is one thing I do not understand. > While I've read trough the archive and understand that the GLUT binding > cannot handle more than the standard Mouse-buttons I thought handling > the MouseWheel-buttons should work. > However, regardless of whether I actually want to know about > Mouse-Buttons my applications segfault when I trigger the > WheelUp-Button. WheelDown works as expected (They are reported as button > 4 and 5 in X). > I don't know where that behaviour comes from - other buttons at least > give an error message about the missing marshalling. > > I guess something is wrong with my setup as I could not find any similar > error report (AMD64, linux kernel 2.6.19 (64bit), X.org 7.2, GHC 6.6.1, > GLUT 2.1.1, OpenGL-2.2.1). > > Any suggestions how to further investigate this ? I'm willing to add > hooks to the GLUT (?) package if someone can point me to the right > direction... > > This is the output from doing a backtrace on the dumped core - not very > informative... : > #0 0x0000000000000000 in ?? () > #1 0x00002b6f40ccd172 in __glutRegisterEventParser () > from /usr/lib/libglut.so.3 > #2 0x00002b6f40ccdeb2 in glutMainLoop () from /usr/lib/libglut.so.3 > #3 0x0000000000411c08 in > GLUTzm2zi1zi1_GraphicsziUIziGLUTziBegin_mainLoop_info > () > #4 0x000000000057b498 in stg_ap_0_fast () > #5 0x0000000000529b98 in s5YF_info () > #6 0x00002aaaaac8eaf8 in ?? () > #7 0x00000000007c89d0 in ?? () > #8 0x0000000000000000 in ?? () > > Best regards, > Hendrik > _______________________________________________ > HOpenGL mailing list > HOpenGL@haskell.org > http://www.haskell.org/mailman/listinfo/hopengl I'm sorry for not trying this before posting to this list. I just realized that the segfaults also happen with pure C-code (using GLUT). SDL bindings for Haskell still work correct with the wheel - wierd. Best regards, Hendrik From hiben at informatik.uni-bremen.de Sat Jul 21 09:03:00 2007 From: hiben at informatik.uni-bremen.de (Hendrik Iben) Date: Sat Jul 21 08:56:03 2007 Subject: [HOpenGL] Segfaults on MouseWheel In-Reply-To: <46A1FF22.2090406@informatik.uni-bremen.de> References: <46A059E6.3010005@informatik.uni-bremen.de> <46A1FF22.2090406@informatik.uni-bremen.de> Message-ID: <46A20404.2090701@informatik.uni-bremen.de> Hendrik Iben schrieb: > Hendrik Iben schrieb: > >>Hi, >> >>I've been experimenting some time with the OpenGL and GLUT bindings and >>there is one thing I do not understand. >>While I've read trough the archive and understand that the GLUT binding >>cannot handle more than the standard Mouse-buttons I thought handling >>the MouseWheel-buttons should work. >>However, regardless of whether I actually want to know about >>Mouse-Buttons my applications segfault when I trigger the >>WheelUp-Button. WheelDown works as expected (They are reported as button >>4 and 5 in X). >>I don't know where that behaviour comes from - other buttons at least >>give an error message about the missing marshalling. >> >>I guess something is wrong with my setup as I could not find any similar >>error report (AMD64, linux kernel 2.6.19 (64bit), X.org 7.2, GHC 6.6.1, >>GLUT 2.1.1, OpenGL-2.2.1). >> >>Any suggestions how to further investigate this ? I'm willing to add >>hooks to the GLUT (?) package if someone can point me to the right >>direction... >> >>This is the output from doing a backtrace on the dumped core - not very >>informative... : >>#0 0x0000000000000000 in ?? () >>#1 0x00002b6f40ccd172 in __glutRegisterEventParser () >> from /usr/lib/libglut.so.3 >>#2 0x00002b6f40ccdeb2 in glutMainLoop () from /usr/lib/libglut.so.3 >>#3 0x0000000000411c08 in >>GLUTzm2zi1zi1_GraphicsziUIziGLUTziBegin_mainLoop_info >> () >>#4 0x000000000057b498 in stg_ap_0_fast () >>#5 0x0000000000529b98 in s5YF_info () >>#6 0x00002aaaaac8eaf8 in ?? () >>#7 0x00000000007c89d0 in ?? () >>#8 0x0000000000000000 in ?? () >> >>Best regards, >>Hendrik >>_______________________________________________ >>HOpenGL mailing list >>HOpenGL@haskell.org >>http://www.haskell.org/mailman/listinfo/hopengl > > > I'm sorry for not trying this before posting to this list. I just > realized that the segfaults also happen with pure C-code (using GLUT). > SDL bindings for Haskell still work correct with the wheel - wierd. > > Best regards, > Hendrik Just to finish this: I could solve the problem by switching from GLUT to freeglut. Best regards, Hendrik From hughperkins at gmail.com Sat Jul 21 10:49:17 2007 From: hughperkins at gmail.com (Hugh Perkins) Date: Sat Jul 21 10:42:16 2007 Subject: [HOpenGL] Compiling hopengl apps? Message-ID: <837db430707210749h7b15a51bub82c9c68f18f41ff@mail.gmail.com> Started to play with hopengl. It's pretty cool :-) Very easy to use, quite cool :-) Started to look at perf. What interests me most is to see how fast we can make vertex3f calls. Basically, we're testing the speed of the haskell/c boundary, where security(?) and marshalling are going to occur. Yes, we can send the vertices to a vertexarray and not have to handle vertex3f calls, but that's not what I want to measure ;-) So, have a really rough and ready application that draws 45000 triangles a frame, then measures the framerate. Thats about 150,000 calls to vertex3f per frame. The application runs in Java, C#, and now Haskell. Running in ghci, this runs at about 1.5 fps, really ballpark, havent checked I'm really drawing the number of triangles I think I'm drawing, or settings such as backface-culling or shademodel. That's not too bad. I'd like to compile to an executable to increase the framerate, but it's giving me the following output: J:\dev\haskell>ghc -fglasgow-exts -O2 -o OglPerf.exe OglPerf.hs OglPerf.o(.text+0x1f4):ghc3668_0.hc: undefined reference to `glutPostRedisplay@0 ' OglPerf.o(.text+0x255):ghc3668_0.hc: undefined reference to `glVertex3f@12' OglPerf.o(.text+0x1148):ghc3668_0.hc: undefined reference to `glViewport@16' OglPerf.o(.text+0x1157):ghc3668_0.hc: undefined reference to `glMatrixMode@4' OglPerf.o(.text+0x115f):ghc3668_0.hc: undefined reference to `glLoadIdentity@0' OglPerf.o(.text+0x11cc):ghc3668_0.hc: undefined reference to `glFrustum@48' OglPerf.o(.text+0x11db):ghc3668_0.hc: undefined reference to `glMatrixMode@4' OglPerf.o(.text+0x11e3):ghc3668_0.hc: undefined reference to `glLoadIdentity@0' OglPerf.o(.text+0x11fd):ghc3668_0.hc: undefined reference to `glTranslatef@12' OglPerf.o(.text+0x1672):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1764):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1856):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1948):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' OglPerf.o(.text+0x1b56):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziPrimitiveMode_Quads_closure' OglPerf.o(.text+0x1de9):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziFramebuffer_marshalClearBuffer_closure' OglPerf.o(.text+0x1e00):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziFramebuffer_sum_closure' OglPerf.o(.text+0x1e42):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziFramebuffer_sum_closure' [...] aphicsziRenderingziOpenGLziGLziStringQueries_Vendor_closure' OglPerf.o(.text+0x340f):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziStringQueries_Renderer_closure' OglPerf.o(.text+0x3634):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' OglPerf.o(.text+0x3668):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziCoordTrans_normalizze_closure' OglPerf.o(.text+0x36c1):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' OglPerf.o(.text+0x3716):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' OglPerf.o(.text+0x374a):ghc3668_0.hc: undefined reference to `OpenGLzm2zi2zi1_Gr aphicsziRenderingziOpenGLziGLziColors_lighting_closure' [...] collect2: ld returned 1 exit status What am I missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hopengl/attachments/20070721/ca267ee0/attachment.htm From hiben at informatik.uni-bremen.de Sat Jul 21 12:05:12 2007 From: hiben at informatik.uni-bremen.de (Hendrik Iben) Date: Sat Jul 21 11:58:18 2007 Subject: [HOpenGL] Compiling hopengl apps? In-Reply-To: <837db430707210749h7b15a51bub82c9c68f18f41ff@mail.gmail.com> References: <837db430707210749h7b15a51bub82c9c68f18f41ff@mail.gmail.com> Message-ID: <46A22EB8.4000903@informatik.uni-bremen.de> Hugh Perkins schrieb: > Started to play with hopengl. It's pretty cool :-) Very easy to use, quite > cool :-) > > Started to look at perf. What interests me most is to see how fast we can > make vertex3f calls. Basically, we're testing the speed of the haskell/c > boundary, where security(?) and marshalling are going to occur. > > Yes, we can send the vertices to a vertexarray and not have to handle > vertex3f calls, but that's not what I want to measure ;-) > > So, have a really rough and ready application that draws 45000 triangles a > frame, then measures the framerate. Thats about 150,000 calls to vertex3f > per frame. > > The application runs in Java, C#, and now Haskell. > > Running in ghci, this runs at about 1.5 fps, really ballpark, havent > checked > I'm really drawing the number of triangles I think I'm drawing, or settings > such as backface-culling or shademodel. That's not too bad. > > I'd like to compile to an executable to increase the framerate, but it's > giving me the following output: > > J:\dev\haskell>ghc -fglasgow-exts -O2 -o OglPerf.exe OglPerf.hs > OglPerf.o(.text+0x1f4):ghc3668_0.hc: undefined reference to > `glutPostRedisplay@0 > ' > OglPerf.o(.text+0x255):ghc3668_0.hc: undefined reference to `glVertex3f@12' > OglPerf.o(.text+0x1148):ghc3668_0.hc: undefined reference to > `glViewport@16' > OglPerf.o(.text+0x1157):ghc3668_0.hc: undefined reference to > `glMatrixMode@4' > OglPerf.o(.text+0x115f):ghc3668_0.hc: undefined reference to > `glLoadIdentity@0' > OglPerf.o(.text+0x11cc):ghc3668_0.hc: undefined reference to `glFrustum@48' > OglPerf.o(.text+0x11db):ghc3668_0.hc: undefined reference to > `glMatrixMode@4' > OglPerf.o(.text+0x11e3):ghc3668_0.hc: undefined reference to > `glLoadIdentity@0' > OglPerf.o(.text+0x11fd):ghc3668_0.hc: undefined reference to > `glTranslatef@12' > OglPerf.o(.text+0x1672):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' > OglPerf.o(.text+0x1764):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' > OglPerf.o(.text+0x1856):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' > OglPerf.o(.text+0x1948):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziVertexSpec_Vertex3_con_info' > OglPerf.o(.text+0x1b56):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziPrimitiveMode_Quads_closure' > OglPerf.o(.text+0x1de9):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziFramebuffer_marshalClearBuffer_closure' > OglPerf.o(.text+0x1e00):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziFramebuffer_sum_closure' > OglPerf.o(.text+0x1e42):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziFramebuffer_sum_closure' > [...] > aphicsziRenderingziOpenGLziGLziStringQueries_Vendor_closure' > OglPerf.o(.text+0x340f):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziStringQueries_Renderer_closure' > OglPerf.o(.text+0x3634):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' > OglPerf.o(.text+0x3668):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziCoordTrans_normalizze_closure' > OglPerf.o(.text+0x36c1):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' > OglPerf.o(.text+0x3716):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziBasicTypes_Enabled_closure' > OglPerf.o(.text+0x374a):ghc3668_0.hc: undefined reference to > `OpenGLzm2zi2zi1_Gr > aphicsziRenderingziOpenGLziGLziColors_lighting_closure' > [...] > collect2: ld returned 1 exit status > > What am I missing? I could image two different origins of that problem. The first one would be, that GHC tries to use the object files that were generated during a previous GHCi-session and fails at the linking step. In that case you should remove all gerated .hi and the windows-world equivalent to object files and try again. The second thing that comes to my mind is that you are not using the '--make' switch and that GHC fails to recognize and link the missing libraries. Maybe this could also be solved by adding '-package OpenGL -package GLUT' to the compile command. Personally I tend to use Cabal even for small projects so it takes care of all these technical details :-) I hope this is of some help to you. Best regards, Hendrik From hughperkins at gmail.com Sat Jul 21 15:39:53 2007 From: hughperkins at gmail.com (Hugh Perkins) Date: Sat Jul 21 15:32:49 2007 Subject: [HOpenGL] Compiling hopengl apps? In-Reply-To: <46A22EB8.4000903@informatik.uni-bremen.de> References: <837db430707210749h7b15a51bub82c9c68f18f41ff@mail.gmail.com> <46A22EB8.4000903@informatik.uni-bremen.de> Message-ID: <837db430707211239j27a6eb94jb1f496e7becae7e@mail.gmail.com> Cool that works, and, what is more, that gives a decent framerate. I quite like the way the opengl works in Haskell, it's pretty easy to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hopengl/attachments/20070721/720ac209/attachment.htm From hughperkins at gmail.com Sat Jul 21 17:52:34 2007 From: hughperkins at gmail.com (Hugh Perkins) Date: Sat Jul 21 17:45:29 2007 Subject: [HOpenGL] Set polygon mode? Message-ID: <837db430707211452v6055629dxe1bed9cd5b75ed75@mail.gmail.com> Hi, question, how do I do "Gl.glPolygonMode(Gl.GL_BACK, Gl.GL_LINE);" in HOpenGl? Maybe something like "polygonMode $= (Line,Line)" ? (By the way, what does "$=" do?) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/hopengl/attachments/20070721/89fdbc02/attachment.htm From sebastian.sylvan at gmail.com Sat Jul 21 19:59:46 2007 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat Jul 21 19:52:41 2007 Subject: [HOpenGL] Set polygon mode? In-Reply-To: <837db430707211452v6055629dxe1bed9cd5b75ed75@mail.gmail.com> References: <837db430707211452v6055629dxe1bed9cd5b75ed75@mail.gmail.com> Message-ID: <3d96ac180707211659i696ee844k99216ec159bc8e2f@mail.gmail.com> On 21/07/07, Hugh Perkins wrote: > Hi, question, how do I do "Gl.glPolygonMode(Gl.GL_BACK, Gl.GL_LINE);" in > HOpenGl? > > Maybe something like "polygonMode $= (Line,Line)" ? > > (By the way, what does "$=" do?) > >From the docs ( http://www.haskell.org/ghc/docs/latest/html/libraries/index.html ): polygonMode :: StateVar (PolygonMode, PolygonMode) So apparently it's a value of type "StateVar ...". Right, so look up StateVar and we see that it's a data type wich is an instance of HasGetter and HasSetter. So it appears that it models some sort of mutable state variable. In this case we want to set the variable, so HasSetter seems like the right place to look: class HasSetter s where ($=) :: s a -> a -> IO () There's no textual description in the doc, but from the type and name of the class it looks like this takes a statevar, a value, and sets the state variable to the value. So indeed the following should do what you want: polygonMode $= (Line,Line) And now you should also know what that operator does. It's just a convenient way of setting OpenGL state variables (and you can also find e.g. ($~) which modifies a state variable by the function you pass it). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 From scs4cajf at comp.leeds.ac.uk Mon Jul 23 06:36:45 2007 From: scs4cajf at comp.leeds.ac.uk (C Flynn) Date: Mon Jul 23 06:29:37 2007 Subject: [HOpenGL] Set polygon mode? In-Reply-To: <3d96ac180707211659i696ee844k99216ec159bc8e2f@mail.gmail.com> References: <837db430707211452v6055629dxe1bed9cd5b75ed75@mail.gmail.com> <3d96ac180707211659i696ee844k99216ec159bc8e2f@mail.gmail.com> Message-ID: On Sun, 22 Jul 2007, Sebastian Sylvan wrote: > On 21/07/07, Hugh Perkins wrote: >> Hi, question, how do I do "Gl.glPolygonMode(Gl.GL_BACK, Gl.GL_LINE);" in >> HOpenGl? >> >> Maybe something like "polygonMode $= (Line,Line)" ? >> >> (By the way, what does "$=" do?) >> > >> From the docs ( > http://www.haskell.org/ghc/docs/latest/html/libraries/index.html ): > > polygonMode :: StateVar (PolygonMode, PolygonMode) > > So apparently it's a value of type "StateVar ...". Right, so look up > StateVar and we see that it's a data type wich is an instance of > HasGetter and HasSetter. So it appears that it models some sort of > mutable state variable. In this case we want to set the variable, so > HasSetter seems like the right place to look: > > class HasSetter s where > ($=) :: s a -> a -> IO () > > There's no textual description in the doc, but from the type and name > of the class it looks like this takes a statevar, a value, and sets > the state variable to the value. So indeed the following should do > what you want: > > polygonMode $= (Line,Line) > > And now you should also know what that operator does. It's just a > convenient way of setting OpenGL state variables (and you can also > find e.g. ($~) which modifies a state variable by the function you > pass it). > I quite like the $= operator. Makes it clear you're playing around with an underlying state variable. In the C binding it's often not clear you're doing this which can lead to unexpected behaviours. Charles, From scs4cajf at comp.leeds.ac.uk Mon Jul 23 06:39:59 2007 From: scs4cajf at comp.leeds.ac.uk (C Flynn) Date: Mon Jul 23 06:36:58 2007 Subject: [HOpenGL] "can't load .so/.dll for: glut32 (addDll: unknown error)" In-Reply-To: <837db430707210416x2aa1428fi1d701e756d8e8e19@mail.gmail.com> References: <837db430707210416x2aa1428fi1d701e756d8e8e19@mail.gmail.com> Message-ID: On Sat, 21 Jul 2007, Hugh Perkins wrote: > Hi, > > Kindof a dumb question I know, what do I need to do to avoid getting the > following message when I try loading GLUT? > > J:\dev\haskell>ghci -fglasgow-exts Teapots.hs > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package base ... linking ... done. > Ok, modules loaded: Main. > Prelude Main> main > Loading package OpenGL-2.2.1 ... linking ... done. > Loading package GLUT-2.1.1 ... can't load .so/.DLL for: glut32 (addDLL: > unknown > error) > > As you can see, running ghc 6.6.1, on Windows. > Have you got the glut32.dll on your PC? As far as I can remember it does not come with windows. Charles From dukedave at gmail.com Tue Jul 31 19:36:17 2007 From: dukedave at gmail.com (Dave Tapley) Date: Tue Jul 31 19:28:39 2007 Subject: [HOpenGL] Bug (typo) in Graphics.UI.GLUT.Begin Message-ID: Hi all, Sorry if this is known; I searched the achieves but nothing came up. I just noticed that one of the constructors for the data type ActionOnWindowClose, namely ContinueExectuion contains an incorrect spelling of execution as 'exectuion'. As shown here: http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Begin.html#v%3AactionOnWindowClose My ghc-pkg reports version: GLUT-2.0 Dave,