From gershomb at gmail.com Sun Apr 1 04:56:39 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 1 Apr 2018 00:56:39 -0400 Subject: Proposal: Professionalizing GHC Development Message-ID: Fellow Haskellers, Recently there has been much work into creating a better and more professional GHC development process, including in the form of DevOps infrastructure, scheduled releases and governance, etc. But much remains to be done. There continues to be concern about the lack of use of industry-standard tools. For example, GHC development is tied to Phabricator, which is a custom product originally developed for in-house use by an obscure startup. GHC development is documented on a wiki still -- ancient technology, not appropriate for 2018. Wiki syntax for documentation needs to be replaced by the only modern standard -- github flavored markdown. Trac itself is ancient technology, dating to 2003, well before anybody knew how to program real software. It provides no support for all the most important aspects of software development -- Kanban boards, sprint management, or even burndown charts. What is necessary is an integrated solution that holistically addresses all aspects of development, fostering a DevOps culture, embracing cloud-first, agile-first, test-first, disrupt-first principles, and with an ironclad SLA. Rather than homegrown solutions, we need a GHC development process that utilizes tools and procedures already familiar to regular developers. Cross-sectional feature comparison analysis yields a clear front-runner -- Visual Studio Team Services. VSTS is a recognized Leader in the Gartner Magic Quadrant for Enterprise Agile Planning tools. It lets us migrate from custom git hosting to a more reliable source control system -- Team Foundation Version Control. By enforcing the locking of checked-out files, we can prevent the sorts of overlap between different patches that occur in the current distributed version management system, and coordinate tightly between developers, enabling and fostering T-shaped skills. Team Build also lets us migrate from antiquated makefiles to modern, industry-standard technology -- XML descriptions of build processes that integrate automatically with tracking of PBIs (product backlog items), and one-button release management. In terms of documentation, rather than deal with the subtleties of different markdown implementations and the confusing world of restructured text, we can utilize the full power of Word, including SharePoint integration as well as Office 365 capabilities, and integration with Microsoft Teams, the chat-based workspace for collaboration. This enables much more effective cross-team collaboration with product and marketing divisions. One of the most exciting features of VSTS is powerful extensibility, with APIs offered in both major programming paradigms in use today -- JVM and .NET. The core organizational principle for full application lifecycle management is a single data construct -- the "work item" which documentation informs us "represents a thing," which can be anything that "a user can imagine." The power of work items comes through their extensible XML representation. Work items are combined into a Process Template, with such powerful Process Templates available as Agile, Scrum, and CMMI. VSTS will also allow us to analyze GHC Developer team performance with an integrated reporting data warehouse that uses a cube. Pricing for up to 100 users is $750 a month. Individual developers can also purchase subscriptions to Visual Studio Professional for $45 a month. I suggest we start directing resources towards a transition. I imagine all work to accomplish this could be done within a year, and by next April 1, the GHC development process will be almost unrecognizable from that today. Regards, Gershom From amindfv at gmail.com Sun Apr 1 05:28:01 2018 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sun, 1 Apr 2018 01:28:01 -0400 Subject: Proposal: Professionalizing GHC Development In-Reply-To: References: Message-ID: Overall this is a great proposal; glad we're finally modernizing! Still, it's got a pretty steep price tag - maybe we can offset costs with an I.C.O.? ("GHC Coin"?) > El 1 abr 2018, a las 00:56, Gershom B escribió: > > Fellow Haskellers, > > Recently there has been much work into creating a better and more > professional GHC development process, including in the form of DevOps > infrastructure, scheduled releases and governance, etc. But much > remains to be done. There continues to be concern about the lack of > use of industry-standard tools. For example, GHC development is tied > to Phabricator, which is a custom product originally developed for > in-house use by an obscure startup. GHC development is documented on a > wiki still -- ancient technology, not appropriate for 2018. Wiki > syntax for documentation needs to be replaced by the only modern > standard -- github flavored markdown. Trac itself is ancient > technology, dating to 2003, well before anybody knew how to program > real software. It provides no support for all the most important > aspects of software development -- Kanban boards, sprint management, > or even burndown charts. > > What is necessary is an integrated solution that holistically > addresses all aspects of development, fostering a DevOps culture, > embracing cloud-first, agile-first, test-first, disrupt-first > principles, and with an > ironclad SLA. Rather than homegrown solutions, we need a GHC > development process that utilizes tools and procedures already > familiar to regular developers. Cross-sectional feature comparison > analysis yields a clear front-runner -- Visual Studio Team Services. > > VSTS is a recognized Leader in the Gartner Magic Quadrant for > Enterprise Agile Planning tools. It lets us migrate from custom git > hosting to a more reliable source control system -- Team Foundation > Version Control. By enforcing the locking of checked-out files, we can > prevent the sorts of overlap between different patches that occur in > the current distributed version management system, and coordinate > tightly between developers, enabling and fostering T-shaped skills. > Team Build also lets us migrate from antiquated makefiles to modern, > industry-standard technology -- XML descriptions of build processes > that integrate automatically with tracking of PBIs (product backlog > items), and one-button release management. > > In terms of documentation, rather than deal with the subtleties of > different markdown implementations and the confusing world of > restructured text, we can utilize the full power of Word, including > SharePoint integration as well as Office 365 capabilities, and integration > with Microsoft Teams, the chat-based workspace for collaboration. This > enables much more effective cross-team collaboration with product and > marketing divisions. > > One of the most exciting features of VSTS is powerful extensibility, > with APIs offered in both major programming paradigms in use today -- > JVM and .NET. The core organizational principle for full application > lifecycle management is a single data construct -- the "work item" > which documentation informs us "represents a thing," which can be > anything that "a user can imagine." The power of work items comes > through their extensible XML representation. Work items are combined > into a Process Template, with such powerful Process Templates > available as Agile, Scrum, and CMMI. VSTS will also allow us to > analyze GHC Developer team performance with an integrated reporting > data warehouse that uses a cube. > > Pricing for up to 100 users is $750 a month. Individual developers can > also purchase subscriptions to Visual Studio Professional for $45 a > month. I suggest we start directing resources towards a transition. I > imagine all work to accomplish this could be done within a year, and > by next April 1, the GHC development process will be almost > unrecognizable from that today. > > Regards, > Gershom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From kane at kane.cx Sun Apr 1 05:33:53 2018 From: kane at kane.cx (David Kraeutmann) Date: Sun, 01 Apr 2018 05:33:53 +0000 Subject: Proposal: Professionalizing GHC Development In-Reply-To: References: Message-ID: Leveraging the blockchain to compile GHC is a great idea! Unfortunately the proof-of-work algorithm is still just wasted cycles. On Sun, 1 Apr 2018, 07:28 , wrote: > Overall this is a great proposal; glad we're finally modernizing! Still, > it's got a pretty steep price tag - maybe we can offset costs with an > I.C.O.? ("GHC Coin"?) > > > > El 1 abr 2018, a las 00:56, Gershom B escribió: > > > > Fellow Haskellers, > > > > Recently there has been much work into creating a better and more > > professional GHC development process, including in the form of DevOps > > infrastructure, scheduled releases and governance, etc. But much > > remains to be done. There continues to be concern about the lack of > > use of industry-standard tools. For example, GHC development is tied > > to Phabricator, which is a custom product originally developed for > > in-house use by an obscure startup. GHC development is documented on a > > wiki still -- ancient technology, not appropriate for 2018. Wiki > > syntax for documentation needs to be replaced by the only modern > > standard -- github flavored markdown. Trac itself is ancient > > technology, dating to 2003, well before anybody knew how to program > > real software. It provides no support for all the most important > > aspects of software development -- Kanban boards, sprint management, > > or even burndown charts. > > > > What is necessary is an integrated solution that holistically > > addresses all aspects of development, fostering a DevOps culture, > > embracing cloud-first, agile-first, test-first, disrupt-first > > principles, and with an > > ironclad SLA. Rather than homegrown solutions, we need a GHC > > development process that utilizes tools and procedures already > > familiar to regular developers. Cross-sectional feature comparison > > analysis yields a clear front-runner -- Visual Studio Team Services. > > > > VSTS is a recognized Leader in the Gartner Magic Quadrant for > > Enterprise Agile Planning tools. It lets us migrate from custom git > > hosting to a more reliable source control system -- Team Foundation > > Version Control. By enforcing the locking of checked-out files, we can > > prevent the sorts of overlap between different patches that occur in > > the current distributed version management system, and coordinate > > tightly between developers, enabling and fostering T-shaped skills. > > Team Build also lets us migrate from antiquated makefiles to modern, > > industry-standard technology -- XML descriptions of build processes > > that integrate automatically with tracking of PBIs (product backlog > > items), and one-button release management. > > > > In terms of documentation, rather than deal with the subtleties of > > different markdown implementations and the confusing world of > > restructured text, we can utilize the full power of Word, including > > SharePoint integration as well as Office 365 capabilities, and > integration > > with Microsoft Teams, the chat-based workspace for collaboration. This > > enables much more effective cross-team collaboration with product and > > marketing divisions. > > > > One of the most exciting features of VSTS is powerful extensibility, > > with APIs offered in both major programming paradigms in use today -- > > JVM and .NET. The core organizational principle for full application > > lifecycle management is a single data construct -- the "work item" > > which documentation informs us "represents a thing," which can be > > anything that "a user can imagine." The power of work items comes > > through their extensible XML representation. Work items are combined > > into a Process Template, with such powerful Process Templates > > available as Agile, Scrum, and CMMI. VSTS will also allow us to > > analyze GHC Developer team performance with an integrated reporting > > data warehouse that uses a cube. > > > > Pricing for up to 100 users is $750 a month. Individual developers can > > also purchase subscriptions to Visual Studio Professional for $45 a > > month. I suggest we start directing resources towards a transition. I > > imagine all work to accomplish this could be done within a year, and > > by next April 1, the GHC development process will be almost > > unrecognizable from that today. > > > > Regards, > > Gershom > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Sun Apr 1 07:10:22 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Sun, 1 Apr 2018 15:10:22 +0800 Subject: Proposal: Professionalizing GHC Development In-Reply-To: References: Message-ID: Compiling GHC on a blockchain may not be economical, but running GHC-compiled programs on a blockchain is definitely a great idea! I've even come up with a paper title: A Secure Decentralized Transactional Implementation of Spinless Tagless G-machine, aka Haskoin! Time to recruiting a few engineers, write a white paper and raise a seed round :) On Sun, Apr 1, 2018 at 1:33 PM, David Kraeutmann wrote: > Leveraging the blockchain to compile GHC is a great idea! > > Unfortunately the proof-of-work algorithm is still just wasted cycles. > > On Sun, 1 Apr 2018, 07:28 , wrote: > >> Overall this is a great proposal; glad we're finally modernizing! Still, >> it's got a pretty steep price tag - maybe we can offset costs with an >> I.C.O.? ("GHC Coin"?) >> >> >> > El 1 abr 2018, a las 00:56, Gershom B escribió: >> > >> > Fellow Haskellers, >> > >> > Recently there has been much work into creating a better and more >> > professional GHC development process, including in the form of DevOps >> > infrastructure, scheduled releases and governance, etc. But much >> > remains to be done. There continues to be concern about the lack of >> > use of industry-standard tools. For example, GHC development is tied >> > to Phabricator, which is a custom product originally developed for >> > in-house use by an obscure startup. GHC development is documented on a >> > wiki still -- ancient technology, not appropriate for 2018. Wiki >> > syntax for documentation needs to be replaced by the only modern >> > standard -- github flavored markdown. Trac itself is ancient >> > technology, dating to 2003, well before anybody knew how to program >> > real software. It provides no support for all the most important >> > aspects of software development -- Kanban boards, sprint management, >> > or even burndown charts. >> > >> > What is necessary is an integrated solution that holistically >> > addresses all aspects of development, fostering a DevOps culture, >> > embracing cloud-first, agile-first, test-first, disrupt-first >> > principles, and with an >> > ironclad SLA. Rather than homegrown solutions, we need a GHC >> > development process that utilizes tools and procedures already >> > familiar to regular developers. Cross-sectional feature comparison >> > analysis yields a clear front-runner -- Visual Studio Team Services. >> > >> > VSTS is a recognized Leader in the Gartner Magic Quadrant for >> > Enterprise Agile Planning tools. It lets us migrate from custom git >> > hosting to a more reliable source control system -- Team Foundation >> > Version Control. By enforcing the locking of checked-out files, we can >> > prevent the sorts of overlap between different patches that occur in >> > the current distributed version management system, and coordinate >> > tightly between developers, enabling and fostering T-shaped skills. >> > Team Build also lets us migrate from antiquated makefiles to modern, >> > industry-standard technology -- XML descriptions of build processes >> > that integrate automatically with tracking of PBIs (product backlog >> > items), and one-button release management. >> > >> > In terms of documentation, rather than deal with the subtleties of >> > different markdown implementations and the confusing world of >> > restructured text, we can utilize the full power of Word, including >> > SharePoint integration as well as Office 365 capabilities, and >> integration >> > with Microsoft Teams, the chat-based workspace for collaboration. This >> > enables much more effective cross-team collaboration with product and >> > marketing divisions. >> > >> > One of the most exciting features of VSTS is powerful extensibility, >> > with APIs offered in both major programming paradigms in use today -- >> > JVM and .NET. The core organizational principle for full application >> > lifecycle management is a single data construct -- the "work item" >> > which documentation informs us "represents a thing," which can be >> > anything that "a user can imagine." The power of work items comes >> > through their extensible XML representation. Work items are combined >> > into a Process Template, with such powerful Process Templates >> > available as Agile, Scrum, and CMMI. VSTS will also allow us to >> > analyze GHC Developer team performance with an integrated reporting >> > data warehouse that uses a cube. >> > >> > Pricing for up to 100 users is $750 a month. Individual developers can >> > also purchase subscriptions to Visual Studio Professional for $45 a >> > month. I suggest we start directing resources towards a transition. I >> > imagine all work to accomplish this could be done within a year, and >> > by next April 1, the GHC development process will be almost >> > unrecognizable from that today. >> > >> > Regards, >> > Gershom >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Sun Apr 1 09:09:05 2018 From: monkleyon at gmail.com (MarLinn) Date: Sun, 1 Apr 2018 11:09:05 +0200 Subject: Proposal: Professionalizing GHC Development In-Reply-To: References: Message-ID: Could you clarify? I see two promising proposals in this: A) Redefining proof-of-work to mean one has to compile a GHC instead of computing some obscure hashes only nerds care about B) GHC will be compiled via contracts in the blockchain, to make sure all mistake remain attributable I like both ideas, but maybe you had something different in mind? Or maybe we can combine both. Nested blockchains. Recursion! I wonder if there's a lens for that already… On 2018-04-01 07:33, David Kraeutmann wrote: > Leveraging the blockchain to compile GHC is a great idea! > > Unfortunately the proof-of-work algorithm is still just wasted cycles. > > On Sun, 1 Apr 2018, 07:28 , > wrote: > > Overall this is a great proposal; glad we're finally modernizing! > Still, it's got a pretty steep price tag - maybe we can offset > costs with an I.C.O.? ("GHC Coin"?) > > > > El 1 abr 2018, a las 00:56, Gershom B > escribió: > > > > Fellow Haskellers, > > > > Recently there has been much work into creating a better and more > > professional GHC development process, including in the form of > DevOps > > infrastructure, scheduled releases and governance, etc. But much > > remains to be done. There continues to be concern about the lack of > > use of industry-standard tools. For example, GHC development is tied > > to Phabricator, which is a custom product originally developed for > > in-house use by an obscure startup. GHC development is > documented on a > > wiki still -- ancient technology, not appropriate for 2018. Wiki > > syntax for documentation needs to be replaced by the only modern > > standard -- github flavored markdown. Trac itself is ancient > > technology, dating to 2003, well before anybody knew how to program > > real software. It provides no support for all the most important > > aspects of software development -- Kanban boards, sprint management, > > or even burndown charts. > > > > What is necessary is an integrated solution that holistically > > addresses all aspects of development, fostering a DevOps culture, > > embracing cloud-first, agile-first, test-first, disrupt-first > > principles, and with an > > ironclad SLA. Rather than homegrown solutions, we need a GHC > > development process that utilizes tools and procedures already > > familiar to regular developers. Cross-sectional feature comparison > > analysis yields a clear front-runner -- Visual Studio Team Services. > > > > VSTS is a recognized Leader in the Gartner Magic Quadrant for > > Enterprise Agile Planning tools. It lets us migrate from custom git > > hosting to a more reliable source control system -- Team Foundation > > Version Control. By enforcing the locking of checked-out files, > we can > > prevent the sorts of overlap between different patches that occur in > > the current distributed version management system, and coordinate > > tightly between developers, enabling and fostering T-shaped skills. > > Team Build also lets us migrate from antiquated makefiles to modern, > > industry-standard technology -- XML descriptions of build processes > > that integrate automatically with tracking of PBIs (product backlog > > items), and one-button release management. > > > > In terms of documentation, rather than deal with the subtleties of > > different markdown implementations and the confusing world of > > restructured text, we can utilize the full power of Word, including > > SharePoint integration as well as Office 365 capabilities, and > integration > > with Microsoft Teams, the chat-based workspace for > collaboration. This > > enables much more effective cross-team collaboration with > product and > > marketing divisions. > > > > One of the most exciting features of VSTS is powerful extensibility, > > with APIs offered in both major programming paradigms in use > today -- > > JVM and .NET. The core organizational principle for full application > > lifecycle management is a single data construct -- the "work item" > > which documentation informs us "represents a thing," which can be > > anything that "a user can imagine." The power of work items comes > > through their extensible XML representation. Work items are combined > > into a Process Template, with such powerful Process Templates > > available as Agile, Scrum, and CMMI. VSTS will also allow us to > > analyze GHC Developer team performance with an integrated reporting > > data warehouse that uses a cube. > > > > Pricing for up to 100 users is $750 a month. Individual > developers can > > also purchase subscriptions to Visual Studio Professional for $45 a > > month. I suggest we start directing resources towards a > transition. I > > imagine all work to accomplish this could be done within a year, and > > by next April 1, the GHC development process will be almost > > unrecognizable from that today. > > > > Regards, > > Gershom > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at halfaya.org Sun Apr 1 11:58:12 2018 From: leo at halfaya.org (John Leo) Date: Sun, 1 Apr 2018 04:58:12 -0700 Subject: Haskell Colonectomy Message-ID: A serious proposal: https://github.com/halfaya/ghc-proposals/blob/master/proposals/0000-colonectomy.rst John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jweakly at pdx.edu Sun Apr 1 15:41:39 2018 From: jweakly at pdx.edu (Jared Weakly) Date: Sun, 01 Apr 2018 15:41:39 +0000 Subject: Haskell Colonectomy In-Reply-To: References: Message-ID: Ahh, yes, I've been waiting for someone to start this. I'll get the popcorn On Sun, Apr 1, 2018, 4:58 AM John Leo wrote: > A serious proposal: > > https://github.com/halfaya/ghc-proposals/blob/master/proposals/0000-colonectomy.rst > > John > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Apr 1 21:05:29 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 01 Apr 2018 17:05:29 -0400 Subject: [ANNOUNCE] GHC 8.4.2-rc1 now available Message-ID: <87in9afxij.fsf@smart-cactus.org> Hello everyone, The GHC team is proud to announce the first release candidate of 8.4.2. the source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.4.2-rc1 This release follows so closely to 8.4.1 due to a number last-minute bug-fixes that didn't quite make it into 8.4.1. This includes fixes for: * #14705, the interpreter being broken on some systems * #14779, where the compiler produces invalid code when used with -g * #14891, where a selection of GHC testsuite cases fail on OS X * #5129, where the simplifier would incorrectly reorder evaluation in under some conditions. Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. Happy testing Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From gershomb at gmail.com Mon Apr 2 00:53:48 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 1 Apr 2018 20:53:48 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.2-rc1 now available In-Reply-To: <87in9afxij.fsf@smart-cactus.org> References: <87in9afxij.fsf@smart-cactus.org> Message-ID: Thanks for the announcement, Ben. Since cabal-install 2.2 was just released, we were planning a new Haskell Platform release Any Day Now (tm). But given the impending 8.4.2 release, I think we will hold off until it lands. Cheers, Gershom On April 1, 2018 at 5:07:35 PM, Ben Gamari (ben at well-typed.com) wrote: Hello everyone, The GHC team is proud to announce the first release candidate of 8.4.2. the source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.4.2-rc1 This release follows so closely to 8.4.1 due to a number last-minute bug-fixes that didn't quite make it into 8.4.1. This includes fixes for: * #14705, the interpreter being broken on some systems * #14779, where the compiler produces invalid code when used with -g * #14891, where a selection of GHC testsuite cases fail on OS X * #5129, where the simplifier would incorrectly reorder evaluation in under some conditions. Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. Happy testing Cheers, - Ben _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 2 10:53:47 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Apr 2018 10:53:47 +0000 Subject: Testsuite failures Message-ID: Ben I'm getting these unexpected failures on my Linux box (64 bit) Unexpected failures: /tmp/ghctest-g01j3x6z/test spaces/./cabal/ghcpkg05.run ghcpkg05 [bad stderr] (normal) Unexpected stat failures: /tmp/ghctest-g01j3x6z/test spaces/./perf/compiler/T5837.run T5837 [stat too good] (normal) /tmp/ghctest-g01j3x6z/test spaces/./perf/compiler/T5321FD.run T5321FD [stat too good] (normal) I would LOVE it if the testsuite framework didn't print those long prefix paths! I'd prefer Unexpected failures: cabal/ghcpkg05.run ghcpkg05 [bad stderr] (normal) Unexpected stat failures: perf/compiler/T5837.run T5837 [stat too good] (normal) perf/compiler/T5321FD.run T5321FD [stat too good] (normal) The stat failures look like this: =====> T5321FD(normal) 1 of 1 [0, 0, 0] cd "./T5321FD.run" && "/5playpen/simonpj/HEAD-1/inplace/test spaces/ghc-stage2" -c T5321FD.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output +RTS -V0 -tT5321FD.comp.stats --machine-readable -RTS bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5321FD(normal) bytes allocated: 415136648 +/-10% Lower bound T5321FD(normal) bytes allocated: 373622983 Upper bound T5321FD(normal) bytes allocated: 456650313 Actual T5321FD(normal) bytes allocated: 373272448 Deviation T5321FD(normal) bytes allocated: -10.1 % *** unexpected stat test failure for T5321FD(normal) =====> T5837(normal) 1 of 1 [0, 0, 0] cd "./T5837.run" && "/5playpen/simonpj/HEAD-1/inplace/test spaces/ghc-stage2" -c T5837.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -freduction-depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5837(normal) bytes allocated: 55813608 +/-7% Lower bound T5837(normal) bytes allocated: 51906655 Upper bound T5837(normal) bytes allocated: 59720561 Actual T5837(normal) bytes allocated: 51558808 Deviation T5837(normal) bytes allocated: -7.6 % *** unexpected stat test failure for T5837(normal) In both cases, just a bit past the threshold. What is odd is that the latter doesn't fail on our CI system (I asked you this before). The former is new, maybe to do with Richard's recent patches. Question: are the numbers 'centred' for the CI infrastructure. Maybe they are just under 10% and 7% resp, and something local pushes them a tiny bit lower? The ghcpkg05 failure is quite consistent, despite from-clean rebuild. =====> ghcpkg05(normal) 1 of 1 [0, 0, 0] cd "./ghcpkg05.run" && $MAKE -s --no-print-directory ghcpkg05 Actual stderr output differs from expected: diff -uw "./ghcpkg05.run/ghcpkg05.stderr.normalised" "./ghcpkg05.run/ghcpkg05.run.stderr.normalised" --- ./ghcpkg05.run/ghcpkg05.stderr.normalised 2018-04-02 11:52:51.407023104 +0100 +++ ./ghcpkg05.run/ghcpkg05.run.stderr.normalised 2018-04-02 11:52:51.407023104 +0100 @@ -10,6 +10,13 @@ cannot find any of ["C/D.hi","C/D.p_hi","C/D.dyn_hi"] cannot find any of ["C/E.hi","C/E.p_hi","C/E.dyn_hi"] cannot find any of ["libtestpkg-2.0-XXX.a","libtestpkg-2.0-XXX.p_a","libtestpkg-2.0-XXX-ghc.so","libtestpkg-2.0-XXX-ghc.dylib","testpkg-2.0-XXX-ghc.dll"] on library path +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/utils doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/stage2 doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/haskeline/dist-install/build/includes doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/text/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/containers/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/bytestring/dist-install/build/include doesn't exist or isn't a directory The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. *** unexpected failure for ghcpkg05(normal) Any ideas? Thanks SImon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Apr 2 15:50:33 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Apr 2018 11:50:33 -0400 Subject: Building GHC using cabal repl Message-ID: <1522684233.6808.9.camel@joachim-breitner.de> Hi, when hacking on most Haskell projects these days, I enjoy having a shell with ghcid -c 'cabal new-repl -w ghc-8.2' open. I wondered if I can achieve the same when hacking on GHC. The compiler/ directory has a Cabal file. It does not work out-of-the box (in a fully built tree): $ cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 Build profile: -w ghc-8.5.20180320 -O1 In order, the following will be built (use -v for more details): - ghc-8.5 (lib) (first run) Preprocessing library for ghc-8.5.. cabal: can't find source for Config in backpack, basicTypes, cmm, codeGen, coreSyn, deSugar, ghci, hsSyn, iface, llvmGen, main, nativeGen, parser, prelude, profiling, rename, simplCore, simplStg, specialise, stgSyn, stranal, typecheck, types, utils, vectorise, /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/autogen, /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/global-autogen cabal: repl failed for ghc-8.5. It seems that the stage2/build directory is not registered as a source directory: $ find -name Config.hs ./stage2/build/Config.hs ./stage1/build/Config.hs But if I extend the section if flag(stage2) Include-Dirs: stage2 with these lines Include-Dirs: stage2/build hs-source-dirs: stage2/build ghc-options: -DSTAGE=2 ghc-options: -fobject-code and call cabal like so, it actually works: cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 If I now make hdevtools use this line, then hacking on GHC will have a bit less friction… (BTW, does Hadrian have a “load all of GHC in GHCi” mode?) Cheers, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at cs.brynmawr.edu Mon Apr 2 21:23:24 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 2 Apr 2018 17:23:24 -0400 Subject: T7050 failing Message-ID: Hi Simon, Your recent "unpack datacons" patch (https://phabricator.haskell.org/rGHC9187d5fb1d3d38a4e607b0d61784c21447c8195b ) causes typecheck/should_compile/T7050 to loop. This was harder to discover because I had broken validation previously... Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Apr 2 22:15:04 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 02 Apr 2018 18:15:04 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.2-rc1 now available In-Reply-To: References: <87in9afxij.fsf@smart-cactus.org> Message-ID: <87370dfe71.fsf@smart-cactus.org> Gershom B writes: > Thanks for the announcement, Ben. Since cabal-install 2.2 was just > released, we were planning a new Haskell Platform release Any Day Now > (tm). But given the impending 8.4.2 release, I think we will hold off > until it lands. > Yes, I think that is probably best; 8.4.1 is just broken enough that I would prefer if we would avoid pushing it out any more widely than necessary. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Mon Apr 2 22:23:29 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Apr 2018 22:23:29 +0000 Subject: More windows Message-ID: Tamar I've noticed that "sh" (which is invoked at lot by make etc) takes AGES to start up. At least I think it's 'sh' that is causing the delay. I think it's c:/msys64/usr/bin/sh.exe >From searching the web (eg https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html) it seems likely that it executes c:/msys64/etc/profile first. And If I put an 'echo' at the start and end of that file, they do seem to take place with a significant gap between them. I have not started sprinkling more echos, but does that ring any bells? Can I replace 'sh' with c:/msys64/usr/bin/bash.exe, which seems to be faster? (My evnt variable SHELL already points to bash.exe. ) And if so, how would I do that? An environment variable. Physically copy bash.exe to sh.exe? Or what? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From higuoxing at gmail.com Tue Apr 3 01:02:32 2018 From: higuoxing at gmail.com (Xing GUO) Date: Mon, 2 Apr 2018 21:02:32 -0400 Subject: [Newcomer] [Bug 13795] :kind! is not expanding type synonyms anymore Message-ID: Hi, I am a newcomer, I have compiled the GHC codes ... And, I want to do some contribution for it ... I found a ticket on the website, and I want to work on this ... #BUG 13795 Can someone give me some advice? or is there anyone that has been working on this ? Regards, Xing -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Tue Apr 3 01:45:18 2018 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Tue, 3 Apr 2018 09:45:18 +0800 Subject: Building GHC using cabal repl In-Reply-To: <1522684233.6808.9.camel@joachim-breitner.de> References: <1522684233.6808.9.camel@joachim-breitner.de> Message-ID: Hi Joachim, I believe this might be due to the recent changes that try to keep the source tree pristine instead of generating data in-place. This is partially the result of making ghc relocatable: hadrian#445[1]. It included changes to cabal and ghc and the final bits have been merged in the form of hadrian#531[2] just a few days ago into hadrian. The make based build system does not take advantage of this. As `Config.hs` is a generated file it no resides in the build folder; as such I believe your changes to be correct. Does hadrian have a load all of ghc into ghci? I'm afraid I don't think it does yet. I've opened hadrian#551[3] for this. Cheers, Moritz -- [1]: https://github.com/snowleopard/hadrian/pull/445 [2]: https://github.com/snowleopard/hadrian/pull/531 [3]: https://github.com/snowleopard/hadrian/issues/551 > On Apr 2, 2018, at 11:50 PM, Joachim Breitner wrote: > > Hi, > > when hacking on most Haskell projects these days, I enjoy having a > shell with > > ghcid -c 'cabal new-repl -w ghc-8.2' > > open. I wondered if I can achieve the same when hacking on GHC. The > compiler/ directory has a Cabal file. > > It does not work out-of-the box (in a fully built tree): > > $ cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 > Build profile: -w ghc-8.5.20180320 -O1 > In order, the following will be built (use -v for more details): > - ghc-8.5 (lib) (first run) > Preprocessing library for ghc-8.5.. > cabal: can't find source for Config in backpack, basicTypes, cmm, codeGen, > coreSyn, deSugar, ghci, hsSyn, iface, llvmGen, main, nativeGen, parser, > prelude, profiling, rename, simplCore, simplStg, specialise, stgSyn, stranal, > typecheck, types, utils, vectorise, > /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/autogen, > /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/global-autogen > > cabal: repl failed for ghc-8.5. > > It seems that the stage2/build directory is not registered as a source > directory: > > $ find -name Config.hs > ./stage2/build/Config.hs > ./stage1/build/Config.hs > > But if I extend the section > > if flag(stage2) > Include-Dirs: stage2 > > with these lines > > Include-Dirs: stage2/build > hs-source-dirs: stage2/build > ghc-options: -DSTAGE=2 > ghc-options: -fobject-code > > and call cabal like so, it actually works: > > cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 > > If I now make hdevtools use this line, then hacking on GHC will have a > bit less friction… > > (BTW, does Hadrian have a “load all of GHC in GHCi” mode?) > > Cheers, > Joachim > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de > https://www.joachim-breitner.de/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at cs.brynmawr.edu Tue Apr 3 04:11:58 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 3 Apr 2018 00:11:58 -0400 Subject: [Newcomer] [Bug 13795] :kind! is not expanding type synonyms anymore In-Reply-To: References: Message-ID: This bug is under active consideration as a proposal -- and I believe @alpmestan may have already implemented it. So it's perhaps not the best place to start. See https://github.com/ghc-proposals/ghc-proposals/pull/79 Were there other bugs you spotted that you might be interested in? Richard > On Apr 2, 2018, at 9:02 PM, Xing GUO wrote: > > > Hi, I am a newcomer, I have compiled the GHC codes ... And, I want to do some contribution for it ... I found a ticket on the website, and I want to work on this ... > #BUG 13795 Can someone give me some advice? or is there anyone that has been working on this ? > > Regards, > Xing > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Apr 3 06:00:04 2018 From: lonetiger at gmail.com (Phyx) Date: Tue, 03 Apr 2018 06:00:04 +0000 Subject: More windows In-Reply-To: References: Message-ID: Hi Simon, Hmm I'm not sure about replacing sh with bash. I think bash has some Non-POSIX extensions that may affect the behavior of valid posix scripts. Is bash --login slow as well? How about once sh or bash starts, are commands still slow then? I assume your computer is domain joined and you may be hitting a very long standing issue with certain domain joined machines https://github.com/Alexpux/MSYS2-packages/issues/138#issuecomment-70813762 The solution seems to be to cache the user info locally instead of it having to query the domain controller everytime. See solution 2 here https://gist.github.com/k-takata/9b8d143f0f3fef5abdab for instructions Does that help the problem? I believe you had a similar problem last time setting up a new machine. At that time magit was also slow. Kind regards, Tamar On Mon, Apr 2, 2018, 23:23 Simon Peyton Jones wrote: > Tamar > > I’ve noticed that “sh” (which is invoked at lot by make etc) takes AGES to > start up. At least I think it’s ‘sh’ that is causing the delay. > > I think it’s c:/msys64/usr/bin/sh.exe > > From searching the web (eg > https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html) it seems > likely that it executes c:/msys64/etc/profile first. > > And If I put an ‘echo’ at the start and end of that file, they do seem to > take place with a significant gap between them. > > I have not started sprinkling more echos, but does that ring any bells? > > Can I replace ‘sh’ with c:/msys64/usr/bin/bash.exe, which seems to be > faster? (My evnt variable SHELL already points to bash.exe. ) And if so, > how would I do that? An environment variable. Physically copy bash.exe to > sh.exe? Or what? > > Thanks > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndmitchell at gmail.com Tue Apr 3 08:24:38 2018 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue, 3 Apr 2018 09:24:38 +0100 Subject: Building GHC using cabal repl In-Reply-To: References: <1522684233.6808.9.camel@joachim-breitner.de> Message-ID: Hi Joachim, There are instructions on how to do it, described at https://github.com/ndmitchell/ghcid/issues/140 One word of warning - GHC runs preprocessors way more than is necessary, which vastly slows down the feedback loop. My hope is a GHC Dev will quickly get frustrated by that and fix it :) Thanks, Neil On Tue, Apr 3, 2018 at 2:45 AM, Moritz Angermann wrote: > Hi Joachim, > > I believe this might be due to the recent changes > that try to keep the source tree pristine instead > of generating data in-place. This is partially > the result of making ghc relocatable: hadrian#445[1]. > It included changes to cabal and ghc and the final > bits have been merged in the form of hadrian#531[2] > just a few days ago into hadrian. The make based > build system does not take advantage of this. > > As `Config.hs` is a generated file it no resides in > the build folder; as such I believe your changes to > be correct. > > Does hadrian have a load all of ghc into ghci? I'm > afraid I don't think it does yet. I've opened > hadrian#551[3] for this. > > Cheers, > Moritz > > -- > [1]: https://github.com/snowleopard/hadrian/pull/445 > [2]: https://github.com/snowleopard/hadrian/pull/531 > [3]: https://github.com/snowleopard/hadrian/issues/551 > >> On Apr 2, 2018, at 11:50 PM, Joachim Breitner wrote: >> >> Hi, >> >> when hacking on most Haskell projects these days, I enjoy having a >> shell with >> >> ghcid -c 'cabal new-repl -w ghc-8.2' >> >> open. I wondered if I can achieve the same when hacking on GHC. The >> compiler/ directory has a Cabal file. >> >> It does not work out-of-the box (in a fully built tree): >> >> $ cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 >> Build profile: -w ghc-8.5.20180320 -O1 >> In order, the following will be built (use -v for more details): >> - ghc-8.5 (lib) (first run) >> Preprocessing library for ghc-8.5.. >> cabal: can't find source for Config in backpack, basicTypes, cmm, codeGen, >> coreSyn, deSugar, ghci, hsSyn, iface, llvmGen, main, nativeGen, parser, >> prelude, profiling, rename, simplCore, simplStg, specialise, stgSyn, stranal, >> typecheck, types, utils, vectorise, >> /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/autogen, >> /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/global-autogen >> >> cabal: repl failed for ghc-8.5. >> >> It seems that the stage2/build directory is not registered as a source >> directory: >> >> $ find -name Config.hs >> ./stage2/build/Config.hs >> ./stage1/build/Config.hs >> >> But if I extend the section >> >> if flag(stage2) >> Include-Dirs: stage2 >> >> with these lines >> >> Include-Dirs: stage2/build >> hs-source-dirs: stage2/build >> ghc-options: -DSTAGE=2 >> ghc-options: -fobject-code >> >> and call cabal like so, it actually works: >> >> cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 >> >> If I now make hdevtools use this line, then hacking on GHC will have a >> bit less friction… >> >> (BTW, does Hadrian have a “load all of GHC in GHCi” mode?) >> >> Cheers, >> Joachim >> >> -- >> Joachim “nomeata” Breitner >> mail at joachim-breitner.de >> https://www.joachim-breitner.de/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From leo at halfaya.org Tue Apr 3 15:06:14 2018 From: leo at halfaya.org (John Leo) Date: Tue, 3 Apr 2018 08:06:14 -0700 Subject: 8.5 build failure Message-ID: Hi everyone, I pulled from head this morning and rebased my current work on it, and am getting a build error I've never seen before. I don't think it's due to any of my own changes, and everything built fine last time I tried just a couple days ago . I'd pulled both code and submodules. I did make clean, ./boot, ./configure, and then make. The last few lines of the output are below. This is on a Mac using GHC 8.2.2. Let me know if you need any more info. John "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o rts/dist/build/Capability.thr_debug_dyn_o rts/dist/build/CheckUnload.thr_debug_dyn_o rts/dist/build/ClosureFlags.thr_debug_dyn_o rts/dist/build/Disassembler.thr_debug_dyn_o rts/dist/build/FileLock.thr_debug_dyn_o rts/dist/build/Globals.thr_debug_dyn_o rts/dist/build/Hash.thr_debug_dyn_o rts/dist/build/Hpc.thr_debug_dyn_o rts/dist/build/HsFFI.thr_debug_dyn_o rts/dist/build/Inlines.thr_debug_dyn_o rts/dist/build/Interpreter.thr_debug_dyn_o rts/dist/build/LdvProfile.thr_debug_dyn_o rts/dist/build/Libdw.thr_debug_dyn_o rts/dist/build/LibdwPool.thr_debug_dyn_o rts/dist/build/Linker.thr_debug_dyn_o rts/dist/build/Messages.thr_debug_dyn_o rts/dist/build/OldARMAtomic.thr_debug_dyn_o rts/dist/build/PathUtils.thr_debug_dyn_o rts/dist/build/Pool.thr_debug_dyn_o rts/dist/build/Printer.thr_debug_dyn_o rts/dist/build/ProfHeap.thr_debug_dyn_o rts/dist/build/ProfilerReport.thr_debug_dyn_o rts/dist/build/ProfilerReportJson.thr_debug_dyn_o rts/dist/build/Profiling.thr_debug_dyn_o rts/dist/build/Proftimer.thr_debug_dyn_o rts/dist/build/RaiseAsync.thr_debug_dyn_o rts/dist/build/RetainerProfile.thr_debug_dyn_o rts/dist/build/RetainerSet.thr_debug_dyn_o rts/dist/build/RtsAPI.thr_debug_dyn_o rts/dist/build/RtsDllMain.thr_debug_dyn_o rts/dist/build/RtsFlags.thr_debug_dyn_o rts/dist/build/RtsMain.thr_debug_dyn_o rts/dist/build/RtsMessages.thr_debug_dyn_o rts/dist/build/RtsStartup.thr_debug_dyn_o rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o rts/dist/build/RtsSymbols.thr_debug_dyn_o rts/dist/build/RtsUtils.thr_debug_dyn_o rts/dist/build/STM.thr_debug_dyn_o rts/dist/build/Schedule.thr_debug_dyn_o rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o rts/dist/build/StaticPtrTable.thr_debug_dyn_o rts/dist/build/Stats.thr_debug_dyn_o rts/dist/build/StgCRun.thr_debug_dyn_o rts/dist/build/StgPrimFloat.thr_debug_dyn_o rts/dist/build/Task.thr_debug_dyn_o rts/dist/build/ThreadLabels.thr_debug_dyn_o rts/dist/build/ThreadPaused.thr_debug_dyn_o rts/dist/build/Threads.thr_debug_dyn_o rts/dist/build/Ticky.thr_debug_dyn_o rts/dist/build/Timer.thr_debug_dyn_o rts/dist/build/TopHandler.thr_debug_dyn_o rts/dist/build/Trace.thr_debug_dyn_o rts/dist/build/WSDeque.thr_debug_dyn_o rts/dist/build/Weak.thr_debug_dyn_o rts/dist/build/fs.thr_debug_dyn_o rts/dist/build/xxhash.thr_debug_dyn_o rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o rts/dist/build/hooks/MallocFail.thr_debug_dyn_o rts/dist/build/hooks/OnExit.thr_debug_dyn_o rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o rts/dist/build/sm/CNF.thr_debug_dyn_o rts/dist/build/sm/Compact.thr_debug_dyn_o rts/dist/build/sm/Evac.thr_debug_dyn_o rts/dist/build/sm/Evac_thr.thr_debug_dyn_o rts/dist/build/sm/GC.thr_debug_dyn_o rts/dist/build/sm/GCAux.thr_debug_dyn_o rts/dist/build/sm/GCUtils.thr_debug_dyn_o rts/dist/build/sm/MBlock.thr_debug_dyn_o rts/dist/build/sm/MarkWeak.thr_debug_dyn_o rts/dist/build/sm/Sanity.thr_debug_dyn_o rts/dist/build/sm/Scav.thr_debug_dyn_o rts/dist/build/sm/Scav_thr.thr_debug_dyn_o rts/dist/build/sm/Storage.thr_debug_dyn_o rts/dist/build/sm/Sweep.thr_debug_dyn_o rts/dist/build/eventlog/EventLog.thr_debug_dyn_o rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o rts/dist/build/linker/CacheFlush.thr_debug_dyn_o rts/dist/build/linker/Elf.thr_debug_dyn_o rts/dist/build/linker/LoadArchive.thr_debug_dyn_o rts/dist/build/linker/M32Alloc.thr_debug_dyn_o rts/dist/build/linker/MachO.thr_debug_dyn_o rts/dist/build/linker/PEi386.thr_debug_dyn_o rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o rts/dist/build/linker/elf_got.thr_debug_dyn_o rts/dist/build/linker/elf_plt.thr_debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o rts/dist/build/linker/elf_reloc.thr_debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_util.thr_debug_dyn_o rts/dist/build/posix/GetEnv.thr_debug_dyn_o rts/dist/build/posix/GetTime.thr_debug_dyn_o rts/dist/build/posix/Itimer.thr_debug_dyn_o rts/dist/build/posix/OSMem.thr_debug_dyn_o rts/dist/build/posix/OSThreads.thr_debug_dyn_o rts/dist/build/posix/Select.thr_debug_dyn_o rts/dist/build/posix/Signals.thr_debug_dyn_o rts/dist/build/posix/TTY.thr_debug_dyn_o rts/dist/build/Apply.thr_debug_dyn_o rts/dist/build/Compact.thr_debug_dyn_o rts/dist/build/Exception.thr_debug_dyn_o rts/dist/build/HeapStackCheck.thr_debug_dyn_o rts/dist/build/PrimOps.thr_debug_dyn_o rts/dist/build/StgMiscClosures.thr_debug_dyn_o rts/dist/build/StgStartup.thr_debug_dyn_o rts/dist/build/StgStdThunks.thr_debug_dyn_o rts/dist/build/Updates.thr_debug_dyn_o rts/dist/build/AutoApply.thr_debug_dyn_o -fPIC -dynamic -optc-DTHREADED_RTS -optc-DDEBUG -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_thr_debug-ghc8.5.20180403.dylib "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.debug_dyn_o rts/dist/build/Arena.debug_dyn_o rts/dist/build/Capability.debug_dyn_o rts/dist/build/CheckUnload.debug_dyn_o rts/dist/build/ClosureFlags.debug_dyn_o rts/dist/build/Disassembler.debug_dyn_o rts/dist/build/FileLock.debug_dyn_o rts/dist/build/Globals.debug_dyn_o rts/dist/build/Hash.debug_dyn_o rts/dist/build/Hpc.debug_dyn_o rts/dist/build/HsFFI.debug_dyn_o rts/dist/build/Inlines.debug_dyn_o rts/dist/build/Interpreter.debug_dyn_o rts/dist/build/LdvProfile.debug_dyn_o rts/dist/build/Libdw.debug_dyn_o rts/dist/build/LibdwPool.debug_dyn_o rts/dist/build/Linker.debug_dyn_o rts/dist/build/Messages.debug_dyn_o rts/dist/build/OldARMAtomic.debug_dyn_o rts/dist/build/PathUtils.debug_dyn_o rts/dist/build/Pool.debug_dyn_o rts/dist/build/Printer.debug_dyn_o rts/dist/build/ProfHeap.debug_dyn_o rts/dist/build/ProfilerReport.debug_dyn_o rts/dist/build/ProfilerReportJson.debug_dyn_o rts/dist/build/Profiling.debug_dyn_o rts/dist/build/Proftimer.debug_dyn_o rts/dist/build/RaiseAsync.debug_dyn_o rts/dist/build/RetainerProfile.debug_dyn_o rts/dist/build/RetainerSet.debug_dyn_o rts/dist/build/RtsAPI.debug_dyn_o rts/dist/build/RtsDllMain.debug_dyn_o rts/dist/build/RtsFlags.debug_dyn_o rts/dist/build/RtsMain.debug_dyn_o rts/dist/build/RtsMessages.debug_dyn_o rts/dist/build/RtsStartup.debug_dyn_o rts/dist/build/RtsSymbolInfo.debug_dyn_o rts/dist/build/RtsSymbols.debug_dyn_o rts/dist/build/RtsUtils.debug_dyn_o rts/dist/build/STM.debug_dyn_o rts/dist/build/Schedule.debug_dyn_o rts/dist/build/Sparks.debug_dyn_o rts/dist/build/Stable.debug_dyn_o rts/dist/build/StaticPtrTable.debug_dyn_o rts/dist/build/Stats.debug_dyn_o rts/dist/build/StgCRun.debug_dyn_o rts/dist/build/StgPrimFloat.debug_dyn_o rts/dist/build/Task.debug_dyn_o rts/dist/build/ThreadLabels.debug_dyn_o rts/dist/build/ThreadPaused.debug_dyn_o rts/dist/build/Threads.debug_dyn_o rts/dist/build/Ticky.debug_dyn_o rts/dist/build/Timer.debug_dyn_o rts/dist/build/TopHandler.debug_dyn_o rts/dist/build/Trace.debug_dyn_o rts/dist/build/WSDeque.debug_dyn_o rts/dist/build/Weak.debug_dyn_o rts/dist/build/fs.debug_dyn_o rts/dist/build/xxhash.debug_dyn_o rts/dist/build/hooks/FlagDefaults.debug_dyn_o rts/dist/build/hooks/LongGCSync.debug_dyn_o rts/dist/build/hooks/MallocFail.debug_dyn_o rts/dist/build/hooks/OnExit.debug_dyn_o rts/dist/build/hooks/OutOfHeap.debug_dyn_o rts/dist/build/hooks/StackOverflow.debug_dyn_o rts/dist/build/sm/BlockAlloc.debug_dyn_o rts/dist/build/sm/CNF.debug_dyn_o rts/dist/build/sm/Compact.debug_dyn_o rts/dist/build/sm/Evac.debug_dyn_o rts/dist/build/sm/Evac_thr.debug_dyn_o rts/dist/build/sm/GC.debug_dyn_o rts/dist/build/sm/GCAux.debug_dyn_o rts/dist/build/sm/GCUtils.debug_dyn_o rts/dist/build/sm/MBlock.debug_dyn_o rts/dist/build/sm/MarkWeak.debug_dyn_o rts/dist/build/sm/Sanity.debug_dyn_o rts/dist/build/sm/Scav.debug_dyn_o rts/dist/build/sm/Scav_thr.debug_dyn_o rts/dist/build/sm/Storage.debug_dyn_o rts/dist/build/sm/Sweep.debug_dyn_o rts/dist/build/eventlog/EventLog.debug_dyn_o rts/dist/build/eventlog/EventLogWriter.debug_dyn_o rts/dist/build/linker/CacheFlush.debug_dyn_o rts/dist/build/linker/Elf.debug_dyn_o rts/dist/build/linker/LoadArchive.debug_dyn_o rts/dist/build/linker/M32Alloc.debug_dyn_o rts/dist/build/linker/MachO.debug_dyn_o rts/dist/build/linker/PEi386.debug_dyn_o rts/dist/build/linker/SymbolExtras.debug_dyn_o rts/dist/build/linker/elf_got.debug_dyn_o rts/dist/build/linker/elf_plt.debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.debug_dyn_o rts/dist/build/linker/elf_plt_arm.debug_dyn_o rts/dist/build/linker/elf_reloc.debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.debug_dyn_o rts/dist/build/linker/elf_util.debug_dyn_o rts/dist/build/posix/GetEnv.debug_dyn_o rts/dist/build/posix/GetTime.debug_dyn_o rts/dist/build/posix/Itimer.debug_dyn_o rts/dist/build/posix/OSMem.debug_dyn_o rts/dist/build/posix/OSThreads.debug_dyn_o rts/dist/build/posix/Select.debug_dyn_o rts/dist/build/posix/Signals.debug_dyn_o rts/dist/build/posix/TTY.debug_dyn_o rts/dist/build/Apply.debug_dyn_o rts/dist/build/Compact.debug_dyn_o rts/dist/build/Exception.debug_dyn_o rts/dist/build/HeapStackCheck.debug_dyn_o rts/dist/build/PrimOps.debug_dyn_o rts/dist/build/StgMiscClosures.debug_dyn_o rts/dist/build/StgStartup.debug_dyn_o rts/dist/build/StgStdThunks.debug_dyn_o rts/dist/build/Updates.debug_dyn_o rts/dist/build/AutoApply.debug_dyn_o -fPIC -dynamic -optc-DDEBUG -ticky -DTICKY_TICKY -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_debug-ghc8.5.20180403.dylib "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o -dyno libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Base.hs-boot -o libraries/base/dist-install/build/GHC/Base.o-boot -dyno libraries/base/dist-install/build/GHC/Base.dyn_o-boot "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Real.hs-boot -o libraries/base/dist-install/build/GHC/Real.o-boot -dyno libraries/base/dist-install/build/GHC/Real.dyn_o-boot "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/IO.hs-boot -o libraries/base/dist-install/build/GHC/IO.o-boot -dyno libraries/base/dist-install/build/GHC/IO.dyn_o-boot libraries/base/GHC/IO.hs-boot:9:12: error: • Failed to load interface for ‘GHC.Integer.Type’ There are files missing in the ‘integer-gmp-1.0.1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. • In the type signature: mplusIO :: IO a -> IO a -> IO a | 9 | mplusIO :: IO a -> IO a -> IO a | ^^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at halfaya.org Tue Apr 3 15:09:49 2018 From: leo at halfaya.org (John Leo) Date: Tue, 3 Apr 2018 08:09:49 -0700 Subject: 8.5 build failure In-Reply-To: References: Message-ID: One thing I should note is that I believe since the last time I'd built I updated Mac OS to 10.13.4, if that is relevant. Note that stage 1 built fine; the failure occurs about 22 minutes into a build that typically takes 30 minute on my machine. John On Tue, Apr 3, 2018 at 8:06 AM, John Leo wrote: > Hi everyone, > > I pulled from head this morning and rebased my current work on it, and am > getting a build error I've never seen before. I don't think it's due to any > of my own changes, and everything built fine last time I tried just a > couple days ago . I'd pulled both code and submodules. I did make clean, > ./boot, ./configure, and then make. The last few lines of the output are > below. This is on a Mac using GHC 8.2.2. Let me know if you need any more > info. > > John > > "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload > deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath > -optl-Wl, at loader_path `cat rts/dist/libs.depend` > rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o > rts/dist/build/Capability.thr_debug_dyn_o rts/dist/build/CheckUnload.thr_debug_dyn_o > rts/dist/build/ClosureFlags.thr_debug_dyn_o rts/dist/build/Disassembler.thr_debug_dyn_o > rts/dist/build/FileLock.thr_debug_dyn_o rts/dist/build/Globals.thr_debug_dyn_o > rts/dist/build/Hash.thr_debug_dyn_o rts/dist/build/Hpc.thr_debug_dyn_o > rts/dist/build/HsFFI.thr_debug_dyn_o rts/dist/build/Inlines.thr_debug_dyn_o > rts/dist/build/Interpreter.thr_debug_dyn_o rts/dist/build/LdvProfile.thr_debug_dyn_o > rts/dist/build/Libdw.thr_debug_dyn_o rts/dist/build/LibdwPool.thr_debug_dyn_o > rts/dist/build/Linker.thr_debug_dyn_o rts/dist/build/Messages.thr_debug_dyn_o > rts/dist/build/OldARMAtomic.thr_debug_dyn_o rts/dist/build/PathUtils.thr_debug_dyn_o > rts/dist/build/Pool.thr_debug_dyn_o rts/dist/build/Printer.thr_debug_dyn_o > rts/dist/build/ProfHeap.thr_debug_dyn_o rts/dist/build/ProfilerReport.thr_debug_dyn_o > rts/dist/build/ProfilerReportJson.thr_debug_dyn_o > rts/dist/build/Profiling.thr_debug_dyn_o rts/dist/build/Proftimer.thr_debug_dyn_o > rts/dist/build/RaiseAsync.thr_debug_dyn_o rts/dist/build/ > RetainerProfile.thr_debug_dyn_o rts/dist/build/RetainerSet.thr_debug_dyn_o > rts/dist/build/RtsAPI.thr_debug_dyn_o rts/dist/build/RtsDllMain.thr_debug_dyn_o > rts/dist/build/RtsFlags.thr_debug_dyn_o rts/dist/build/RtsMain.thr_debug_dyn_o > rts/dist/build/RtsMessages.thr_debug_dyn_o rts/dist/build/RtsStartup.thr_debug_dyn_o > rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o > rts/dist/build/RtsSymbols.thr_debug_dyn_o rts/dist/build/RtsUtils.thr_debug_dyn_o > rts/dist/build/STM.thr_debug_dyn_o rts/dist/build/Schedule.thr_debug_dyn_o > rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o > rts/dist/build/StaticPtrTable.thr_debug_dyn_o rts/dist/build/Stats.thr_debug_dyn_o > rts/dist/build/StgCRun.thr_debug_dyn_o rts/dist/build/StgPrimFloat.thr_debug_dyn_o > rts/dist/build/Task.thr_debug_dyn_o rts/dist/build/ThreadLabels.thr_debug_dyn_o > rts/dist/build/ThreadPaused.thr_debug_dyn_o rts/dist/build/Threads.thr_debug_dyn_o > rts/dist/build/Ticky.thr_debug_dyn_o rts/dist/build/Timer.thr_debug_dyn_o > rts/dist/build/TopHandler.thr_debug_dyn_o rts/dist/build/Trace.thr_debug_dyn_o > rts/dist/build/WSDeque.thr_debug_dyn_o rts/dist/build/Weak.thr_debug_dyn_o > rts/dist/build/fs.thr_debug_dyn_o rts/dist/build/xxhash.thr_debug_dyn_o > rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o > rts/dist/build/hooks/MallocFail.thr_debug_dyn_o > rts/dist/build/hooks/OnExit.thr_debug_dyn_o rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o > rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o > rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o rts/dist/build/sm/CNF.thr_debug_dyn_o > rts/dist/build/sm/Compact.thr_debug_dyn_o rts/dist/build/sm/Evac.thr_debug_dyn_o > rts/dist/build/sm/Evac_thr.thr_debug_dyn_o rts/dist/build/sm/GC.thr_debug_dyn_o > rts/dist/build/sm/GCAux.thr_debug_dyn_o rts/dist/build/sm/GCUtils.thr_debug_dyn_o > rts/dist/build/sm/MBlock.thr_debug_dyn_o rts/dist/build/sm/MarkWeak.thr_debug_dyn_o > rts/dist/build/sm/Sanity.thr_debug_dyn_o rts/dist/build/sm/Scav.thr_debug_dyn_o > rts/dist/build/sm/Scav_thr.thr_debug_dyn_o rts/dist/build/sm/Storage.thr_debug_dyn_o > rts/dist/build/sm/Sweep.thr_debug_dyn_o rts/dist/build/eventlog/EventLog.thr_debug_dyn_o > rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o > rts/dist/build/linker/CacheFlush.thr_debug_dyn_o > rts/dist/build/linker/Elf.thr_debug_dyn_o rts/dist/build/linker/LoadArchive.thr_debug_dyn_o > rts/dist/build/linker/M32Alloc.thr_debug_dyn_o > rts/dist/build/linker/MachO.thr_debug_dyn_o rts/dist/build/linker/PEi386.thr_debug_dyn_o > rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o > rts/dist/build/linker/elf_got.thr_debug_dyn_o > rts/dist/build/linker/elf_plt.thr_debug_dyn_o > rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o > rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o > rts/dist/build/linker/elf_reloc.thr_debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o > rts/dist/build/linker/elf_util.thr_debug_dyn_o > rts/dist/build/posix/GetEnv.thr_debug_dyn_o rts/dist/build/posix/GetTime.thr_debug_dyn_o > rts/dist/build/posix/Itimer.thr_debug_dyn_o rts/dist/build/posix/OSMem.thr_debug_dyn_o > rts/dist/build/posix/OSThreads.thr_debug_dyn_o > rts/dist/build/posix/Select.thr_debug_dyn_o rts/dist/build/posix/Signals.thr_debug_dyn_o > rts/dist/build/posix/TTY.thr_debug_dyn_o rts/dist/build/Apply.thr_debug_dyn_o > rts/dist/build/Compact.thr_debug_dyn_o rts/dist/build/Exception.thr_debug_dyn_o > rts/dist/build/HeapStackCheck.thr_debug_dyn_o rts/dist/build/PrimOps.thr_debug_dyn_o > rts/dist/build/StgMiscClosures.thr_debug_dyn_o > rts/dist/build/StgStartup.thr_debug_dyn_o rts/dist/build/StgStdThunks.thr_debug_dyn_o > rts/dist/build/Updates.thr_debug_dyn_o rts/dist/build/AutoApply.thr_debug_dyn_o > -fPIC -dynamic -optc-DTHREADED_RTS -optc-DDEBUG -eventlog -O -H64m -Wall > -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build > -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE > -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen > -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 > -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_thr_ > debug-ghc8.5.20180403.dylib > "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload > deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath > -optl-Wl, at loader_path `cat rts/dist/libs.depend` > rts/dist/build/Adjustor.debug_dyn_o rts/dist/build/Arena.debug_dyn_o > rts/dist/build/Capability.debug_dyn_o rts/dist/build/CheckUnload.debug_dyn_o > rts/dist/build/ClosureFlags.debug_dyn_o rts/dist/build/Disassembler.debug_dyn_o > rts/dist/build/FileLock.debug_dyn_o rts/dist/build/Globals.debug_dyn_o > rts/dist/build/Hash.debug_dyn_o rts/dist/build/Hpc.debug_dyn_o > rts/dist/build/HsFFI.debug_dyn_o rts/dist/build/Inlines.debug_dyn_o > rts/dist/build/Interpreter.debug_dyn_o rts/dist/build/LdvProfile.debug_dyn_o > rts/dist/build/Libdw.debug_dyn_o rts/dist/build/LibdwPool.debug_dyn_o > rts/dist/build/Linker.debug_dyn_o rts/dist/build/Messages.debug_dyn_o > rts/dist/build/OldARMAtomic.debug_dyn_o rts/dist/build/PathUtils.debug_dyn_o > rts/dist/build/Pool.debug_dyn_o rts/dist/build/Printer.debug_dyn_o > rts/dist/build/ProfHeap.debug_dyn_o rts/dist/build/ProfilerReport.debug_dyn_o > rts/dist/build/ProfilerReportJson.debug_dyn_o rts/dist/build/Profiling.debug_dyn_o > rts/dist/build/Proftimer.debug_dyn_o rts/dist/build/RaiseAsync.debug_dyn_o > rts/dist/build/RetainerProfile.debug_dyn_o rts/dist/build/RetainerSet.debug_dyn_o > rts/dist/build/RtsAPI.debug_dyn_o rts/dist/build/RtsDllMain.debug_dyn_o > rts/dist/build/RtsFlags.debug_dyn_o rts/dist/build/RtsMain.debug_dyn_o > rts/dist/build/RtsMessages.debug_dyn_o rts/dist/build/RtsStartup.debug_dyn_o > rts/dist/build/RtsSymbolInfo.debug_dyn_o rts/dist/build/RtsSymbols.debug_dyn_o > rts/dist/build/RtsUtils.debug_dyn_o rts/dist/build/STM.debug_dyn_o > rts/dist/build/Schedule.debug_dyn_o rts/dist/build/Sparks.debug_dyn_o > rts/dist/build/Stable.debug_dyn_o rts/dist/build/StaticPtrTable.debug_dyn_o > rts/dist/build/Stats.debug_dyn_o rts/dist/build/StgCRun.debug_dyn_o > rts/dist/build/StgPrimFloat.debug_dyn_o rts/dist/build/Task.debug_dyn_o > rts/dist/build/ThreadLabels.debug_dyn_o rts/dist/build/ThreadPaused.debug_dyn_o > rts/dist/build/Threads.debug_dyn_o rts/dist/build/Ticky.debug_dyn_o > rts/dist/build/Timer.debug_dyn_o rts/dist/build/TopHandler.debug_dyn_o > rts/dist/build/Trace.debug_dyn_o rts/dist/build/WSDeque.debug_dyn_o > rts/dist/build/Weak.debug_dyn_o rts/dist/build/fs.debug_dyn_o > rts/dist/build/xxhash.debug_dyn_o rts/dist/build/hooks/FlagDefaults.debug_dyn_o > rts/dist/build/hooks/LongGCSync.debug_dyn_o rts/dist/build/hooks/MallocFail.debug_dyn_o > rts/dist/build/hooks/OnExit.debug_dyn_o rts/dist/build/hooks/OutOfHeap.debug_dyn_o > rts/dist/build/hooks/StackOverflow.debug_dyn_o > rts/dist/build/sm/BlockAlloc.debug_dyn_o rts/dist/build/sm/CNF.debug_dyn_o > rts/dist/build/sm/Compact.debug_dyn_o rts/dist/build/sm/Evac.debug_dyn_o > rts/dist/build/sm/Evac_thr.debug_dyn_o rts/dist/build/sm/GC.debug_dyn_o > rts/dist/build/sm/GCAux.debug_dyn_o rts/dist/build/sm/GCUtils.debug_dyn_o > rts/dist/build/sm/MBlock.debug_dyn_o rts/dist/build/sm/MarkWeak.debug_dyn_o > rts/dist/build/sm/Sanity.debug_dyn_o rts/dist/build/sm/Scav.debug_dyn_o > rts/dist/build/sm/Scav_thr.debug_dyn_o rts/dist/build/sm/Storage.debug_dyn_o > rts/dist/build/sm/Sweep.debug_dyn_o rts/dist/build/eventlog/EventLog.debug_dyn_o > rts/dist/build/eventlog/EventLogWriter.debug_dyn_o rts/dist/build/linker/CacheFlush.debug_dyn_o > rts/dist/build/linker/Elf.debug_dyn_o rts/dist/build/linker/LoadArchive.debug_dyn_o > rts/dist/build/linker/M32Alloc.debug_dyn_o rts/dist/build/linker/MachO.debug_dyn_o > rts/dist/build/linker/PEi386.debug_dyn_o rts/dist/build/linker/SymbolExtras.debug_dyn_o > rts/dist/build/linker/elf_got.debug_dyn_o rts/dist/build/linker/elf_plt.debug_dyn_o > rts/dist/build/linker/elf_plt_aarch64.debug_dyn_o > rts/dist/build/linker/elf_plt_arm.debug_dyn_o rts/dist/build/linker/elf_reloc.debug_dyn_o > rts/dist/build/linker/elf_reloc_aarch64.debug_dyn_o > rts/dist/build/linker/elf_util.debug_dyn_o rts/dist/build/posix/GetEnv.debug_dyn_o > rts/dist/build/posix/GetTime.debug_dyn_o rts/dist/build/posix/Itimer.debug_dyn_o > rts/dist/build/posix/OSMem.debug_dyn_o rts/dist/build/posix/OSThreads.debug_dyn_o > rts/dist/build/posix/Select.debug_dyn_o rts/dist/build/posix/Signals.debug_dyn_o > rts/dist/build/posix/TTY.debug_dyn_o rts/dist/build/Apply.debug_dyn_o > rts/dist/build/Compact.debug_dyn_o rts/dist/build/Exception.debug_dyn_o > rts/dist/build/HeapStackCheck.debug_dyn_o rts/dist/build/PrimOps.debug_dyn_o > rts/dist/build/StgMiscClosures.debug_dyn_o rts/dist/build/StgStartup.debug_dyn_o > rts/dist/build/StgStdThunks.debug_dyn_o rts/dist/build/Updates.debug_dyn_o > rts/dist/build/AutoApply.debug_dyn_o -fPIC -dynamic -optc-DDEBUG -ticky > -DTICKY_TICKY -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist > -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header > -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts > -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build > -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 > -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o > rts/dist/build/libHSrts_debug-ghc8.5.20180403.dylib > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i > -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build > -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen > -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. > -optP-include -optPlibraries/ghc-prim/dist- > install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id > ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts > -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances > -odir libraries/ghc-prim/dist-install/build -hidir > libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build > -dynamic-too -c libraries/ghc-prim/./GHC/CString.hs -o > libraries/ghc-prim/dist-install/build/GHC/CString.o -dyno > libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i > -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build > -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen > -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. > -optP-include -optPlibraries/ghc-prim/dist- > install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id > ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts > -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances > -odir libraries/ghc-prim/dist-install/build -hidir > libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build > -dynamic-too -c libraries/ghc-prim/./GHC/IntWord64.hs -o > libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno > libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i > -ilibraries/base/. -ilibraries/base/dist-install/build > -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen > -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include > -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM > -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h > -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id > rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db > -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build > -hidir libraries/base/dist-install/build -stubdir > libraries/base/dist-install/build -dynamic-too -c > libraries/base/./GHC/Base.hs-boot -o libraries/base/dist-install/build/GHC/Base.o-boot > -dyno libraries/base/dist-install/build/GHC/Base.dyn_o-boot > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i > -ilibraries/base/. -ilibraries/base/dist-install/build > -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen > -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include > -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM > -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h > -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id > rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db > -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build > -hidir libraries/base/dist-install/build -stubdir > libraries/base/dist-install/build -dynamic-too -c > libraries/base/./GHC/Real.hs-boot -o libraries/base/dist-install/build/GHC/Real.o-boot > -dyno libraries/base/dist-install/build/GHC/Real.dyn_o-boot > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i > -ilibraries/base/. -ilibraries/base/dist-install/build > -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen > -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include > -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM > -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h > -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id > rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db > -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build > -hidir libraries/base/dist-install/build -stubdir > libraries/base/dist-install/build -dynamic-too -c > libraries/base/./GHC/IO.hs-boot -o libraries/base/dist-install/build/GHC/IO.o-boot > -dyno libraries/base/dist-install/build/GHC/IO.dyn_o-boot > > libraries/base/GHC/IO.hs-boot:9:12: error: > • Failed to load interface for ‘GHC.Integer.Type’ > There are files missing in the ‘integer-gmp-1.0.1.0’ package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > • In the type signature: mplusIO :: IO a -> IO a -> IO a > | > 9 | mplusIO :: IO a -> IO a -> IO a > | ^^^^^^^^^^^^^^^^^^^^ > make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 3 15:09:51 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Apr 2018 15:09:51 +0000 Subject: 8.5 build failure In-Reply-To: References: Message-ID: so is every one else ☹. No one has a clue what’s going on. Ben &co are investigating. Simon From: ghc-devs On Behalf Of John Leo Sent: 03 April 2018 16:06 To: ghc-devs Subject: 8.5 build failure Hi everyone, I pulled from head this morning and rebased my current work on it, and am getting a build error I've never seen before. I don't think it's due to any of my own changes, and everything built fine last time I tried just a couple days ago . I'd pulled both code and submodules. I did make clean, ./boot, ./configure, and then make. The last few lines of the output are below. This is on a Mac using GHC 8.2.2. Let me know if you need any more info. John "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o rts/dist/build/Capability.thr_debug_dyn_o rts/dist/build/CheckUnload.thr_debug_dyn_o rts/dist/build/ClosureFlags.thr_debug_dyn_o rts/dist/build/Disassembler.thr_debug_dyn_o rts/dist/build/FileLock.thr_debug_dyn_o rts/dist/build/Globals.thr_debug_dyn_o rts/dist/build/Hash.thr_debug_dyn_o rts/dist/build/Hpc.thr_debug_dyn_o rts/dist/build/HsFFI.thr_debug_dyn_o rts/dist/build/Inlines.thr_debug_dyn_o rts/dist/build/Interpreter.thr_debug_dyn_o rts/dist/build/LdvProfile.thr_debug_dyn_o rts/dist/build/Libdw.thr_debug_dyn_o rts/dist/build/LibdwPool.thr_debug_dyn_o rts/dist/build/Linker.thr_debug_dyn_o rts/dist/build/Messages.thr_debug_dyn_o rts/dist/build/OldARMAtomic.thr_debug_dyn_o rts/dist/build/PathUtils.thr_debug_dyn_o rts/dist/build/Pool.thr_debug_dyn_o rts/dist/build/Printer.thr_debug_dyn_o rts/dist/build/ProfHeap.thr_debug_dyn_o rts/dist/build/ProfilerReport.thr_debug_dyn_o rts/dist/build/ProfilerReportJson.thr_debug_dyn_o rts/dist/build/Profiling.thr_debug_dyn_o rts/dist/build/Proftimer.thr_debug_dyn_o rts/dist/build/RaiseAsync.thr_debug_dyn_o rts/dist/build/RetainerProfile.thr_debug_dyn_o rts/dist/build/RetainerSet.thr_debug_dyn_o rts/dist/build/RtsAPI.thr_debug_dyn_o rts/dist/build/RtsDllMain.thr_debug_dyn_o rts/dist/build/RtsFlags.thr_debug_dyn_o rts/dist/build/RtsMain.thr_debug_dyn_o rts/dist/build/RtsMessages.thr_debug_dyn_o rts/dist/build/RtsStartup.thr_debug_dyn_o rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o rts/dist/build/RtsSymbols.thr_debug_dyn_o rts/dist/build/RtsUtils.thr_debug_dyn_o rts/dist/build/STM.thr_debug_dyn_o rts/dist/build/Schedule.thr_debug_dyn_o rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o rts/dist/build/StaticPtrTable.thr_debug_dyn_o rts/dist/build/Stats.thr_debug_dyn_o rts/dist/build/StgCRun.thr_debug_dyn_o rts/dist/build/StgPrimFloat.thr_debug_dyn_o rts/dist/build/Task.thr_debug_dyn_o rts/dist/build/ThreadLabels.thr_debug_dyn_o rts/dist/build/ThreadPaused.thr_debug_dyn_o rts/dist/build/Threads.thr_debug_dyn_o rts/dist/build/Ticky.thr_debug_dyn_o rts/dist/build/Timer.thr_debug_dyn_o rts/dist/build/TopHandler.thr_debug_dyn_o rts/dist/build/Trace.thr_debug_dyn_o rts/dist/build/WSDeque.thr_debug_dyn_o rts/dist/build/Weak.thr_debug_dyn_o rts/dist/build/fs.thr_debug_dyn_o rts/dist/build/xxhash.thr_debug_dyn_o rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o rts/dist/build/hooks/MallocFail.thr_debug_dyn_o rts/dist/build/hooks/OnExit.thr_debug_dyn_o rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o rts/dist/build/sm/CNF.thr_debug_dyn_o rts/dist/build/sm/Compact.thr_debug_dyn_o rts/dist/build/sm/Evac.thr_debug_dyn_o rts/dist/build/sm/Evac_thr.thr_debug_dyn_o rts/dist/build/sm/GC.thr_debug_dyn_o rts/dist/build/sm/GCAux.thr_debug_dyn_o rts/dist/build/sm/GCUtils.thr_debug_dyn_o rts/dist/build/sm/MBlock.thr_debug_dyn_o rts/dist/build/sm/MarkWeak.thr_debug_dyn_o rts/dist/build/sm/Sanity.thr_debug_dyn_o rts/dist/build/sm/Scav.thr_debug_dyn_o rts/dist/build/sm/Scav_thr.thr_debug_dyn_o rts/dist/build/sm/Storage.thr_debug_dyn_o rts/dist/build/sm/Sweep.thr_debug_dyn_o rts/dist/build/eventlog/EventLog.thr_debug_dyn_o rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o rts/dist/build/linker/CacheFlush.thr_debug_dyn_o rts/dist/build/linker/Elf.thr_debug_dyn_o rts/dist/build/linker/LoadArchive.thr_debug_dyn_o rts/dist/build/linker/M32Alloc.thr_debug_dyn_o rts/dist/build/linker/MachO.thr_debug_dyn_o rts/dist/build/linker/PEi386.thr_debug_dyn_o rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o rts/dist/build/linker/elf_got.thr_debug_dyn_o rts/dist/build/linker/elf_plt.thr_debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o rts/dist/build/linker/elf_reloc.thr_debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_util.thr_debug_dyn_o rts/dist/build/posix/GetEnv.thr_debug_dyn_o rts/dist/build/posix/GetTime.thr_debug_dyn_o rts/dist/build/posix/Itimer.thr_debug_dyn_o rts/dist/build/posix/OSMem.thr_debug_dyn_o rts/dist/build/posix/OSThreads.thr_debug_dyn_o rts/dist/build/posix/Select.thr_debug_dyn_o rts/dist/build/posix/Signals.thr_debug_dyn_o rts/dist/build/posix/TTY.thr_debug_dyn_o rts/dist/build/Apply.thr_debug_dyn_o rts/dist/build/Compact.thr_debug_dyn_o rts/dist/build/Exception.thr_debug_dyn_o rts/dist/build/HeapStackCheck.thr_debug_dyn_o rts/dist/build/PrimOps.thr_debug_dyn_o rts/dist/build/StgMiscClosures.thr_debug_dyn_o rts/dist/build/StgStartup.thr_debug_dyn_o rts/dist/build/StgStdThunks.thr_debug_dyn_o rts/dist/build/Updates.thr_debug_dyn_o rts/dist/build/AutoApply.thr_debug_dyn_o -fPIC -dynamic -optc-DTHREADED_RTS -optc-DDEBUG -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_thr_debug-ghc8.5.20180403.dylib "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.debug_dyn_o rts/dist/build/Arena.debug_dyn_o rts/dist/build/Capability.debug_dyn_o rts/dist/build/CheckUnload.debug_dyn_o rts/dist/build/ClosureFlags.debug_dyn_o rts/dist/build/Disassembler.debug_dyn_o rts/dist/build/FileLock.debug_dyn_o rts/dist/build/Globals.debug_dyn_o rts/dist/build/Hash.debug_dyn_o rts/dist/build/Hpc.debug_dyn_o rts/dist/build/HsFFI.debug_dyn_o rts/dist/build/Inlines.debug_dyn_o rts/dist/build/Interpreter.debug_dyn_o rts/dist/build/LdvProfile.debug_dyn_o rts/dist/build/Libdw.debug_dyn_o rts/dist/build/LibdwPool.debug_dyn_o rts/dist/build/Linker.debug_dyn_o rts/dist/build/Messages.debug_dyn_o rts/dist/build/OldARMAtomic.debug_dyn_o rts/dist/build/PathUtils.debug_dyn_o rts/dist/build/Pool.debug_dyn_o rts/dist/build/Printer.debug_dyn_o rts/dist/build/ProfHeap.debug_dyn_o rts/dist/build/ProfilerReport.debug_dyn_o rts/dist/build/ProfilerReportJson.debug_dyn_o rts/dist/build/Profiling.debug_dyn_o rts/dist/build/Proftimer.debug_dyn_o rts/dist/build/RaiseAsync.debug_dyn_o rts/dist/build/RetainerProfile.debug_dyn_o rts/dist/build/RetainerSet.debug_dyn_o rts/dist/build/RtsAPI.debug_dyn_o rts/dist/build/RtsDllMain.debug_dyn_o rts/dist/build/RtsFlags.debug_dyn_o rts/dist/build/RtsMain.debug_dyn_o rts/dist/build/RtsMessages.debug_dyn_o rts/dist/build/RtsStartup.debug_dyn_o rts/dist/build/RtsSymbolInfo.debug_dyn_o rts/dist/build/RtsSymbols.debug_dyn_o rts/dist/build/RtsUtils.debug_dyn_o rts/dist/build/STM.debug_dyn_o rts/dist/build/Schedule.debug_dyn_o rts/dist/build/Sparks.debug_dyn_o rts/dist/build/Stable.debug_dyn_o rts/dist/build/StaticPtrTable.debug_dyn_o rts/dist/build/Stats.debug_dyn_o rts/dist/build/StgCRun.debug_dyn_o rts/dist/build/StgPrimFloat.debug_dyn_o rts/dist/build/Task.debug_dyn_o rts/dist/build/ThreadLabels.debug_dyn_o rts/dist/build/ThreadPaused.debug_dyn_o rts/dist/build/Threads.debug_dyn_o rts/dist/build/Ticky.debug_dyn_o rts/dist/build/Timer.debug_dyn_o rts/dist/build/TopHandler.debug_dyn_o rts/dist/build/Trace.debug_dyn_o rts/dist/build/WSDeque.debug_dyn_o rts/dist/build/Weak.debug_dyn_o rts/dist/build/fs.debug_dyn_o rts/dist/build/xxhash.debug_dyn_o rts/dist/build/hooks/FlagDefaults.debug_dyn_o rts/dist/build/hooks/LongGCSync.debug_dyn_o rts/dist/build/hooks/MallocFail.debug_dyn_o rts/dist/build/hooks/OnExit.debug_dyn_o rts/dist/build/hooks/OutOfHeap.debug_dyn_o rts/dist/build/hooks/StackOverflow.debug_dyn_o rts/dist/build/sm/BlockAlloc.debug_dyn_o rts/dist/build/sm/CNF.debug_dyn_o rts/dist/build/sm/Compact.debug_dyn_o rts/dist/build/sm/Evac.debug_dyn_o rts/dist/build/sm/Evac_thr.debug_dyn_o rts/dist/build/sm/GC.debug_dyn_o rts/dist/build/sm/GCAux.debug_dyn_o rts/dist/build/sm/GCUtils.debug_dyn_o rts/dist/build/sm/MBlock.debug_dyn_o rts/dist/build/sm/MarkWeak.debug_dyn_o rts/dist/build/sm/Sanity.debug_dyn_o rts/dist/build/sm/Scav.debug_dyn_o rts/dist/build/sm/Scav_thr.debug_dyn_o rts/dist/build/sm/Storage.debug_dyn_o rts/dist/build/sm/Sweep.debug_dyn_o rts/dist/build/eventlog/EventLog.debug_dyn_o rts/dist/build/eventlog/EventLogWriter.debug_dyn_o rts/dist/build/linker/CacheFlush.debug_dyn_o rts/dist/build/linker/Elf.debug_dyn_o rts/dist/build/linker/LoadArchive.debug_dyn_o rts/dist/build/linker/M32Alloc.debug_dyn_o rts/dist/build/linker/MachO.debug_dyn_o rts/dist/build/linker/PEi386.debug_dyn_o rts/dist/build/linker/SymbolExtras.debug_dyn_o rts/dist/build/linker/elf_got.debug_dyn_o rts/dist/build/linker/elf_plt.debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.debug_dyn_o rts/dist/build/linker/elf_plt_arm.debug_dyn_o rts/dist/build/linker/elf_reloc.debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.debug_dyn_o rts/dist/build/linker/elf_util.debug_dyn_o rts/dist/build/posix/GetEnv.debug_dyn_o rts/dist/build/posix/GetTime.debug_dyn_o rts/dist/build/posix/Itimer.debug_dyn_o rts/dist/build/posix/OSMem.debug_dyn_o rts/dist/build/posix/OSThreads.debug_dyn_o rts/dist/build/posix/Select.debug_dyn_o rts/dist/build/posix/Signals.debug_dyn_o rts/dist/build/posix/TTY.debug_dyn_o rts/dist/build/Apply.debug_dyn_o rts/dist/build/Compact.debug_dyn_o rts/dist/build/Exception.debug_dyn_o rts/dist/build/HeapStackCheck.debug_dyn_o rts/dist/build/PrimOps.debug_dyn_o rts/dist/build/StgMiscClosures.debug_dyn_o rts/dist/build/StgStartup.debug_dyn_o rts/dist/build/StgStdThunks.debug_dyn_o rts/dist/build/Updates.debug_dyn_o rts/dist/build/AutoApply.debug_dyn_o -fPIC -dynamic -optc-DDEBUG -ticky -DTICKY_TICKY -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_debug-ghc8.5.20180403.dylib "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o -dyno libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Base.hs-boot -o libraries/base/dist-install/build/GHC/Base.o-boot -dyno libraries/base/dist-install/build/GHC/Base.dyn_o-boot "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Real.hs-boot -o libraries/base/dist-install/build/GHC/Real.o-boot -dyno libraries/base/dist-install/build/GHC/Real.dyn_o-boot "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/IO.hs-boot -o libraries/base/dist-install/build/GHC/IO.o-boot -dyno libraries/base/dist-install/build/GHC/IO.dyn_o-boot libraries/base/GHC/IO.hs-boot:9:12: error: • Failed to load interface for ‘GHC.Integer.Type’ There are files missing in the ‘integer-gmp-1.0.1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. • In the type signature: mplusIO :: IO a -> IO a -> IO a | 9 | mplusIO :: IO a -> IO a -> IO a | ^^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Apr 3 15:10:55 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 3 Apr 2018 11:10:55 -0400 Subject: 8.5 build failure In-Reply-To: References: Message-ID: <65B5ACA2-CCCE-4FDB-9600-FD81364AD6DE@cs.brynmawr.edu> I've hit this, too, in the last few days. It seems to be caused by some missing Makefile dependency. My solution has been to `make -j1` for a bit, then cut it off, then `make -j` again. I'm glad to know it's not just me. :) > On Apr 3, 2018, at 11:06 AM, John Leo wrote: > > Hi everyone, > > I pulled from head this morning and rebased my current work on it, and am getting a build error I've never seen before. I don't think it's due to any of my own changes, and everything built fine last time I tried just a couple days ago . I'd pulled both code and submodules. I did make clean, ./boot, ./configure, and then make. The last few lines of the output are below. This is on a Mac using GHC 8.2.2. Let me know if you need any more info. > > John > > "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o rts/dist/build/Capability.thr_debug_dyn_o rts/dist/build/CheckUnload.thr_debug_dyn_o rts/dist/build/ClosureFlags.thr_debug_dyn_o rts/dist/build/Disassembler.thr_debug_dyn_o rts/dist/build/FileLock.thr_debug_dyn_o rts/dist/build/Globals.thr_debug_dyn_o rts/dist/build/Hash.thr_debug_dyn_o rts/dist/build/Hpc.thr_debug_dyn_o rts/dist/build/HsFFI.thr_debug_dyn_o rts/dist/build/Inlines.thr_debug_dyn_o rts/dist/build/Interpreter.thr_debug_dyn_o rts/dist/build/LdvProfile.thr_debug_dyn_o rts/dist/build/Libdw.thr_debug_dyn_o rts/dist/build/LibdwPool.thr_debug_dyn_o rts/dist/build/Linker.thr_debug_dyn_o rts/dist/build/Messages.thr_debug_dyn_o rts/dist/build/OldARMAtomic.thr_debug_dyn_o rts/dist/build/PathUtils.thr_debug_dyn_o rts/dist/build/Pool.thr_debug_dyn_o rts/dist/build/Printer.thr_debug_dyn_o rts/dist/build/ProfHeap.thr_debug_dyn_o rts/dist/build/ProfilerReport.thr_debug_dyn_o rts/dist/build/ProfilerReportJson.thr_debug_dyn_o rts/dist/build/Profiling.thr_debug_dyn_o rts/dist/build/Proftimer.thr_debug_dyn_o rts/dist/build/RaiseAsync.thr_debug_dyn_o rts/dist/build/RetainerProfile.thr_debug_dyn_o rts/dist/build/RetainerSet.thr_debug_dyn_o rts/dist/build/RtsAPI.thr_debug_dyn_o rts/dist/build/RtsDllMain.thr_debug_dyn_o rts/dist/build/RtsFlags.thr_debug_dyn_o rts/dist/build/RtsMain.thr_debug_dyn_o rts/dist/build/RtsMessages.thr_debug_dyn_o rts/dist/build/RtsStartup.thr_debug_dyn_o rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o rts/dist/build/RtsSymbols.thr_debug_dyn_o rts/dist/build/RtsUtils.thr_debug_dyn_o rts/dist/build/STM.thr_debug_dyn_o rts/dist/build/Schedule.thr_debug_dyn_o rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o rts/dist/build/StaticPtrTable.thr_debug_dyn_o rts/dist/build/Stats.thr_debug_dyn_o rts/dist/build/StgCRun.thr_debug_dyn_o rts/dist/build/StgPrimFloat.thr_debug_dyn_o rts/dist/build/Task.thr_debug_dyn_o rts/dist/build/ThreadLabels.thr_debug_dyn_o rts/dist/build/ThreadPaused.thr_debug_dyn_o rts/dist/build/Threads.thr_debug_dyn_o rts/dist/build/Ticky.thr_debug_dyn_o rts/dist/build/Timer.thr_debug_dyn_o rts/dist/build/TopHandler.thr_debug_dyn_o rts/dist/build/Trace.thr_debug_dyn_o rts/dist/build/WSDeque.thr_debug_dyn_o rts/dist/build/Weak.thr_debug_dyn_o rts/dist/build/fs.thr_debug_dyn_o rts/dist/build/xxhash.thr_debug_dyn_o rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o rts/dist/build/hooks/MallocFail.thr_debug_dyn_o rts/dist/build/hooks/OnExit.thr_debug_dyn_o rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o rts/dist/build/sm/CNF.thr_debug_dyn_o rts/dist/build/sm/Compact.thr_debug_dyn_o rts/dist/build/sm/Evac.thr_debug_dyn_o rts/dist/build/sm/Evac_thr.thr_debug_dyn_o rts/dist/build/sm/GC.thr_debug_dyn_o rts/dist/build/sm/GCAux.thr_debug_dyn_o rts/dist/build/sm/GCUtils.thr_debug_dyn_o rts/dist/build/sm/MBlock.thr_debug_dyn_o rts/dist/build/sm/MarkWeak.thr_debug_dyn_o rts/dist/build/sm/Sanity.thr_debug_dyn_o rts/dist/build/sm/Scav.thr_debug_dyn_o rts/dist/build/sm/Scav_thr.thr_debug_dyn_o rts/dist/build/sm/Storage.thr_debug_dyn_o rts/dist/build/sm/Sweep.thr_debug_dyn_o rts/dist/build/eventlog/EventLog.thr_debug_dyn_o rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o rts/dist/build/linker/CacheFlush.thr_debug_dyn_o rts/dist/build/linker/Elf.thr_debug_dyn_o rts/dist/build/linker/LoadArchive.thr_debug_dyn_o rts/dist/build/linker/M32Alloc.thr_debug_dyn_o rts/dist/build/linker/MachO.thr_debug_dyn_o rts/dist/build/linker/PEi386.thr_debug_dyn_o rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o rts/dist/build/linker/elf_got.thr_debug_dyn_o rts/dist/build/linker/elf_plt.thr_debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o rts/dist/build/linker/elf_reloc.thr_debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_util.thr_debug_dyn_o rts/dist/build/posix/GetEnv.thr_debug_dyn_o rts/dist/build/posix/GetTime.thr_debug_dyn_o rts/dist/build/posix/Itimer.thr_debug_dyn_o rts/dist/build/posix/OSMem.thr_debug_dyn_o rts/dist/build/posix/OSThreads.thr_debug_dyn_o rts/dist/build/posix/Select.thr_debug_dyn_o rts/dist/build/posix/Signals.thr_debug_dyn_o rts/dist/build/posix/TTY.thr_debug_dyn_o rts/dist/build/Apply.thr_debug_dyn_o rts/dist/build/Compact.thr_debug_dyn_o rts/dist/build/Exception.thr_debug_dyn_o rts/dist/build/HeapStackCheck.thr_debug_dyn_o rts/dist/build/PrimOps.thr_debug_dyn_o rts/dist/build/StgMiscClosures.thr_debug_dyn_o rts/dist/build/StgStartup.thr_debug_dyn_o rts/dist/build/StgStdThunks.thr_debug_dyn_o rts/dist/build/Updates.thr_debug_dyn_o rts/dist/build/AutoApply.thr_debug_dyn_o -fPIC -dynamic -optc-DTHREADED_RTS -optc-DDEBUG -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_thr_debug-ghc8.5.20180403.dylib > "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.debug_dyn_o rts/dist/build/Arena.debug_dyn_o rts/dist/build/Capability.debug_dyn_o rts/dist/build/CheckUnload.debug_dyn_o rts/dist/build/ClosureFlags.debug_dyn_o rts/dist/build/Disassembler.debug_dyn_o rts/dist/build/FileLock.debug_dyn_o rts/dist/build/Globals.debug_dyn_o rts/dist/build/Hash.debug_dyn_o rts/dist/build/Hpc.debug_dyn_o rts/dist/build/HsFFI.debug_dyn_o rts/dist/build/Inlines.debug_dyn_o rts/dist/build/Interpreter.debug_dyn_o rts/dist/build/LdvProfile.debug_dyn_o rts/dist/build/Libdw.debug_dyn_o rts/dist/build/LibdwPool.debug_dyn_o rts/dist/build/Linker.debug_dyn_o rts/dist/build/Messages.debug_dyn_o rts/dist/build/OldARMAtomic.debug_dyn_o rts/dist/build/PathUtils.debug_dyn_o rts/dist/build/Pool.debug_dyn_o rts/dist/build/Printer.debug_dyn_o rts/dist/build/ProfHeap.debug_dyn_o rts/dist/build/ProfilerReport.debug_dyn_o rts/dist/build/ProfilerReportJson.debug_dyn_o rts/dist/build/Profiling.debug_dyn_o rts/dist/build/Proftimer.debug_dyn_o rts/dist/build/RaiseAsync.debug_dyn_o rts/dist/build/RetainerProfile.debug_dyn_o rts/dist/build/RetainerSet.debug_dyn_o rts/dist/build/RtsAPI.debug_dyn_o rts/dist/build/RtsDllMain.debug_dyn_o rts/dist/build/RtsFlags.debug_dyn_o rts/dist/build/RtsMain.debug_dyn_o rts/dist/build/RtsMessages.debug_dyn_o rts/dist/build/RtsStartup.debug_dyn_o rts/dist/build/RtsSymbolInfo.debug_dyn_o rts/dist/build/RtsSymbols.debug_dyn_o rts/dist/build/RtsUtils.debug_dyn_o rts/dist/build/STM.debug_dyn_o rts/dist/build/Schedule.debug_dyn_o rts/dist/build/Sparks.debug_dyn_o rts/dist/build/Stable.debug_dyn_o rts/dist/build/StaticPtrTable.debug_dyn_o rts/dist/build/Stats.debug_dyn_o rts/dist/build/StgCRun.debug_dyn_o rts/dist/build/StgPrimFloat.debug_dyn_o rts/dist/build/Task.debug_dyn_o rts/dist/build/ThreadLabels.debug_dyn_o rts/dist/build/ThreadPaused.debug_dyn_o rts/dist/build/Threads.debug_dyn_o rts/dist/build/Ticky.debug_dyn_o rts/dist/build/Timer.debug_dyn_o rts/dist/build/TopHandler.debug_dyn_o rts/dist/build/Trace.debug_dyn_o rts/dist/build/WSDeque.debug_dyn_o rts/dist/build/Weak.debug_dyn_o rts/dist/build/fs.debug_dyn_o rts/dist/build/xxhash.debug_dyn_o rts/dist/build/hooks/FlagDefaults.debug_dyn_o rts/dist/build/hooks/LongGCSync.debug_dyn_o rts/dist/build/hooks/MallocFail.debug_dyn_o rts/dist/build/hooks/OnExit.debug_dyn_o rts/dist/build/hooks/OutOfHeap.debug_dyn_o rts/dist/build/hooks/StackOverflow.debug_dyn_o rts/dist/build/sm/BlockAlloc.debug_dyn_o rts/dist/build/sm/CNF.debug_dyn_o rts/dist/build/sm/Compact.debug_dyn_o rts/dist/build/sm/Evac.debug_dyn_o rts/dist/build/sm/Evac_thr.debug_dyn_o rts/dist/build/sm/GC.debug_dyn_o rts/dist/build/sm/GCAux.debug_dyn_o rts/dist/build/sm/GCUtils.debug_dyn_o rts/dist/build/sm/MBlock.debug_dyn_o rts/dist/build/sm/MarkWeak.debug_dyn_o rts/dist/build/sm/Sanity.debug_dyn_o rts/dist/build/sm/Scav.debug_dyn_o rts/dist/build/sm/Scav_thr.debug_dyn_o rts/dist/build/sm/Storage.debug_dyn_o rts/dist/build/sm/Sweep.debug_dyn_o rts/dist/build/eventlog/EventLog.debug_dyn_o rts/dist/build/eventlog/EventLogWriter.debug_dyn_o rts/dist/build/linker/CacheFlush.debug_dyn_o rts/dist/build/linker/Elf.debug_dyn_o rts/dist/build/linker/LoadArchive.debug_dyn_o rts/dist/build/linker/M32Alloc.debug_dyn_o rts/dist/build/linker/MachO.debug_dyn_o rts/dist/build/linker/PEi386.debug_dyn_o rts/dist/build/linker/SymbolExtras.debug_dyn_o rts/dist/build/linker/elf_got.debug_dyn_o rts/dist/build/linker/elf_plt.debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.debug_dyn_o rts/dist/build/linker/elf_plt_arm.debug_dyn_o rts/dist/build/linker/elf_reloc.debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.debug_dyn_o rts/dist/build/linker/elf_util.debug_dyn_o rts/dist/build/posix/GetEnv.debug_dyn_o rts/dist/build/posix/GetTime.debug_dyn_o rts/dist/build/posix/Itimer.debug_dyn_o rts/dist/build/posix/OSMem.debug_dyn_o rts/dist/build/posix/OSThreads.debug_dyn_o rts/dist/build/posix/Select.debug_dyn_o rts/dist/build/posix/Signals.debug_dyn_o rts/dist/build/posix/TTY.debug_dyn_o rts/dist/build/Apply.debug_dyn_o rts/dist/build/Compact.debug_dyn_o rts/dist/build/Exception.debug_dyn_o rts/dist/build/HeapStackCheck.debug_dyn_o rts/dist/build/PrimOps.debug_dyn_o rts/dist/build/StgMiscClosures.debug_dyn_o rts/dist/build/StgStartup.debug_dyn_o rts/dist/build/StgStdThunks.debug_dyn_o rts/dist/build/Updates.debug_dyn_o rts/dist/build/AutoApply.debug_dyn_o -fPIC -dynamic -optc-DDEBUG -ticky -DTICKY_TICKY -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_debug-ghc8.5.20180403.dylib > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o -dyno libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Base.hs-boot -o libraries/base/dist-install/build/GHC/Base.o-boot -dyno libraries/base/dist-install/build/GHC/Base.dyn_o-boot > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Real.hs-boot -o libraries/base/dist-install/build/GHC/Real.o-boot -dyno libraries/base/dist-install/build/GHC/Real.dyn_o-boot > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/IO.hs-boot -o libraries/base/dist-install/build/GHC/IO.o-boot -dyno libraries/base/dist-install/build/GHC/IO.dyn_o-boot > > libraries/base/GHC/IO.hs-boot:9:12: error: > • Failed to load interface for ‘GHC.Integer.Type’ > There are files missing in the ‘integer-gmp-1.0.1.0’ package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > • In the type signature: mplusIO :: IO a -> IO a -> IO a > | > 9 | mplusIO :: IO a -> IO a -> IO a > | ^^^^^^^^^^^^^^^^^^^^ > make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Tue Apr 3 15:13:11 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 3 Apr 2018 18:13:11 +0300 Subject: 8.5 build failure In-Reply-To: References: Message-ID: Does the error go away if you restart the build without cleaning? I had the same error on my nightly builder, but it worked when I restarted the build. Ömer 2018-04-03 18:06 GMT+03:00 John Leo : > Hi everyone, > > I pulled from head this morning and rebased my current work on it, and am > getting a build error I've never seen before. I don't think it's due to any > of my own changes, and everything built fine last time I tried just a couple > days ago . I'd pulled both code and submodules. I did make clean, ./boot, > ./configure, and then make. The last few lines of the output are below. This > is on a Mac using GHC 8.2.2. Let me know if you need any more info. > > John > > "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy > -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath > -optl-Wl, at loader_path `cat rts/dist/libs.depend` > rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o > rts/dist/build/Capability.thr_debug_dyn_o > rts/dist/build/CheckUnload.thr_debug_dyn_o > rts/dist/build/ClosureFlags.thr_debug_dyn_o > rts/dist/build/Disassembler.thr_debug_dyn_o > rts/dist/build/FileLock.thr_debug_dyn_o > rts/dist/build/Globals.thr_debug_dyn_o rts/dist/build/Hash.thr_debug_dyn_o > rts/dist/build/Hpc.thr_debug_dyn_o rts/dist/build/HsFFI.thr_debug_dyn_o > rts/dist/build/Inlines.thr_debug_dyn_o > rts/dist/build/Interpreter.thr_debug_dyn_o > rts/dist/build/LdvProfile.thr_debug_dyn_o > rts/dist/build/Libdw.thr_debug_dyn_o > rts/dist/build/LibdwPool.thr_debug_dyn_o > rts/dist/build/Linker.thr_debug_dyn_o > rts/dist/build/Messages.thr_debug_dyn_o > rts/dist/build/OldARMAtomic.thr_debug_dyn_o > rts/dist/build/PathUtils.thr_debug_dyn_o rts/dist/build/Pool.thr_debug_dyn_o > rts/dist/build/Printer.thr_debug_dyn_o > rts/dist/build/ProfHeap.thr_debug_dyn_o > rts/dist/build/ProfilerReport.thr_debug_dyn_o > rts/dist/build/ProfilerReportJson.thr_debug_dyn_o > rts/dist/build/Profiling.thr_debug_dyn_o > rts/dist/build/Proftimer.thr_debug_dyn_o > rts/dist/build/RaiseAsync.thr_debug_dyn_o > rts/dist/build/RetainerProfile.thr_debug_dyn_o > rts/dist/build/RetainerSet.thr_debug_dyn_o > rts/dist/build/RtsAPI.thr_debug_dyn_o > rts/dist/build/RtsDllMain.thr_debug_dyn_o > rts/dist/build/RtsFlags.thr_debug_dyn_o > rts/dist/build/RtsMain.thr_debug_dyn_o > rts/dist/build/RtsMessages.thr_debug_dyn_o > rts/dist/build/RtsStartup.thr_debug_dyn_o > rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o > rts/dist/build/RtsSymbols.thr_debug_dyn_o > rts/dist/build/RtsUtils.thr_debug_dyn_o rts/dist/build/STM.thr_debug_dyn_o > rts/dist/build/Schedule.thr_debug_dyn_o > rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o > rts/dist/build/StaticPtrTable.thr_debug_dyn_o > rts/dist/build/Stats.thr_debug_dyn_o rts/dist/build/StgCRun.thr_debug_dyn_o > rts/dist/build/StgPrimFloat.thr_debug_dyn_o > rts/dist/build/Task.thr_debug_dyn_o > rts/dist/build/ThreadLabels.thr_debug_dyn_o > rts/dist/build/ThreadPaused.thr_debug_dyn_o > rts/dist/build/Threads.thr_debug_dyn_o rts/dist/build/Ticky.thr_debug_dyn_o > rts/dist/build/Timer.thr_debug_dyn_o > rts/dist/build/TopHandler.thr_debug_dyn_o > rts/dist/build/Trace.thr_debug_dyn_o rts/dist/build/WSDeque.thr_debug_dyn_o > rts/dist/build/Weak.thr_debug_dyn_o rts/dist/build/fs.thr_debug_dyn_o > rts/dist/build/xxhash.thr_debug_dyn_o > rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o > rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o > rts/dist/build/hooks/MallocFail.thr_debug_dyn_o > rts/dist/build/hooks/OnExit.thr_debug_dyn_o > rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o > rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o > rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o > rts/dist/build/sm/CNF.thr_debug_dyn_o > rts/dist/build/sm/Compact.thr_debug_dyn_o > rts/dist/build/sm/Evac.thr_debug_dyn_o > rts/dist/build/sm/Evac_thr.thr_debug_dyn_o > rts/dist/build/sm/GC.thr_debug_dyn_o rts/dist/build/sm/GCAux.thr_debug_dyn_o > rts/dist/build/sm/GCUtils.thr_debug_dyn_o > rts/dist/build/sm/MBlock.thr_debug_dyn_o > rts/dist/build/sm/MarkWeak.thr_debug_dyn_o > rts/dist/build/sm/Sanity.thr_debug_dyn_o > rts/dist/build/sm/Scav.thr_debug_dyn_o > rts/dist/build/sm/Scav_thr.thr_debug_dyn_o > rts/dist/build/sm/Storage.thr_debug_dyn_o > rts/dist/build/sm/Sweep.thr_debug_dyn_o > rts/dist/build/eventlog/EventLog.thr_debug_dyn_o > rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o > rts/dist/build/linker/CacheFlush.thr_debug_dyn_o > rts/dist/build/linker/Elf.thr_debug_dyn_o > rts/dist/build/linker/LoadArchive.thr_debug_dyn_o > rts/dist/build/linker/M32Alloc.thr_debug_dyn_o > rts/dist/build/linker/MachO.thr_debug_dyn_o > rts/dist/build/linker/PEi386.thr_debug_dyn_o > rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o > rts/dist/build/linker/elf_got.thr_debug_dyn_o > rts/dist/build/linker/elf_plt.thr_debug_dyn_o > rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o > rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o > rts/dist/build/linker/elf_reloc.thr_debug_dyn_o > rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o > rts/dist/build/linker/elf_util.thr_debug_dyn_o > rts/dist/build/posix/GetEnv.thr_debug_dyn_o > rts/dist/build/posix/GetTime.thr_debug_dyn_o > rts/dist/build/posix/Itimer.thr_debug_dyn_o > rts/dist/build/posix/OSMem.thr_debug_dyn_o > rts/dist/build/posix/OSThreads.thr_debug_dyn_o > rts/dist/build/posix/Select.thr_debug_dyn_o > rts/dist/build/posix/Signals.thr_debug_dyn_o > rts/dist/build/posix/TTY.thr_debug_dyn_o > rts/dist/build/Apply.thr_debug_dyn_o rts/dist/build/Compact.thr_debug_dyn_o > rts/dist/build/Exception.thr_debug_dyn_o > rts/dist/build/HeapStackCheck.thr_debug_dyn_o > rts/dist/build/PrimOps.thr_debug_dyn_o > rts/dist/build/StgMiscClosures.thr_debug_dyn_o > rts/dist/build/StgStartup.thr_debug_dyn_o > rts/dist/build/StgStdThunks.thr_debug_dyn_o > rts/dist/build/Updates.thr_debug_dyn_o > rts/dist/build/AutoApply.thr_debug_dyn_o -fPIC -dynamic -optc-DTHREADED_RTS > -optc-DDEBUG -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist > -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header > -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts > -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build > -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 > -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o > rts/dist/build/libHSrts_thr_debug-ghc8.5.20180403.dylib > "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy > -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath > -optl-Wl, at loader_path `cat rts/dist/libs.depend` > rts/dist/build/Adjustor.debug_dyn_o rts/dist/build/Arena.debug_dyn_o > rts/dist/build/Capability.debug_dyn_o rts/dist/build/CheckUnload.debug_dyn_o > rts/dist/build/ClosureFlags.debug_dyn_o > rts/dist/build/Disassembler.debug_dyn_o rts/dist/build/FileLock.debug_dyn_o > rts/dist/build/Globals.debug_dyn_o rts/dist/build/Hash.debug_dyn_o > rts/dist/build/Hpc.debug_dyn_o rts/dist/build/HsFFI.debug_dyn_o > rts/dist/build/Inlines.debug_dyn_o rts/dist/build/Interpreter.debug_dyn_o > rts/dist/build/LdvProfile.debug_dyn_o rts/dist/build/Libdw.debug_dyn_o > rts/dist/build/LibdwPool.debug_dyn_o rts/dist/build/Linker.debug_dyn_o > rts/dist/build/Messages.debug_dyn_o rts/dist/build/OldARMAtomic.debug_dyn_o > rts/dist/build/PathUtils.debug_dyn_o rts/dist/build/Pool.debug_dyn_o > rts/dist/build/Printer.debug_dyn_o rts/dist/build/ProfHeap.debug_dyn_o > rts/dist/build/ProfilerReport.debug_dyn_o > rts/dist/build/ProfilerReportJson.debug_dyn_o > rts/dist/build/Profiling.debug_dyn_o rts/dist/build/Proftimer.debug_dyn_o > rts/dist/build/RaiseAsync.debug_dyn_o > rts/dist/build/RetainerProfile.debug_dyn_o > rts/dist/build/RetainerSet.debug_dyn_o rts/dist/build/RtsAPI.debug_dyn_o > rts/dist/build/RtsDllMain.debug_dyn_o rts/dist/build/RtsFlags.debug_dyn_o > rts/dist/build/RtsMain.debug_dyn_o rts/dist/build/RtsMessages.debug_dyn_o > rts/dist/build/RtsStartup.debug_dyn_o > rts/dist/build/RtsSymbolInfo.debug_dyn_o > rts/dist/build/RtsSymbols.debug_dyn_o rts/dist/build/RtsUtils.debug_dyn_o > rts/dist/build/STM.debug_dyn_o rts/dist/build/Schedule.debug_dyn_o > rts/dist/build/Sparks.debug_dyn_o rts/dist/build/Stable.debug_dyn_o > rts/dist/build/StaticPtrTable.debug_dyn_o rts/dist/build/Stats.debug_dyn_o > rts/dist/build/StgCRun.debug_dyn_o rts/dist/build/StgPrimFloat.debug_dyn_o > rts/dist/build/Task.debug_dyn_o rts/dist/build/ThreadLabels.debug_dyn_o > rts/dist/build/ThreadPaused.debug_dyn_o rts/dist/build/Threads.debug_dyn_o > rts/dist/build/Ticky.debug_dyn_o rts/dist/build/Timer.debug_dyn_o > rts/dist/build/TopHandler.debug_dyn_o rts/dist/build/Trace.debug_dyn_o > rts/dist/build/WSDeque.debug_dyn_o rts/dist/build/Weak.debug_dyn_o > rts/dist/build/fs.debug_dyn_o rts/dist/build/xxhash.debug_dyn_o > rts/dist/build/hooks/FlagDefaults.debug_dyn_o > rts/dist/build/hooks/LongGCSync.debug_dyn_o > rts/dist/build/hooks/MallocFail.debug_dyn_o > rts/dist/build/hooks/OnExit.debug_dyn_o > rts/dist/build/hooks/OutOfHeap.debug_dyn_o > rts/dist/build/hooks/StackOverflow.debug_dyn_o > rts/dist/build/sm/BlockAlloc.debug_dyn_o rts/dist/build/sm/CNF.debug_dyn_o > rts/dist/build/sm/Compact.debug_dyn_o rts/dist/build/sm/Evac.debug_dyn_o > rts/dist/build/sm/Evac_thr.debug_dyn_o rts/dist/build/sm/GC.debug_dyn_o > rts/dist/build/sm/GCAux.debug_dyn_o rts/dist/build/sm/GCUtils.debug_dyn_o > rts/dist/build/sm/MBlock.debug_dyn_o rts/dist/build/sm/MarkWeak.debug_dyn_o > rts/dist/build/sm/Sanity.debug_dyn_o rts/dist/build/sm/Scav.debug_dyn_o > rts/dist/build/sm/Scav_thr.debug_dyn_o rts/dist/build/sm/Storage.debug_dyn_o > rts/dist/build/sm/Sweep.debug_dyn_o > rts/dist/build/eventlog/EventLog.debug_dyn_o > rts/dist/build/eventlog/EventLogWriter.debug_dyn_o > rts/dist/build/linker/CacheFlush.debug_dyn_o > rts/dist/build/linker/Elf.debug_dyn_o > rts/dist/build/linker/LoadArchive.debug_dyn_o > rts/dist/build/linker/M32Alloc.debug_dyn_o > rts/dist/build/linker/MachO.debug_dyn_o > rts/dist/build/linker/PEi386.debug_dyn_o > rts/dist/build/linker/SymbolExtras.debug_dyn_o > rts/dist/build/linker/elf_got.debug_dyn_o > rts/dist/build/linker/elf_plt.debug_dyn_o > rts/dist/build/linker/elf_plt_aarch64.debug_dyn_o > rts/dist/build/linker/elf_plt_arm.debug_dyn_o > rts/dist/build/linker/elf_reloc.debug_dyn_o > rts/dist/build/linker/elf_reloc_aarch64.debug_dyn_o > rts/dist/build/linker/elf_util.debug_dyn_o > rts/dist/build/posix/GetEnv.debug_dyn_o > rts/dist/build/posix/GetTime.debug_dyn_o > rts/dist/build/posix/Itimer.debug_dyn_o > rts/dist/build/posix/OSMem.debug_dyn_o > rts/dist/build/posix/OSThreads.debug_dyn_o > rts/dist/build/posix/Select.debug_dyn_o > rts/dist/build/posix/Signals.debug_dyn_o > rts/dist/build/posix/TTY.debug_dyn_o rts/dist/build/Apply.debug_dyn_o > rts/dist/build/Compact.debug_dyn_o rts/dist/build/Exception.debug_dyn_o > rts/dist/build/HeapStackCheck.debug_dyn_o rts/dist/build/PrimOps.debug_dyn_o > rts/dist/build/StgMiscClosures.debug_dyn_o > rts/dist/build/StgStartup.debug_dyn_o > rts/dist/build/StgStdThunks.debug_dyn_o rts/dist/build/Updates.debug_dyn_o > rts/dist/build/AutoApply.debug_dyn_o -fPIC -dynamic -optc-DDEBUG -ticky > -DTICKY_TICKY -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist > -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header > -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts > -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build > -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 > -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o > rts/dist/build/libHSrts_debug-ghc8.5.20180403.dylib > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i > -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build > -Ilibraries/ghc-prim/dist-install/build > -ilibraries/ghc-prim/dist-install/build/./autogen > -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. > -optP-include > -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h > -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint > -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build > -hidir libraries/ghc-prim/dist-install/build -stubdir > libraries/ghc-prim/dist-install/build -dynamic-too -c > libraries/ghc-prim/./GHC/CString.hs -o > libraries/ghc-prim/dist-install/build/GHC/CString.o -dyno > libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i > -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build > -Ilibraries/ghc-prim/dist-install/build > -ilibraries/ghc-prim/dist-install/build/./autogen > -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. > -optP-include > -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h > -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint > -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build > -hidir libraries/ghc-prim/dist-install/build -stubdir > libraries/ghc-prim/dist-install/build -dynamic-too -c > libraries/ghc-prim/./GHC/IntWord64.hs -o > libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno > libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i > -ilibraries/base/. -ilibraries/base/dist-install/build > -Ilibraries/base/dist-install/build > -ilibraries/base/dist-install/build/./autogen > -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include > -Ilibraries/base/dist-install/build/include > -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include > -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id > ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts > -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db > -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build > -hidir libraries/base/dist-install/build -stubdir > libraries/base/dist-install/build -dynamic-too -c > libraries/base/./GHC/Base.hs-boot -o > libraries/base/dist-install/build/GHC/Base.o-boot -dyno > libraries/base/dist-install/build/GHC/Base.dyn_o-boot > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i > -ilibraries/base/. -ilibraries/base/dist-install/build > -Ilibraries/base/dist-install/build > -ilibraries/base/dist-install/build/./autogen > -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include > -Ilibraries/base/dist-install/build/include > -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include > -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id > ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts > -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db > -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build > -hidir libraries/base/dist-install/build -stubdir > libraries/base/dist-install/build -dynamic-too -c > libraries/base/./GHC/Real.hs-boot -o > libraries/base/dist-install/build/GHC/Real.o-boot -dyno > libraries/base/dist-install/build/GHC/Real.dyn_o-boot > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m > -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i > -ilibraries/base/. -ilibraries/base/dist-install/build > -Ilibraries/base/dist-install/build > -ilibraries/base/dist-install/build/./autogen > -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include > -Ilibraries/base/dist-install/build/include > -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include > -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id > ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts > -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db > -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags > -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build > -hidir libraries/base/dist-install/build -stubdir > libraries/base/dist-install/build -dynamic-too -c > libraries/base/./GHC/IO.hs-boot -o > libraries/base/dist-install/build/GHC/IO.o-boot -dyno > libraries/base/dist-install/build/GHC/IO.dyn_o-boot > > libraries/base/GHC/IO.hs-boot:9:12: error: > • Failed to load interface for ‘GHC.Integer.Type’ > There are files missing in the ‘integer-gmp-1.0.1.0’ package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > • In the type signature: mplusIO :: IO a -> IO a -> IO a > | > 9 | mplusIO :: IO a -> IO a -> IO a > | ^^^^^^^^^^^^^^^^^^^^ > make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From alan.zimm at gmail.com Tue Apr 3 15:18:38 2018 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 3 Apr 2018 17:18:38 +0200 Subject: 8.5 build failure In-Reply-To: References: Message-ID: I think there was a commit recently that requires you to reconfigure. > > I have just committed 4de585a which lifts the MAX_PATH restrictions for Haskell programs > compiled with GHC 8.6 for Windows users. > > However when you update, you *MUST* run configure again. This counts for ALL platforms otherwise your build will suffer a not so friendly failure. > > If you're using Hadrian to build, you must manually update the submodule to HEAD of master > as the Hadrian submodule hasn't been bumped yet. > > Regards > Tamar Alan On 3 April 2018 at 17:09, John Leo wrote: > One thing I should note is that I believe since the last time I'd built I > updated Mac OS to 10.13.4, if that is relevant. Note that stage 1 built > fine; the failure occurs about 22 minutes into a build that typically takes > 30 minute on my machine. > > John > > On Tue, Apr 3, 2018 at 8:06 AM, John Leo wrote: > >> Hi everyone, >> >> I pulled from head this morning and rebased my current work on it, and am >> getting a build error I've never seen before. I don't think it's due to any >> of my own changes, and everything built fine last time I tried just a >> couple days ago . I'd pulled both code and submodules. I did make clean, >> ./boot, ./configure, and then make. The last few lines of the output are >> below. This is on a Mac using GHC 8.2.2. Let me know if you need any more >> info. >> >> John >> >> "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload >> deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath >> -optl-Wl, at loader_path `cat rts/dist/libs.depend` >> rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o >> rts/dist/build/Capability.thr_debug_dyn_o rts/dist/build/CheckUnload.thr_debug_dyn_o >> rts/dist/build/ClosureFlags.thr_debug_dyn_o >> rts/dist/build/Disassembler.thr_debug_dyn_o >> rts/dist/build/FileLock.thr_debug_dyn_o rts/dist/build/Globals.thr_debug_dyn_o >> rts/dist/build/Hash.thr_debug_dyn_o rts/dist/build/Hpc.thr_debug_dyn_o >> rts/dist/build/HsFFI.thr_debug_dyn_o rts/dist/build/Inlines.thr_debug_dyn_o >> rts/dist/build/Interpreter.thr_debug_dyn_o rts/dist/build/LdvProfile.thr_debug_dyn_o >> rts/dist/build/Libdw.thr_debug_dyn_o rts/dist/build/LibdwPool.thr_debug_dyn_o >> rts/dist/build/Linker.thr_debug_dyn_o rts/dist/build/Messages.thr_debug_dyn_o >> rts/dist/build/OldARMAtomic.thr_debug_dyn_o >> rts/dist/build/PathUtils.thr_debug_dyn_o rts/dist/build/Pool.thr_debug_dyn_o >> rts/dist/build/Printer.thr_debug_dyn_o rts/dist/build/ProfHeap.thr_debug_dyn_o >> rts/dist/build/ProfilerReport.thr_debug_dyn_o >> rts/dist/build/ProfilerReportJson.thr_debug_dyn_o >> rts/dist/build/Profiling.thr_debug_dyn_o rts/dist/build/Proftimer.thr_debug_dyn_o >> rts/dist/build/RaiseAsync.thr_debug_dyn_o rts/dist/build/RetainerProfile.thr_debug_dyn_o >> rts/dist/build/RetainerSet.thr_debug_dyn_o rts/dist/build/RtsAPI.thr_debug_dyn_o >> rts/dist/build/RtsDllMain.thr_debug_dyn_o rts/dist/build/RtsFlags.thr_debug_dyn_o >> rts/dist/build/RtsMain.thr_debug_dyn_o rts/dist/build/RtsMessages.thr_debug_dyn_o >> rts/dist/build/RtsStartup.thr_debug_dyn_o rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o >> rts/dist/build/RtsSymbols.thr_debug_dyn_o rts/dist/build/RtsUtils.thr_debug_dyn_o >> rts/dist/build/STM.thr_debug_dyn_o rts/dist/build/Schedule.thr_debug_dyn_o >> rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o >> rts/dist/build/StaticPtrTable.thr_debug_dyn_o >> rts/dist/build/Stats.thr_debug_dyn_o rts/dist/build/StgCRun.thr_debug_dyn_o >> rts/dist/build/StgPrimFloat.thr_debug_dyn_o >> rts/dist/build/Task.thr_debug_dyn_o rts/dist/build/ThreadLabels.thr_debug_dyn_o >> rts/dist/build/ThreadPaused.thr_debug_dyn_o >> rts/dist/build/Threads.thr_debug_dyn_o rts/dist/build/Ticky.thr_debug_dyn_o >> rts/dist/build/Timer.thr_debug_dyn_o rts/dist/build/TopHandler.thr_debug_dyn_o >> rts/dist/build/Trace.thr_debug_dyn_o rts/dist/build/WSDeque.thr_debug_dyn_o >> rts/dist/build/Weak.thr_debug_dyn_o rts/dist/build/fs.thr_debug_dyn_o >> rts/dist/build/xxhash.thr_debug_dyn_o rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o >> rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o >> rts/dist/build/hooks/MallocFail.thr_debug_dyn_o >> rts/dist/build/hooks/OnExit.thr_debug_dyn_o >> rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o >> rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o >> rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o >> rts/dist/build/sm/CNF.thr_debug_dyn_o rts/dist/build/sm/Compact.thr_debug_dyn_o >> rts/dist/build/sm/Evac.thr_debug_dyn_o rts/dist/build/sm/Evac_thr.thr_debug_dyn_o >> rts/dist/build/sm/GC.thr_debug_dyn_o rts/dist/build/sm/GCAux.thr_debug_dyn_o >> rts/dist/build/sm/GCUtils.thr_debug_dyn_o rts/dist/build/sm/MBlock.thr_debug_dyn_o >> rts/dist/build/sm/MarkWeak.thr_debug_dyn_o rts/dist/build/sm/Sanity.thr_debug_dyn_o >> rts/dist/build/sm/Scav.thr_debug_dyn_o rts/dist/build/sm/Scav_thr.thr_debug_dyn_o >> rts/dist/build/sm/Storage.thr_debug_dyn_o rts/dist/build/sm/Sweep.thr_debug_dyn_o >> rts/dist/build/eventlog/EventLog.thr_debug_dyn_o >> rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o >> rts/dist/build/linker/CacheFlush.thr_debug_dyn_o >> rts/dist/build/linker/Elf.thr_debug_dyn_o rts/dist/build/linker/LoadArchive.thr_debug_dyn_o >> rts/dist/build/linker/M32Alloc.thr_debug_dyn_o >> rts/dist/build/linker/MachO.thr_debug_dyn_o >> rts/dist/build/linker/PEi386.thr_debug_dyn_o >> rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o >> rts/dist/build/linker/elf_got.thr_debug_dyn_o >> rts/dist/build/linker/elf_plt.thr_debug_dyn_o >> rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o >> rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o >> rts/dist/build/linker/elf_reloc.thr_debug_dyn_o >> rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o >> rts/dist/build/linker/elf_util.thr_debug_dyn_o >> rts/dist/build/posix/GetEnv.thr_debug_dyn_o >> rts/dist/build/posix/GetTime.thr_debug_dyn_o >> rts/dist/build/posix/Itimer.thr_debug_dyn_o >> rts/dist/build/posix/OSMem.thr_debug_dyn_o rts/dist/build/posix/OSThreads.thr_debug_dyn_o >> rts/dist/build/posix/Select.thr_debug_dyn_o >> rts/dist/build/posix/Signals.thr_debug_dyn_o >> rts/dist/build/posix/TTY.thr_debug_dyn_o rts/dist/build/Apply.thr_debug_dyn_o >> rts/dist/build/Compact.thr_debug_dyn_o rts/dist/build/Exception.thr_debug_dyn_o >> rts/dist/build/HeapStackCheck.thr_debug_dyn_o >> rts/dist/build/PrimOps.thr_debug_dyn_o rts/dist/build/StgMiscClosures.thr_debug_dyn_o >> rts/dist/build/StgStartup.thr_debug_dyn_o rts/dist/build/StgStdThunks.thr_debug_dyn_o >> rts/dist/build/Updates.thr_debug_dyn_o rts/dist/build/AutoApply.thr_debug_dyn_o >> -fPIC -dynamic -optc-DTHREADED_RTS -optc-DDEBUG -eventlog -O -H64m -Wall >> -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header >> -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build >> -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE >> -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen >> -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 >> -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_thr_de >> bug-ghc8.5.20180403.dylib >> "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload >> deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath >> -optl-Wl, at loader_path `cat rts/dist/libs.depend` >> rts/dist/build/Adjustor.debug_dyn_o rts/dist/build/Arena.debug_dyn_o >> rts/dist/build/Capability.debug_dyn_o rts/dist/build/CheckUnload.debug_dyn_o >> rts/dist/build/ClosureFlags.debug_dyn_o rts/dist/build/Disassembler.debug_dyn_o >> rts/dist/build/FileLock.debug_dyn_o rts/dist/build/Globals.debug_dyn_o >> rts/dist/build/Hash.debug_dyn_o rts/dist/build/Hpc.debug_dyn_o >> rts/dist/build/HsFFI.debug_dyn_o rts/dist/build/Inlines.debug_dyn_o >> rts/dist/build/Interpreter.debug_dyn_o rts/dist/build/LdvProfile.debug_dyn_o >> rts/dist/build/Libdw.debug_dyn_o rts/dist/build/LibdwPool.debug_dyn_o >> rts/dist/build/Linker.debug_dyn_o rts/dist/build/Messages.debug_dyn_o >> rts/dist/build/OldARMAtomic.debug_dyn_o rts/dist/build/PathUtils.debug_dyn_o >> rts/dist/build/Pool.debug_dyn_o rts/dist/build/Printer.debug_dyn_o >> rts/dist/build/ProfHeap.debug_dyn_o rts/dist/build/ProfilerReport.debug_dyn_o >> rts/dist/build/ProfilerReportJson.debug_dyn_o >> rts/dist/build/Profiling.debug_dyn_o rts/dist/build/Proftimer.debug_dyn_o >> rts/dist/build/RaiseAsync.debug_dyn_o rts/dist/build/RetainerProfile.debug_dyn_o >> rts/dist/build/RetainerSet.debug_dyn_o rts/dist/build/RtsAPI.debug_dyn_o >> rts/dist/build/RtsDllMain.debug_dyn_o rts/dist/build/RtsFlags.debug_dyn_o >> rts/dist/build/RtsMain.debug_dyn_o rts/dist/build/RtsMessages.debug_dyn_o >> rts/dist/build/RtsStartup.debug_dyn_o rts/dist/build/RtsSymbolInfo.debug_dyn_o >> rts/dist/build/RtsSymbols.debug_dyn_o rts/dist/build/RtsUtils.debug_dyn_o >> rts/dist/build/STM.debug_dyn_o rts/dist/build/Schedule.debug_dyn_o >> rts/dist/build/Sparks.debug_dyn_o rts/dist/build/Stable.debug_dyn_o >> rts/dist/build/StaticPtrTable.debug_dyn_o rts/dist/build/Stats.debug_dyn_o >> rts/dist/build/StgCRun.debug_dyn_o rts/dist/build/StgPrimFloat.debug_dyn_o >> rts/dist/build/Task.debug_dyn_o rts/dist/build/ThreadLabels.debug_dyn_o >> rts/dist/build/ThreadPaused.debug_dyn_o rts/dist/build/Threads.debug_dyn_o >> rts/dist/build/Ticky.debug_dyn_o rts/dist/build/Timer.debug_dyn_o >> rts/dist/build/TopHandler.debug_dyn_o rts/dist/build/Trace.debug_dyn_o >> rts/dist/build/WSDeque.debug_dyn_o rts/dist/build/Weak.debug_dyn_o >> rts/dist/build/fs.debug_dyn_o rts/dist/build/xxhash.debug_dyn_o >> rts/dist/build/hooks/FlagDefaults.debug_dyn_o >> rts/dist/build/hooks/LongGCSync.debug_dyn_o >> rts/dist/build/hooks/MallocFail.debug_dyn_o >> rts/dist/build/hooks/OnExit.debug_dyn_o rts/dist/build/hooks/OutOfHeap.debug_dyn_o >> rts/dist/build/hooks/StackOverflow.debug_dyn_o >> rts/dist/build/sm/BlockAlloc.debug_dyn_o rts/dist/build/sm/CNF.debug_dyn_o >> rts/dist/build/sm/Compact.debug_dyn_o rts/dist/build/sm/Evac.debug_dyn_o >> rts/dist/build/sm/Evac_thr.debug_dyn_o rts/dist/build/sm/GC.debug_dyn_o >> rts/dist/build/sm/GCAux.debug_dyn_o rts/dist/build/sm/GCUtils.debug_dyn_o >> rts/dist/build/sm/MBlock.debug_dyn_o rts/dist/build/sm/MarkWeak.debug_dyn_o >> rts/dist/build/sm/Sanity.debug_dyn_o rts/dist/build/sm/Scav.debug_dyn_o >> rts/dist/build/sm/Scav_thr.debug_dyn_o rts/dist/build/sm/Storage.debug_dyn_o >> rts/dist/build/sm/Sweep.debug_dyn_o rts/dist/build/eventlog/EventLog.debug_dyn_o >> rts/dist/build/eventlog/EventLogWriter.debug_dyn_o >> rts/dist/build/linker/CacheFlush.debug_dyn_o >> rts/dist/build/linker/Elf.debug_dyn_o rts/dist/build/linker/LoadArchive.debug_dyn_o >> rts/dist/build/linker/M32Alloc.debug_dyn_o rts/dist/build/linker/MachO.debug_dyn_o >> rts/dist/build/linker/PEi386.debug_dyn_o rts/dist/build/linker/SymbolExtras.debug_dyn_o >> rts/dist/build/linker/elf_got.debug_dyn_o rts/dist/build/linker/elf_plt.debug_dyn_o >> rts/dist/build/linker/elf_plt_aarch64.debug_dyn_o >> rts/dist/build/linker/elf_plt_arm.debug_dyn_o >> rts/dist/build/linker/elf_reloc.debug_dyn_o >> rts/dist/build/linker/elf_reloc_aarch64.debug_dyn_o >> rts/dist/build/linker/elf_util.debug_dyn_o rts/dist/build/posix/GetEnv.debug_dyn_o >> rts/dist/build/posix/GetTime.debug_dyn_o rts/dist/build/posix/Itimer.debug_dyn_o >> rts/dist/build/posix/OSMem.debug_dyn_o rts/dist/build/posix/OSThreads.debug_dyn_o >> rts/dist/build/posix/Select.debug_dyn_o rts/dist/build/posix/Signals.debug_dyn_o >> rts/dist/build/posix/TTY.debug_dyn_o rts/dist/build/Apply.debug_dyn_o >> rts/dist/build/Compact.debug_dyn_o rts/dist/build/Exception.debug_dyn_o >> rts/dist/build/HeapStackCheck.debug_dyn_o rts/dist/build/PrimOps.debug_dyn_o >> rts/dist/build/StgMiscClosures.debug_dyn_o rts/dist/build/StgStartup.debug_dyn_o >> rts/dist/build/StgStdThunks.debug_dyn_o rts/dist/build/Updates.debug_dyn_o >> rts/dist/build/AutoApply.debug_dyn_o -fPIC -dynamic -optc-DDEBUG -ticky >> -DTICKY_TICKY -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist >> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header >> -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts >> -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build >> -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 >> -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o >> rts/dist/build/libHSrts_debug-ghc8.5.20180403.dylib >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m >> -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i >> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build >> -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen >> -Ilibraries/ghc-prim/dist-install/build/./autogen >> -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-i >> nstall/build/./autogen/cabal_macros.h -package-id rts -this-unit-id >> ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts >> -Wno-trustworthy-safe -Wno-deprecated-flags >> -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build >> -hidir libraries/ghc-prim/dist-install/build -stubdir >> libraries/ghc-prim/dist-install/build -dynamic-too -c >> libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o >> -dyno libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m >> -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i >> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build >> -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen >> -Ilibraries/ghc-prim/dist-install/build/./autogen >> -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-i >> nstall/build/./autogen/cabal_macros.h -package-id rts -this-unit-id >> ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts >> -Wno-trustworthy-safe -Wno-deprecated-flags >> -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build >> -hidir libraries/ghc-prim/dist-install/build -stubdir >> libraries/ghc-prim/dist-install/build -dynamic-too -c >> libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o >> -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m >> -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i >> -ilibraries/base/. -ilibraries/base/dist-install/build >> -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen >> -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include >> -Ilibraries/base/dist-install/build/include >> -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include >> -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h >> -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id >> rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db >> -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags >> -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build >> -hidir libraries/base/dist-install/build -stubdir >> libraries/base/dist-install/build -dynamic-too -c >> libraries/base/./GHC/Base.hs-boot -o libraries/base/dist-install/build/GHC/Base.o-boot >> -dyno libraries/base/dist-install/build/GHC/Base.dyn_o-boot >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m >> -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i >> -ilibraries/base/. -ilibraries/base/dist-install/build >> -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen >> -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include >> -Ilibraries/base/dist-install/build/include >> -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include >> -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h >> -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id >> rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db >> -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags >> -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build >> -hidir libraries/base/dist-install/build -stubdir >> libraries/base/dist-install/build -dynamic-too -c >> libraries/base/./GHC/Real.hs-boot -o libraries/base/dist-install/build/GHC/Real.o-boot >> -dyno libraries/base/dist-install/build/GHC/Real.dyn_o-boot >> "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m >> -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i >> -ilibraries/base/. -ilibraries/base/dist-install/build >> -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen >> -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include >> -Ilibraries/base/dist-install/build/include >> -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include >> -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h >> -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id >> rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db >> -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags >> -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build >> -hidir libraries/base/dist-install/build -stubdir >> libraries/base/dist-install/build -dynamic-too -c >> libraries/base/./GHC/IO.hs-boot -o libraries/base/dist-install/build/GHC/IO.o-boot >> -dyno libraries/base/dist-install/build/GHC/IO.dyn_o-boot >> >> libraries/base/GHC/IO.hs-boot:9:12: error: >> • Failed to load interface for ‘GHC.Integer.Type’ >> There are files missing in the ‘integer-gmp-1.0.1.0’ package, >> try running 'ghc-pkg check'. >> Use -v to see a list of the files searched for. >> • In the type signature: mplusIO :: IO a -> IO a -> IO a >> | >> 9 | mplusIO :: IO a -> IO a -> IO a >> | ^^^^^^^^^^^^^^^^^^^^ >> make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 >> make[1]: *** Waiting for unfinished jobs.... >> make: *** [all] Error 2 >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 3 15:37:39 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Apr 2018 15:37:39 +0000 Subject: 8.5 build failure In-Reply-To: <65B5ACA2-CCCE-4FDB-9600-FD81364AD6DE@cs.brynmawr.edu> References: <65B5ACA2-CCCE-4FDB-9600-FD81364AD6DE@cs.brynmawr.edu> Message-ID: It seems to be caused by some missing Makefile dependency It may be significant that the dependency is a module in libraries/base GHC/IO.hs-boot depending on one GHC.Integer.Type in libraries/integer-gmp. Simon From: ghc-devs On Behalf Of Richard Eisenberg Sent: 03 April 2018 16:11 To: John Leo Cc: ghc-devs Subject: Re: 8.5 build failure I've hit this, too, in the last few days. It seems to be caused by some missing Makefile dependency. My solution has been to `make -j1` for a bit, then cut it off, then `make -j` again. I'm glad to know it's not just me. :) On Apr 3, 2018, at 11:06 AM, John Leo > wrote: Hi everyone, I pulled from head this morning and rebased my current work on it, and am getting a build error I've never seen before. I don't think it's due to any of my own changes, and everything built fine last time I tried just a couple days ago . I'd pulled both code and submodules. I did make clean, ./boot, ./configure, and then make. The last few lines of the output are below. This is on a Mac using GHC 8.2.2. Let me know if you need any more info. John "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o rts/dist/build/Capability.thr_debug_dyn_o rts/dist/build/CheckUnload.thr_debug_dyn_o rts/dist/build/ClosureFlags.thr_debug_dyn_o rts/dist/build/Disassembler.thr_debug_dyn_o rts/dist/build/FileLock.thr_debug_dyn_o rts/dist/build/Globals.thr_debug_dyn_o rts/dist/build/Hash.thr_debug_dyn_o rts/dist/build/Hpc.thr_debug_dyn_o rts/dist/build/HsFFI.thr_debug_dyn_o rts/dist/build/Inlines.thr_debug_dyn_o rts/dist/build/Interpreter.thr_debug_dyn_o rts/dist/build/LdvProfile.thr_debug_dyn_o rts/dist/build/Libdw.thr_debug_dyn_o rts/dist/build/LibdwPool.thr_debug_dyn_o rts/dist/build/Linker.thr_debug_dyn_o rts/dist/build/Messages.thr_debug_dyn_o rts/dist/build/OldARMAtomic.thr_debug_dyn_o rts/dist/build/PathUtils.thr_debug_dyn_o rts/dist/build/Pool.thr_debug_dyn_o rts/dist/build/Printer.thr_debug_dyn_o rts/dist/build/ProfHeap.thr_debug_dyn_o rts/dist/build/ProfilerReport.thr_debug_dyn_o rts/dist/build/ProfilerReportJson.thr_debug_dyn_o rts/dist/build/Profiling.thr_debug_dyn_o rts/dist/build/Proftimer.thr_debug_dyn_o rts/dist/build/RaiseAsync.thr_debug_dyn_o rts/dist/build/RetainerProfile.thr_debug_dyn_o rts/dist/build/RetainerSet.thr_debug_dyn_o rts/dist/build/RtsAPI.thr_debug_dyn_o rts/dist/build/RtsDllMain.thr_debug_dyn_o rts/dist/build/RtsFlags.thr_debug_dyn_o rts/dist/build/RtsMain.thr_debug_dyn_o rts/dist/build/RtsMessages.thr_debug_dyn_o rts/dist/build/RtsStartup.thr_debug_dyn_o rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o rts/dist/build/RtsSymbols.thr_debug_dyn_o rts/dist/build/RtsUtils.thr_debug_dyn_o rts/dist/build/STM.thr_debug_dyn_o rts/dist/build/Schedule.thr_debug_dyn_o rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o rts/dist/build/StaticPtrTable.thr_debug_dyn_o rts/dist/build/Stats.thr_debug_dyn_o rts/dist/build/StgCRun.thr_debug_dyn_o rts/dist/build/StgPrimFloat.thr_debug_dyn_o rts/dist/build/Task.thr_debug_dyn_o rts/dist/build/ThreadLabels.thr_debug_dyn_o rts/dist/build/ThreadPaused.thr_debug_dyn_o rts/dist/build/Threads.thr_debug_dyn_o rts/dist/build/Ticky.thr_debug_dyn_o rts/dist/build/Timer.thr_debug_dyn_o rts/dist/build/TopHandler.thr_debug_dyn_o rts/dist/build/Trace.thr_debug_dyn_o rts/dist/build/WSDeque.thr_debug_dyn_o rts/dist/build/Weak.thr_debug_dyn_o rts/dist/build/fs.thr_debug_dyn_o rts/dist/build/xxhash.thr_debug_dyn_o rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o rts/dist/build/hooks/MallocFail.thr_debug_dyn_o rts/dist/build/hooks/OnExit.thr_debug_dyn_o rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o rts/dist/build/sm/CNF.thr_debug_dyn_o rts/dist/build/sm/Compact.thr_debug_dyn_o rts/dist/build/sm/Evac.thr_debug_dyn_o rts/dist/build/sm/Evac_thr.thr_debug_dyn_o rts/dist/build/sm/GC.thr_debug_dyn_o rts/dist/build/sm/GCAux.thr_debug_dyn_o rts/dist/build/sm/GCUtils.thr_debug_dyn_o rts/dist/build/sm/MBlock.thr_debug_dyn_o rts/dist/build/sm/MarkWeak.thr_debug_dyn_o rts/dist/build/sm/Sanity.thr_debug_dyn_o rts/dist/build/sm/Scav.thr_debug_dyn_o rts/dist/build/sm/Scav_thr.thr_debug_dyn_o rts/dist/build/sm/Storage.thr_debug_dyn_o rts/dist/build/sm/Sweep.thr_debug_dyn_o rts/dist/build/eventlog/EventLog.thr_debug_dyn_o rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o rts/dist/build/linker/CacheFlush.thr_debug_dyn_o rts/dist/build/linker/Elf.thr_debug_dyn_o rts/dist/build/linker/LoadArchive.thr_debug_dyn_o rts/dist/build/linker/M32Alloc.thr_debug_dyn_o rts/dist/build/linker/MachO.thr_debug_dyn_o rts/dist/build/linker/PEi386.thr_debug_dyn_o rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o rts/dist/build/linker/elf_got.thr_debug_dyn_o rts/dist/build/linker/elf_plt.thr_debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o rts/dist/build/linker/elf_reloc.thr_debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o rts/dist/build/linker/elf_util.thr_debug_dyn_o rts/dist/build/posix/GetEnv.thr_debug_dyn_o rts/dist/build/posix/GetTime.thr_debug_dyn_o rts/dist/build/posix/Itimer.thr_debug_dyn_o rts/dist/build/posix/OSMem.thr_debug_dyn_o rts/dist/build/posix/OSThreads.thr_debug_dyn_o rts/dist/build/posix/Select.thr_debug_dyn_o rts/dist/build/posix/Signals.thr_debug_dyn_o rts/dist/build/posix/TTY.thr_debug_dyn_o rts/dist/build/Apply.thr_debug_dyn_o rts/dist/build/Compact.thr_debug_dyn_o rts/dist/build/Exception.thr_debug_dyn_o rts/dist/build/HeapStackCheck.thr_debug_dyn_o rts/dist/build/PrimOps.thr_debug_dyn_o rts/dist/build/StgMiscClosures.thr_debug_dyn_o rts/dist/build/StgStartup.thr_debug_dyn_o rts/dist/build/StgStdThunks.thr_debug_dyn_o rts/dist/build/Updates.thr_debug_dyn_o rts/dist/build/AutoApply.thr_debug_dyn_o -fPIC -dynamic -optc-DTHREADED_RTS -optc-DDEBUG -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_thr_debug-ghc8.5.20180403.dylib "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/Adjustor.debug_dyn_o rts/dist/build/Arena.debug_dyn_o rts/dist/build/Capability.debug_dyn_o rts/dist/build/CheckUnload.debug_dyn_o rts/dist/build/ClosureFlags.debug_dyn_o rts/dist/build/Disassembler.debug_dyn_o rts/dist/build/FileLock.debug_dyn_o rts/dist/build/Globals.debug_dyn_o rts/dist/build/Hash.debug_dyn_o rts/dist/build/Hpc.debug_dyn_o rts/dist/build/HsFFI.debug_dyn_o rts/dist/build/Inlines.debug_dyn_o rts/dist/build/Interpreter.debug_dyn_o rts/dist/build/LdvProfile.debug_dyn_o rts/dist/build/Libdw.debug_dyn_o rts/dist/build/LibdwPool.debug_dyn_o rts/dist/build/Linker.debug_dyn_o rts/dist/build/Messages.debug_dyn_o rts/dist/build/OldARMAtomic.debug_dyn_o rts/dist/build/PathUtils.debug_dyn_o rts/dist/build/Pool.debug_dyn_o rts/dist/build/Printer.debug_dyn_o rts/dist/build/ProfHeap.debug_dyn_o rts/dist/build/ProfilerReport.debug_dyn_o rts/dist/build/ProfilerReportJson.debug_dyn_o rts/dist/build/Profiling.debug_dyn_o rts/dist/build/Proftimer.debug_dyn_o rts/dist/build/RaiseAsync.debug_dyn_o rts/dist/build/RetainerProfile.debug_dyn_o rts/dist/build/RetainerSet.debug_dyn_o rts/dist/build/RtsAPI.debug_dyn_o rts/dist/build/RtsDllMain.debug_dyn_o rts/dist/build/RtsFlags.debug_dyn_o rts/dist/build/RtsMain.debug_dyn_o rts/dist/build/RtsMessages.debug_dyn_o rts/dist/build/RtsStartup.debug_dyn_o rts/dist/build/RtsSymbolInfo.debug_dyn_o rts/dist/build/RtsSymbols.debug_dyn_o rts/dist/build/RtsUtils.debug_dyn_o rts/dist/build/STM.debug_dyn_o rts/dist/build/Schedule.debug_dyn_o rts/dist/build/Sparks.debug_dyn_o rts/dist/build/Stable.debug_dyn_o rts/dist/build/StaticPtrTable.debug_dyn_o rts/dist/build/Stats.debug_dyn_o rts/dist/build/StgCRun.debug_dyn_o rts/dist/build/StgPrimFloat.debug_dyn_o rts/dist/build/Task.debug_dyn_o rts/dist/build/ThreadLabels.debug_dyn_o rts/dist/build/ThreadPaused.debug_dyn_o rts/dist/build/Threads.debug_dyn_o rts/dist/build/Ticky.debug_dyn_o rts/dist/build/Timer.debug_dyn_o rts/dist/build/TopHandler.debug_dyn_o rts/dist/build/Trace.debug_dyn_o rts/dist/build/WSDeque.debug_dyn_o rts/dist/build/Weak.debug_dyn_o rts/dist/build/fs.debug_dyn_o rts/dist/build/xxhash.debug_dyn_o rts/dist/build/hooks/FlagDefaults.debug_dyn_o rts/dist/build/hooks/LongGCSync.debug_dyn_o rts/dist/build/hooks/MallocFail.debug_dyn_o rts/dist/build/hooks/OnExit.debug_dyn_o rts/dist/build/hooks/OutOfHeap.debug_dyn_o rts/dist/build/hooks/StackOverflow.debug_dyn_o rts/dist/build/sm/BlockAlloc.debug_dyn_o rts/dist/build/sm/CNF.debug_dyn_o rts/dist/build/sm/Compact.debug_dyn_o rts/dist/build/sm/Evac.debug_dyn_o rts/dist/build/sm/Evac_thr.debug_dyn_o rts/dist/build/sm/GC.debug_dyn_o rts/dist/build/sm/GCAux.debug_dyn_o rts/dist/build/sm/GCUtils.debug_dyn_o rts/dist/build/sm/MBlock.debug_dyn_o rts/dist/build/sm/MarkWeak.debug_dyn_o rts/dist/build/sm/Sanity.debug_dyn_o rts/dist/build/sm/Scav.debug_dyn_o rts/dist/build/sm/Scav_thr.debug_dyn_o rts/dist/build/sm/Storage.debug_dyn_o rts/dist/build/sm/Sweep.debug_dyn_o rts/dist/build/eventlog/EventLog.debug_dyn_o rts/dist/build/eventlog/EventLogWriter.debug_dyn_o rts/dist/build/linker/CacheFlush.debug_dyn_o rts/dist/build/linker/Elf.debug_dyn_o rts/dist/build/linker/LoadArchive.debug_dyn_o rts/dist/build/linker/M32Alloc.debug_dyn_o rts/dist/build/linker/MachO.debug_dyn_o rts/dist/build/linker/PEi386.debug_dyn_o rts/dist/build/linker/SymbolExtras.debug_dyn_o rts/dist/build/linker/elf_got.debug_dyn_o rts/dist/build/linker/elf_plt.debug_dyn_o rts/dist/build/linker/elf_plt_aarch64.debug_dyn_o rts/dist/build/linker/elf_plt_arm.debug_dyn_o rts/dist/build/linker/elf_reloc.debug_dyn_o rts/dist/build/linker/elf_reloc_aarch64.debug_dyn_o rts/dist/build/linker/elf_util.debug_dyn_o rts/dist/build/posix/GetEnv.debug_dyn_o rts/dist/build/posix/GetTime.debug_dyn_o rts/dist/build/posix/Itimer.debug_dyn_o rts/dist/build/posix/OSMem.debug_dyn_o rts/dist/build/posix/OSThreads.debug_dyn_o rts/dist/build/posix/Select.debug_dyn_o rts/dist/build/posix/Signals.debug_dyn_o rts/dist/build/posix/TTY.debug_dyn_o rts/dist/build/Apply.debug_dyn_o rts/dist/build/Compact.debug_dyn_o rts/dist/build/Exception.debug_dyn_o rts/dist/build/HeapStackCheck.debug_dyn_o rts/dist/build/PrimOps.debug_dyn_o rts/dist/build/StgMiscClosures.debug_dyn_o rts/dist/build/StgStartup.debug_dyn_o rts/dist/build/StgStdThunks.debug_dyn_o rts/dist/build/Updates.debug_dyn_o rts/dist/build/AutoApply.debug_dyn_o -fPIC -dynamic -optc-DDEBUG -ticky -DTICKY_TICKY -eventlog -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -o rts/dist/build/libHSrts_debug-ghc8.5.20180403.dylib "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o -dyno libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Base.hs-boot -o libraries/base/dist-install/build/GHC/Base.o-boot -dyno libraries/base/dist-install/build/GHC/Base.dyn_o-boot "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Real.hs-boot -o libraries/base/dist-install/build/GHC/Real.o-boot -dyno libraries/base/dist-install/build/GHC/Real.dyn_o-boot "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -package-id rts -this-unit-id base -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/IO.hs-boot -o libraries/base/dist-install/build/GHC/IO.o-boot -dyno libraries/base/dist-install/build/GHC/IO.dyn_o-boot libraries/base/GHC/IO.hs-boot:9:12: error: • Failed to load interface for ‘GHC.Integer.Type’ There are files missing in the ‘integer-gmp-1.0.1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. • In the type signature: mplusIO :: IO a -> IO a -> IO a | 9 | mplusIO :: IO a -> IO a -> IO a | ^^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at halfaya.org Tue Apr 3 15:53:34 2018 From: leo at halfaya.org (John Leo) Date: Tue, 3 Apr 2018 08:53:34 -0700 Subject: 8.5 build failure In-Reply-To: References: <65B5ACA2-CCCE-4FDB-9600-FD81364AD6DE@cs.brynmawr.edu> Message-ID: Thanks everyone. I didn't expect just continuing "make" would work, but it does, so that's a workaround for now. I'll look forward to the real fix, of course. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Tue Apr 3 16:14:22 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 3 Apr 2018 18:14:22 +0200 Subject: 8.5 build failure In-Reply-To: References: <65B5ACA2-CCCE-4FDB-9600-FD81364AD6DE@cs.brynmawr.edu> Message-ID: Hi Simon et al. On Tue, Apr 3, 2018 at 5:37 PM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > It seems to be caused by some missing Makefile dependency > > > > It may be significant that the dependency is a module in libraries/base > GHC/IO.hs-boot depending on one GHC.Integer.Type in > libraries/integer-gmp. > That's quite likely the case, either directly or indirectly. When changing the dependency graph, especially involving `.hs-boot` files, it happens quite easily that one needs to give the build-system a hint and make implicit module-graph dependencies more explicit by adding an explicit `import SomeModule ()` in the appropriate place. You may find commit of mine where I did things like that in the past. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Apr 4 13:57:01 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Apr 2018 13:57:01 +0000 Subject: Perl locale Message-ID: Hi Tamar One other thing happened to me when building GHC, very early. See below. I think the perl concerned is c:/msys64/usr/bin/perl. Any ideas? It seems non-fatal Thanks Simon perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "ENG" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "ENG" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "ENG" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "ENG" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "ENG" are supported and installed on your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Wed Apr 4 18:41:10 2018 From: lonetiger at gmail.com (Phyx) Date: Wed, 4 Apr 2018 19:41:10 +0100 Subject: Perl locale In-Reply-To: References: Message-ID: Hi Simon, That's weird, "ENG" isn't a valid locale as far as I know. The locale should be getting set by your .profile by the line # Set user-defined locale export LANG=$(locale -uU) In my case that returns $ locale -uU en_GB.UTF-8 I would check to see if that line is in your .profile (it should be by default) or in case you're not login into bash (using --login), in your .bashrc. That should fix the warning. However it's weird that it's using c:/msys64/usr/bin/perl to build GHC. As far as I know, the only usage of perl in GHC is for SplitObjs in which case we use a very old perl distribution that should have been downloaded by configure into inplace/perl/ and configure should have picked that one up. It's hardcoded somewhat to do so. What does configure report that it found? in any case, setting the locale as above should fix the warning. Cheers, Tamar On Wed, Apr 4, 2018 at 2:57 PM, Simon Peyton Jones wrote: > Hi Tamar > > One other thing happened to me when building GHC, very early. See below. > I think the perl concerned is c:/msys64/usr/bin/perl. > > Any ideas? It seems non-fatal > > Thanks > > Simon > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LC_ALL = (unset), > > LANG = "ENG" > > are supported and installed on your system. > > perl: warning: Falling back to the standard locale ("C"). > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LC_ALL = (unset), > > LANG = "ENG" > > are supported and installed on your system. > > perl: warning: Falling back to the standard locale ("C"). > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LC_ALL = (unset), > > LANG = "ENG" > > are supported and installed on your system. > > perl: warning: Falling back to the standard locale ("C"). > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LC_ALL = (unset), > > LANG = "ENG" > > are supported and installed on your system. > > perl: warning: Falling back to the standard locale ("C"). > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LC_ALL = (unset), > > LANG = "ENG" > > are supported and installed on your system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Apr 4 21:17:41 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Apr 2018 21:17:41 +0000 Subject: Windows: cannot create here-doc Message-ID: Tamar I think your suggestion of adding # Set user-defined locale export LANG=$(locale -uU) worked. No more perl messages. Still having various troubles... Here's the current one (log below). I'm getting lots of ./configure: line 2534: cannot create temp file for here-document: Device or resource busy And finally checking whether the C compiler works... no sed: can't read conftest.c: No such file or directory configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables I have environment variables TEMP and TMP set. Oddly, re-running configure gets further - see second log below. All deeply strange. Thanks Simon Log 1: first run of 'sh validate -fast' Creating libraries/array/ghc.mk Creating libraries/base/ghc.mk Creating libraries/binary/ghc.mk Creating libraries/bytestring/ghc.mk Creating libraries/Cabal/Cabal/ghc.mk Creating libraries/containers/ghc.mk Creating libraries/deepseq/ghc.mk Creating libraries/directory/ghc.mk Creating libraries/dph/dph-base/ghc.mk Creating libraries/dph/dph-prim-interface/ghc.mk Creating libraries/dph/dph-prim-seq/ghc.mk Creating libraries/dph/dph-prim-par/ghc.mk Creating libraries/dph/dph-lifted-base/ghc.mk Creating libraries/dph/dph-lifted-boxed/ghc.mk Creating libraries/dph/dph-lifted-copy/ghc.mk Creating libraries/dph/dph-lifted-vseg/ghc.mk Creating libraries/filepath/ghc.mk Creating libraries/ghc-boot/ghc.mk Creating libraries/ghc-boot-th/ghc.mk Creating libraries/ghc-compact/ghc.mk Creating libraries/ghc-prim/ghc.mk Creating libraries/ghci/ghc.mk Creating libraries/haskeline/ghc.mk Creating libraries/hpc/ghc.mk Creating libraries/integer-gmp/ghc.mk Creating libraries/integer-simple/ghc.mk Creating libraries/mtl/ghc.mk Creating libraries/parallel/ghc.mk Creating libraries/parsec/ghc.mk Creating libraries/pretty/ghc.mk Creating libraries/primitive/ghc.mk Creating libraries/process/ghc.mk Creating libraries/random/ghc.mk Creating libraries/stm/ghc.mk Creating libraries/template-haskell/ghc.mk Creating libraries/terminfo/ghc.mk Creating libraries/text/ghc.mk Creating libraries/time/ghc.mk Creating libraries/transformers/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/vector/ghc.mk Creating libraries/Win32/ghc.mk Creating libraries/xhtml/ghc.mk Booting . Booting libraries/base/ Booting libraries/directory/ Booting libraries/ghc-prim/ Booting libraries/integer-gmp/ Booting libraries/process/ Booting libraries/terminfo/ Booting libraries/time/ Booting libraries/unix/ ./configure: line 2534: cannot create temp file for here-document: Device or resource busy checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180402 checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12efeaa2e7d902 checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-mingw64 checking host system type... x86_64-pc-mingw64 checking target system type... x86_64-pc-mingw64 Build platform inferred as: x86_64-unknown-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... configure: Extracting Windows toolchain from archives (may take a while)... configure: In-tree MingW-w64 tree created checking for genlib... no configure: Making in-tree perl tree configure: In-tree perl tree created checking for -windres... no checking for windres... windres checking for -dllwrap... no checking for dllwrap... dllwrap checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe ./configure: line 5421: cannot create temp file for here-document: Device or resource busy checking whether the C compiler works... no sed: can't read conftest.c: No such file or directory configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables See `config.log' for more details $ Log 2: run of "./configure" $ ./configure ./configure: line 2542: cannot create temp file for here-document: Device or resource busy configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180402 checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12efeaa2e7d902 checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking target system type... x86_64-w64-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... checking for genlib... no checking for -windres... no checking for -dllwrap... no checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether C:/code/HEAD/inplace/mingw/bin/gcc.exe accepts -g... ./configure: line 5717: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory no checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C89... ./configure: line 5793: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory unsupported checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... ./configure: line 1796: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe -E checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/fp/HP-8.2.2/lib/../mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for -ld... C:/code/HEAD/inplace/mingw/bin/ld.exe checking whether ld is GNU ld... YES checking whether ld understands --build-id... yes checking whether ld understands -no_compact_unwind... yes checking whether ld understands -filelist... no checking for -objdump... (cached) C:/code/HEAD/inplace/mingw/bin/objdump.exe checking for ranlib... C:/code/HEAD/inplace/mingw/bin/ranlib.exe checking for -strip... no checking for libtool... /usr/bin/libtool checking for -clang... no checking for llc-5.0... no checking for llc... no checking for opt-5.0... no checking for opt... no configure: Creating links for in-tree file handling routines. 'utils/lndir/fs.c' => 'utils/fs/fs.c' 'utils/lndir/fs.h' => 'utils/fs/fs.h' 'utils/unlit/fs.c' => 'utils/fs/fs.c' 'utils/unlit/fs.h' => 'utils/fs/fs.h' 'rts/fs.c' => 'utils/fs/fs.c' 'rts/fs.h' => 'utils/fs/fs.h' 'libraries/base/include/fs.h' => 'utils/fs/fs.h' 'libraries/base/cbits/fs.c' => 'utils/fs/fs.c' configure: Routines in place. Packages can now be build normally. checking whether #! works in shell scripts... yes checking version of gcc... 7.2.0 checking whether GCC supports -no-pie... yes checking for extra options to pass gcc when compiling via C... -fwrapv -fno-builtin checking whether C compiler is clang... no checking whether C compiler has an LLVM back end... no checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done checking for .subsections_via_symbols... no checking whether your assembler supports .ident directive... yes checking for GNU non-executable stack support... no checking for a working context diff... diff -U 1 checking for a BSD-compatible install... /usr/bin/install -c checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe is GNU ar... yes checking for ar arguments... q checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe supports @file... yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Apr 4 21:26:19 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Apr 2018 21:26:19 +0000 Subject: More windows In-Reply-To: References: Message-ID: The solution seems to be to cache the user info locally instead of it having to query the domain controller everytime. Ah yes: here’s a better expressed post: http://bjg.io/guide/cygwin-ad/ I did the following * commented out the “db” part for passwd and group in c:/msys64/etc/nsswitch.conf, to give this: # Begin /etc/nsswitch.conf passwd: files #db group: files #db db_enum: cache builtin db_home: windows db_shell: cygwin desc db_gecos: cygwin desc # End /etc/nsswitch.conf * Note that I also set db_home to ‘windows’, so that it gets my windows home directory. I think an explicit path would also be OK * However I discovered that having just “files” for “passwd” in nsswitch.conf means that ssh looks in c:/msys64/etc/passwd to find the home directory for .ssh, totally ignoring the $HOME environment variable, and ignoring the db_home setting. * But there IS no /etc/passwd file! So I created one mkpasswd -c > /etc/passwd mkgroup -c > /etc/group And then I manually edited /etc/passwd to put in the correct home directory. What a saga! Is it faster now? Hard to tell. Simon From: Phyx Sent: 03 April 2018 07:00 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: More windows Hi Simon, Hmm I'm not sure about replacing sh with bash. I think bash has some Non-POSIX extensions that may affect the behavior of valid posix scripts. Is bash --login slow as well? How about once sh or bash starts, are commands still slow then? I assume your computer is domain joined and you may be hitting a very long standing issue with certain domain joined machines https://github.com/Alexpux/MSYS2-packages/issues/138#issuecomment-70813762 The solution seems to be to cache the user info locally instead of it having to query the domain controller everytime. See solution 2 here https://gist.github.com/k-takata/9b8d143f0f3fef5abdab for instructions Does that help the problem? I believe you had a similar problem last time setting up a new machine. At that time magit was also slow. Kind regards, Tamar On Mon, Apr 2, 2018, 23:23 Simon Peyton Jones > wrote: Tamar I’ve noticed that “sh” (which is invoked at lot by make etc) takes AGES to start up. At least I think it’s ‘sh’ that is causing the delay. I think it’s c:/msys64/usr/bin/sh.exe From searching the web (eg https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html) it seems likely that it executes c:/msys64/etc/profile first. And If I put an ‘echo’ at the start and end of that file, they do seem to take place with a significant gap between them. I have not started sprinkling more echos, but does that ring any bells? Can I replace ‘sh’ with c:/msys64/usr/bin/bash.exe, which seems to be faster? (My evnt variable SHELL already points to bash.exe. ) And if so, how would I do that? An environment variable. Physically copy bash.exe to sh.exe? Or what? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Wed Apr 4 22:35:25 2018 From: lonetiger at gmail.com (Phyx) Date: Wed, 4 Apr 2018 23:35:25 +0100 Subject: Windows: cannot create here-doc In-Reply-To: References: Message-ID: Hi Simon, This one is very strange, from the error and the fact that it continues it looks like whatever TEMP and TMP are pointing to are not always available or some locking issue is going on. I would try running ProcMon https://docs.microsoft.com/en-us/sysinternals/downloads/procmon and filtering paths to whatever TEMP and TMP are set to. In the dialog that opens when you run it, select in the first box path, select the "starts with" condition then enter the Windows version of the path in the third one. Make sure the final box is set to "Include" and press add. Then try again. Once it fails, stop capturing (File -> click on "capture events" to unselect). This should contain the accesses to things in your TEMP and why it failed. (If TEMP contains a unix path you can get a windows one with e.g cygpath -w $TEMP) Once we know more can figure out what's going on. Thanks, Tamar On Wed, Apr 4, 2018 at 10:17 PM, Simon Peyton Jones wrote: > Tamar > > I think your suggestion of adding > > # Set user-defined locale > export LANG=$(locale -uU) > > worked. No more perl messages. > > Still having various troubles… > > Here’s the current one (log below). I’m getting lots of > > ./configure: line 2534: cannot create temp file for here-document: > Device or resource busy > > And finally > > checking whether the C compiler works... no > > sed: can't read conftest.c: No such file or directory > > configure: error: in `/c/code/HEAD': > > configure: error: C compiler cannot create executables > > I have environment variables TEMP and TMP set. > > Oddly, re-running configure gets further – see second log below. > > All deeply strange. > > Thanks > > Simon > > > > *Log 1: first run of ‘sh validate –fast’* > > Creating libraries/array/ghc.mk > > Creating libraries/base/ghc.mk > > Creating libraries/binary/ghc.mk > > Creating libraries/bytestring/ghc.mk > > Creating libraries/Cabal/Cabal/ghc.mk > > Creating libraries/containers/ghc.mk > > Creating libraries/deepseq/ghc.mk > > Creating libraries/directory/ghc.mk > > Creating libraries/dph/dph-base/ghc.mk > > Creating libraries/dph/dph-prim-interface/ghc.mk > > Creating libraries/dph/dph-prim-seq/ghc.mk > > Creating libraries/dph/dph-prim-par/ghc.mk > > Creating libraries/dph/dph-lifted-base/ghc.mk > > Creating libraries/dph/dph-lifted-boxed/ghc.mk > > Creating libraries/dph/dph-lifted-copy/ghc.mk > > Creating libraries/dph/dph-lifted-vseg/ghc.mk > > Creating libraries/filepath/ghc.mk > > Creating libraries/ghc-boot/ghc.mk > > Creating libraries/ghc-boot-th/ghc.mk > > Creating libraries/ghc-compact/ghc.mk > > Creating libraries/ghc-prim/ghc.mk > > Creating libraries/ghci/ghc.mk > > Creating libraries/haskeline/ghc.mk > > Creating libraries/hpc/ghc.mk > > Creating libraries/integer-gmp/ghc.mk > > Creating libraries/integer-simple/ghc.mk > > Creating libraries/mtl/ghc.mk > > Creating libraries/parallel/ghc.mk > > Creating libraries/parsec/ghc.mk > > Creating libraries/pretty/ghc.mk > > Creating libraries/primitive/ghc.mk > > Creating libraries/process/ghc.mk > > Creating libraries/random/ghc.mk > > Creating libraries/stm/ghc.mk > > Creating libraries/template-haskell/ghc.mk > > Creating libraries/terminfo/ghc.mk > > Creating libraries/text/ghc.mk > > Creating libraries/time/ghc.mk > > Creating libraries/transformers/ghc.mk > > Creating libraries/unix/ghc.mk > > Creating libraries/vector/ghc.mk > > Creating libraries/Win32/ghc.mk > > Creating libraries/xhtml/ghc.mk > > Booting . > > Booting libraries/base/ > > Booting libraries/directory/ > > Booting libraries/ghc-prim/ > > Booting libraries/integer-gmp/ > > Booting libraries/process/ > > Booting libraries/terminfo/ > > Booting libraries/time/ > > Booting libraries/unix/ > > *./configure: line 2534: cannot create temp file for here-document: Device > or resource busy* > > checking for gfind... no > > checking for find... /usr/bin/find > > checking for sort... /usr/bin/sort > > checking for GHC version date... inferred 8.5.20180402 > > checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12ef > eaa2e7d902 > > checking for ghc... /c/fp/HP-8.2.2/bin/ghc > > checking version of ghc... 8.2.2 > > GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc > > checking build system type... x86_64-pc-mingw64 > > checking host system type... x86_64-pc-mingw64 > > checking target system type... x86_64-pc-mingw64 > > Build platform inferred as: x86_64-unknown-mingw32 > > Host platform inferred as: x86_64-unknown-mingw32 > > Target platform inferred as: x86_64-unknown-mingw32 > > GHC build : x86_64-unknown-mingw32 > > GHC host : x86_64-unknown-mingw32 > > GHC target : x86_64-unknown-mingw32 > > LLVM target: x86_64-unknown-windows > > checking for path to top of build tree... C:/code/HEAD > > configure: Checking for Windows toolchain tarballs... > > configure: Extracting Windows toolchain from archives (may take a while)... > > configure: In-tree MingW-w64 tree created > > checking for genlib... no > > configure: Making in-tree perl tree > > configure: In-tree perl tree created > > checking for -windres... no > > checking for windres... windres > > checking for -dllwrap... no > > checking for dllwrap... dllwrap > > checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe > > ./configure: line 5421: cannot create temp file for here-document: Device > or resource busy > > *checking whether the C compiler works... no* > > sed: can't read conftest.c: No such file or directory > > configure: error: in `/c/code/HEAD': > > configure: error: C compiler cannot create executables > > See `config.log' for more details > > $ > > *Log 2: run of “./configure”* > > $ ./configure > > *./configure: line 2542: cannot create temp file for here-document: Device > or resource busy* > > configure: loading site script /usr/local/etc/config.site > > checking for gfind... no > > checking for find... /usr/bin/find > > checking for sort... /usr/bin/sort > > checking for GHC version date... inferred 8.5.20180402 > > checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12ef > eaa2e7d902 > > checking for ghc... /c/fp/HP-8.2.2/bin/ghc > > checking version of ghc... 8.2.2 > > GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc > > checking build system type... x86_64-w64-mingw32 > > checking host system type... x86_64-w64-mingw32 > > checking target system type... x86_64-w64-mingw32 > > Host platform inferred as: x86_64-unknown-mingw32 > > Target platform inferred as: x86_64-unknown-mingw32 > > GHC build : x86_64-unknown-mingw32 > > GHC host : x86_64-unknown-mingw32 > > GHC target : x86_64-unknown-mingw32 > > LLVM target: x86_64-unknown-windows > > checking for path to top of build tree... C:/code/HEAD > > configure: Checking for Windows toolchain tarballs... > > checking for genlib... no > > checking for -windres... no > > checking for -dllwrap... no > > checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe > > *checking whether the C compiler works... yes* > > checking for C compiler default output file name... a.exe > > checking for suffix of executables... .exe > > checking whether we are cross compiling... no > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > *checking whether C:/code/HEAD/inplace/mingw/bin/gcc.exe accepts -g... > ./configure: line 5717: cannot create temp file for here-document: Device > or resource busy* > > *sed: can't read conftest.c: No such file or directory* > > *no* > > checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO > C89... ./configure: line 5793: cannot create temp file for here-document: > Device or resource busy > > sed: can't read conftest.c: No such file or directory > > sed: can't read conftest.c: No such file or directory > > sed: can't read conftest.c: No such file or directory > > sed: can't read conftest.c: No such file or directory > > sed: can't read conftest.c: No such file or directory > > sed: can't read conftest.c: No such file or directory > > sed: can't read conftest.c: No such file or directory > > unsupported > > checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe > -E > > checking for grep that handles long lines and -e... /usr/bin/grep > > checking for egrep... /usr/bin/grep -E > > checking for ANSI C header files... yes > > checking for sys/types.h... yes > > checking for sys/stat.h... yes > > checking for stdlib.h... yes > > checking for string.h... yes > > checking for memory.h... yes > > checking for strings.h... yes > > checking for inttypes.h... yes > > checking for stdint.h... yes > > checking for unistd.h... yes > > checking minix/config.h usability... no > > checking minix/config.h presence... ./configure: line 1796: cannot create > temp file for here-document: Device or resource busy > > sed: can't read conftest.c: No such file or directory > > no > > checking for minix/config.h... no > > checking whether it is safe to define __EXTENSIONS__... yes > > checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe > -E > > checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO > C99... none needed > > checking for C:/fp/HP-8.2.2/lib/../mingw/bin/gcc.exe option to accept ISO > C99... none needed > > checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO > C99... none needed > > checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO > C99... none needed > > checking for -ld... C:/code/HEAD/inplace/mingw/bin/ld.exe > > checking whether ld is GNU ld... YES > > checking whether ld understands --build-id... yes > > checking whether ld understands -no_compact_unwind... yes > > checking whether ld understands -filelist... no > > checking for -objdump... (cached) C:/code/HEAD/inplace/mingw/ > bin/objdump.exe > > checking for ranlib... C:/code/HEAD/inplace/mingw/bin/ranlib.exe > > checking for -strip... no > > checking for libtool... /usr/bin/libtool > > checking for -clang... no > > checking for llc-5.0... no > > checking for llc... no > > checking for opt-5.0... no > > checking for opt... no > > configure: Creating links for in-tree file handling routines. > > 'utils/lndir/fs.c' => 'utils/fs/fs.c' > > 'utils/lndir/fs.h' => 'utils/fs/fs.h' > > 'utils/unlit/fs.c' => 'utils/fs/fs.c' > > 'utils/unlit/fs.h' => 'utils/fs/fs.h' > > 'rts/fs.c' => 'utils/fs/fs.c' > > 'rts/fs.h' => 'utils/fs/fs.h' > > 'libraries/base/include/fs.h' => 'utils/fs/fs.h' > > 'libraries/base/cbits/fs.c' => 'utils/fs/fs.c' > > configure: Routines in place. Packages can now be build normally. > > checking whether #! works in shell scripts... yes > > checking version of gcc... 7.2.0 > > checking whether GCC supports -no-pie... yes > > checking for extra options to pass gcc when compiling via C... -fwrapv > -fno-builtin > > checking whether C compiler is clang... no > > checking whether C compiler has an LLVM back end... no > > checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and > CPPFLAGS... done > > checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, > CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done > > checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, > CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done > > checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, > CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done > > checking for .subsections_via_symbols... no > > checking whether your assembler supports .ident directive... yes > > checking for GNU non-executable stack support... no > > checking for a working context diff... diff -U 1 > > checking for a BSD-compatible install... /usr/bin/install -c > > checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe is GNU ar... yes > > checking for ar arguments... q > > checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe supports @file... > yes > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang-it at jeltsch.info Thu Apr 5 20:37:01 2018 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Thu, 05 Apr 2018 23:37:01 +0300 Subject: [ANNOUNCE] GHC 8.4.2-rc1 now available In-Reply-To: <87in9afxij.fsf@smart-cactus.org> References: <87in9afxij.fsf@smart-cactus.org> Message-ID: <1522960621.10909.21.camel@jeltsch.info> Am Sonntag, den 01.04.2018, 17:05 -0400 schrieb Ben Gamari: > Hello everyone, > > The GHC team is proud to announce the first release candidate of > 8.4.2. > the source distribution, binary distributions, and documentation are > available at > >     https://downloads.haskell.org/~ghc/8.4.2-rc1 Hi! Unfortunately, this release candidate cannot build order-maintenance-0.2.1.0. When trying, the “impossible” happens. The full output is below. I’ll file a bug report soon. Any chance that this will be fixed before the 8.4.2 release? All the best, Wolfgang Full output: > [ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o ) > [ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o ) > ghc: panic! (the 'impossible' happened) >   (GHC version 8.4.1.20180329 for x86_64-unknown-linux): > StgCmmEnv: variable not found >   x_a46z >   local binds for: >   $tc'Label >   $tcLabel >   $tc'Cell >   $tcCell >   $trModule >   $tc'Cell1 >   $tc'Cell2 >   $tc'Cell3 >   $trModule1 >   $trModule2 >   $trModule3 >   $trModule4 >   $tc'Label1 >   $tc'Label2 >   $tc'Label3 >   $tcCell1 >   $tcCell2 >   $tcLabel1 >   $tcLabel2 >   lvl_r4UD >   lvl1_r4UE >   lvl2_r4UF >   lvl3_r4UG >   lvl4_r4UH >   lvl5_r4UI >   lvl6_r4UJ >   lvl7_r4UK >   lvl8_r4UL >   lvl9_r4UM >   lvl10_r4UN >   lvl11_r4UO >   lvl12_r4UP >   lvl13_r4UQ >   lvl14_r4UR >   lvl15_r4US >   lvl16_r4UT >   lvl17_r4UU >   $krep_r4UV >   $krep1_r4UW >   $krep2_r4UX >   lvl18_r4UY >   $krep3_r4UZ >   $krep4_r4V0 >   $krep5_r4V1 >   $krep6_r4V2 >   $krep7_r4V3 >   $krep8_r4V4 >   $krep9_r4V5 >   lvl19_r4V6 >   lvl20_r4V7 >   lvl21_r4V8 >   lvl22_r4V9 >   lvl23_r4Va >   lvl24_r4Vb >   lvl25_r4Vc >   ww_s4W2 >   lwild_s4W3 >   lwild1_s4W4 >   noOfLabels_s4W5 >   noOfLabels1_s4W6 >   labelMask_s4W7 >   $wnewAfterCell_s4Wa >   ww1_s4Wb >   ipv1_s4Wf >   wild_s4Wg >   ds_s4Wh >   ds2_s4Wi >   ww2_s4Wk >   ww3_s4Wl >   ww4_s4Wn >   ww5_s4Wo >   wild1_s4Wq >   smallGap_s4Wr >   wild2_s4Ws >   Call stack: >       CallStack (from HasCallStack): >         callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable >         pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv > > Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug From wolfgang-it at jeltsch.info Thu Apr 5 20:48:50 2018 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Thu, 05 Apr 2018 23:48:50 +0300 Subject: [ANNOUNCE] GHC 8.4.2-rc1 now available In-Reply-To: <1522960621.10909.21.camel@jeltsch.info> References: <87in9afxij.fsf@smart-cactus.org> <1522960621.10909.21.camel@jeltsch.info> Message-ID: <1522961330.10909.23.camel@jeltsch.info> Am Donnerstag, den 05.04.2018, 23:37 +0300 schrieb Wolfgang Jeltsch: > Am Sonntag, den 01.04.2018, 17:05 -0400 schrieb Ben Gamari: > > > > Hello everyone, > > > > The GHC team is proud to announce the first release candidate of > > 8.4.2. > > the source distribution, binary distributions, and documentation are > > available at > > > >     https://downloads.haskell.org/~ghc/8.4.2-rc1 > > Hi! > > Unfortunately, this release candidate cannot build > order-maintenance-0.2.1.0. When trying, the “impossible” happens. > The full output is below. I’ll file a bug report soon. The ticket number is #15005. By the way, this problem also exists with GHC 8.4.1. All the best, Wolfgang From omeragacan at gmail.com Fri Apr 6 13:49:41 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 6 Apr 2018 16:49:41 +0300 Subject: Why does the RTS run GC right before shutting down? Message-ID: Hi, I'm wondering why we run GC in this line: https://github.com/ghc/ghc/blob/master/rts/Schedule.c#L2670 I went back in commit history using git blame and found the commit that introduced that line (5638488ba28), but it didn't help. Does anyone know why we need that line? Thanks, Ömer From ezyang at mit.edu Fri Apr 6 14:06:55 2018 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 06 Apr 2018 10:06:55 -0400 Subject: Why does the RTS run GC right before shutting down? In-Reply-To: References: Message-ID: <1523023597-sup-7425@sabre> I believe it's so that we can run finalizers before shutdown. Excerpts from Ömer Sinan Ağacan's message of 2018-04-06 16:49:41 +0300: > Hi, > > I'm wondering why we run GC in this line: > > https://github.com/ghc/ghc/blob/master/rts/Schedule.c#L2670 > > I went back in commit history using git blame and found the commit that > introduced that line (5638488ba28), but it didn't help. Does anyone know why we > need that line? > > Thanks, > > Ömer From omeragacan at gmail.com Fri Apr 6 14:08:22 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 6 Apr 2018 17:08:22 +0300 Subject: Why does the RTS run GC right before shutting down? In-Reply-To: <1523023597-sup-7425@sabre> References: <1523023597-sup-7425@sabre> Message-ID: We already run all finalizers after exitScheduler: https://github.com/ghc/ghc/blob/master/rts/RtsStartup.c#L382-L388 so no need to run GC for that. Ömer 2018-04-06 17:06 GMT+03:00 Edward Z. Yang : > I believe it's so that we can run finalizers before shutdown. > > Excerpts from Ömer Sinan Ağacan's message of 2018-04-06 16:49:41 +0300: >> Hi, >> >> I'm wondering why we run GC in this line: >> >> https://github.com/ghc/ghc/blob/master/rts/Schedule.c#L2670 >> >> I went back in commit history using git blame and found the commit that >> introduced that line (5638488ba28), but it didn't help. Does anyone know why we >> need that line? >> >> Thanks, >> >> Ömer From ryan.gl.scott at gmail.com Fri Apr 6 18:51:50 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 6 Apr 2018 14:51:50 -0400 Subject: 8.5 build failure Message-ID: I've just landed a commit of Ben's [1] which should fix this issue. Ryan S. ----- [1] Specifically, http://git.haskell.org/ghc.git/commit/54acfbbf64f5fcb108836412e9be0cfabf0d7801 From raichoo at googlemail.com Sat Apr 7 07:24:55 2018 From: raichoo at googlemail.com (raichoo) Date: Sat, 7 Apr 2018 09:24:55 +0200 Subject: DTrace patch for FreeBSD breaks ability to function as a bootstrap compiler under FreeBSD Message-ID: Hi, Last year I've provided a patch that enables DTrace probes under FreeBSD, sadly as it turns out this currently breaks the ability of GHC 8.4.1 to function as a bootstrap compiler under FreeBSD. I've provided a patch that adds a flag to the build system so one can turn off DTrace in case one needs to build a bootstrap compiler. https://phabricator.haskell.org/D4575 This should probably also contain some heads up in the documentation, otherwise someone might end up with a compiler that's not suitable for bootstrapping. Not sure on how this is being handled. I have an idea on how to fix the actual issue but for the time being this might be a suitable workaround. Maybe we can still get this into 8.4.2? I've already notified the FreeBSD ports maintainers regarding this issue. Sorry for the inconvenience. Kind regards, raichoo -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.cacciarimiraldo at uu.nl Sat Apr 7 11:02:11 2018 From: v.cacciarimiraldo at uu.nl (Victor Miraldo (UU)) Date: Sat, 7 Apr 2018 13:02:11 +0200 Subject: Memory usage exploding for complex pattern matching In-Reply-To: <924a115c65bd4a0287ade32dd9a69777@ICTSC-W-S211.soliscom.uu.nl> References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> <924a115c65bd4a0287ade32dd9a69777@ICTSC-W-S211.soliscom.uu.nl> Message-ID: Hello all, Following up on this, I have created a trac ticket https://ghc.haskell.org/trac/ghc/ticket/14987#no2 as suggested a couple days ago. In order to try to hack my way through and get my library to compile, I tried progressively adding more and more pattern synonyms to try to avoid exhaustiveness checking,yet, something really surprising happened. Big examples have type errors where small ones don't! I tried documenting the process in a repository: https://github.com/VictorCMiraldo/ghc-14987-repro-pipeline Unfortunately, however, I couldn't get the self contained repros in the repository above to throw type errors. Hence, I'm attaching my full code. Compiling the file src/Generics/MRSOP/Examples/GoAST.hs gives type errors, even though it is being generated by the same template haskell code as the other files inside Examples, all of which compile just fine. To trigger the error, just run `stack build`. It really is a shame that the combination of pattern synonyms that shows the best memory performance crashes completely on bigger examples. Any suggestions are appreciated, thank you very much! Have a great weekend! Cheers, Victor On Fri, Mar 30, 2018 at 5:23 PM, Ben Gamari wrote: > "Victor Miraldo (UU)" writes: > >> Hello, >> >>>>>> I have just tried compiling my code with 8.4.2 and using >>>>>> -fmax-pmcheck-iterations=0, >>>>>> I gave GHC 12GB of ram and it still ran out (through `ulimit >>>>>> -v$((1024*1024*12))`). >>>>>> >>>>> Hmmm, I'm a bit confused. Why are our results so different? How >>>>> precisely are you invoking GHC? >>>> >>>> Here I meant my whole code, not just the repro. I could have been more clear. >>>> Nevertheless, I'm calling it through stack: >>>> >>> I'll admit that I am a bit lost; Minimal.hs compiles for me with a >>> maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled >>> using GHC 8.4.1. Is this not the repro you are referring to? >> >> I get the same behavior as you for Minimal.hs. >> >> The "my code" above referred to the whole library that I'm developping. >> In fact, the Minimal.hs file contains a distilled version of that library with >> a template haskell splice that we are trying to use in one of our >> fully fledged examples. >> > Okay, I just wanted to be certain we were indeed seeing the same > behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC program, > even one with the deep matches seen in Minimal.hs. > > Cheers, > > - Ben > -------------- next part -------------- A non-text attachment was scrubbed... Name: generics-mrsop.zip Type: application/zip Size: 31991 bytes Desc: generics-mrsop.zip URL: From mail at nh2.me Sat Apr 7 13:33:27 2018 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Sat, 7 Apr 2018 15:33:27 +0200 Subject: ZuriHac 2018 GHC DevOps track - Request for Contributions Message-ID: Hi GHC devs, The ZuriHac 2018 conference will feature a GHC DevOps track (which Andreas and I are coordinating), that will be all about fostering contributions to GHC and learning to hack it. There will be a room or two allocated at Zurihac for this purpose. We hope to focus on roughly these topics: * How to build GHC from source * How to iterate on changes quickly * What's the development workflow, how do I get my patch merged? * How do specific parts of GHC work * Extending GHC's test suite * Improving automation, processes and release quality * Documenting the undocumented If we are successful, we will have more GHC contributers after ZuriHac than before. But we need your contributions to add content to the track! Specifically, we're looking for ZuriHac attendees who could (help) run a session in this track. Such as: * Giving a talk about one of the above or related topics * Hosting a hack session where participants of the track work together on the GHC code base towards a specific goal * Being around as a "GHC mentor" during open hack sessions, helping new GHC contributors out To give some examples, I could offer to give a talk on a recent effort to improve Ctrl+C and signal handling in the RTS, and I would like to run a hack session where we add performance regression tests based on CPU instruction counters. Please contact Andreas or me (on this list or privately) if you think you could help in any of these directions! If you're not sure, contact us anyway and tell us your idea! Best, Niklas and Andreas ZuriHac 2018 GHC DevOps track coordinators From oleg.grenrus at iki.fi Sat Apr 7 14:06:33 2018 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sat, 7 Apr 2018 17:06:33 +0300 Subject: ZuriHac 2018 GHC DevOps track - Request for Contributions In-Reply-To: References: Message-ID: <264DB8C9-A0E1-42FB-8435-5B651EACA203@iki.fi> I hope Hadrian topics qualify under "building GHC from source"? Sent from my iPhone > On 7 Apr 2018, at 16.33, Niklas Hambüchen wrote: > > Hi GHC devs, > > The ZuriHac 2018 conference will feature a GHC DevOps track (which > Andreas and I are coordinating), that will be all about fostering > contributions to GHC and learning to hack it. There will be a room or > two allocated at Zurihac for this purpose. > > We hope to focus on roughly these topics: > > * How to build GHC from source > * How to iterate on changes quickly > * What's the development workflow, how do I get my patch merged? > * How do specific parts of GHC work > * Extending GHC's test suite > * Improving automation, processes and release quality > * Documenting the undocumented > > If we are successful, we will have more GHC contributers after ZuriHac > than before. > > But we need your contributions to add content to the track! > > Specifically, we're looking for ZuriHac attendees who could (help) run a > session in this track. Such as: > > * Giving a talk about one of the above or related topics > * Hosting a hack session where participants of the track work together > on the GHC code base towards a specific goal > * Being around as a "GHC mentor" during open hack sessions, helping new > GHC contributors out > > To give some examples, I could offer to give a talk on a recent effort > to improve Ctrl+C and signal handling in the RTS, and I would like to > run a hack session where we add performance regression tests based on > CPU instruction counters. > > Please contact Andreas or me (on this list or privately) if you think > you could help in any of these directions! > If you're not sure, contact us anyway and tell us your idea! > > Best, > Niklas and Andreas > ZuriHac 2018 GHC DevOps track coordinators > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sat Apr 7 14:11:36 2018 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Sat, 7 Apr 2018 16:11:36 +0200 Subject: ZuriHac 2018 GHC DevOps track - Request for Contributions In-Reply-To: <264DB8C9-A0E1-42FB-8435-5B651EACA203@iki.fi> References: <264DB8C9-A0E1-42FB-8435-5B651EACA203@iki.fi> Message-ID: <47de58dc-c313-e71f-308c-3ff87aeeccc6@nh2.me> On 07/04/2018 16.06, Oleg Grenrus wrote: > I hope Hadrian topics qualify under "building GHC from source"? Of course! From ben at well-typed.com Sat Apr 7 17:00:44 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 07 Apr 2018 13:00:44 -0400 Subject: DTrace patch for FreeBSD breaks ability to function as a bootstrap compiler under FreeBSD In-Reply-To: References: Message-ID: <873707dk91.fsf@smart-cactus.org> raichoo via ghc-devs writes: > Hi, > > Last year I've provided a patch that enables DTrace probes under > FreeBSD, sadly as it turns out this currently breaks the ability of > GHC 8.4.1 to function as a bootstrap compiler under FreeBSD. I've > provided a patch that adds a flag to the build system so one can turn > off DTrace in case one needs to build a bootstrap compiler. > > https://phabricator.haskell.org/D4575 > Thanks for the patch. Do you think you could open a ticket for this to make sure we don't lose track of it? > This should probably also contain some heads up in the documentation, > otherwise someone might end up with a compiler that's not suitable for > bootstrapping. Not sure on how this is being handled. > > I have an idea on how to fix the actual issue but for the time being > this might be a suitable workaround. Maybe we can still get this into > 8.4.2? I've already notified the FreeBSD ports maintainers regarding > this issue. Yes, I can push this to 8.4.2. Thanks for the heads-up! > > Sorry for the inconvenience. > > Kind regards, > raichoo > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simon.jakobi at googlemail.com Sat Apr 7 22:30:08 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Sun, 8 Apr 2018 00:30:08 +0200 Subject: How do you build the haddocks for a boot library? Message-ID: Hi, I have some changes to the haddocks in ghc-prim which are re-exported from base. In order to check that I got the syntax right I've tried to build the haddocks by following https://ghc.haskell.org/trac/ghc/wiki/Building/Docs#Haddockdocumentation. Sadly, when I run "make html" in libraries/ghc-prim or libraries/base I get the following error: GNUmakefile:3: libraries/ghc-prim/mk/sub-makefile.mk: No such file or directory make: *** No rule to make target 'libraries/ghc-prim/mk/sub-makefile.mk'. Stop. What should I do instead? Cheers, Simon From omeragacan at gmail.com Sun Apr 8 09:07:46 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 8 Apr 2018 12:07:46 +0300 Subject: New slow validate errors Message-ID: Hi, I see a lot of these errors in slow validate using current GHC HEAD: ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180407 for x86_64-unknown-linux): Each block should be reachable from only one ProcPoint This wasn't happening ~10 days ago. I suspect it may be D4417 but I haven't checked. Ömer From michal.terepeta at gmail.com Sun Apr 8 12:46:47 2018 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 08 Apr 2018 12:46:47 +0000 Subject: New slow validate errors In-Reply-To: References: Message-ID: Yes, sorry for that! This is tracked in: https://ghc.haskell.org/trac/ghc/ticket/14989 Revert: https://phabricator.haskell.org/D4577 - Michal On Sun, Apr 8, 2018 at 11:08 AM Ömer Sinan Ağacan wrote: > Hi, > > I see a lot of these errors in slow validate using current GHC HEAD: > > ghc: panic! (the 'impossible' happened) > (GHC version 8.5.20180407 for x86_64-unknown-linux): > Each block should be reachable from only one ProcPoint > > This wasn't happening ~10 days ago. I suspect it may be D4417 but I haven't > checked. > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Sun Apr 8 13:01:58 2018 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 08 Apr 2018 13:01:58 +0000 Subject: ZuriHac 2018 GHC DevOps track - Request for Contributions In-Reply-To: References: Message-ID: On Sat, Apr 7, 2018 at 3:34 PM Niklas Hambüchen wrote: > Hi GHC devs, > > The ZuriHac 2018 conference will feature a GHC DevOps track (which > Andreas and I are coordinating), that will be all about fostering > contributions to GHC and learning to hack it. There will be a room or > two allocated at Zurihac for this purpose. > [...] > Please contact Andreas or me (on this list or privately) if you think > you could help in any of these directions! > If you're not sure, contact us anyway and tell us your idea! > > Best, > Niklas and Andreas > ZuriHac 2018 GHC DevOps track coordinators > Hi Niklas, Andreas, I'd be happy to help. :) I know a bit about the backend (e.g., cmm level), but it might be tricky to find there some smaller/self-contained projects that would fit ZuriHac. You've mentioned performance regression tests - maybe we could also work on improving nofib? - Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Mon Apr 9 04:56:33 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 9 Apr 2018 07:56:33 +0300 Subject: ZuriHac 2018 GHC DevOps track - Request for Contributions In-Reply-To: References: Message-ID: Hi, I'd also be happy to help. At the very least I can be around as a mentor, but if I can find a suitable hask I may also host a hacking session. Ömer 2018-04-08 16:01 GMT+03:00 Michal Terepeta : > On Sat, Apr 7, 2018 at 3:34 PM Niklas Hambüchen wrote: >> >> Hi GHC devs, >> >> The ZuriHac 2018 conference will feature a GHC DevOps track (which >> Andreas and I are coordinating), that will be all about fostering >> contributions to GHC and learning to hack it. There will be a room or >> two allocated at Zurihac for this purpose. >> [...] >> Please contact Andreas or me (on this list or privately) if you think >> you could help in any of these directions! >> If you're not sure, contact us anyway and tell us your idea! >> >> Best, >> Niklas and Andreas >> ZuriHac 2018 GHC DevOps track coordinators > > > Hi Niklas, Andreas, > > I'd be happy to help. :) I know a bit about the backend (e.g., cmm level), > but it might be tricky to find there some smaller/self-contained projects > that would fit ZuriHac. > You've mentioned performance regression tests - maybe we could also work on > improving nofib? > > - Michal > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at well-typed.com Mon Apr 9 15:13:05 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 09 Apr 2018 11:13:05 -0400 Subject: How do you build the haddocks for a boot library? In-Reply-To: References: Message-ID: <87r2nobeh0.fsf@smart-cactus.org> Simon Jakobi via ghc-devs writes: > Hi, > > I have some changes to the haddocks in ghc-prim which are re-exported > from base. In order to check that I got the syntax right I've tried to > build the haddocks by following > https://ghc.haskell.org/trac/ghc/wiki/Building/Docs#Haddockdocumentation. > > Sadly, when I run "make html" in libraries/ghc-prim or libraries/base > I get the following error: > > GNUmakefile:3: libraries/ghc-prim/mk/sub-makefile.mk: No such file > or directory > make: *** No rule to make target > 'libraries/ghc-prim/mk/sub-makefile.mk'. Stop. > > What should I do instead? > Indeed this is a bug. See D4580 for a fix. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simon.jakobi at googlemail.com Mon Apr 9 15:41:06 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Mon, 9 Apr 2018 17:41:06 +0200 Subject: How do you build the haddocks for a boot library? In-Reply-To: <87r2nobeh0.fsf@smart-cactus.org> References: <87r2nobeh0.fsf@smart-cactus.org> Message-ID: Ah, ok! Thanks for the fix, Ben! 2018-04-09 17:13 GMT+02:00 Ben Gamari : > Simon Jakobi via ghc-devs writes: > >> Hi, >> >> I have some changes to the haddocks in ghc-prim which are re-exported >> from base. In order to check that I got the syntax right I've tried to >> build the haddocks by following >> https://ghc.haskell.org/trac/ghc/wiki/Building/Docs#Haddockdocumentation. >> >> Sadly, when I run "make html" in libraries/ghc-prim or libraries/base >> I get the following error: >> >> GNUmakefile:3: libraries/ghc-prim/mk/sub-makefile.mk: No such file >> or directory >> make: *** No rule to make target >> 'libraries/ghc-prim/mk/sub-makefile.mk'. Stop. >> >> What should I do instead? >> > Indeed this is a bug. See D4580 for a fix. > > Cheers, > > - Ben From csaba.hruska at gmail.com Mon Apr 9 23:23:11 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 10 Apr 2018 01:23:11 +0200 Subject: GHC Core / STG to supercombinators Message-ID: Hello, I'd like to use GHC as a haskell frontend in a project. I wonder what is the easiest way to compile Haskell to supercombinators (top level functions) using GHC as a library. Is it possible to use the simplifier to transform the parsed Haskell source to supercombinators? i.e. to do - eta expansion - closure conversion - lambda lifting Regarding the eta expansion and lambda lifting it seems (according the comments in simplifier code) it does not guarantee to make these transformations in every case. If GHC could transform the Core representation to supercombinators, which transformation should I use from *CoreToDo*? https://github.com/ghc/ghc/blob/master/compiler/simplCore/CoreMonad.hs#L107- L135 I'd like to use GHC as a frontend for my custom code generator which can handle (lazy) top level functions only. Is it better to use GHC as a library or is it better to write a compiler plugin to capture the core representation. I do not want to optimize the Core at all neither want to use other parts of GHC's backend (i.e. codegen). Ideally GHC would typecheck and transform everything to top level function and my system would do the rest. Do you know what would be the easiest way to do this? (i.e. via *CoreToDo* or custom calls for the simplifying functions) Or would it be simpler to generate top level (lazy) functions from STG? Regards, Csaba Hruska -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Tue Apr 10 11:11:43 2018 From: benl at ouroborus.net (Ben Lippmeier) Date: Tue, 10 Apr 2018 21:11:43 +1000 Subject: GHC Core / STG to supercombinators In-Reply-To: References: Message-ID: <9006D5BC-1D5D-4D15-97A2-04AB9238B56E@ouroborus.net> > On 10 Apr 2018, at 9:23 am, Csaba Hruska wrote: > > I'd like to use GHC as a haskell frontend in a project. > I wonder what is the easiest way to compile Haskell to supercombinators (top level functions) using GHC as a library. > > Is it possible to use the simplifier to transform the parsed Haskell source to supercombinators? i.e. to do The Intel Haskell Research Compiler did something similar. See: https://github.com/IntelLabs/flrc http://www.leafpetersen.com/leaf/publications/hs2013/hrc-paper.pdf Ben. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alicekoroleva239 at gmail.com Tue Apr 10 20:04:07 2018 From: alicekoroleva239 at gmail.com (alice) Date: Tue, 10 Apr 2018 23:04:07 +0300 Subject: TcPluginContradiction understanding problem and converting Type to Typeable Message-ID: <7357686E-6864-49F5-9668-EA1DC813D529@gmail.com> Hello, I'm writing a type-checker plugin for ghc, and I'm stuck on two problems. I can't understand how does TcPluginContradiction work. My problem is, when I do TcPluginContradiction listOfFailedConstraints and run the plugin on something which should fail, compiler output contains strange errors for places which doesn't produce any errors when the rest type checks. And it can be seen from debug that listOfFailedConstraints does contain only the constraints that are expected to fail. For example my plugin should type check Set '[Int]) ~ Set '[Int, Int], and should not Set '[Int, Bool, Int] ~ Set '[Int]. And everything is great when I run it on the first case, but if I run it on the both first and second, the compiler output will contain «Couldn't match type ‘Set '[Int]’ with ‘Set '[Int, Int]’» and «Couldn't match type ‘Set '[Int, Bool, Int]’ with ‘Set '[Int]’». My ghc version is 8.2.2. Also how does ghc converts Type from https://hackage.haskell.org/package/ghc-8.2.1/docs/src/TyCoRep.html#Type to Typeable/TypeRep from https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Typeable.Internal.html#TypeRep ? I’d like to use a function (if there exists one) that takes Type and returns its fingerprint (https://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Fingerprint.Type.html#Fingerprint ). Thank you for your time, Alice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Apr 10 22:22:35 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 10 Apr 2018 18:22:35 -0400 Subject: ghc-8.4.1-release tag Message-ID: Hi, I noticed that the tag ghc-8.4.1-release points to f31c40efdc918bc9da8a325327ba5a472bd6ea9e but the tarball has different content: $ cat /tmp/ghc-8.4.1/GIT_COMMIT_ID 0a3e2f324dbd525d626ebd3d97e8ffa1cf2f0ffb Ben, would you mind updating the git tag to reflect reality, to avoid confusion (it’s be a forced tag update, but still better than inconsistent information). Cheers, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From adam at well-typed.com Wed Apr 11 13:07:43 2018 From: adam at well-typed.com (Adam Gundry) Date: Wed, 11 Apr 2018 14:07:43 +0100 Subject: TcPluginContradiction understanding problem and converting Type to Typeable In-Reply-To: <7357686E-6864-49F5-9668-EA1DC813D529@gmail.com> References: <7357686E-6864-49F5-9668-EA1DC813D529@gmail.com> Message-ID: Hi Alice, TcPluginContradiction is intended to be used when the set of constraints provided to the plugin is inherently impossible to solve (and that GHC or other plugins should give up trying). Unfortunately it doesn't provide a way to say "I solved some constraints, but not others". Instead, I think you can simply return TcPluginOk with the constraint you have solved, and no new constraints. The unsolved constraint will still be reported as an error. No doubt this interface could be improved and better documented! Hope this helps, Adam On 10/04/18 21:04, alice wrote: > Hello, I'm writing a type-checker plugin for ghc, and I'm stuck on two > problems. I can't understand how does TcPluginContradiction work. My > problem is, when I do TcPluginContradiction listOfFailedConstraints and > run the plugin on something which should fail, compiler output contains > strange errors for places which doesn't produce any errors when the rest > type checks. And it can be seen from debug that listOfFailedConstraints > does contain only the constraints that are expected to fail.  > For example my plugin should type check Set '[Int]) ~ Set '[Int, Int], > and should not Set '[Int, Bool, Int] ~ Set '[Int]. And everything is > great when I run it on the first case, but if I run it on the both first > and second, the compiler output will contain «Couldn't match type ‘Set > '[Int]’ with ‘Set '[Int, Int]’» and «Couldn't match type ‘Set '[Int, > Bool, Int]’ with ‘Set '[Int]’». > My ghc version is 8.2.2. > Also how does ghc converts Type from > https://hackage.haskell.org/package/ghc-8.2.1/docs/src/TyCoRep.html#Type > to Typeable/TypeRep from > https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Typeable.Internal.html#TypeRep? > I’d like to use a function (if there exists one) that takes Type and > returns its fingerprint > (https://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Fingerprint.Type.html#Fingerprint).  > > Thank you for your time, > Alice. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ryan.gl.scott at gmail.com Wed Apr 11 18:08:23 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 11 Apr 2018 14:08:23 -0400 Subject: [ANNOUNCE] GHC 8.4.1 released Message-ID: Thanks, Ben. It looks like the version number for base has not been bumped to 4.11.1.0, despite incorporating this commit [1] which introduces readFieldHash to base. Currently, this makes it impossible to guard against the existence of the readFieldHash function in a project I'm working on. Ryan S. ----- [1] http://git.haskell.org/ghc.git/commit/d5577f44eaf3b9dfdfc77828038782bf818c176a From ryan.gl.scott at gmail.com Thu Apr 12 12:47:58 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 12 Apr 2018 08:47:58 -0400 Subject: [ANNOUNCE] GHC 8.4.1 released Message-ID: I've submitted a Diff [1] for this. Ryan S. ----- [1] https://phabricator.haskell.org/D4586 From iavor.diatchki at gmail.com Thu Apr 12 23:47:09 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 12 Apr 2018 23:47:09 +0000 Subject: Question about TypeInType Message-ID: Hello, I was experimenting with TypeInType and run into a problem, that can be reduced to the following example. Does anyone have any insight on what causes the error, in particular why is `IxKind` not being reduced? -Iavor {-# Language TypeInType, TypeFamilies #-} module Help where import Data.Kind type family IxKind (m :: Type) :: Type type family Value (m :: Type) :: IxKind m -> Type data T (k :: Type) (f :: k -> Type) type instance IxKind (T k f) = k type instance Value (T k f) = f {- [1 of 1] Compiling Help ( Desktop/Help.hs, interpreted ) Desktop/Help.hs:13:31: error: • Expected kind ‘IxKind (T k f) -> *’, but ‘f’ has kind ‘k -> *’ • In the type ‘f’ In the type instance declaration for ‘Value’ | 13 | type instance Value (T k f) = f | ^ Failed, no modules loaded. -} -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Apr 13 01:39:23 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 12 Apr 2018 21:39:23 -0400 Subject: Question about TypeInType In-Reply-To: References: Message-ID: I think this is #12088. The problem is that open type family instances aren't used in kind checking in the same region of a module. The workaround is to put a top-level Template Haskell splice > $(return []) between the two type instances. This is far from optimal, but fixing it is a Major Project. See https://ghc.haskell.org/trac/ghc/ticket/12088#comment:15 Richard > On Apr 12, 2018, at 7:47 PM, Iavor Diatchki wrote: > > Hello, > > I was experimenting with TypeInType and run into a problem, that can be reduced to the following example. Does anyone have any insight on what causes the error, in particular why is `IxKind` not being reduced? > > -Iavor > > > {-# Language TypeInType, TypeFamilies #-} > > module Help where > > import Data.Kind > > type family IxKind (m :: Type) :: Type > type family Value (m :: Type) :: IxKind m -> Type > > data T (k :: Type) (f :: k -> Type) > > type instance IxKind (T k f) = k > type instance Value (T k f) = f > > {- > [1 of 1] Compiling Help ( Desktop/Help.hs, interpreted ) > Desktop/Help.hs:13:31: error: > • Expected kind ‘IxKind (T k f) -> *’, but ‘f’ has kind ‘k -> *’ > • In the type ‘f’ > In the type instance declaration for ‘Value’ > | > 13 | type instance Value (T k f) = f > | ^ > Failed, no modules loaded. > -} > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From raichoo at googlemail.com Fri Apr 13 11:33:07 2018 From: raichoo at googlemail.com (raichoo) Date: Fri, 13 Apr 2018 13:33:07 +0200 Subject: DTrace patch for FreeBSD breaks ability to function as a bootstrap compiler under FreeBSD In-Reply-To: <873707dk91.fsf@smart-cactus.org> References: <873707dk91.fsf@smart-cactus.org> Message-ID: Darn, just saw your message, sorry. I'll file a ticket once I can reach trac again. On Sat, Apr 7, 2018 at 7:00 PM, Ben Gamari wrote: > raichoo via ghc-devs writes: > > > Hi, > > > > Last year I've provided a patch that enables DTrace probes under > > FreeBSD, sadly as it turns out this currently breaks the ability of > > GHC 8.4.1 to function as a bootstrap compiler under FreeBSD. I've > > provided a patch that adds a flag to the build system so one can turn > > off DTrace in case one needs to build a bootstrap compiler. > > > > https://phabricator.haskell.org/D4575 > > > Thanks for the patch. Do you think you could open a ticket for this to > make sure we don't lose track of it? > > > This should probably also contain some heads up in the documentation, > > otherwise someone might end up with a compiler that's not suitable for > > bootstrapping. Not sure on how this is being handled. > > > > I have an idea on how to fix the actual issue but for the time being > > this might be a suitable workaround. Maybe we can still get this into > > 8.4.2? I've already notified the FreeBSD ports maintainers regarding > > this issue. > > Yes, I can push this to 8.4.2. > > Thanks for the heads-up! > > > > Sorry for the inconvenience. > > > > Kind regards, > > raichoo > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjanen.loic at gmail.com Fri Apr 13 15:22:17 2018 From: arjanen.loic at gmail.com (ARJANEN =?ISO-8859-1?Q?Lo=EFc?= Jean David) Date: Fri, 13 Apr 2018 22:22:17 +0700 Subject: Error submitting a code review Message-ID: <2219902.RNrllMZZg3@berenger> Hello, I'm currently having an issue submitting my first code review. I recently registered on Phabricator and tried to send my first code review through the web interface. However, Harbormaster is failing to build it with the following error in the lease: Couldn't find remote ref. When searching on Google for this error, I found indications that it's related to Drydock not managing to push the changes to the staging area, likely due to a bad SSH key or git URL for arcanist. Could the SSH key issue also apply when using the web interface?Hoping to read from you soon, I wish you a very good day. Yours sincerely,ARJANEN Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Fri Apr 13 15:49:08 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 13 Apr 2018 16:49:08 +0100 Subject: Error submitting a code review In-Reply-To: <2219902.RNrllMZZg3@berenger> References: <2219902.RNrllMZZg3@berenger> Message-ID: Harbormaster only works if you use `arc` to submit the patch. You can see how to use `arc` from the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Phabricator Cheers, Matt On Fri, Apr 13, 2018 at 4:22 PM, ARJANEN Loïc Jean David wrote: > Hello, > > I'm currently having an issue submitting my first code review. I recently > registered on Phabricator and tried to send my first code review through the > web interface. However, Harbormaster is failing to build it with the > following error in the lease: Couldn't find remote ref. When searching on > Google for this error, I found indications that it's related to Drydock not > managing to push the changes to the staging area, likely due to a bad SSH > key or git URL for arcanist. Could the SSH key issue also apply when using > the web interface? > Hoping to read from you soon, I wish you a very good day. > > Yours sincerely, > ARJANEN Loïc > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From arjanen.loic at gmail.com Fri Apr 13 16:14:51 2018 From: arjanen.loic at gmail.com (ARJANEN =?ISO-8859-1?Q?Lo=EFc?= Jean David) Date: Fri, 13 Apr 2018 23:14:51 +0700 Subject: Error submitting a code review In-Reply-To: References: <2219902.RNrllMZZg3@berenger> Message-ID: <2978584.LgBpH0DMgv@berenger> Thanks for the answer. Is there any way to remove an existing draft code review? I'm not seeing any in the web interface. Yours sincerely, ARJANEN Loïc Le vendredi 13 avril 2018, 22:49:08 +07 Matthew Pickering a écrit : > Harbormaster only works if you use `arc` to submit the patch. > > You can see how to use `arc` from the wiki page: > https://ghc.haskell.org/trac/ghc/wiki/Phabricator > > Cheers, > > Matt > > On Fri, Apr 13, 2018 at 4:22 PM, ARJANEN Loïc Jean David > > wrote: > > Hello, > > > > I'm currently having an issue submitting my first code review. I recently > > registered on Phabricator and tried to send my first code review through > > the web interface. However, Harbormaster is failing to build it with the > > following error in the lease: Couldn't find remote ref. When searching on > > Google for this error, I found indications that it's related to Drydock > > not managing to push the changes to the staging area, likely due to a bad > > SSH key or git URL for arcanist. Could the SSH key issue also apply when > > using the web interface? > > Hoping to read from you soon, I wish you a very good day. > > > > Yours sincerely, > > ARJANEN Loïc > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From moritz at lichtzwerge.de Fri Apr 13 18:01:06 2018 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 13 Apr 2018 20:01:06 +0200 Subject: Error submitting a code review In-Reply-To: <2978584.LgBpH0DMgv@berenger> References: <2219902.RNrllMZZg3@berenger> <2978584.LgBpH0DMgv@berenger> Message-ID: Choose “Abandon Revision” in the comment field at the end of the review. Sent from my iPhone > On 13 Apr 2018, at 6:14 PM, ARJANEN Loïc Jean David wrote: > > Thanks for the answer. Is there any way to remove an existing draft code > review? I'm not seeing any in the web interface. > > Yours sincerely, > ARJANEN Loïc > > Le vendredi 13 avril 2018, 22:49:08 +07 Matthew Pickering a écrit : >> Harbormaster only works if you use `arc` to submit the patch. >> >> You can see how to use `arc` from the wiki page: >> https://ghc.haskell.org/trac/ghc/wiki/Phabricator >> >> Cheers, >> >> Matt >> >> On Fri, Apr 13, 2018 at 4:22 PM, ARJANEN Loïc Jean David >> >> wrote: >>> Hello, >>> >>> I'm currently having an issue submitting my first code review. I recently >>> registered on Phabricator and tried to send my first code review through >>> the web interface. However, Harbormaster is failing to build it with the >>> following error in the lease: Couldn't find remote ref. When searching on >>> Google for this error, I found indications that it's related to Drydock >>> not managing to push the changes to the staging area, likely due to a bad >>> SSH key or git URL for arcanist. Could the SSH key issue also apply when >>> using the web interface? >>> Hoping to read from you soon, I wish you a very good day. >>> >>> Yours sincerely, >>> ARJANEN Loïc >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Fri Apr 13 19:17:31 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 13 Apr 2018 20:17:31 +0100 Subject: Error submitting a code review In-Reply-To: <2978584.LgBpH0DMgv@berenger> References: <2219902.RNrllMZZg3@berenger> <2978584.LgBpH0DMgv@berenger> Message-ID: Or you can use `arc diff --update D1234` to update the existing differential. On Fri, Apr 13, 2018 at 5:14 PM, ARJANEN Loïc Jean David wrote: > Thanks for the answer. Is there any way to remove an existing draft code > review? I'm not seeing any in the web interface. > > Yours sincerely, > ARJANEN Loïc > > Le vendredi 13 avril 2018, 22:49:08 +07 Matthew Pickering a écrit : >> Harbormaster only works if you use `arc` to submit the patch. >> >> You can see how to use `arc` from the wiki page: >> https://ghc.haskell.org/trac/ghc/wiki/Phabricator >> >> Cheers, >> >> Matt >> >> On Fri, Apr 13, 2018 at 4:22 PM, ARJANEN Loïc Jean David >> >> wrote: >> > Hello, >> > >> > I'm currently having an issue submitting my first code review. I recently >> > registered on Phabricator and tried to send my first code review through >> > the web interface. However, Harbormaster is failing to build it with the >> > following error in the lease: Couldn't find remote ref. When searching on >> > Google for this error, I found indications that it's related to Drydock >> > not managing to push the changes to the staging area, likely due to a bad >> > SSH key or git URL for arcanist. Could the SSH key issue also apply when >> > using the web interface? >> > Hoping to read from you soon, I wish you a very good day. >> > >> > Yours sincerely, >> > ARJANEN Loïc >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From takenobu.hs at gmail.com Sun Apr 15 06:37:59 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sun, 15 Apr 2018 15:37:59 +0900 Subject: Site of ghc.haskell.org is down? Message-ID: Hi devs, When I accessed `https://ghc.haskell.org/`, the following message is displayed: Your connection is not secure I checked it with Firefox and Chrome. Is it a matter of site setting? Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kane at kane.cx Sun Apr 15 07:19:43 2018 From: kane at kane.cx (David Kraeutmann) Date: Sun, 15 Apr 2018 03:19:43 -0400 Subject: Site of ghc.haskell.org is down? In-Reply-To: References: Message-ID: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> It's an issue with the site---the SSL certificate seems to have expired. On 04/15/2018 02:37 AM, Takenobu Tani wrote: > Hi devs, > > When I accessed `https://ghc.haskell.org/` > , the following message is displayed: > >   Your connection is not secure > > I checked it with Firefox and Chrome. > Is it a matter of site setting? > > Regards, > Takenobu > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From a.pelenitsyn at gmail.com Sun Apr 15 12:07:34 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Sun, 15 Apr 2018 14:07:34 +0200 (CEST) Subject: Site of ghc.haskell.org is down? In-Reply-To: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> References: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> Message-ID: Another issue, not directly connected, but also with the site: the menu links on haskell.org/ghc (Report a bug, Request a feature, Developers (wiki)) point to Hackage subdomain instead of ghc one. -- Best, Artem On Sun, 15 Apr 2018, David Kraeutmann wrote: > It's an issue with the site---the SSL certificate seems to have expired. > > > On 04/15/2018 02:37 AM, Takenobu Tani wrote: >> Hi devs, >> >> When I accessed `https://ghc.haskell.org/` >> , the following message is displayed: >> >>   Your connection is not secure >> >> I checked it with Firefox and Chrome. >> Is it a matter of site setting? >> >> Regards, >> Takenobu >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Sun Apr 15 17:49:04 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sun, 15 Apr 2018 17:49:04 +0000 Subject: Site of ghc.haskell.org is down? In-Reply-To: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> References: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> Message-ID: I'm getting this too. ---------- The owner of ghc.haskell.org has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website. This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate. ghc.haskell.org uses an invalid security certificate. The certificate expired on 15 April 2018, 05:49. The current time is 15 April 2018, 18:48. Error code: SEC_ERROR_EXPIRED_CERTIFICATE ----------- It'd be great to get this fixed, since it means no one can access GHC's Trac. Simon | -----Original Message----- | From: ghc-devs On Behalf Of David | Kraeutmann | Sent: 15 April 2018 08:20 | To: ghc-devs at haskell.org | Subject: Re: Site of ghc.haskell.org is down? | | It's an issue with the site---the SSL certificate seems to have expired. | | | On 04/15/2018 02:37 AM, Takenobu Tani wrote: | > Hi devs, | > | > When I accessed `https://ghc.haskell.org/` | > , the following message is displayed: | > | >   Your connection is not secure | > | > I checked it with Firefox and Chrome. | > Is it a matter of site setting? | > | > Regards, | > Takenobu | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From hvriedel at gmail.com Sun Apr 15 21:32:24 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sun, 15 Apr 2018 23:32:24 +0200 Subject: Site of ghc.haskell.org is down? In-Reply-To: References: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> Message-ID: Hi *, Should be fixed now. Please check. -- hvr On Sun, Apr 15, 2018 at 7:49 PM, Simon Peyton Jones via ghc-devs wrote: > I'm getting this too. > > ---------- > The owner of ghc.haskell.org has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website. > > This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate. > > ghc.haskell.org uses an invalid security certificate. The certificate expired on 15 April 2018, 05:49. The current time is 15 April 2018, 18:48. Error code: SEC_ERROR_EXPIRED_CERTIFICATE > > ----------- > > It'd be great to get this fixed, since it means no one can access GHC's Trac. > > Simon > > | -----Original Message----- > | From: ghc-devs On Behalf Of David > | Kraeutmann > | Sent: 15 April 2018 08:20 > | To: ghc-devs at haskell.org > | Subject: Re: Site of ghc.haskell.org is down? > | > | It's an issue with the site---the SSL certificate seems to have expired. > | > | > | On 04/15/2018 02:37 AM, Takenobu Tani wrote: > | > Hi devs, > | > > | > When I accessed `https://ghc.haskell.org/` > | > , the following message is displayed: > | > > | > Your connection is not secure > | > > | > I checked it with Firefox and Chrome. > | > Is it a matter of site setting? > | > > | > Regards, > | > Takenobu > | > > | > > | > > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Apr 16 08:34:48 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Apr 2018 08:34:48 +0000 Subject: Site of ghc.haskell.org is down? In-Reply-To: References: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> Message-ID: Thanks! Yes working again now. Simon | -----Original Message----- | From: Herbert Valerio Riedel | Sent: 15 April 2018 22:32 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Site of ghc.haskell.org is down? | | Hi *, | | Should be fixed now. Please check. | | -- hvr | | On Sun, Apr 15, 2018 at 7:49 PM, Simon Peyton Jones via ghc-devs wrote: | > I'm getting this too. | > | > ---------- | > The owner of ghc.haskell.org has configured their website | improperly. To protect your information from being stolen, Firefox has | not connected to this website. | > | > This site uses HTTP Strict Transport Security (HSTS) to specify that | Firefox may only connect to it securely. As a result, it is not | possible to add an exception for this certificate. | > | > ghc.haskell.org uses an invalid security certificate. The | certificate | > expired on 15 April 2018, 05:49. The current time is 15 April 2018, | > 18:48. Error code: SEC_ERROR_EXPIRED_CERTIFICATE | > | > ----------- | > | > It'd be great to get this fixed, since it means no one can access | GHC's Trac. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs On Behalf Of David | > | Kraeutmann | > | Sent: 15 April 2018 08:20 | > | To: ghc-devs at haskell.org | > | Subject: Re: Site of ghc.haskell.org is down? | > | | > | It's an issue with the site---the SSL certificate seems to have | expired. | > | | > | | > | On 04/15/2018 02:37 AM, Takenobu Tani wrote: | > | > Hi devs, | > | > | > | > When I accessed `https://ghc.haskell.org/` | > | > , the following message is | displayed: | > | > | > | > Your connection is not secure | > | > | > | > I checked it with Firefox and Chrome. | > | > Is it a matter of site setting? | > | > | > | > Regards, | > | > Takenobu | > | > | > | > | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fma | > | > il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7 | > | > | C01%7Csimonpj%40microsoft.com%7Cabca1c88bdb8425bec5308d5a3186d98%7 | > | > | C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636594247667031596&sda | > | > ta=FpvNdlBK6zVLbfSFTYarlkKfc3mwcG0E3FLQqigzVYI%3D&reserved=0 | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail | > | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01% | > | | 7Csimonpj%40microsoft.com%7Cabca1c88bdb8425bec5308d5a3186d98%7C72f98 | > | | 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636594247667041604&sdata=RaiRN | > | MFae8kT%2Fmv5LcD2d2cEnMJ%2BK4B0rTih57DKCDk%3D&reserved=0 | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csi | > | monpj%40microsoft.com%7Cabca1c88bdb8425bec5308d5a3186d98%7C72f988bf86f | > | 141af91ab2d7cd011db47%7C1%7C0%7C636594247667041604&sdata=RaiRNMFae8kT% | > 2Fmv5LcD2d2cEnMJ%2BK4B0rTih57DKCDk%3D&reserved=0 From takenobu.hs at gmail.com Mon Apr 16 12:35:28 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Mon, 16 Apr 2018 21:35:28 +0900 Subject: Site of ghc.haskell.org is down? In-Reply-To: References: <2e113ca5-c53a-9fbd-de1b-935f04e1fd50@kane.cx> Message-ID: Thank you very much. I can now access the site in both Firefox and Chrome. Regards, Takenobu 2018-04-16 6:32 GMT+09:00 Herbert Valerio Riedel : > Hi *, > > Should be fixed now. Please check. > > -- hvr > > On Sun, Apr 15, 2018 at 7:49 PM, Simon Peyton Jones via ghc-devs > wrote: > > I'm getting this too. > > > > ---------- > > The owner of ghc.haskell.org has configured their website improperly. > To protect your information from being stolen, Firefox has not connected to > this website. > > > > This site uses HTTP Strict Transport Security (HSTS) to specify that > Firefox may only connect to it securely. As a result, it is not possible to > add an exception for this certificate. > > > > ghc.haskell.org uses an invalid security certificate. The certificate > expired on 15 April 2018, 05:49. The current time is 15 April 2018, 18:48. > Error code: SEC_ERROR_EXPIRED_CERTIFICATE > > > > ----------- > > > > It'd be great to get this fixed, since it means no one can access GHC's > Trac. > > > > Simon > > > > | -----Original Message----- > > | From: ghc-devs On Behalf Of David > > | Kraeutmann > > | Sent: 15 April 2018 08:20 > > | To: ghc-devs at haskell.org > > | Subject: Re: Site of ghc.haskell.org is down? > > | > > | It's an issue with the site---the SSL certificate seems to have > expired. > > | > > | > > | On 04/15/2018 02:37 AM, Takenobu Tani wrote: > > | > Hi devs, > > | > > > | > When I accessed `https://ghc.haskell.org/` > > | > , the following message is displayed: > > | > > > | > Your connection is not secure > > | > > > | > I checked it with Firefox and Chrome. > > | > Is it a matter of site setting? > > | > > > | > Regards, > > | > Takenobu > > | > > > | > > > | > > > | > _______________________________________________ > > | > ghc-devs mailing list > > | > ghc-devs at haskell.org > > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > | > > | _______________________________________________ > > | ghc-devs mailing list > > | ghc-devs at haskell.org > > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 16 12:47:29 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Apr 2018 12:47:29 +0000 Subject: GHC Core / STG to supercombinators In-Reply-To: References: Message-ID: The FloatOut pass is designed so that it can do lambda lifting for every lambda. I think if you try -ffloat-all-lams that might do it. See CoreMonad.FloatOutSwitches, the floatOutLambdas field Simon From: ghc-devs On Behalf Of Csaba Hruska Sent: 10 April 2018 00:23 To: ghc-devs at haskell.org Subject: GHC Core / STG to supercombinators Hello, I'd like to use GHC as a haskell frontend in a project. I wonder what is the easiest way to compile Haskell to supercombinators (top level functions) using GHC as a library. Is it possible to use the simplifier to transform the parsed Haskell source to supercombinators? i.e. to do * eta expansion * closure conversion * lambda lifting Regarding the eta expansion and lambda lifting it seems (according the comments in simplifier code) it does not guarantee to make these transformations in every case. If GHC could transform the Core representation to supercombinators, which transformation should I use from CoreToDo? https://github.com/ghc/ghc/blob/master/compiler/simplCore/CoreMonad.hs#L107-L135 I'd like to use GHC as a frontend for my custom code generator which can handle (lazy) top level functions only. Is it better to use GHC as a library or is it better to write a compiler plugin to capture the core representation. I do not want to optimize the Core at all neither want to use other parts of GHC's backend (i.e. codegen). Ideally GHC would typecheck and transform everything to top level function and my system would do the rest. Do you know what would be the easiest way to do this? (i.e. via CoreToDo or custom calls for the simplifying functions) Or would it be simpler to generate top level (lazy) functions from STG? Regards, Csaba Hruska -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 16 12:51:59 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Apr 2018 12:51:59 +0000 Subject: Nested Implications In-Reply-To: References: Message-ID: Mathias I suspect substImplication was removed simply because it was never called, but I’m not certain. The entire cloning and substitution business is very heavyweight. Here’s an alternative idea: * Gather ‘fuvs’, the set of all free unification variables of the constraint you are about to solve. * Solve the constraint * For each variable in ‘fuvs’, set its IORef to Flexi; that is, simply undo any unification that has taken place. That seems simple, very non-invasive, and robust. Simon From: Matthías Páll Gissurarson Sent: 10 April 2018 00:57 To: Simon Peyton Jones Subject: Nested Implications Greetings Simon, I've been working on implementing the valid substitutions for typed holes in terms of nested implications, and I think I've worked out how to do it. But one thing bothers me. To use the implications that are passed along with the ReportErrCtxt, I have to clone the type variables within, to avoid having side-effects that could impact later searches. I clone the type variables and create a substitution from the old variables to the new, which I'd like to apply to the implication. When I was looking around for how to do that, I came across this code in GHC 7.6.3 https://downloads.haskell.org/~ghc/7.6-latest/docs/html/libraries/ghc-7.6.3/src/Inst.html The `substImplication` function does precisely what I want, i.e. applies a substitution to an implication. However, that code is no longer present in GHC 8.5! The git history doesn't go far enough back for me to find an explanation, so I wanted to ask: why was this function removed? Is there something I should be wary of if I re-implement it? Please correct me if my approach is all wrong, I'd like to hear what you had in mind. -- - Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 16 15:08:57 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Apr 2018 15:08:57 +0000 Subject: Question about TypeInType In-Reply-To: References: Message-ID: if it is, please can someone add a new regression example to #12088. You can never have too many. Thanks Simon From: ghc-devs On Behalf Of Richard Eisenberg Sent: 13 April 2018 02:39 To: Iavor Diatchki Cc: ghc-devs at haskell.org Subject: Re: Question about TypeInType I think this is #12088. The problem is that open type family instances aren't used in kind checking in the same region of a module. The workaround is to put a top-level Template Haskell splice > $(return []) between the two type instances. This is far from optimal, but fixing it is a Major Project. See https://ghc.haskell.org/trac/ghc/ticket/12088#comment:15 Richard On Apr 12, 2018, at 7:47 PM, Iavor Diatchki > wrote: Hello, I was experimenting with TypeInType and run into a problem, that can be reduced to the following example. Does anyone have any insight on what causes the error, in particular why is `IxKind` not being reduced? -Iavor {-# Language TypeInType, TypeFamilies #-} module Help where import Data.Kind type family IxKind (m :: Type) :: Type type family Value (m :: Type) :: IxKind m -> Type data T (k :: Type) (f :: k -> Type) type instance IxKind (T k f) = k type instance Value (T k f) = f {- [1 of 1] Compiling Help ( Desktop/Help.hs, interpreted ) Desktop/Help.hs:13:31: error: • Expected kind ‘IxKind (T k f) -> *’, but ‘f’ has kind ‘k -> *’ • In the type ‘f’ In the type instance declaration for ‘Value’ | 13 | type instance Value (T k f) = f | ^ Failed, no modules loaded. -} _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Apr 16 15:19:03 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 16 Apr 2018 11:19:03 -0400 Subject: Question about TypeInType In-Reply-To: References: Message-ID: Done. > On Apr 16, 2018, at 11:08 AM, Simon Peyton Jones wrote: > > if it is, please can someone add a new regression example to #12088. You can never have too many. > > Thanks > > Simon > > From: ghc-devs On Behalf Of Richard Eisenberg > Sent: 13 April 2018 02:39 > To: Iavor Diatchki > Cc: ghc-devs at haskell.org > Subject: Re: Question about TypeInType > > I think this is #12088. The problem is that open type family instances aren't used in kind checking in the same region of a module. The workaround is to put a top-level Template Haskell splice > > > $(return []) > > between the two type instances. This is far from optimal, but fixing it is a Major Project. See https://ghc.haskell.org/trac/ghc/ticket/12088#comment:15 > > Richard > > > On Apr 12, 2018, at 7:47 PM, Iavor Diatchki > wrote: > > Hello, > > I was experimenting with TypeInType and run into a problem, that can be reduced to the following example. Does anyone have any insight on what causes the error, in particular why is `IxKind` not being reduced? > > -Iavor > > > {-# Language TypeInType, TypeFamilies #-} > > module Help where > > import Data.Kind > > type family IxKind (m :: Type) :: Type > type family Value (m :: Type) :: IxKind m -> Type > > data T (k :: Type) (f :: k -> Type) > > type instance IxKind (T k f) = k > type instance Value (T k f) = f > > {- > [1 of 1] Compiling Help ( Desktop/Help.hs, interpreted ) > Desktop/Help.hs:13:31: error: > • Expected kind ‘IxKind (T k f) -> *’, but ‘f’ has kind ‘k -> *’ > • In the type ‘f’ > In the type instance declaration for ‘Value’ > | > 13 | type instance Value (T k f) = f > | ^ > Failed, no modules loaded. > -} > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Mon Apr 16 17:22:08 2018 From: david at well-typed.com (David Feuer) Date: Mon, 16 Apr 2018 13:22:08 -0400 Subject: CI builds failing Message-ID: <2738009.pykKlX2gNT@squirrel> It looks like the recent differential builds are all failing like this: compiler/main/DynamicLoading.hs:79:19: warning: [-Wunused-matches] Defined but not used: ‘hsc_env’ | 79 | initializePlugins hsc_env df | ^^^^^^^ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (r_apc3 :: TYPE rep_apc2) rep_apc2 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage1/build/PrelRules.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Oddly, I don't see a commit to master failing like this. What's going on? David From simonpj at microsoft.com Mon Apr 16 21:16:37 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Apr 2018 21:16:37 +0000 Subject: CI builds failing In-Reply-To: <2738009.pykKlX2gNT@squirrel> References: <2738009.pykKlX2gNT@squirrel> Message-ID: I wonder if you are compiling with 8.2.1? It's broken. You need 8.2.2 | -----Original Message----- | From: ghc-devs On Behalf Of David Feuer | Sent: 16 April 2018 18:22 | To: ghc-devs at haskell.org | Subject: CI builds failing | | It looks like the recent differential builds are all failing like this: | | compiler/main/DynamicLoading.hs:79:19: warning: [-Wunused-matches] | Defined but not used: ‘hsc_env’ | | | 79 | initializePlugins hsc_env df | | ^^^^^^^ | ghc: panic! (the 'impossible' happened) | (GHC version 8.2.1 for x86_64-unknown-linux): | runtimeRepPrimRep | typePrimRep (r_apc3 :: TYPE rep_apc2) | rep_apc2 | Call stack: | CallStack (from HasCallStack): | prettyCurrentCallStack, called at | compiler/utils/Outputable.hs:1133:58 in ghc:Outputable | callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in | ghc:Outputable | pprPanic, called at compiler/simplStg/RepType.hs:360:5 in | ghc:RepType | Please report this as a GHC bug: | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hask | ell.org%2Fghc%2Freportabug&data=02%7C01%7Csimonpj%40microsoft.com%7C9cae | ba32974343dc3b4008d5a3bea49b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C636594961595926044&sdata=%2Fnn6O17%2BCIhszUh1CtWoiNcrHvuFKEVoYS%2FyWn7 | JDtk%3D&reserved=0 | make[1]: *** [compiler/stage1/build/PrelRules.o] Error 1 | make[1]: *** Waiting for unfinished jobs.... | make: *** [all] Error 2 | | | Oddly, I don't see a commit to master failing like this. What's going | on? | | David | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C9caeba32974343dc3b4008d5a3 | bea49b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636594961595926044&s | data=oy9JC8aDfj%2BmnyLwDfQQYliavRlu9oXGNLvXYof1uZc%3D&reserved=0 From david at well-typed.com Tue Apr 17 00:54:47 2018 From: david at well-typed.com (David Feuer) Date: Mon, 16 Apr 2018 20:54:47 -0400 Subject: CI builds failing In-Reply-To: References: <2738009.pykKlX2gNT@squirrel> Message-ID: <2105198.3p51slOljT@squirrel> On Monday, April 16, 2018 9:16:37 PM EDT Simon Peyton Jones wrote: > I wonder if you are compiling with 8.2.1? It's broken. You need 8.2.2 I'm talking about Harbormaster and CircleCI. Ben, do you know if someone changed the configuration of the build bots or something? From sylvain at haskus.fr Tue Apr 17 01:08:09 2018 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 17 Apr 2018 03:08:09 +0200 Subject: CI builds failing In-Reply-To: <2105198.3p51slOljT@squirrel> References: <2738009.pykKlX2gNT@squirrel> <2105198.3p51slOljT@squirrel> Message-ID: It should be ok with the following revert: https://git.haskell.org/ghc.git/commitdiff/0e37361392a910ccbbb2719168f4e8d8272b2ae2 On 17/04/2018 02:54, David Feuer wrote: > On Monday, April 16, 2018 9:16:37 PM EDT Simon Peyton Jones wrote: >> I wonder if you are compiling with 8.2.1? It's broken. You need 8.2.2 > I'm talking about Harbormaster and CircleCI. Ben, do you know if someone changed the configuration of the build bots or something? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue Apr 17 15:18:06 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Apr 2018 15:18:06 +0000 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> <924a115c65bd4a0287ade32dd9a69777@ICTSC-W-S211.soliscom.uu.nl> Message-ID: | In order to try to hack my way through and get my library to compile, | I tried progressively adding more and more pattern synonyms to try to | avoid exhaustiveness checking,yet, something really surprising | happened. Big examples have type errors where small ones don't! That is strange. Sounds as if you want a new Trac report, just for that. Simon | -----Original Message----- | From: Victor Miraldo (UU) | Sent: 07 April 2018 12:02 | To: Ben Gamari | Cc: Simon Peyton Jones ; ghc-devs at haskell.org | Subject: Re: Memory usage exploding for complex pattern matching | | Hello all, | | Following up on this, I have created a trac ticket | https://ghc.haskell.org/trac/ghc/ticket/14987#no2 as suggested a | couple days ago. | | In order to try to hack my way through and get my library to compile, | I tried progressively adding more and more pattern synonyms to try to | avoid exhaustiveness checking,yet, something really surprising | happened. Big examples have type errors where small ones don't! | | I tried documenting the process in a repository: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2FVictorCMiraldo%2Fghc-14987-repro- | pipeline&data=02%7C01%7Csimonpj%40microsoft.com%7C59fdacad7f94412d665e | 08d59c7717f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636586957847 | 493826&sdata=bnuBOL%2FELkmJahidX%2BmWPSDDf%2BuKlJkBAJyFVyY%2Bel8%3D&re | served=0 | | Unfortunately, however, I couldn't get the self contained repros in | the repository above to throw type errors. Hence, I'm attaching my | full code. Compiling the file src/Generics/MRSOP/Examples/GoAST.hs | gives type errors, even though it is being generated by the same | template haskell code as the other files inside Examples, all of which | compile just fine. To trigger the error, just run `stack build`. | | It really is a shame that the combination of pattern synonyms that | shows the best memory performance crashes completely on bigger | examples. | | Any suggestions are appreciated, thank you very much! | | Have a great weekend! | Cheers, | Victor | | | | On Fri, Mar 30, 2018 at 5:23 PM, Ben Gamari | wrote: | > "Victor Miraldo (UU)" writes: | > | >> Hello, | >> | >>>>>> I have just tried compiling my code with 8.4.2 and using | >>>>>> -fmax-pmcheck-iterations=0, I gave GHC 12GB of ram and it still | >>>>>> ran out (through `ulimit -v$((1024*1024*12))`). | >>>>>> | >>>>> Hmmm, I'm a bit confused. Why are our results so different? How | >>>>> precisely are you invoking GHC? | >>>> | >>>> Here I meant my whole code, not just the repro. I could have been | more clear. | >>>> Nevertheless, I'm calling it through stack: | >>>> | >>> I'll admit that I am a bit lost; Minimal.hs compiles for me with a | >>> maximum residency of ~3.5 GBytes with both -O1 and the PM check | >>> enabled using GHC 8.4.1. Is this not the repro you are referring | to? | >> | >> I get the same behavior as you for Minimal.hs. | >> | >> The "my code" above referred to the whole library that I'm | developping. | >> In fact, the Minimal.hs file contains a distilled version of that | >> library with a template haskell splice that we are trying to use in | >> one of our fully fledged examples. | >> | > Okay, I just wanted to be certain we were indeed seeing the same | > behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC | > program, even one with the deep matches seen in Minimal.hs. | > | > Cheers, | > | > - Ben | > From simonpj at microsoft.com Wed Apr 18 10:28:00 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Apr 2018 10:28:00 +0000 Subject: Windows: cannot create here-doc In-Reply-To: References: Message-ID: Tamar I have good news. After giving my computer a rest while I was on holiday, and rebooting it, everything seems to be working fine. I have no idea what was going wrong, but it’s not going wrong any more! I’ll keep you posted. Simon From: Phyx Sent: 04 April 2018 23:35 To: Simon Peyton Jones Cc: ghc-devs Subject: Re: Windows: cannot create here-doc Hi Simon, This one is very strange, from the error and the fact that it continues it looks like whatever TEMP and TMP are pointing to are not always available or some locking issue is going on. I would try running ProcMon https://docs.microsoft.com/en-us/sysinternals/downloads/procmon and filtering paths to whatever TEMP and TMP are set to. In the dialog that opens when you run it, select in the first box path, select the "starts with" condition then enter the Windows version of the path in the third one. Make sure the final box is set to "Include" and press add. Then try again. Once it fails, stop capturing (File -> click on "capture events" to unselect). This should contain the accesses to things in your TEMP and why it failed. (If TEMP contains a unix path you can get a windows one with e.g cygpath -w $TEMP) Once we know more can figure out what's going on. Thanks, Tamar On Wed, Apr 4, 2018 at 10:17 PM, Simon Peyton Jones > wrote: Tamar I think your suggestion of adding # Set user-defined locale export LANG=$(locale -uU) worked. No more perl messages. Still having various troubles… Here’s the current one (log below). I’m getting lots of ./configure: line 2534: cannot create temp file for here-document: Device or resource busy And finally checking whether the C compiler works... no sed: can't read conftest.c: No such file or directory configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables I have environment variables TEMP and TMP set. Oddly, re-running configure gets further – see second log below. All deeply strange. Thanks Simon Log 1: first run of ‘sh validate –fast’ Creating libraries/array/ghc.mk Creating libraries/base/ghc.mk Creating libraries/binary/ghc.mk Creating libraries/bytestring/ghc.mk Creating libraries/Cabal/Cabal/ghc.mk Creating libraries/containers/ghc.mk Creating libraries/deepseq/ghc.mk Creating libraries/directory/ghc.mk Creating libraries/dph/dph-base/ghc.mk Creating libraries/dph/dph-prim-interface/ghc.mk Creating libraries/dph/dph-prim-seq/ghc.mk Creating libraries/dph/dph-prim-par/ghc.mk Creating libraries/dph/dph-lifted-base/ghc.mk Creating libraries/dph/dph-lifted-boxed/ghc.mk Creating libraries/dph/dph-lifted-copy/ghc.mk Creating libraries/dph/dph-lifted-vseg/ghc.mk Creating libraries/filepath/ghc.mk Creating libraries/ghc-boot/ghc.mk Creating libraries/ghc-boot-th/ghc.mk Creating libraries/ghc-compact/ghc.mk Creating libraries/ghc-prim/ghc.mk Creating libraries/ghci/ghc.mk Creating libraries/haskeline/ghc.mk Creating libraries/hpc/ghc.mk Creating libraries/integer-gmp/ghc.mk Creating libraries/integer-simple/ghc.mk Creating libraries/mtl/ghc.mk Creating libraries/parallel/ghc.mk Creating libraries/parsec/ghc.mk Creating libraries/pretty/ghc.mk Creating libraries/primitive/ghc.mk Creating libraries/process/ghc.mk Creating libraries/random/ghc.mk Creating libraries/stm/ghc.mk Creating libraries/template-haskell/ghc.mk Creating libraries/terminfo/ghc.mk Creating libraries/text/ghc.mk Creating libraries/time/ghc.mk Creating libraries/transformers/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/vector/ghc.mk Creating libraries/Win32/ghc.mk Creating libraries/xhtml/ghc.mk Booting . Booting libraries/base/ Booting libraries/directory/ Booting libraries/ghc-prim/ Booting libraries/integer-gmp/ Booting libraries/process/ Booting libraries/terminfo/ Booting libraries/time/ Booting libraries/unix/ ./configure: line 2534: cannot create temp file for here-document: Device or resource busy checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180402 checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12efeaa2e7d902 checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-mingw64 checking host system type... x86_64-pc-mingw64 checking target system type... x86_64-pc-mingw64 Build platform inferred as: x86_64-unknown-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... configure: Extracting Windows toolchain from archives (may take a while)... configure: In-tree MingW-w64 tree created checking for genlib... no configure: Making in-tree perl tree configure: In-tree perl tree created checking for -windres... no checking for windres... windres checking for -dllwrap... no checking for dllwrap... dllwrap checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe ./configure: line 5421: cannot create temp file for here-document: Device or resource busy checking whether the C compiler works... no sed: can't read conftest.c: No such file or directory configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables See `config.log' for more details $ Log 2: run of “./configure” $ ./configure ./configure: line 2542: cannot create temp file for here-document: Device or resource busy configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180402 checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12efeaa2e7d902 checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking target system type... x86_64-w64-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... checking for genlib... no checking for -windres... no checking for -dllwrap... no checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether C:/code/HEAD/inplace/mingw/bin/gcc.exe accepts -g... ./configure: line 5717: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory no checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C89... ./configure: line 5793: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory unsupported checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... ./configure: line 1796: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe -E checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/fp/HP-8.2.2/lib/../mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for -ld... C:/code/HEAD/inplace/mingw/bin/ld.exe checking whether ld is GNU ld... YES checking whether ld understands --build-id... yes checking whether ld understands -no_compact_unwind... yes checking whether ld understands -filelist... no checking for -objdump... (cached) C:/code/HEAD/inplace/mingw/bin/objdump.exe checking for ranlib... C:/code/HEAD/inplace/mingw/bin/ranlib.exe checking for -strip... no checking for libtool... /usr/bin/libtool checking for -clang... no checking for llc-5.0... no checking for llc... no checking for opt-5.0... no checking for opt... no configure: Creating links for in-tree file handling routines. 'utils/lndir/fs.c' => 'utils/fs/fs.c' 'utils/lndir/fs.h' => 'utils/fs/fs.h' 'utils/unlit/fs.c' => 'utils/fs/fs.c' 'utils/unlit/fs.h' => 'utils/fs/fs.h' 'rts/fs.c' => 'utils/fs/fs.c' 'rts/fs.h' => 'utils/fs/fs.h' 'libraries/base/include/fs.h' => 'utils/fs/fs.h' 'libraries/base/cbits/fs.c' => 'utils/fs/fs.c' configure: Routines in place. Packages can now be build normally. checking whether #! works in shell scripts... yes checking version of gcc... 7.2.0 checking whether GCC supports -no-pie... yes checking for extra options to pass gcc when compiling via C... -fwrapv -fno-builtin checking whether C compiler is clang... no checking whether C compiler has an LLVM back end... no checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done checking for .subsections_via_symbols... no checking whether your assembler supports .ident directive... yes checking for GNU non-executable stack support... no checking for a working context diff... diff -U 1 checking for a BSD-compatible install... /usr/bin/install -c checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe is GNU ar... yes checking for ar arguments... q checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe supports @file... yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.d.podlovics at gmail.com Wed Apr 18 20:23:19 2018 From: peter.d.podlovics at gmail.com (Peter Podlovics) Date: Wed, 18 Apr 2018 22:23:19 +0200 Subject: GHC extensions Message-ID: Hi everyone, I have a question about handling missing extension errors in modules. What does exactly happen if an extension is needed for a certain language element, but it is not present? I couldn't find the code segment where error messages are handled, and since there are no immediate program interrupts at their creation site (e.g.: at TcValidity.checkValidType), I can only assume that there is some tricky laziness in action here. Does the type checker still continue its business after encountering such an error; or does it stop, and dump its the error messages? Thanks in advance, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Thu Apr 19 12:45:03 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 19 Apr 2018 08:45:03 -0400 Subject: GHC extensions Message-ID: Hi Peter, > What does exactly happen if an extension is needed for a certain language element, but it is not present? Generally, these manifest as runtime checks of the form (xopt LangExt.TheLanguageExtensionName dflags). For an example, see [1], where GHC checks if the TypeFamilyDependencies extension is enabled, and if not, subsequently throws an error. > Does the type checker still continue its business after encountering such an error; or does it stop, and dump its the error messages? It depends. Sometimes, GHC uses the addErrTc function to add an error but not cause an outright failure, continuing until there is a fatal error. The failWithTc function, on the other hand, adds an error and causes GHC to exit, reporting all errors it's collected up to that point. (The example in [1] does this.) Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/5d76846405240c051b00cddcda9d8d02c880968e:/compiler/typecheck/TcTyClsDecls.hs#l1097 From ben at well-typed.com Fri Apr 20 00:01:22 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 19 Apr 2018 20:01:22 -0400 Subject: [ANNOUNCE] GHC 8.4.2 released Message-ID: <87in8md9v9.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release, fixing numerous regressions and bugs present in GHC 8.4.1. These include: * A regression resulting in some uses of `Control.Exception.evaluate` to be inappropriately optimised away (see #13930) * A regression resulting in segmentation faults of programs compiled with profiling (#14705) * A bug causing runtime system panics while running programs with retainer profiling (#14947) * The configure scripts now accepts a `--disable-dtrace` option, again allowing GHC to be bootstrapped on FreeBSD (#15040) * The version number of the `base` package has been bumped to 4.11.1.0 to reflect the addition of the `GHC.IO.FixIOException` type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. * Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.html Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri Apr 20 00:26:38 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 19 Apr 2018 20:26:38 -0400 Subject: Plan for GHC 8.6.1 Message-ID: <87h8o6d8p8.fsf@smart-cactus.org> Hello fellow lazy purists, With GHC 8.4.2 out the door, it is time to begin looking forward to 8.6.1. In keeping with our six-month release schedule, this release will be targetted for early-September, with the stable branch being cut in mid-to-late June. Remarkably, this is only 6 weeks away. If you have patches that you would like to see in 8.6.1, please do put them up on Phabricator and the 8.6.1 status page [1] in the coming weeks to ensure that there is sufficient time for review. If you have a patch which you are concerned won't make the cut-off, do say something. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Fri Apr 20 05:28:34 2018 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 20 Apr 2018 08:28:34 +0300 Subject: [ANNOUNCE] GHC 8.4.2 released In-Reply-To: <87in8md9v9.fsf@smart-cactus.org> References: <87in8md9v9.fsf@smart-cactus.org> Message-ID: <1524202114.2651.143.camel@jeltsch.info> Am Donnerstag, den 19.04.2018, 20:01 -0400 schrieb Ben Gamari: > Hello everyone, > > The GHC team is pleased to announce the availability of GHC 8.4.2. The > source distribution, binary distributions, and documentation for this > release are available at > >     https://downloads.haskell.org/~ghc/8.4.2 > > This release is a bug-fix release, fixing numerous regressions and > bugs present in GHC 8.4.1. These include: > >  * A regression resulting in some uses of `Control.Exception.evaluate` >    to be inappropriately optimised away (see #13930) > >  * A regression resulting in segmentation faults of programs compiled >    with profiling (#14705) > >  * A bug causing runtime system panics while running programs with >    retainer profiling (#14947) > >  * The configure scripts now accepts a `--disable-dtrace` option, >    again allowing GHC to be bootstrapped on FreeBSD (#15040) > >  * The version number of the `base` package has been bumped to >    4.11.1.0 to reflect the addition of the `GHC.IO.FixIOException` >    type. This interface was added in 8.4.1 but the version bump was >    missed due to an oversight. > >  * Support for DWARF debug information has been significantly improved >    (#14894, #14779) > > A more thorough list of the changes in this release can be found in > the release notes, > >   https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.html What about #15005? It is closed as fixed but not mentioned in the release notes. All the best, Wolfgang From mikolaj at well-typed.com Fri Apr 20 06:55:32 2018 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Fri, 20 Apr 2018 08:55:32 +0200 Subject: [ANNOUNCE] GHC 8.4.2 released In-Reply-To: <1524202114.2651.143.camel@jeltsch.info> References: <87in8md9v9.fsf@smart-cactus.org> <1524202114.2651.143.camel@jeltsch.info> Message-ID: > What about #15005? It is closed as fixed but not mentioned in the > release notes. The fix was merged and included in the release. It's on the list of commits at https://github.com/ghc/ghc/commits/ghc-8.4.2-release * In Exitify, zap idInfo of abstracted variables (fixes #15005) Cheers, Mikolaj From ryan.gl.scott at gmail.com Fri Apr 20 13:19:39 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 20 Apr 2018 09:19:39 -0400 Subject: Plan for GHC 8.6.1 Message-ID: I have one major feature planned: -XDerivingVia. I haven't made a patch yet, since the idea itself is still technically going through the proposal process at [1]. But the feedback seems pretty positive, so I think I'll submit it to the committee next week for final consideration. There is an implementation that's 99% already at [2], so there shouldn't be much of a delay in getting it to Phabricator once the committee gives the go-ahead. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/pull/120 [2] https://github.com/RyanGlScott/ghc/tree/deriving-via-8.5 From alan.zimm at gmail.com Fri Apr 20 13:21:27 2018 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 20 Apr 2018 15:21:27 +0200 Subject: HsVectInstIn is dead code? Message-ID: If I grep through the GHC source, or do a github search[1] It seems that HsVectInst exists, and can be renamed, typechecked, zonked, desugared. But it does not get parse, and does not appear to be introduced in any other way. Am I missing something? Should it be deleted (as hinted at in one of the comments?) Alan [1] https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=HsVectInstIn&type= -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Apr 20 14:58:19 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Apr 2018 14:58:19 +0000 Subject: HsVectInstIn is dead code? In-Reply-To: References: Message-ID: Manuel Can you comment on this? You’ve argued for keeping the vectorisation code in, but is this particular data constructor in VectDecl used? Simon From: ghc-devs On Behalf Of Alan & Kim Zimmerman Sent: 20 April 2018 14:21 To: ghc-devs Subject: HsVectInstIn is dead code? If I grep through the GHC source, or do a github search[1] It seems that HsVectInst exists, and can be renamed, typechecked, zonked, desugared. But it does not get parse, and does not appear to be introduced in any other way. Am I missing something? Should it be deleted (as hinted at in one of the comments?) Alan [1] https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=HsVectInstIn&type= -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Fri Apr 20 16:28:13 2018 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Fri, 20 Apr 2018 18:28:13 +0200 Subject: Accessing 'Annotations' of modules in external packages In-Reply-To: References: Message-ID: ghc-devs is probably a better location for GHC API questions. Anyhow, you might want to look at some code in the Clash compiler: https://github.com/clash-lang/clash-compiler/blob/6ec3ca426bfaaaddcd3692775c25614bc19482fa/clash-ghc/src-ghc/Clash/GHC/LoadInterfaceFiles.hs#L168-L225 We use that to find the following annotations in compiled packages: http://hackage.haskell.org/package/clash-prelude-0.99/docs/Clash-Annotations-Primitive.html Anyhow, the gist of: https://github.com/clash-lang/clash-compiler/blob/6ec3ca426bfaaaddcd3692775c25614bc19482fa/clash-ghc/src-ghc/Clash/GHC/LoadInterfaceFiles.hs#L168-L225 is: * You need a `Module` to start with (you can e.g. get one from a `CoreBndr`) * You need to load the interface file (.hi) for that module. * One you have the contents of the interface file, you can do `TcIface.tcIfaceAnnotations (GHC.mi_anns iface)` to get something of the `Annotation` type. Hope that helps. -- Christiaan On 18 April 2018 at 23:01, Ranjit Jhala wrote: > > Hi all, > > I'm looking for some help using the GHC API to > > access the 'Annotations' (created using the 'ANN' > > mechanism) within modules of *external* packages > > i.e. non-home modules.Currently I'm using > > hscEPS :: HscEnv -> IO ExternalPackageState > > and then using the field > > eps_PIT :: !PackageIfaceTable > > and from there, accessing the > > mi_anns :: [IfaceAnnotation] > > field of the > > data ModIface > > stored in the PackageIfaceTable but this ends in an unfortunate: > > ``` > panic! (the 'impossible' happened) > (GHC version 8.2.2 for x86_64-apple-darwin): > No mi_anns in PIT > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > ``` > > Perhaps this is because, as the documentation for `mi_anns` says: > > Annotations NOT STRICT! we read this field lazily from the interface > file > > but I am not sure how to proceed at this point? Do I need a _different_ > HscEnv? Or perhaps I need to set up/initialize the HscEnv separately? > > Any pointers would be most welcome! > > Thanks! > > Ranjit. > > > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Apr 20 17:56:35 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 20 Apr 2018 13:56:35 -0400 Subject: Plan for GHC 8.6.1 In-Reply-To: References: Message-ID: <87zi1xbw32.fsf@smart-cactus.org> Ryan Scott writes: > I have one major feature planned: -XDerivingVia. I haven't made a > patch yet, since the idea itself is still technically going through > the proposal process at [1]. But the feedback seems pretty positive, > so I think I'll submit it to the committee next week for final > consideration. > > There is an implementation that's 99% already at [2], so there > shouldn't be much of a delay in getting it to Phabricator once the > committee gives the go-ahead. > Right, I think this can be made to work assuming there is no objection from the devops committee. Thanks for the heads-up! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Fri Apr 20 17:58:34 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 20 Apr 2018 13:58:34 -0400 Subject: [ANNOUNCE] GHC 8.4.2 released In-Reply-To: <1524202114.2651.143.camel@jeltsch.info> References: <87in8md9v9.fsf@smart-cactus.org> <1524202114.2651.143.camel@jeltsch.info> Message-ID: <87wox1bvzs.fsf@smart-cactus.org> Wolfgang Jeltsch writes: > Am Donnerstag, den 19.04.2018, 20:01 -0400 schrieb Ben Gamari: >> Hello everyone, >> ... > > What about #15005? It is closed as fixed but not mentioned in the > release notes. > Sigh, yes, it looks like I missed that one in the release notes. Nevertheless, the issue should be fixed. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Fri Apr 20 18:38:53 2018 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 20 Apr 2018 21:38:53 +0300 Subject: [ANNOUNCE] GHC 8.4.2 released In-Reply-To: <87wox1bvzs.fsf@smart-cactus.org> References: <87in8md9v9.fsf@smart-cactus.org> <1524202114.2651.143.camel@jeltsch.info> <87wox1bvzs.fsf@smart-cactus.org> Message-ID: <1524249533.2651.150.camel@jeltsch.info> Am Freitag, den 20.04.2018, 13:58 -0400 schrieb Ben Gamari: > Wolfgang Jeltsch writes: > > What about #15005? It is closed as fixed but not mentioned in the > > release notes. > > Sigh, yes, it looks like I missed that one in the release notes. > > Nevertheless, the issue should be fixed. Yes, it looks fine: the order-maintenance package can be compiled with GHC 8.4.2. All the best, Wolfgang From ben at well-typed.com Sun Apr 22 23:04:49 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 22 Apr 2018 19:04:49 -0400 Subject: GHC HCAR submission Message-ID: <87efj6c06s.fsf@smart-cactus.org> tl;dr. Add your project to GHC's HCAR submission [1]. Hello everyone, I have uploaded a first draft of GHC's May 2018 HCAR submission to the Wiki [1]. While I believe I have covered most of the on-going projects, do check that your project appears and feel free to make any edits you feel appropriate. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/Apr18 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From chak at justtesting.org Mon Apr 23 02:03:51 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 23 Apr 2018 12:03:51 +1000 Subject: HsVectInstIn is dead code? In-Reply-To: References: Message-ID: <2DA4F184-56A1-4111-AB3C-564D7F11CFCE@justtesting.org> Hi Alan, You can remove ’HsVectInstIn’ as well as ’HsVectInstOut’ for that matter. Thanks, Manuel > 20.04.2018 23:21 Alan & Kim Zimmerman : > > If I grep through the GHC source, or do a github search[1] > > It seems that HsVectInst exists, and can be renamed, typechecked, zonked, desugared. > > But it does not get parse, and does not appear to be introduced in any other way. > > Am I missing something? Should it be deleted (as hinted at in one of the comments?) > > Alan > > [1] https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=HsVectInstIn&type= > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From simonpj at microsoft.com Mon Apr 23 09:48:23 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Apr 2018 09:48:23 +0000 Subject: primitive library Message-ID: Andrew, David I've seen a lot of traffic about the primitive library, in which you two are playing a leading role. Clearly something interesting is going on, but I have not been paying enough attention to work out what. Maybe lots of unrelated things? Maybe a handful of closely related things? Would you consider putting out a summary (to libraries and ghc-devs) to give an overview of the main threads, and any driving motivations. Why has all this blown up now? Meanwhile, thank you for being so active. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Apr 23 10:56:55 2018 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 23 Apr 2018 12:56:55 +0200 Subject: Type family constraints Message-ID: Given data GhcPass (c :: Pass) deriving instance Eq (GhcPass c) deriving instance Typeable c => Data (GhcPass c) data Pass = Parsed | Renamed | Typechecked deriving (Data) Is there any way to express that `pass` must be valid for each value of `Pass` in the following instance head? instance (p ~ GhcPass pass, OutputableBndrId p) => Outputable (HsIPBinds p) where This comes from a problem where setting each type family instance separately does not get picked up during instance resolution (and can't be, according to earlier questions by me on this) i.e. type instance XIPBinds (GhcPass 'Parsed) = NoExt type instance XIPBinds (GhcPass 'Renamed) = NoExt type instance XIPBinds (GhcPass 'Typechecked) = TcEvBinds it works fine for type instance XIPBinds (GhcPass _) = NoExt Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Apr 23 13:48:14 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 23 Apr 2018 14:48:14 +0100 Subject: Plan for GHC 8.6.1 In-Reply-To: <87h8o6d8p8.fsf@smart-cactus.org> References: <87h8o6d8p8.fsf@smart-cactus.org> Message-ID: Perhaps Nested CPR will be ready :) ? https://phabricator.haskell.org/D4244 I am also working on the linear types branch. Arnaud is quite keen for it to be ready for 8.6 but we still have a bit to go. Cheers, Matt On Fri, Apr 20, 2018 at 1:26 AM, Ben Gamari wrote: > Hello fellow lazy purists, > > With GHC 8.4.2 out the door, it is time to begin looking forward to > 8.6.1. In keeping with our six-month release schedule, this release will > be targetted for early-September, with the stable branch being cut in > mid-to-late June. > > Remarkably, this is only 6 weeks away. If you have patches that you > would like to see in 8.6.1, please do put them up on Phabricator and the > 8.6.1 status page [1] in the coming weeks to ensure that there is > sufficient time for review. > > If you have a patch which you are concerned won't make the cut-off, do > say something. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From rae at cs.brynmawr.edu Mon Apr 23 14:29:28 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 23 Apr 2018 10:29:28 -0400 Subject: Type family constraints In-Reply-To: References: Message-ID: <5E400C3C-5672-47F5-B187-F30827120F1A@cs.brynmawr.edu> > On Apr 23, 2018, at 6:56 AM, Alan & Kim Zimmerman wrote: > > Is there any way to express that `pass` must be valid for each value of `Pass` in the following instance head? > No, there isn't. And for good reason: whatever you're trying to do likely requires some runtime decision-making, and that's impossible with just type-level information. (Even without that motivation, there's this: any way of doing this would likely break type soundness. See #7259 and #14420.) My recommendation is to have > class ValidPass p > instance ValidPass Parsed > instance ValidPass Renamed > instance ValidPass Typechecked My guess is that you'll need to add a method to ValidPass, anyway. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Apr 23 14:32:43 2018 From: david.feuer at gmail.com (David Feuer) Date: Mon, 23 Apr 2018 14:32:43 +0000 Subject: primitive library In-Reply-To: References: Message-ID: I think the areas in the primitive library demonstrate a part of the array design space that seems to have gone relatively unexplored in Haskell: plain old vectors. Unlike the vector library, there is no stream fusion framework. Unlike the array library, there is no class-based reliance on fold/build fusion. The (flawed) addition of numerous class instances a couple versions ago made primitive arrays seem much more viable to end users as an alternative to their heavier counterparts. I have become interested in fixing the mistakes that were made, seeing just how much performance we can squeeze out (and what limitations we run into), and fleshing out the API. On Mon, Apr 23, 2018, 9:20 AM Andrew Martin wrote: > I'll get something together soon that explains my motivations. The short > summary is that the types in primitive unpack better that their > counterparts in vector (meaning, they unpack into one machine word instead > of three). I started using these types in internal data structures in > libraries I would write (since I didn't need slicing), and then just > started noticing stuff I thought it would be nice to add. > > David noticed that a bunch of the typeclass instances were broken. I'd > been working on a library quickcheck-classes that I use to test instances > at my work place. The primitive library was missing a test suite, so I used > it to test all the instances to ensure that the fixes David had written > were correct. In the process, I found more broken instances and fixed them. > The life lesson here is that property testing is important. > > PrimArray is an interesting story. Both winterland1989 and I had > independently written libraries that did the same exact thing: implement a > typed interface to ByteArray that keeps track of the element type. This > makes PrimArray much safer to work with than ByteArray. Eventually, > winterland's initial PR to bring this to primitive stalled. It implemented > several other features (some of which may still eventually get added), but > it's scope was large enough that no maintainer was able to feel comfortable > approving it. More recently, I took at stab at doing the same thing, but I > only added PrimArray, and after a lot of feedback from David, Carter, and > Ryan, it got merged in. > > This got longer than I thought it would. I'll work on something that talks > more about motivations and features soon. > > On Mon, Apr 23, 2018 at 5:48 AM, Simon Peyton Jones > wrote: > >> Andrew, David >> >> I’ve seen a lot of traffic about the *primitive* library, in which you >> two are playing a leading role. >> >> Clearly something interesting is going on, but I have not been paying >> enough attention to work out what. Maybe lots of unrelated things? Maybe >> a handful of closely related things? >> >> Would you consider putting out a summary (to libraries and ghc-devs) to >> give an overview of the main threads, and any driving motivations. Why has >> all this blown up now? >> >> Meanwhile, thank you for being so active. >> >> Simon >> > > > > -- > -Andrew Thaddeus Martin > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Apr 23 15:25:26 2018 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 23 Apr 2018 17:25:26 +0200 Subject: Type family constraints In-Reply-To: <5E400C3C-5672-47F5-B187-F30827120F1A@cs.brynmawr.edu> References: <5E400C3C-5672-47F5-B187-F30827120F1A@cs.brynmawr.edu> Message-ID: Thanks Richard Ryan Scott has also put together a solution[1], which is basically what you proposed. But in terms of trying to clean up the code by removing a straightforward constraint type, I think this solution adds more complexity than it removes. So I will leave it as it is. Alan [1] http://lpaste.net/365181 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Apr 23 16:55:50 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 23 Apr 2018 17:55:50 +0100 Subject: Eight GHC projects for Google Summer of Code Message-ID: Hi all, I am glad to report that eight GHC related projects have been selected for this years GSoC. Chitrak Gupta - Help Hadrian - https://summerofcode.withgoogle.com/projects/#4778106259243008 Alanas Plascinskas - Depecating Exports - https://summerofcode.withgoogle.com/projects/#4906802404130816 Simon Jakobi - HI Haddock - https://summerofcode.withgoogle.com/projects/#4975710121230336 Abhiroop Sarkar - SIMD Improvements - https://summerofcode.withgoogle.com/projects/#5641742712307712 Ningning Xie - Dependently Typed Core Replacement in GHC - https://summerofcode.withgoogle.com/projects/#5851493949767680 Andreas Klebinger - Codegen of Conditional Constructs - https://summerofcode.withgoogle.com/projects/#5953351515111424 Shayan Najd - Native-Metaprogramming Reloaded - https://summerofcode.withgoogle.com/projects/#6085694691213312 Zubin Duggal - Making GHC Tooling friendly - https://summerofcode.withgoogle.com/projects/#6509299262554112 I am sure that some names will already be familiar but please look out for questions and patches from these eight students over the next few months. Looking forward to seeing everyone on the mailing list and in #ghc! Cheers, Matt From alan.zimm at gmail.com Mon Apr 23 17:43:06 2018 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 23 Apr 2018 19:43:06 +0200 Subject: Eight GHC projects for Google Summer of Code In-Reply-To: References: Message-ID: Congratulations to all. I look forward to seeing these move forward. Alan On 23 April 2018 at 18:55, Matthew Pickering wrote: > Hi all, > > I am glad to report that eight GHC related projects have been selected > for this years GSoC. > > Chitrak Gupta - Help Hadrian - > https://summerofcode.withgoogle.com/projects/#4778106259243008 > Alanas Plascinskas - Depecating Exports - > https://summerofcode.withgoogle.com/projects/#4906802404130816 > Simon Jakobi - HI Haddock - > https://summerofcode.withgoogle.com/projects/#4975710121230336 > Abhiroop Sarkar - SIMD Improvements - > https://summerofcode.withgoogle.com/projects/#5641742712307712 > Ningning Xie - Dependently Typed Core Replacement in GHC - > https://summerofcode.withgoogle.com/projects/#5851493949767680 > Andreas Klebinger - Codegen of Conditional Constructs - > https://summerofcode.withgoogle.com/projects/#5953351515111424 > Shayan Najd - Native-Metaprogramming Reloaded - > https://summerofcode.withgoogle.com/projects/#6085694691213312 > Zubin Duggal - Making GHC Tooling friendly - > https://summerofcode.withgoogle.com/projects/#6509299262554112 > > I am sure that some names will already be familiar but please look out > for questions and patches from these eight students over the next few > months. > > Looking forward to seeing everyone on the mailing list and in #ghc! > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 23 20:04:13 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Apr 2018 20:04:13 +0000 Subject: primitive library In-Reply-To: References: Message-ID: This got longer than I thought it would. I'll work on something that talks more about motivations and features soon. That would be great, thanks. It would also mean that more people would use the new stuff, sooner. Simon From: Andrew Martin Sent: 23 April 2018 14:20 To: Simon Peyton Jones Cc: David Feuer ; ghc-devs ; Haskell Libraries Subject: Re: primitive library I'll get something together soon that explains my motivations. The short summary is that the types in primitive unpack better that their counterparts in vector (meaning, they unpack into one machine word instead of three). I started using these types in internal data structures in libraries I would write (since I didn't need slicing), and then just started noticing stuff I thought it would be nice to add. David noticed that a bunch of the typeclass instances were broken. I'd been working on a library quickcheck-classes that I use to test instances at my work place. The primitive library was missing a test suite, so I used it to test all the instances to ensure that the fixes David had written were correct. In the process, I found more broken instances and fixed them. The life lesson here is that property testing is important. PrimArray is an interesting story. Both winterland1989 and I had independently written libraries that did the same exact thing: implement a typed interface to ByteArray that keeps track of the element type. This makes PrimArray much safer to work with than ByteArray. Eventually, winterland's initial PR to bring this to primitive stalled. It implemented several other features (some of which may still eventually get added), but it's scope was large enough that no maintainer was able to feel comfortable approving it. More recently, I took at stab at doing the same thing, but I only added PrimArray, and after a lot of feedback from David, Carter, and Ryan, it got merged in. This got longer than I thought it would. I'll work on something that talks more about motivations and features soon. On Mon, Apr 23, 2018 at 5:48 AM, Simon Peyton Jones > wrote: Andrew, David I’ve seen a lot of traffic about the primitive library, in which you two are playing a leading role. Clearly something interesting is going on, but I have not been paying enough attention to work out what. Maybe lots of unrelated things? Maybe a handful of closely related things? Would you consider putting out a summary (to libraries and ghc-devs) to give an overview of the main threads, and any driving motivations. Why has all this blown up now? Meanwhile, thank you for being so active. Simon -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 23 20:04:15 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Apr 2018 20:04:15 +0000 Subject: Type family constraints In-Reply-To: References: Message-ID: I’m afraid I don’t understand the question. type instance XIPBinds (GhcPass 'Parsed) = NoExt type instance XIPBinds (GhcPass 'Renamed) = NoExt type instance XIPBinds (GhcPass 'Typechecked) = TcEvBinds it works fine for type instance XIPBinds (GhcPass _) = NoExt You mean, the first group does not work, but the latter does?? I’m not even sure what “work” means. I’m perplexed and need more context Simon From: ghc-devs On Behalf Of Alan & Kim Zimmerman Sent: 23 April 2018 11:57 To: ghc-devs Subject: Type family constraints Given data GhcPass (c :: Pass) deriving instance Eq (GhcPass c) deriving instance Typeable c => Data (GhcPass c) data Pass = Parsed | Renamed | Typechecked deriving (Data) Is there any way to express that `pass` must be valid for each value of `Pass` in the following instance head? instance (p ~ GhcPass pass, OutputableBndrId p) => Outputable (HsIPBinds p) where This comes from a problem where setting each type family instance separately does not get picked up during instance resolution (and can't be, according to earlier questions by me on this) i.e. type instance XIPBinds (GhcPass 'Parsed) = NoExt type instance XIPBinds (GhcPass 'Renamed) = NoExt type instance XIPBinds (GhcPass 'Typechecked) = TcEvBinds it works fine for type instance XIPBinds (GhcPass _) = NoExt Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Tue Apr 24 08:28:30 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Tue, 24 Apr 2018 10:28:30 +0200 Subject: In which format should GHC expose documentation via its .hi-files? Message-ID: Hi! In preparation for the coding phase of the Hi Haddock proposal that I want to implement, I need a decision on the format in which we should expose haddocks in GHC's .hi interface files. Please visit https://github.com/haskell/haddock/issues/805, ask questions, make suggestions and help me find a timely decision! :) Cheers, Simon From simonpj at microsoft.com Wed Apr 25 15:01:10 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Apr 2018 15:01:10 +0000 Subject: GHC HCAR submission In-Reply-To: <87efj6c06s.fsf@smart-cactus.org> References: <87efj6c06s.fsf@smart-cactus.org> Message-ID: Thanks. I think you'd be far more likely to get input if you address contributors individually in the To: line, and by name in the salutation. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 23 April 2018 00:05 | To: ghc-devs at haskell.org | Subject: GHC HCAR submission | | tl;dr. Add your project to GHC's HCAR submission [1]. | | | Hello everyone, | | I have uploaded a first draft of GHC's May 2018 HCAR submission to the | Wiki [1]. While I believe I have covered most of the on-going | projects, do check that your project appears and feel free to make any | edits you feel appropriate. | | Cheers, | | - Ben | | | [1] https://ghc.haskell.org/trac/ghc/wiki/Status/Apr18 From simonpj at microsoft.com Wed Apr 25 17:34:19 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Apr 2018 17:34:19 +0000 Subject: [core libraries] Re: Name for unary unboxed one-tuple In-Reply-To: References: Message-ID: OK great, thanks. Solo# is it. Adding ghc-devs: would someone like to make a patch? Simon From: Edward Kmett Sent: 25 April 2018 17:13 To: Andrew Martin Cc: Simon Peyton Jones ; core-libraries-committee at haskell.org; Haskell Libraries Subject: Re: [core libraries] Re: Name for unary unboxed one-tuple Argh. Not another color for the bikeshed. We were so close to a nice universal consensus given your +1 on the thread. =) Let's end this and just go with Simon's Solo# as it had already achieved a reasonably wide consensus on the thread and we can put this to bed. Simon: I'd replied a couple of weeks ago on the trac ticket to try to end this, but apparently didn't visibly weigh in in a fashion that obviously carried the full force of the committee. -Edward On Wed, Apr 25, 2018 at 8:40 AM, Andrew Martin > wrote: My vote is for Single/Single#. Also, in case there is any confusion around this, I was not a member of the CLC when this issue was originally raised, but the committee has accepted me since then. On Wed, Apr 25, 2018 at 4:28 AM, Simon Peyton Jones via Libraries > wrote: Dear Libraries Committee Some time ago Andrew Martin asked you what the name of the unary unboxed one-tuple type and data constructor should be. The thread ran for a while, but you never came to a conclusion. Can we nail this one? You’ll see on Trac #14673 that chessai wants me to decide 😊. But it should really be you. To me, there seems to be something of a consensus around Solo#. Simon PS: actually I think Andrew may have addressed libraries@ rather than core-libraries-committee@ by mistake. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- -Andrew Thaddeus Martin -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Apr 25 17:37:50 2018 From: david.feuer at gmail.com (David Feuer) Date: Wed, 25 Apr 2018 17:37:50 +0000 Subject: [core libraries] Re: Name for unary unboxed one-tuple In-Reply-To: References: Message-ID: One question I don't remember seeing resolved. Will we still be able to use the old data constructor syntax and (fully applied) type constructor syntax? These are used a good bit in the wild. On Wed, Apr 25, 2018, 1:34 PM Simon Peyton Jones via Libraries < libraries at haskell.org> wrote: > OK great, thanks. Solo# is it. Adding ghc-devs: would someone like to > make a patch? > > > > Simon > > > > *From:* Edward Kmett > *Sent:* 25 April 2018 17:13 > *To:* Andrew Martin > *Cc:* Simon Peyton Jones ; > core-libraries-committee at haskell.org; Haskell Libraries < > libraries at haskell.org> > *Subject:* Re: [core libraries] Re: Name for unary unboxed one-tuple > > > > Argh. Not another color for the bikeshed. We were so close to a nice > universal consensus given your +1 on the thread. =) > > > > Let's end this and just go with Simon's Solo# as it had already achieved > a reasonably wide consensus on the thread and we can put this to bed. > > > > Simon: I'd replied a couple of weeks ago on the trac ticket to try to end > this, but apparently didn't visibly weigh in in a fashion that obviously > carried the full force of the committee. > > > > -Edward > > > > On Wed, Apr 25, 2018 at 8:40 AM, Andrew Martin > wrote: > > My vote is for Single/Single#. > > > > Also, in case there is any confusion around this, I was not a member of > the CLC when this issue was originally raised, but the committee has > accepted me since then. > > > > > > > > On Wed, Apr 25, 2018 at 4:28 AM, Simon Peyton Jones via Libraries < > libraries at haskell.org> wrote: > > Dear Libraries Committee > > Some time ago Andrew Martin asked you > > what the name of the unary unboxed one-tuple type and data constructor > should be. The thread ran for a while, but you never came to a conclusion. > > Can we nail this one? You’ll see on Trac #14673 > that chessai > wants me to decide 😊. But it should really be you. > > To me, there seems to be something of a consensus around Solo#. > > Simon > > PS: actually I think Andrew may have addressed libraries@ rather than > core-libraries-committee@ by mistake. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > > -- > > -Andrew Thaddeus Martin > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout > > . > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Apr 25 17:40:51 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Apr 2018 17:40:51 +0000 Subject: [core libraries] Re: Name for unary unboxed one-tuple In-Reply-To: References: Message-ID: You mean can you say (# Int #) and (# x #). Yes, of course. They would presumably be synonymous with (Solo# Int) and (Solo# x). Just as (# Int, Bool #) is synonymous with (#,#) Int Bool etc. Simon From: David Feuer Sent: 25 April 2018 18:38 To: Simon Peyton Jones Cc: Edward Kmett ; Andrew Martin ; core-libraries-committee at haskell.org; Haskell Libraries ; ghc-devs at haskell.org Subject: Re: [core libraries] Re: Name for unary unboxed one-tuple One question I don't remember seeing resolved. Will we still be able to use the old data constructor syntax and (fully applied) type constructor syntax? These are used a good bit in the wild. On Wed, Apr 25, 2018, 1:34 PM Simon Peyton Jones via Libraries > wrote: OK great, thanks. Solo# is it. Adding ghc-devs: would someone like to make a patch? Simon From: Edward Kmett > Sent: 25 April 2018 17:13 To: Andrew Martin > Cc: Simon Peyton Jones >; core-libraries-committee at haskell.org; Haskell Libraries > Subject: Re: [core libraries] Re: Name for unary unboxed one-tuple Argh. Not another color for the bikeshed. We were so close to a nice universal consensus given your +1 on the thread. =) Let's end this and just go with Simon's Solo# as it had already achieved a reasonably wide consensus on the thread and we can put this to bed. Simon: I'd replied a couple of weeks ago on the trac ticket to try to end this, but apparently didn't visibly weigh in in a fashion that obviously carried the full force of the committee. -Edward On Wed, Apr 25, 2018 at 8:40 AM, Andrew Martin > wrote: My vote is for Single/Single#. Also, in case there is any confusion around this, I was not a member of the CLC when this issue was originally raised, but the committee has accepted me since then. On Wed, Apr 25, 2018 at 4:28 AM, Simon Peyton Jones via Libraries > wrote: Dear Libraries Committee Some time ago Andrew Martin asked you what the name of the unary unboxed one-tuple type and data constructor should be. The thread ran for a while, but you never came to a conclusion. Can we nail this one? You’ll see on Trac #14673 that chessai wants me to decide 😊. But it should really be you. To me, there seems to be something of a consensus around Solo#. Simon PS: actually I think Andrew may have addressed libraries@ rather than core-libraries-committee@ by mistake. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- -Andrew Thaddeus Martin -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Apr 25 17:42:30 2018 From: david.feuer at gmail.com (David Feuer) Date: Wed, 25 Apr 2018 17:42:30 +0000 Subject: [core libraries] Re: Name for unary unboxed one-tuple In-Reply-To: References: Message-ID: Great. On Wed, Apr 25, 2018, 1:40 PM Simon Peyton Jones wrote: > You mean can you say (# Int #) and (# x #). Yes, of course. They would > presumably be synonymous with (Solo# Int) and (Solo# x). Just as (# Int, > Bool #) is synonymous with (#,#) Int Bool etc. > > > > Simon > > > > *From:* David Feuer > *Sent:* 25 April 2018 18:38 > *To:* Simon Peyton Jones > *Cc:* Edward Kmett ; Andrew Martin < > andrew.thaddeus at gmail.com>; core-libraries-committee at haskell.org; Haskell > Libraries ; ghc-devs at haskell.org > *Subject:* Re: [core libraries] Re: Name for unary unboxed one-tuple > > > > One question I don't remember seeing resolved. Will we still be able to > use the old data constructor syntax and (fully applied) type constructor > syntax? These are used a good bit in the wild. > > > > On Wed, Apr 25, 2018, 1:34 PM Simon Peyton Jones via Libraries < > libraries at haskell.org> wrote: > > OK great, thanks. Solo# is it. Adding ghc-devs: would someone like to > make a patch? > > > > Simon > > > > *From:* Edward Kmett > *Sent:* 25 April 2018 17:13 > *To:* Andrew Martin > *Cc:* Simon Peyton Jones ; > core-libraries-committee at haskell.org; Haskell Libraries < > libraries at haskell.org> > *Subject:* Re: [core libraries] Re: Name for unary unboxed one-tuple > > > > Argh. Not another color for the bikeshed. We were so close to a nice > universal consensus given your +1 on the thread. =) > > > > Let's end this and just go with Simon's Solo# as it had already achieved > a reasonably wide consensus on the thread and we can put this to bed. > > > > Simon: I'd replied a couple of weeks ago on the trac ticket to try to end > this, but apparently didn't visibly weigh in in a fashion that obviously > carried the full force of the committee. > > > > -Edward > > > > On Wed, Apr 25, 2018 at 8:40 AM, Andrew Martin > wrote: > > My vote is for Single/Single#. > > > > Also, in case there is any confusion around this, I was not a member of > the CLC when this issue was originally raised, but the committee has > accepted me since then. > > > > > > > > On Wed, Apr 25, 2018 at 4:28 AM, Simon Peyton Jones via Libraries < > libraries at haskell.org> wrote: > > Dear Libraries Committee > > Some time ago Andrew Martin asked you > > what the name of the unary unboxed one-tuple type and data constructor > should be. The thread ran for a while, but you never came to a conclusion. > > Can we nail this one? You’ll see on Trac #14673 > that chessai > wants me to decide 😊. But it should really be you. > > To me, there seems to be something of a consensus around Solo#. > > Simon > > PS: actually I think Andrew may have addressed libraries@ rather than > core-libraries-committee@ by mistake. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > > -- > > -Andrew Thaddeus Martin > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout > > . > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Wed Apr 25 22:11:25 2018 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Wed, 25 Apr 2018 22:11:25 +0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <061.e8883d84d121dee78a851095b34d1a80@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> <061.e8883d84d121dee78a851095b34d1a80@haskell.org> Message-ID: I'm happy this is seeing some attention! I've habitually over promised on this and feel bad about that. My work-life-hobby programming balance has remained a mystery to me. Even so, I'll give what answers I can to any questions that come up. I remember ultimately getting stuck on trying to identify a broadly useful heuristic: there are lots of possible parameters to tune and I was seeing massive run time differences for nofib cases on different CPU architectures for equivalent LLF parameters. I never managed to get a good handle on the crucial independent variables (e.g. code cache sizes, RTS parameters, etc). I'm hoping the join point work revealed some easier wins. Best of luck and don't hesitate to ping me with questions. Hope I can help. On Wed, Apr 25, 2018, 10:33 GHC wrote: > #9476: Implement late lambda-lifting > -------------------------------------+------------------------------------- > Reporter: simonpj | Owner: nfrisby > Type: feature request | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.8.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Runtime | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: #8763 | Differential Rev(s): > Wiki Page: LateLamLift | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > OK, great. Do keep us posted. I think there are real wins to be had > here. Nicholas's detailed wiki page identifies many of the issues very > clearly. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alicekoroleva239 at gmail.com Mon Apr 30 12:27:57 2018 From: alicekoroleva239 at gmail.com (alice) Date: Mon, 30 Apr 2018 15:27:57 +0300 Subject: Poly-kinded type family Message-ID: <6167FAEE-DCE0-4447-A93A-BC705DFDA4B9@gmail.com> Hello. I’m trying to make a type family with resolving it inside type checking classes, like CmpNat. Its type signature is «type family Cmp (a :: k1) (b :: k2) :: Ordering», so the function is poly kinded. But it seems unclear how to make its TyCon. I’ve tried to follow the CmpNat and CmpSymbol style, and also saw Any TyCon in TysWiredIn. So this is my attempt: typeCmpTyCon :: TyCon typeCmpTyCon = mkFamilyTyCon name (binders ++ (mkTemplateAnonTyConBinders [ input_kind1, input_kind2 ])) orderingKind Nothing (BuiltInSynFamTyCon ops) Nothing NotInjective where name = mkWiredInTyConName UserSyntax gHC_TYPELITS (fsLit "Cmp") typeCmpTyFamNameKey typeCmpTyCon ops = BuiltInSynFamily { sfMatchFam = matchFamCmpType , sfInteractTop = interactTopCmpType , sfInteractInert = \_ _ _ _ -> [] } binders@[kv1, kv2] = mkTemplateKindTyConBinders [ liftedTypeKind, liftedTypeKind ] input_kind1 = mkTyVarTy (binderVar kv1) input_kind2 = mkTyVarTy (binderVar kv2) ghci says this: :kind Cmp Cmp :: forall {k0} {k1}. k0 -> k1 -> Ordering But then I try to apply it to some values and get this exception: :kind! Cmp 4 5 :1:15: error: • Expected kind ‘k0’, but ‘4’ has kind ‘Nat’ • In the first argument of ‘Cmp’, namely ‘4’ In the type ‘Cmp 4 5’ :1:17: error: • Expected kind ‘k1’, but ‘5’ has kind ‘Nat’ • In the second argument of ‘Cmp’, namely ‘5’ In the type ‘Cmp 4 5’ Does anyone know where I made a mistake? Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Apr 30 14:38:38 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 30 Apr 2018 10:38:38 -0400 Subject: Poly-kinded type family In-Reply-To: <6167FAEE-DCE0-4447-A93A-BC705DFDA4B9@gmail.com> References: <6167FAEE-DCE0-4447-A93A-BC705DFDA4B9@gmail.com> Message-ID: <8EBDB324-22A1-43D5-8F3C-53FECF2B40C6@cs.brynmawr.edu> Hi Alice, You'll need mkTemplateTyConBinders, not the two variants of that function you use below. The problem is that both mkTemplateKindTyConBinders and mkTemplateAnonTyConBinders pull Uniques starting from the same value, and so GHC gets very confused when multiple arguments to your TyCon have the same Uniques. mkTemplateTyConBinders, on the other hand, allows you to specify dependency among your arguments without confusing Uniques. You can see a usage of this function in TysPrim.proxyPrimTyCon. I hope this helps! Richard PS: I've made this mistake myself several times, and it's quite baffling to debug! > On Apr 30, 2018, at 8:27 AM, alice wrote: > > Hello. I’m trying to make a type family with resolving it inside type checking classes, like CmpNat. Its type signature is «type family Cmp (a :: k1) (b :: k2) :: Ordering», so the function is poly kinded. But it seems unclear how to make its TyCon. I’ve tried to follow the CmpNat and CmpSymbol style, and also saw Any TyCon in TysWiredIn. So this is my attempt: > > typeCmpTyCon :: TyCon > typeCmpTyCon = > mkFamilyTyCon name > (binders ++ (mkTemplateAnonTyConBinders [ input_kind1, input_kind2 ])) > orderingKind > Nothing > (BuiltInSynFamTyCon ops) > Nothing > NotInjective > where > name = mkWiredInTyConName UserSyntax gHC_TYPELITS (fsLit "Cmp") > typeCmpTyFamNameKey typeCmpTyCon > ops = BuiltInSynFamily > { sfMatchFam = matchFamCmpType > , sfInteractTop = interactTopCmpType > , sfInteractInert = \_ _ _ _ -> [] > } > binders@[kv1, kv2] = mkTemplateKindTyConBinders [ liftedTypeKind, liftedTypeKind ] > input_kind1 = mkTyVarTy (binderVar kv1) > input_kind2 = mkTyVarTy (binderVar kv2) > > ghci says this: > > :kind Cmp > Cmp :: forall {k0} {k1}. k0 -> k1 -> Ordering > > But then I try to apply it to some values and get this exception: > > :kind! Cmp 4 5 > > :1:15: error: > • Expected kind ‘k0’, but ‘4’ has kind ‘Nat’ > • In the first argument of ‘Cmp’, namely ‘4’ > In the type ‘Cmp 4 5’ > > :1:17: error: > • Expected kind ‘k1’, but ‘5’ has kind ‘Nat’ > • In the second argument of ‘Cmp’, namely ‘5’ > In the type ‘Cmp 4 5’ > > Does anyone know where I made a mistake? Any help would be appreciated. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Mon Apr 30 16:12:27 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 30 Apr 2018 16:12:27 +0000 Subject: Discussion on proposal #99: forall {k} Message-ID: Hello, As a shepherd for proposal #99, I'd like to kick off the discussion. The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures. The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred. The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds. As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax. While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons: 1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified. While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y). 2. It still requires that programmers instantiate arguments in a fixed order, which is sometimes dictated by the structure of the type itslef. Here is, for example, what the proposal suggests to do if you want to provide type before a kind: typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a While technically this is not wrong, it is not exactly elegant. I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem. One alternative design is to allow programmers to instantiate type variables by name. This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order. We've been doing this in Cryptol for a long time, and it seems to work really well. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: