GHC status report

Thu May 1 21:27:00 UTC 2014

On 01/05/14 14:48, Dominick Samperi wrote:
> 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.

So I understand how -fno-ghci-sandbox avoids problems with GUI libraries 
that use thread-local state.  But how is dynamic linking involved here? 
  What improved in GHC 7.8 relative to 7.6 for you? And could you 
clarify "miscalculate the available stack space"? What needs to 
calculate stack space? Why? C stack space?

We can certainly make a smoother experience around -fno-ghci-sandbox for 
using GUI libraries.

> 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"?

When I say "revert to static linking" I mean make GHCi static linked, 
and have it load Haskell code compiled for static linking using the RTS 
linker (like it did in 7.6).  Foreign libraries would still be loaded 
using the system linker, as they always have been.

To be clear, I'm not officially proposing that we drop dynamic linking, 
but I think it's worthwhile exploring the design space again, given that 
we know dynamic linking has been tougher than we expected.

Cheers,
Simon

> 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
>>