Re: thenIO removal
Hi, Am Sonntag, den 02.11.2014, 20:10 -0500 schrieb David Feuer: GHC.Base has a function, thenIO, that isn't used anywhere in the libraries or compiler, and isn't exported anywhere public. But for some reason, it's listed in compiler/prelude/PrelNames.lhs, which causes a validation failure if I remove it. Is there a reason that a completely unused function is wired in? Is it a historical artifact, or an optimization that was never completed, or something else? Should I wipe it out of PrelNames, or do we want to use it for something? I find uses in compiler/typecheck/TcRnDriver.lhs in tcUserStmt, it seems to be related to ghci’s support for IO actions. If you can rewrite that easily, then it surely can go, but there likely is a reason for it. If you find that reason, a Note would be appreciated. Greeting, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC on Windows (extended/broad discussion)
My timezone is GMT+5 (mostly, sometimes I visit Moscow, which is +3). Cheers, Kyra On 03.11.2014 0:42, Gintautas Miliauskas wrote: Alright, based on the votes let's do Wednesday (Nov 5) 8:00pm. Kyrill, what's your timezone? Did this go too much into the evening for you? Would be good to know for next time. Shall we use Hangouts for the call? Skype would also work for me, but Hangouts is probably a bit easier and more portable. Looking forward to seeing everyone! I will try to take notes of the meeting and send them to the mailing list afterwards. On Thu, Oct 30, 2014 at 9:03 PM, Gintautas Miliauskas gintautas.miliaus...@gmail.com mailto:gintautas.miliaus...@gmail.com wrote: Updated. Note that I'm on vacation starting Friday (Nov 7) and will be back only on Nov 24. On Thu, Oct 30, 2014 at 6:40 PM, loneti...@gmail.com mailto:loneti...@gmail.com wrote: Hi Gintautas, Is it possible for you to add the rest of next week to the schedule times? I’m unavailable on the given dates. Kind Regards, Tamar *From:* Gintautas Miliauskas mailto:gintautas.miliaus...@gmail.com *Sent:* Thursday, October 30, 2014 16:34 *To:* Simon Peyton Jones mailto:simo...@microsoft.com *Cc:* kyra mailto:ky...@mail.ru, ghc-devs@haskell.org mailto:ghc-devs@haskell.org On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones simo...@microsoft.com mailto:simo...@microsoft.com wrote: The people problem is tricky. At work, this would be the right time to do a video chat and at least see the faces of the other people involved. Would folks be interested in a Skype/Hangout sometime? It would be interesting to hear what interests / skills / resources / constraints we have between us. I think that’s a great idea, thanks. It’s easier to work with people with whom you have formed a personal relationship, and a video conf is a good way to do that. Let's try that. Shall we try to find a good timeslot? Sign up at http://doodle.com/34e598zc7m8sbaqm -- Gintautas Miliauskashttp://doodle.com/34e598zc7m8sbaqm http://doodle.com/34e598zc7m8sbaqm -- Gintautas Miliauskas -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: package hashes
So, there seem to be two things going on here: 1. For some reason, your checkout thinks that the package key is unambiguous, whereas all the checkouts I've run it on think it is ambiguous, and thus must be qualified. I actually can't reproduce your version of the error, but it seems harmless. I think the right thing to do here is force GHC to always print fully qualified; I suspect one of the DynFlags will do it for us. 2. But the test seems to be gaining a new entry entirely, what gives? Well, the test-case is using grep to pull out the part of --show-iface that it cares about. However, --show-iface is using the pretty-printing combinators, so when a field is sufficiently long it spills over to the next line, and it isn't picked up by grep. So the test here is actually a bit broken. I think if we force GHC to have infinite columns that will fix the second problem. Edward Excerpts from Simon Peyton Jones's message of 2014-10-30 08:26:45 -0700: Edward On branch wip/new-flatten-skolems-Oct14, I'm getting this test failure repeatably on test safePkgO1. I'm pretty sure I have done nothing to mess with package hashes! Any ideas? Simon = safePkg01(normal) 108 of 120 [0, 0, 0] cd ./check/pkg01 $MAKE -s --no-print-directory safePkg01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--enable-shared/dev/null safePkg01.run.stdout 2safePkg01.run.stderr Actual stdout output differs from expected: --- ./check/pkg01/safePkg01.stdout 2014-10-29 15:09:16.0 + +++ ./check/pkg01/safePkg01.run.stdout 2014-10-30 15:25:17.799094762 + @@ -29,17 +29,17 @@ require own pkg trusted: True M_SafePkg6 -package dependencies: array-0.5.0.1@array_HASH +package dependencies: array-0.5.0.1 base-4.8.0.0* trusted: trustworthy require own pkg trusted: False M_SafePkg7 -package dependencies: array-0.5.0.1@array_HASH +package dependencies: array-0.5.0.1 base-4.8.0.0* trusted: safe require own pkg trusted: False M_SafePkg8 -package dependencies: array-0.5.0.1@array_HASH +package dependencies: array-0.5.0.1 base-4.8.0.0 trusted: trustworthy require own pkg trusted: False ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RFC: Concrete syntax for pattern synonym type signatures
Background -- As explained on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics the type of a pattern synonym can be fully described with the following pieces of information: * If the pattern synonym is bidirectional * Universially-bound type variables, and required constraints on them * The type of the pattern itself, closed over the universially-bound type variables * Existentially-bound type variables, and the constraints provided by them * The types of the arguments, closed over the universially and existentially bound type variables Here's an example showing all of these axes in action: data T a b where MkT :: (Eq a, Ord b, Show c) = a - (b, b) - c - T a b pattern P x y = MkT 5 (y, True) x In this case: * The name of the pattern synonym is `P` * The pattern synonym is bidirectional * The universially-bound tyvars/required constraints are `forall a. Num a` * The type of the pattern is `T a Bool` * The existentially-bound tyvars/provided constraints are `forall c. (Eq a, Ord Bool, Show c)` * The type of the arguments are `c` and `Bool`. The problem, then, is finding a concrete syntax that captures all of this information. This syntax is needed for at least two purposes: * Showing pattern synonym type information in Haddock/GHCi * Pattern synonym type signatures (#8584) Current state of things --- GHCi 7.8.3 shows the type above as: pattern (Eq t, Ord Bool, Show c) = P c Bool :: Num t = (T t Bool) Not only does it not show directionality, I think this is very confusing in every other way as well, especially with explicit foralls: pattern forall c. (Eq t, Ord Bool, Show c) = P c Bool :: forall t. Num t = (T t Bool) I am currently working on implementing #8584, which means I need to parse these type signatures. I managed to get the above monstrosity to parse (unambigiously from actual pattern synonym definitions) by throwing in an extra 'type' keyword: pattern type (Eq t, Ord Bool, Show c) = P c Bool :: Num t = (T t Bool) Request for help Surely we can do better than that! So let's come up with a nice syntax for pattern synonym type signatures. It will be used in the pattern synonym type signature annotations of GHC 7.10, and we could also retrofit it into GHC 7.8.4 and its Haddock, so that documentation generated with today's tools will look consistent with code you will be able to enter in tomorrow's version. Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Trac
Hopping from one ticket to the next takes about 5 seconds for me. I call that very slow. Cheers, Gabor On 11/3/14, Simon Peyton Jones simo...@microsoft.com wrote: Is it just me, or is the GHC Trac soul-destroyingly slow at the moment? IT takes minutes to load one page! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC on Windows (extended/broad discussion)
Alright, based on the votes let's do Wednesday (Nov 5) 8:00pm. Sorry, forgot to specify the timezone: 8:00pm UTC. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problem with installing primitive on Windows/i686
Gintautas, I'm afraid I don't quite know what's going on immediately, but at a glance it seems to be some Cabal bug. I'm not quite sure why it specifically has the 'includes' directive set to primitive-memops.h, considering 'include-dirs' and 'c-sources' are set properly. Have you tried fiddling with any of these and seen any different behavior? On Sun, Nov 2, 2014 at 4:53 PM, Gintautas Miliauskas gintautas.miliaus...@gmail.com wrote: Installation of Alex in the msys2 i686 instructions is broken, more details in https://ghc.haskell.org/trac/ghc/ticket/9712. Before I spend more time on this, maybe someone knows off the bat what's going on? $ cabal install alex Resolving dependencies... Downloading primitive-0.5.4.0... Configuring primitive-0.5.4.0... Failed to install primitive-0.5.4.0 Build log ( C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log ): [1 of 1] Compiling Main ( C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs, C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o ) Linking C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe ... Configuring primitive-0.5.4.0... setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing dependency on a foreign library: * Missing (or bad) header file: primitive-memops.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. If the header file does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: Concrete syntax for pattern synonym type signatures
How about pattern type forall a. Num a = P :: forall c. (Eq a, Ord Bool, Show c) = c - Bool - T a Bool or pattern type forall a. Num a = P - forall c. (Eq a, Ord Bool, Show c) = c - Bool - T a Bool for a unidirectional pattern. (Note that `::` became `-`.) This resembles the syntax for GADT-style data constructors, but with the universal constraints listed. This may not be (much) better than the original form, but I like that it corresponds closely with at least one piece of existing syntax. Richard On Nov 3, 2014, at 5:13 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: Background -- As explained on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics the type of a pattern synonym can be fully described with the following pieces of information: * If the pattern synonym is bidirectional * Universially-bound type variables, and required constraints on them * The type of the pattern itself, closed over the universially-bound type variables * Existentially-bound type variables, and the constraints provided by them * The types of the arguments, closed over the universially and existentially bound type variables Here's an example showing all of these axes in action: data T a b where MkT :: (Eq a, Ord b, Show c) = a - (b, b) - c - T a b pattern P x y = MkT 5 (y, True) x In this case: * The name of the pattern synonym is `P` * The pattern synonym is bidirectional * The universially-bound tyvars/required constraints are `forall a. Num a` * The type of the pattern is `T a Bool` * The existentially-bound tyvars/provided constraints are `forall c. (Eq a, Ord Bool, Show c)` * The type of the arguments are `c` and `Bool`. The problem, then, is finding a concrete syntax that captures all of this information. This syntax is needed for at least two purposes: * Showing pattern synonym type information in Haddock/GHCi * Pattern synonym type signatures (#8584) Current state of things --- GHCi 7.8.3 shows the type above as: pattern (Eq t, Ord Bool, Show c) = P c Bool :: Num t = (T t Bool) Not only does it not show directionality, I think this is very confusing in every other way as well, especially with explicit foralls: pattern forall c. (Eq t, Ord Bool, Show c) = P c Bool :: forall t. Num t = (T t Bool) I am currently working on implementing #8584, which means I need to parse these type signatures. I managed to get the above monstrosity to parse (unambigiously from actual pattern synonym definitions) by throwing in an extra 'type' keyword: pattern type (Eq t, Ord Bool, Show c) = P c Bool :: Num t = (T t Bool) Request for help Surely we can do better than that! So let's come up with a nice syntax for pattern synonym type signatures. It will be used in the pattern synonym type signature annotations of GHC 7.10, and we could also retrofit it into GHC 7.8.4 and its Haddock, so that documentation generated with today's tools will look consistent with code you will be able to enter in tomorrow's version. Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: thenIO removal
Simon Peyton Jones wrote: It's not a big deal. You can probably replace both those bindIOName uses with bindMName (i.e (=)), in TcRnDriver. That will just make GHCi generate code with uses of overloaded (=) that must be evaluated, rather than calling bindIO directly. It should work just fine, but it'll make everything a tiny bit slower and more indirect. If it simplified the code a lot, then fine, but it doesn't really. So I'm inclined to leave it. That's fine; I don't know why my search didn't turn that up (perhaps it's referenced in some weird indirect way). If we're going to keep thenIO, we should surely define (*) = () = thenIO, right? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ghc panic during build
Just got this during a build:
inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O
-Werror -Wall -H64m -O0-this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ
-hide-all-packages -i -ilibraries/base/.
-ilibraries/base/dist-install/build
-ilibraries/base/dist-install/build/autogen
-Ilibraries/base/dist-install/build
-Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include
-optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include
-optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key
ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty
-package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint
-fno-warn-deprecated-flags -fno-warn-tabs -no-user-package-db -rtsopts
-odir libraries/base/dist-install/build -hidir
libraries/base/dist-install/build -stubdir
libraries/base/dist-install/build -c libraries/base/./GHC/TypeLits.hs -o
libraries/base/dist-install/build/GHC/TypeLits.o
ghc-stage1.exe: panic! (the 'impossible' happened)
(GHC version 7.9.20141031 for x86_64-unknown-mingw32):
Ix{Int}.index: Index (2053) out of range ((0,10))
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
libraries/base/ghc.mk:4: recipe for target
'libraries/base/dist-install/build/GHC/TypeLits.o' failed
I may have been building in a non-clean repository after a git pull though,
could that have caused this?
--
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: ghc panic during build
Usually this is to do with stale .hi files
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gintautas
Miliauskas
Sent: 03 November 2014 16:31
To: ghc-devs@haskell.org
Subject: ghc panic during build
Just got this during a build:
inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O
-Werror -Wall -H64m -O0-this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ
-hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build
-ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build
-Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include
-optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include
-optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key
ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty
-package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint
-fno-warn-deprecated-flags -fno-warn-tabs -no-user-package-db -rtsopts
-odir libraries/base/dist-install/build -hidir
libraries/base/dist-install/build -stubdir libraries/base/dist-install/build
-c libraries/base/./GHC/TypeLits.hs -o
libraries/base/dist-install/build/GHC/TypeLits.o
ghc-stage1.exe: panic! (the 'impossible' happened)
(GHC version 7.9.20141031 for x86_64-unknown-mingw32):
Ix{Int}.index: Index (2053) out of range ((0,10))
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
libraries/base/ghc.mk:4http://ghc.mk:4: recipe for target
'libraries/base/dist-install/build/GHC/TypeLits.o' failed
I may have been building in a non-clean repository after a git pull though,
could that have caused this?
--
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Major commit to the constraint solver
Friends I've pushed branch wip/new-flatten-skolems-Oct14. (It has some rebasing near the top.) It branches off master some a few days ago; i.e. it is almost completely up to date. Can you try building it? I want to push it to HEAD, but would like some independent validation first. Three things don't validate for me: * Several tests fail with ioManagerWakeup problems: reported as Trac #9722 * ghcirun002 experiences stack overflow in the bytecode interpreter, but so does HEAD: Trac #9741 * I get an odd wibble in safePk01, see this threadhttps://www.haskell.org/pipermail/ghc-devs/2014-November/007065.html with Edward I'd like to push to master soon. Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc panic during build
Try `make clean` in the libraries directory and then building again. I usually
need to run `make` twice in a row to build after cleaning the libraries.
On Nov 3, 2014, at 11:48 AM, Simon Peyton Jones simo...@microsoft.com wrote:
Usually this is to do with stale .hi files
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gintautas
Miliauskas
Sent: 03 November 2014 16:31
To: ghc-devs@haskell.org
Subject: ghc panic during build
Just got this during a build:
inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O
-Werror -Wall -H64m -O0-this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ
-hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build
-ilibraries/base/dist-install/build/autogen
-Ilibraries/base/dist-install/build
-Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include
-optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include
-optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key
ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty
-package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint
-fno-warn-deprecated-flags -fno-warn-tabs -no-user-package-db -rtsopts
-odir libraries/base/dist-install/build -hidir
libraries/base/dist-install/build -stubdir libraries/base/dist-install/build
-c libraries/base/./GHC/TypeLits.hs -o
libraries/base/dist-install/build/GHC/TypeLits.o
ghc-stage1.exe: panic! (the 'impossible' happened)
(GHC version 7.9.20141031 for x86_64-unknown-mingw32):
Ix{Int}.index: Index (2053) out of range ((0,10))
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
libraries/base/ghc.mk:4: recipe for target
'libraries/base/dist-install/build/GHC/TypeLits.o' failed
I may have been building in a non-clean repository after a git pull though,
could that have caused this?
--
Gintautas Miliauskas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Major commit to the constraint solver
Hi, Am Montag, den 03.11.2014, 17:28 + schrieb Simon Peyton Jones: I’ve pushed branch wip/new-flatten-skolems-Oct14. (It has some rebasing near the top.) It branches off master some a few days ago; i.e. it is almost completely up to date. Can you try building it? I want to push it to HEAD, but would like some independent validation first. Travis build branches automatically, and is already trying to build it: https://travis-ci.org/ghc/ghc/builds/39856856 It just finished, but it is not completely happy: Actual stderr output differs from expected: --- /dev/null 2014-11-03 17:30:32.067943898 + +++ ./indexed-types/should_compile/PushedInAsGivens.comp.stderr 2014-11-03 18:11:53.225519481 + @@ -0,0 +1,27 @@ + +PushedInAsGivens.hs:10:31: +Couldn't match expected type ‘a1’ with actual type ‘a’ + because type variable ‘a1’ would escape its scope +This (rigid, skolem) type variable is bound by + the type signature for foo :: (F Int ~ [a1]) = a1 - Int + at PushedInAsGivens.hs:9:20-44 +Relevant bindings include + x :: a1 (bound at PushedInAsGivens.hs:10:17) + foo :: a1 - Int (bound at PushedInAsGivens.hs:10:13) + y :: a (bound at PushedInAsGivens.hs:9:5) + bar :: a - (a, Int) (bound at PushedInAsGivens.hs:9:1) +In the expression: y +In the first argument of ‘length’, namely ‘[x, y]’ + +PushedInAsGivens.hs:11:15: +Couldn't match expected type ‘[a]’ with actual type ‘F Int’ +Relevant bindings include + y :: a (bound at PushedInAsGivens.hs:9:5) + bar :: a - (a, Int) (bound at PushedInAsGivens.hs:9:1) +In the expression: foo y +In the expression: (y, foo y) +In the expression: + let +foo :: (F Int ~ [a]) = a - Int +foo x = length [...] + in (y, foo y) = T2715(normal) 3281 of 4140 [0, 0, 0] *** unexpected failure for PushedInAsGivens(normal) Actual stdout output differs from expected: --- ./safeHaskell/check/pkg01/safePkg01.stdout 2014-11-03 17:30:57.327803827 + +++ ./safeHaskell/check/pkg01/safePkg01.run.stdout 2014-11-03 18:12:11.178706914 + @@ -29,17 +29,17 @@ require own pkg trusted: True M_SafePkg6 -package dependencies: array-0.5.0.1@array_HASH +package dependencies: array-0.5.0.1 base-4.8.0.0* trusted: trustworthy require own pkg trusted: False M_SafePkg7 -package dependencies: array-0.5.0.1@array_HASH +package dependencies: array-0.5.0.1 base-4.8.0.0* trusted: safe require own pkg trusted: False M_SafePkg8 -package dependencies: array-0.5.0.1@array_HASH +package dependencies: array-0.5.0.1 base-4.8.0.0 trusted: trustworthy require own pkg trusted: False *** unexpected failure for safePkg01(normal) Is there more you want us to do besides what Travis just did for us? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [GHC] #9358: Improve flag description in the user guide
Jan, you said you'd be willing to do this updating before 7.10 Yes, that's the plan. The question is do I have to make it before the mid-November feature freeze? Austin, what's your opinion? So far as I can see, there simply is no list of what is enabled by -O or -O2. I can make such a list if you want. It's more than a simple on/off thing because the order matters. Hmm in which cases does it matter? Can you give an example? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add GHC.Prim.oneShot (c271e32)
Perhaps this should be documented in the User's Guide? Janek Dnia niedziela, 2 listopada 2014, g...@git.haskell.org napisał: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/c271e32eac65ee95ba1aacc72ed1b24b5 8ef17ad/ghc --- commit c271e32eac65ee95ba1aacc72ed1b24b58ef17ad Author: Joachim Breitner m...@joachim-breitner.de Date: Sun Jan 26 11:36:23 2014 + Add GHC.Prim.oneShot to allow the programer to explictitly set the oneShot flag. This helps with #7994 and will be used in left folds. Also see https://ghc.haskell.org/trac/ghc/wiki/OneShot This commit touches libraries/base/GHC/Event/Manager.hs (which used to have a local definition of the name oneShot) to avoid a shadowing error. Differential Revision: https://phabricator.haskell.org/D392 --- c271e32eac65ee95ba1aacc72ed1b24b58ef17ad compiler/basicTypes/MkId.lhs | 42 -- compiler/prelude/PrelNames.lhs | 3 +- libraries/base/GHC/Event/Manager.hs| 6 ++-- libraries/ghc-prim/GHC/Magic.hs| 11 +- testsuite/.gitignore | 1 + .../should_compile = simplCore/prog003}/Makefile | 0 testsuite/tests/simplCore/prog003/OneShot1.hs | 21 +++ testsuite/tests/simplCore/prog003/OneShot2.hs | 24 + .../simplCore/prog003/simplCore.oneShot.stderr | 21 +++ .../simplCore/prog003/simplCore.oneShot.stdout | 1 + testsuite/tests/simplCore/prog003/test.T | 7 11 files changed, 130 insertions(+), 7 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc c271e32eac65ee95ba1aacc72ed1b24b58ef17ad ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add GHC.Prim.oneShot (c271e32)
Hi, Am Montag, den 03.11.2014, 20:20 +0100 schrieb Jan Stolarek: Perhaps this should be documented in the User's Guide? I don’t like having documentation scattered around, so I’d rather put all documentation in a singe place: The haddocks for this function. I should add a link to https://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html though. Done. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Resurrecting ticky code
Hi, I originally reported #8308 so I suppose I could help :-) But I need to find some time to take a look at your code - the ticket was reported over a year ago and I admit I don't remember much. I'll take a look at your patch soon (hopefully this week). Janek Dnia poniedziałek, 3 listopada 2014, Mateusz Lenik napisał: Hi *, Recently I started working on resurrecting ticky code[1] and got to the point where I can compile and run bumpHistogram as well as accompanying code in RTS. Work in progress version can be found at [2], but there are few things remaining to get it working: * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and tickyVectoredReturn need to be added. Unfortunately I'm not familiar with the code enough to find the right place to insert them. * magic eight needs to be replaced by a constant both Haskell and C files. Preprocessor macro seems to be the simplest choice here, however I don't find it the cleanest way to do it. I would be very grateful if someone could take a look and point me into the right direction. Best, Mateusz 1: https://ghc.haskell.org/trac/ghc/ticket/8308 2: https://github.com/mlen/ghc/compare/ticky ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Major commit to the constraint solver
Excerpts from Simon Peyton Jones's message of 2014-11-03 09:28:49 -0800: * I get an odd wibble in safePk01, see this threadhttps://www.haskell.org/pipermail/ghc-devs/2014-November/007065.html with Edward Hello Simon, Here's what you should do for the safePkg01 wibble: 1. Apply the attached patch to your tree (this will break the tests temporarily.) 2. Accept the new output for safePkg01 which no longer has the package keys in it. 3. Remove the noramliseArrayPackageKey goop from all.T I could do the changes myself but it's your branch so I don't want to touch it unduly. BTW, here is why your change removed the package keys: --show-iface previously pretty-printed as if -dppr-debug was always on. You touched this code so that --show-iface only prints in debug style if you actually asked for -dppr-debug; this changed the output of these tests. Edward 0001-Tweak-Safe-Haskell-test-to-show-iface-with-large-col.patch Description: Binary data ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Automating GHC build for Windows
Potentially related issues: https://github.com/haskell/cabal/issues/1698 https://ghc.haskell.org/trac/ghc/ticket/2924 https://ghc.haskell.org/trac/ghc/ticket/3231 https://ghc.haskell.org/trac/ghc/ticket/2650 On Mon, Nov 3, 2014 at 1:24 AM, Gintautas Miliauskas gintautas.miliaus...@gmail.com wrote: Without knowing much about the surrounding code, I would try two things here. 1. Is it possible that the file was opened by for writing and not closed because of lazy I/O? 2. Since the error is completely deterministic, you could try freezing evaluation right before the crash (either by a breakpoint in ghci or just adding a time delay / console read on the code), and then using a utility app http://serverfault.com/questions/1966/how-do-you-find-what-process-is-holding-a-file-open-in-windows to check which process is keeping the file open, whether it's the same process or something else. If any of the involved paths is a directory, this could be #8482 https://ghc.haskell.org/trac/ghc/ticket/8482, although that does not seem to be the case. On Thu, Oct 30, 2014 at 7:13 PM, Páli Gábor János pali.ga...@gmail.com wrote: 2014-10-30 16:24 GMT+01:00 Gintautas Miliauskas gintau...@miliauskas.lt : I wonder what's going on with DeleteFile. What is the step that's failing? Basically it happens at the same point, that is, at the configure phase but at the ghc-prim package. Note that the previously mentioned workaround has a removeFile action [1], I guess the failure of that triggers the DeleteFile exception. Can you post the log? inplace/bin/ghc-cabal.exe configure libraries/ghc-prim dist-install --with-ghc=C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-stage1.exe --with-ghc-pkg=C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-pkg.exe --flag=include-ghc-prim --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --enable-library-profiling --disable-shared --configure-option=CFLAGS= -U__i686 -march=i686 -fno-stack-protector --configure-option=LDFLAGS=--configure-option=CPPFLAGS= --gcc-options= -U__i686 -march=i686 -fno-stack-protector --with-gcc=C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe --with-ld=C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/ld.exe --configure-option=--with-cc=C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe --with-ar=/usr/bin/ar --with-alex=/usr/local/bin/alex --with-happy=/usr/local/bin/happy Configuring ghc-prim-0.3.1.0... ghc-cabal.exe: DeleteFile dist-install\\setup-config: permission denied (The process cannot access the file because it is being used by another process.) libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed I also wonder why this issue is not arising on other Windows machines... As the comment in the workaround goes, it has a Big fat hairy race condition. Therefore I am inclined to believe that it may be a problem for other systems as well, but I am the most unfortunate one who hits this error with 100% probability :-) [1] https://github.com/ghc/ghc/blob/master/libraries/bin-package-db/GHC/PackageDb.hs#L267 -- Gintautas Miliauskas -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
+ghc-devs Hi Ray, thanks for the feedback. ghc-stage1 is a native application, it is built using a host ghc and a mingw gcc bundled with the ghc distribution (in order to keep Windows builds more predictable). The thing is, the same builds (using make) that were stable on cygwin seem to be crashing on msys2, even though the (bundled) gcc used for the build is the same. It could be that msys2 is triggering a bug in ghc somehow, but it could be something going on in msys2 itself. The tricky part is that the crashes are rare, one in thousands of ghc invocations within a make build, and I'm having trouble pinning one down to investigate. I'll try some basic tracing first, but ideas for something more sophisticated would be very helpful. A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit tricky (some Haskell tools need to be preinstalled). I'm not sure how useful it would be since for Windows there is already a nicely packaged native Haskell Platform installer. On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly mingw.andr...@gmail.com wrote: On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas gintautas.miliaus...@gmail.com wrote: Hello, I have been working on building GHC, the Glasgow Haskell Compiler, on Windows using msys2 [1]. We have been having some strange trouble with ghc segfaulting during the bootstrapping process (i.e., during make). The crashes are not very hard to reproduce, but they are not predictable either. This is almost certainly a bug in ghc itself and not with msys2 (although the crashes do not seem to occur in other environments), but I've been having some trouble pinning it down. Hi Gintuatas, Great. I spotted that MSYS2 was the recommended env. for GHC on Windows, hopefully it will remain so! What's a good way to debug such crashes? Is it possible to somehow stop the ghc process when it segfaults and attach gdb, or to dump core somehow for later inspection? [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Here's one example crash: inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-this-package-key ghc_4ugNArSu5ba0Z1uHXrbTlU -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key array_GX4NwjS8xZkC2ZPtjgwhnz -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key binpa_17GphrLqCXt1H1lm4Kse1p -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_HU5aFxMIQNwGQFzisjuinu -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key hpc_1QTsfQSN40FHN9p3mydARY -package-key proce_7ZlAbRkwiRO8qgXx3NNP0G -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key time_HGs4JcQCd4wF6U8vJQ5fNH -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2 -fwarn-tabs -O -dcore-lint -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/basicTypes/UniqSupply.lhs -o compiler/stage2/build/UniqSupply.o compiler/ghc.mk:657: recipe for target 'compiler/stage2/build/UniqSupply.o' failed make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation fault Well, it's pretty much the same story as with Linux. Build the executable and as many libraries as you can with (something like) -ggdb -O0 then use gdb command line or some IDE of choice. Personally I use Qt Creator (we have packages for this) as it can debug external programs and, even though I don't dislike command lines, I find debugging from them a bit too masochistic. Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is it built with exactly? What would be involved in creating a PKGBUILD for ghc? We'd love to have one, and it'd certainly make me a lot more inclined to dive in to see what's going on if one existed already. Ray. -- Gintautas Miliauskas --
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 0:07, Gintautas Miliauskas wrote: A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit tricky (some Haskell tools need to be preinstalled). I'm not sure how useful it would be since for Windows there is already a nicely packaged native Haskell Platform installer. It definitely helps MSYS2 users by providing an easily installable ghc package. That in turn could help with setting up ghc development environment. Hopefully after Windows ghc migrates to gcc 4.8, ghc package will be able to use the MSYS2 packaged toolchain to reduce duplication. I have this so far, but I give no guarantees: https://github.com/elieux/MINGW-packages/tree/ghc To use: - download ghc and put it in PATH - optionally alter ghc/lib/settings to use MSYS2 toolchain instead of the bundled one (see below) - use cabal-install PKGBUILD to build Cabal and put it in PATH - use built Cabal to download and build Alex and Happy and put them in PATH (I think they're installed somewhere inside AppData by default) - run ghc PKGBUILD Related: https://www.haskell.org/pipermail/ghc-devs/2014-October/006759.html My ghc/lib/settings (from version 7.6.3): [(GCC extra via C opts, -fwrapv), (C compiler command, gcc.exe), (C compiler flags, -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads), (ar command, ar.exe), (ar flags, q), (ar supports at file, YES), (touch command, $topdir/touchy.exe), (dllwrap command, dllwrap.exe), (windres command, windres.exe), (perl command, perl.exe), (target os, OSMinGW32), (target arch, ArchX86_64), (target word size, 8), (target has GNU nonexec stack, False), (target has .ident directive, True), (target has subsections via symbols, False), (LLVM llc command, ), (LLVM opt command, ) ] -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
On 4. 11. 2014 1:05, Gintautas Miliauskas wrote: Nice! This needs a host ghc (with alex and happy) preinstalled, correct? Maybe I misunderstood, but the answer should be clear from my message. Yes, the ghc PKGBUILD expects working ghc, alex and happy in PATH. ghc has to be downloaded (until an MSYS2 package becomes available), cabal can be built using cabal-install PKGBUILD and alex and happy can then be downloaded and built using cabal. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
I have a suspicion that the segmentation faults are related to fork errors,
which appear in logs from time to time. After a few builds fork() errors
become very frequent, and segfaults seem to occur more often. I just ran
the build (validate.sh) in a loop, and after a while got a bunch of
segfaults in Makefile rules as basic as rm invocations in the initial make
clean, e.g.:
rm -rf driver/split/dist
driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist' failed
make[1]: *** [clean_driver/split_dist] Segmentation fault
Makefile:94: recipe for target 'maintainer-clean' failed
Closing and reopening the msys2 console seems to help - for some time.
On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly mingw.andr...@gmail.com
wrote:
On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas
gintautas.miliaus...@gmail.com wrote:
+ghc-devs
Hi Ray,
thanks for the feedback. ghc-stage1 is a native application, it is built
using a host ghc and a mingw gcc bundled with the ghc distribution (in
order
to keep Windows builds more predictable). The thing is, the same builds
(using make) that were stable on cygwin seem to be crashing on msys2,
even
though the (bundled) gcc used for the build is the same. It could be that
msys2 is triggering a bug in ghc somehow, but it could be something
going on
in msys2 itself.
The tricky part is that the crashes are rare, one in thousands of ghc
invocations within a make build, and I'm having trouble pinning one down
to
investigate. I'll try some basic tracing first, but ideas for something
more
sophisticated would be very helpful.
Ah, ok. I skim read your initial email and applied totally incorrect
weighting to the not very hard to reproduce bit, apologies!
It *should* be possible to setup post-mortem debugging using either Qt
Creator (Tools-Options-Debugger, tick Use Qt Creator for
post-mortem debugging) or Dr. Mingw
(https://github.com/jrfonseca/drmingw). I briefly tested both options:
Qt Creator: It seems there's a bug in its handling of the
-wincrashevent command line which I've just added a note about to the
MINGW-packages todo list since I'd find this feature more than very
useful:
https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md
Dr Mingw: Launching the crashing executable from Windows Explorer, it
launches it and gives me useful information.
Unfortunately, regardless of the debugger used, when invoking the
crashing executable from the mintty commandline, something inhibits
all post mortem debugging. I will ask the mingw-w64 guys if they know
what this is. I guess intrusive dialogs would be annoying, but I'd
like an env. var override for that I think.
There is another possibility, and that's that bash is crashing, which
is an MSYS2 program. We do have a way of hooking into post-mortem
debugging there since Cygwin provided a way and we improved it. If you
check your msys2_shell.bat you'll see:
rem set
MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|process-id
If you remove the rem and make sure the path is correct (it may have
rotted some since I last used it) then hopefully you'll get something
useful. To be really useful, you should rebuild two packages,
MSYS2-packages/{msys2-runtime,bash}/PKGBUILD with
options=('debug' '!strip')
and then install them.
Finally, can anyone else confirm the problem?
There may be some edge cases when e.g. PATH is around 1024 characters,
I've seen some hardcoded limits in the msys2-runtime (nee Cygwin)
code base for things like that. I'd advise cutting your Windows PATH
down to just the essentials.
Cheers,
Ray.
A PKGBUILD for ghc should be feasible, although the bootstrapping is a
bit
tricky (some Haskell tools need to be preinstalled). I'm not sure how
useful
it would be since for Windows there is already a nicely packaged native
Haskell Platform installer.
On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly mingw.andr...@gmail.com
wrote:
On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas
gintautas.miliaus...@gmail.com wrote:
Hello,
I have been working on building GHC, the Glasgow Haskell Compiler, on
Windows using msys2 [1]. We have been having some strange trouble with
ghc
segfaulting during the bootstrapping process (i.e., during make). The
crashes are not very hard to reproduce, but they are not predictable
either.
This is almost certainly a bug in ghc itself and not with msys2
(although
the crashes do not seem to occur in other environments), but I've been
having some trouble pinning it down.
Hi Gintuatas,
Great. I spotted that MSYS2 was the recommended env. for GHC on
Windows, hopefully it will remain so!
What's a good way to debug such crashes? Is it possible to somehow
stop
the
ghc process when it segfaults and attach gdb, or to dump core somehow
for
later inspection?
[1]
Re: [GHC] #9358: Improve flag description in the user guide
For updating the users guide, no, I don't think hitting the freeze is really necessary. We're mostly worried about big features as opposed to big documentation upgrades. So do please take your time and let me know what to merge if you don't get it done by then. On Mon, Nov 3, 2014 at 12:57 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Jan, you said you'd be willing to do this updating before 7.10 Yes, that's the plan. The question is do I have to make it before the mid-November feature freeze? Austin, what's your opinion? So far as I can see, there simply is no list of what is enabled by -O or -O2. I can make such a list if you want. It's more than a simple on/off thing because the order matters. Hmm in which cases does it matter? Can you give an example? Janek -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Major commit to the constraint solver
I've done a validate on my Mac. Here is the output (indented), with comments (outdented): ../../libraries/base/tests/IO hReady002 [bad stderr] (normal) Succeeded on a later run cabal/cabal01 cabal01 [bad exit code] (normal) Wrong exit code (expected 0 , actual 2 ) Stdout: install1: bin lib install2: bin lib Stderr: tar: --format: Cannot stat: No such file or directory tar: ustar: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. make[2]: *** [cabal01] Error 1 *** unexpected failure for cabal01(normal) cabal/cabal06 cabal06 [bad stdout] (normal) Actual stdout output differs from expected: --- ./cabal06/cabal06.stdout2014-11-03 13:23:21.0 -0500 +++ ./cabal06/cabal06.run.stdout2014-11-03 20:00:56.0 -0500 @@ -1,7 +1,7 @@ Does the first instance of q depend on p-1.0? -1 + 1 Does the second instance of q depend on p-1.0? -1 + 1 Configuring r-1.0... Configuring r-1.0... 10 *** unexpected failure for cabal06(normal) driver/objcobjc-hi [exit code non-0] (normal) driver/objcobjcpp-hi [exit code non-0] (normal) driver/sigof02 sigof02dmt [bad stderr] (normal) These three are almost certainly not related to your work. indexed-types/should_compile PushedInAsGivens [stderr mismatch] (normal) Actual stderr output differs from expected: --- /dev/null 2014-11-03 20:06:19.0 -0500 +++ ./PushedInAsGivens.comp.stderr 2014-11-03 20:06:21.0 -0500 @@ -0,0 +1,27 @@ + +PushedInAsGivens.hs:10:31: +Couldn't match expected type ‘a1’ with actual type ‘a’ + because type variable ‘a1’ would escape its scope +This (rigid, skolem) type variable is bound by + the type signature for foo :: (F Int ~ [a1]) = a1 - Int + at PushedInAsGivens.hs:9:20-44 +Relevant bindings include + x :: a1 (bound at PushedInAsGivens.hs:10:17) + foo :: a1 - Int (bound at PushedInAsGivens.hs:10:13) + y :: a (bound at PushedInAsGivens.hs:9:5) + bar :: a - (a, Int) (bound at PushedInAsGivens.hs:9:1) +In the expression: y +In the first argument of ‘length’, namely ‘[x, y]’ + +PushedInAsGivens.hs:11:15: +Couldn't match expected type ‘[a]’ with actual type ‘F Int’ +Relevant bindings include + y :: a (bound at PushedInAsGivens.hs:9:5) + bar :: a - (a, Int) (bound at PushedInAsGivens.hs:9:1) +In the expression: foo y +In the expression: (y, foo y) +In the expression: + let +foo :: (F Int ~ [a]) = a - Int +foo x = length [...] + in (y, foo y) *** unexpected failure for PushedInAsGivens(normal) llvm/should_compileT5486 [stderr mismatch] (optllvm) llvm/should_compileT5681 [stderr mismatch] (optllvm) llvm/should_compileT7571 [stderr mismatch] (optllvm) These seem to be some clang misconfiguration. perf/compiler T4801 [stat too good] (normal) perf/compiler T5631 [stat not good enough] (normal) rtsT5435_dyn_asm [bad stdout] (normal) These three have been failing on and off for a while. safeHaskell/check/pkg01safePkg01 [bad stdout] (normal) Edward addressed this one, I believe. So, it seems the one real hit is the one you were expecting -- that's good. Unfortunately, we also see that validation on a Mac doesn't work so well these days. My experience is that there's usually a few failing tests, but not nearly this many. Perhaps it's a sign of the success of the Travis/Harbormaster validation runs that folks aren't validating at home, lessening the pressure to keep clean validation on a variety of platforms. Anyway, I hope this is helpful. Richard On Nov 3, 2014, at 4:23 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Simon Peyton Jones's message of 2014-11-03 09:28:49 -0800: * I get an odd wibble in safePk01, see this threadhttps://www.haskell.org/pipermail/ghc-devs/2014-November/007065.html with Edward Hello Simon, Here's what you should do for the safePkg01 wibble: 1. Apply the attached patch to your tree (this will break the tests temporarily.) 2. Accept the new output for safePkg01 which no longer has the package keys in it. 3. Remove the noramliseArrayPackageKey goop from all.T I could do the changes myself but it's your branch so I don't want to touch it unduly. BTW, here is why your change removed the package keys: --show-iface previously pretty-printed as if -dppr-debug was always on. You touched this code so that --show-iface only prints in debug style if you actually asked for -dppr-debug; this changed the output of these tests. Edward 0001-Tweak-Safe-Haskell-test-to-show-iface-with-large-col.patch___ ghc-devs mailing list ghc-devs@haskell.org
Re: Major commit to the constraint solver
On Mon, Nov 3, 2014 at 8:11 PM, Richard Eisenberg e...@cis.upenn.edu wrote: Stderr: tar: --format: Cannot stat: No such file or directory tar: ustar: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. make[2]: *** [cabal01] Error 1 Apple got rid of gnutar, it's now libarchive tar. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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 the timeout computed from the Haskell call. On my current (OSX) machine my test case overflows struct timeval, causing select to return EINVAL and crash the runtime. Unfortunately, there appears to be no portable to find the maximum size of time_t/suseconds_t (the types of the struct timeval fields), and therefore no portable way to avoid this overflow. The most practical thing I can think of is to add a configure case that checks sizeof(time_t) and sizeof(suseconds_t) and guesses they're just unsigned values of the relevant type, but I'm open to better suggestions. Alternatively, the solution is to hardcode the max value for every platform, in which case I avoid you all to tell me the maximum value on your specific platform :p Cheers, Merijn ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Problem with select(2) in single threaded runtime.
Worse, it appears the maximum size of time_t is unrelated to the maximum value accepted by select(2). After diving into my system's header files time_t appears to be 'long', but a timeout of INT_MAX seconds already triggers EINVAL. At this point, the only option I see is to verify the max 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...@inconsistent.nl wrote: 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 the timeout computed from the Haskell call. On my current (OSX) machine my test case overflows struct timeval, causing select to return EINVAL and crash the runtime. Unfortunately, there appears to be no portable to find the maximum size of time_t/suseconds_t (the types of the struct timeval fields), and therefore no portable way to avoid this overflow. The most practical thing I can think of is to add a configure case that checks sizeof(time_t) and sizeof(suseconds_t) and guesses they're just unsigned values of the relevant type, but I'm open to better suggestions. Alternatively, the solution is to hardcode the max value for every platform, in which case I avoid you all to tell me the maximum value on your specific platform :p Cheers, Merijn ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
