The problem with some graphics libraries used via FFI (and other libraries that are not thread-safe), if I understand the situation correctly, is that ghci forks a thread when it shouldn't, causing some programs to miscalculate the available stack space (because they think there is only one thread).
The new dynamic linking support and the flag -fno-ghci-sandbox fixes this problem, and I would not vote for the removal of these features. It is not clear to me from Simon's original post how linking to all of those C++ libs can continue to work if dynamic linking is removed in 7.10? Perhaps I misunderstand what you mean by "revert to static linking"? Thanks, Dominick On Wed, Apr 30, 2014 at 9:26 PM, George Colpitts <george.colpi...@gmail.com> wrote: > To elaborate, in the past, I had a lot of problems using libraries from the > ghci prompt on the Mac but I haven't tried recently. > > As an example, on the web page for the book the Haskell School of Expression > it says: > > Note for OS X users: running graphics applications from GHCi is no longer > supported. Instead, one has to compile a graphics program using GHC in order > to run it (see example/GMIExamples.lhs for an example). > > I had similar problems using the Yale Euterpea music program from ghci. When > I inquired I was referred to https://ghc.haskell.org/trac/ghc/ticket/4244 > and https://ghc.haskell.org/trac/ghc/ticket/781. I see that the latter is > now scheduled for 7.10.1 > > > On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow <marlo...@gmail.com> wrote: >> >> On 30/04/2014 01:35, George Colpitts wrote: >>> >>> It doesn't have anything about the dynamic linking changes made for 7.8. >>> I think it's worth mentioning the improvements we expect to get from >>> that. The highlights of the release notes do mention it, so maybe that >>> suffices. >>> >>> In particular, I'm hoping that it is going to fix a lot of problems with >>> using foreign libraries such as OpenGL from ghci. I could be wrong about >>> that though. >> >> >> I'd like to understand more about what those problems are. As a data >> point, at Facebook we're using static linking (I compiled GHC with >> DYNAMIC_GHC_PROGRAMS=NO), we're loading upwards of 50 3rd-party C++ >> libraries and one gigantic shared library consisting of a ton of in-house >> C++ code, together with all our Haskell code into GHCi, and it works >> perfectly. The key to using the static linker is to not use it for C++ code >> - you want all your external C++ code in shared libraries and load those >> using the system linker. >> >> Dynamic linking has been a huge headache in GHC, and it's not clear that >> it's an overall improvement compared with the static linker. Now that 7.8 >> is out of the way, it's time to have a conversation about whether we want to >> do dynamic linking again for 7.10, or revert to static linking. I think >> Austin is going to update >> https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms, and then we'll see >> where we stand. >> >> Cheers, >> Simon >> >> >> >>> >>> On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones >>> <simo...@microsoft.com <mailto:simo...@microsoft.com>> wrote: >>> >>> As Austin has told us, there's a draft of the *GHC Status Report for >>> the HCAR*, here:____ >>> >>> https://ghc.haskell.org/trac/ghc/wiki/Status/May14____ >>> >>> >>> Have we missed out something you have been working hard on? Do >>> take a moment to add a bullet in an appropriate place (it's a >>> wiki). I'd like to be sure that we are giving credit to all the >>> appropriate people, so please help us fix that too. GHC is a team >>> effort.____ >>> >>> Deadline is 1 May I think.____ >>> >>> Thanks____ >>> >>> Simon____ >>> >>> __ __ >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
