Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Ben Gamari]

George Colpitts  writes:

> installs fine on mac but cabal install vector fails on primitive, looks to
> me like gmp library is not provided
>
I have built a new OS X binary [1] which should be linked against the
in-tree libgmp, fixing this issue (which we've been tracking as Trac
#11423).

I have also pushed a 32-bit Windows build.

Perhaps those affected by this issue could try this distribution?

Cheers,

- Ben


[1] 
http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0b.20160111-x86_64-apple-darwin.tar.xz


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

RE: Explanation of a core-lint warning (Bad getNth)

[Simon Peyton Jones]

Maybe put this all on a ticket?

Everyone: would someone like to dig into this?  I’m so under water that I just 
can’t

Simon

From: Jan Bracker [mailto:jan.brac...@googlemail.com]
Sent: 15 January 2016 14:03
To: Simon Peyton Jones 
Cc: Richard Eisenberg ; ghc-devs@haskell.org
Subject: Re: Explanation of a core-lint warning (Bad getNth)

I have condensed a self-contained plugin and an example application that 
reproduces the error. You can find it here:
https://github.com/jbracker/polymonad-plugin/tree/master/examples/core-error

You just have to download the three files and run "cabal install" to reproduce 
the error. There is a high-level explanation of
what is going on in [1]. The plugin [2] is still around 600 lines long, but I 
have added a lot of comments to make it comprehensible.
I suppose the most interesting part is the production of evidence [3]. I have 
added checks to see if the evidence I produce contains the 'Nth' constructors 
the core-linter refers to [4,5], but the evidence produced does not contain 
them. So somehow the evidence triggers GHC to produce evidence that the 
core-linter warns about.

I hope this is comprehensible and you can help me with what is going on.

Best,
Jan

[1] 
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/Main.hs#L83
[2] 
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs
[3] 
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L198
[4] 
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L130
[5] 
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L556

2015-11-20 9:57 GMT+00:00 Simon Peyton Jones 
>:
I don’t know how to help either, because there’s no way to reproduce it.  Can 
you find a Haskell program that, when GHC compiles it, produces this Lint 
error?  Or does it require your plugin?  If the latter, it’s hard to know what 
your plugin might be doing…

So I feel a bit stalled on how to help.

Simon

From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Richard Eisenberg
Sent: 18 November 2015 17:14
To: Jan Bracker
Cc: ghc-devs@haskell.org
Subject: Re: Explanation of a core-lint warning (Bad getNth)

Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the 
outermost that's the problem, which is deconstructing the Union. But it's doing 
so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is rather easy 
to prove without NthCo. I'm not sure why GHC is doing this.

Richard

On Nov 18, 2015, at 12:11 PM, Jan Bracker 
> wrote:

Hi Richard,

No "Split" is a class and is defined here: 
http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split
"Union" is a type function (synonym that refers to a type function call): 
http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union

thank you for your quick reply!

Best,
Jan

2015-11-18 17:05 GMT+00:00 Richard Eisenberg 
>:
I took just a quick look at this. Is Split a type family? The NthCo coercion 
form takes apart a composite equality into its pieces. For example, if we know 
(Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it 
looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ (Union 
'["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) types. If 
Split is a type family, this deduction is unsound. That may be what Core Lint 
is worried about.

I'm not surprised that the executable would run with an error. But it might not 
in the future. If -dcore-lint fails, it means that there is a potential type 
safety issue in the Core code, and this should be taken seriously.

I hope this helps!
Richard

On Nov 18, 2015, at 11:35 AM, Jan Bracker 
> wrote:

Hi,

I am using the type checker plugin interface and I am trying to produce some 
evidence for type class instances. During 

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Karel Gardas]

Hi,

SPARC/Solaris 11.2 build: 
https://app.box.com/s/lktjbjtnqv39pil4pkkni4xpn5mi2053

Its signature: https://app.box.com/s/catr69sepivx5xb0g5totl2y6hwrznpj

Signatures of already sent files:
i386/solaris: https://app.box.com/s/it4pih3bi6bq02mfqmnnae13sk7gebb4
amd64/solaris: https://app.box.com/s/okvd7dq3g1jhznkmlf4coug51f83724t
amd64/openbsd: https://app.box.com/s/xa4u80t8htmmqotxwcmdj25soxddgrxb
SHA256SUM: https://app.box.com/s/86ipjn3z3wwzbcpwos8e80qcivn6fnhv

Updated SHA256SUM file: 
https://app.box.com/s/0t3kutu8i3xhhs1vh97x6vcmjdnvlm78


Karel

On 01/14/16 10:27 PM, Karel Gardas wrote:


Hi,

I've build two builds for Solaris 11.2:

i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446
amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg

Both binary distributions support shared libraries and use system
provided GMP library. If you do not have it installed then you should do
that using "pkg install library/gmp" command.


and one build for OpenBSD 5.9 (current):

amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi

This binary distribution also supports shared libraries and by default
also OpenBSD position independent executables (PIE). It requires gmp,
libffi and libiconv to be installed by "pkg_add " command.


SPARC build for Solaris 11.2 is ongoing.

Karel


On 01/13/16 04:43 PM, Ben Gamari wrote:


The GHC Team is very pleased to announce the first release candidate of
the Glasgow Haskell Compiler 8.0.1 release. Source and binary
distributions as well as the newly revised users guide can be found at

 http://downloads.haskell.org/~ghc/8.0.1-rc1/

This is the first in a series of release candidates which will allow us
to get wider testing of the significant changes that have occurred since
the 7.10 series. These include,

  * the TypeInType extension, which unifies types and kinds allowing for
promotion of more Haskell constructs to the type-level

  * the introduction of type application in source programs

  * support for recursive superclass relationships

  * support for Applicative do notation

  * introduction of the DuplicateRecordFields language extension

  * a rewritten and substantially more thorough pattern match checker

  * the introduction of injective type classes

  * introduction of the Strict and StrictData language extensions,
allowing modules to be compiled with strict-by-default evaluation
of bindings

  * the ability to run the GHCi interpreter in a separate process,
allowing a callstacks in GHCi, easier integration with tooling, and
more

and much more.

Changes of this magnitude will invariably bring bugs. This release
candidate in particular is known to suffer from a few significant issues
which are being actively worked upon,

  * The new -XInjectiveTypeFamilies language extension will likely be
renamed to -XTypeFamilyDependencies

  * #11120: Type representations are missing for some types and promoted
constructors

  * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails

  * #11276: Pattern checker performance can degrade significantly in
presence of pattern matches with guards

  * #11405: Type-level skolem-escape check fails incorrectly

  * #11414: Use of -XStrict results in compiler abort

  * #11379: Instance solver fails to terminate

  * #11419: Haddock documentation is currently not included in the binary
distributions (and hence is missing on downloads.haskell.org)

  * #11370: -Wredundant-constraints being included in -Wall breaks
the three-release compatibility policy

In the coming weeks we will continue to iterate on these issues. We will
also look at Trac tickets marked with "highest" priority on the release
status page [2].

If you have a ticket that you would like to see addressed that does not
meet one of these criteria, please bring this to our attention.
Likewise, if you encounter an issue please open a ticket if one does not
already exist.

Also note that we currently cannot offer 32-bit Windows builds due to
breaking changing in a recent Windows 10 upgrade. We'll work to
resolve this before the 8.0 release but please let us know if this poses
a significant problem for you.

Cheers,

- Ben


[1] https://cygwin.com/ml/cygwin/2015-12/msg3.htm
[2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1



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



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



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

Re: Explanation of a core-lint warning (Bad getNth)

[Jan Bracker]

I have condensed a self-contained plugin and an example application that
reproduces the error. You can find it here:
https://github.com/jbracker/polymonad-plugin/tree/master/examples/core-error

You just have to download the three files and run "cabal install" to
reproduce the error. There is a high-level explanation of
what is going on in [1]. The plugin [2] is still around 600 lines long, but
I have added a lot of comments to make it comprehensible.
I suppose the most interesting part is the production of evidence [3]. I
have added checks to see if the evidence I produce contains the 'Nth'
constructors the core-linter refers to [4,5], but the evidence produced
does not contain them. So somehow the evidence triggers GHC to produce
evidence that the core-linter warns about.

I hope this is comprehensible and you can help me with what is going on.

Best,
Jan

[1]
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/Main.hs#L83
[2]
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs
[3]
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L198
[4]
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L130
[5]
https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L556

2015-11-20 9:57 GMT+00:00 Simon Peyton Jones :

> I don’t know how to help either, because there’s no way to reproduce it.
> Can you find a Haskell program that, when GHC compiles it, produces this
> Lint error?  Or does it require your plugin?  If the latter, it’s hard to
> know what your plugin might be doing…
>
>
>
> So I feel a bit stalled on how to help.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Richard
> Eisenberg
> *Sent:* 18 November 2015 17:14
> *To:* Jan Bracker
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Explanation of a core-lint warning (Bad getNth)
>
>
>
> Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its
> the outermost that's the problem, which is deconstructing the Union. But
> it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which
> is rather easy to prove without NthCo. I'm not sure why GHC is doing this.
>
>
>
> Richard
>
>
>
> On Nov 18, 2015, at 12:11 PM, Jan Bracker 
> wrote:
>
>
>
> Hi Richard,
>
>
>
> No "Split" is a class and is defined here:
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split
> 
>
> "Union" is a type function (synonym that refers to a type function call):
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union
> 
>
>
>
> thank you for your quick reply!
>
>
>
> Best,
>
> Jan
>
>
>
> 2015-11-18 17:05 GMT+00:00 Richard Eisenberg :
>
> I took just a quick look at this. Is Split a type family? The NthCo
> coercion form takes apart a composite equality into its pieces. For
> example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a
> ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres"
> :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of
> two (Split ...) types. If Split is a type family, this deduction is
> unsound. That may be what Core Lint is worried about.
>
>
>
> I'm not surprised that the executable would run with an error. But it
> might not in the future. If -dcore-lint fails, it means that there is a
> potential type safety issue in the Core code, and this should be taken
> seriously.
>
>
>
> I hope this helps!
>
> Richard
>
>
>
> On Nov 18, 2015, at 11:35 AM, Jan Bracker 
> wrote:
>
>
>
> Hi,
>
>
>
> I am using the type checker plugin interface and I am trying to produce
> some evidence for type class instances. During compilation of one of my
> examples I get this core-lint error:
>
>
>
> *** Core Lint errors : in result of Simplifier ***
>
> : Warning:
>
> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))]
>
> Bad getNth:
>
>   Nth:0
>
> (Nth:2
>
>(Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N
> <'[]>_N))
>
> ; (Inv
>
>  _N <'["thres" :-> Int]>_N 

Re: Explanation of a core-lint warning (Bad getNth)

[Jan Bracker]

I have created Ticket #11435.

I am still not sure if I am producing incorrect evidence or if there really
is an issue with GHC, but I would expect GHC to tell me if the evidence I
produced does not make sense.

[1] https://ghc.haskell.org/trac/ghc/ticket/11435

2016-01-15 14:15 GMT+00:00 Simon Peyton Jones :

> Maybe put this all on a ticket?
>
>
>
> Everyone: would someone like to dig into this?  I’m so under water that I
> just can’t
>
>
>
> Simon
>
>
>
> *From:* Jan Bracker [mailto:jan.brac...@googlemail.com]
> *Sent:* 15 January 2016 14:03
> *To:* Simon Peyton Jones 
> *Cc:* Richard Eisenberg ; ghc-devs@haskell.org
>
> *Subject:* Re: Explanation of a core-lint warning (Bad getNth)
>
>
>
> I have condensed a self-contained plugin and an example application that
> reproduces the error. You can find it here:
>
>
> https://github.com/jbracker/polymonad-plugin/tree/master/examples/core-error
>
>
>
> You just have to download the three files and run "cabal install" to
> reproduce the error. There is a high-level explanation of
>
> what is going on in [1]. The plugin [2] is still around 600 lines long,
> but I have added a lot of comments to make it comprehensible.
>
> I suppose the most interesting part is the production of evidence [3]. I
> have added checks to see if the evidence I produce contains the 'Nth'
> constructors the core-linter refers to [4,5], but the evidence produced
> does not contain them. So somehow the evidence triggers GHC to produce
> evidence that the core-linter warns about.
>
>
>
> I hope this is comprehensible and you can help me with what is going on.
>
>
>
> Best,
>
> Jan
>
>
>
> [1]
> https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/Main.hs#L83
>
> [2]
> https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs
>
> [3]
> https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L198
>
> [4]
> https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L130
>
> [5]
> https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L556
>
>
>
> 2015-11-20 9:57 GMT+00:00 Simon Peyton Jones :
>
> I don’t know how to help either, because there’s no way to reproduce it.
> Can you find a Haskell program that, when GHC compiles it, produces this
> Lint error?  Or does it require your plugin?  If the latter, it’s hard to
> know what your plugin might be doing…
>
>
>
> So I feel a bit stalled on how to help.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Richard
> Eisenberg
> *Sent:* 18 November 2015 17:14
> *To:* Jan Bracker
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Explanation of a core-lint warning (Bad getNth)
>
>
>
> Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its
> the outermost that's the problem, which is deconstructing the Union. But
> it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which
> is rather easy to prove without NthCo. I'm not sure why GHC is doing this.
>
>
>
> Richard
>
>
>
> On Nov 18, 2015, at 12:11 PM, Jan Bracker 
> wrote:
>
>
>
> Hi Richard,
>
>
>
> No "Split" is a class and is defined here:
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split
> 
>
> "Union" is a type function (synonym that refers to a type function call):
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union
> 
>
>
>
> thank you for your quick reply!
>
>
>
> Best,
>
> Jan
>
>
>
> 2015-11-18 17:05 GMT+00:00 Richard Eisenberg :
>
> I took just a quick look at this. Is Split a type family? The NthCo
> coercion form takes apart a composite equality into its pieces. For
> example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a
> ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres"
> :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of
> two (Split ...) types. If Split is a type family, this deduction is
> unsound. That may be what Core Lint is worried about.
>
>
>
> I'm not surprised that the executable would run with an 

Phab failing to apply patches

[Jan Stolarek]

It seems that Phab is once again failing to apply patches (eg. D1778, which 
built perfectly fine 
until latest update). Is anyone else experiencing this?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Thomas Miedema]

"Unable to apply patch!" means just that. Harbormaster is unable to apply
the patch (to master). You can test it yourself by running 'arc patch
--nobranch D1778` on an up-to-date checkout of the master branch, and it
will fail in the same way.

Solution: rebase your patch onto master, and update the Diff. You'll notice
there are indeed merge problems.


On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek 
wrote:

> It seems that Phab is once again failing to apply patches (eg. D1778,
> which built perfectly fine
> until latest update). Is anyone else experiencing this?
>
> Janek
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message
> in error,
> please notify the sender and delete it from your system.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

Somehow I always I believed that Harbormaster does not apply a patch onto 
master but onto the 
revision it was created from. Has there been any change in this behaviour 
recently?

Janek

Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:
> "Unable to apply patch!" means just that. Harbormaster is unable to apply
> the patch (to master). You can test it yourself by running 'arc patch
> --nobranch D1778` on an up-to-date checkout of the master branch, and it
> will fail in the same way.
>
> Solution: rebase your patch onto master, and update the Diff. You'll notice
> there are indeed merge problems.
>
>
> On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek 
>
> wrote:
> > It seems that Phab is once again failing to apply patches (eg. D1778,
> > which built perfectly fine
> > until latest update). Is anyone else experiencing this?
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę
> > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed.
> > If you are not the intended recipient or if you have received this
> > message in error,
> > please notify the sender and delete it from your system.
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Ben Gamari]

Karel Gardas  writes:

> Hi,
>
Hi Karel,

In the future do you suppose you could just tar these up and post the
tarball? box.com is a bit annoying to download files from.

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: Explanation of a core-lint warning (Bad getNth)

[Thomas Miedema]

On Fri, Jan 15, 2016 at 3:03 PM, Jan Bracker 
wrote:

> You just have to download the three files and run "cabal install" to
> reproduce the error.
>

It's never that easy, is it? Can you try in a cabal sandbox, with
ghc-7.10.3. I'm getting:



cabal: Could not resolve dependencies:
trying: core-error-0.1 (user goal)
next goal: base (dependency of core-error-0.1)
rejecting: base-4.8.2.0/installed-0d6... (conflict: core-error =>
base==4.8.1.0)
rejecting: base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
base-3.0.3.1 (constraint from main config /home/thomas/.cabal/config
requires
installed instance)
Dependency tree exhaustively searched.



After relaxing the depenency on base (or is the problem only reproducible
with base 4.8.1.0 that, in case we are done here), I get:





Preprocessing library effect-monad-0.6.1...

src/Control/Effect/State.hs:4:14: Warning:
-XOverlappingInstances is deprecated: instead use per-instance pragmas
OVERLAPPING/OVERLAPPABLE/OVERLAPS
[ 1 of 17] Compiling Control.Effect.Helpers.List (
src/Control/Effect/Helpers/List.hs,
dist/build/Control/Effect/Helpers/List.o )
[ 2 of 17] Compiling Control.Effect.Cond ( src/Control/Effect/Cond.hs,
dist/build/Control/Effect/Cond.o )
[ 3 of 17] Compiling Control.Effect   ( src/Control/Effect.hs,
dist/build/Control/Effect.o )
[ 4 of 17] Compiling Control.Effect.Counter (
src/Control/Effect/Counter.hs, dist/build/Control/Effect/Counter.o )
[ 5 of 17] Compiling Control.Effect.CounterNat (
src/Control/Effect/CounterNat.hs, dist/build/Control/Effect/CounterNat.o )
[ 6 of 17] Compiling Control.Effect.Maybe ( src/Control/Effect/Maybe.hs,
dist/build/Control/Effect/Maybe.o )
[ 7 of 17] Compiling Control.Effect.Monad ( src/Control/Effect/Monad.hs,
dist/build/Control/Effect/Monad.o )
[ 8 of 17] Compiling Control.Effect.Parameterised (
src/Control/Effect/Parameterised.hs,
dist/build/Control/Effect/Parameterised.o )
[ 9 of 17] Compiling Control.Effect.Reader ( src/Control/Effect/Reader.hs,
dist/build/Control/Effect/Reader.o )

src/Control/Effect/Reader.hs:33:8:
Not in scope: type constructor or class ‘Var’

src/Control/Effect/Reader.hs:33:28:
Not in scope: type constructor or class ‘:->’

src/Control/Effect/Reader.hs:34:5:
Not in scope: data constructor ‘Var’

src/Control/Effect/Reader.hs:34:24:
Not in scope: data constructor ‘Var’

src/Control/Effect/Reader.hs:34:28:
Not in scope: data constructor ‘:->’
Failed to install effect-monad-0.6.1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Explanation of a core-lint warning (Bad getNth)

[Jan Bracker]

Hard-coding the exact base version was a stupid mistake, sorry. I relaxed
that and reattached a new version of the files to the ticket.

It seems that 'effect-monad's dependency on 'type-level-sets' is a bit to
liberal, because the module structure and exports of that package changed
between versions. I hard-coded the correct version of 'type-level-set' into
the cabal file of the example. I did not get this, because I share a
sandbox between my main project and the examples (and its been around for
some time now). Seems like 'effect-monad' is bitrotting a bit...

I did not test these changes on 7.10.3, because I currently only have
version 7.10.2 installed.

2016-01-15 22:30 GMT+00:00 Thomas Miedema :

>
>
> On Fri, Jan 15, 2016 at 3:03 PM, Jan Bracker 
> wrote:
>
>> You just have to download the three files and run "cabal install" to
>> reproduce the error.
>>
>
> It's never that easy, is it? Can you try in a cabal sandbox, with
> ghc-7.10.3. I'm getting:
>
>
>
> cabal: Could not resolve dependencies:
> trying: core-error-0.1 (user goal)
> next goal: base (dependency of core-error-0.1)
> rejecting: base-4.8.2.0/installed-0d6... (conflict: core-error =>
> base==4.8.1.0)
> rejecting: base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
> base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
> base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
> base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
> base-3.0.3.1 (constraint from main config /home/thomas/.cabal/config
> requires
> installed instance)
> Dependency tree exhaustively searched.
>
>
>
> After relaxing the depenency on base (or is the problem only reproducible
> with base 4.8.1.0 that, in case we are done here), I get:
>
>
>
>
>
> Preprocessing library effect-monad-0.6.1...
>
> src/Control/Effect/State.hs:4:14: Warning:
> -XOverlappingInstances is deprecated: instead use per-instance pragmas
> OVERLAPPING/OVERLAPPABLE/OVERLAPS
> [ 1 of 17] Compiling Control.Effect.Helpers.List (
> src/Control/Effect/Helpers/List.hs,
> dist/build/Control/Effect/Helpers/List.o )
> [ 2 of 17] Compiling Control.Effect.Cond ( src/Control/Effect/Cond.hs,
> dist/build/Control/Effect/Cond.o )
> [ 3 of 17] Compiling Control.Effect   ( src/Control/Effect.hs,
> dist/build/Control/Effect.o )
> [ 4 of 17] Compiling Control.Effect.Counter (
> src/Control/Effect/Counter.hs, dist/build/Control/Effect/Counter.o )
> [ 5 of 17] Compiling Control.Effect.CounterNat (
> src/Control/Effect/CounterNat.hs, dist/build/Control/Effect/CounterNat.o )
> [ 6 of 17] Compiling Control.Effect.Maybe ( src/Control/Effect/Maybe.hs,
> dist/build/Control/Effect/Maybe.o )
> [ 7 of 17] Compiling Control.Effect.Monad ( src/Control/Effect/Monad.hs,
> dist/build/Control/Effect/Monad.o )
> [ 8 of 17] Compiling Control.Effect.Parameterised (
> src/Control/Effect/Parameterised.hs,
> dist/build/Control/Effect/Parameterised.o )
> [ 9 of 17] Compiling Control.Effect.Reader ( src/Control/Effect/Reader.hs,
> dist/build/Control/Effect/Reader.o )
>
> src/Control/Effect/Reader.hs:33:8:
> Not in scope: type constructor or class ‘Var’
>
> src/Control/Effect/Reader.hs:33:28:
> Not in scope: type constructor or class ‘:->’
>
> src/Control/Effect/Reader.hs:34:5:
> Not in scope: data constructor ‘Var’
>
> src/Control/Effect/Reader.hs:34:24:
> Not in scope: data constructor ‘Var’
>
> src/Control/Effect/Reader.hs:34:28:
> Not in scope: data constructor ‘:->’
> Failed to install effect-monad-0.6.1
>
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Explanation of a core-lint warning (Bad getNth)

[Thomas Miedema]

I can reproduce the problem with 7.10.3. Since the compiler got completely
rewritten, the plugin for sure doesn't work with 8.0.

In case anyone else wants to take look at this bug, I can say the plugin
contains a lot of hopefully helpful comments.


On Sat, Jan 16, 2016 at 12:49 AM, Jan Bracker 
wrote:

> Seems like 'effect-monad' is bitrotting a bit...
>

I submitted this pull request:
https://github.com/dorchard/effect-monad/pull/5
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Ben Gamari]

Karel Gardas  writes:

> Hi,
>
> I've build two builds for Solaris 11.2:
>
> i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446
> amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg
>
> Both binary distributions support shared libraries and use system 
> provided GMP library. If you do not have it installed then you should do 
> that using "pkg install library/gmp" command.
>
>
> and one build for OpenBSD 5.9 (current):
>
> amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi
>
> This binary distribution also supports shared libraries and by default 
> also OpenBSD position independent executables (PIE). It requires gmp, 
> libffi and libiconv to be installed by "pkg_add " command.
>
>
> SPARC build for Solaris 11.2 is ongoing.
>
Thanks Karel, let me know when it's available.

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