I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald wrote:

Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too.

I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check)

At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before.

On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:

...

Dear GHC devs

See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.)

Thanks

Simon

-----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal,

I wasn't able to make it to last Saturday's FARM track, but I think

there was a good chance that Paul would have demonstrated his Euterpea

music library, which includes a GUI interface (called MUI) written on

top of GLFW. I wrote its initial implementation (around 2009?) with a

monadic interface that let you wire together UI components with

signals (I believe Dan later wrote an arrow interface, but I could be

wrong). It was actually inspired by the ideas behind your Phooey UI

library. It should be very easy to extract this part out as a

standalone package if there is enough interest.

The only issue with it (and all other UI libraries) is that it doesn't

play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4

on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke

Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this

problem.

BTW, as also the author of the GLFW library on HackageDB, I've done

barely minimal to keep this Haskell binding afloat. I'm actually

leaning towards GLFW-b library, which is better maintained, and

provides similar binding for GLFW C library but with a saner interface

(no dependency on the OpenGL library, for example). If you don't need

the two extra things that GLFW does (choice of either dynamic or

static linking to GLFW C, and an embedded bitmap font), I suggest you

try out GLFW-b if you are only looking for a think graphics layer with

input+window+OpenGL.

The only thing keeping GLFW-b from becoming a good foundation for a

pure Haskell UI lib is IMHO the lack of a light-weight,

cross-platform, and full-featured font rendering solution. I believe

many other libraries (including Diagram) are having the same problem.

On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott wrote:

...

I'm polling to see whether there are will and expertise to reboot graphics

...

and GUIs work in Haskell. I miss working on functional graphics and GUIs in

...

Haskell, as I've been blocked for several years (eight?) due to the absence

...

of low-level foundation libraries having the following properties:

...

...

* cross-platform,

...

* easily buildable,

...

* GHCi-friendly, and

...

* OpenGL-compatible.

...

...

The last several times I tried Gtk2hs, I was unable to compile it on my Mac.

...

Years ago when I was able to compile, the GUIs looked and interacted like a

...

Linux app, which made them awkward and upleasant to use. wxHaskell (whose

...

API and visual appearance I prefered) has for years been incompatible with

...

GHCi, in that the second time I open a top-level window, the host process

...

(GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners,

...

and I tend to experiment a lot, using a full compilation greatly thwarts my

...

flow. For many years, I've thought that the situation would eventually

...

improve, since I'm far from the only person who wants GUIs or graphics from

...

Haskell.

...

...

About three years ago, I built a modern replacement of my old Pan and

...

V

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Paul Liu

Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald wrote:

thats the linker bug.

the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing).

the historical element doesn't matter any more.

To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD.

the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology.

anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked.

tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD.

thanks -Carter

On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote:

...

I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread:

http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html

I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem.

Regards, Paul Liu

On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald wrote:

...

Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too.

I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check)

At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before.

On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:

...

Dear GHC devs

See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.)

Thanks

Simon

-----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal,

I wasn't able to make it to last Saturday's FARM track, but I think

there was a good chance that Paul would have demonstrated his Euterpea

music library, which includes a GUI interface (called MUI) written on

top of GLFW. I wrote its initial implementation (around 2009?) with a

monadic interface that let you wire together UI components with

signals (I believe Dan later wrote an arrow interface, but I could be

wrong). It was actually inspired by the ideas behind your Phooey UI

library. It should be very easy to extract this part out as a

standalone package if there is enough interest.

The only issue with it (and all other UI libraries) is that it doesn't

play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4

on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke

Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this

problem.

BTW, as also the author of the GLFW library on HackageDB, I've done

barely minimal to keep this Haskell binding afloat. I'm actually

leaning towards GLFW-b library, which is better maintained, and

provides similar binding for GLFW C library but with a saner interface

(no dependency on the OpenGL library, for example). If you don't need

the two extra things that GLFW does (choice of either dynamic or

static linking to GLFW C, and an embedded bitmap font), I suggest you

try out GLFW-b if you are only looking for a think graphics layer with

input+window+OpenGL.

The only thing keeping GLFW-b from becoming a good foundation for a

pure Haskell UI lib is IMHO the lack of a light-weight,

cross-platform, and full-featured font rendering solution. I believe

many other libraries (including Diagram) are having the same problem.

On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott wrote:

...

I'm polling to see whether there are will and expertise to reboot graphics

...

and GUIs work in Haskell. I miss working on functional graphics and GUIs in

...

Haskell, as I've been blocked for several years (eight?) due to the absence

...

of low-level foundation libraries having the following properties:

...

...

* cross-platform,

...

* easily buildable,

...

