August 2014 - ghc-devs

arc diff linter looping / stuck
by Richard Eisenberg 08 Aug '14

08 Aug '14

Hi all, I've prepared a bunch of commits to fix several tickets. After pushing these commits to branch wip/rae (to save my place and to get validate running on Travis), I then `git checkout`ed back to a point where `git diff origin/master` gave me a patch for precisely one bug (instead of the several unrelated ones I had fixed). I wanted to post to Differential. `arc diff` allowed me to fill out a description message (which mentioned, in its comments, the right set of commits), but then hung on the "linting..." stage. I suppose I could skip the linter, but it's more likely I've done something wrong here... Any advice? In the meantime, please consider this to be a request for feedback on everything in wip/rae! The bugs fixed are #9200, #9415, #9404, and #9371. Thanks! Richard

2 2

biographical profiling is broken?
by Ömer Sinan Ağacan 08 Aug '14

08 Aug '14

Hi all, I'm trying to use LDV profiling features of GHC but I'm failing. Here's what I try: (I'm using GHC 7.8.2) * I'm compiling my app with `-prof` and I'm also using `-fprof-auto` just to be sure. * I'm running my app using `+RTS -hbdrag,void` as described in the docs. (https://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html#bio…) This always generates an empty MyApp.hp file. There's only this header in the generated file: JOB "MyApp +RTS -hd -hbdrag,void,lag" DATE "Thu Aug 7 18:14 2014" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.00 END_SAMPLE 0.00 BEGIN_SAMPLE 0.10 END_SAMPLE 0.10 I tried different programs, from "hello world" to a complex language interpreter. I always get the same file with only a header. * I also tried adding more arguments like `-hc`, `-hm`, `-hr` etc. but I got same results. I feel like the feature is broken. I checked the test suite to find some working LDV profiling programs. But as far as I can see we don't have any tests for LDV stuff. There's a `bio001.stdout` which I believe is related with "biographical profiling"(which means LDV) but again AFAICS it's not used. (I'm not having any different behaviors or exceptions while running programs using LDV RTS arguments.) Can anyone help me with this? Is anyone using this feature? Am I right that this feature is not tested? Thanks. --- Ömer Sinan Ağacan http://osa1.net

2 1

Improving the Int/Word story inside GHC
by Johan Tibell 08 Aug '14

08 Aug '14

Inside GHC we mostly use Int instead of Word, even when we want to represent non-negative values, such as sizes of things or indices into things. This is now causing some grief in https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation boundary case test fails with a segfault because a n < m Int comparison overflows. I tried to fix the issue by changing the type of maxInlineAllocSize, which is used on one side of the above comparison, to Word. However, that unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are all Int-valued quantities. I could perhaps work around these problems by judicious use of fromIntegral in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the code uglier and 2) needs to be done in quite a few places. How much work would it be to try to switch the codegen to use Word for most of these quantities instead? -- Johan

5 15

Building GHC under Wine?
by Joachim Breitner 08 Aug '14

08 Aug '14

Hi, I feel sorry for Simon always repeatedly stuck with an unbuildable tree, and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it likely to catch the kind of problems that Simon is getting? If so, maybe it runs fast enough to be also tested by travis on every commit? (This mail is to find out if people have tried it before. If not, I’ll give it a quick shot.) Greetings, Joachim ¹ we surely can use it: http://www.haskell.org/haskellwiki/GHC_under_Wine -- 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

5 8

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