- ghc-devs - Haskell.org

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

Re: I've moved the primitive package to github
by Roman Leshchinskiy 25 Sep '13

25 Sep '13

Can't post to ghc-devs from the other address so here it is again... I'm awfully sorry to have gone silent but I just can't find the time for hacking any longer. If someone wants to take over primitive and vector please feel free to do so, I'd be very grateful. Roman On 24/09/13 14:30, Bryan O'Sullivan wrote: > Roman seems to have gone silent, and primitive being broken with GHC > HEAD means that there's a ton of packages we can't build right now. > > Accordingly, I've imported the old darcs repo into git and published it > on github. > > https://github.com/haskell/primitive > > Austin, please plan to fix the GHC build to get its copy of primitive > from here, once we have it working with HEAD.

1 0

[PATCH] Fix user guide documentation about unboxed values
by Arash Rouhani 24 Sep '13

24 Sep '13

Signed-off-by: Arash Rouhani <rarash(a)student.chalmers.se> --- docs/users_guide/glasgow_exts.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml index a8057a6..43fa155 100644 --- a/docs/users_guide/glasgow_exts.xml +++ b/docs/users_guide/glasgow_exts.xml @@ -272,7 +272,7 @@ If the types of <literal>p</literal> and <literal>q</literal> are not unboxed, the resulting binding is lazy like any other Haskell pattern binding. The above example desugars like this: <programlisting> - f x = let t = case h x o f{ (# p,q #) -> (p,q) + f x = let t = case h x of { (# p,q #) -> (p,q) } p = fst t q = snd t in ..body.. -- 1.8.1.2

2 1