Re: gcc vs. clang builds of 7.8.3 on OS X
It won't work in our case because the gcc 4.9 build we have references it's own c rts lib, which is 4.9 specific, and is notably different than what is on a stock Mac Imagine if we were to ship a libHSrts.a, compiled against the gcc 4.9 libc (and it's includes). Now a user without gcc 4.9 on thier system, installs that bindist. And when they compile code that references libc, it'll compile against the system libc (and it's includes). If tha code is paired with Haskell code (or *is* Haskell code via the FFI), and is then linked with libHSrts.a from the bindist now we have an executable that has parts compiled against two different libc-s. This won't work unless the two libcs (and their includes) are ABI compatible which I don't know if it is between gcc's 4.9 libc, and the libc Apple ships for it's systems. On Sat, Jul 12, 2014 at 6:40 PM, Carter Schonwald carter.schonw...@gmail.com wrote: why wouldn't it work? heres my 4.9 gcc build, I believe it should work on any = 10.7 system that has xcode cli tools installed, please let me know if it fails! http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.3-x86_64-apple-darwin.tar.bz2 On Sat, Jul 12, 2014 at 9:04 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: I will try to measure on 10.7 later today. Preliminary numbers for gcc 4.9 are even better than clang - it saves 12% over gcc 4.2 builds. However, the gcc runtime isn't the same as the Apple standard... and we are so far at a loss how to package a ghc based on 4.9 that would work for Mac users without gcc 4.9. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: gcc vs. clang builds of 7.8.3 on OS X
The clang executable size mystery deepens: The sizes are indeed wy big: 7.4M test-files-clang/test* 4.5M test-files-clang/test-stripped* 1.4M test-files-gcc/test* 1.1M test-files-gcc/test-stripped* Looking at the load info from the stripped versions, it is all in the main text segment: test-files-clang/load test-files-gcc/load __TEXT.__text: 3,554,134 833,502 __TEXT.__stubs : 876 672 __TEXT.__stub_helper : 1,476 1,136 __TEXT.__const :59,04032,104 __TEXT.__cstring :24,15624,900 __TEXT.__dof_HaskellEv : 4,774 4,774 __TEXT.__eh_frame:22,97646,664 __DATA.__got : 1,264 880 __DATA.__nl_symbol_ptr :1616 __DATA.__la_symbol_ptr : 1,168 896 __DATA.__mod_init_func : 8 8 __DATA.__const : 130,04879,744 __DATA.__data: 231,84822,904 __DATA.__common :45,92446,092 __DATA.__bss : 856 840 TOTAL SIZE : 4,078,564 1,095,132 But, the compiled sizes are identical: 1.9K test-files-clang/Main.o 1.9K test-files-gcc/Main.o And, after dumping the link command, and looking up all the libs linked in (identical set in both cases), the clang libs are actually *smaller:* 13,004,272 ...clang.../lib/ghc-7.8.3/base-4.7.0.1/libHSbase-4.7.0.1.a 792,352 ...clang.../lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0.a 1,010,824 ...clang.../lib/ghc-7.8.3/integer-gmp-0.5.1.0/libHSinteger-gmp-0.5.1.0.a 55,816 ...clang.../lib/ghc-7.8.3/rts-1.0/libCffi.a 565,112 ...clang.../lib/ghc-7.8.3/rts-1.0/libHSrts.a 24,378,416 ...gcc.../lib/ghc-7.8.3/base-4.7.0.1/libHSbase-4.7.0.1.a 1,253,176 ...gcc.../lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0.a 1,014,280 ...gcc.../lib/ghc-7.8.3/integer-gmp-0.5.1.0/libHSinteger-gmp-0.5.1.0.a 57,984 ...gcc.../lib/ghc-7.8.3/rts-1.0/libCffi.a 556,432 ...gcc.../lib/ghc-7.8.3/rts-1.0/libHSrts.a So now I'm totally mystified! What is in that 3M of extra text segment?!?!? - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: gcc vs. clang builds of 7.8.3 on OS X
AHA! The clang libs weren't/aren't being built split-obj! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: gcc vs. clang builds of 7.8.3 on OS X
Found the culprit!!! XCodeVersion=`xcodebuild -version | grep Xcode | sed s/Xcode //` This line in configure doesn't work on a system that just the Xcode command line tools installed! It also won't work on an OS X system that has some other tool chain (say, via brew) installed. On such systems, itsets XCodeVersion to , which in tur The follow on code sets XCodeVersion1 and XCodeVersion2 to 0, and then this code runs, causing the problem: SplitObjsBroken=NO if test $TargetOS_CPP = darwin then # Split objects is broken (#4013) with XCode 3.2 if test $XCodeVersion1 -lt 3 then SplitObjsBroken=YES else if test $XCodeVersion1 -eq 3 then if test $XCodeVersion2 -lt 2 then SplitObjsBroken=YES fi fi fi fi Alas, it doesn't look like SplitObjsBroken has the logic to allow it to be overriden on the ./configure invocation (anyone know for sure? my autoconf is very rusty) Too late here for me to think of a fix - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell] ANNOUNCE: GHC version 7.8.3
On 2014-07-13 at 05:52:09 +0200, Bryan O'Sullivan wrote: [...] haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a bad interaction with cabal, it's hard to say from the outside, but here are some details. Here's the kind of error I get from haddock when I try to use cabal to install a package (primitive, in this case): module ‘primitive-0.5.3.0:Main’ is defined in multiple files: [...] The result is that I have no haddock docs for any packages now :-( I can't reproduce that here with a ghc-7.8.3/haddock-2.14.3 install on Linux. However, this sounds *alot* like a Clang/CPP issue, specifically https://github.com/haskell/cabal/issues/1740#issuecomment-39559026 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: unsafeShrinkMutableByteArray#
On 2014-07-12 at 17:40:07 +0200, Simon Marlow wrote: Yes, this will cause problems in some modes, namely -debug and -prof that need to be able to scan the heap linearly. ...and I assume we don't want to fallback to a non-zerocopy mode for -debug -prof in order avoid distorting the profiling measurements either? Usually we invoke the OVERWRITING_CLOSURE() macro which overwrites the original closure with zero words, but this won't work in your case because you want to keep the original contents. So you'll need a version of OVERWRITING_CLOSURE() that takes the size that you want to retain, and doesn't overwrite that part of the closure. This is probably a good idea anyway, because it might save some work in other places where we use OVERWRITING_CLOSURE(). I'm not sure I follow. What's the purpose of overwriting the original closure payload with zeros while in debug/profile mode? (and on what occasions that would be problematic for a MutableByteArray does it happen?) I am worried about sizeofMutableByteArray# though. It wouldn't be safe to call sizeofMutableByteArray# on the original array, just in case it was evaluated after the shrink. You could make things slightly safer by having unsafeShrinkMutableByteArray# return the new array, so that you have a safe way to call sizeofMutableByteArray# after the shrink. This still doesn't seem very satisfactory to me though. ...as a somewhat drastic obvious measure, one could change the type-sig of sizeofMutableByteArray# to :: MutableByteArray# s a - State# s - (# State# s, Int# #) and fwiw, I could find only one use-site of sizeofMutableByteArray# inside ghc.git, so I'm wondering if that primitive is used much anyway. btw, is it currently safe to call/evaluate sizeofMutableByteArray# on the original MBA after a unsafeFreezeByteArray# was performed? Otoh, if we are to thread a MutableByteArray# through the call anyway, can't we just combine shrinking and freezing in one primop (as suggested below)? [...] PS: maybe unsafeShrinkMutableByteArray# could unsafe-freeze the ByteArray# while at it (thus be called something like unsafeShrinkAndFreezeMutableByteArray#), as once I know the final smaller size I would freeze it anyway right after shrinking. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell] ANNOUNCE: GHC version 7.8.3
On 07/13/2014 01:06 PM, Miëtek Bak wrote: haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a bad interaction with cabal, it's hard to say from the outside, but here are some details. Here's the kind of error I get from haddock when I try to use cabal to install a package (primitive, in this case): module ‘primitive-0.5.3.0:Main’ is defined in multiple files: I can't reproduce that here with a ghc-7.8.3/haddock-2.14.3 install on Linux. However, this sounds *alot* like a Clang/CPP issue, specifically https://github.com/haskell/cabal/issues/1740#issuecomment-39559026 This is a Clang/CPP issue. A workaround is to pass `—ghc-options=-optP-P` to `cabal haddock`. The corresponding GHC issue was closed 5 weeks ago: https://ghc.haskell.org/trac/ghc/ticket/9174 Right, as pointed out, this has been hacked around in cabal. I was under the impression that the mentioned commit was going into whatever the next cabal version is and that it would be in the cabal distributed with 7.8.3. Is that not the case? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell] ANNOUNCE: GHC version 7.8.3
If this is happening on OS X and your computer is really clang (gcc -version will say clang somewhere) ... then please try this simple fix: Edit the compiler settings file, find the line with Haskell CPP Flags, and add -P to the list of flags. If that works, then the upcoming Haskell Platform release will take care of doing this, no need to hack this into cabal. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
On 06/30/2014 04:19 PM, Richard Eisenberg wrote: Thanks, Johan, for starting this discussion. I mostly agree with the proposal. However, one (at times, serious) drawback to using Haddock is that it means that editing comments can cause parse failures. The way the GHC build works, these failures may not be detected until the end of a hacking session (if I'm using, say, `make 2`, as I tend to do) and then can be hard to diagnose. I've actually been bitten by this when working on GHC. You should never get a parse failure anymore, as of 2.14.x versions. At worst, the comment will render in an ugly way but it will no longer cause failures due to typos in comment syntax. What might cause failures is if you put a Haddock comment where GHC doesn't expect it to. This should be fixed in GHC parser. If you don't want to mess around with pretty comments, all you have to do is to turn your function comments from ‘-- ’ to ’-- |’ and suddenly everyone else can benefit without source-diving. So, I have to ask: why use Haddock? Do folks read the Haddock docs for GHC? (I don't, but perhaps that's because the docs aren't so good right now.) Would it be acceptable to change this proposal not to require Haddock docs? I read the generated Haddock docs. The advantage of Haddock over something else here is that you can look at class instances, have clickable links and so on. Having to navigate on Haddock pages and reading the function docs elsewhere would be cluttered. Even if we decide to keep this proposal about Haddock docs specifically, I would strongly request that correct rendering of the Haddock docs not be scrutinized. At the end of a hacking session (which is hard enough to find time for, as is), I don't want to be expected to look through the generated HTML to make sure that my typewriter font and italics are rendering correctly. This is something of a corollary to Simon's comment about wanting to refer to Notes from Haddock comments -- I would want the Haddock output to be quite secondary to the proper documentation in the source code. (Note that this demotion of the role of Haddock is certainly not my practice in released libraries! But, Haddock is much less useful in an application like GHC than in a library.) GHC is also a library, I think it's unreasonable to expect people to jump into source and manually tracking down all the comments (if any) when they want to use GHC API. All that said, I do agree with the intent of this proposal and am happy to take on my part of the burden of documenting new (and perhaps some old) functions as I work. I have been very guilty of the broken window effect in not documenting new code. Thanks, Richard -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell] ANNOUNCE: GHC version 7.8.3
It was exactly the clang cpp issue. Since I didn't know what I was doing, I reinstalled GHC telling it to use cpphs (at Carter's suggestion), and that worked. Thanks! On Jul 13, 2014, at 7:35, Mark Lentczner mark.lentcz...@gmail.com wrote: If this is happening on OS X and your computer is really clang (gcc -version will say clang somewhere) ... then please try this simple fix: Edit the compiler settings file, find the line with Haskell CPP Flags, and add -P to the list of flags. If that works, then the upcoming Haskell Platform release will take care of doing this, no need to hack this into cabal. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell] ANNOUNCE: GHC version 7.8.3
Glad that worked for you... I'd like to be sure that my -P fix as part of the Platform fixes things. Can you point me to a small package that that haddock fails on? Then I can repro with the 7.8.3 bindist, and test the fix. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell] ANNOUNCE: GHC version 7.8.3
On Sun, Jul 13, 2014 at 10:08 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: I'd like to be sure that my -P fix as part of the Platform fixes things. Can you point me to a small package that that haddock fails on? Then I can repro with the 7.8.3 bindist, and test the fix. Haddock was failing on just about everything I tried - a suitably quick repro with no dependencies would be primitive. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC version 7.8.3
I'm just surprised that this wasn't caught before Would have been easy to fix. On Sunday, July 13, 2014, Bryan O'Sullivan b...@serpentine.com wrote: On Sun, Jul 13, 2014 at 10:08 AM, Mark Lentczner mark.lentcz...@gmail.com javascript:_e(%7B%7D,'cvml','mark.lentcz...@gmail.com'); wrote: I'd like to be sure that my -P fix as part of the Platform fixes things. Can you point me to a small package that that haddock fails on? Then I can repro with the 7.8.3 bindist, and test the fix. Haddock was failing on just about everything I tried - a suitably quick repro with no dependencies would be primitive. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC version 7.8.3
I'm pretty sure I tested on clang only though On Sunday, July 13, 2014, Carter Schonwald carter.schonw...@gmail.com wrote: I'm just surprised that this wasn't caught before Would have been easy to fix. On Sunday, July 13, 2014, Bryan O'Sullivan b...@serpentine.com javascript:_e(%7B%7D,'cvml','b...@serpentine.com'); wrote: On Sun, Jul 13, 2014 at 10:08 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: I'd like to be sure that my -P fix as part of the Platform fixes things. Can you point me to a small package that that haddock fails on? Then I can repro with the 7.8.3 bindist, and test the fix. Haddock was failing on just about everything I tried - a suitably quick repro with no dependencies would be primitive. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC version 7.8.3
Bryan: what version of cabal-install do you have? I suspect it might be because you have an older version of cabal install? On Sunday, July 13, 2014, Carter Schonwald carter.schonw...@gmail.com wrote: I'm pretty sure I tested on clang only though On Sunday, July 13, 2014, Carter Schonwald carter.schonw...@gmail.com javascript:_e(%7B%7D,'cvml','carter.schonw...@gmail.com'); wrote: I'm just surprised that this wasn't caught before Would have been easy to fix. On Sunday, July 13, 2014, Bryan O'Sullivan b...@serpentine.com wrote: On Sun, Jul 13, 2014 at 10:08 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: I'd like to be sure that my -P fix as part of the Platform fixes things. Can you point me to a small package that that haddock fails on? Then I can repro with the 7.8.3 bindist, and test the fix. Haddock was failing on just about everything I tried - a suitably quick repro with no dependencies would be primitive. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC version 7.8.3
On Sun, Jul 13, 2014 at 10:51 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Bryan: what version of cabal-install do you have? I suspect it might be because you have an older version of cabal install? I have the very latest version. I'll have to retry with clang's cpp, though, as cpphs prints annoying warnings during every compile :-( ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell] ANNOUNCE: GHC version 7.8.3
On Sun, Jul 13, 2014 at 10:08 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: I'd like to be sure that my -P fix as part of the Platform fixes things. Can you point me to a small package that that haddock fails on? Then I can repro with the 7.8.3 bindist, and test the fix. Using -P seems to work for me - thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HaRe and incremental type checking / type inference
Hello Alan, It's not clear what you're asking for here. What's keeping you from accessing the full power of the GHC type system? Richard On Jul 9, 2014, at 4:35 PM, AlanKim Zimmerman alan.z...@gmail.com wrote: I have hit a problem in HaRe when lifting a declaration from e.g. a where clause of a function to the top level, where there is a type signature of any complexity. e.g lifting 'baz' from function 'foo' below -- foo a = baz where baz :: Int baz = xx 1 a xx :: (Num t) = t - t - t xx p1 p2 = p1 + p2 -- becomes - foo a = (baz xx a) where xx :: (Num t) = t - t - t xx p1 p2 = p1 + p2 -- baz:: (forall t. Num t = t - t - t) - Int -Int baz :: Num a = (a - t1 - t) - t1 - t baz xx a= xx 1 a --- For a very small subset this can be calculated easily, but for full generality it would be great to access the full power of the GHC type system. So before diving in too deeply, I thought I would test the waters as to the feasibility of doing something like this. I was hoping that perhaps the effort at an external constraint solver might be making the interfacing slightly simpler. Regards Alan ___ ghc-devs mailing list 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: HaRe and incremental type checking / type inference
Sorry -- I'm still not sure what you mean. What AST are you working with? HsSyn RdrName? HsSyn Name? HsSyn Id? Core? And, in your original example, there is a commented-out type signature and then an uncommented-out one. Which are you trying to generate? Would the recent partial type signature work help you? (I don't think it's in HEAD yet.) Perhaps give the type of a function in the GHC API that you would like to have... Richard On Jul 13, 2014, at 4:31 PM, AlanKim Zimmerman alan.z...@gmail.com wrote: Basically I want to be able to make a few small changes to an already type checked AST and then query the type system, similar to what is possible with typed holes. So in my example I would like to move baz to the top level, and then invoke the type checker to get the required signature, without having to convert the partial result back to source and re-run the entire compilation. Alan On Sun, Jul 13, 2014 at 10:21 PM, Richard Eisenberg e...@cis.upenn.edu wrote: Hello Alan, It's not clear what you're asking for here. What's keeping you from accessing the full power of the GHC type system? Richard On Jul 9, 2014, at 4:35 PM, AlanKim Zimmerman alan.z...@gmail.com wrote: I have hit a problem in HaRe when lifting a declaration from e.g. a where clause of a function to the top level, where there is a type signature of any complexity. e.g lifting 'baz' from function 'foo' below -- foo a = baz where baz :: Int baz = xx 1 a xx :: (Num t) = t - t - t xx p1 p2 = p1 + p2 -- becomes - foo a = (baz xx a) where xx :: (Num t) = t - t - t xx p1 p2 = p1 + p2 -- baz:: (forall t. Num t = t - t - t) - Int -Int baz :: Num a = (a - t1 - t) - t1 - t baz xx a= xx 1 a --- For a very small subset this can be calculated easily, but for full generality it would be great to access the full power of the GHC type system. So before diving in too deeply, I thought I would test the waters as to the feasibility of doing something like this. I was hoping that perhaps the effort at an external constraint solver might be making the interfacing slightly simpler. Regards Alan ___ ghc-devs mailing list 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
