Re: linker_unload

Have you tried using ld.gold instead? I've run into many issues with the default ld.bfd recently (none of which seems related to this issue, but it tells me that weird linker bugs do happen and testing with another linker may help isolate the root cause). -- Mathieu Boespflug Founder at

Re: Proposal for removing transformers dependency

On 22 January 2015 at 09:34, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Donnerstag, den 22.01.2015, 08:37 +0100 schrieb Herbert Valerio Riedel: One thing to keep in mind though is that then 'haskeline' (which is needed by GHCi) still remains a consumer of 'transformers', so we'd

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

I'm unclear why cpphs needs to be made a dependency of the GHC API and included as a lib. Could you elaborate? (in the wiki page possibly) Currently, GHC uses the system preprocessor, as a separate process. Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by default GHC would

Re: QRE: Cabal and simultaneous installations of the same package

As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary. Currently, if you install B-0.1 and then install A-2.0 that has a

Re: RFC: Native -XCPP Proposal

On 19 May 2015 at 08:26, Bardur Arantsson s...@scientician.net wrote: On 05/19/2015 07:31 AM, Carter Schonwald wrote: I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3! That is of no consequence licensing-wise since

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

Hi Lars, I'm really not sure that the community has the resources to spare to reimplement non-trivial pieces of *standalone (non-library)* software to address perceived but ethereal business problems that are based on lack of understanding about how IP law works as both you and Carter point out.

Re: Abstract FilePath Proposal

Hi Neil, why does the proposal *not* include normalization? There are four advantages that I see to making FilePath a datatype: 1. it makes it possible to implement the correct semantics for some systems (including POSIX), 2. it allows for information hiding, which in turn helps modularity, 3.

Re: Abstract FilePath Proposal

On 28 June 2015 at 16:34, Sven Panne svenpa...@gmail.com wrote: 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu m...@tweag.io: why does the proposal *not* include normalization? [...] I think this is intentional, because otherwise we are in the IO monad for basically all operations. What's

Re: Abstract FilePath Proposal

, Mathieu m...@tweag.io wrote: On 28 June 2015 at 16:34, Sven Panne svenpa...@gmail.com wrote: 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu m...@tweag.io: why does the proposal *not* include normalization? [...] I think this is intentional, because otherwise we are in the IO monad

Re: New type of ($) operator in GHC 8.0 is problematic

Hi Ben, thanks for the nice summary. I haven't been following all the details in the meanderings of this thread, but perhaps someone can chime in with an answer to this simple question: * has it been discussed what type ($) should have in the Haddock's for base? If so, will it the one GHCi shows

Re: Reconsidering -Wall and -Wcompat

>> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat >> never causes a build to fail even when users set -Wall -Werror. > > Tbh, I don't like the "magic" part at all. In fact, I currently rely on > `-Wcompat -Werror` triggering an error in my builds. Point is - if -Wall implies

Re: New type of ($) operator in GHC 8.0 is problematic

> As far as I know, there is currently know way to > do this in 7.10. > > Given how much backlash there has been to changing the type of ($), ... Keep in mind... as we saw with FTP, that in this community it's often unclear just how large or tiny a group of people represent when they're vocal

Re: Reification of out-of-scope variables?

Hi Richard, Facundo and I had a chat about this offline. Facundo noticed that there /is/ a form of splicing that runs during type checking, and therefore has access to the type environment: namely typed splices, which return a TExp rather than an Exp. Turns out the example from my first email

Reification of out-of-scope variables?

Hi all, the community is increasingly using quasiquotation as a means to interoperate with foreign languages. E.g. language-c-inline, inline-c and inline-r allow calling foreign functions using foreign language syntax, rather than "foreign import" declarations. There are efforts underway for

Re: Reification of out-of-scope variables?

Hi all, For our use case, namely automatic bindings generation via quasiquotation à la language-c-inline, typed quasiquotation alone wouldn't solve much. Because in order to be sensible it would likely have to be restricted (one way or another) to only allowing reification of variables in the

Re: How to force -fPIC on package builds?

to 32 bit builds, but I am attempting a 64 bit build. > > The problem may be related to the way modules are randomly relocated > > for security reasons, Fedora security policies, and confusion/bugs in > > the linker(s). > > > > Cheers, > > Dominick > > > >

