GLFW, OpenGL 2.3.0.0

[paul at theV.net]

Ok, I've made two more patches, please take a look.
If things look ok, I'll bump the version to 0.4.1
and release it to HackageDB. Thanks a lot!

Regards,
Paul Liu

On Wed, Aug 12, 2009 at 08:30:03AM -0400, paul at theV.net wrote:
> Hi Brian,
> 
> I think the priority now is to release a version that fixes
> the OpenGL compatibility thing ASAP. Otherwise it'll just stay
> broken for those who upgraded.
> 
> So I'm going ahead to prepare a release. I'll ask you to take
> a quick look before rolling it out just to make sure I don't
> do anything stupid at the last moment.
> 
> Regards,
> Paul Liu
> 
> On Tue, Aug 04, 2009 at 11:58:27PM -0500, Brian Lewis wrote:
> > On Sunday, 02.08.09 at 09:01, paul at theV.net wrote:
> > > I've committed a change to make it work with both older and new
> > > versions of OpenGL.
> > 
> > OK, cool.
> > 
> > > The issue of changing to C types makes me thinking whether we should
> > > do it too at the cost of losing compatibility with 0.3. But then I
> > > still prefer standard types such as Int for GLFW's API.
> > 
> > Well, Sven seems to be very careful to do the correct thing, so I'm
> > inclined to do it his way.
> > 
> > I think we're going to have to break compatibility with 0.3 sooner or
> > later anyway, so we might go ahead and do it in a big way.
> > 
> > I read the Haskell versioning policy to read that we're required to have
> > at least 3 numbers in our version, like a.b.c, where 'a' is the major
> > version, etc.
> > 
> > Sven has split StateVar into its own package. Is using StateVars in GLFW
> > really helping? It seems to me we could simplify the interface a lot by
> > not requiring that additional step.
> > 
> > I think we can get rid of a lot of FFI clutter by using c2hs. The author
> > of GLFW does not seem interested in accepting certain kinds of patches,
> > so I think we should develop our own small patch to help c2hs do more
> > useful work for us. The patch would do stuff like place existing GLFW
> > #defines into enums.
> > 
> > I would also like to make sure our function bindings and Haddock
> > comments are ordered like the GLFW reference manual.
> > 
> > We also discussed previously figuring out some way to make cabal compile
> > the C part with optimization.
> > 
> > Sorry, that's just a bunch of stuff that occurred to me off the top of
> > my head.