* GHCi-friendly, and

...

* OpenGL-compatible.

...

...

The last several times I tried Gtk2hs, I was unable to compile it on my Mac.

...

Years ago when I was able to compile, the GUIs looked and interacted like a

...

Linux app, which made them awkward and upleasant to use. wxHaskell (whose

...

API and visual appearance I prefered) has for years been incompatible with

...

GHCi, in that the second time I open a top-level window, the host process

...

(GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners,

...

and I tend to experiment a lot, using a full compilation greatly thwarts my

...

flow. For many years, I've thought that the situation would eventually

...

improve, since I'm far from the only person who wants GUIs or graphics from

...

Haskell.

...

...

About three years ago, I built a modern replacement of my old Pan and

...

V

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Paul Liu

-- Regards, Paul Liu

Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu wrote:

Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8!

...

thats the linker bug.

the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing).

the historical element doesn't matter any more.

To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD.

the better this issue is properly tested (which i believe it has been),

...

more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology.

anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked.

tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD.

thanks -Carter

On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote:

...

I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread:

http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html

I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem.

Regards, Paul Liu

On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald wrote:

...

Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI

bindings

...

...

when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too.

I believe a number of folks in #haskell-game have recently tested

On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald wrote: the point

...

...

...

one. (Though I should ask to double check)

At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before.

On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:

...

Dear GHC devs

See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again?

(I’m

...

guessing that the latter might be hard.)

Thanks

Simon

-----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal,

I wasn't able to make it to last Saturday's FARM track, but I think

there was a good chance that Paul would have demonstrated his Euterpea

music library, which includes a GUI interface (called MUI) written on

top of GLFW. I wrote its initial implementation (around 2009?) with a

monadic interface that let you wire together UI components with

signals (I believe Dan later wrote an arrow interface, but I could be

wrong). It was actually inspired by the ideas behind your Phooey UI

library. It should be very easy to extract this part out as a

standalone package if there is enough interest.

The only issue with it (and all other UI libraries) is that it doesn't

play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4

on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke

Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this

problem.

BTW, as also the author of the GLFW library on HackageDB, I've done

barely minimal to keep this Haskell binding afloat. I'm actually

leaning towards GLFW-b library, which is better maintained, and

provides similar binding for GLFW C library but with a saner interface

(no dependency on the OpenGL library, for example). If you don't need

the two extra things that GLFW does (choice of either dynamic or

static linking to GLFW C, and an embedded bitmap font), I suggest you

try out GLFW-b if you are only looking for a think graphics layer with

input+window+OpenGL.

The only thing keeping GLFW-b from becoming a good foundation for a

pure Haskell UI lib is IMHO the lack of a light-weight,

cross-platform, and full-featured font rendering solution. I believe

many other libraries (including Diagram) are having the same problem.

On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott wrote:

...

I'm polling to see whether there are will and expertise to reboot graphics

...

and GUIs work in Haskell. I miss working on functional graphics and GUIs in

...

Haskell, as I've been blocked for several years (eight?) due to the absence

...

of low-level foundation libraries having the following properties:

...

...

* cross-platform,

...

* easily buildable,

...

* GHCi-friendly, and

...

* OpenGL-compatible.

...

...

The last several times I tried Gtk2hs, I was unable to compile it on my Mac.

...

Years ago when I was able to compile, the GUIs looked and interacted like a

...

Linux app, which made them awkward and upleasant to use. wxHaskell (whose

...

API and visual appearance I prefered) has for years been incompatible with

...

GHCi, in that the second time I open a top-level window, the host process

...

(GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners,

...

and I tend to experiment a lot, using a full compilation greatly thwarts my

...

flow. For many years, I've thought that the situation would eventually

...

improve, since I'm far from the only person who wants GUIs or graphics from

...

Haskell.

...

...

About three years ago, I built a modern replacement of my old Pan and

...

V

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Paul Liu

-- Regards, Paul Liu _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

2013/10/1 Carter Schonwald :

[...] to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. [...]

I don't have spare cycles left to do the building + testing for myself, so I'd like to turn this around: Is there any test coverage regarding the upcoming GHC 7.8 and the libraries in the Haskell Platform? I'm thinking especially about the examples in https://github.com/haskell-opengl/GLUT/tree/master/examples (especially RedBook8/Chapter01). Building alone is not enough, one has to test this manually. :-/ Avoiding any unpleasant surprises would be nice. Some nightly builds of the upcoming 7.8 *plus* the HP for several platforms would really help here. Do we have such a thing? Regarding -fno-ghci-sandbox: I never needed to use that flag, even with the GLUT examples in GHCi. When exactly should this be necessary?