GHC status report

[Dominick Samperi]

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.colpitts at 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 <marlowsd at 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
>>> <simonpj at microsoft.com <mailto:simonpj at 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 at haskell.org <mailto:ghc-devs at haskell.org>
>>>     http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>