April 2011 - HOpenGL - Haskell.org

Render fonts in HopenGL
by er9999 26 Jul '11

26 Jul '11

Hello, Can anyone give me an example for fonts rendering? I tried to use FTGL library, but it is too complicated on Windows(compile). Is it possible to do it in a simple way? I need more than the given example in red book(Font.hs), something like outline font. By the way, I am new in OpenGL and Haskell, so the real exmaple should be the best. Thanks!

4 6

New programmer => some comments/suggestions
by L Corbijn 08 May '11

08 May '11

Hi everyone, I was wondering if anyone is working on improving the OpenGL package. As the git repository [1] on github looks rather quiet, beside my (Laar, not my real name) casual editing. In that process of adding extra functions to improve the library to some higher version of OpenGL I ran into some structural inconveniences. But as I'm not that experienced with Haskell nor with collaborating in open source projects. The major problem in my opinion is the boat load of deprecated functions and objects that make finding and having an overview of the code rather difficult. This is not helped by the fact that there are a lot of files that could be marked as deprecated. Therefore I think that something more serious should be done than only adding deprecated pragma's as Jason Dagit suggests in [2]. I think it should improve the overview of the code if all deprecated functions/code/etc. are move to a different namespace, say ...OpenGL.GL.Deprecated. This would help a lot as with coding new stuff the files would be quite a bit smaller as you wouldn't see the deprecated stuff. Though this will probably be quite a hard break with older code. Though quite a lot of code to refactor I think it would lead to a better structured project that is easier to maintain. Furthermore in it's current state importing ...OpenGL.GL does import everything, whether it's deprecated, usefull or even only usable for higher versions of OpenGL-contexts than you use. Although the exported functions/Types wouldn't lead to clashes it would be nice to have modules that only export the stuff that is usable for a certain OpenGL-context (e.g. importing ...Core31 or ...Core31Compatibility). This would lead to a compile error when using unsupported functions, which is a lot more pleasant than having to debug why code doesn't work (talking from experience). And if the future brings better auto-complete for Haskell it might lead to better suggestions (all the unused stuff out). Greetings, L Corbijn [1] https://github.com/dagit/OpenGL/network [2] http://www.haskell.org/pipermail/hopengl/2011-April/001002.html

2 3

Google Summer of Code Project: Modernize and simplify OpenGL bindings for Haskell. Focus on safety, shaders and simplicity.
by Jason Dagit 26 Apr '11

26 Apr '11

I'm excited to announce that we will have a student this summer! Alexander Göransson: Simplified OpenGL bindings Alexander, could I ask you to post your proposal to the list? Thanks! Jason

1 0

Re: [HOpenGL] How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 19 Apr '11

19 Apr '11

On Mon, Apr 18, 2011 at 6:21 PM, Jens Petersen <juhp(a)community.haskell.org>wrote: > On 7 April 2011 06:51, Don Stewart <dons00(a)gmail.com> wrote: > > Moving those modules under OpenGL.*.*.StateVar etc would remove the > > problems with upgrading to the HP. > > Perhaps it would be a good time now to revisit again whether > we really need to include OpenGL support inside HP or not. > > I grant that it may be convenient for users who might find it > hard to build OpenGL and GLUT with cabal-install; on the other hand > not that many haskell packages actually need those libraries AFAICT > so I am still not convinced that they really belong in HP. > Let's look at some numbers: http://www.galois.com/~dons/hackage/march-2011/mar-10-to-feb-11.txt <http://www.galois.com/~dons/hackage/march-2011/mar-10-to-feb-11.txt>Search for opengl and you'll see that it's in the top 25, meaning it's used by a relatively high number of packages. That means we're discussing a library that provides a unique capability (opengl support) that is in the top 25 of the Haskell libraries. Not making it easy to get seems like a bit of a strategic error to me. The reverse package index shows what depends on it: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/OpenGL… And some things depend on the raw bindings instead: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/OpenGL… Additionally, I've had 1 person contact me off list saying that they wouldn't even be a Haskell programmer if the opengl bindings were not in the HP. If there had been any barrier to getting good opengl support when they started learning Haskell that would have been a show stopper for them. Jason

1 1

Re: [HOpenGL] How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 18 Apr '11

18 Apr '11

