headers
Sven Panne | 1 Aug 2009 16:16
Picon

Re: [Haskell] ANNOUNCE: OpenGL 2.3.0.0

[ Thread moved to HOpenGL mailing list ]

Am Freitag, 31. Juli 2009 22:43:14 schrieb Paul L:
> [...]
> I've also noticed that the decision was made to use solely C types as
> instances for VertexComponent, ColorComponent, etc. I'm not sure I
> understand this change because:

First of all I have to admit that I'm guilty of leaving out this change from 
the change notes, sorry for that.

> 1. There was no default type for things like GL.Vertex3, and one had
> to explicitly annotate the type. Removing Int, Float from the
> Component classes would surely break A LOT OF existing code.

Strictly speaking, it breaks only code which was wrong, anyway. The OpenGL 
spec itself makes e.g. only assumptions about minimum sizes of the types, but 
prescribes no specific mapping. Granted, GLfloat e.g. has been a type synonym 
for Float, but there was never a guarantee for that and I consider the usage 
of type synonyms for this an API bug in previous versions of my package. 
Fixing code which breaks is quite trivial and those fixes will make any non-
portable assumptions explicit (via fromIntegral, realToFrac or castPtr), which 
is a good thing, and the way it should have always been.

In your example above, the type annotation should be ':: GLfloat', not ':: 
Float', which worked only by accident. If you have a 'Vertex3 Float', use 
'fmap realToFrac' to get a 'Vertex3 GLfloat'.

> 2. I don't see a problem adding back Int, Float, Double, etc. as
> instances of those Component classes along side of C types.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sven Panne | 1 Aug 2009 16:54
Picon

Re: problems running SmoothOpenGL3

Am Freitag, 31. Juli 2009 17:25:45 schrieb Michael [Plouj] Ploujnikov:
> [...] Finally, this is what I get if I try to compile with 'ghc --make':
>
> $ ghc --make -lglut SmoothOpenGL3.hs # the linker fails without -lglut
> similar to this:
> http://www.haskell.org/pipermail/hopengl/2008-September/000756.html

I don't know what's going on here, things work for me without -lglut on 
openSUSE 11.1. Which OS/distro are you using? It is hard to debug without 
actually seeing it fail for oneself. Anyway, I am in the process of changing 
the GLUT package to use dynamic linking internally, too, and the autoconf 
dependency will be removed as well. If you like, you could give the code on 
http://darcs.haskell.org/packages/GLUT/ a try and tell us about your results. 
Hopefully such linking issues will be a thing of the past... (famous last 
words ;-)

> [1 of 1] Compiling Main             ( SmoothOpenGL3.hs, SmoothOpenGL3.o )
> Linking SmoothOpenGL3 ...
> $ ./SmoothOpenGL3
> SmoothOpenGL3: user error (unknown GLUT call glutInitContextVersion,
> check for freeglut)

That's OK: To create an OpenGL 3.x context, you need a recent version of 
freeglut. Classic GLUT and older versions of freeglut simply do not have the 
API entries glutInitContextVersion and glutInitContextFlags. I really, really 
hope that the freeglut project admins make a release soon. I am active in this 
project, but I can't make releases. There are a few GL/GLX extensions I'd like 
to add to freeglut, too, but only after a release.

Depending on your OpenGL driver, you can make things work by using
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael [Plouj] Ploujnikov | 2 Aug 2009 01:08
Picon

Re: problems running SmoothOpenGL3

On Sat, Aug 1, 2009 at 10:54 AM, Sven Panne<Sven.Panne <at> aedion.de> wrote:
> Am Freitag, 31. Juli 2009 17:25:45 schrieb Michael [Plouj] Ploujnikov:
>> [...] Finally, this is what I get if I try to compile with 'ghc --make':
>>
>> $ ghc --make -lglut SmoothOpenGL3.hs # the linker fails without -lglut
>> similar to this:
>> http://www.haskell.org/pipermail/hopengl/2008-September/000756.html
>
> I don't know what's going on here, things work for me without -lglut on
> openSUSE 11.1. Which OS/distro are you using?

Fedora 11 x86_64

> It is hard to debug without
> actually seeing it fail for oneself. Anyway, I am in the process of changing
> the GLUT package to use dynamic linking internally, too, and the autoconf
> dependency will be removed as well. If you like, you could give the code on
> http://darcs.haskell.org/packages/GLUT/ a try and tell us about your results.
> Hopefully such linking issues will be a thing of the past... (famous last
> words ;-)

