- HOpenGL - Haskell.org

Re: ANNOUNCE: GHC version 6.0
by Sven Panne 31 May '03

31 May '03

[ Redirected to hopengl mailing list ] Ralf Hinze wrote: >>Compiling 6.0 from source fails with: >> >>../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude '-#include >>"HsOpenGL.h"' -cpp -I/usr/X11R6/include -DCALLCONV=ccall >>'-DGET_PROC_ADDRESS="glXGetProcAddressARB"' -package-name OpenGL -O >>-Rghc-timing -package base -split-objs -c >>Graphics/Rendering/OpenGL/GL/Extensions.hs -o >>Graphics/Rendering/OpenGL/GL/Extensions.o -ohi >>Graphics/Rendering/OpenGL/GL/Extensions.hi >>Graphics/Rendering/OpenGL/GL/Extensions.hs:42: parse error on input >>`glXGetProcAddressARB' <<ghc: 3261568 bytes, 2 GCs, 20548/20548 avg/max >>bytes residency (1 samples), 5M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT >>(0.09 elapsed), 0.01 GC (0.03 elapsed) :ghc>> make[2]: *** >>[Graphics/Rendering/OpenGL/GL/Extensions.o] Fehler 1 >>make[1]: *** [all] Fehler 1 >>make[1]: Leaving directory >>`/var/tmp/portage/ghc-6.0/work/stage2-build/libraries' make: *** [build] >>Fehler 1 > > > The following patch worked for me (but does it cure the problem?) > > irrwisch root # diff libraries/OpenGL/Graphics/Rendering/OpenGL/GL/Extensions.hs libraries/OpenGL/Graphics/Rendering/OpenGL/GL/Extensions.hs-orig > 42c42 > < foreign import CALLCONV unsafe GET_PROC_ADDRESS :: > --- > >>foreign import CALLCONV unsafe GET_PROC_ADDRESS glXGetProcAddressARB :: Hmmmm, that's definitely no solution. What platform exactly are you using? (ghc used for building, gcc version, etc.) Calling make with EXTRA_HC_OPTS="-v -keep-tmp-files" and sending the output plus the generated *.hscpp file might help. I guess that something goes wrong during the preprocessing stage. On a non-WinDoze platform the last lines of Extensions.hs should expand into: foreign import ccall unsafe "glXGetProcAddressARB" glXGetProcAddressARB :: CString -> IO (FunPtr a) On WinDoze they should expand into: foreign import stdcall unsafe "wglGetProcAddress" glXGetProcAddressARB :: CString -> IO (FunPtr a) Cheers, S.

1 0

GLUT not found
by Milos Hasan 03 May '03

03 May '03

Hello, I use Windows 2000/MingGW/MSYS and HOpenGL compiled OK, but when trying to compile a simple program, I got: ghc: can't find module `Graphics.UI.GLUT' (while processing "Hello.hs") It seems that "make install" does not copy the GLUT files into the GHC directory structure at all. What to do? Milos

2 2

Re: problems invoking haddock
by Andre W B Furtado 03 May '03

03 May '03

> This sounds just like what I got with cygwin and Python. You have to > rebase your dll's due to some upgrade/restructure they did, just search > for rebase and cygwin and I'm sure you'll find some text on how to fix > it. Problems, problems, problems... The info I found told me that I should: 1) Download a file called rebase.cc and build it with "g++ -O2 -o rebase rebase.cc -limagehlp" 2) Use the rebase program against some Cygwin DLLs Now here come the problems: a) Trying to build rebase.cc gives me an error: rebase.cc:45: `main' must return `int'. Making main to return 'int' builds the program, but when trying to rebase the DLLs other problem arises: ReBaseImage() failed with last error = 2 b) I found a pre-installed rebase command in cygwin and gave up building rebase.cc. Trying to run this rebase command gives me the error: REBASE: -R must preceed -o. Adding the -R option to the command line, another error arises: REBASE: Total Size of mapping 0x00200000 REBASE: Range 0x67e00000 -0x68000000 Argh! I wonder if haddock has a install shield wizard for Windows! :) Cheers, -- Andre

1 0

Re: [HOpenGL] How to compile a hopengl program?
by Sven Panne 21 Apr '03

21 Apr '03

Bas van Dijk wrote: > I built GHC from sources using --enable-hopengl at configuration > time. [...] In that case "-package GLUT" is OK. The GLUT package depends on the OpenGL package (cf. the output of "ghc-pkg --show-package=GLUT"), so there is no need for an explicit "-package OpenGL". The reason for the new package names is a cleaner separation of the rendering part (GL/GLU in package "OpenGL") and the UI part (GLUT in package "GLUT"). The error you get is caused by the fact that the new API in CVS uses hierarchical modules, while the examples on the web pages are for the old modules. Another basic difference is that the new API is modeled around the notion of "state variables" http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/OpenGL/Graphics… which mirrors the OpenGL state machine very closely and gives a unified view of getters and setters, e.g. the current viewport has the type viewport :: StateVar (Position, Size) So you can set the viewport with viewport $= (Position 10 10, Size 20 20) and retrieve the current viewport with (Position x y, Size w h) <- get viewport OpenGL state which can only be queried has a different type, e.g. maxViewportDims :: GettableStateVar Size which allows mvd <- get maxViewportDims but catches the following error at compile-time: maxViewportDims $= Size 30 40 Some examples with the new API: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/examples/R… http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/examples/R… After this small digression, here my advice: If you want to use Haskell + OpenGL *now*, you should probably use HOpenGL 1.04 from http://haskell.org/HOpenGL, not the stuff from CVS. Switching to the new API in the future will be relatively easy because there are no subtle semantic changes, mostly syntax. Cheers, S.

2 2

Fwd: Re: [HOpenGL] How to compile a hopengl program?
by Bas van Dijk 21 Apr '03

21 Apr '03

1 0

How to compile a hopengl program?
by Bas van Dijk 21 Apr '03

21 Apr '03

Hi, I'm trying to compile the hopengl program: http://www.haskell.org/HOpenGL/examples/BezMesh.hs But I get the following error with ghc version 5.04.3: --------------------------------------------------------------------------------------------- bas@BASSBOX> ghc -package GLUT -package OpenGL BezMesh.hs BezMesh.hs:12: failed to load interface for `GL': Could not find interface file for `GL' --------------------------------------------------------------------------------------------- Does it have something to do with a wrong packagename??? Greetings, Bas.