Re: How to force -fPIC on package builds?

any binary that links to inline-r). > > BTW, how can I compare my results with yours if all I know is that you > have used "a docker container"? Wouldn't I need to know what > repository and snapshot you are using? > > On Sun, Aug 14, 2016 at 2:55 PM, Boespflug, Mathieu &

Re: How to force -fPIC on package builds?

Hi Dominick, which version of Fedora Linux are you on? The -fPIC message from the linker may well be a red herring. AFAIR generating PIC is the default in GHC, at least for dynamic libraries. Best, -- Mathieu Boespflug Founder at http://tweag.io. On 13 August 2016 at 05:55, Dominick Samperi

Re: Linker.c broken

True. Worth a try asking them what limits they're willing to lift for a high profile open source project like GHC, I think. -- Mathieu Boespflug Founder at http://tweag.io. On 4 July 2016 at 13:26, Ben Gamari <b...@well-typed.com> wrote: > "Boespflug, Mathieu" <m...@tweag

Re: Linker.c broken

On 4 July 2016 at 12:36, Ben Gamari wrote: > Simon Marlow writes: > >> I will fix it, sorry about this. Unfortunately I can't really add a >> Windows validate into my workflow because it would mean rebooting my laptop >> into Windows and not doing

Re: Last call for merge requests for 8.0.2

Depends how you look at it I guess. It's arguably a fix to addModFinalizer, which never really worked for the use case it was intended since it was first introduced. This function was added by the author of language-c-inline, who wanted things like cos :: Double -> Double cos x = [c| cos($x) |]

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

Hi Richard! thanks for creating the pull request with a full proposal. You beat me to it - tried writing up much the same before stopping for dinner, essentially capturing just one of the points in Moritz's earlier (large) proposal. Moritz, I would encourage you like Richard did earlier to split

Re: Improving GHC GC for latency-sensitive networked services

Hi Chris, the GC pauses when using GHC have seldom been a serious issue in most of our projects at Tweag I/O. We do also have some projects with special requirements, however (strong synchrony between many machines that block frequently). For those the GC pauses are indeed a problem. And like

Re: GHC 8.0.2 status

Hi Ben, still a few tickets, most of them with patches, slated for the 8.0.2 milestone: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.2. Is the plan still to merge those in? https://ghc.haskell.org/trac/ghc/ticket/12777 is particularly important for inline-java. Many thanks, -- Mathieu

Re: IRC: Logging #ghc with ircbrowse.net

> > Note that currently there are no logs for any time prior to the last few > days. However, I have ZNC logs which Chris said he may be able to import > which cover the last several years of #ghc activity. If there is no > objection I would like to have him import these so we have a more >

Re: GHC 8.0.2 status

Ok many thanks for the heads up Ben. I'll let Facundo coordinate from here, regarding #12777. -- Mathieu Boespflug Founder at http://tweag.io. On 14 November 2016 at 23:28, Ben Gamari <b...@well-typed.com> wrote: > "Boespflug, Mathieu" <m...@tweag.io> writes: > >

Re: Please don’t break travis

Or this route: https://mail.haskell.org/pipermail/ghc-devs/2015-June/009234.html. -- Mathieu Boespflug Founder at http://tweag.io. On 9 December 2016 at 17:06, Joachim Breitner wrote: > Am Freitag, den 09.12.2016, 10:56 -0500 schrieb Ben Gamari: > > > Joachim Breitner

Re: FW: Lightweight Concurrency Branch

Hi KC, if blackholes only appear during thunk evaluation, could the problem you describe below be worked around by simply imposing that the scheduler never creates black holes? Say by leveraging GHC's new -XStrict language extension? -- Mathieu Boespflug Founder at http://tweag.io. On 4 January

Re: Help needed: Restrictions of proc-notation with RebindableSyntax

And Opaleye (a successor to haskellDB, for safe interaction with SQL databases) also uses arrow notation last I checked. As I recall do-notation is too powerful, whereas proc-notation provides exactly the right expressive power (no illegal SQL queries can be expressed). But that's not to say Tom

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

and works fine, even when FFI code is invoked, but slower than for C programs due to running user-level code to inspect the stack for each sample. Is that right? Best, -- Mathieu Boespflug Founder at http://tweag.io. On 10 April 2017 at 21:28, Ben Gamari <b...@well-typed.com> wrote: > &

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

