November 2001 - HOpenGL

Quadrics
by Andre W B Furtado 27 Nov '01

27 Nov '01

In OpenGL, the following command is used to create a new Quadric Object: qObj = gluNewQuadric(); And, to delete it, we have: gluDeleteQuadric(qObj); In HOpenGL, to create a new Quadric, the command is: qObj <- newQuadric But how do I issue deleteQuadric? Its signature is: deleteQuadric :: QuadricObj -> Addr -> IO () but I don't know how to use it. What is this "Addr" parameter for? -- Andre

3 3

make clean bug?
by Andre W B Furtado 19 Nov '01

19 Nov '01

(More feedback on HOpenGL-1.01 with GHC-5.02 + Cygwin + Windows98): One day I decided to issue the "make clean" command to free some space in HOpenGL. I was surprised when I discovered that, after doing this, my programs now complain: "could not find interface file for GLUT/GL". After I re-compiled HOpenGL once again, everything came back to normality. Is this a "make clean bug"? I noticed some "new" warning messages when compiling HOpenGL (I got the latest pack from Sven's site): Warning: This binding for `edges' shadows an existing binding -- Andre

2 1

RE: Strange fatal error
by Julian Seward (Intl Vendor) 19 Nov '01

19 Nov '01

We fixed some obscure GC-related bugs in 5.02. The fixes are in 5.02.1. When you try it with 5.02.1, does the problem still happen? J -----Original Message----- From: Andre W B Furtado [mailto:awfurtado@uol.com.br] Sent: Tuesday, November 13, 2001 7:41 PM To: glasgow-haskell-users(a)haskell.org Cc: hopengl(a)haskell.org Subject: Strange fatal error 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

2 1

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