I actually don't know how to install a package from source like this.
I'm only familiar with the 'cabal install ...' way. Anyways, I deleted
~/.ghc/ and ~/.cabal/ and reinstalled all of my packages (GLUT, SDL
and xmonad-contrib). After this, I'm able to run 'ghc --make
SmoothOpenGL3.hs' successfully on my Fedora11 desktop, but not the
Fedora11 laptop (I'll continue to investigate it).

>
>> [1 of 1] Compiling Main             ( SmoothOpenGL3.hs, SmoothOpenGL3.o )
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory D. Weber | 4 Aug 2009 18:03
Favicon
Gravatar

Split package organization (AntTweakBar, Cabal, darcs)

I'm working on a Haskell binding for AntTweakBar,
a light user interface for OpenGL applications
(http://www.antisphere.com/Wiki/tools:anttweakbar).

I have three questions about how to organize it as a
Haskell package or packages, Cabal, and darcs.

First, since AntTweakBar provides support for handling
events from GLUT, GLFW, and SDL, as well as customizable
event handling from other sources, would it be best to
divide it into four packages -- AntTweakBar (core),
AntTweakBar-GLUT, AntTweakBar-GLFW, and AntTweakBar-SDL?
A few other "package groups" on Hackage have taken this
approach of splitting according to the user interface:
for example, grapefruit-ui-gtk, reactive-glut,
though not on such a large scale as I am proposing.

Advantages of four packages rather than one:
-- Fewer build dependencies, for example, for users who want to use
   just SDL and not have to install GLUT or GLFW.
-- If one of the build dependencies is broken (as for example GLFW
   is just at the moment with the latest OpenGL), users could still
   build the other AntTweakBar-* packages.

Disadvantages:
-- More packages to install, for those who want it all.
-- I might seem to be grabbing an undue share of the package namespace.
   And it could get way out of hand if I further split the examples
   from the library, making 
   AntTweakBar-(base|GLUT|GLFW|SDL)-(lib|examples) = 8 packages!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zach Kozatek | 9 Aug 2009 18:18
Picon

Windows and Hopegenl/Hglut

I have tried glut 3.7 and free glut
I have the mingw and msys toolchain
I have cabal working
With ghc 6.10>= I can not get my opengl/glut programs working
I have them compile and linked
when they run with glut 3.7 I get a runtime error of the nature:

logo.exe - Entry Point Not Found
The procedure entry point glutAddmenuEntry <at> 8 could not be located in the dynamic link library

My programs work fine with ghc 6.8.3 but then i can not cabal install the latest libraries

Any help would be appreciated,
Zach Kozatek

_______________________________________________
HOpenGL mailing list
HOpenGL <at> haskell.org
http://www.haskell.org/mailman/listinfo/hopengl
Permalink | Reply | 0 comments |
headers
Sven Panne | 10 Aug 2009 19:55
Picon

Re: Fwd: OpenGLRaw

[Forwarded to the HOpenGL list, because it might be of general interest]

Am Friday 07 August 2009 08:06:04 schrieben Sie:
> Sven,
>
> I got this working by *removing* GL from the line
>        extra-libraries: GL
> in the *cabal file.
>
> It seems to work with this change. Perhaps GL is needed for another
> build method?
>
> Thank you for doing the hard work with OpenGL and OpenGLRaw, that lets
> us experiment with our ChalkBoard accelerator.
>
> Andy
>
> Begin forwarded message:
> > From: Andy Gill <andygill <at> ku.edu>
> > Date: August 6, 2009 10:53:37 PM CDT
> > To: Sven Panne <Sven.Panne <at> aedion.de>
> > Cc: Kevin Matlage <kmatlage <at> ittc.ku.edu>
> > Subject: OpenGLRaw
> >
> > Hi Sven,
> >
> > I get the following error when trying to include OpenGLRaw, as build
> > out of the box.
> >
> > $ cat Main.hs
> > import Graphics.Rendering.OpenGL.Raw
> >
> > main = print "Hello"
> > $ ghc --make Main.hs
> > [1 of 1] Compiling Main             ( Main.hs, Main.o )
> > Linking Main ...
> > ld: library not found for -lGL
> > collect2: ld returned 1 exit status
> >
> > *Any* ideas? I'm stuck. I've got a OSX 10.5. Are there any gotyas I
> > should know about?
> >
> > Andy Gill
>
> Andy Gill, <andygill <at> ku.edu>
> Assistant Professor
> The University of Kansas, EECS Department
> Information and Telecommunication Technology Center

Is this generally the case for Mac OS X users? If yes, the extra-libraries 
line should be excluded in the Cabal file for this platform. Have others 
experienced the same problem? Reports would be nice, regardless if things work 
or not...

Cheers,
   S.
Permalink | Reply | 4 comments |
headers
Sven Panne | 10 Aug 2009 20:03
Picon

Re: Re: Fwd: OpenGLRaw

Am Montag, 10. August 2009 19:55:24 schrieb Sven Panne:
> [...]
> Is this generally the case for Mac OS X users? If yes, the extra-libraries
> line should be excluded in the Cabal file for this platform. Have others
> experienced the same problem? Reports would be nice, regardless if things
> work or not...

Just another idea from a different email: Perhaps "-framework OpenGL" is 
missing for Mac OS X? It would be nice to hear what the right fix is, I don't 
have access to any Macs...

Cheers,
   S.
Permalink | Reply | 3 comments |
headers
Sven Panne | 10 Aug 2009 20:11
Picon

Re: [Haskell] ANNOUNCE: OpenGL 2.3.0.0

Am Sonntag, 2. August 2009 13:50:08 schrieb Paul L:
> Thanks for the reply. If the issue was caused by an "API bug", I'm
> actually not sure if this "API bug" has been fixed. Compare
>
> http://hackage.haskell.org/packages/archive/OpenGL/2.2.3.0/doc/html/Graphic
>s-Rendering-OpenGL-GL-VertexSpec.html#t%3AVertexComponent
>
> to
>
> http://hackage.haskell.org/packages/archive/OpenGL/2.3.0.0/doc/html/Graphic
>s-Rendering-OpenGL-GL-VertexSpec.html#t%3AVertexComponent
>
> You can see that either Int16/Int32/Float/Double (in older versions)
> or CShort/CInt/CFloat/CDouble (in the new version) are listed as
> instances, not GLshort/GLint/GLfloat/GLdouble.
>
> This is less of a "real" bug, but it's certainly misleading. Maybe you
> can get it fixed by using -XTypeSynonymInstances.

I am well aware of the fact the documentation is not optimal at the moment, 
but I am not willing to sacrifice portability for this tiny issue, so the flag 
you mention is not an option. In former releases I used an ugly CPP hack to 
improve the documentation a bit, but this feels wrong IMHO.

The recent change from the sized Int/Word types to the C types was a 
consequence of removing autoconf, the next step will be using the C types 
wrapped in newtypes. This is the right way to do it, and it will fix the 
documentation, too. If you do not make any assumptions about the actual 
representations (i.e. use fromIntegral and friends when needed), this further 
change will not affect any portable code.

Cheers,
    S.
Permalink | Reply | 0 comments |
headers
Sven Panne | 16 Aug 2009 17:25
Picon

Re: Re: Fwd: OpenGLRaw

Am Montag, 10. August 2009 20:03:53 schrieb Sven Panne:
> Am Montag, 10. August 2009 19:55:24 schrieb Sven Panne:
> > [...]
> > Is this generally the case for Mac OS X users? If yes, the
> > extra-libraries line should be excluded in the Cabal file for this
> > platform. Have others experienced the same problem? Reports would be
> > nice, regardless if things work or not...
>
> Just another idea from a different email: Perhaps "-framework OpenGL" is
> missing for Mac OS X? It would be nice to hear what the right fix is, I
> don't have access to any Macs...

Hmmm, no replies yet... So I'd like to The OpenGLRaw.cabal obviously needs 
some tweaks on Mac OS X, but it is not clear for me what to do. Should

   a) the "extra-libraries: GL" line be removed for the "os(darwin)" case?

   b) a "frameworks: OpenGL" line be added?

What is the right way to fix things? a) alone? b) alone? Or both a) and b)? 
Feedback would be highly appreciated, because I don't have access to Macs.

Cheers,
   S.
Permalink | Reply | 2 comments |
headers
Sven Panne | 16 Aug 2009 18:12
Picon

ANNOUNCE: GLUT 2.2.1.0

A new version of the GLUT package has been uploaded to Hackage.

 * The package is now autoconf-free. API entries are resolved dynamically at 
runtime, just like the OpenGLRaw and GLURaw packages.

 * Support for sRGB framebuffers has been added, just use SRGBMode with 
initialDisplayMode. To use this functionality, you need the upcoming freeglut 
2.6.0 library, older versions and "classic" GLUT do not support this feature.

 * Support for context profiles has been added via initialContextProfile. 
Again, this works with the upcoming freeglut 2.6.0 library only.

Cheers,
   S.
Permalink | Reply | 0 comments |

Gmane