Re: [ANNOUNCE] GHC 8.4.1-rc1 available

[Vincent Hanquez]

On 25/02/18 17:42, Ben Gamari wrote:

The GHC development team is pleased to announce the first (and likely
final) release candidate of GHC 8.4.1. The usual release artifacts are
available from

 https://downloads.haskell.org/~ghc/8.4.1-rc1


Hi Ben,

Looks like both SHA1SUM and SHA256SUM are missing the fedora27 variant

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

Re: [ANNOUNCE] GHC 8.4.1-alpha1 available

[Vincent Hanquez]

On 21/12/17 20:48, Oleg Grenrus wrote:

I copy & paste Hervert's reddit answer here [1], for ones who don't
follow it:

As the suffix "alpha" implies, this is a very bleeding edge release with
very little guarantees regarding API stability (c.f. new GHC schedule
[2]
).

Put differently, a package that works now with GHC 8.4.1-alpha1 may not
necessarily work with the final GHC 8.4.1 release.


A package that works now with -alpha1 doesn't have to be the same as
the one that work with the final release.

(And that's only in the unlikely case that an alpha->final break API
which in most cases it really shouldn't)

Resorting to another system than the common system for testing, means 
much less
people are actually going to have the opportunity to integrate it in 
their test suite,

which ultimately reduces GHC QA at large.

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

Re: Impredicative types and forall regression in 8.0 ?

[Vincent Hanquez]

On 15/02/2016 10:49, Adam Gundry wrote:

Hi Vincent,

On 15/02/16 09:44, Vincent Hanquez wrote:

I recently came across a compilation problem on 8.0 that do not trigger
on < 8.0. I've reduced the issue to this snippet with Rank2Types:

 type Action = (forall a . Show a => a) -> Int
 data Command = Command (Maybe Action)

 com1 = Command Nothing

With GHC 7.0 to 7.10, this compile and works.

This shouldn't be accepted without ImpredicativeTypes[*], but GHC
versions prior to 8.0 failed to look through the type synonym. Note that
if you say

 data Command = Command (Maybe ((forall a . Show a => a) -> Int))

then earlier versions report an error. Take a look at GHC ticket #10194
for more details: https://ghc.haskell.org/trac/ghc/ticket/10194
Ok, make sense; After reading what ImpredicativeTypes are, I can see the 
difference in the construct.


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

Impredicative types and forall regression in 8.0 ?

[Vincent Hanquez]

Hi GHC-Devs,

I recently came across a compilation problem on 8.0 that do not trigger 
on < 8.0. I've reduced the issue to this snippet with Rank2Types:


type Action = (forall a . Show a => a) -> Int
data Command = Command (Maybe Action)

com1 = Command Nothing

With GHC 7.0 to 7.10, this compile and works.
However on GHC 8.0, I now have:

Test.hs:19:16: error:
• Cannot instantiate unification variable ‘a0’
  with a type involving foralls: Action
GHC doesn't yet support impredicative polymorphism
• In the first argument of ‘Command’, namely ‘Nothing’
  In the expression: Command Nothing
  In an equation for ‘com1’: com1 = Command Nothing

I workarounded it by "inlining" the maybe and creating a proper wrapping 
type:


data Action2 = Action2 ((forall a . Show a => a) -> Int) | NoAction2
data Command2 = Command2 Action2

com2 = Command2 NoAction2

Any idea why this is triggering this issue in GHC 8.0 ? Is this 
something that need fixing maybe ?


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

Re: Proposal: accept pull requests on GitHub

[Vincent Hanquez]

On 03/09/2015 10:53, Thomas Miedema wrote:


The real hint is that "the number of contributions will go up". That's
a noble goal and I think it's at the heart of this proposal.


When you're going to require contributors to use a non-standard tool 
to get patches to your code review system, it better just work. `arc` 
is clearly failing us here, and I'm saying enough is enough.
Not only this, but there's (probably) lots of small/janitorial 
contributions that do not need the full power of phabricator or any 
sophisticated code review.


Not accepting github PRs and forcing everyone to go through an uncommon 
tool (however formidable), is quite likely to turn those contributions 
away IMHO.


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

Re: Ian leaving and the glorious future

[Vincent Hanquez]

On 08/02/2013 07:32 PM, Simon Peyton-Jones wrote:


Dear ghc-dev friends,

[snip]

Don’t worry: I’m not bowing out! But I am very much trying to 
encourage you to feel that GHC is *your* compiler, not just SPJ/SM’s 
compiler that you can contribute to. I’m open to suggestions for how 
best to nurture broad participation.




Hi,

As a suggestion to increase participation, OcamlLab recently hosted a 
compiler hacking evening [1] and maybe it would be a good idea to host 
the same kind of thing for GHC ? If it's not practical to meet in the 
same physical place (not enough people in the same place, no place to 
meet, etc), organizing IRC hacking session might a good backup option.


Also, one thing that I find missing is a bite sized list of 
projects/bug/improvements to get started for newcomers. The full list of 
opened issued on trac is probably an intimidating list to get started.


[1] https://github.com/ocamllabs/compiler-hacking/wiki 
https://github.com/ocamllabs/compiler-hacking/wiki


--
Vincent

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Build broken: urgent

[Vincent Hanquez]

On 06/11/2013 09:09 PM, Simon Peyton-Jones wrote:


Ian

This getRegister bug is killing my Windows builds too; indeed every 
32-bit build is broken, and that is stalling a lot of people, now 
including me.


Could you perhaps revert the patch (around 6 June) that caused this, 
until it’s sorted out?


Thanks

Simon

inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m 
-O -Werror -Wall -H64m -O0 -package-name ghc-prim-0.3.1.0 
-hide-all-packages -i -ilibraries/ghc-prim/. 
-ilibraries/ghc-prim/dist-install/build 
-ilibraries/ghc-prim/dist-install/build/autogen 
-Ilibraries/ghc-prim/dist-install/build 
-Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. 
-optP-include 
-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h 
-package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash 
-XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples 
-XEmptyDataDecls -XNoImplicitPrelude -O2 -O -dcore-lint 
-fno-warn-deprecated-flags -no-user-package-db -rtsopts -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/dist-install/build/GHC/PrimopWrappers.hs -o 
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno 
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o


ghc-stage1.exe: panic! (the 'impossible' happened)

(GHC version 7.7.20130611 for i386-unknown-mingw32):

getRegister(x86) I64[Sp]


Hi Simon,

Could the culprit be my bswap patches that Ian pushed on the 6th ?
Quickly looking at the history, doesn't look there's lots of things 
changing primops around this time.


--
Vincent


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Build broken: urgent

[Vincent Hanquez]

On 06/11/2013 10:18 PM, Simon Peyton-Jones wrote:

Yes, that's the one.  I'm reverting it now

sorry about that.
i'll have a look at the fix for the 32 bit version ASAP.

--
Vincent


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: how to checkout proper submodules

[Vincent Hanquez]

On 06/05/2013 10:10 AM, David Terei wrote:

On 5 June 2013 01:43, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote:


I agree with Austin and Johan. It's a bizarre setup. Submodules have their
pain points (which we already have to deal with), but the ability to
properly snapshot and branch the whole tree would be a serious benefit IMO.

Manuel

PS: While we are at it, why don't we just have the main repos on GitHub
and use forks and pull requests like the rest of the world? (Using Git, but
not GitHub's superb infrastructure, seems like a terrible waste to me.)


I'd be all for this. We partially use the GitHub infrastructure since trac
broke and I changed the emails to point to GitHub instead. I also often do
code reviews with other devs on a personal GHC fork on github before
merging in.

I believe it would also help encourage more contributors (especially for
libraries) but others have expressed disagreement with this point of view
in the past and I'm not in hold of data.
As a very recent new (try-to-be-)contributor, i'ld like to weight in, in 
favor of this.


IMHO, having to create a trac account, and submit patches by attachment
(with the confusing trac UI) instead of just pushing to some 
repositories and

issuing pull requests is quite suboptimal.

I don't think it would scare anyone enough that they wouldn't 
contribute, but

lowering the entry cost is always useful.

--
Vincent

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs