Message

From awfurtado@uol.com.br Thu Nov 1 02:14:39 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Thu, 1 Nov 2001 00:14:39 -0200 Subject: [HOpenGL] Weird solution... but it worked! (was: HOpenGL-1.01 feedback) Message-ID: <000d01c1627b$02a12820$8b30e3c8@windows9> The good news: copying /usr/include/GL to PATH_TO_5.02\include\mingw\GL makes HOpenGL find 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 From awfurtado@uol.com.br Thu Nov 1 02:24:14 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Thu, 1 Nov 2001 00:24:14 -0200 Subject: [HOpenGL] more feedback (HOpenGL-1.01) Message-ID: <001801c1627c$5bb8f7c0$8b30e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1626B.89867E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------=_NextPart_000_0015_01C1626B.89867E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

When running some examples that use the = ESC (\27)=20 key to quit the program, I'm getting a uncaught exception. For=20 example:

light: fatal error: GLUT_CBWindow_d7lF: = uncaught=20 exception

This is happening only with the = examples of=20 redbook_HS. The examples in redbook_C are alright (no exceptions occurs = when=20 pressing ESC).

-- Andre

------=_NextPart_000_0015_01C1626B.89867E40-- From jeaf@cin.ufpe.br Thu Nov 1 23:59:48 2001 From: jeaf@cin.ufpe.br (Edson) Date: Thu, 1 Nov 2001 21:59:48 -0200 (EDT) Subject: [HOpenGL] some problems Message-ID: 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 " 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 From Sven.Panne@informatik.uni-muenchen.de Fri Nov 2 16:00:02 2001 From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne) Date: Fri, 02 Nov 2001 17:00:02 +0100 Subject: [HOpenGL] Re: FFI Addendum, CVS Id 1.19 References: <20011030213144E.chak@cse.unsw.edu.au> Message-ID: <3BE2C302.95F3BD8E@informatik.uni-muenchen.de> [ 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. From Sven.Panne@informatik.uni-muenchen.de Fri Nov 2 16:07:37 2001 From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne) Date: Fri, 02 Nov 2001 17:07:37 +0100 Subject: [HOpenGL] some problems References: Message-ID: <3BE2C4C9.509A229@informatik.uni-muenchen.de> Edson wrote: > [...] > 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 " HGraphicsTypes.hs > > HGraphicsTypes.hs:3: > failed to load interface for `GL': > Could not find interface file for `GL' > [...] It looks like you're mixing version 1.00 and 1.01. Has 1.01 been built successfully before? And do your hierarchies really start in the root directory? Cheers, S. From Sven.Panne@informatik.uni-muenchen.de Fri Nov 2 16:19:30 2001 From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne) Date: Fri, 02 Nov 2001 17:19:30 +0100 Subject: [HOpenGL] Weird solution... but it worked! (was: HOpenGL-1.01 feedback) References: <000d01c1627b$02a12820$8b30e3c8@windows9> Message-ID: <3BE2C792.1A0A228@informatik.uni-muenchen.de> Andre W B Furtado wrote: > The good news: copying /usr/include/GL to PATH_TO_5.02\include\mingw\GL > makes HOpenGL find correctly (I don't have to use the absolute > path anymore). Fine. GHC's WinDoze grandmaster promised me to include this fix in the next InstallShield version of GHC, too. > [ glut vs. glut32 ] As WinDoze doesn't come with GLUT, you must have installed it for yourself somehow. For problems like this, it would be helpful to know the locations of all OpenGL/GLUT DLLs, with and without *32. > [...] In other words, how do I "unistall" the older glut version? By moving glut.dll into "Trash". :-) But there's always the problem that you can't be sure that no other program still needs it. But in that case I guess that copying glut32.dll to glut.dll will do the trick. Nevertheless, I've uploaded a fresh http://www.informatik.uni-muenchen.de/~Sven.Panne/haskell_libs/HOpenGL/HOpenGL-1.01.tar.gz which contains the following changes: * look for glut32.dll before glut.dll is tried * cruel hacks for the GLU versionitis * a fix for Char vs. CChar confusion (the keyboard callbacks didn't work) As usual, feedback is highly appreciated. Cheers, S. From jeaf@cin.ufpe.br Mon Nov 5 14:57:41 2001 From: jeaf@cin.ufpe.br (Edson) Date: Mon, 5 Nov 2001 12:57:41 -0200 (EDT) Subject: [HOpenGL] more some problems... In-Reply-To: <3BE2C302.95F3BD8E@informatik.uni-muenchen.de> Message-ID: Hi all, Can someone help me to fix it? It was perfect with ghc-4.08.2, but now(ghc-5.02) i have some compilations problems. $ make 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 -lHOpen GL -lglut32 -lglu32 -lopengl32 "-#include " 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 From sof@galconn.com Mon Nov 5 19:36:24 2001 From: sof@galconn.com (Sigbjorn Finne) Date: Mon, 5 Nov 2001 11:36:24 -0800 Subject: [HOpenGL] gc 2.03 release candidate Message-ID: <021601c16631$2779aa00$4576fea9@sofbox> 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 From awfurtado@uol.com.br Tue Nov 6 05:09:03 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Tue, 6 Nov 2001 03:09:03 -0200 Subject: [HOpenGL] NEW-HOpenGL-1.01 feedback Message-ID: <001801c16681$35cc99a0$8c35e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C16670.63CC7AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_000B_01C16670.63CC7AC0 Content-Type: application/octet-stream; name="tst.hs" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tst.hs" import GLUT import GL display :: DisplayAction display = do clear [ ColorBufferBit ] flush swapBuffers myInit :: IO () myInit = do clearColor (Color4 0 0 0 0) clear[ColorBufferBit] matrixMode Projection loadIdentity ortho 0.0 1.0 0.0 1.0 (-1.0) 1.0 main :: IO () main = do GLUT.init Nothing createWindow "AWBF Bitmap Display" (return ()) [ GLUT.Double, GLUT.Rgb ] (Just (WindowPosition 100 100)) (Just (WindowSize 250 250)) myInit displayFunc display mainLoop ------=_NextPart_000_000B_01C16670.63CC7AC0-- From Sven_Panne@BetaResearch.de Tue Nov 6 09:05:53 2001 From: Sven_Panne@BetaResearch.de (Sven Panne) Date: Tue, 06 Nov 2001 10:05:53 +0100 Subject: [HOpenGL] gc 2.03 release candidate References: <021601c16631$2779aa00$4576fea9@sofbox> Message-ID: <3BE7A7F1.199F8445@BetaResearch.de> I've just made a quick test of the RC on Solaris with ghc-5.02, and it looks fine, except for one thing: StdDIS doesn't seem to take the fact into account that Char is now a 16bit Unicode thing for ghc. So there should probably be some castCharToCChar/castCCharToChar interspersed into the right places. Left as an easy exercise for the inclined reader... ;-) Cheers, S. From Sven_Panne@BetaResearch.de Tue Nov 6 09:16:26 2001 From: Sven_Panne@BetaResearch.de (Sven Panne) Date: Tue, 06 Nov 2001 10:16:26 +0100 Subject: [HOpenGL] NEW-HOpenGL-1.01 feedback References: <001801c16681$35cc99a0$8c35e3c8@windows9> Message-ID: <3BE7AA6A.7F1839DE@BetaResearch.de> Andre W B Furtado wrote: > [...] 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". Just guess what *I* have forgotten to do before putting this release candidate onto the server. :-} But luckily enough, there was enough time to fix this stealthily... > [...] Warning messages still appear during the "make step". As I've already mentioned, these are a consequence of the FFI design and GreenCard. > [...] fatal error: GLUT_CBWindow_d7T5: uncaught exception No response on the FFI front about System.exitWith yet... > [ size/speed concerns ] I didn't have a look at the generated code recently, so I've currently no idea what causes this. But you could give GHC's FFI backend a try by changing GreenCard's option "-t ghc" to "-t ffi". I'm not sure if HOpenGL's Makefiles handle all consequences of this correctly, but this should be easy to fix. 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 From awfurtado@uol.com.br Mon Nov 12 04:45:17 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Mon, 12 Nov 2001 02:45:17 -0200 Subject: [HOpenGL] Profiling & HOpenGL Message-ID: <000701c16b34$d4f0b220$0930e3c8@windows9> 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 From Sven_Panne@BetaResearch.de Mon Nov 12 09:15:07 2001 From: Sven_Panne@BetaResearch.de (Sven Panne) Date: Mon, 12 Nov 2001 10:15:07 +0100 Subject: [HOpenGL] Profiling & HOpenGL References: <000701c16b34$d4f0b220$0930e3c8@windows9> Message-ID: <3BEF931B.140F1137@BetaResearch.de> Andre W B Furtado wrote: > [...] > 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? About a week ago I used profiling with HOpenGL with a GHC-5.03 under Linux and it worked fine, but I haven't tried profiling under WinDoze for a long time. Anyway, I guess this is more a plattform problem than a HOpenGL one. Does profiling of simple "Hello, world!"-programs work? Cheers, S. From awfurtado@uol.com.br Tue Nov 13 16:45:17 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Tue, 13 Nov 2001 14:45:17 -0200 Subject: [HOpenGL] Profiling & HOpenGL References: <000701c16b34$d4f0b220$0930e3c8@windows9> <3BEF931B.140F1137@BetaResearch.de> Message-ID: <001801c16c62$94b0e3e0$5836e3c8@windows9> > Andre W B Furtado wrote: > > [...] > > 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? > > About a week ago I used profiling with HOpenGL with a GHC-5.03 under > Linux and it worked fine, but I haven't tried profiling under WinDoze > for a long time. Anyway, I guess this is more a plattform problem than > a HOpenGL one. Does profiling of simple "Hello, world!"-programs work? People at glasgow-haskell-users list said that is not possible to work with profiling when part of a program was not compiled with the profiling options. In my case, HOpenGL was not compiled with profiling options, so when I try to work with profiling in a HOpenGL program, I'm supposed to get a strange behavior. So I ask: is there a better way to build a profiling-enabled HOpenGL version than "hacking" config.mk to add the -prof option to the HC_OPTS? -- Andre From Sven.Panne@informatik.uni-muenchen.de Tue Nov 13 19:03:35 2001 From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne) Date: Tue, 13 Nov 2001 20:03:35 +0100 Subject: [HOpenGL] Profiling & HOpenGL References: <000701c16b34$d4f0b220$0930e3c8@windows9> <3BEF931B.140F1137@BetaResearch.de> <001801c16c62$94b0e3e0$5836e3c8@windows9> Message-ID: <3BF16E87.96B15B90@informatik.uni-muenchen.de> Andre W B Furtado wrote: > [...] is there a better way to build a profiling-enabled HOpenGL version > than "hacking" config.mk to add the -prof option to the HC_OPTS? You can pass configure a full path to ghc, including options: ./configure --with-hc="/usr/bin/ghc -prof -auto-all" Setting the HC environment variable before is another way IIRC. Cheers, S. From awfurtado@uol.com.br Tue Nov 13 19:41:02 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Tue, 13 Nov 2001 17:41:02 -0200 Subject: [HOpenGL] Strange fatal error Message-ID: <001401c16c7b$34638880$6a37e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C16C6A.5CEAA7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------=_NextPart_000_0011_01C16C6A.5CEAA7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Can anyone explain me the following=20 error?

fatal error: scavenge: = unimplemented/strange=20 closure type 0 @ 08C03FD0

(this happened with a program that = reads and do=20 some manipulations in a 3MB bitmap file, using HOpenGL-1.01 and=20 GHC-5.02 under Windows 98 + Cygwin)

Thanks,

-- = Andre

------=_NextPart_000_0011_01C16C6A.5CEAA7E0-- From v-julsew@microsoft.com Tue Nov 13 19:39:53 2001 From: v-julsew@microsoft.com (Julian Seward (Intl Vendor)) Date: Tue, 13 Nov 2001 11:39:53 -0800 Subject: [HOpenGL] RE: Strange fatal error Message-ID: <68B95AA1648D1840AB0083CC63E57AD60302ABCE@red-msg-06.redmond.corp.microsoft.com> This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16C7A.F7556CD3" ------_=_NextPart_001_01C16C7A.F7556CD3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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? =20 J -----Original Message----- From: Andre W B Furtado [mailto:awfurtado@uol.com.br]=20 Sent: Tuesday, November 13, 2001 7:41 PM To: glasgow-haskell-users@haskell.org Cc: hopengl@haskell.org Subject: Strange fatal error =09 =09 Can anyone explain me the following error? =20 fatal error: scavenge: unimplemented/strange closure type 0 @ 08C03FD0 =20 =09 (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) =20 Thanks, -- Andre ------_=_NextPart_001_01C16C7A.F7556CD3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

We=20 fixed some obscure GC-related bugs in 5.02. The fixes are in=20 5.02.1.

When=20 you try it with 5.02.1, does the problem still = happen?

-----Original Message-----
From: = Andre W B=20 Furtado [mailto:awfurtado@uol.com.br]
Sent: Tuesday, = November 13,=20 2001 7:41 PM
To: = glasgow-haskell-users@haskell.org
Cc:=20 hopengl@haskell.org
Subject: Strange fatal=20 error

Can anyone explain me the following=20 error?

fatal error: scavenge: = unimplemented/strange=20 closure type 0 @ 08C03FD0

(this happened with a program that = reads and do=20 some manipulations in a 3MB bitmap file, using HOpenGL-1.01 and=20 GHC-5.02 under Windows 98 + Cygwin)

Thanks,

--=20 Andre

=00 ------_=_NextPart_001_01C16C7A.F7556CD3-- --------------InterScan_NT_MIME_Boundary-- From Sven.Panne@informatik.uni-muenchen.de Sat Nov 17 19:02:53 2001 From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne) Date: Sat, 17 Nov 2001 20:02:53 +0100 Subject: [HOpenGL] ANNOUNCE: HOpenGL 1.01 released Message-ID: <3BF6B45D.B3216C66@informatik.uni-muenchen.de> 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 From awfurtado@uol.com.br Sun Nov 18 06:52:53 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Sun, 18 Nov 2001 04:52:53 -0200 Subject: [HOpenGL] HOpenGL profiling problem References: <000701c16b34$d4f0b220$0930e3c8@windows9> <3BEF931B.140F1137@BetaResearch.de> <001801c16c62$94b0e3e0$5836e3c8@windows9> <3BF16E87.96B15B90@informatik.uni-muenchen.de> Message-ID: <000601c16ffd$a6e32e80$3f0ac7c8@windows9> When I use profiling with HOpenGL, the file is empty (0 bytes) unless I change "mainLoop" for "return ()" in . Obviously, this program will terminate just after the window is created. Does anyone know the reason for this? (I'm using HOpenGL-1.01, GHC-5.02.1 under Windows98 + cygwin). -- Andre From Sven.Panne@informatik.uni-muenchen.de Sun Nov 18 16:59:24 2001 From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne) Date: Sun, 18 Nov 2001 17:59:24 +0100 Subject: [HOpenGL] HOpenGL profiling problem References: <000701c16b34$d4f0b220$0930e3c8@windows9> <3BEF931B.140F1137@BetaResearch.de> <001801c16c62$94b0e3e0$5836e3c8@windows9> <3BF16E87.96B15B90@informatik.uni-muenchen.de> <000601c16ffd$a6e32e80$3f0ac7c8@windows9> Message-ID: <3BF7E8EC.B70F0B56@informatik.uni-muenchen.de> Andre W B Furtado wrote: > When I use profiling with HOpenGL, the file is empty (0 bytes) > unless I change "mainLoop" for "return ()" in . Obviously, this > program will terminate just after the window is created. Alas, this is not HOpenGL-specific... > Does anyone know the reason for this? (I'm using HOpenGL-1.01, GHC-5.02.1 > under Windows98 + cygwin). The reason is that the only way to exit GLUT programs is via System.exitWith or System.exitFailure. But GHC's RTS currently doesn't like calls to these functions in callbacks, so the program terminates abnormally and nothing is written to . SimonM, almighty master of the RTS, hear our plea...: ;-) * Is there an easy way to fix exit{With,Failure} in callbacks? * Looking at shutdownHaskell(), it looks like profiling data should be written anyway, but it doesn't (at least for Andre and me). Any clues? Cheers, S. From awfurtado@uol.com.br Sun Nov 18 21:16:46 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Sun, 18 Nov 2001 19:16:46 -0200 Subject: [HOpenGL] make clean bug? Message-ID: <000801c17076$5a21c920$8d30e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C17065.915418A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (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):=20 Warning: This binding for `edges' shadows an existing binding -- Andre ------=_NextPart_000_0005_01C17065.915418A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(More feedback on HOpenGL-1.01 with = GHC-5.02 +=20 Cygwin + Windows98):