> > * Compiler performance: do you have any numbers to quantify what 8.0 vs 8.2 > > is likely to look like? > > I'm afraid the best I can provide at the moment is [1]. On closer > inspection of these I'm a bit suspicious of the 8.0 numbers; I'll try to > reproduce them (and characterize the

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

/ideas.html? As HSoC sponsors, we'd be more than happy to see someone pick this up. Best, -- Mathieu Boespflug Founder at http://tweag.io. On 10 April 2017 at 22:52, Ben Gamari <b...@well-typed.com> wrote: > "Boespflug, Mathieu" <m...@tweag.io> writes: >

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

Hi Ben, this is great news! I'm particularly keen on learning more about two points you mentioned in your email: * Compiler performance: do you have any numbers to quantify what 8.0 vs 8.2 is likely to look like? How much has the work that's been done affect performance across the board? Or are

Re: Which stable GHC release is expected to have support for linear types?

Hi Wolfgang, 8.4 is the next release after the (by now imminent) 8.2 release. But no support for linear types has of yet been merged into the master branch that will eventually form the basis of the 8.4 release. This support is under active development at the moment on a side branch. Some of us

Re: Which stable GHC release is expected to have support for linear types?

just cloning the Git repository at https://github.com/tweag/ghc.git > and want to build GHC from it. Is this still the right repository? Does > it contain the same as the Docker image? > > All the best, > Wolfgang > > Am Freitag, den 30.06.2017, 16:02 +0200 schrieb Boespflug, Math

Re: Where to discuss the linear types extension of GHC?

Hi Wolfgang, great to see interest in linear types! I would advise caution about building anything on top of the linear types extension at this time. If you have interesting use cases, however, do tell, so that these use cases can influence the design. This is pre-alpha software, meaning that

Re: Disabling Travis?

It took me no more than a couple hours to get this working, but using CircleCI, for our fork of GHC. I started from Joachim's TravisCI script. https://circleci.com/gh/tweag/ghc/tree/circleci It would be trivial to activate this for github.com/ghc/ghc as well. A few notes: - It runs ./validate

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1

Hi Ben, https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like sparkle and others, since they crucially rely on PIE, in this case to dynamically load executables in the JVM. It looks like you committed a fix for this in HEAD. Any chance you could backport this to the GHC 8.2 branch?

Re: CircleCI (Was: Disable Travis?)

And the solution to get email notifications is quite simple in fact: just add Richard to the ghc GitHub org! Or just as simple: Richard (and indeed anyone else on the Internet) can fork the ghc/ghc repo on GitHub and just needs to click one button at https://circleci.com/projects/gh/goldfirere

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1

? Should say at least 8.2.2. -- Mathieu Boespflug Founder at http://tweag.io. On 2 October 2017 at 22:45, Boespflug, Mathieu <m...@tweag.io> wrote: > Hi Ben, > > https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like > sparkle and others, since they crucially rely on

Re: [ANNOUNCE] GHC 8.2.2 release candidate 1

Thanks! As you say - not a regression over 8.0.2, but is a regression over 8.0.1 (albeit a very conscious one). -- Mathieu Boespflug Founder at http://tweag.io. On 3 October 2017 at 00:01, Ben Gamari <b...@smart-cactus.org> wrote: > "Boespflug, Mathieu" <m...@tweag.i

Re: CircleCI (Was: Disable Travis?)

On 25 September 2017 at 21:30, Joachim Breitner <m...@joachim-breitner.de> wrote: > Hi, > > Am Montag, den 25.09.2017, 13:36 +0200 schrieb Boespflug, Mathieu: >> Can you configure circleci to mail both the committeer and a specific >> person (e.g. you, or me) on every fa

Re: GHC Threads affinity

Note that the (AFAIK unreleased) version of ghc-events on the master branch of the upstream repo can parse event streams incrementally, if that's what you meant. -- Mathieu Boespflug Founder at http://tweag.io. On 1 October 2017 at 03:49, Michael Baikov wrote: > Hi Niklas >

Re: GHC Threads affinity

