Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-, citeproc / highlighting-kate
Dear Devs, On 04/10/2014 09:09 AM, ghc-devs-requ...@haskell.org wrote: Filed the reproducer as a new ticket: https://ghc.haskell.org/trac/ghc/ticket/8980 [ Looks like highlighting-kate asks to be added to compiler performance benchmarks (are there such ones?) It tends to stress ghc all the time: http://hackage.haskell.org/trac/ghc/ticket/3664 ] Please consider adding hPDB too, if you want to stress the optimizer. It shows GHC optimizer at its best, with at least 10-20% improvement in every major version of the compiler since 6.12. Unfortunately at cost of very long compile times. Please let me know if I should submit a driver code for automatic benchmarks it (it is in hPDB-examples.) Thanks! SpecConstr is too aggressive: it sometimes blows up the program badly and we have no good solution. See Trac #7898, #7068, #7944, #5550, #8836. And #8960, where GHC runs out of memory. (Only in 7.8.) Should be easy to reproduce by just `cabal install hPDB`. I notice that the latter three are actually fixed in 7.8, so worth trying that. If it still fails, do add instructions to reproduce to one of the above open tickets, or make a new one. Meanwhile you can use -fno-spec-constr to simply switch it off for offending modules. That should get you going. -- Best regards Michal ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Breaking bug in 7.8.1
Austin, Simon (and others) As you'll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it seems to matter. (Because of the windows seg-fault saga, RC2 was active for a long time, and none of our regression tests showed up this bug.) It looks to me that we have little choice but to push out 7.8.2, more or less immediately, and advise everyone to ignore 7.8.1.Do you agree? Sorry about this. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
64bit Solaris was: Re: 7.8.1 plan
Hi, I've tried to cross-compile https://ghc.haskell.org/trac/ghc/ticket/8910 but did not succeed, yet. There seem to be problems with Int64 and/or Word data types. The proper start would be to make a careful comparison of the test-suite results, but there are already failures for the 32bit version (under Solaris 10). Unfortunately I don't have time to look into it further. Cheers Christian Am 09.04.2014 16:49, schrieb Pavel Ryzhov: Hi Karel, That is great! Do you know if there any plans for 64-bit build of GHC for Solaris 11? Regards, Pavel On 09 Apr 2014, at 10:49, Karel Gardas karel.gar...@centrum.cz wrote: Hi Pavel, I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs. Solaris 2.10: https://app.box.com/s/s1bysqga0x5f3itysu7g https://app.box.com/s/fbfki0szetnp4pghpeuk Solaris 2.11: https://app.box.com/s/zstci63pt10t4yix74s8 https://app.box.com/s/9375dyx8hwu9cnox2lgi The first link is binary tarball while the second is sha256. Karel On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: Hi, I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than. https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 Regards, Pavel Ryzhov On 08 Apr 2014, at 21:39, Carter Schonwald carter.schonw...@gmail.com mailto:carter.schonw...@gmail.com wrote: ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János pali.ga...@gmail.com mailto:pali.ga...@gmail.com wrote: 2014-04-08 15:28 GMT+02:00 Austin Seipp aus...@well-typed.com mailto:aus...@well-typed.com: Feel free to make builds - I'll add them as they come in and will announce soon... The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual: http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html ___ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org mailto: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 ___ 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: Proposal: Partial Type Signatures - Status update
Hi, I'm back with a status update. We implemented Austin's suggestion to make wildcards in partial type signatures behave like holes. Let's demonstrate the new behaviour with an example. The example program: module Example where foo :: (Show _a, _) = _a - _ foo x = show (succ x) Compiled with GHC master gives: Example.hs:3:18: parse error on input ‘_’ When we compile it with our branch: Example.hs:3:18: Instantiated extra-constraints wildcard ‘_’ to: (Enum _a) in the type signature for foo :: (Show _a, _) = _a - _ at Example.hs:3:8-30 The complete inferred type is: foo :: forall _a. (Show _a, Enum _a) = _a - String To use the inferred type, enable PartialTypeSignatures Example.hs:3:30: Instantiated wildcard ‘_’ to: String in the type signature for foo :: (Show _a, _) = _a - _ at Example.hs:3:8-30 The complete inferred type is: foo :: forall _a. (Show _a, Enum _a) = _a - String To use the inferred type, enable PartialTypeSignatures Now the types the wildcards were instantiated to are reported. Note that `_a` is still treated as a type variable, as prescribed in Haskell 2010. To treat it as a /named wildcard/, we pass the -XNamedWildcards flag and get: [..] Example.hs:3:24: Instantiated wildcard ‘_a’ to: tw_a in the type signature for foo :: (Show _a, _) = _a - _ at Example.hs:3:8-30 The complete inferred type is: foo :: forall tw_a. (Show tw_a, Enum tw_a) = tw_a - String To use the inferred type, enable PartialTypeSignatures [..] An extra error message appears, reporting that `_a` was instantiated to a new type variable (`tw_a`). Finally, when passed the -XPartialTypeSignatures flag, the typechecker will just use the inferred types for the wildcards and compile the program without generating any error messages. We added this example and a section about the monomorphism restriction to the wiki page [1]. Comments and feedback are still welcome. Cheers, Thomas Winant [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 64bit Solaris was: Re: 7.8.1 plan
Hi, thanks to an advice put by Alain (cced), I've grabbed the copy of SmartOS and installed GHC there. It looks like this package is AMD64 based. I've then moved it to my Solaris 11.1 and it runs fine and compile the code well: $ ghc --make HelloWorld.lhs [1 of 1] Compiling Main ( HelloWorld.lhs, HelloWorld.o ) Linking HelloWorld ... $ ./HelloWorld Hello world! $ file HelloWorld HelloWorld: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped $ ldd HelloWorld libiconv.so.2 = /opt/local/lib/libiconv.so.2 libgmp.so.10 = /opt/local/lib/libgmp.so.10 libm.so.2 = /lib/64/libm.so.2 librt.so.1 = /lib/64/librt.so.1 libdl.so.1 = /lib/64/libdl.so.1 libc.so.1 = /lib/64/libc.so.1 libumem.so.1 = /lib/64/libumem.so.1 libgcc_s.so.1 = /opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1 Well, so this is IMHO a easier way to bootstrap GHC HEAD on Solaris/AMD64. I currently do not have a time to deal with it, but hopefully will find some during the weekend -- well, if nobody is faster, otherwise I will devote my weekend ghc hobby time to SPARC NCG debugging. :-) Cheers, Karel On 04/10/14 09:39 AM, Christian Maeder wrote: Hi, I've tried to cross-compile https://ghc.haskell.org/trac/ghc/ticket/8910 but did not succeed, yet. There seem to be problems with Int64 and/or Word data types. The proper start would be to make a careful comparison of the test-suite results, but there are already failures for the 32bit version (under Solaris 10). Unfortunately I don't have time to look into it further. Cheers Christian Am 09.04.2014 16:49, schrieb Pavel Ryzhov: Hi Karel, That is great! Do you know if there any plans for 64-bit build of GHC for Solaris 11? Regards, Pavel On 09 Apr 2014, at 10:49, Karel Gardas karel.gar...@centrum.cz wrote: Hi Pavel, I've too built binary dist for Solaris 11 and Solaris 10. The advantage of Solaris 11 build is that it supports shared libs and is built using system provided gmp and ffi libs. Solaris 2.10: https://app.box.com/s/s1bysqga0x5f3itysu7g https://app.box.com/s/fbfki0szetnp4pghpeuk Solaris 2.11: https://app.box.com/s/zstci63pt10t4yix74s8 https://app.box.com/s/9375dyx8hwu9cnox2lgi The first link is binary tarball while the second is sha256. Karel On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote: Hi, I made Solaris 11 x86 bindist. It seems to be working fine. I will try to make IPS package later than. https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2 sha256: 268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2 Regards, Pavel Ryzhov On 08 Apr 2014, at 21:39, Carter Schonwald carter.schonw...@gmail.com mailto:carter.schonw...@gmail.com wrote: ok, did a sha256 on my bindist 98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2 On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János pali.ga...@gmail.com mailto:pali.ga...@gmail.com wrote: 2014-04-08 15:28 GMT+02:00 Austin Seipp aus...@well-typed.com mailto:aus...@well-typed.com: Feel free to make builds - I'll add them as they come in and will announce soon... The FreeBSD builds are now available, along with the respective SHA256 sums and the updated README file, as usual: http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/SHA256SUMS http://haskell.inf.elte.hu/ghc/README.html ___ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org mailto: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 ___ 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: 7.8.1 plan
Hi Austin/all, Here's GHC iOS 7.8.1 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1-device/ghc-7.8.1-arm-apple-ios.tar.bz2 (sha 4b98f55212b33296ed9d59d7e30eaa12d7a34a3b) https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1/ghc-7.8.1-i386-apple-ios.tar.bz2 (sha bcd213b4da15f77aaa4b1b06c51867785f262002) and README https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Cheers Luke On Wed, Apr 9, 2014 at 6:09 PM, Austin Seipp aus...@well-typed.com wrote: Jens, It's probably due to abb86adf7f749b3d44887d28bc96b43c5a1e0631[1] which was merged post RC2. I base this on the fact your build is failing during the dynamic build. Do try a reverse patch and see if it helps. I believe Karel is right - you just need to use Gold. Ben actually had patches to make the build fail if using binutils ld was detected, but I believe I had reservations about the patch which I cannot recall off the top of my head. In any case, a fix like that can certainly go in 7.8.2. Do let us know how it goes. [1] https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631 On Wed, Apr 9, 2014 at 8:03 PM, Jens Petersen peter...@fedoraproject.org wrote: On 9 April 2014 17:53, Karel Gardas karel.gar...@centrum.cz wrote: Ben Gamari (cced) documented it well here: http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html Looks like the issue is caused by binutils' linker while fixed in gold. Thanks a lot, Karel! I will try Ben's hack later. I am still surprised that RC2 builds fine on ARM (I re-verified that yesterday [1]) but not final 7.8.1. Were there some late ARM or linking changes that cause this now? On 04/ 9/14 10:21 AM, Jens Petersen wrote: dll-split: internal error: evacuate(static): strange closure type 0 See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for I reproduced this two times now. RC2 built okay on ARM so I am not sure what changed. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331 ___ 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Breaking bug in 7.8.1
This seems good to me. I'll go ahead and prep the tree then and get some things ready. To everyone: I'm going to carefully review the outstanding patches etc besides #8979, but I'm not inclined to take very many - if any - besides this one. So if you missed the 7.8.1 train, but you *really* want something in 7.8.2, please talk to me soon... On Thu, Apr 10, 2014 at 2:34 AM, Simon Peyton Jones simo...@microsoft.com wrote: Austin, Simon (and others) As you’ll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it seems to matter. (Because of the windows seg-fault saga, RC2 was active for a long time, and none of our regression tests showed up this bug.) It looks to me that we have little choice but to push out 7.8.2, more or less immediately, and advise everyone to ignore 7.8.1.Do you agree? Sorry about this. Simon -- 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: 7.8.2 bugs and beyond
Hello all, Misfortune has struck unfortunately - we shipped with a bit of an awful bug in 7.8.1, see #8978. The good news is Simon already has a fix! Yay! However, I'll probably be going ahead and releasing an immediate today. For everyone, I don't think this changes much regarding my last email - just substitute '7.8.2' with '7.8.3' where you might see it. Here's the list of 7.8.3 bugs for reference, I migrated the old 7.8.2 tickets here: https://ghc.haskell.org/trac/ghc/query?milestone=7.8.3group=status Thanks! On Wed, Apr 9, 2014 at 7:34 PM, Austin Seipp aus...@well-typed.com wrote: Hello all, 7.8.1 is out. Yay! Now, on to the next thing. Here's the very preliminary 7.8.2 buglist: - https://ghc.haskell.org/trac/ghc/query?group=statusmilestone=7.8.2 Note that this list has effectively received zero curation so far. I plan on fixing that soon, and in the process I am probably going to touch a lot of trac tickets (so I apologize in advance for the mail spam, because y'all are probably going to get a lot of it). This will include re-prioritizing these bugs, so take things with a grain of salt right now. Note that the bug tracker now has 7.8.1 as the default version - if you're filing bugs, please be sure to try it first of course. :) And don't forget to set the milestone to 7.8.2 if you think it qualifies for a fix. There are already a couple of things in the merge queue. There's currently no expected date for 7.8.2. Should it arrive quickly? Or slowly? Simon, Simon and I are inclined to just let things play out for a while of course, which is the traditional way things are done. But this release window has been especially awkward, so we'll see what happens. This of course leaves timeline questions for 7.10 open - but before we decide that, now's a time to just get some hacking done I suppose... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- 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: Breaking bug in 7.8.1
This fix is now merged in the 7.8 branch and is ready to go. Unless someone speaks soon, I'm going to go ahead and start the builds... On Thu, Apr 10, 2014 at 7:28 AM, Austin Seipp aus...@well-typed.com wrote: This seems good to me. I'll go ahead and prep the tree then and get some things ready. To everyone: I'm going to carefully review the outstanding patches etc besides #8979, but I'm not inclined to take very many - if any - besides this one. So if you missed the 7.8.1 train, but you *really* want something in 7.8.2, please talk to me soon... On Thu, Apr 10, 2014 at 2:34 AM, Simon Peyton Jones simo...@microsoft.com wrote: Austin, Simon (and others) As you’ll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it seems to matter. (Because of the windows seg-fault saga, RC2 was active for a long time, and none of our regression tests showed up this bug.) It looks to me that we have little choice but to push out 7.8.2, more or less immediately, and advise everyone to ignore 7.8.1.Do you agree? Sorry about this. Simon -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- 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: Breaking bug in 7.8.1
I'm now building the source distribution and sanity checking it before I push the tags. Stay tuned. On Thu, Apr 10, 2014 at 7:54 AM, Austin Seipp aus...@well-typed.com wrote: This fix is now merged in the 7.8 branch and is ready to go. Unless someone speaks soon, I'm going to go ahead and start the builds... On Thu, Apr 10, 2014 at 7:28 AM, Austin Seipp aus...@well-typed.com wrote: This seems good to me. I'll go ahead and prep the tree then and get some things ready. To everyone: I'm going to carefully review the outstanding patches etc besides #8979, but I'm not inclined to take very many - if any - besides this one. So if you missed the 7.8.1 train, but you *really* want something in 7.8.2, please talk to me soon... On Thu, Apr 10, 2014 at 2:34 AM, Simon Peyton Jones simo...@microsoft.com wrote: Austin, Simon (and others) As you’ll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it seems to matter. (Because of the windows seg-fault saga, RC2 was active for a long time, and none of our regression tests showed up this bug.) It looks to me that we have little choice but to push out 7.8.2, more or less immediately, and advise everyone to ignore 7.8.1.Do you agree? Sorry about this. Simon -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- 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
Website repository
Hello all, While making the release the other day, one thing I found odd is that the GHC website is still under Darcs version control on the website. I'm not sure how many people are generally aware of this, however, but you should just be able to darcs get http://haskell.org/ghc I'm wondering if we should move this somewhere else more public. I've wanted someone to perhaps look into updating the website to something a little more modern an easier to update for a while now.* Right now it's just a bunch of SHTML pages stamped together, and it could probably be a lot easier to maintain. I don't necessarily propose we put it in the GHC repository (the LLVM folks do this, but I think it would make actually *updating* the website somewhat confusing), just somewhere more public. Does anyone have any inputs? My first inclination is to just put it on git.haskell.org, but perhaps the github.com/haskell organization is a better place (a bit more public). Just wondering if anyone has thoughts. * If someone out there is interested in doing this that would be excellent, by the way, and I'm sure everyone would appreciate it :) -- 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: Website repository
On Thu, Apr 10, 2014 at 3:55 PM, Austin Seipp aus...@well-typed.com wrote: I don't necessarily propose we put it in the GHC repository (the LLVM folks do this, but I think it would make actually *updating* the website somewhat confusing), just somewhere more public. Does anyone have any inputs? My first inclination is to just put it on git.haskell.org, but perhaps the github.com/haskell organization is a better place (a bit more public). I say put it on git.haskell.org and have our GitHub mirroring mirror it to github.com/ghc/repo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Website repository
I thought that too, but the reason I suggest GitHub is because it might make people more inclined to submit patches. I still hear people who want the GitHub mirrors to allow pull requests, but I think moving it to the haskell organization would be easier and allow that anyway in the short term without mirror complications.* * Note I'm not interested in having the debate about allowing PRs on GitHub mirrors right now - it's just a recommendation as a result of that. On Thu, Apr 10, 2014 at 8:56 AM, Johan Tibell johan.tib...@gmail.com wrote: On Thu, Apr 10, 2014 at 3:55 PM, Austin Seipp aus...@well-typed.com wrote: I don't necessarily propose we put it in the GHC repository (the LLVM folks do this, but I think it would make actually *updating* the website somewhat confusing), just somewhere more public. Does anyone have any inputs? My first inclination is to just put it on git.haskell.org, but perhaps the github.com/haskell organization is a better place (a bit more public). I say put it on git.haskell.org and have our GitHub mirroring mirror it to github.com/ghc/repo -- 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: Website repository
On Thu, Apr 10, 2014 at 4:00 PM, Austin Seipp aus...@well-typed.com wrote: I thought that too, but the reason I suggest GitHub is because it might make people more inclined to submit patches. I still hear people who want the GitHub mirrors to allow pull requests, but I think moving it to the haskell organization would be easier and allow that anyway in the short term without mirror complications.* * Note I'm not interested in having the debate about allowing PRs on GitHub mirrors right now - it's just a recommendation as a result of that. I'm fine with that too, although if this is really just the /ghc section of haskell.org, we could also put it under github.com/ghc/website (not as a mirror). If you want to use the haskell GitHub org, I can give you access. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: Partial Type Signatures - Status update
Yay! I have nothing else constructive to say, at the moment. What's the next step from your point of view? Are there unimplemented bits of this? Thanks for doing this! Richard On Apr 10, 2014, at 3:48 AM, Thomas Winant thomas.win...@cs.kuleuven.be wrote: Hi, I'm back with a status update. We implemented Austin's suggestion to make wildcards in partial type signatures behave like holes. Let's demonstrate the new behaviour with an example. The example program: module Example where foo :: (Show _a, _) = _a - _ foo x = show (succ x) Compiled with GHC master gives: Example.hs:3:18: parse error on input ‘_’ When we compile it with our branch: Example.hs:3:18: Instantiated extra-constraints wildcard ‘_’ to: (Enum _a) in the type signature for foo :: (Show _a, _) = _a - _ at Example.hs:3:8-30 The complete inferred type is: foo :: forall _a. (Show _a, Enum _a) = _a - String To use the inferred type, enable PartialTypeSignatures Example.hs:3:30: Instantiated wildcard ‘_’ to: String in the type signature for foo :: (Show _a, _) = _a - _ at Example.hs:3:8-30 The complete inferred type is: foo :: forall _a. (Show _a, Enum _a) = _a - String To use the inferred type, enable PartialTypeSignatures Now the types the wildcards were instantiated to are reported. Note that `_a` is still treated as a type variable, as prescribed in Haskell 2010. To treat it as a /named wildcard/, we pass the -XNamedWildcards flag and get: [..] Example.hs:3:24: Instantiated wildcard ‘_a’ to: tw_a in the type signature for foo :: (Show _a, _) = _a - _ at Example.hs:3:8-30 The complete inferred type is: foo :: forall tw_a. (Show tw_a, Enum tw_a) = tw_a - String To use the inferred type, enable PartialTypeSignatures [..] An extra error message appears, reporting that `_a` was instantiated to a new type variable (`tw_a`). Finally, when passed the -XPartialTypeSignatures flag, the typechecker will just use the inferred types for the wildcards and compile the program without generating any error messages. We added this example and a section about the monomorphism restriction to the wiki page [1]. Comments and feedback are still welcome. Cheers, Thomas Winant [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ 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: Trac seems to think I'm a spambot...?
Did the spamchecker get turned off? I just deleted a ticket (#8982; check your mail archives) which should have been caught by essentially any spamchecker worth its salt. Also, do we have any facilities for permanently banning spammers? Excerpts from Kyle Van Berendonck's message of 2014-04-07 02:43:23 -0700: Hmm. I just got flagged as a spambot trying to reply to a ticket too. It did give me a captcha option though. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Validate failures (perf, ghc-7.8)
I've got perf failures on Linux 64-bit on ghc-7.8 (and master too, I think). Please take a look. Unexpected results from: TEST=T4801 T3064 T5837 T6048 OVERALL SUMMARY for test run started at Thu Apr 10 15:33:27 2014 PDT 0:02:52 spent to go through 3920 total tests, which gave rise to 12853 test cases, of which 9274 were skipped 26 had missing libraries 3491 expected passes 58 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Offering GHC builder build slaves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu 10 Apr 2014 07:57:16 AM UTC, Karel Gardas wrote: On 04/10/14 02:52 AM, Alain O'Dea wrote: hmm, that's after GHC own platform processing is done, but what does sh config.guess tells you? E.g. on my two Solaris 11 I get: $ sh config.guess i386-pc-solaris2.11 $ sh config.guess sparc-sun-solaris2.11 Karel, I think I finally have what you were looking for: x86_64-pc-solaris2.11 i386-pc-solaris2.11 Great, so this means SmartOS is just another member of Solaris family. I've installed it and verified that `ld' and `nm' are really what we expect on real Solaris. Them's fightin' words ;) There are hard feelings (with good reason) between Illumos and Solaris. Oracle betrayed the OpenSolaris community and particularly their Open Source contributors when they closed Solaris. It was a very unethical thing to do. Bryan Cantrill spoke well on the reasons for and nature of the Illumos fork at LISA11: http://smartos.org/2011/12/15/fork-yeah-the-rise-and-development-of-illumos-2/ I am very happy that they remain binary compatible. I can immediately use Solaris 10 binaries on Illumos and in many cases Solaris 10 and 11 can run Illumos binaries. In fact thanks for your advice I've been able to use its packaged GHC on my Solaris 11 to compile some code and even attempted the bootstrap of HEAD for Solaris/AMD64 platform. There are some outstanding issues with bootstrap so this needs to wait till my weekend ghc hobby time...(if someone does not solved it faster of course...) Thanks! Karel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRy0bAAoJEP0rIXJNjNSA4oUH/irlhd1xztoUA1yTDB/y5eDs jygqjp5cymU9jELfMGTJqTzuIyw/whvpDcqmiPqEaDrWdTgCUIHraZrxk0UTT/BF w6jtY1dBCqECUkQhT5Pdr/T/GtnRxVItiMGxn6fJ8c4yWb0HDcMFmXmCkyrwQQi6 ZwiLqpWu8P1zAHplbaOeEihusRaKtllOEm07eIajZdYcyjCoszgQrZyORaBVllkh Czwyk9WCkkh9u9GWhYZu7p1p8Z7ToJ/lrv/VgGWxbaCZcS1q+j4a7Z9r41L6HJ8v mgpEqBNtKgVZ1cRzVN8sapinXWt6PoNR38dHHUEGeW76z9TrqD5pPvOab9ROfGc= =5KpS -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
Thanks Austin, On 10 April 2014 10:09, Austin Seipp aus...@well-typed.com wrote: It's probably due to https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631abb86adf7f749b3d44887d28bc96b43c5a1e0631 which was merged post RC2. I base this on the fact your build is failing during the dynamic build. Do try a reverse patch and see if it helps. Yes, that fixed the build with the standard bfd linker (http://koji.fedoraproject.org/koji/taskinfo?taskID=6722847). It seems to pass the dyn helloworld test at least. I believe Karel is right - you just need to use Gold. Ben actually had patches to make the build fail if using binutils ld was detected, but I believe I had reservations about the patch which I cannot recall off the top of my head. In any case, a fix like that can certainly go in 7.8.2. If it doesn't then I think I can bootstrap to 7.8 with ld.bfd and then rebuild with ld.gold so hopefully it should work out anyway. Thanks, Jens dll-split: internal error: evacuate(static): strange closure type 0 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