One day I decided to issue the "make = clean" command=20 to free some space in HOpenGL. I was surprised when I discovered that, = after=20 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=20 normality. Is this a "make clean bug"?

I noticed some "new" warning messages = when=20 compiling HOpenGL (I got the latest pack from Sven's site): =

Warning: This binding for `edges' = shadows an=20 existing binding

-- Andre

------=_NextPart_000_0005_01C17065.915418A0-- From awfurtado@uol.com.br Mon Nov 19 04:07:49 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Mon, 19 Nov 2001 02:07:49 -0200 Subject: [HOpenGL] Re: Strange fatal error References: <68B95AA1648D1840AB0083CC63E57AD60302ABCE@red-msg-06.redmond.corp.microsoft.com> Message-ID: <000501c170af$c283f4a0$b932e3c8@windows9> MessageI installed GHC-5.02.1 and now this problem doesn't happen anymore. -- Andre ----- Original Message ----- From: Julian Seward (Intl Vendor) To: Andre W B Furtado ; glasgow-haskell-users@haskell.org Cc: hopengl@haskell.org Sent: Tuesday, November 13, 2001 5:39 PM Subject: RE: Strange fatal error 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@haskell.org Cc: hopengl@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 From Sven_Panne@BetaResearch.de Mon Nov 19 09:38:07 2001 From: Sven_Panne@BetaResearch.de (Sven Panne) Date: Mon, 19 Nov 2001 10:38:07 +0100 Subject: [HOpenGL] make clean bug? References: <000801c17076$5a21c920$8d30e3c8@windows9> Message-ID: <3BF8D2FF.D9055A8C@BetaResearch.de> Andre W B Furtado wrote: > [...] 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". Ooops, I haven't tried a plain "make clean" for a long time. Probably "make distclean" and/or "make maintainer-clean" does the trick. > [...] 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 This is only an aesthetic warning, so it can be safely ignored. 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 From awfurtado@uol.com.br Tue Nov 27 01:42:29 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Mon, 26 Nov 2001 23:42:29 -0200 Subject: [HOpenGL] Quadrics Message-ID: <004701c176e4$c786b600$5730e3c8@windows9> 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 From Sven_Panne@BetaResearch.de Tue Nov 27 08:35:51 2001 From: Sven_Panne@BetaResearch.de (Sven Panne) Date: Tue, 27 Nov 2001 09:35:51 +0100 Subject: [HOpenGL] Quadrics References: <004701c176e4$c786b600$5730e3c8@windows9> Message-ID: <3C035067.403E2F0C@BetaResearch.de> Andre W B Furtado wrote: > [...] In HOpenGL, to create a new Quadric, the command is: > > qObj <- newQuadric > > But how do I issue deleteQuadric? [...] Simple answer: Never! :-) The garbage collector automatically takes care of this via the ForeignObj mechanism (well, this should be ForeignPtr or something in future versions). deleteQuadric is oly use internally and not exported, anyway. examples/redbook_HS/Quadric.hs demonstrates the usage of quadrics in HOpenGL. Tesselators and NURBS are not explicitly deleted, either, BTW. OTOH, I must admit that I haven't used GLU's quadrics, tesselators, and NURBS extensively yet. They are quite a moving target in different OpenGL versions, but things have settled down a bit recently. As always, API critique and suggestions are highly welcome. 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 From awfurtado@uol.com.br Tue Nov 27 18:14:48 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Tue, 27 Nov 2001 16:14:48 -0200 Subject: [HOpenGL] Quadrics References: <004701c176e4$c786b600$5730e3c8@windows9> <3C035067.403E2F0C@BetaResearch.de> Message-ID: <001e01c1776f$92e45fc0$6335e3c8@windows9> Sven Panne wrote: > [...] The garbage collector automatically takes > care of this [...] So if I have an idleFunc (or timerFunc) that has the following command: qObj <- newQuadric and if it's called a lot of times I sould not worry about the heap, souldn't I? Does this apply to display lists also? (Does the GC takes care of unused display lists?) Thanks, -- Andre From Sven.Panne@informatik.uni-muenchen.de Tue Nov 27 21:27:01 2001 From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne) Date: Tue, 27 Nov 2001 22:27:01 +0100 Subject: [HOpenGL] Quadrics References: <004701c176e4$c786b600$5730e3c8@windows9> <3C035067.403E2F0C@BetaResearch.de> <001e01c1776f$92e45fc0$6335e3c8@windows9> Message-ID: <3C040525.B48FCBFA@informatik.uni-muenchen.de> Andre W B Furtado wrote: > So if I have an idleFunc (or timerFunc) that has the following command: > > qObj <- newQuadric > > and if it's called a lot of times I sould not worry about the heap, souldn't > I? We should handle quadrics, tesselators, and NURBS objects similarly, because they are all structs/classes in the GLU C binding, which are created and destroyed in the same manner. The sizes of these objects in the SGI sample implementation on Intel-Linux are: GLUquadricObj 20 GLUtesselator 3140 GLUnurbsObj 140812 (Huh?! I hope I got this one correct...) I didn't expect the latter ones to be so large, so relying on Haskell's GC alone might not be the best thing. Here's a suggestion for improvement: In analogy to Haskell's file handles, add explicit "destructors", which *can* be used explicitly (e.g. in your case), but needn't if you don't care about the exact time when the associated resources are released. For convenience, a "withFOO" action could be added, too. So, e.g. for quadrics: newQuadric :: IO QuadricObj deleteQuadric :: QuadricObj -> IO () withQuadric :: (QuadricObj -> IO a) -> IO a Although withFOO would be the minimalistic interface, looking at the different GLU implementations reveals that apart from the allocation alone there is a lot of initialization going on internally (at least for tesselators and NURBS). This could be a performance killer if you are forced to allocate a new object every time you need one. But that is only a guess. Comments? > Does this apply to display lists also? (Does the GC takes care of unused > display lists?) Display lists are another story: There are not much resources associated with themselves (at least if I read the SI/Mesa code correctly), and there is deleteLists. GC alone can not determine if a display list name will be used in the future, but perhaps there is a way I didn't see yet... Cheers, S. From awfurtado@uol.com.br Thu Nov 1 02:14:39 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Thu, 1 Nov 2001 00:14:39 -0200 Subject: [HOpenGL] Weird solution... but it worked! (was: HOpenGL-1.01 feedback) Message-ID: <000d01c1627b$02a12820$8b30e3c8@windows9> The good news: copying /usr/include/GL to PATH_TO_5.02\include\mingw\GL makes HOpenGL find 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 From awfurtado@uol.com.br Thu Nov 1 02:24:14 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Thu, 1 Nov 2001 00:24:14 -0200 Subject: [HOpenGL] more feedback (HOpenGL-1.01) Message-ID: <001801c1627c$5bb8f7c0$8b30e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1626B.89867E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------=_NextPart_000_0015_01C1626B.89867E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

When running some examples that use the = ESC (\27)=20 key to quit the program, I'm getting a uncaught exception. For=20 example:

light: fatal error: GLUT_CBWindow_d7lF: = uncaught=20 exception

This is happening only with the = examples of=20 redbook_HS. The examples in redbook_C are alright (no exceptions occurs = when=20 pressing ESC).

-- Andre

Can anyone explain me the following=20 error?

fatal error: scavenge: = unimplemented/strange=20 closure type 0 @ 08C03FD0

(this happened with a program that = reads and do=20 some manipulations in a 3MB bitmap file, using HOpenGL-1.01 and=20 GHC-5.02 under Windows 98 + Cygwin)

Thanks,

-- = Andre

We=20 fixed some obscure GC-related bugs in 5.02. The fixes are in=20 5.02.1.

When=20 you try it with 5.02.1, does the problem still = happen?

-----Original Message-----
From: = Andre W B=20 Furtado [mailto:awfurtado@uol.com.br]
Sent: Tuesday, = November 13,=20 2001 7:41 PM
To: = glasgow-haskell-users@haskell.org
Cc:=20 hopengl@haskell.org
Subject: Strange fatal=20 error

Can anyone explain me the following=20 error?

fatal error: scavenge: = unimplemented/strange=20 closure type 0 @ 08C03FD0

(this happened with a program that = reads and do=20 some manipulations in a 3MB bitmap file, using HOpenGL-1.01 and=20 GHC-5.02 under Windows 98 + Cygwin)

Thanks,

--=20 Andre

(More feedback on HOpenGL-1.01 with = GHC-5.02 +=20 Cygwin + Windows98):

I noticed some "new" warning messages = when=20 compiling HOpenGL (I got the latest pack from Sven's site): =

Warning: This binding for `edges' = shadows an=20 existing binding

-- Andre