ing slower (significantly so) rather than faster (my suspicion: something somewhere that should be constant time is actually linear). -- Mathieu Boespflug Founder at http://tweag.io. On 1 October 2017 at 14:34, Michael Baikov <manpac...@gmail.com> wrote: > On Sun, Oct 1, 2017 at 8:09 PM, Bo

Re: CircleCI (Was: Disable Travis?)

oespflug Founder at http://tweag.io. On 21 September 2017 at 15:55, Joachim Breitner <m...@joachim-breitner.de> wrote: > Hi, > > Am Donnerstag, den 21.09.2017, 14:25 +0200 schrieb Boespflug, Mathieu: >> It took me no more than a couple hours to get this working, but usin

Re: Including libffi as a submodule

Aren't we talking about the C project here? https://sourceware.org/libffi/ -- Mathieu Boespflug Founder at http://tweag.io. On 28 September 2017 at 06:27, David Feuer wrote: > On Tuesday, September 26, 2017 9:38:11 PM EDT Ben Gamari wrote: > >> Numerous attempts have >>

Re: GHC staus

Hi George, >> Currently it is looking like 8.4.1 will be another cleanup release. >> The only item I can think of beyond those listed on the status page is >> the possibility of progress on #8809. > > > I believe there was a post on the Tweag IO blog suggesting linear types work > might make

Re: Hadrian

Hi all, As a user who tried to be an early adopter of Hadrian, I can attest to Andrey's remarks about GHC progress sometimes (frequently?) breaking Hadrian. Ben, Andrey - how about this strawman proposal: we merge Hadrian into GHC *now*, not because ./validate with Hadrian works (it doesn't

Re: Fwd: Release policies

>> On 14 December 2017 at 00:19, Gershom B wrote: >>> >>> Mathieu: >>> >>> I think the points about better tooling for documenting the correct >>> claims in the release process are well taken. Updating the release >>> notes manually leaves way too much room for error. >>> >

Re: Fwd: Release policies

