- HOpenGL - Haskell.org

Profiling & HOpenGL
by Andre W B Furtado 18 Nov '01

18 Nov '01

My HOpenGL programs seems not to work well with GHC profiling. If I compile any program with the -prof option, when I run the program I get an "illegal operation" message and the program aborts. For example, this happens with the following simple program (it does not have any _scc_ at all): import GL import GLUT main :: IO () main = do GLUT.init Nothing createWindow "AWBF Bitmap Display" (return ()) [ GLUT.Double, GLUT.Rgb ] (Just (WindowPosition 100 100)) (Just (WindowSize 250 250)) mainLoop I'm running HOpenGL-1.01 (NEW pack) and GHC-5.02 under Windows98. Can you all (HOpenGL users) check if you also have this problem? -- Andre

3 5

ANNOUNCE: HOpenGL 1.01 released
by Sven Panne 17 Nov '01

17 Nov '01

HOpenGL, a Haskell binding for OpenGL and GLUT version 1.01 I am pleased to announce the twelfth release of the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the* industrial strength 3D graphics API and a GUI toolkit. More details about HOpenGL can be found at http://www.informatik.uni-muenchen.de/~Sven.Panne/haskell_libs/HOpenGL.html This is a compatibility release for >= GHC-5.02. With a little work, HOpenGL can probably tweaked to work with a recent Hugs and NHC98, feedback about this and/or patches are highly welcome. Have fun! Sven

1 0

Strange fatal error
by Andre W B Furtado 13 Nov '01

13 Nov '01

Can anyone explain me the following error? fatal error: scavenge: unimplemented/strange closure type 0 @ 08C03FD0 (this happened with a program that reads and do some manipulations in a 3MB bitmap file, using HOpenGL-1.01 and GHC-5.02 under Windows 98 + Cygwin) Thanks, -- Andre

1 0

NEW-HOpenGL-1.01 feedback
by Andre W B Furtado 06 Nov '01

06 Nov '01

Ok, here you have my feedback on the NEW-HOpenGL-1.01 pack (I think it would be called HOpenGL-1.02 to avoid misunderstanding... :) (1) The problem between glut.dll and glut32.dll was resolved. Now the "configure step" finds "-lglut32" rather than "-lglut", and when I run the Red Book examples (and my own examples also) I don't get bored by *foo.dll not found* anymore. [I would like to say that, when I modified aclocal.m4 to make this happens before (OLD-HOpenGL-1.01), I DID NOT run "autoconf". I just deleted config.cache and started the compiling process all over again... sorry for this, I think it would have worked if I've done the right thing.] (2) [not very important] Warning messages still appear during the "make step". (3) I still get the following exception when leaving (pressing ESC in the) the RedBook_HS examples: fatal error: GLUT_CBWindow_d7T5: uncaught exception (4) Now this really intrigued me: why (GHC-4.08-1 + HOpenGL-1.00) programs are significantly smaller than (GHC-5.02 + HOpenGL-1.01)? The file attached in this email (tst.hs), once compiled, has 120Kb with the previous versions of GHC+HOpenGL, but 492Kb (!) with the present versions. This is true also for the RedBook_HS examples. And, to make things worse, the new programs are also SLOWER than the old ones. I thought that migrating to GHC-5.02 would make things faster... (specially for my bitmap loader!) -- Andre

2 1

gc 2.03 release candidate
by Sigbjorn Finne 06 Nov '01

06 Nov '01

http://www.galois.com/~sof/gc-2.03.tar.gz contains a candidate source bundle of what I intend to put out as GreenCard 2.03. Problems/bugs? Let me now. --sigbjorn

2 1

Re: FFI Addendum, CVS Id 1.19
by Sven Panne 05 Nov '01

05 Nov '01

