- ghc-devs - Haskell.org

Broken build: Documentation mistake
by Páli Gábor János 17 Jun '15

17 Jun '15

Hello there, Looks like there is some problem with one of the recent changes to The User's Guide source code as it cannot be built any more [1] (since about June 4). Here is the error message, hopefully it helps with fixing the cause: [..] Build users_guide.ps latex failed users_guide.tex:15584: Cannot determine size of graphic in docs/users_guide//prof_scc.png (no BoundingBox). users_guide.tex:15584: leading text: ...width=645pt,height=428pt]{prof_scc.png} Unexpected error occured [ -f docs/users_guide/users_guide.ps ] docs/users_guide/ghc.mk:26: recipe for target 'docs/users_guide/users_guide.ps' failed gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1 Makefile:102: recipe for target 'all' failed gmake: *** [all] Error 2 Thanks, Gábor [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/652/10.html

3 9

Problem about `DerivedConstants.h` and `tmp.c` in `includes/dist-derivedconstants/header`, GHC 7.8.3
by Zhen Zhang 16 Jun '15

16 Jun '15

Hi everyone, I am having trouble porting some 6.8.2 GHC code to 7.8.3 GHC. The main trouble I met is that, in 6.8.2, there is a includes/mkDerivedConstants.c and some constants about RTS are declared here. While in 7.8.3, there is only a similar `includes/dist-derivedconstants/header` directory containing a bunch of code. Some seems generated like `DerivedConstants.h`, and it seems like `tmp.c` generated this. However, when I added some entries in `tmp.c` and compiled it, then it became the original version ... So I doubted that if there is another file which is equivalent to the includes/mkDerivedConstants.c in 6.8.2? Thank a lot! Zhen

2 1

ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Austin Seipp 16 Jun '15

16 Jun '15

We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc1 https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ This includes the source tarball and bindists for Windows, Mac OS X, and Debian Linux. FreeBSD and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release at the end of this coming week - so please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Austin Seipp 15 Jun '15

15 Jun '15

Yes, as noted on the ticket, I've bumped the priority and we'll be looking into this - and hopefully have a fix in time for 7.10.2. There are some similar tickets where we get large explosions of terms, so it may be in the same ballpark. On Sun, Jun 14, 2015 at 11:18 PM, Rob Everest <robertce(a)cse.unsw.edu.au> wrote: >> We plan to make the 7.10.2 final release at the end of this coming week - >> so please test as much as possible; bugs are much cheaper if we find them >> before the release! > > > Could I possibly draw attention to #10491? It's a regression in the > simplifier that is causing considerable pain for Accelerate, namely a > compile time of many hours for a 300 line module. It would be unfortunate if > this couldn't be resolved for the 7.10.2 release. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: the platform has outgrown Travis-CI
by Christopher Allen 15 Jun '15

15 Jun '15

Have the build timeout issues been resolved? Mathias Meyer (CEO at TravisCI) said you didn't get in touch with him with the info he needed to bump the timeout for Haskell Platform. Did you not get the email? On Tue, Jun 9, 2015 at 9:04 AM, Mathias Meyer <mathias(a)travis-ci.com> wrote: > Hey Christopher and Mark, > > Great to meet you. > > Could you let me know what the name of the project on GitHub and the > owner's account name is? > > I'll have a look if I can adjust the timeout upwards for this project. > > Cheers, Mathias > > On Tue, Jun 9, 2015 at 3:50 PM, Christopher Allen <cma(a)bitemyapp.com> > wrote: > >> Mark Lentczner has been the main (and hard-working) Haskell Platform >> mensch for at least a couple years now. I forwarded the initial email for >> context. >> >> What can be done? >> >> Thanks for your time. >> >> ---------- Forwarded message ---------- >> From: Mark Lentczner <mark.lentczner(a)gmail.com> >> Date: Sun, Jun 7, 2015 at 11:33 AM >> Subject: the platform has outgrown Travis-CI >> To: "haskell-platform(a)projects.haskell.org" < >> haskell-platform(a)projects.haskell.org>, "ghc-devs(a)haskell.org" < >> ghc-devs(a)haskell.org>, "haskell-infrastructure(a)community.galois.com" < >> haskell-infrastructure(a)community.galois.com> >> >> >> I finally figured out what was wrong with the Travis CI build for Haskell >> Platform, and got it all working w/hvr's .debs of GHC (for the boot >> compiler)... and ran smack into this: >> >> Your test run exceeded 50 minutes. >> >> >> SO... I'd like to find another CI solution. Is phabricator.haskell.org >> an option? Can we / should we create a project there? >> >> - Mark >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > -- Chris Allen Currently working on http://haskellbook.com