>> * But actually if we look at their respective release notes, GHC 8.2.1 was >> relased in July 2017, even though the Cabal website claims that >> Cabal-2.0.0.2 was released in August 2017 (see >> https://www.haskell.org/cabal/download.html). So it looks like GHC didn't >> just not give enough

Re: [GHC DevOps Group] Release policies

; build-type have to do with this? > > Cheers, > Manuel > >> 15.12.2017, 19:41 Boespflug, Mathieu <m...@tweag.io>: >> >> Thanks for the feedback, Michael. >> >> Manuel, I believe you are also a Cabal-the-library consumer in Haskell For >>

Re: [GHC DevOps Group] Release policies

Hi Herbert, On 18 December 2017 at 12:22, Herbert Valerio Riedel <hvrie...@gmail.com> wrote: > Hi Mathieu, > > On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu <m...@tweag.io> wrote: >> it's worth thinking about asking that >> the versions of all upstre

Re: Fwd: Release policies

Cabal release. Again, GHC should always have the option to stick to the old Cabal version until things get ironed out. On 15 December 2017 at 08:42, Michael Snoyman <mich...@snoyman.com> wrote: > > > On Thu, Dec 14, 2017 at 12:27 PM, Boespflug, Mathieu <m...@tweag.io

Re: [GHC DevOps Group] Fwd: Release policies

On 15 December 2017 at 16:32, Ben Gamari <b...@well-typed.com> wrote: > "Boespflug, Mathieu" <m...@tweag.io> writes: > >> Thanks for the feedback, Michael. >> >> Manuel, I believe you are also a Cabal-the-library consumer in Haskell For >>

Re: [GHC DevOps Group] Fwd: Release policies

On 15 December 2017 at 19:03, Gershom B <gersh...@gmail.com> wrote: > On Fri, Dec 15, 2017 at 12:37 PM, Boespflug, Mathieu <m...@tweag.io> wrote: >> I did mean that one, yes. That was my question earlier - is Cabal >> along with *all* core libraries covered by the CLC's

Re: Fwd: Release policies

Hi Gerhom, On 14 December 2017 at 00:19, Gershom B wrote: > > Mathieu: > > I think the points about better tooling for documenting the correct > claims in the release process are well taken. Updating the release > notes manually leaves way too much room for error. > >

Re: Fwd: Release policies

. This assumes that the 2 months of feature freeze are enough time for downstream tooling. Thoughts from any of those maintainers? On 14 December 2017 at 01:27, Gershom B <gersh...@gmail.com> wrote: > On Wed, Dec 13, 2017 at 7:06 PM, Boespflug, Mathieu <m...@tweag.io> wrote: >> &

Fwd: Release policies

-- Forwarded message -- From: Boespflug, Mathieu <m...@tweag.io> Date: 13 December 2017 at 23:03 Subject: Re: Release policies To: Simon Peyton Jones <simo...@microsoft.com> Cc: ghc-devops-gr...@haskell.org [replying to ghc-devops-group@, which I assume based on

Re: Moving hadrian to submodule

Great! A submodule makes a lot more sense to me, at least short term. I would hope that medium term the development processes of GHC-as-a-whole and Hadrian(-a-part-of-GHC) can converge, so that a submodule is no longer necessary. Submodules do have their downsides and it would be odd for such a

Re: perf.haskell.org functional again

Hi Joachim, > But that’s what I am saying: By measuring dynamic instructions (using > cachegrind), the execution time is no longer relevant. I'm skeptical that this metric is a reliable enough proxy for actual runtime of user programs to make tracking it and only it sufficient. For the reasons

Re: Release policies

[replying to ghc-devops-group@, which I assume based on your email's content is the mailing list you intended.] Hi Simon, feedback from downstream consumers of Cabal metadata (e.g. build tool authors) will be particularly useful for the discussion here. Here are my thoughts as a bystander. It's

Re: Goals for GHC 8.8

Hi Ben, yes - as for the implementation of the linear types extension, we're aiming for the submission of a Diff before the 8.8 branch is cut. (If the Committee has given the green light by then, of course.) Best, -- Mathieu Boespflug Founder at http://tweag.io. On Tue, 21 Aug 2018 at 21:34,

Re: Treatment of unknown pragmas

> > I'm a bit skeptical of this idea. Afterall, adding cases to the > > lexer for every tool that wants a pragma seems quite unsustainable. > > I don't find this argument that convincing. Given the list already > includes CATCH and DERIVE, the bar can't have been _that_ high to > entry. And yet,

Re: Goals for GHC 8.8

, but so far so good. I've been told that we'll be hearing from the Committee before then about acceptance or rejection of the proposal. Best, -- Mathieu Boespflug Founder at http://tweag.io. On Wed, 5 Sep 2018 at 15:46, Boespflug, Mathieu wrote: > Hi Ben, > > yes - as for the imple

Re: [GHC DevOps Group] The future of Phabricator

Hi Ben, On Tue, 30 Oct 2018 at 15:34, Ben Gamari wrote: > > ... > > Some of the issues I list with GitHub are entirely orthogonal to > GitHub's code review tool. > > While Rust has shown that large open-source projects can use GitHub, > they have also demonstrated that it requires a remarkable

Re: [GHC DevOps Group] The future of Phabricator

Hi Ben, On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote: > > ... > > It occurs to me that I never did sit down to write up my thoughts on > reviewable. I tried doing a few reviews with it [1] and indeed it is > quite good; in many ways it is comparable to Differential. [...] > However, it really

Re: [GHC DevOps Group] The future of Phabricator

So IIUC Gitlab features: - Good multi-platform *hosted* CI or at least workable integration with other (existing) CI solutions - Hosted review tool that we don't have to maintain ourselves (though a little bit less good than Phabricator, allegedly) - familiar GitHub-like workflow with no

Re: Type family equation violates injectivity?

Hi Carter, thanks for looking into this. We were initially surprised to see a breaking change in a point release, but no biggy. It's pretty hard to offer strong stability guarantees without automated tooling to catch this kind of thing, and these things happen. We'll patch up HaskellR shortly.

Re: Haddock tree spongled

If the status quo is poor, then why not merge the two? git-subtree won't fix the problem and will arguably be even harder to manage than submodules. Best, On Wed, 6 Mar 2019 at 15:59, Ben Gamari wrote: > Sylvain Henry writes: > > > Why don't we just put Haddock into GHC's repository? It was

Re: I'm concerned about the affine-types extension and its impact on ghc and haskell at large

Hi Bryan, the discussion has continued on the original PR for the GHC proposal. See https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583795811 and following comments. The tl;dr is that the concerns raised about performance are far too premature: for their own curiosity