[ This mail answers Andre's last question in the HOpenGL mailing list, so I'll cross-post... ] The addendum looks fine for me, well done Manuel! But as usual, I've got a few minor points: * Section 3.4 (export declarations) says: "If an evaluation triggered by an external invocation of an exported Haskell value returns with an exception, the system behaviour is undefined." So far, so good... It continues: "Thus, Haskell exceptions have to be caught within Haskell and explicitly marshalled to the foreign code." I understand the idea here, but what about System.exitWith and System.exitFailure in callbacks? GHC implements this via throwing an exception, but this is an implementation detail IMHO. The consequence of this implementation choice is a fatal error (uncaught exception) when exit{With,Failure} is evaluated in callbacks. So there are two questions: * Should we allow exit{With,Failure} in such circumstances? (My opinion: yes) * If the answer is no, what is the "official" way to terminate cleanly from callbacks? Note that in the context of HOpenGL the callback can't return a value due to the nature of an external lib (GLUT). I fear that the answer could be hs_exit(), but that would lead to a backwards compatibility hell... * The example in section 5.4.2 should use "wrapper" instead of the old f.e.d. * I'm still not happy with the choice of Int in the signature of plusPtr/minusPtr, but I'll probably surrender... :-] Cheers, S.

2 1

Weird solution... but it worked! (was: HOpenGL-1.01 feedback)
by Andre W B Furtado 02 Nov '01

02 Nov '01

The good news: copying /usr/include/GL to PATH_TO_5.02\include\mingw\GL makes HOpenGL find <GL/glut.h> correctly (I don't have to use the absolute path anymore). The bad news: modifying aclocal.m4 (and trying a lot of other things) in order to make HOpenGL recognize the library "lglut32" instead of "lglut" was not successful. The examples still call for glut.dll when executed in Windows Explorer and for opengl.dll when executed in the cygwin shell. The really good news: I tried to make things work by copying glut32.dll to the examples directory, and renaming it to glut.dll and (surprise!) everything worked well. This is not the best way to make the examples run, I'm sure, but at least it worked. (I think Edson should try the same thing...) There's still a doubt: how to make the "configure" step recognize glut32 instead of glut? In other words, how do I "unistall" the older glut version? -- Andre

2 1

some problems
by Edson 02 Nov '01

02 Nov '01

hi all, can someone help me to solve it. thanks a lot, edson. make depend make[1]: Entering directory `/HOpenGL-1.00/examples/othello-project' ghc -c -i/HOpenGL-1.01/lib -I/HOpenGL-1.01/lib -L/HOpenGL-1.01/lib -fglasgow-ex ts -recomp -Wall -O -syslib concurrent -package lang -L/HOpenGL-1.01/lib -lHOpenGL -lglut32 -lglu32 -lopengl32 "-#include <GL/glut.h>" HGraphicsTypes.hs HGraphicsTypes.hs:3: failed to load interface for `GL': Could not find interface file for `GL' HGraphicsTypes.hs:5: failed to load interface for `GLUT': Could not find interface file for `GLUT' make[1]: *** [depend] Error 1 make[1]: Leaving directory `/HOpenGL-1.00/examples/othello-project' make: *** [all] Error 2

2 1

more feedback (HOpenGL-1.01)
by Andre W B Furtado 01 Nov '01

01 Nov '01

When running some examples that use the ESC (\27) key to quit the program, I'm getting a uncaught exception. For example: light: fatal error: GLUT_CBWindow_d7lF: uncaught exception This is happening only with the examples of redbook_HS. The examples in redbook_C are alright (no exceptions occurs when pressing ESC). -- Andre

1 0

Re: thank you for the package...but still won't compile
by Sven Panne 31 Oct '01

31 Oct '01

[ I've re-routed this into the main list, because other people could have the same problem. ] Denver wrote: > 'make depend' was successful...but 'make all' wasn't unfortunately. > i received these errors: > /tmp/ghc1407.hc: In function `GLzuErrors_zdwunmarshallzuError_fast1': > > /tmp/ghc1407.hc:654: `GLU_INCOMPATIBLE_GL_VERSION' undeclared (first use in this function) > make[1]: *** [GL_Errors.o] Error 1 > > make: *** [all] Error 1 > please help me with this. Thank you That looks like mixing GL headers from different sources, but that's only a guess. Did you copy cygwin's GL headers into GHC's mingw include directory (where they should be)? What cygwin version are you using? Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

1 0