September 2013 - ghc-devs

Make compiler_stage2_dll0_MODULES multi-line
by Dr. ERDI Gergo 28 Sep '13

28 Sep '13

Hi, Currently, compiler_stage2_dll0_MODULES is defined on a single line in compiler/ghc.mk. This means at least on git, any two changes to it on separate branches results in a merge conflict (I don't know if darcs handles same-line changes better). Is there any reason we don't change it to multiple lines (with escaped trailing newlines) so that git can merge changes? Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' "Last week, I left my 2 XP CD's on my dashboard in plain view. Someone broke into my car and left 2 more." -- /.

1 0

Re: [GHC] #8371: ghci byte compiler + FFI crashes when used with embedded R
by Dominick Samperi 28 Sep '13

28 Sep '13

Thanks! Turning off R's stack limit checks will not work. I tried this and this leads to a segfault. Fortunately, your experiments led me to a work-around: simply use the -fno-ghci-sandbox flag. R is not thread-safe, and this flag tells ghci to run computations in the main thread instead of forking. On Sat, Sep 28, 2013 at 1:29 AM, GHC <ghc-devs(a)haskell.org> wrote: > #8371: ghci byte compiler + FFI crashes when used with embedded R > -------------------------------+---------------------------------- > Reporter: dsamperi | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: GHCi | Version: 7.6.3 > Resolution: | Keywords: > Operating System: Linux | Architecture: x86_64 (amd64) > Type of failure: GHCi crash | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: > -------------------------------+---------------------------------- > > Comment (by rwbarton): > > I can reproduce this without ghci, by putting a forkIO around the body of > main (and adding a threadDelay in the main thread). > > It seems to just be an interaction between R's method for determining the > base address of the stack and the way pthread allocates stacks for new > threads. Try this C example program `pt.c`. > > {{{ > #include <stdio.h> > #include <unistd.h> > #include <pthread.h> > > int Rf_initEmbeddedR(int argc, char **argv); > > void *foo(void *blah) > { > char *args[] = {"pt", "--gui=none", "--silent", "--vanilla"}; > int r; > setenv("R_HOME", "/usr/lib/R", 1); > r = Rf_initEmbeddedR(sizeof(args)/sizeof(args[0]), args); > printf("r = %d\n", r); > } > > int main(void) > { > pthread_t tid; > pthread_create(&tid, NULL, foo, NULL); > while (1) > sleep(1); > return 0; > } > }}} > > {{{ > rwbarton@adjunction:/tmp$ gcc -o pt pt.c -lpthread -lR > rwbarton@adjunction:/tmp$ ./pt > Error: C stack usage is too close to the limit > Error: C stack usage is too close to the limit > r = 1 > }}} > > It would probably be best to just disable R's stack limit checks, if > possible. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8371#comment:6> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

2 3

Re: Executables using GHC API require dynamic linking in GHC 7.7
by Carter Tazio Schonwald 28 Sep '13

28 Sep '13

please report this issue on ghc trac and all the relevant information there in. That is the best way to promptly get folks to see it -Carter On Saturday, September 28, 2013 at 2:55 AM, Christiaan Baaij wrote: > Yes, I have both the static libs and the dynamic libs. > So for every library I have both the 'libHS<PACKAGE-VERSION>.a' and the 'libHS<PACKAGE-VERSION-ghc<GHCVERSION>.dylib' files. > And for all the compiled modules I have both the '.hi' and '.dyn_hi' files. > > So to be clear: > - I have both the static and dynamic versions of all libraries/packages > > - I built a statically-linked executable by setting 'executable-dynamic' in my '.cabal/config' file explicitly to 'False' > - otool -L <EXE> confirms that the executable is indeed statically linked > - Running the statically-linked executable that uses the GHC API, where the GHC API does dynamic linking (e.g. TH) => Segfault > > - I built a dynamically-linked executable setting 'executable-dynamic' in my '.cabal/config' file explicitly to 'True' > - otool -L <EXE> confirms that the executable is indeed dynamically linked. > - Running the dynamically-linked binary that uses the GHC API, where the GHC API does dynamic linking => No problem, behaves normally > > So the problem is not that TH is not working/segfaulting, the problem is that I get segfaults when a statically linked executable does dynamic linking. > At least on OS X. > > -- Christiaan > > > > On Sat, Sep 28, 2013 at 4:23 AM, Carter Schonwald <carter.schonwald(a)gmail.com (mailto:carter.schonwald@gmail.com)> wrote: > > Hey Christian, did you build ghc and libs I both Dylib and static ways? TH uses ghci, and ghci on OS X and a few other platforms uses the system dylinker, so it may be that you've only built certain libs the static way, but ghci requires the dynamic way as of 7.7 > > > > Please let me know if that helps. > > > > > > > > > > On Friday, September 27, 2013, Christiaan Baaij wrote: > > > Dear all, > > > > > > It seems that executables that use the GHC API require to be dynamically linked on GHC 7.7. > > > At least in the case that an GHC API function has to perform linking. > > > Statically linked executable SEGFAULT when a GHC API function tries to do linking. > > > > > > I build 'haddock' from source by doing a 'cabal install' in the 'utils/haddock' directory of my ghc build tree. > > > Here is the output of my statically linked haddock when I run it on one of my libraries: > > > Haddock coverage: > > > Warning: main:CLaSH.Util: Could not find documentation for exported module: X > > > Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses > > > 95% ( 18 / 19) in 'CLaSH.Util' > > > 100% ( 8 / 8) in 'CLaSH.Core.TyCon' > > > 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' > > > 100% ( 5 / 5) in 'CLaSH.Core.DataCon' > > > 100% ( 3 / 3) in 'CLaSH.Core.Literal' > > > 100% ( 5 / 5) in 'CLaSH.Core.Var' > > > Bus error: 10 <-- SEGFAULT > > > > > > Here is the output of my dynamically linked haddock when I run it on one of my libraries: > > > Haddock coverage: > > > Warning: main:CLaSH.Util: Could not find documentation for exported module: X > > > Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses > > > 95% ( 18 / 19) in 'CLaSH.Util' > > > 100% ( 8 / 8) in 'CLaSH.Core.TyCon' > > > 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' > > > 100% ( 5 / 5) in 'CLaSH.Core.DataCon' > > > 100% ( 3 / 3) in 'CLaSH.Core.Literal' > > > 100% ( 5 / 5) in 'CLaSH.Core.Var' > > > 100% ( 5 / 5) in 'CLaSH.Core.Term' > > > 100% ( 8 / 8) in 'CLaSH.Core.Subst' > > > 100% ( 24 / 24) in 'CLaSH.Core.Type' > > > <… lots of warnings about missing link destination … > > > > ~/Documents/devel/clash/src (master *)$ > > > > > > I believe that the use of TH in the CLaSH.Core.Var file triggers the segfault in the statically linked version. > > > I'm trying to create a smaller test case than running haddock on my library, but have been unsuccessful so far. > > > That is why I haven't posted a bug report on the bug tracker yet. > > > If somebody thinks I should, then please say so :-) > > > > > > My platform is: > > > OS: OS X 10.8.5 > > > XCode: X-Code CL-tools 4.6.2 > > > GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546) > > > Build.mk: > > > SRC_HC_OPTS = -O -H64m > > > GhcStage1HcOpts = -O -fasm > > > GhcStage2HcOpts = -O2 -fasm > > > GhcHcOpts = -Rghc-timing > > > GhcLibHcOpts = -O2 > > > HADDOCK_DOCS = NO > > > > > > I hope somebody can test this on linux with dynamic linking. > > > As this bug affects haddock, I think it is quite important that somebody with more knowledge of dynamic linking looks into this. > > > > > > Regards, > > > > > > Christiaan > > > > > > > > > > > > _______________________________________________ > > > Glasgow-haskell-users mailing list > > > Glasgow-haskell-users(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 1

Re: [GHC] #8173: GHC uses nub
by Kim-Ee Yeoh 27 Sep '13

27 Sep '13

On Fri, Sep 27, 2013 at 8:14 PM, GHC <ghc-devs(a)haskell.org> wrote: > A 5% improvement in compile time is remarkable, if it's true. Great! But > I'm always worried about the noise in compile times measured in seconds. > Does anyone else think the noise in runtimes is alarming considering that the following is the fib-analysis of /binary-identical/ programs? > Min -0.1% -0.0% -25.4% -32.2% -1.3% > Max +0.1% +0.0% +19.0% +22.2% +10.0% Shouldn't we find an explanation for this before believing the compile time numbers? What would cause these wide swings on the benchmarking machine? p.s. For the record: Should do more rigorous statistical testing instead of naive percentages, yes? -- Kim-Ee

2 2

Trac emails for CC additions
by Simon Marlow 27 Sep '13

27 Sep '13

Can we stop Trac from sending an email when someone adds themselves to the CC list of a ticket, without making any other changes to the ticket? It's hard to filter these automatically. Cheers, Simon

2 1

recomp013
by Simon Peyton-Jones 27 Sep '13

27 Sep '13

I'm getting the failure below for recomp013. Any ideas? It was added by Joachim: commit b1f6cab360faf79d586eda8ee3c1c486e53d0066 Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Tue Sep 17 22:37:51 2013 +0200 Recompilation test case for #8247 Joachim: when you have a test for a ticket, please use "T8247" as the test name. Much easier to track back! Thanks. Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

6 10

Trac DefaultCcPlugin
by Simon Marlow 27 Sep '13

27 Sep '13

Could we install this plugin in the Trac please? http://trac-hacks.org/wiki/DefaultCcPlugin This will mean that I can be automatically added to the CC list of any ticket where the component is set to "Runtime System", for example. Cheers, Simon

1 0

Re: [commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)
by Johan Tibell 26 Sep '13

26 Sep '13

Having coerce (!) show up in such a commonly used type class is a bit alarming. Was there a libraries discussion about this? At least we should add some docs to the method. On Wed, Sep 25, 2013 at 12:37 AM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/3da4fd92e005cb9348ab2852d9268ad61… > >>--------------------------------------------------------------- > > commit 3da4fd92e005cb9348ab2852d9268ad61ae1b347 > Author: Austin Seipp <austin(a)well-typed.com> > Date: Tue Sep 24 23:20:35 2013 -0500 > > Add fmapCoerce to Functor class. > > This allows coercions to work under functors that are not locally known. > > Authored-by: Edward Kmett <ekmett(a)gmail.com> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >>--------------------------------------------------------------- > > 3da4fd92e005cb9348ab2852d9268ad61ae1b347 > GHC/Base.lhs | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/GHC/Base.lhs b/GHC/Base.lhs > index d876202..55172af 100644 > --- a/GHC/Base.lhs > +++ b/GHC/Base.lhs > @@ -105,7 +105,6 @@ module GHC.Base > module GHC.Err -- import it explicitly > ) > where > - > import GHC.Types > import GHC.Classes > import GHC.CString > @@ -186,6 +185,9 @@ class Functor f where > (<$) :: a -> f b -> f a > (<$) = fmap . const > > + fmapCoerce :: Coercible a b => f a -> f b > + fmapCoerce = fmap coerce > + > {- | The 'Monad' class defines the basic operations over a /monad/, > a concept from a branch of mathematics known as /category theory/. > From the perspective of a Haskell programmer, however, it is best to > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

7 7

Incorrect Binding in GHCi (trac #6098)
by Paul Cavallaro 25 Sep '13

25 Sep '13

Hey All, I'm trying to get up and running on this bug, but largely seem to be chasing my tail. I've tried turning on -ddump-tc and -ddump-tc-trace and followed the output there (git grepped through code), and explored around, but any sort of high level advice for chasing this bug down would be awesome. (And sorry for the lack of actionable info on my end) Thanks, -Paul

1 0

RE: [commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)
by Simon Peyton-Jones 25 Sep '13

25 Sep '13

This is great, but does needs some explanatory material, on the Haskell wiki or Trac. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 25 September 2013 05:38 | To: ghc-commits(a)haskell.org | Subject: [commit: packages/base] master: Add fmapCoerce to Functor | class. (3da4fd9) | | Repository : ssh://git@git.haskell.org/base | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3da4fd92e005cb9348ab2852d9268a | d61ae1b347/base | | >--------------------------------------------------------------- | | commit 3da4fd92e005cb9348ab2852d9268ad61ae1b347 | Author: Austin Seipp <austin(a)well-typed.com> | Date: Tue Sep 24 23:20:35 2013 -0500 | | Add fmapCoerce to Functor class. | | This allows coercions to work under functors that are not locally | known. | | Authored-by: Edward Kmett <ekmett(a)gmail.com> | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 3da4fd92e005cb9348ab2852d9268ad61ae1b347 | GHC/Base.lhs | 4 +++- | 1 file changed, 3 insertions(+), 1 deletion(-) | | diff --git a/GHC/Base.lhs b/GHC/Base.lhs | index d876202..55172af 100644 | --- a/GHC/Base.lhs | +++ b/GHC/Base.lhs | @@ -105,7 +105,6 @@ module GHC.Base | module GHC.Err -- import it explicitly | ) | where | - | import GHC.Types | import GHC.Classes | import GHC.CString | @@ -186,6 +185,9 @@ class Functor f where | (<$) :: a -> f b -> f a | (<$) = fmap . const | | + fmapCoerce :: Coercible a b => f a -> f b | + fmapCoerce = fmap coerce | + | {- | The 'Monad' class defines the basic operations over a /monad/, | a concept from a branch of mathematics known as /category theory/. | From the perspective of a Haskell programmer, however, it is best to | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0