On Sun, Apr 17, 2011 at 10:51 AM, Joachim Breitner <mail(a)joachim-breitner.de > wrote: > Hi, > > Am Sonntag, den 17.04.2011, 14:37 -0300 schrieb Felipe Almeida Lessa: > > On Sun, Apr 17, 2011 at 12:53 PM, Joachim Breitner > > <mail(a)joachim-breitner.de> wrote: > > > work of 1 module in 10 packages. The new OpenGL packages have split out > > > lots of small packages (OpenGLRaw, StateVar, Tensor, ObjectName). > Please > > > review this and see if you can somehow lessen the package number > > > inflation before your version enters the platform. > > > > At least StateVar is very useful outside OpenGL. > > I’m not saying it is not useful. But there is very little code and most > of it is rather, well, trivial. So if you need the functionality in one > of your packages only, then you can put it there. If you need it in on > collection of multiple packages with one package dominating the > dependency tree, then put it there. > > A package of its own for these few lines is only required if > * Package A and package B provide an _interface_ in terms of StateVar > * Neither A depends on B nor B depends on A > * There will be a package C that not only uses the interface of both A > and B but also combines them, e.g. really requires that the same type is > used in both the interfaces. > > Also, small packages without external dependencies can be combined in > one package without much loss. E.g. a package opengl-utils (or some > better name) that provides all of StateVar, Tensor, ObjectName would do > the job equally well. > > I know that its tempting to have very fine-grained Cabal packages, > because its so cheap to put them on Hackage and leave it to > cabal-install to install take care of them. Unfortunately, it doesn’t > scale on the Distribution side very well – and we are already trying > hard to keep the per-package maintenance cost down. > In this specific case, I'll do what I can to clean things up but your request makes me pause and think that the debian packaging for cabal packages is not automated enough. As haskell developers it seems a little odd to me that we need to consider the cost of creating new packages for the sake of debian. I like debian, so please don't take that the wrong way :) Thanks for your input! Jason

1 0

Re: [HOpenGL] How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 18 Apr '11

18 Apr '11

On Sun, Apr 17, 2011 at 10:43 AM, Don Stewart <dons00(a)gmail.com> wrote: > It would need to be proposed to join the HP standard library set -- at > the moment, it has no other users, and a surprising top level name. > The top level name for StateVar is Data.StateVar. It is a pretty general api that has some handy uses. The best parts being, turning Ptrs into something that behaves like an IORef and splitting read and write capabilities. > > My proposal would be to move those packages under the Graphics.* > namespace, and, optionally, merge (some) of them back into OpenGL, to > reduce maintainance burden. I don't buy the argument that the StateVar > interface should be widely exposed and encouraged. > Where it's useful is that it provides an api that unifies access to IORefs and Ptrs and it separates read/write capabilities. For something like the opengl package that exposes the OpenGL state machine via Ptrs and higher level state via IORefs this makes some sense as a way to hide implementation details and provide a more haskell-friendly api. Outside of Haskell bindings for stateful C apis, it's probably not that useful. Due to how it's implemented (IORefs, Ptr and Storable), I think this is something that should possibly be in an FFI related module, if it were to live separate from the opengl package. It does get used for opengl, openal, himpunk and a few other things so I can see why Sven separated it from OpenGL: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/StateV… My main goal though is to balance the concerns people have so that we can move forward using it and bundling it with the HP. If being a top level name (Data.StateVar) means people don't want it in the platform then I'm happy to compromise on that. Graphics.StateVar is fine with me in that sense of compromise for opengl, but then it will look kind of funny when OpenAL imports something from the graphics hierarchy just to get access to its state variables. So for that reason, I would prefer a name like, Foreign.State or Foreign.StateVar. Would that be acceptable? Which parts of the module name space can I use for something like this? Suggestions? Jason

1 0

Re: [HOpenGL] How to contact OpenGL package maintainer (where is Sven?)
by Felipe Almeida Lessa 18 Apr '11

18 Apr '11

On Sun, Apr 17, 2011 at 12:53 PM, Joachim Breitner <mail(a)joachim-breitner.de> wrote: > work of 1 module in 10 packages. The new OpenGL packages have split out > lots of small packages (OpenGLRaw, StateVar, Tensor, ObjectName). Please > review this and see if you can somehow lessen the package number > inflation before your version enters the platform. At least StateVar is very useful outside OpenGL. Thanks, -- Felipe.

1 0

Re: [HOpenGL] How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 07 Apr '11

07 Apr '11

On Wed, Apr 6, 2011 at 2:51 PM, Don Stewart <dons00(a)gmail.com> wrote: > Taking the discussion back to the libraries@ list. > > The OpenGL packages weren't updated, as they added new dependent > packages using funny parts of the top level namespace. In particular, > StateVar took "Data.StateVar" -- which isn't necessarily something the > HP wants to push on beginner Haskellers. > > Moving those modules under OpenGL.*.*.StateVar etc would remove the > problems with upgrading to the HP. > Yup, that sounds super easy. I'll add it to the list I'm making. Thanks for clarifying that! Jason

1 0

Re: [HOpenGL] How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 07 Apr '11

07 Apr '11

