Re: build failures when hiding non-visible imports
On 21 August 2012 07:36, John Lato wrote: >> From: Brandon Allbery >> >> On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald < >> carter.schonw...@gmail.com> wrote: >> >>> meaning: flags for treating it as a warning vs as an error? (pardon, i'm >>> over thinking ambiguity in phrasing). >>> if thats the desired difference, that sounds good to me! >>> >> >> I would expect it means that, having demoted it to a warning, we would have >> -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or whatever we call >> it) as with all other warnings. >> >> For warning vs. error, it seems to me that should be more general: perhaps >> taking any of the -f[no-]warn-* options and replacing "warn" with "err". > > Yes. To be concrete, this is what I would like to see. > > In a statement of the form: > > import Module hiding (x) > where Module doesn't export x, ghc should report a warning instead of an error > > This warning would be enabled/disabled by the usual flags (I like > -fwarn-unused-import-hiding, but -fwarn-hiding-no-target is good too). > > The warning would be on by default. > > If a user wants this to be an error, I think -Werror should be > sufficient. I am unable to think of any case where hiding a > non-visible symbol would lead to errors on its own, and any errors > likely to occur in tandem with this issue already have their own, more > helpful, error conditions (e.g. symbols not in scope, symbols in a > qualified import list not visible). > > I agree with Ganesh's point that it would be beneficial to have this > available for ghc-7.6.1 if possible. +1 and it must be a warning (not error) by default, or else we will need to tell everyone to use "cabal install --ghc-option=-fwarn-unused-import-hiding" to install lots of packages on hackage (currently including things like HTTP and gtk2hs-buildtools, which are pulled in by many packages). Also, if this remains an error by default then it will become a sensible coding style to simply avoid using import hiding, to avoid build errors that will occur when some other library removes an interface (that you have explicitly marked as unused ...) Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build failures when hiding non-visible imports
> From: Brandon Allbery > > On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> meaning: flags for treating it as a warning vs as an error? (pardon, i'm >> over thinking ambiguity in phrasing). >> if thats the desired difference, that sounds good to me! >> > > I would expect it means that, having demoted it to a warning, we would have > -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or whatever we call > it) as with all other warnings. > > For warning vs. error, it seems to me that should be more general: perhaps > taking any of the -f[no-]warn-* options and replacing "warn" with "err". Yes. To be concrete, this is what I would like to see. In a statement of the form: import Module hiding (x) where Module doesn't export x, ghc should report a warning instead of an error This warning would be enabled/disabled by the usual flags (I like -fwarn-unused-import-hiding, but -fwarn-hiding-no-target is good too). The warning would be on by default. If a user wants this to be an error, I think -Werror should be sufficient. I am unable to think of any case where hiding a non-visible symbol would lead to errors on its own, and any errors likely to occur in tandem with this issue already have their own, more helpful, error conditions (e.g. symbols not in scope, symbols in a qualified import list not visible). I agree with Ganesh's point that it would be beneficial to have this available for ghc-7.6.1 if possible. John L. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build failures when hiding non-visible imports
On 17/08/2012 11:18, Simon Peyton-Jones wrote: > | Would it be reasonable to change ghc's behavior to treat this > | (ie an 'import' statement that hides something that isn't exported) as a > | warning instead of an error? > > Yes, that would be easy if it's what everyone wants. Any other opinions? I don't feel strongly either way, but I'd just argue that if it happens it should happen for 7.6.1 to get maximum benefit. Otherwise packages will still need preprocessor hacks to hide Prelude.catch in the meantime (or to use explicit imports from the Prelude, which would be pretty annoying). Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: funny type inference error with ghc7.6rc1
I'll *try* :) I assume ghc rc, plus having cabal installed 1) cabal unpack the most recent haskeline, and fix it so it can build, this is updating the Setup.hs file for haskeline, as theres no longer a Control.Exception.Extensible (instead its just Control.Exception.Base ), so that just needs to be swapped cabal install that. 2) git clone https://github.com/cartazio/EpiVM, 3) cd EpiVM ; git checkout patch-1 ; cabal build ; cabal configure ; cabal build ; cabal install 4) now you can try doing "cabal install idris" and you should get the following type error message https://gist.github.com/3405712 which is exactly an example of this sort of phenomena. i can try to spend some more time on concocting a smaller case, but I'd rather not... i need to focus on building my haskell backed numerical computation tools I've got some enterprise customers waiting for this fall! please let me know either way if that helps! cheers -Carter On Mon, Aug 20, 2012 at 4:44 AM, Simon Peyton-Jones wrote: > That does seem odd. Can you give instructions for how to reproduce > this? The fewer dependencies the better :-) > > ** ** > > Simon > > ** ** > > *From:* glasgow-haskell-users-boun...@haskell.org [mailto: > glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Carter Schonwald > *Sent:* 17 August 2012 19:01 > *To:* GHC Users List > *Subject:* funny type inference error with ghc7.6rc1 > > ** ** > > Hey All, > > ** ** > > When playing with the current hackage versions of Epic and Idris to make > them play nice with ghc7.6rc1 > > ** ** > > http://hackage.haskell.org/package/idris-0.9.2.1 > > and > > http://hackage.haskell.org/package/epic-0.9.3(current version on > github now builds on ghc 7.6, https://github.com/edwinb/EpiVM) > > ** ** > > I ran into some funny type inference problems. Namely, using > the idris-0.9.2.1 source and iteratively seeing how ghc complains, > > I repeated found that ghc would infer extraneous class constraints with > variables that don't appear in the function type! > > ** ** > > eg (Num a, Ord a) => PArg -> Doc, when the *correct* type to infer > would be PArg -> Doc. > > heres some gists with links to more info > > https://gist.github.com/3365312 > > https://gist.github.com/3365073 > > https://gist.github.com/3364775 > > ** ** > > Anyways, I'm not sure what to make of this, is this a reasonable artifact > of type inference getting confused on functions with a large number of > case analyses when various typeclass extensions are enabled? Or Is this a > bug in terms of what inference should be able to handle? > > ** ** > > Just to be clear, when I add the infererred type ascriptions without the > type class constraint, everything type checks in those modules. So my > confusion is why the inference adding those unused class constraint > variables! > > ** ** > > thanks all, > > -Carter > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: +RTS -S heap reporting oddity
On 17/08/2012 17:08, Wolfram Kahl wrote: During one of my long Agda runs (with GHC-7.4.2), I observed the following output, with run-time options +RTS -S -H11G -M11G -K256M : 7694558208 30623864 3833166176 0.11 0.11 234.75 234.7900 (Gen: 0) 7678904688 29295168 3847737784 0.11 0.11 242.04 242.0900 (Gen: 0) 7662481840 29195736 3861451856 0.11 0.11 249.31 249.3500 (Gen: 0) 7647989280 26482704 3872463688 0.12 0.12 256.64 256.6800 (Gen: 0) 4609865360 25764016 3886000448 0.09 0.09 261.04 261.0900 (Gen: 0) 4581294920 19435032 3891512272 0.07 0.07 265.37 265.4200 (Gen: 0) 4568757088 21095864 3902286000 0.08 0.08 269.70 269.7400 (Gen: 0) 4546421608 21618856 3913923976 0.09 0.09 274.04 274.0900 (Gen: 0) 452151 2894668056 3484748224 7.63 7.63 285.94 285.9800 (Gen: 1) 8085358392 23776128 3499185336 0.11 0.11 293.49 293.5300 (Gen: 0) 8064630856 32055112 3515876576 0.13 0.13 300.91 300.9500 (Gen: 0) 8040500112 31477608 3528105088 0.12 0.12 308.37 308.4100 (Gen: 0) 8031456296 29641328 3540632456 0.11 0.11 315.83 315.8700 (Gen: 0) 8018447264 30187208 3554339600 0.12 0.12 323.26 323.3100 (Gen: 0) To my untrained eye, this seems to be saying the following: In the first 4 lines, the heap runs (almost) full before (minor) collections. In lines 5 to 9 it apparently leaves 3G empty before collection, but ``those 3G'' then appear on line 9 in the ``amount of data copied during (major) collection'' column, and after that it runs up to fill all 11G again before the next few minor collections. What is really going on here? (Previously I had never seen such big numbers in the second column on major collections.) It looks like on line 5, the GC thought it was going to do a major collection the next time, so it left 3G free to copy the contents of the old generation. But then it didn't do a major GC until line 9. I've just checked the code, and I think this might be due to a slight inaccuracy in the way that we estimate whether the next GC will be a major one, and at these huge sizes the discrepancy becomes significant. Thanks for pointing it out, I'll fix it to use the same calculation in both places. Cheers, Simon Wolfram P.S.: Same effect again, but more dramatic, later during the same Agda run: 448829488 4864536 5710435424 0.02 0.02 1422.80 1422.9000 (Gen: 0) 445544064 3251712 5710248752 0.01 0.01 1423.23 1423.3200 (Gen: 0) 450236784 4148864 5712696848 0.02 0.02 1423.68 1423.7700 (Gen: 0) 445240152 3828120 5713606328 0.02 0.02 1424.10 1424.1900 (Gen: 0) 443285616 5906448 5717731864 0.02 0.02 1424.52 1424.6100 (Gen: 0) 430698248 4773500032 5363214440 9.30 9.30 1434.21 1434.3000 (Gen: 1) 6148455592 13490304 5374609848 0.07 0.07 1439.83 1439.9200 (Gen: 0) 6185350848 27419744 5389326896 0.11 0.11 1445.50 1445.5900 (Gen: 0) 6168805736 23069072 5398725784 0.11 0.11 1451.22 1451.3200 (Gen: 0) 6157744328 23451872 5408370152 0.09 0.09 1456.93 1457.0300 (Gen: 0) 6151715272 25739584 5421044592 0.11 0.11 1462.62 1462.7200 (Gen: 0) 6132589488 24541688 5428809632 0.10 0.10 1468.26 1468.3700 (Gen: 0) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: funny type inference error with ghc7.6rc1
That does seem odd. Can you give instructions for how to reproduce this? The fewer dependencies the better :-) Simon From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Carter Schonwald Sent: 17 August 2012 19:01 To: GHC Users List Subject: funny type inference error with ghc7.6rc1 Hey All, When playing with the current hackage versions of Epic and Idris to make them play nice with ghc7.6rc1 http://hackage.haskell.org/package/idris-0.9.2.1 and http://hackage.haskell.org/package/epic-0.9.3(current version on github now builds on ghc 7.6, https://github.com/edwinb/EpiVM) I ran into some funny type inference problems. Namely, using the idris-0.9.2.1 source and iteratively seeing how ghc complains, I repeated found that ghc would infer extraneous class constraints with variables that don't appear in the function type! eg (Num a, Ord a) => PArg -> Doc, when the correct type to infer would be PArg -> Doc. heres some gists with links to more info https://gist.github.com/3365312 https://gist.github.com/3365073 https://gist.github.com/3364775 Anyways, I'm not sure what to make of this, is this a reasonable artifact of type inference getting confused on functions with a large number of case analyses when various typeclass extensions are enabled? Or Is this a bug in terms of what inference should be able to handle? Just to be clear, when I add the infererred type ascriptions without the type class constraint, everything type checks in those modules. So my confusion is why the inference adding those unused class constraint variables! thanks all, -Carter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
