[HOpenGL] New programmer => some comments/suggestions

[L Corbijn]

On Sun, May 1, 2011 at 6:55 AM, Jason Dagit <dagitj at gmail.com> wrote:

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

Could you give me a link to the page where those issues are (there is only
one issue on https://github.com/haskell-opengl/OpenGL/issues).


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

Thanks, the only thing I need now is time to read it ;).


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

Of course that is something we should look out for, maybe it is possible to
make some changes and then later remove/move the deprecated stuff. About the
messiness, I find the query utils not very nice, 400 names in a single type.
Might it not be a better idea to group those per 'subject', say one for the
shaders, one for texturing, etc. and create a typeclass PName? The other
thing is that the deprecated stuff should be all implemented, stable and be
subject to many new updates in the spec. Therefore while developing I don't
need to see the stuff and it only clutters my view (in the files, as well as
when viewing folders).


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

Some examples. While 'updating' my knowledge from GL < 3.0 to 3.0 (not using
haskell) I liked to use the hands on approach, combining reading and
testing. Though without going in the spec back then it was very hard to find
out why some functions gave an error as the errors are not always that
descriptive, furthermore it costs some time to identify which function is
the problem (especially without debug points as in java ...).
Second example, say for some project it is decided that for say technical
constraint (e.g. my graphics card doesn't support GL 4+) a certain GL
context is used, though the people coding would probably know and read more
about OpenGL and the functions it's API provides. So it's not inconceivable
that someone uses a function that is not in the spec for that certain
context. In the best scenario OpenGL creates an error, though it might as
well not generate an error and the code could become part of the project.
In both cases importing the functions for a specific version of OpenGL would
lead to a compile error when you try to use an unsupported function, costing
less time to find the bug.


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

I'm currently using a combination of gedit (with syntax highlighting) and
leksah. What I tried to say was that if the support autocompletion and
prediction based on the imports you use (which leksah doesn't (yet))
importing only a part of the needed functions these functionalities wouldn't
suggest the functions you don't care about.

L Corbijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/hopengl/attachments/20110501/9f64e11a/attachment.htm>