Skip to content
This repository was archived by the owner on Oct 7, 2020. It is now read-only.

Conversation

@alanz
Copy link
Collaborator

@alanz alanz commented Feb 1, 2020

cabal now index state 2020-01-31T21:11:24Z
GHC 8.8.2 is nightly-2020-01-31
GHC 8.6.5 is lts-14.22

hlint is 2.2.9
brittany is 0.12.1.1

@alanz alanz requested review from fendor and jneira February 1, 2020 11:32
@alanz
Copy link
Collaborator Author

alanz commented Feb 1, 2020

@jneira I had to flush the cache on CircleCI for this to pass. Could the azure failures be something like that?

@jneira
Copy link
Member

jneira commented Feb 1, 2020

Mmm some linux failed with

Failures:

  test/dispatcher/Main.hs:297:7: 
  1) functional dispatch instantly responds to failed modules with no cache with the default
       expected: ("req7",Just [])
        but got: ("req8",Nothing)

  To rerun use: --match "/functional dispatch/instantly responds to failed modules with no cache with the default/"

Randomized with seed 429502550

i think i saw that error before, i've just rerun the failing jobs to see if it is transient

@jneira
Copy link
Member

jneira commented Feb 2, 2020

Linux errors are gone, only left:

  • build error with stack+stack.yaml: i don't see the concrete error 🤔
  • error running cabal-hie-install latest in windows: the second one

i would try both locally

@jneira
Copy link
Member

jneira commented Feb 2, 2020

cabal-hie-install latest was my fault fix in #1627

@alanz
Copy link
Collaborator Author

alanz commented Feb 2, 2020

Ok. Heads up, I am rebasing this PR on the hie-bios update one, and some things are changing. We will see how it ends up.

Aside, I had to blow away my cabal store and rebuild it, to get rid of weird errors about diamond deps.

@@ -1,39 +1,34 @@
resolver: nightly-2019-09-21 # Last GHC 8.6.5
resolver: nightly-2020-01-31
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cant build hie with ghc-8.2.2, if we use it in stack.yaml we should remove it from azure ci.
I think the plan was keeping ghc-8.6.5 in stack.yaml until ghc-8.8.3 lands.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we get azure to use stack-8.6.5.yaml instead? Which makes it clear

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mmm, there already is a job that uses stack-8.6.5.yaml. We can remove the one that uses stack.yaml

cabal now index state 2020-01-31T21:11:24Z
GHC 8.8.2 is nightly-2020-01-31
GHC 8.6.5 is lts-14.22

hlint is 2.2.10
brittany is 0.12.1.1
@jneira
Copy link
Member

jneira commented Feb 3, 2020

Now, builds with ghc-8.4.3 are failing with:

warp                             > [21 of 39] Compiling Network.Wai.Handler.Warp.Recv
warp                             > 
warp                             > /tmp/stack6092/warp-3.2.25/Network/Wai/Handler/Warp/Recv.hs:96:34: error:
warp                             >     • Couldn't match expected type ‘CInt’ with actual type ‘IO CInt’
warp                             >     • In the first argument of ‘receiveloop’, namely ‘sock'’
warp                             >       In the second argument of ‘(<$>)’, namely
warp                             >         ‘receiveloop sock' ptr size'’
warp                             >       In a stmt of a 'do' block:
warp                             >         fromIntegral <$> receiveloop sock' ptr size'
warp                             >    |
warp                             > 96 |     fromIntegral <$> receiveloop sock' ptr size'
warp                             >    |                                  ^^^^^
warp                             > 
warp                             > /tmp/stack6092/warp-3.2.25/Network/Wai/Handler/Warp/Recv.hs:103:43: error:
warp                             >     • Couldn't match expected type ‘CInt’ with actual type ‘IO CInt’
warp                             >     • In the first argument of ‘receiveloop’, namely ‘fd’
warp                             >       In the second argument of ‘(<$>)’, namely
warp                             >         ‘receiveloop fd buf (fromIntegral siz)’
warp                             >       In a stmt of a 'do' block:
warp                             >         n <- fromIntegral <$> receiveloop fd buf (fromIntegral siz)
warp                             >     |
warp                             > 103 |         n <- fromIntegral <$> receiveloop fd buf (fromIntegral siz)
warp                             >     |                              

@jneira
Copy link
Member

jneira commented Feb 3, 2020

I am working to fix ghc-8.4.3 builds

@jneira
Copy link
Member

jneira commented Feb 3, 2020

There is a failing unit test but ,as @fendor as noted , it was introduced by #1261 so i think we can merge this.

@jneira jneira merged commit 79cb340 into haskell:master Feb 3, 2020
@alanz
Copy link
Collaborator Author

alanz commented Feb 3, 2020

@jneira thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants