- ghc-devs - Haskell.org

Re: Overlapping and incoherent instances
by Ben Millwood 07 Aug '14

07 Aug '14

On Sat, Aug 02, 2014 at 08:51:57PM +0100, Ben Millwood wrote: >On Sat, Aug 02, 2014 at 04:27:14PM +0100, Ben Millwood wrote: >>On Thu, Jul 31, 2014 at 07:20:31AM +0000, Simon Peyton Jones wrote: >>>My main motivation was to signal the proposed deprecation of the global per-module flag -XoverlappingInstances. Happily people generally seem fine with this. It is, after all, precisely what deprecations are for ("the old thing still works for now, but it won't do so for ever, and you should change as soon as is convenient"). >> >>Here's one concern I have with the deprecation of >>-XOverlappingInstances: I don't like overlapping instances, I find >>them confusing and weird and prefer to use code that doesn't >>include them, because they violate my expectations about how type >>classes work. When there is a single LANGUAGE pragma, that's a >>simple, easily-checkable signpost of "this code uses techniques >>that Ben doesn't understand". When it is all controlled by pragmas >>I basically have to check every instance declaration individually. >> >>On a largely unrelated note, here's another thing I don't >>understand: when is OVERLAPPABLE at one instance declaration >>preferable to using only OVERLAPPING at the instance declarations >>that overlap it? In the latter model, as long as none of the >>instances I write have pragmas, I can be sure none of them overlap. >>In the former model, any instance I write for an existing typeclass >>might overlap another instance, even if I don't want it to. Do we >>have any specific use cases in mind for OVERLAPPABLE? >>_______________________________________________ >>Libraries mailing list >>Libraries(a)haskell.org >>http://www.haskell.org/mailman/listinfo/libraries > >When I originally sent this mail I wasn't subscribed to the GHC >lists, so I went and fixed that and am now resending. Good grief, and then I sent from the wrong address. Sorry for the noise. >Addendum: I was surprised by the behaviour of overlapping instances >when I went and looked closer at it. > > {-# LANGUAGE FlexibleInstances #-} > module M where > class C a where f :: a -> a > instance C a where f x = x > instance C Int where f x = x + 1 > >I suspect many people have the intuition that NoOverlappingInstances >should forbid the above, but in fact OverlappingInstances or no only >controls instance *resolution*. I imagine you all already knew this >but I did not until I carefully reread things. > >As someone who dislikes overlapping type class instances, I am >finding them harder to avoid than I at first thought :(

3 2

New docs about tracking down regressions in GHC
by Edward Z. Yang 07 Aug '14

07 Aug '14

I recently spent some time debugging a performance regression in Haddock, and came up with some useful tips and tricks for tracking these things down in GHC. I wrote them up here: https://ghc.haskell.org/trac/ghc/wiki/Debugging/ProfilingGhc Please take a look. Thanks, Edward

1 0

linker_unload validate related issue (how to duplicate that?).
by Karel Gardas 07 Aug '14

07 Aug '14

Folks, I've noted that validate is failing on Linux recently due to issue in linker_unload. As I've submitted some patch to this test case recently which fixes this on Solaris I'm kind of curious if I broke it or not. Anyway, strange thing is: when I configure ghc and run the test by (g)make TEST=linker_unload on both Linux and Solaris I get no failure. When I validate on Linux (validate is not working on Solaris yet), then I get failure in linker_unload: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: 1: Syntax error: Unterminated quoted string make[3]: *** [linker_unload] Error 2 *** unexpected failure for linker_unload(normal) when I try to run: cd testsuite make TEST=linker_unload inside this validation tree I again get no failure in this test: [...] =====> linker_unload(normal) 2522 of 4082 [0, 0, 0] cd ./rts && $MAKE -s --no-print-directory linker_unload </dev/null >linker_unload.run.stdout 2>linker_unload.run.stderr OVERALL SUMMARY for test run started at Wed Aug 6 10:55:17 2014 CEST 0:00:08 spent to go through 4082 total tests, which gave rise to 13459 test cases, of which 13458 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures make[1]: Leaving directory `/home/karel/src/validate-test/testsuite/tests' I've also noted that this test case fails on Solaris builders with strange error: =====> linker_unload(normal) 170 of 4082 [0, 0, 1] cd ./rts && $MAKE -s --no-print-directory linker_unload </dev/null >linker_unload.run.stdout 2>linker_unload.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: internal error: loadObj: can't read `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/bindisttest/install/libHSinteg_BcPVjqcazPNGsNFG4agFty.a' (GHC version 7.9.20140806 for i386_unknown_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug gmake[3]: *** [linker_unload] Abort (core dumped) So the question is: why validate fails and why builder fails on this particular test and why my common testing on both Solaris and Linux is not able to duplicate the issue? What's so different between validate and builders and between my common: perl boot; ./configure <some params>; gmake -j12; cd testsuite; gmake THREADS=12 fast ? Thanks! Karel

2 3

Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
by Joachim Breitner 06 Aug '14

06 Aug '14

Hi Sergei, Am Mittwoch, den 06.08.2014, 22:15 +0300 schrieb Sergei Trofimovich: > On Wed, 06 Aug 2014 09:30:45 +0200 Joachim Breitner <mail(a)joachim-breitner.de> wrote: > > the attached commit seems to have regressed the scs nofib benchmark by > > ~3%: > > http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?ex… > > That's a test of compiled binary performance, not the compiler, right? Correct. > > The graph unfortunately is in the wrong order, as the tool gets confused > > by timezones and by commits with identical CommitDate, e.g. due to > > rebasing. This needs to be fixed, I manually verified that the commit > > below is the first that shows the above-noise-level-increase of runtime. > > > > (Other benchmarks seem to be unaffected.) > > > > Is this regression expected and intended or unexpected? Is it fixable? > > Or is is this simply inexplicable? > > The graph looks mysterious (18 ms bump). Bencmark does not use haskell > threads at all. Yes, I was surprised by that as well. > I'll try to reproduce degradation locally and will investigate. Thanks! > The only runtime part affected by the patch only renames threads > (the renamer gets called once for each created thread): > > > > diff --git a/libraries/base/GHC/Event/Thread.hs b/libraries/base/GHC/Event/Thread.hs > > > index 6e991bf..dcfa32a 100644 > > > --- a/libraries/base/GHC/Event/Thread.hs > > > +++ b/libraries/base/GHC/Event/Thread.hs > > > @@ -39,6 +39,7 @@ import GHC.Event.Manager (Event, EventManager, evtRead, evtWrite, loop, > > > import qualified GHC.Event.Manager as M > > > import qualified GHC.Event.TimerManager as TM > > > import GHC.Num ((-), (+)) > > > +import GHC.Show (showSignedInt) > > > import System.IO.Unsafe (unsafePerformIO) > > > import System.Posix.Types (Fd) > > > > > > @@ -244,11 +245,14 @@ startIOManagerThreads = > > > forM_ [0..high] (startIOManagerThread eventManagerArray) > > > writeIORef numEnabledEventManagers (high+1) > > > > > > +show_int :: Int -> String > > > +show_int i = showSignedInt 0 i "" > > > + > > > restartPollLoop :: EventManager -> Int -> IO ThreadId > > > restartPollLoop mgr i = do > > > M.release mgr > > > !t <- forkOn i $ loop mgr > > > - labelThread t "IOManager" > > > + labelThread t ("IOManager on cap " ++ show_int i) > > > return t > > > > > > startIOManagerThread :: IOArray Int (Maybe (ThreadId, EventManager)) > > > @@ -258,7 +262,7 @@ startIOManagerThread eventManagerArray i = do > > > let create = do > > > !mgr <- new True > > > !t <- forkOn i $ loop mgr > > > - labelThread t "IOManager" > > > + labelThread t ("IOManager on cap " ++ show_int i) > > > writeIOArray eventManagerArray i (Just (t,mgr)) > > > old <- readIOArray eventManagerArray i > > > case old of It does replace a reference to the a string ("IOManager") by something involving allocation and computation. I guess that could have a measurable effect. What happens to programs relying on very cheap threads? Do we have benchmarks for this class of programs at all? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
by Joachim Breitner 06 Aug '14

06 Aug '14

Hi, the attached commit seems to have regressed the scs nofib benchmark by ~3%: http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?ex… The graph unfortunately is in the wrong order, as the tool gets confused by timezones and by commits with identical CommitDate, e.g. due to rebasing. This needs to be fixed, I manually verified that the commit below is the first that shows the above-noise-level-increase of runtime. (Other benchmarks seem to be unaffected.) Is this regression expected and intended or unexpected? Is it fixable? Or is is this simply inexplicable? Thanks, Joachim Am Montag, den 04.08.2014, 13:13 +0000 schrieb git(a)git.haskell.org: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/f6866824ce5cdf5359f0cad78c49d65f6… > > >--------------------------------------------------------------- > > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich <slyfox(a)gentoo.org> > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) > > Summary: > The patch names most of RTS threads > and ghc (the tool) threads. > > It makes nicer debug and eventlog output for ghc itself. > > Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> > > Test Plan: ran debugged ghc under '+RTS -Ds' > > Reviewers: simonmar, austin > > Reviewed By: austin > > Subscribers: phaskell, simonmar, relrod, ezyang, carter > > Differential Revision: https://phabricator.haskell.org/D101 > > > >--------------------------------------------------------------- > > f6866824ce5cdf5359f0cad78c49d65f6d43af12 > compiler/main/GhcMake.hs | 14 ++++++++++++++ > libraries/base/GHC/Event/Thread.hs | 8 ++++++-- > 2 files changed, 20 insertions(+), 2 deletions(-) > > diff --git a/compiler/main/GhcMake.hs b/compiler/main/GhcMake.hs > index 33f163c..0c63203 100644 > --- a/compiler/main/GhcMake.hs > +++ b/compiler/main/GhcMake.hs > @@ -63,6 +63,7 @@ import qualified Data.Set as Set > import qualified FiniteMap as Map ( insertListWith ) > > import Control.Concurrent ( forkIOWithUnmask, killThread ) > +import qualified GHC.Conc as CC > import Control.Concurrent.MVar > import Control.Concurrent.QSem > import Control.Exception > @@ -80,6 +81,11 @@ import System.IO.Error ( isDoesNotExistError ) > > import GHC.Conc ( getNumProcessors, getNumCapabilities, setNumCapabilities ) > > +label_self :: String -> IO () > +label_self thread_name = do > + self_tid <- CC.myThreadId > + CC.labelThread self_tid thread_name > + > -- ----------------------------------------------------------------------------- > -- Loading the program > > @@ -744,10 +750,18 @@ parUpsweep n_jobs old_hpt stable_mods cleanup sccs = do > | ((ms,mvar,_),idx) <- comp_graph_w_idx ] > > > + liftIO $ label_self "main --make thread" > -- For each module in the module graph, spawn a worker thread that will > -- compile this module. > let { spawnWorkers = forM comp_graph_w_idx $ \((mod,!mvar,!log_queue),!mod_idx) -> > forkIOWithUnmask $ \unmask -> do > + liftIO $ label_self $ unwords > + [ "worker --make thread" > + , "for module" > + , show (moduleNameString (ms_mod_name mod)) > + , "number" > + , show mod_idx > + ] > -- Replace the default log_action with one that writes each > -- message to the module's log_queue. The main thread will > -- deal with synchronously printing these messages. > diff --git a/libraries/base/GHC/Event/Thread.hs b/libraries/base/GHC/Event/Thread.hs > index 6e991bf..dcfa32a 100644 > --- a/libraries/base/GHC/Event/Thread.hs > +++ b/libraries/base/GHC/Event/Thread.hs > @@ -39,6 +39,7 @@ import GHC.Event.Manager (Event, EventManager, evtRead, evtWrite, loop, > import qualified GHC.Event.Manager as M > import qualified GHC.Event.TimerManager as TM > import GHC.Num ((-), (+)) > +import GHC.Show (showSignedInt) > import System.IO.Unsafe (unsafePerformIO) > import System.Posix.Types (Fd) > > @@ -244,11 +245,14 @@ startIOManagerThreads = > forM_ [0..high] (startIOManagerThread eventManagerArray) > writeIORef numEnabledEventManagers (high+1) > > +show_int :: Int -> String > +show_int i = showSignedInt 0 i "" > + > restartPollLoop :: EventManager -> Int -> IO ThreadId > restartPollLoop mgr i = do > M.release mgr > !t <- forkOn i $ loop mgr > - labelThread t "IOManager" > + labelThread t ("IOManager on cap " ++ show_int i) > return t > > startIOManagerThread :: IOArray Int (Maybe (ThreadId, EventManager)) > @@ -258,7 +262,7 @@ startIOManagerThread eventManagerArray i = do > let create = do > !mgr <- new True > !t <- forkOn i $ loop mgr > - labelThread t "IOManager" > + labelThread t ("IOManager on cap " ++ show_int i) > writeIOArray eventManagerArray i (Just (t,mgr)) > old <- readIOArray eventManagerArray i > case old of > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Re: Haskell Platform 2014.2.0.0 Release Candidate 2
by George Colpitts 05 Aug '14

05 Aug '14

Yes, as you stated, not an HP problem. I did a cabal update and got past this problem. I still can't install threadscope but I don't believe this is an HP platform problem so I'll follow up with the threadscope people and won't post again to this group Thanks [10 of 35] Compiling GUI.ProgressView ( GUI/ProgressView.hs, dist/build/threadscope/threadscope-tmp/GUI/ProgressView.o ) GUI/ProgressView.hs:92:15: Could not deduce (System.Glib.UTFString.GlibString string0) arising from a use of ‘labelNew’ from the context (WindowClass win) bound by the type signature for new :: WindowClass win => win -> IO () -> IO ProgressView at GUI/ProgressView.hs:79:8-57 The type variable ‘string0’ is ambiguous Note: there are several potential instances: instance System.Glib.UTFString.GlibString text-1.1.0.0:Data.Text.Internal.Text -- Defined in ‘System.Glib.UTFString’ instance System.Glib.UTFString.GlibString [Char] -- Defined in ‘System.Glib.UTFString’ In a stmt of a 'do' block: progText <- labelNew Nothing In the expression: do { win <- windowNew; set win [containerBorderWidth := 10, windowTitle := "", ....]; progText <- labelNew Nothing; set progText [miscXalign := 0, labelUseMarkup := True]; .... } In an equation for ‘new’: new parent cancelAction = do { win <- windowNew; set win [containerBorderWidth := 10, ....]; progText <- labelNew Nothing; .... } cabal: Error: some packages failed to install: threadscope-0.2.4 failed during the building phase. The exception was: ExitFailure 1 On Tue, Jul 29, 2014 at 10:48 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Tue, Jul 29, 2014 at 7:45 AM, George Colpitts < > george.colpitts(a)gmail.com> wrote: > >> Installation worked fine. However I encountered a problem that looks like >> a regression, although it may be a problem with new versions of the package >> I am trying to install: > > > It's not an H-P problem; Apple's started using their BLOCKS C extension in > system headers, and gtk2hsc2hs doesn't understand it. (And possibly is not > using cpp properly when processing headers.) You'll need to take this up > with the gtk2hs folks. > > #ifdef __BLOCKS__ > int scandir_b(const char *, struct dirent ***, > int (^)(const struct dirent *), int (^)(const struct dirent **, > const struct > dirent **)) __DARWIN_INODE64(scandir_b) > __OSX_AVAILABLE_STARTING(__MAC_10_6, __ > IPHONE_3_2); > #endif /* __BLOCKS__ */ > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >

1 0

Core Lint warnings
by Gabor Greif 05 Aug '14

05 Aug '14

Hello all, I see *literally thousands* of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} I don't know when this started and it does not seem to lead to a damaged GHC, but nevertheless it does not look very trustworthy... Any idea what this could be and where it came from? Cheers, Gabor

1 0

Interrupt interruptible foreign calls on HS exit
by Andreas Voellmy 05 Aug '14

05 Aug '14

Hi GHCers, I've been looking into issue #9284, which boils down to getting certain foreign calls issued by HS threads to finish (i.e. return) in the exit sequence of forkProcess. There are several options for solving the particular problem in #9284; one option is to issue the particular foreign calls causing that issue as "interruptible" and then have the exit sequence interrupt interruptible foreign calls. The exit sequence, starting from hs_exit(), goes through hs_exit_(), exitScheduler(), scheduleDoGC(), deleteAllThreads(), and then deleteThread(), where deleteThread is this: static void deleteThread (Capability *cap STG_UNUSED, StgTSO *tso) { // NOTE: must only be called on a TSO that we have exclusive // access to, because we will call throwToSingleThreaded() below. // The TSO must be on the run queue of the Capability we own, or // we must own all Capabilities. if (tso->why_blocked != BlockedOnCCall && tso->why_blocked != BlockedOnCCall_Interruptible) { throwToSingleThreaded(tso->cap,tso,NULL); } } So it looks like interruptible foreign calls are not interrupted in the exit sequence. Is there a good reason why we have this behavior? Could we change it to interrupt TSO's with why_blocked == BlockedOnCCall_Interruptible in the exit sequence? Thanks, Andi P.S. It looks like this was introduced in commit 83d563cb9ede0ba792836e529b1e2929db926355.

2 4

last call... for HP 2014.2.0.0
by Mark Lentczner 05 Aug '14

05 Aug '14

As it stands, I'm planning on calling the final RCs final: - RC2 Mac - RC4 Win - RC3 Src and linux-dist They have a few wibbles, but nothing close to show-stopping. I'll rebuild the web site and upload it tomorrow and announce then as well. - Mark ("still on vacation") L.

1 0

Re: Release building for Windows
by Mark Lentczner 05 Aug '14

05 Aug '14

Seems to me that given the state of affairs, it is best to just leave it as it is this round: That is GHC is built split-obj, but the HP libs on Windows are not. In general, split-obj only makes executables smaller at the expense of link time and memory. It is a trade-off, and I'd make the call for faster link, and now uncertainty for now. So, unless there is objection, I'd call RC4 final for Windows. - Mark

1 0