Could Marge change the target branch of an MR before merging it? Perhaps
this would convince GitLab to show the right info.
On Fri, Jul 5, 2019, 6:18 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
> | You believe the one which marge posts telling you that the patch is
> |
Sorry meant to reply all:
I ran into the error recently here:
https://github.com/monadfix/named/issues/24
trying to use a fun named arguments library. I can't immediately tell if
these changes to GHC are sufficient to help. This library is using a
newtype with phantom arguments.
On Fri, Jun 28,
This may be relevant: https://support.google.com/faqs/answer/7625886
Note that both GCC and LLVM will be learning this Ratpoline technique.
On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald wrote:
> With the caveat of that I maybe have no clue what I’m talking about
The only loss is the ability to look at changes over time. If that's an
important feature, you could write the files with a commit hash in the
name. But that may not be worth it.
On Tue, Mar 14, 2017 at 4:38 AM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
> It's very helpful
I'd imagine that "opt-in" could even mean you have to install a separate
program/package to send data that's been collected. If it were very
separate from the compiler itself, would these security concerns still be a
problem? I for one would go through the effort of opting in since I want
the
The Python community is heavily pushing to get Python 2 out of normal use,
so the only reason I can imagine of trying to maintain Python 2
compatibility is if people have written scripts atop GHC's test suites. I
sort of doubt that's common.
ᐧ
On Wed, Nov 30, 2016 at 2:46 PM, Ben Gamari
I second Herbert's concern. Giving semantics to import order is one of the
greatest plagues of C, C++, Python, etc. It is worth avoiding at all costs.
Herbert's suggestion re: explicitly enumerated names seems to hold promise,
however.
On Tue, Oct 4, 2016 at 7:50 AM, Herbert Valerio Riedel
With the "stock option" might I also suggest "OEM"? ;)
+1 stock
On Tue, Sep 27, 2016 at 10:06 PM, Richard Eisenberg
wrote:
> +1 on `stock` from me. Though I was all excited to get my class next
> semester jazzed for PL work by explaining that I had slipped a new keyword
>
arding" process are truly
herculean and a massive investment to the community. Thank you! Matthew,
and other core devs, your hard work and world-class insight make Haskell
the technology that it is today and I cannot thank you enough.
Elliot Cameron
On Sun, Sep 25, 2016 at 4:35 AM, Matthew Picker
nce you don't like "bespoke", would you mind suggesting an
> > alternative, or advocating for a previously mentioned idea? From [1],
> > the ideas I've seen tossed around are:
> >
> > * builtin
> > * standard (Elliot Cameron suggested it here [2])
> > * wiredi
Just a quick thought: The term "built-in" seems a bit myopic IMO since all
these extensions are in a sense built-in, and especially if any of them
make it into Haskell 2020. I wonder if "standard" would be better or
something similar.
On Jul 17, 2016 08:57, "Ryan Scott"
I'm going by my rather poor memory for this. Frankly, I don't really care where
the option sits, as long as I don't need a separate build of GHC to avoid LGPL.
From: Ben Gamari b...@well-typed.com
Sent: Friday, August 28, 2015 5:48 AM
To: Elliot Cameron
I can't seem to find the exact trac ticket, but the ability to swap out
Integer implementations at link time would be a huge relief on Windows, which
suffers from various problems with dynamic linking. I believe it was originally
slated for 7.12. Can someone find it? Here's what I did find:
this special treatment to get away from integer-gmp.
Elliot Cameron
-Original Message-
From: Edward Z. Yang [mailto:ezy...@mit.edu]
Sent: Wednesday, July 1, 2015 12:52 AM
To: Elliot Cameron
Cc: ghc-devs@haskell.org
Subject: Re: Help Building GHC on Windows to avoid LGPL
Excerpts from Elliot
14 matches
Mail list logo