Re: nofib behind master?

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
>
> nofib currently does not build (and hence perf.haskell.org is broken),
> du to the Monoid-Semigroup-Change. I looked into it and found that
> nofib, as refernced by ghc HEAD, is 26 commits behind nofib master.
>
> Ben, you did some of those commits. Any good reason not to update the
> submodule in ghc?
>
Nope, not at all. I'll bump it now.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

nofib behind master?

[Joachim Breitner]

Hi,


nofib currently does not build (and hence perf.haskell.org is broken),
du to the Monoid-Semigroup-Change. I looked into it and found that
nofib, as refernced by ghc HEAD, is 26 commits behind nofib master.

Ben, you did some of those commits. Any good reason not to update the
submodule in ghc?

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de
  https://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.2.1 release commit

[Ben Gamari]

Harendra Kumar  writes:

> Hi,
>
Sorry for the latency; just catching up on the post-ICFP mail queue.

> In the GHC git repo how do I figure out which commit belongs to release
> 8.2.1. I cannot find 8.2.1 in "git tag" output. I tried "git log" and
> searching for 8.2.1 but there seems to be no definitive comment marking
> 8.2.1.
>
Releases are tagged with the ghc-$VER-release naming convention. You
should find a tag for every release since 7.2.1. For instance,

$ git tag | grep ghc
ghc-7.10.1-rc1
ghc-7.10.1-rc2
ghc-7.10.1-rc3
ghc-7.10.1-release
ghc-7.10.2-rc1
ghc-7.10.2-rc2
ghc-7.10.2-release
ghc-7.10.3-rc1
ghc-7.10.3-rc2
ghc-7.10.3-rc3
ghc-7.10.3-release
ghc-7.10.3a-release
ghc-7.11-start
ghc-7.2.1-release
ghc-7.2.2-release
ghc-7.4.1-release
ghc-7.4.2-release
ghc-7.6.1-release
ghc-7.6.2-release
ghc-7.6.3-release
ghc-7.8.1-release
ghc-7.8.2-release
ghc-7.8.3-release
ghc-7.8.4-release
ghc-7.9-start
ghc-8.0.1-rc1
ghc-8.0.1-rc2
ghc-8.0.1-rc3
ghc-8.0.1-rc4
ghc-8.0.1-release
ghc-8.0.2-rc1
ghc-8.0.2-rc2
ghc-8.0.2-release
ghc-8.1-start
ghc-8.2.1-rc1
ghc-8.2.1-rc2
ghc-8.2.1-rc3
ghc-8.2.1-release
ghc-8.3-start

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab: conditional approval

[Ben Gamari]

Simon Marlow  writes:

> On 19 August 2017 at 03:56, Richard Eisenberg  wrote:
>
>> Hi devs,
>>
>> When reviewing a diff on Phab, I can "accept" or "request changes".
>> Sometimes, though, I want to do both: I suggest very minor (e.g., typo)
>> changes, but then when these changes are made, I accept. I'm leery of
>> making the suggestions and saying "accept", because then someone working
>> quickly may merge without noticing the typos. Does Phab have such an option?
>>
>
> "Accept with nits" is standard practice, but you're right it can go wrong
> when someone else is merging accepted diffs.  We could adopt a standard
> comment keyword, e.g. "NITS" that indicates you'd like the nits to be fixed
> before committing, perhaps?
>
Sounds reasonable to me.


> Also, I don't think it's a good idea to merge commits when the author is a
> committer, they can land themselves.
>
I would be quite happy to not have to merge such patches; I merely merge
them currently since I thought it was generally expected.

On the other hand, I generally do integration builds on the batches of
patches that I merge which can sometimes catch validation issues.
However, I expect this will be less of an issue with the
test-before-merge support in the pipeline.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Does span run in bounded space?

[Facundo Domínguez]

Dear devs,

I used to think that span is a function which doesn't run in bounded
space. But ghc defied this understanding. The program copied below
runs in bounded space with "ghc-8.2.1 -O0 main.hs; ./main" but it does
not if run with "runghc-8.2.1 -O0 main.hs".

Does someone have any insights on what's the optimization that is
making a difference in the memory footprint of these two methods of
running?

Or is there a bug in ghci, and span is supposed to run in bounded
space after all?

Thanks,
Facundo

import Prelude hiding (span)
import Data.List (foldl')

main = case span (>0) (replicate 1 1) of
(xs, ys) -> do
  print (foldl' (+) 0 xs)
  print (foldl' (+) 0 ys)

span:: (a -> Bool) -> [a] -> ([a],[a])
span _ xs@[]=  (xs, xs)
span p xs@(x:xs')
 | p x  =  let (ys, zs) = span p xs' in (x : ys, zs)
 | otherwise=  ([],xs)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Feedback on applying implicit exceptions wanted

[Andreas Klebinger]

I'm currently working out ideas for potential optimizations in pattern 
matching compilation for GHC.


While I think the theory works out fine in regards to exceptions I would 
like feedback on the possible implications.


Trac ticket with details is here:
https://ghc.haskell.org/trac/ghc/ticket/14201#comment:4

As for the theory I worked based of the assumptions that error = bottom 
and pattern match failure = error. Otherwise we get different results 
from both cases even in theory.


While I mostly worry about the practical implications I would also 
appreciate any other feedback.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs