Re: GHC status report
On 2014-05-01, at 23:46, Edward Kmett ekm...@gmail.com wrote: With the old custom linker we weren't able to get our custom MPFR linked in properly on all platforms for use in ghci. On Macs we ran into some rather interesting problems. We could get it to work for actual executables, but ghci would segfault with stuff resolved to clearly wrong addresses. If I recall correctly it may have been some kind of MachO symbol type that wasn't being resolved properly by the custom GHC linker, perhaps? We chased after it off and on for a long time to no avail. Did these segfaults look like the following GHCi 7.6.3 crash? https://ghc.haskell.org/trac/ghc/ticket/9278 It looks like Jason ran into something similar last year: https://gist.github.com/dagit/5986541 Unfortunately, while the new linker in GHCi 7.8.2 doesn’t suffer from this problem, there appears to be another issue: https://ghc.haskell.org/trac/ghc/ticket/9277 Any clues? Thanks, -- Miëtek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
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.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
Re: GHC status report
. 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
Re: GHC status report
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.colpi...@gmail.com mailto: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 mailto: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 mailto: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
Re: GHC status report
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
Re: GHC status report
: 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 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 mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto: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 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 mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman
Re: GHC status report
. 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 https://ghc.haskell.org/trac/__ghc/wiki/DynamicGhcPrograms https://ghc.haskell.org/trac/__ghc/wiki/DynamicGhcPrograms 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 mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com__ mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto: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 https://ghc.haskell.org/trac/__ghc/wiki/Status/May14 https://ghc.haskell.org/trac/__ghc/wiki/Status/May14 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
Re: GHC status report
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
Re: GHC status report
...@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 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 mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | | | | | _ | ghc-devs mailing list | ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
many un-anticipated costs and it is still very far from sorted out. It originally felt like a Fantastic Idea to give up our own linker and adopt the system linker, but it now feels to me like a black hole, endlessly sucking effort and increasing complexity. My viewpoint is highly un-informed about details; I just watch the traffic going by. And of course it does have benefits that doubtless generate less traffic. Simon | | | | | On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones | simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto: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 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 mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | | | | | _ | ghc-devs mailing list | ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
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
Re: GHC status report
whether we | want to do dynamic linking again for 7.10, or revert to static linking. I echo this. Dynamic linking has had many un-anticipated costs and it is still very far from sorted out. It originally felt like a Fantastic Idea to give up our own linker and adopt the system linker, but it now feels to me like a black hole, endlessly sucking effort and increasing complexity. My viewpoint is highly un-informed about details; I just watch the traffic going by. And of course it does have benefits that doubtless generate less traffic. Simon | | | | | On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones | simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto: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 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 mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | | | | | _ | ghc-devs mailing list | ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
On Fri, May 2, 2014 at 10:19 AM, Edward Kmett ekm...@gmail.com wrote: I may have to dig to find an example, but when I last checked it seemed that c++ libraries would load fine, but there was a problem with static initializers not getting called, when loading from ghci, so if your c++ library needed them then you'd have problems. This has been a longstanding problem, but was reported closed in https://ghc.haskell.org/trac/ghc/ticket/5435 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
, -dynamic-too seems to cause me all sorts of problems elsewhere. ^C'ing out of a build and restarting it will often make a .o but lose the .dyn_o, leading to GHC + cabal getting confused and refusing to build until I clean. This hits me several times a day. We should fix this (or at least make it a lot less likely). Is there a ticket? Cheers, Simon -Edward On Thu, May 1, 2014 at 3:29 AM, Simon Peyton Jones simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com__ wrote: | 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 echo this. Dynamic linking has had many un-anticipated costs and it is still very far from sorted out. It originally felt like a Fantastic Idea to give up our own linker and adopt the system linker, but it now feels to me like a black hole, endlessly sucking effort and increasing complexity. My viewpoint is highly un-informed about details; I just watch the traffic going by. And of course it does have benefits that doubtless generate less traffic. Simon | | | | | On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones | simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto: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 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 mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
. 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
Re: GHC status report
On 02/05/2014 01:09, Dominick Samperi wrote: If I understand your last comment correctly linking to libR should continue to work, even if you revert to static linking of Haskell compiled code via RTS linker. Since you say this is the way things have always been, perhaps the real explanation for why 7.8 fixed the issue is that some bug was fixed along the way... Indeed. To know for sure we would have to test 7.8 with DYNAMIC_GHC_PROGRAMS=NO with your setup - is there a way to do that? Cheers, Simon Note that R is a C library, so the C++ issues that Carter mentions are not a factor here. Thanks, Dominick On Thu, May 1, 2014 at 5:27 PM, Simon Marlow marlo...@gmail.com wrote: 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.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
Re: GHC status report
...@microsoft.com mailto:simo...@microsoft.com mailto:simo...@microsoft.com mailto: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 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 mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | | | | | _ | ghc-devs mailing list | ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs | _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHC status report
| 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 echo this. Dynamic linking has had many un-anticipated costs and it is still very far from sorted out. It originally felt like a Fantastic Idea to give up our own linker and adopt the system linker, but it now feels to me like a black hole, endlessly sucking effort and increasing complexity. My viewpoint is highly un-informed about details; I just watch the traffic going by. And of course it does have benefits that doubtless generate less traffic. 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
Re: GHC status report
On 01/05/2014 02:26, George Colpitts 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 http://www.cs.yale.edu/homes/hudak/SOE/software1.htm 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 I think we just punted on all the problems and assumed that dynamic linking would fix everything. What we've found is that dynamic linking causes a whole new set of problems and complexities. Meanwhile, many of the original problems have been fixed (except #781, which is kind of unfixable, but fortunately is also quite rare). Unfortunately dynamic linking is needed to support GHCi and TH on unregisterised platforms. In 7.8, GHCi and TH now works on some platforms where it didn't before (albeit not very widely used platforms). Cheers, Simon On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow marlo...@gmail.com mailto: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 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 mailto: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 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 mailto:ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
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.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
Re: GHC status report
On Thu, May 1, 2014 at 5:30 PM, Simon Marlow marlo...@gmail.com wrote: We should fix this (or at least make it a lot less likely). Is there a ticket? Not yet. I just converted to 7.8.2 the other day (I'd been running the release candidate) and wanted to duplicate the problem first. I haven't been writing code on my larger projects since upgrading, so I've yet to experience the problem again. A similar issue was happening with parallel rebuilds with -j on a Mac after ^C'ing out of a cabal build, when compiling with -dynamic-too, where it winds up blaming missing files, but can't generate them That has caused me to abandon using -j during development. I encountered this one first, and I'm not sure if these are both just the same error. If I had to guess part of the problem seems like the logic in cabal and/or ghc around -dynamic-too treats the .dyn_foo and the .foo files as one inseparable artifact, when you can actually wind up with one of them and not the other. A final dynamic-linking issue that is only tangentially related is that it seems the dynamic-only code path is a bit broken as well. e.g. shared: True, executable-dynamic: True in cabal. I've had it complain about about looking for missing installed .hi files and skip right past the .dyn_hi files when working on a subsequent package that uses the first one. The only real relevance of that issue is that I was hoping to use it to cut my build times and to address the above concerns by not having two artifacts being produced when the tooling is designed around one, but I seem forced to build both. As soon as I have a build break in a way that I can show a decent trace, I'll put in a ticket. -Edward Cheers, Simon -Edward On Thu, May 1, 2014 at 3:29 AM, Simon Peyton Jones simo...@microsoft.com mailto:simo...@microsoft.com wrote: | 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 echo this. Dynamic linking has had many un-anticipated costs and it is still very far from sorted out. It originally felt like a Fantastic Idea to give up our own linker and adopt the system linker, but it now feels to me like a black hole, endlessly sucking effort and increasing complexity. My viewpoint is highly un-informed about details; I just watch the traffic going by. And of course it does have benefits that doubtless generate less traffic. Simon | | | | | On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones | simo...@microsoft.com mailto:simo...@microsoft.com mailto: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 mailto: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 mailto:ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | ___ 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
Re: GHC status report
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
Re: GHC status report
Done now. OK, unless anyone has anything else major going in, I'll look for typos closely and send it to Mihail later today. It filled up pretty fast - thanks for the haste everyone! On Tue, Apr 29, 2014 at 7:46 PM, Austin Seipp aus...@well-typed.com wrote: Good idea! Definitely one of the biggest changes. On Tue, Apr 29, 2014 at 7:35 PM, George Colpitts george.colpi...@gmail.com 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. On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones 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 http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
Added a few sentences about DWARF support - we should really aim to get this done for 7.10. Greetings, Peter Wortmann ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
Great, thanks Peter! On Wed, Apr 30, 2014 at 8:29 AM, Peter Wortmann sc...@leeds.ac.uk wrote: Added a few sentences about DWARF support - we should really aim to get this done for 7.10. Greetings, Peter Wortmann ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
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
Re: GHC status report
Hi, On Wed, 30 Apr 2014 17:45:35 +0100, Simon Marlow marlo...@gmail.com writes: 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. Apart from the bugs, which are steadily being fixed (hooray), I have a little concern about -dynamic-too. The whole thing is kind of a mess, that if you forget to use it, then ghci doesn't work and TH doesn't work. And cabal used it wrong (maybe now it's getting better). It also increases the compilation times. And of course I get used to it, but I wanted to ask: would it be possible to change the default compilation method to be only dynamic? If we have only dynamic objects, can we still build a static executable (I mean haskelly half static: libc and libgmp is dynamic, but the haskell libs are not shared, so as of now)? If I remember correctly when I do gcc + ld for a simple C project, it's enough to decide ld time if I'm building a shared or a static executable. But maybe I'm oversimplifying something... Gergely ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
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 pagehttp://www.cs.yale.edu/homes/hudak/SOE/software1.htmfor 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
Re: GHC status report
Good idea! Definitely one of the biggest changes. On Tue, Apr 29, 2014 at 7:35 PM, George Colpitts george.colpi...@gmail.com 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. On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones 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 http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
