GHC error message on type mismatch
Hello, I don't know if I'm the only one struggeling with this GHC error message on type mismatches or it's because I'm not a full time Haskeller, or because I'm not a native english speaker. Couldn't match type `A' with `B´ Expected type: B Actual type: A My problem is with 'Expected' and 'Actual', that I'm often unsure if the compiler is expecting something or if I'm the expecting one and the same goes for actual. I know that the compiler is the expecting one and that I'm given the actual thing, but it's quite often that I'm looking at this error and have to repeat this reasoning. It's strange, because normaly I can memorize such things quite good, but this one bothers me. Perhaps it would be easier for myself if 'Actual type' would be called e.g. 'Given type', I don't know, that just one of the two has a less generic meaning. Greetings, Daniel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
windows agiain
Austin I'm crashing in the testsuite as below. On Windows with the new msys. Any ideas? How do I set my Windows terminal type? Simon python2 ../../../driver/runtests.py -e ghc_compiler_always_flags='-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts ' -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=0 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir=../../../config' -e 'config.compiler=C:/code/HEAD/inplace/bin/ghc-stage1.exe' -e 'config.ghc_pkg=C:/code/HEAD/inplace/bin/ghc-pkg.exe' -e 'config.hp2ps=C:/code/HEAD/inplace/bin/hp2ps.exe' -e 'config.hpc=C:/code/HEAD/inplace/bin/hpc.exe' -e 'config.gs=gs' -e 'config.platform=i386-unknown-mingw32' -e 'config.os=mingw32' -e 'config.arch=i386' -e 'config.wordsize=32' -e 'default_testopts.cleanup=' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog=../../../timeout/install-inplace/bin/timeout.exe' -e 'config.exeext=.exe' -e 'config.top=C:/code/HEAD/testsuite' \ --only=T8037 \ \ \ \ \ \ Traceback (most recent call last): File ../../../driver/runtests.py, line 144, in module raise Exception(Can't detect Windows terminal type) Exception: Can't detect Windows terminal type ../../../mk/test.mk:242: recipe for target 'test' failed make: *** [test] Error 1 should_compile $ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Possible bug related to stm and exceptions
Hi all, Thanks so much for everyone's responses! I finally found the problem, so I thought I'd follow up and share what happened... It turned out that the problem was not in the STM implementation, but rather in bad programming on my part. For some reason, I had a thread (thread #1) performing a transaction that blocked until any one of several TQueues become non-empty. On success, the thread sent a value onto another TQueue monitored by some another thread (thread #2). Thread #2 would then process all the items in the queues monitored by the first thread. This lead to the following problem: when one of the TQueues became non-empty, the first thread would just go through its loop repeatedly, filling the other queue with values, and thread #2 wouldn't get a chance to run for a long time. This quickly lead to huge amounts of memory being used and the program would get totally bogged down. I finally found the problem when I noticed that I could make the problem less severe with -C0 and more severe with large values for -C. Large values let the first thread repeat the loop for a longer time before the second thread is scheduled and removes values from the queues. -Andi On Thu, Oct 17, 2013 at 10:53 AM, Andreas Voellmy andreas.voel...@gmail.com wrote: Thanks! I'll try to reduce my test case and then I'll post an issue. I'm currently suspecting that it has something to do with signal handling and STM. It seems that the program goes wrong after getting a SIGPIPE from trying to send to a closed socket. On Thu, Oct 17, 2013 at 9:35 AM, Ryan Yates fryguy...@gmail.com wrote: The bug that Luite and I uncovered is http://ghc.haskell.org/trac/ghc/ticket/7930. It would not be related. There was a bug relating to `catchSTM` that was fixed recently: http://ghc.haskell.org/trac/ghc/ticket/8035. And another related to profiling: http://ghc.haskell.org/trac/ghc/ticket/8298. I doubt either of these is related. I'm happy to help narrow things down. Ryan On Thu, Oct 17, 2013 at 4:39 AM, Simon Marlow marlo...@gmail.com wrote: On 17/10/2013 03:01, Andreas Voellmy wrote: Hi all, I have a program that uses STM heavily and also performs lots of foreign calls. I've noticed that sometimes the program uses 100% CPU indefinitely and uses lots of memory - I see it go up to about 5GB before I kill it. I've grabbed some preliminary samples of stack traces and see lots stm related stuff (e.g. lots of stg_atomically_frame_info and stmCommitTransaction entries). I can pretty reliably get the behavior to happen now by closing a socket that my Haskell program is trying to recv from. When this causes an exception to be raised (something like recv: resource vanished (Connection reset by peer)) , then this behavior gets triggered. I haven't pinned down the bug yet, but I'm suspecting it is STM related - somehow the exception causes some STM transaction to go wrong. Are there any known bugs that sound similar to this? BTW, this is with GHC 7.6.3 from a recent HP release on OS X. Please create a ticket and dump all the information you have in it. There might be something we can tell from the stack trace, but if not we'll need a way to reproduce it. Cheers, Simon ___ 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: Unicode quotes
On 2013-09-04 at 09:24:38 +0200, Kazu Yamamoto (山本和彦) wrote: GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks. Why do you guys decide this behavior change? I'm just curious. seems to be due to http://ghc.haskell.org/trac/ghc/ticket/2507 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Thanks for the reminder. Wiki is updated; atomics branch is merged. The only further work I plan to do in the near term is add additional tests. On Wed, Sep 4, 2013 at 9:52 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions*. In each case could you update the wiki with the current state of play, and your intentions, including dates. * That is, don’t put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 *Also : What is missing from the list that should be done?* **· ***Patrick Palka*: status of ghc –make –j? **· ***Nick*: status of your three items? **· ***Pedro/Richard*: is all the Typeable stuff, and gcast and friends, finished? **· ***Geoff*: what about the new Template Haskell story? **· ***Iavor*: when do you think you can merge? **· ***Austin*: what about ARMv7? **· ***Edsko/Thomas/Luite*: if you want anything for 7.8 it’ll have to be jolly soon. At the moment I don’t even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? **· ***Dynamic GHCi*. I have no idea who is driving this, or how important it is. **· ***Ryan*: atomic stuff. All merged? **· ***AMP warnings*: David Luposchainsky is driving this. ** ** Thanks! Simon *Microsoft Research Limited (company number 03369488) is registered in England and Wales * *Registered office is at 21 Station Road, Cambridge, CB1 2FB* ** ** ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHC 7.8 release status
I do need more than a patch, please, please. A wiki page explaining the design, as seen by the user (of the GHC API), the problems it solves, and the use-cases it enables, would be most helpful. Simon | -Original Message- | From: Thomas Schilling [mailto:nomin...@googlemail.com] | Sent: 04 September 2013 17:26 | To: Simon Peyton-Jones; Luite Stegeman | Cc: Nicolas Frisby; Pedro Magalhães (drei...@gmail.com); Richard | Eisenberg (e...@cis.upenn.edu); Geoffrey Mainland | (mainl...@cs.drexel.edu); Iavor Diatchki; Austin Seipp; Edsko de Vries; | Ryan Newton (rrnew...@gmail.com); David Luposchainsky; ghc- | d...@haskell.org | Subject: Re: GHC 7.8 release status | | | On 4 Sep 2013, at 15:52, Simon Peyton-Jones simo...@microsoft.com | wrote: | | Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be | jolly soon. At the moment I don't even know the motivation or design, | let alone implementation. Could you make a wiki page explaining the | proposed design? Is it really important to do this for 7.8? | | Yes, it is quite important to get this into 7.8. Not having these | features in GHC makes it very difficult for people to adopt GHCJS. One | could argue that GHCJS is not yet production-ready anyway and users that | want to try it can figure out building GHC from source to use it, but | this doesn't quite apply. | | 1. GHCJS targets a wider audience than users brave enough to compile | GHC from source. In addition, the next chance to get these features into | GHC is in a year from now, so when GHCJS becomes more mature then this | will be a major hurdle for adoption. | | 2. These changes are also required for IDE tools which really mustn't | require users to build a custom version of GHC. | | | Luite's design is actually very flexible. It simply allows GHC API | users to provide functions that are called instead of (or in addition | to) existing functions in GHC. Instead of calling, say, genHardCode, | the driver now looks up whether the user has specified a hook for | genHardCode and calls that instead. | | Currently we only specify a small number of hooks that are sufficient | for our use cases. Future releases of GHC can be extended to include | more hooks, if that is needed. | | Hooks are stored as an untyped map inside the DynFlags (to avoid issues | with circular dependencies). Each hook is looked up using a single- | constructor type and type families are used to make this type safe. | There is one use of unsafeCoerce to avoid having to make every hook | function an instance of Typeable. | | Unlike CorePlugins, it is only a GHC API feature, and users cannot | specify plugins to be added via command line options. If we can come up | with a good design, then we could add this in GHC 7.10, but it is not | necessary at this point. | | Luite: Do you have a link to your latest patch? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows validate failure
On 2013-09-22 at 15:59:01 +0200, Simon Peyton-Jones wrote: My latest Windows validate fell over as below, with some kind of Python failure (ie not just a failing test). It worked fine couple of days ago. Does anyone have any ideas of what might be going on? Seems to be caused by this: https://github.com/ghc/testsuite/commit/36a70ba030b86fb5db923b60dde852287291dba2#L3R824 (alas, I can't fix it right now myself) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Thank you Ryan! I'll be getting my ARMv7 build machine back online today, hopefully. Jens Peterson reported he had a working ARMv7 build to me today from HEAD, which is good news. On Wed, Sep 4, 2013 at 10:15 AM, Ryan Newton rrnew...@gmail.com wrote: Thanks for the reminder. Wiki is updated; atomics branch is merged. The only further work I plan to do in the near term is add additional tests. On Wed, Sep 4, 2013 at 9:52 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don’t put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? · Patrick Palka: status of ghc –make –j? · Nick: status of your three items? · Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? · Geoff: what about the new Template Haskell story? · Iavor: when do you think you can merge? · Austin: what about ARMv7? · Edsko/Thomas/Luite: if you want anything for 7.8 it’ll have to be jolly soon. At the moment I don’t even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? · Dynamic GHCi. I have no idea who is driving this, or how important it is. · Ryan: atomic stuff. All merged? · AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cabal-1.18.1.1 released
Hello Johan, On 2013-10-16 at 01:00:17 +0200, Johan Tibell wrote: I've released Cabal-1.18.1.1, which requires the fixes needed for the GHC 7.8 release. Please update the submodule to point to the Cabal-v1.18.1.1 tag. Done: http://git.haskell.org/ghc.git/commitdiff/0a80baa559be5d107f96cb25197e4a50aa6ebce4 Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC 7.8 release status
Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don't put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? · Patrick Palka: status of ghc -make -j? · Nick: status of your three items? · Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? · Geoff: what about the new Template Haskell story? · Iavor: when do you think you can merge? · Austin: what about ARMv7? · Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be jolly soon. At the moment I don't even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? · Dynamic GHCi. I have no idea who is driving this, or how important it is. · Ryan: atomic stuff. All merged? · AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
By the way, the parallel IO manager is also new in 7.8 right? I'm not sure but I think it may have something to do with the excessive system time bug I just filed: http://ghc.haskell.org/trac/ghc/ticket/8224 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC HEAD vs Hackage, panic-free edition
On Sun, Oct 13, 2013 at 2:14 AM, Michael Snoyman mich...@snoyman.comwrote: The issue with yesod-core was an issue from the underlying hamlet package. hamlet has some internal functions which are used by the TH-generated code it produces, and those internal functions were not previously exported. With previous versions of GHC, this wasn't a problem, though 7.8 seems to have an issue with it. Is this an intended change? I wouldn't know, porque yo no hablo el idioma del diablo llamado TH :-) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
