February 2002 - HOpenGL

RE: [HOpenGL] HOpenGL and the new library hierarchy
by Simon Marlow 25 Feb '02

25 Feb '02

> Sorry for the long period of silence, but I'm currently > slowly recovering > from a head crash (my hard disk's head, to be exact, not *mine* :-). > > I'm going to re-implement HOpenGL based on the .spec files > and the new FFI, > moving to the new library hierarchy on the way. Great! > So I'm seeking advice where > to put it exactly. My suggestion: > > The GL/GLU modules reside into the subtrees > > Graphics.Drawing.OpenGL.GL > Graphics.Drawing.OpenGL.GLU > > with 2 modules of the same names, re-exporting the modules from the > subtrees. A module Graphics.Drawing.OpenGL re-exports those > two modules > again. This looks fine. > The GLUT modules reside in Graphics.UI.GLUT, with a module of the same > name, re-exporting the modules below it plus Graphics.Drawing.OpenGL > (Graphics.UI.OpenGL.GLUT looks a little bit like overkill, IMHO). > > I'm a little bit unhappy with "Drawing", "Rendering" would be more > appropriate, but I could live with that... I have no objection to a Drawing==>Rendering change; if you suggest this on libraries(a)haskell.org and no-one complains, then go ahead - we don't have any other occupants of the Graphics.Drawing namespace as yet. Cheers, Simon

1 0

HOpenGL and the new library hierarchy
by Sven Panne 24 Feb '02

24 Feb '02

Sorry for the long period of silence, but I'm currently slowly recovering from a head crash (my hard disk's head, to be exact, not *mine* :-). I'm going to re-implement HOpenGL based on the .spec files and the new FFI, moving to the new library hierarchy on the way. So I'm seeking advice where to put it exactly. My suggestion: The GL/GLU modules reside into the subtrees Graphics.Drawing.OpenGL.GL Graphics.Drawing.OpenGL.GLU with 2 modules of the same names, re-exporting the modules from the subtrees. A module Graphics.Drawing.OpenGL re-exports those two modules again. The GLUT modules reside in Graphics.UI.GLUT, with a module of the same name, re-exporting the modules below it plus Graphics.Drawing.OpenGL (Graphics.UI.OpenGL.GLUT looks a little bit like overkill, IMHO). I'm a little bit unhappy with "Drawing", "Rendering" would be more appropriate, but I could live with that... Comments/suggestions? Cheers, S.

2 2

forcing IO operations
by Andre W B Furtado 20 Feb '02

20 Feb '02

Curious problem... Suppose MyMonad is a Monad other than the IO Monad. Consider the following piece of code: > f :: MyMonad () > f = action1 Now suppose also that ioToMyMonad converts an IO Monad to a MyMonad Monad: > ioToMyMonad :: IO a -> MyMonad a > ioToMyMonad = return . unsafePerformIO Suppose also that action1 needs to perform some IO operation (called IO_op), which returns IO (). In other words, action1 would be: > action1 :: MyMonad () > action1 = do > -- MyMonad operations > ioToMyMonad $ IO_op > -- other MyMonad operations When I run f (via runMyMonad or something like that), I noticed that the io operation (IO_op) is not executed. I guess that this happens because of laziness properties, since the value returned by IO_op is useless to MyMonad. I have then two questions: 1. Does this really happen because of laziness properties? 2. Which is the best way to force IO_op to be performed? I tried the following approach: Step1: Change the type of IO_op from "IO ()" to "IO Bool" and make it returns True. Step2: Change action1 to > action1 :: MyMonad Bool > action1 = do > -- MyMonad operations > b <- ioToMyMonad $ IO_op > -- other MyMonad operations > return b Step3: Change the type of f to MyMonad Bool Step4: Finally, use this boolean somewhere after calling "runMyMonad", e. g., printing it on the screen. I'm sure this is not the best approach, so I'd really appreciate any suggestions. [I'm sending this mail to the HOpenGL list also because runMyMonad is being called inside the display callback, so perhaps it may have something to do with the problem] Thanks a lot, -- Andre

1 0

RE: [HOpenGL] news on FFI?
by Simon Marlow 05 Feb '02

05 Feb '02

> > I would like to know if that will help to solve that > "uncaught exception > > problem" when leaving HOpenGL programs. > > A strictly conforming implementation shouldn't have that problem, see: > > http://haskell.org/pipermail/ffi/2002-January/000436.html > > I know that Simon "RTS" Marlow :-) is on this list, what... who.. me? :-} > so perhaps he could answer > the question when GHC is changed this way... Ok, the problem as we all know is that System.exitWith now raises an exception rather than simply terminating the program. This is highly desirable behaviour especially in a concurrent system, and was essential in GHCi so that if the interpreted program calls System.exitWith we don't terminate GHCi itself. The problem is that this exception isn't propagated to the main thread automatically if it is raised in a child thread. Foreign-exported functions are run in child threads. Furthermore, it's not clear exactly how the exception should be propagated, because there isn't always a single main thread to send it to. Two workarounds spring to mind: firstly, you could wrap callbacks in a suitable exception handler. So instead of calling 'mkCallback e' where mkCallback is a foreign export dynamic, you would call 'mkCallback (Exception.catch e handler)' where handler is something like topHandler in fptools/ghc/lib/std/PrelTopHandler.lhs, but you probably want to discard all exceptions except ExitException. Perhaps GHC should do this wrapping automatically, I'm not sure. Alternatively you could call your own version of exitWith which does a real exit. Again, see PrelTopHandler.lhs for the function shutdownHaskellAndExit, which is our equivalent of hs_exit() (when we get around to catching up with the FFI spec, hs_exit() will probably be a synonym for shutdownHaskellAndExit()). Cheers, Simon

2 1

mainloop & return
by Andre W B Furtado 03 Feb '02

03 Feb '02

Is there any problem if the same function that calls "mainloop" returns a value? Ex.: main :: IO () main = do msg <- startGL putStrLn msg startGL :: IO String startGL = do -- init GLUT -- create window -- declare callback procedures mainloop return "ok"

2 2