GLFW 0.4 release

[paul at theV.net]

Hi Brian,

Thanks a lot for the update! Please see my replies below.

On Sun, Jun 07, 2009 at 07:57:38AM -0500, Brian Lewis wrote:
> I originally sent this to glfw at projects.haskell.org, but it got
> returned:
>   <glfw at projects.haskell.org>:
>   72.249.126.23 does not like recipient.
>   Remote host said: 550 Unrouteable address
>   Giving up on 72.249.126.23.
> 
> I pushed some changes. Please pull and review them.
> 
> I plan to add some simple tests soon.

Thanks for doing it! Do you plan to do it with quickcheck? 
I've never used it, but will learn by your examples.

> I added conditional compilation directives so that users of GHC 6.10 and
> above don't have to pay for the workaround for the 64-bit FFI bug. But
> is 6.10 really the first version without the bug? Also, is there more
> workaround code?

I'll do some testing on my end to make sure our code works
for both 6.8.3 and 6.10 for 64-bit systems.
 
> I think we can eliminate a lot of repetitive code by using c2hs,
> particularly its 'enum' directive. See
> http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/implementing.html#id314717
> . GLFW's glfw.h does not currently group its defines into enums, but I
> talked to the maintainer briefly on IRC and submitted a patch today that
> he should not find objectionable. See
> http://sourceforge.net/tracker/?func=detail&aid=2802428&group_id=72569&atid=534940
> .

This is great, but I think we can hold it until next release, or
until GLFW's maintainer accepts your patch.

> It's hard for me to see how much of the original GLFW API is covered.
> Maybe we can break GLFW.hs into smaller files by section, and/or follow
> the order in the GLFW reference manual more closely?

I usually avoid small modules because they are scattered, at least 
in the case of generated documentations. 
 
> When I compile GLFW (the C library), its Makefile sets preprocessor
> flags like _GLFW_HAS_SYSCONF, _GLFW_HAS_DLOPEN, etc., and optimizes with
> -Os. Is anything like this happening in our GLFW? I don't see how it can
> be.

For the moment we are not doing any of this. Frankly I don't know
if cabal is powerful enough to do some of the checks. We can work
around this problem by having cabal invoke autoconf, but this takes
quite some effort. Right now we have the option to link to GLFW
dynamic libraries on Linux, so if people are really concerned they
can use this flag.

Now that I come to think of it, os(linux) doesn't work for BSDs,
maybe we shall change the order to os(darwin), os(win32), and then 
everything else without checking if its linux/bsd/others.

Regards,
Paul Liu