[HOpenGL] New programmer => some comments/suggestions

[Jason Dagit]

On Sat, Apr 30, 2011 at 12:50 PM, L Corbijn <aspergesoepje at gmail.com> wrote:

> Hi everyone,
>
> I was wondering if anyone is working on improving the OpenGL package.


Yes.  Alexander Göransson is doing a google summer of code project[1] with
that specific goal.  I'll be mentoring him.  I've asked him to post his
proposal to the list but I think he's a bit busy with his uni courses at the
moment.  Hopefully soon.


> As the git repository [1] on github looks rather quiet,


The one you linked to is my personal branch.  In general, I think you want
this one:
https://github.com/haskell-opengl/OpenGL

I created the haskell-opengl organization on github specifically for
managing the haskell opengl repositories.  I think that StateVar, tensor,
and possibly some other repos are missing still.  I've been adding things
lazily.

I've been kind of busy in my work/personal life lately so I haven't done
much yet other than getting things up on github.  I would like to do a
release soon with some of the old patches that are floating around.  Just
performance fixes mostly.  Then start looking at some of the more
experimental stuff.  I've created issues on github.  Feel free to assign
them to yourself or send me pull requests if you've been working on that
stuff.

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.
>

No worries.  I would recommend reading, "Producing Open Source Software" by
Karl Fogel, available online for free[2].


>
> 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.
>

Thanks for the feedback.  I'll think about it.  I don't personally see the
current code layout as an issue but I also don't want the code to be
unnecessarily messy.  Changing the high level module names, the ones people
import, is problematic but I assume that at the end of the summer we'll be
able to release Alexander's work as OpenGL 3.0 and we'll just warn people
ahead of time that it's going to be a big compatibility breaker compared to
OpenGL 2.4.  That means we need to release any bug fixes we make along the
way in the current 2.4.x series or else suffer the wrath of people who use
the current API.


> 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).


Could you give an example where you needed to debug something?  I don't
think I understand what you're saying.  I will say, I find OpenGLRaw much
easier to use as the names and types match the OpenGL API really well.  It's
a bit harder for beginners though as it requires more familiarity with the
FFI.


> And if the future brings better auto-complete for Haskell it might lead to
> better suggestions (all the unused stuff out).
>

You might try leksah[3] or eclipsefp[4] if you want wizzbang IDE style
features.  I get by with just emacs/vim plus find/grep/ack, but I might be a
bit old school.  Hoogle integration in my editor would be pretty nice
though.

Jason

[1] http://www.haskell.org/pipermail/hopengl/2011-April/001010.html
[2] http://producingoss.com/
[3] http://www.leksah.org/
[4] http://eclipsefp.sourceforge.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/hopengl/attachments/20110430/280feba9/attachment.htm>