Re: Adding Doxygen (or other documentation tool) comments to GHC patches?

2014-04-24 Thread Carter Tazio Schonwald
hey howard, somehow your emails keep on going to my spam folder!

https://ghc.haskell.org/trac/ghc/ticket/9021 right? Im not sure if theres any 
docs convention for the C code in ghc, 
perhaps simon marlow or austin can chime in?


On Thu, Apr 24, 2014 at 12:45 PM, Howard B. Golden mailto:howard_b_gol...@yahoo.com)> wrote:
> Hi, I am working on a patch for GHC Trac ticket #9021. I wonder whether it 
> would be welcome or unwelcome to include Doxygen (or other documentation 
> tool) comments in the patch? If another tool is preferred, please recommend 
> it. Thanks.
> 
> Howard B. Golden
> Northridge, CA
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org (mailto:ghc-devs@haskell.org)
> http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Executables using GHC API require dynamic linking in GHC 7.7

2013-09-28 Thread Carter Tazio Schonwald
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.a' and the 
> 'libHS.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  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  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  (mailto:carter.schonw...@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-us...@haskell.org
> > > http://www.haskell.org/mailman/listinfo/glasg