On Wed, Apr 6, 2011 at 2:35 PM, Don Stewart <dons00(a)gmail.com> wrote: > Note, there are some issues, as this is a package in the Haskell > Platform, to do with upgrading and dependent packages. We should talk > first about issues there. > An older version is in the HP, but Johan pointed out to me in a private email that the latest version is not in the HP. Here are the results of my research into that: I'm not finding much in the way of reasons why the *Raw packages were not added or why OpenGL/GLUT were not updated. There are these: http://trac.haskell.org/haskell-platform/ticket/157 http://trac.haskell.org/haskell-platform/ticket/158 That's a request for the latest version of GLUT and OpenGL. I found those via the archives but the threads are empty and no comments on the tickets. Magnus created those tickets as a result of this thread, I believe: http://projects.haskell.org/pipermail/haskell-platform/2011-February/001401… Is that the thread in your memory? Perhaps it was this one? http://www.haskell.org/pipermail/libraries/2009-June/011920.html That one turned into a discussion of the module system. I added a proposal to add OpenGLRaw, but no one commented on it: http://projects.haskell.org/pipermail/haskell-platform/2011-March/001506.ht… Based on that, it seems that Magnus wants the packages updated, and I'd like to see the *Raw packages added to the platform. I don't see any dissenting public opinions on the libraries list or on the trac, other than tickets #57 and #58 that make a case for removing OpenGL and GLUT entirely from the platform. Tickets #57 and #58 seem to be old though. If you have more information or I overlooked something, please let me know :) Thanks, Jason > On Wed, Apr 6, 2011 at 2:32 PM, Jason Dagit <dagitj(a)gmail.com> wrote: > > No response yet from Sven after about a month and no one seems to have > heard > > from him in over a year. > > > > I'm going to take over for now under the assumption that Sven is missing. > > == My plans for moving forward == > > * Assemble an opengl taskforce, a few people have already mentioned an > > interest in being on the team > > * clean up the current cabal files (I already wrote patches for that) > > * put the repos on github to make team collaboration easier > > * add the RULES that Andy Gill suggested for realToFrac > > * look at adding instances for MArray so that GLfloat et al can be > stored > > in IOUArrays > > * add support for opengl 4.x > > * look at adding deprecation pragmas for deprecated opengl calls > > * new hackage releases > > * anything else that comes up > > Thanks, > > Jason > > > > On Sun, Mar 27, 2011 at 2:11 PM, Jason Dagit <dagitj(a)gmail.com> wrote: > >> > >> I sent the message below to Haskell-Cafe about a week ago. I got one > >> response saying that Sven has disappeared in the past but reappeared > when > >> updates were necessary. I still haven't heard from Sven. Now I'm > widening > >> my search. My original email to Sven was on March 11th. > >> It looks like the OpenGL packages on hackage[1,2,3,4] have not been > >> updated in some time. No updates later than Oct 2009. I tried to email > >> Sven directly using the email address listed on hackage but after over > two > >> weeks I still haven't heard from him. I sent some patches to > >> the opengl list about a week ago but I noticed that Sven hasn't posted > on > >> that list since Oct 2009 when he released the current version of > OpenGLRaw. > >> None of the public darcs repos have patches newer than Oct 2009. Also, > the > >> homepage url listed in the packages is a 404: > >> http://www.haskell.org/HOpenGL/ > >> My concern is that Sven has disappeared for some reason. I hope he's > >> well. He has always done top notch work in the past maintaining these > >> libraries. Perhaps he's simply busy or lost interest? > >> Does anyone know if he was looking for a new maintainer? Perhaps you've > >> heard from him more recently than Oct 2009? > >> If a new maintainer is needed, I would consider nominating myself :) > >> Thanks, > >> Jason > >> [1] http://hackage.haskell.org/package/OpenGLRaw > >> [2] http://hackage.haskell.org/package/OpenGL > >> [3] http://hackage.haskell.org/package/GLURaw > >> [4] http://hackage.haskell.org/package/GLUT > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > >

1 0

How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 07 Apr '11

07 Apr '11

I sent the message below to Haskell-Cafe about a week ago. I got one response saying that Sven has disappeared in the past but reappeared when updates were necessary. I still haven't heard from Sven. Now I'm widening my search. My original email to Sven was on March 11th. It looks like the OpenGL packages on hackage[1,2,3,4] have not been updated in some time. No updates later than Oct 2009. I tried to email Sven directly using the email address listed on hackage but after over two weeks I still haven't heard from him. I sent some patches to the opengl list about a week ago but I noticed that Sven hasn't posted on that list since Oct 2009 when he released the current version of OpenGLRaw. None of the public darcs repos have patches newer than Oct 2009. Also, the homepage url listed in the packages is a 404: http://www.haskell.org/HOpenGL/ My concern is that Sven has disappeared for some reason. I hope he's well. He has always done top notch work in the past maintaining these libraries. Perhaps he's simply busy or lost interest? Does anyone know if he was looking for a new maintainer? Perhaps you've heard from him more recently than Oct 2009? If a new maintainer is needed, I would consider nominating myself :) Thanks, Jason [1] http://hackage.haskell.org/package/OpenGLRaw [2] http://hackage.haskell.org/package/OpenGL [3] http://hackage.haskell.org/package/GLURaw [4] http://hackage.haskell.org/package/GLUT

1 1