Re: On CI

On 17 Mar 2021, at 16:16, Andreas Klebinger wrote: > > While I fully agree with this. We should *always* want to know if a small > syntetic benchmark regresses by a lot. > Or in other words we don't want CI to accept such a regression for us ever, > but the developer of a patch should need to

Re: safe to upgrade my Mac?

> On 27 Jan 2021, at 21:56, Richard Eisenberg wrote: > I'm currently running MacOS High Sierra, 10.13.6. Things are fine, but I'd > like to upgrade to get Dark Mode and (hopefully) to speed up Mail. (That is, > upgrading is nice, but not at all necessary.) I just (finally) upgraded to

Re: GHC Logo

> On 16 Aug 2020, at 16:02, Ben Gamari wrote: > > Carter Schonwald writes: > >> I def like the serif / times new Roman version >> > I'm not aware of a serif version and in general I would be hesitant to > introduce one given that: The one you send out renders using a serif font for GHC on

Re: [ANNOUNCE] GHC 8.6.5-rc1 is now available

There doesn't appear to be a bindist for CentOS 7 (nor for 8.6.4, despite 8.6.3 having one). Cheers, Merijn > On 8 Apr 2019, at 20:28, Ben Gamari wrote: > > Signed PGP part > Hello everyone, > > The GHC team is proud to announce the first release candidate of 8.6.5. > The source

Re: Underscore in binary literals

I, too, have wished for the ability to have a separator in large number literals. So a strong +1 from me. Cheers, Merijn > On 26 Sep 2017, at 15:43, Ben Gamari wrote: > > Takenobu Tani writes: > >> Hi Rahul, >> >> Thanks for the explanation.

Re: Removing Hoopl dependency?

Lemme toss in my 2 cents as an outsider who likes to dabble in programming language and compilers: I would *love* to be able just drop in (parts) of GHC's optimisation into my toy compilers. Optimisation is complicated, lots of work, and not really the part I care about when toying with

Re: Proposal: Automatic derivation of Lift

I proposed automated derivation of Lift earlier (this year even?), but it got shot down as "needless and trivial to do using TH", so if people are now in favour consider me a very strong +1. This would make it significantly easier to implement an efficient version of

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

Hi Adam, On 9 Feb 2015, at 17:44, Adam Gundry a...@well-typed.com wrote: In the absence of a coherent story for polymorphism, I think the right thing to do is to be able to specify a particular validator, rather than try to have type inference determine a monomorphic type and otherwise get

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

Hi Adam, On 6 Feb 2015, at 21:31, Adam Gundry a...@well-typed.com wrote: What does all monomorphic cases mean? Is the idea what GHC would typecheck an expression involving a literal integer, determine that the occurrence had type Even, then evaluate the TH splice *after* typechecking?

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

This sounds rather similar to C++'s constexpr functions and I would totally be in favour for that sort of thing, but I figured that reusing Typed TH would be a less cumbersome way to implement this. If people are in favour of a more elaborate approach, I'm all ears, but I fear that might be out

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

as $$(validate 38). But it's still noisy. So: what is the non-noisy scheme you want to propose? You don't quite get to that in the wiki page! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Merijn | Verstraaten | Sent: 05 February 2015

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

haven't thought this through very far, so there may be other advantages/disadvantages/glaring-holes-in-the-idea that I'm missing. Regards, Dominique 2015-02-06 11:07 GMT+01:00 Merijn Verstraaten mer...@inconsistent.nl: And no one of my proofreaders noticed that . I would propose to have

OS X breakage: make -j and 4 unexpected failures

Carter was having difficulty compiling on OS X 10.9 with Xcode 6.0, so I tried building head and ran into some issues. 1) I used to build using make -j, but this fails with cryptic errors now. ./validate (which uses -j) and make seem to work. The specific error (appearing somewhere during

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

Hi Simon, Thanks for the comments. I think most of the confusion stems from people overthinking the scope of what I was proposing. I'll clear up the page a bit as it's currently conflating implementation details with semantics. On 14 Nov 2014, at 2:29, Simon Peyton Jones simo...@microsoft.com

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

On 16 Nov 2014, at 14:09, Simon Peyton Jones simo...@microsoft.com wrote: Thanks. Can you make sure that you update the wiki page to reflect what you say here? Email is transitory; the wiki page gives the *specification* of the feature, and says unambiguously what you intend.

Re: Problem with select(2) in single threaded runtime.

Hi Herbert, On 4 Nov 2014, at 0:34, Herbert Valerio Riedel hvrie...@gmail.com wrote: Was the passed `timeval` structure valid? I.e. is the tv_usec value inside the [0,1e6-1] range? and was tv_sec=0 ? The simple test I wrote is: #include stdio.h #include errno.h #include string.h #include

Re: Problem with select(2) in single threaded runtime.

On 4 Nov 2014, at 9:32, Herbert Valerio Riedel hvrie...@gmail.com wrote: I'm wondering if there's already an Autoconf test somewhere we could steal for detecting this peculiarity of select() on BSD systems... I googled around for ways to detect this, but I haven't found anything so far. I've

Problem with select(2) in single threaded runtime.

While adding a test case for https://phabricator.haskell.org/D407 I noticed that while my initial patch fixed the crash for the threaded runtime, the single threaded runtime was still affected. I dove into the RTS and have hit a snag. In awaitEvent (rts/posix/Select.c) select(2) is called with

Re: Problem with select(2) in single threaded runtime.

timeout for every platform, by reading the source and/or trying all possible timeouts until the max is found and hard coding these max values using CPP. If anyone has a better solution, you're more than welcome to enlighten me! Cheers, Merijn On 3 Nov 2014, at 21:36, Merijn Verstraaten mer

How to treat testsuite timeout as success?

Ola! I was trying to re-re-fix https://ghc.haskell.org/trac/ghc/ticket/8089 and add a test-case for this fix. However, I'm having trouble creating a test that can actually be successful. The simplest case exhibiting the issue (on OSX) is that main = threadDelay maxBound crashes, I need a way

Re: GitHub pull requests

Whoops, accidentally only addressed Ben instead of the list: On 20 Oct 2014, at 12:13 , Ben Gamari bgamari.f...@gmail.com wrote: a) Confusion between Github issue numbers, Trac bug numbers, and Phabricator identifiers It is possible to disable GitHub issues on a repository, would this not at

Re: PROPOSAL: Make Data.Type.Bool.If polykinded

for you? Richard On Sep 1, 2014, at 11:41 PM, Merijn Verstraaten mer...@inconsistent.nl wrote: Ola! Currently we have: type family If cond tru fls where If True tru fls = tru If False tru fls = fls Unfortunately, this appears to turned into a monomorphicly kinded type family

PROPOSAL: Make Data.Type.Bool.If polykinded

Ola! Currently we have: type family If cond tru fls where If True tru fls = tru If False tru fls = fls Unfortunately, this appears to turned into a monomorphicly kinded type family by GHC, which means it’s impossible to do foo :: If cond () (“Condition does not hold” ~ “”) = Foo - Bar

Re: Proposal - Foreign enum support

take that idiom into account. On Apr 17, 2014 7:19 AM, Merijn Verstraaten mer...@inconsistent.nl wrote: Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification. Proposal - Foreign enum support