1 0

Test message, please ignore
by Austin Seipp 15 Jun '15

15 Jun '15

If you can see this, it probably works. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Test message, please ignore
by Austin Seipp 15 Jun '15

15 Jun '15

If you can see this, it probably works. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

RE: overlapping instances in 7.10.1
by Simon Peyton Jones 13 Jun '15

13 Jun '15

Sergei I finally found time to look into what is happening here. It's a good illustration of the dangers of overlapping instances. Here is the setup: * Module ResEuc_ * Contains instance (...) => Ring (ResidueE a) <---- (A) instance (..., Ring (ResidueE a)) => Field (ResidueE a) <---- (B) * Module PFact__ * Imports Pgcd_, which imports ResEuc_ * Contains code that needs (Field (ResidueE (UPol (ResidueE Integer)))) <------ (X) * To solve (X) we use instance (B) from ResEuc_ * And hence we need to solve (Ring (ResidueE (UPol (ResidueE Integer)))) which we do using (A) but not (C) * Module RsePol_ * Imports PFact__ * Contains the specialised instance instance (...) => Ring (ResidueE (UPol a)) <------ (C) which overlaps instance (A) * Module Main * Needs an instance for Field (ResidueE (UPol (Residue Integer))) <------ (Y) * Although GHC *could* generate this by instance declarations, which it would do using (B) and then using (C), instead GHC cleverly sees that it has generated it before, in module PFact__, and so uses the one from PFact__. And that is what gives rise to your error So the real problem is that in PFact__, we make an instance (X) that does not see the specialised instance (C). It *cannot* see that instance because RsePol_ imports PFact__. So whatever code uses (X) is not going to see the specialised instance. I bet that this is not what you intend. This may be a latent bug in DoCon. I solved the problem by combining PFact__ and RsePol_ into a single module. Then everything works fine. What are the general lessons here? * GHC generally assumes that if it generates (C T) in one place, then it can use that anywhere in the program that (C T) is needed. That is, there is only one (C T) dictionary. * But suppose you have overlapping instance in different modules; say module A where instance C [a] module B where import A; instance C [Maybe a] If you use (C [Maybe Int]) in A, then of course we won't see the instance in B. So you'll get a different dictionary than if you compute C [Maybe Int] in module B. In short, overlapping instances are OK, but it's best to put them in the same module as the instances they overlap. Could GHC behave as if all instances were calculated afresh in the module being compiled. Yes, of course it could, but at the cost of losing the benefit of cross-module specialisation. An overloaded function specialised at, say, [Int] in one module could not be re-used in another in case the instances changed. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | Sergei Meshveliani | Sent: 23 May 2015 22:08 | To: glasgow-haskell-users(a)haskell.org | Cc: glasgow-haskell-bugs(a)haskell.org | Subject: overlapping instances in 7.10.1 | | Dear GHC developers, | | This request overrides my previous one of "7.10.1-err..." | (it is simpler and more precise). | The archive | | http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-<http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2…> | may23-2015.zip<http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2…> | | presents a question about ghc-7.10.1. | | Make it, please, with ghc-7.10.1 by | | ghc $doconCpOpt -O --make Main | , | $doconCpOpt = | -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports | -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns | -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances | -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 | | | as it is written there in README.txt. | | README.txt explains which two instances are wrongly resolved | -- as I expect. | | In ghc-7.8.2 they are resolved in a correct way | (and there is a different pragma syntax). | I conclude this from running the test in docon-2.12. | | Am I missing something? | | Please, advise, | | ------ | Sergei | | | | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

1 0

GHC build failure
by Wolfgang Jeltsch 11 Jun '15

11 Jun '15

Hi, I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? All the best, Wolfgang

5 7

Adding location information to derived code
by Jan Stolarek 11 Jun '15

11 Jun '15

Hi devs, say I have: class C a where type F a type F a = a instance C Int During compilation of "instance C Int" GHC will derive a default associated type instance "F Int = Int". That instance has no location information and so any errors that it might cause will have a very uninformative source code location 1:1. I want to fix this but I'm not sure whether it is a good idea to add location information to automatically generated code. Do we make any assumptions that derived code should have no location information? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 2