2 1

problems invoking haddock
by Andre W B Furtado 11 Apr '03

11 Apr '03

I was not able to make Haddock run... Invoking it for a simple hello world example > module Main where > > main :: IO() > main = putStrLn "Hello World" gives me the following errors: Warning: module not found: Prelude Warning: Main: the following names could not be resolved: IO Prelude.() Fail: does not exist Action: openFile Reason: No such file or directory File: /usr/local/lib/haddock-0.4/haddock.css Using the option --no-implicit-prelude solves the first problem, but I wonder if this is the correct way to get around it. Using a specified stylesheet instead of the default one that comes with Haddock (--css=filename) solves the last problem, but introduces a new one: Fail: does not exist Action: openFile Reason: No such file or directory File: /usr/local/lib/haddock-0.4/haskell_icon.gif Putting /usr/local/lib/haddock-0.4 in the PATH does not solve the problem... Another attempt to invoke Haddock for other example such as module Test where test :: Int test = 3 gave me the problem: "Warning: Test: the following names could not be resolved: Int" Any ideas of what's going wrong? (My config: WindowsXP + GHC-5.04.2 + Cygwin) Thanks, -- Andre

1 0

Haddock installation question
by Andre W B Furtado 09 Apr '03

09 Apr '03

I got the following error while trying to compile Haddock (./configure step): error: 'lex' or 'flex' is required to compile GHC >From where can I download 'lex' or 'flex'? Do they come with Cygwin/GHC installation packages? My config is: Windows XP under Cygwin, GHC-5.04.2 Thanks, -- Andre

1 1

nullAddr...
by Andre W B Furtado 01 Apr '03

01 Apr '03

Perhaps the HOpenGL list is not the best place to post this question, but I'll try it... I'm trying to compile FunGEn (a Haskell Game Engine) with the new versions of GHC, Cygwin, HOpenGL, etc., etc. One of the modules (the Sound module) uses the following foreign import to call function PlaySound of the windows API. : foreign import ccall "PlaySound" play :: CString -> Win32.HMODULE -> Word32 -> IO Bool The module also exports the following funcion, playSound: playSound :: String -> Win32.HMODULE -> [SoundFlag] -> IO Bool playSound filename hmod flags = play (unsafePerformIO (newCString filename)) hmod (marshall_SoundFlagLIST flags) I used to call this function like this: playSound filename nullAddr flags Now I'm having some problems with the "nullAddr" parameter, which I've never had before: Variable not in scope: `nullAddr'. Can anyone tell me if it does not exist anymore or what has happened to it? Thanks, -- Andre

1 0

Re: [HOpenGL] HOpenGL without GLUT
by C.Reinke 29 Mar '03

29 Mar '03

> Axel Simon wrote: > > I thought about extending my gtk2hs with OpenGL functionality. > > A good plan! :-) more, more, more!-) > > There is new functionality for Gtk version 2 which seems to just > > add 3D rendering to normal widgets: > > Just to be clear: Neither GtkGLArea nor GtkGLExt offer any kind of > rendering capabilities, they offer the resource management for the > current OpenGL context (i.e. the OpenGL state machine(s)). Does that mean there'll be 3d-scenes running in Gtk menu entries, dialogue boxes, buttons, etc.?-) > The rendering itself is done always the same way, regardless of the > Toolkit / resource management library in question (GTK, GLUT, WGL, > AGL, GLX). Yes, but the interfacing will differ. Most GUI libraries will provide a superset of GLUT (otherwise, why bother?), so if you really want to get into GUI-specific HOpenGL applications, there's no way to avoid programming differences. It would be nice, though, to have a single basic API that would make it easy to switch between a GLUT-based HOpenGL app and a Gtk-based one. The de-facto standard is GLUT itself, so apart from providing gtk2hs with access to GtkGLExt, a GtkGLExt/GtkGLArea-based GLUT equivalent would be useful. Ideally, I just want to replace -package GLUT with -package gtk2hs or something when compiling!-) Cheers, Claus PS. Why do HOpenGL apps have to be that big (on win2k, the Klein example gives me a 4Mb executable, which seems to be standard size for non-trivial, but tiny, examples; even the Planet example gives about 1Mb, on win2k)? Glut is already shared between HOpenGL apps, and small (easy to distribute to those who don't already have it); could other parts of HOpenGL apps be shared out as well? PPS. I know that Haskell programs don't tend to run on phones - does that mean that the embedded OpenGL iniatives are irrelevant for HOpenGL?

3 2