Re: Can't build 8.6.1-beta1 with debugging.
Hi, I was able to get GHC to compile with the patch in your ticket. Thanks! -- Mateusz K. On Tue, 14 Aug 2018, at 9:08 AM, Ömer Sinan Ağacan wrote: > Hi Mateusz, > > > /usr/bin/ld.gold: error: cannot find -lHSrts_thr_debug_p > > We currently don't ship GHC with profiling + debug + threaded runtime. See my > previous email on this: > https://mail.haskell.org/pipermail/ghc-devs/2018-July/015982.html > > I show a way to enable these runtimes in > https://ghc.haskell.org/trac/ghc/ticket/15508 > > Hope this helps, > > Ömer > > Mateusz Kowalczyk , 14 Ağu 2018 Sal, 09:19 > tarihinde şunu yazdı: > > > > Hi all, > > > > I wanted to try our codebase with 8.6. I happened to already have > > 8.6.0.20180714 ready so I started with that. > > > > Compilation went well but I got a segfault when running a benchmark we have > > with profiling on. GDB told me the segfault was in stg_ap_p_info in > > AutoApply.cmm which as I understand is generated. Strange but OK... I > > decided to try unprofiled with LLVM to see if some LLVM issue we had with > > current version (7.10.x) has gone away. Sadly I encountered a segfault > > during regular compilation (clean build, LLVM 6.0). I had no debugging > > symbols. > > > > Next I decided to try the beta1 version. I copied mk/build.mk.sample into > > mk/build.mk and added the following: > > > > GhcDebugged = YES > > GhcStage1HcOpts = -DDEBUG > > GhcStage2HcOpts = -DDEBUG > > > > I checked out the 8.6.1-beta1 tag then ran following. > > > > fuuzetsu@rubin:~/programming/ghc$ echo $PREFIX > > /usr/local/ghc/ghc-8.6.1-beta1 > > fuuzetsu@rubin:~/programming/ghc$ ./configure --prefix=$PREFIX && make -j4 > > && make install > > > > After some time I was met with: > > > > /usr/bin/ld.gold: error: cannot find -lHSrts_thr_debug_p > > > > Also a long chain of messages about undefined refs you can find at [1]. > > > > Considering I haven't touched any settings beyond adding debug flags, it > > surprised me a little that I can't build successfully. Please advise and > > feel free to ask for any specs. > > > > uname -a: > > Linux rubin.tsuru.it 4.15.0-30-generic #32~16.04.1-Ubuntu SMP Thu Jul 26 > > 20:25:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > > > > > > [1]: https://gist.github.com/Fuuzetsu/7a65a963dd625386d13938ba1e22af5c > > > > -- > > Mateusz K. > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Can't build 8.6.1-beta1 with debugging.
Hi all, I wanted to try our codebase with 8.6. I happened to already have 8.6.0.20180714 ready so I started with that. Compilation went well but I got a segfault when running a benchmark we have with profiling on. GDB told me the segfault was in stg_ap_p_info in AutoApply.cmm which as I understand is generated. Strange but OK... I decided to try unprofiled with LLVM to see if some LLVM issue we had with current version (7.10.x) has gone away. Sadly I encountered a segfault during regular compilation (clean build, LLVM 6.0). I had no debugging symbols. Next I decided to try the beta1 version. I copied mk/build.mk.sample into mk/build.mk and added the following: GhcDebugged = YES GhcStage1HcOpts = -DDEBUG GhcStage2HcOpts = -DDEBUG I checked out the 8.6.1-beta1 tag then ran following. fuuzetsu@rubin:~/programming/ghc$ echo $PREFIX /usr/local/ghc/ghc-8.6.1-beta1 fuuzetsu@rubin:~/programming/ghc$ ./configure --prefix=$PREFIX && make -j4 && make install After some time I was met with: /usr/bin/ld.gold: error: cannot find -lHSrts_thr_debug_p Also a long chain of messages about undefined refs you can find at [1]. Considering I haven't touched any settings beyond adding debug flags, it surprised me a little that I can't build successfully. Please advise and feel free to ask for any specs. uname -a: Linux rubin.tsuru.it 4.15.0-30-generic #32~16.04.1-Ubuntu SMP Thu Jul 26 20:25:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [1]: https://gist.github.com/Fuuzetsu/7a65a963dd625386d13938ba1e22af5c -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: FFI-free NaN checks? (isDoubleNan and friends)
On 03/06/2018 10:43 AM, Brandon Allbery wrote:
> I'd in general expect good C code to optimize a little better; and in
> particular, decomposing an IEEE float is almost certainly more expensive in
> Haskell than in C, because unions let you cheat. (And I recall looking at
> the implementation of decodeFloat once; it's significantly longer than that
> C.) But I have to wonder if that code would be better done with something
> more native; the implementation may be a portable default, and you might be
> able to find something x86-specific that is faster.
There's a https://c9x.me/x86/html/file_module_x86_id_316.html that the
‘d /= d’ way compiles to. I suppose maybe I could just keep using that
and fall back onto isDoubleNaN if __FAST_MATH__ is set…
> On Tue, Mar 6, 2018 at 5:35 AM, Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk>
> wrote:
>
>> On 03/05/2018 10:23 PM, Brandon Allbery wrote:
>>> If the FFI version is done with "safe", consider using "unsafe" instead.
>>> There are technical reasons why this is slightly incorrect, but unless
>>> you're fiddling with the CPU's FP control flags they're mostly irrelevant
>>> and you can treat isNaN as pure and non-side-effectful, significantly
>>> reducing the overhead. You may also be able to use "ccall" to take
>>> advantage of C compiler level optimizations, or simply to directly
>> invoke a
>>> CPU-based test with asm(); but you'll need to hide that in a C
>> preprocessor
>>> #define, so that it looks syntactically like a function call to the FFI.
>>>
>>> (One of the technical reasons is that various OSes have been known to
>>> introduce bugs in their FP register and state handling across system
>> calls,
>>> in which case the "safe" version may turn "complete FP chaos" into merely
>>> "wrong answer". It's your call whether, or which side, of this bothers
>> you.)
>>
>> Perhaps I was a little unclear. The FFI-using isDoubleNaN is something
>> GHC does!
>>
>> ```
>> libraries/base/GHC/Float.hs:foreign import ccall unsafe "isDoubleNaN"
>> isDoubleNaN :: Double -> Int
>> ```
>> ```
>> HsInt
>> isDoubleNaN(HsDouble d)
>> {
>> union stg_ieee754_dbl u;
>>
>> u.d = d;
>>
>> return (
>> u.ieee.exponent == 2047 /* 2^11 - 1 */ && /* Is the exponent all
>> ones? */
>> (u.ieee.mantissa0 != 0 || u.ieee.mantissa1 != 0)
>> /* and the mantissa non-zero? */
>> );
>> }
>> ```
>>
>> My question is whether it could do better by not doing FFI and instead
>> computing natively and if not, why not?
>>
>>> On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk <
>> fuuze...@fuuzetsu.co.uk>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Recently at a client I was profiling some code and isDoubleNaN lit up.
>>>> We were checking a lot of doubles for NaN as that's what customer would
>>>> send in.
>>>>
>>>> I went to investigate and I found that FFI is used to achieve this. I
>>>> was always under the impression that FFI costs a little. I had at the
>>>> time replaced the code with a hack with great results:
>>>>
>>>> ```
>>>> isNaN' :: Double -> Bool
>>>> isNaN' d = d /= d
>>>> ```
>>>>
>>>> While this worked and provided good speedup in my case, this fails
>>>> catastrophically if the program is compiled with -ffast-math. This is
>>>> expected. I have since reverted it. Seeking an alternative solution I
>>>> have thought about re-implementing the C code with a native Haskell
>>>> version: after all it just checks a few bits. Apparently unsafeCoerce#
>>>> and friends were a big no-no but I found
>>>> https://phabricator.haskell.org/D3358 . I have implemented the code at
>>>> the bottom of this post. Obviously it's missing endianness (compile-time
>>>> switch).
>>>>
>>>> This seems to be faster for smaller `mkInput` list than Prelude.isNaN
>>>> but slower slightly on the one below. The `/=` version is the fastest
>>>> but very fragile.
>>>>
>>>> My question to you all is whether implementing a version of this
>>>> function in Haskell makes sense and if not, why not? The
>>>> stgDoubleToWord64 is implemented in CMM and I don't know anything about
>>>> the costs of that.
>>>>
>>>> * Is there
Re: FFI-free NaN checks? (isDoubleNan and friends)
On 03/05/2018 10:23 PM, Brandon Allbery wrote:
> If the FFI version is done with "safe", consider using "unsafe" instead.
> There are technical reasons why this is slightly incorrect, but unless
> you're fiddling with the CPU's FP control flags they're mostly irrelevant
> and you can treat isNaN as pure and non-side-effectful, significantly
> reducing the overhead. You may also be able to use "ccall" to take
> advantage of C compiler level optimizations, or simply to directly invoke a
> CPU-based test with asm(); but you'll need to hide that in a C preprocessor
> #define, so that it looks syntactically like a function call to the FFI.
>
> (One of the technical reasons is that various OSes have been known to
> introduce bugs in their FP register and state handling across system calls,
> in which case the "safe" version may turn "complete FP chaos" into merely
> "wrong answer". It's your call whether, or which side, of this bothers you.)
Perhaps I was a little unclear. The FFI-using isDoubleNaN is something
GHC does!
```
libraries/base/GHC/Float.hs:foreign import ccall unsafe "isDoubleNaN"
isDoubleNaN :: Double -> Int
```
```
HsInt
isDoubleNaN(HsDouble d)
{
union stg_ieee754_dbl u;
u.d = d;
return (
u.ieee.exponent == 2047 /* 2^11 - 1 */ && /* Is the exponent all
ones? */
(u.ieee.mantissa0 != 0 || u.ieee.mantissa1 != 0)
/* and the mantissa non-zero? */
);
}
```
My question is whether it could do better by not doing FFI and instead
computing natively and if not, why not?
> On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk>
> wrote:
>
>> Hi,
>>
>> Recently at a client I was profiling some code and isDoubleNaN lit up.
>> We were checking a lot of doubles for NaN as that's what customer would
>> send in.
>>
>> I went to investigate and I found that FFI is used to achieve this. I
>> was always under the impression that FFI costs a little. I had at the
>> time replaced the code with a hack with great results:
>>
>> ```
>> isNaN' :: Double -> Bool
>> isNaN' d = d /= d
>> ```
>>
>> While this worked and provided good speedup in my case, this fails
>> catastrophically if the program is compiled with -ffast-math. This is
>> expected. I have since reverted it. Seeking an alternative solution I
>> have thought about re-implementing the C code with a native Haskell
>> version: after all it just checks a few bits. Apparently unsafeCoerce#
>> and friends were a big no-no but I found
>> https://phabricator.haskell.org/D3358 . I have implemented the code at
>> the bottom of this post. Obviously it's missing endianness (compile-time
>> switch).
>>
>> This seems to be faster for smaller `mkInput` list than Prelude.isNaN
>> but slower slightly on the one below. The `/=` version is the fastest
>> but very fragile.
>>
>> My question to you all is whether implementing a version of this
>> function in Haskell makes sense and if not, why not? The
>> stgDoubleToWord64 is implemented in CMM and I don't know anything about
>> the costs of that.
>>
>> * Is there a cheaper alternative to FFI way?
>> * If yes, does anyone know how to write it such that it compiles to same
>> code but without the call overhead? I must have failed below as it's
>> slower on some inputs.
>>
>> Basically if a faster way exists for isNaN, something I have to do a
>> lot, I'd love to hear about it.
>>
>> I leave you with basic code I managed to come up with. 8.4.x only.
>>
>>
>> ```
>> {-# LANGUAGE MagicHash#-}
>> {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-}
>> module Main (main) where
>>
>> import GHC.Float
>> import GHC.Prim
>>
>> isNaN' :: Double -> Bool
>> isNaN' d = d /= d
>>
>> isNaNBits :: Double -> Bool
>> isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of
>> 1# -> case bits `and#` mantissaMask of
>> 0## -> False
>> _ -> True
>> _ -> False
>> where
>> bits :: Word#
>> bits = stgDoubleToWord64 d
>>
>> expMask, mantissaMask :: Word#
>> expMask = 0x7FF0##
>> mantissaMask = 0x000F##
>>
>> main :: IO ()
>> main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 1)
>> `seq` pure ()
>> where
>> nan :: Double
>> nan = log (-1)
>>
>> mkInput :: Int -> [Double]
>> mkInput n = take n $ cycle [1, nan]
>>
>> sumFilter :: (Double -> Bool) -> [Double] -> Double
>> sumFilter p = Prelude.sum . Prelude.filter (not . p)
>> ```
>>
>> --
>> Mateusz K.
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>
--
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
FFI-free NaN checks? (isDoubleNan and friends)
Hi,
Recently at a client I was profiling some code and isDoubleNaN lit up.
We were checking a lot of doubles for NaN as that's what customer would
send in.
I went to investigate and I found that FFI is used to achieve this. I
was always under the impression that FFI costs a little. I had at the
time replaced the code with a hack with great results:
```
isNaN' :: Double -> Bool
isNaN' d = d /= d
```
While this worked and provided good speedup in my case, this fails
catastrophically if the program is compiled with -ffast-math. This is
expected. I have since reverted it. Seeking an alternative solution I
have thought about re-implementing the C code with a native Haskell
version: after all it just checks a few bits. Apparently unsafeCoerce#
and friends were a big no-no but I found
https://phabricator.haskell.org/D3358 . I have implemented the code at
the bottom of this post. Obviously it's missing endianness (compile-time
switch).
This seems to be faster for smaller `mkInput` list than Prelude.isNaN
but slower slightly on the one below. The `/=` version is the fastest
but very fragile.
My question to you all is whether implementing a version of this
function in Haskell makes sense and if not, why not? The
stgDoubleToWord64 is implemented in CMM and I don't know anything about
the costs of that.
* Is there a cheaper alternative to FFI way?
* If yes, does anyone know how to write it such that it compiles to same
code but without the call overhead? I must have failed below as it's
slower on some inputs.
Basically if a faster way exists for isNaN, something I have to do a
lot, I'd love to hear about it.
I leave you with basic code I managed to come up with. 8.4.x only.
```
{-# LANGUAGE MagicHash#-}
{-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-}
module Main (main) where
import GHC.Float
import GHC.Prim
isNaN' :: Double -> Bool
isNaN' d = d /= d
isNaNBits :: Double -> Bool
isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of
1# -> case bits `and#` mantissaMask of
0## -> False
_ -> True
_ -> False
where
bits :: Word#
bits = stgDoubleToWord64 d
expMask, mantissaMask :: Word#
expMask = 0x7FF0##
mantissaMask = 0x000F##
main :: IO ()
main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 1)
`seq` pure ()
where
nan :: Double
nan = log (-1)
mkInput :: Int -> [Double]
mkInput n = take n $ cycle [1, nan]
sumFilter :: (Double -> Bool) -> [Double] -> Double
sumFilter p = Prelude.sum . Prelude.filter (not . p)
```
--
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Testsuite: recenter haddock.base allocation numbers (1b76997)
On 07/22/2015 05:35 PM, Simon Peyton Jones wrote:
Could it be creeping up because Haddock is doing more than before? Ie not
just because GHC is being bad?
S
Yes, it very much could be. Haddock is a moving target so it's not too
weird that the numbers change. I want to say that the perf test should
just be removed but it's still useful: if you're GHC hacking and not
changing Haddock and numbers go awry then it serves its purpose.
Ideally GHC would have more perf tests so the Haddock perf test is just
not necessary but it's not easy to tell when that would be.
| -Original Message-
| From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf
| Of g...@git.haskell.org
| Sent: 22 July 2015 17:33
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Testsuite: recenter haddock.base
| allocation numbers (1b76997)
|
| Repository : ssh://g...@git.haskell.org/ghc
|
| On branch : master
| Link :
| http://ghc.haskell.org/trac/ghc/changeset/1b76997dba5c35ee956960e1948e
| e247dc57c500/ghc
|
| ---
|
| commit 1b76997dba5c35ee956960e1948ee247dc57c500
| Author: Thomas Miedema thomasmied...@gmail.com
| Date: Wed Jul 22 18:21:44 2015 +0200
|
| Testsuite: recenter haddock.base allocation numbers
|
|
| ---
|
| 1b76997dba5c35ee956960e1948ee247dc57c500
| testsuite/tests/perf/haddock/all.T | 3 ++-
| 1 file changed, 2 insertions(+), 1 deletion(-)
|
| diff --git a/testsuite/tests/perf/haddock/all.T
| b/testsuite/tests/perf/haddock/all.T
| index 94f7cbd..1e5a16c 100644
| --- a/testsuite/tests/perf/haddock/all.T
| +++ b/testsuite/tests/perf/haddock/all.T
| @@ -5,7 +5,7 @@
| test('haddock.base',
|[unless(in_tree_compiler(), skip), req_haddock
|,stats_num_field('bytes allocated',
| - [(wordsize(64), 9014511528, 5)
| + [(wordsize(64), 9418857192, 5)
| # 2012-08-14: 5920822352 (amd64/Linux)
| # 2012-09-20: 5829972376 (amd64/Linux)
| # 2012-10-08: 5902601224 (amd64/Linux) @@ -23,6 +23,7 @@
| test('haddock.base',
| # 2014-10-07: 8322584616 (x86_64/Linux)
| # 2014-12-14: 9502647104 (x86_64/Linux) - Update to
| Haddock 2.16
| # 2014-01-08: 9014511528 (x86_64/Linux) - Eliminate so-
| called silent superclass parameters (and others)
| +# 2015-07-22: 9418857192 (x86_64/Linux) - Just slowly
| creeping up.
|
| ,(platform('i386-unknown-mingw32'), 4434804940, 5)
| # 2013-02-10: 3358693084
| (x86/Windows)
|
| ___
| ghc-commits mailing list
| ghc-comm...@haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Backporting srcLoc to the GHC 7.10 branch
On 07/08/2015 11:32 PM, Simon Peyton Jones wrote: I don't have a strong opinion here. I believe that you are saying that: * There is some change you want to make to 7.10.2. I'm not sure precisely what it is. I followed the link and got a github repo with a ton of commits on it. The change would be to put the latest two commits from https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip on top of 7.10 branch. * The change is an API change, which we do not normally make. But you argue that it will harm no one (why are you so sure?), and you are confident that it will not break anything (why?) The API change is precisely at this commit. https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f89b6b I never said that it will not harm anyone or that it will not break anything. I only said that it is a small price to pay. The change is your own in the typechecker, a two SrcSpans turning into RealSrcSpans. I think we can agree at least that it is not a large change. I understand if it gets rejected on this basis regardless, I am merely trying my chances. * FP Complete and Zalora specifically want this change. Zalora = you? Who at FP Complete wants the change? Some of us at Zalora, yes. This thread of messages was created my FP Complete and they did the backport. They even say that they'll include the changes into their custom build of GHC and ship that to their customers. So it seems like they'd want the change. The very first message in this thread is Michael Snoyman asking if such backport could make it into 7.10. Ben and Herbert are the guys you have to persuade if you really want this. I suspect it'll be more effective to open a ticket, milestoned for 7.10.2, with specifics on it. Email gets lost; tickets don't. Noted, thanks. Thanks Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Mateusz | Kowalczyk | Sent: 06 July 2015 17:40 | To: ghc-devs@haskell.org | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | | On 04/20/2015 05:29 PM, Niklas Hambüchen wrote: | Hello everybody, | | I'm glad to announce that I performed the suggested backporting as part | of | my work for FP Complete! | | With the help of Eric (thanks for your support in #ghc!) we now have | this | patch for 7.10 and 7.8. | | As promised, here are the commits: | | * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip | | You can see in the history that I only needed to cherry-pick Make the | location in TcLclEnv and CtLoc into a RealSrcSpan as a dependent | commit, | so the changes beyond the actual feature are fairly minimal. | | For 7.8, I had to do a little more cleanup, see the Use wrapIPTc | instead | of coercionToTcCoercion on wrapIP commit. | | Regarding the commit of the feature itself, I had to do quite some | merge | resolution, especially due to the (lack of) the -fwarn-redundant- | constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias | but it | was Christmas, so I did some recreational programming that went much | further). | However, the type checker had a strong opinion of what the right merge | decision was, at least for the 7.10 backport; for 7.8 there was an | ambiguity (whether to return `Nothing` or `Just` in `interactDict`), | which | was resolved with Eric's help. | | Please be invited to review the two commits. | | We would like to make 7.8 and 7.10 binaries with this feature available | as | well, and will do so after getting a review! | | Niklas | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | | Hi all, | | In light of how small the actual backported changes are, I wonder if it | would be possible to include it in 7.10.2 (or .3 if we're doing that). I | know that at first it was rejected but it was rejected before the diff | existed. In practice, the only API change was two SrcSpans changing into | RealSrcSpans inside the typechecker. Seems like a small price, | considering two commercial companies that use Haskell (FP Complete and | I'm here on behalf of Zalora's internal team) would love to see it. | | I know SPJ suggested perhaps lobbying for early 7.12 instead but how | early could we possibly lobby for it considering 7.10.2 is not even out | of the door yet? | | Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be | interested in seeing that too. | | -- | Mateusz K. | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http
Re: Backporting srcLoc to the GHC 7.10 branch
On 04/20/2015 05:29 PM, Niklas Hambüchen wrote: Hello everybody, I'm glad to announce that I performed the suggested backporting as part of my work for FP Complete! With the help of Eric (thanks for your support in #ghc!) we now have this patch for 7.10 and 7.8. As promised, here are the commits: * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip You can see in the history that I only needed to cherry-pick Make the location in TcLclEnv and CtLoc into a RealSrcSpan as a dependent commit, so the changes beyond the actual feature are fairly minimal. For 7.8, I had to do a little more cleanup, see the Use wrapIPTc instead of coercionToTcCoercion on wrapIP commit. Regarding the commit of the feature itself, I had to do quite some merge resolution, especially due to the (lack of) the -fwarn-redundant- constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias but it was Christmas, so I did some recreational programming that went much further). However, the type checker had a strong opinion of what the right merge decision was, at least for the 7.10 backport; for 7.8 there was an ambiguity (whether to return `Nothing` or `Just` in `interactDict`), which was resolved with Eric's help. Please be invited to review the two commits. We would like to make 7.8 and 7.10 binaries with this feature available as well, and will do so after getting a review! Niklas ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs Hi all, In light of how small the actual backported changes are, I wonder if it would be possible to include it in 7.10.2 (or .3 if we're doing that). I know that at first it was rejected but it was rejected before the diff existed. In practice, the only API change was two SrcSpans changing into RealSrcSpans inside the typechecker. Seems like a small price, considering two commercial companies that use Haskell (FP Complete and I'm here on behalf of Zalora's internal team) would love to see it. I know SPJ suggested perhaps lobbying for early 7.12 instead but how early could we possibly lobby for it considering 7.10.2 is not even out of the door yet? Niklas, do you also have a diff on top of 7.10.2 (rc-1/2)? I'd be interested in seeing that too. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: build: make haddock a bit less chatty (e796026)
On 06/02/2015 03:31 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/e796026b45974d71233eef7ffb6feee482c6dd7e/ghc --- commit e796026b45974d71233eef7ffb6feee482c6dd7e Author: Austin Seipp aus...@well-typed.com Date: Tue Jun 2 09:31:52 2015 -0500 build: make haddock a bit less chatty Summary: Haddock outputs well over a thousand lines of file output just to give its executive summary about coverage. Kill this by default, since we really don't need it in any setting. Signed-off-by: Austin Seipp aus...@well-typed.com Test Plan: Crossed my fingers. Reviewers: nomeata, thomie Reviewed By: thomie Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D933 --- e796026b45974d71233eef7ffb6feee482c6dd7e ghc.mk | 2 +- rules/haddock.mk | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/ghc.mk b/ghc.mk index 5a1845c..3b38372 100644 --- a/ghc.mk +++ b/ghc.mk @@ -1375,7 +1375,7 @@ validate_build_xhtml: cd libraries/xhtml ./Setup configure --with-ghc=$(BINDIST_PREFIX)/bin/ghc $(BINDIST_HADDOCK_FLAG) $(BINDIST_LIBRARY_FLAGS) --global --builddir=dist-bindist --prefix=$(BINDIST_PREFIX) cd libraries/xhtml ./Setup build --builddir=dist-bindist ifeq $(HADDOCK_DOCS) YES - cd libraries/xhtml ./Setup haddock --ghc-options=-optP-P --builddir=dist-bindist + cd libraries/xhtml ./Setup haddock -v0 --ghc-options=-optP-P --builddir=dist-bindist endif cd libraries/xhtml ./Setup install --builddir=dist-bindist cd libraries/xhtml ./Setup clean --builddir=dist-bindist diff --git a/rules/haddock.mk b/rules/haddock.mk index a43df95..5604a50 100644 --- a/rules/haddock.mk +++ b/rules/haddock.mk @@ -48,6 +48,7 @@ ifeq $$(HSCOLOUR_SRCS) YES $$(ghc-cabal_INPLACE) hscolour $1 $2 endif $$(TOP)/$$(INPLACE_BIN)/haddock \ + --verbosity=0 \ --odir=$1/$2/doc/html/$$($1_PACKAGE) \ --no-tmp-comp-dir \ --dump-interface=$$($$($1_PACKAGE)-$$($1_$2_VERSION)_HADDOCK_FILE) \ ___ ghc-commits mailing list ghc-comm...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits You could have just used --no-print-missing-docs to go to the old amount of output. Or start filling out the stuff Haddock is complaining about, I made it a default to nag people :) -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Non-deterministic package IDs are really bad in 7.10
On 05/19/2015 06:46 AM, Daniel Peebles wrote: Don't Nix builds all happen in a randomly generated temporary directory by default? Then you just copy to $out in installPhase. Perhaps stabilizing the build directory would help alleviate some of the immediate problems, if what Joachim is describing affects us too. Oh, I was far too hasty in reading the bug on the Debian tracker. Yes, I suppose this could be a problem for us though I'd like to see it first before trying to work around it. On Mon, May 18, 2015 at 10:13 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 05/14/2015 05:43 PM, Joachim Breitner wrote: Hi, Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: I'd like to bring some attention to ticket #4012 about non-determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. is NixOS sensitive to changes in the build directory. Debian is, and since 7.8 the build path creeps into the interface files and affects the hash: https://bugs.debian.org/785282 But you probably are not, otherwise you’d have complained when 7.8 was out, and not now :-) Greetings, Joachim Not a problem for nix, the paths are are calculated based on the derivation inputs. I don't want to go into details but if same expression goes in, same path comes out. If the path that comes out is different, you simply don't get to use it. More or less nix does ‘calculate the store path from this expression, check if it exists in binary caches and fetch it if it does, build if it does not’. So for us the store paths in the interface files would always be the same for the same inputs hence no problem there. -- -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Non-deterministic package IDs are really bad in 7.10
On 05/14/2015 05:43 PM, Joachim Breitner wrote: Hi, Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: I'd like to bring some attention to ticket #4012 about non-determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. is NixOS sensitive to changes in the build directory. Debian is, and since 7.8 the build path creeps into the interface files and affects the hash: https://bugs.debian.org/785282 But you probably are not, otherwise you’d have complained when 7.8 was out, and not now :-) Greetings, Joachim Not a problem for nix, the paths are are calculated based on the derivation inputs. I don't want to go into details but if same expression goes in, same path comes out. If the path that comes out is different, you simply don't get to use it. More or less nix does ‘calculate the store path from this expression, check if it exists in binary caches and fetch it if it does, build if it does not’. So for us the store paths in the interface files would always be the same for the same inputs hence no problem there. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Non-deterministic package IDs are really bad in 7.10
Hi, I'd like to bring some attention to ticket #4012 about non-determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. The situation was pretty bad in 7.8.4 in presence of parallel builds so we switched those off. Joachim's a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and we were hopeful for 7.10. Now that 7.10.1 is out and people have been using and testing it, the situation turns out to be really bad: daily we get multiple reports from people about their packages ending up broken and our only advice is to do what we did back in 7.8 days which is to purge GHC and rebuild everything locally or fetch everything from a machine that already built it all, as long as the two don't mix. This is not really acceptable. See comment 76 on #4012 for an example of a rather simple file you can compile right now with nothing extra but -O and get different interface hash. This e-mail is just to raise awareness that there is a serious problem. If people are thinking about cutting 7.10.2 or whatever, I would consider part of this ticket to be a blocker as it makes using GHC reliably while benefitting from binary caches pretty much impossible. Of course there's the ‘why don't you fix it yourself’ question. I certainly plan to but do not have time for a couple more weeks to do so. For all I know right now, the fix to comment 76 might be easy and someone looking for something to hack on might have the time to get to it before I do. Thanks -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: release timing
On 05/05/2015 11:16 AM, Roman Cheplyaka wrote: I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385 There's a PR for it sitting on GitHub[1]. I did not have time to test it but if you want to go ahead and give it a quick look, I'd be happy to merge it if you give it an OK. [1]: https://github.com/haskell/haddock/pull/386 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HP 2015.2.0.0 and GHC 7.10
On 03/28/2015 04:27 PM, Randy Polen wrote: Mateusz, Haddock issue #285 indeed sounds like a win (or Win-dows). A logistical wrinkle I worry about for the short-term is that the HP uses the GHC release, and haddock is part of that release. I can certainly incorporate a newer haddock, but I want to mention this GHC-related release issue in case others here have a better approach for this part of the plan (e.g., yes, go ahead and augment GHC 7.10.1 release with a custom haddock or no, let's spin up a 7.10.1.1 (?)). There is also the Cabal piece as well, but that is separate from GHC and thus a bit easier to incorporate into the HP build. Randy We cut a Haddock release when GHC comes out so that it's easy to track versions but that's simply to try to keep some sanity when users report --version. But there is nothing stopping us from releasing a new Haddock version without forcing a GHC release. If I release 2.16.1 tomorrow with the argument list thing, you can just cabal install install it. As long as your system knows to look into binaries built through cabal first and binaries shipped with GHC second, you'll be golden. For HP purposes, you probably want to ship 2.16.1 (or whatever version) when that comes out because tools like cabal-install depend on the version number to determine what features (such as response files) are available. I don't have a date for next point release. Do you have a date for HP? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC version 7.10.1
On 03/27/2015 07:43 AM, Austin Seipp wrote: == The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 == The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized [snip] I wanted to learn about which combinators have been updated so I click on ‘GHC 7.10 Migration Guide’ in linked documentation page but it seems that it doesn't lead anywhere, or rather leads to the page it's linked from. It was probably meant to link to https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Broken `cabal haddock --hoogle` with GHC 7.10
On 02/25/2015 10:57 AM, Neil Mitchell wrote: When you say change is on the 7.10 branch, you mean a fix for Haddock, or changes to Cabal? To Haddock. There are also other issues with the --hoogle output, the newest regression being that constructors are wrapped in square brackets, for example: [Nothing] :: Maybe a Generally, the --hoogle output from Haddock keeps going downhill. When I first implemented it, there was a test suite, but that seems to no longer be catching issues. I'm aware and really want to fix these issues (Hoogle is great!) but as always what little manpower becomes available tends to go into showstopper bugs instead as apparent by the sad commit list in Haddock… I think I will try to jump into Hoogle problems at start of March and just ignore other stuff. As always, my apologies. Thanks, Neil On Wed, Feb 25, 2015 at 5:47 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 02/25/2015 05:41 AM, Michael Snoyman wrote: I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it: https://github.com/haskell/haddock/issues/361 https://github.com/haskell/cabal/issues/2297 I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release. I think only work needs to go into cabal now. GHCs point of concern here is that it ships with a patched cabal for this when the patch does get crafted rather than only dumped onto the master branch. It's already fixed on Haddock side and I believe the change is on 7.10 branch. So I guess this is just a FYI that something is broken and we're awaiting cabal patch. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Broken `cabal haddock --hoogle` with GHC 7.10
On 02/25/2015 05:41 AM, Michael Snoyman wrote: I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it: https://github.com/haskell/haddock/issues/361 https://github.com/haskell/cabal/issues/2297 I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release. I think only work needs to go into cabal now. GHCs point of concern here is that it ships with a patched cabal for this when the patch does get crafted rather than only dumped onto the master branch. It's already fixed on Haddock side and I believe the change is on 7.10 branch. So I guess this is just a FYI that something is broken and we're awaiting cabal patch. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Haddock error
On 01/01/2015 08:34 PM, Simon Peyton Jones wrote: Folks I'm getting this Haddock error (see below) from a clean build on Windows. Does it ring any bells for anyone? Anyone have any idea how to fix? My build isn't exactly HEAD but I'd be very surprised if my changes are the cause. Thanks Simon C:/code/HEAD/inplace/bin/haddock --odir=libraries/ghc-prim/dist-install/doc/html/ghc-prim --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title=ghc-prim-0.3.1.0: GHC primitives --prologue=libraries/ghc-prim/dist-install/haddock-prologue.txt --optghc=-hisuf --optghc=hi --optghc=-osuf --optghc=o --optghc=-hcsuf --optghc=hc --optghc=-static --optghc=-H32m --optghc=-O --optghc=-Werror --optghc=-Wall --optghc=-H64m --optghc=-O0 --optghc=-this-package-key --optghc=ghcpr_FgrV6cgh2JHBlbcx1OSlwt --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package-key --optghc=rts --optghc=-this-package-key --optghc=ghc-prim --optghc=-XHaskell2010 --optghc=-O2 --optghc=-O --optghc=-dcore-lint --optghc=-fno-warn-deprecated-flags --optghc=-fno-warn-tabs --optghc=-Wwarn --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-fno-warn-trustworthy-safe --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable [snip] Declaration for $fOrdMaybe: attempting to use module 'GHC.Classes' (libraries/ghc-prim/./GHC/Classes.hs) which is not loaded CCSOf# (libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs:3187) [snip] Cannot continue after interface file error libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock' failed make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 HEAD (master)$ Hi Simon, In InterfaceFile.hs in Haddock there is binaryInterfaceVersion :: Word16 #if (__GLASGOW_HASKELL__ = 711) (__GLASGOW_HASKELL__ 713) binaryInterfaceVersion = 27 … Try bumping this to 28 and if it works then then you may want to commit the change. By the way I see that there is a lot of output from Haddock now as I made it print locations of missing documentation by default. Maybe --no-print-missing-docs should be passed in for GHC stuff. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles from constraint-solver improvements
On 12/10/2014 10:13 PM, Simon Peyton Jones wrote: This is a single stat failure in haddock.base; doesn't happen for me. Simon | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 10 December 2014 18:48 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements | | Harbormaster failed to build B2572: rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC37b3646c9da4 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs As I suggested yesterday on IRC, it may be worthwhile to make the check on Haddock numbers quite a bit looser considering it's not developed in-tree anymore and fails quite frequently due to other things. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Fw: Long term support - in general and Windows XP specifically
On 11/08/2014 07:32 PM, Howard B. Golden wrote: Hi, I am combining the two topics because the issues are both support-related. First, long term support (LTS) is an important goal in making GHC/Haskell a viable production platform. I would argue that providing it is a necessary condition to encourage more adoption of Haskell by plain users (as opposed to those willing to take more risks). This includes both individuals and organizations. I believe this makes LTS a high priority for the community. LTS requires support of both GHC and stable libraries. Any plan for LTS must incorporate a plan for identifying libraries to keep supporting for the same period. This must be part of the effort. FP Complete's Stackage is one approach. Practically, each LTS version requires significant maintainer resources. Therefore, there is a tension between how many versions to support, how long to support them, and how much demand there will be for new features. The developers need to get a sense of how much value the plain user will get from a new release versus bug fixes and backports to an LTS release. As a thought experiment (and perhaps a survey of users), how many users are content with GHC 7.4, 7.6 and 7.8, or even earlier releases? Will they clamor for the new features in 7.10, or is this more aimed at those who are experimenting or are willing to take greater risk? What is the current demographic of users/GHC release usage? Based on the results of this study, we'll have a better idea of what release to make the first LTS one. I would suggest starting with a prior release based on what is being used now. For example, find out how many users are using 7.4 and ask what difficulties they would have in adopting 7.6. Try to get a sense of what the first LTS release should be, recognizing that you won't get unanimous agreement. I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded. If organisations care then they should voice their thoughts *and* provide some developer effort to make the backports. Delaying new releases and pulling off volunteers to do soul-crushing fix backporting because it might, just might, make it easier for some business out there to achieve something is silly. No one wants to put their free time into porting stuff years back especially if it might not even matter. The issue of Windows XP support should be considered using a similar approach. If an LTS release is created with Windows XP support, this should satisfy XP users for a period of time. It could then be discussed when XP support would no longer be part of a later version. I don't know what API differences there are between XP and Vista or Window 7 that impact GHC. Do the newer APIs provide a significant benefit that justifies dropping XP support? Could newer features be used only where essential, so degraded XP support can be maintained longer? XP came out in 2001. There's LTS and then there's 13 year old OS that's after EOL from its own developer. I hope my perspective is of value to the developers. Regards, Howard Northridge, CA, USA - Original Message - From: Austin Seipp aus...@well-typed.com To: ghc-devs@haskell.org ghc-devs@haskell.org Cc: Sent: Friday, November 7, 2014 2:07 PM Subject: GHC Weekly News - 2014/11/07 [Excerpt] - Austin also opened a discussion about a possible LTS branch for GHC, spawned off from a suggestion by John Lato a few weeks email. This discussion has been brought up several times before this, but for the most part has fizzled out a bit. But maybe with a different focus - on a separate branch with a team of maintainers - we can hash out a plan of action, and just give it a whirl. https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html - Austin Seipp brought up a question about Windows support: can we officially drop support for XP, now that Microsoft has done the same? And what minimum version requirements should we endorse? Vista or Windows 7 would give improvements due to API improvements, with Windows 7 offering even more. If you're a GHC on Windows user, please let us know! https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: Improving the LLVM backend by packaging it
On 10/25/2014 12:52 AM, Austin Seipp wrote: Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. Needless to say, the situation right now isn't so hot: we have no commitment to version support, two major versions are busted, others are seriously buggy, and yet there are lots of things we could improve on. So I give you a proposal, from a few of us to you all, about improving it: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend I won't repeat what's on the wiki page too much, but the TL;DR version is: we should start packaging a version of LLVM, and shipping it with e.g. binary distributions of GHC. It's just a lot better for everyone. I know we're normally fairly hesitant about things like this (shipping external dependencies), but I think it's the only sane thing to do here, and the situation is fairly unique in that it's not actually very complicated to implement or support, I think. We'd like to do this for 7.12. I've also wrangled some people to help. Those people know who they are (because they're CC'd), and I will now badger them into submission until it is fixed for 7.12. Please let me know what you think. PS. Joachim, I would be particularly interested in upstream needs for Debian, as I know of their standard packaging policy to not duplicate things. I don't think any distro wants to duplicate things. Even if GHC does end up shipping with LLVM, it should be easy for distro packagers to ignore that and use their own. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
On 10/18/2014 04:48 PM, Christopher Done wrote: Good evening, So I’ve been working on Haskell user-facing tooling in general for some years. By that I mean the level of Emacs talking with Haskell tools. [snip] You’ve seen some of these features in GHC Mod, in hdevtools, in the FP Haskell Center, maybe some are in Yi, possibly also in Leksah (?). Currently any Yi support for such things is either poor or not present. We currently also just talk to the REPL and parse stuff out. The upside is that it is possible for us to talk to any Haskell stuff natively (including GHC API/ghc-mod) so we don't need to depend as much on GHCi as emacs or other editors, at least in theory. [snip] Well, that’s everything. Thoughts? Ciao! Sounds interesting. My only request/comment is that I hope whatever conclusion you come to, the library part of it will be usable just as much (or even more) as the executable: if we can talk to the library natively then that's much easier than talking to some remote socket and parsing out data. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Warning on tabs by default (#9230) for GHC 7.10
On 10/18/2014 01:25 AM, Austin Seipp wrote: Hi all, Please see here: https://phabricator.haskell.org/D255 and https://ghc.haskell.org/trac/ghc/ticket/9230 Making tabs warn by default has been requested many times before, and now that the compiler is completely detabbed, this should become possible to enable easily, and we can gradually remove warnings from everything else. Unless someone has huge complaints or this becomes a gigantic bikeshed/review (bike-review), please let me know - I would like this to go in for 7.10. On Phabricator I see a diff which adds a suppression for the warning to GHC. Is this necessary considering you say GHC is now fully detabbed? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Show instance for SrcSpan
On 10/06/2014 01:59 PM, Alan Kim Zimmerman wrote: Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan Why? If you're looking for pretty output then you should be changing Outputable. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: sync-all
On 10/02/2014 08:49 AM, Simon Peyton Jones wrote: Herbert says (in bold font) do not ever use sync-all, in this post http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/. If that's really true, we should either nuke it altogether, or change it to do something correct. The idea that it might set up your tree in subtly different ways is alarming. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs This is news to me, I always use sync-all get sync-all pull when I have to… I'd appreciate if such things were announced on lists rather than a comment on reddit somewhere… -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Should we occasionally merge haddock master into ghc-head?
On 09/18/2014 10:30 PM, Edward Z. Yang wrote: Hello Mateusz and all, With ghc-head and master being developed concurrently, I am wondering if GHC developers should be allowed to occasionally merge in changes from master. Seems like a good service which would help Mateusz out a bit when it comes time to update master for the next version GHC. Or is there some reason we shouldn't do this? Cheers, Edward Hi, tl;dr: Far too much effort on the GHC side for very little gain on Haddock side makes the master/ghc-head split lose part of its function. Longer version: As I mentioned on IRC, my plan at GHC release time is not to just merge from ghc-head. Changes by GHC team tend to be small, fixes due to API changes. Ideally what would happen is that I sit down near release date and cherry-pick it all out, maybe even squashing it first into a ‘update for next GHC’ commit as that makes looking at the actual diff between branches much easier – we do not care what changed between day 1 of 7.9 until last day of 7.9, we only care about what changed between 7.8.3 and 7.10.x-justbeforerc1. One of the large reasons why I wanted to move out Haddock from GHC tree is that we (Haddock) do not have to go through these API changes at all, we're only there for the final release. I think this makes cherry-picking more suited to merging ghc-head → master. But your question is master → ghc-head. I think it is not necessary for you to do so. We have already taken steps for compatibility with 7.8.2 and even split Haddock up further into more packages. This means that not only would this merge be very unpleasant to do, it'd also be unpleasant to maintain thereafter. As I don't plan merging ghc-head back in, it does not greatly reduce labour for me when it comes to it but it makes it painful for GHC folk. The only reason you might have to merge master → ghc-head would therefore be if GHC needed features from master at which point cherry-picking those features is easier than merging the whole thing. I think it makes sense to think of it as Haddock now being disjoint software that GHC happens to use, needs to patch sometimes, and simply contributes those (finalised) patches to Haddock at GHC release time. Once these merges are done, you can restart ghc-head for 7.11 from master at that point, rather than trying to go through merges and try to keep in sync throughout the process. Basically ‘master’ is the upstream and ‘ghc-head’ is your private fork that you maintain and contribute back when the time comes. I can develop quickly and test against 7.8.3 because I don't have to worry about impacting HEAD and you can develop and test against HEAD because you don't have to worry about impacting the versions in the wild. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/25/2014 01:21 PM, Alan Kim Zimmerman wrote: What happens in the case of a change to the dev branch of ghc that requires a patch to haddock as well, how does that patch get added to phabricator, or is there a separate process? A case in point is https://phabricator.haskell.org/D157 with matching change at https://github.com/alanz/haddock/tree/wip/landmine-param-family Regards Alan You need to push the patch against the Haddock ghc-head branch and update the submodule reference to point at your patch. I don't think that you need to do anything special for Phabricator unless it does some weird checking out instead of using whatever references GHC points to. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/15/2014 04:32 PM, Simon Peyton Jones wrote: Great. Please can what you do be documented clearly somewhere, with a link to that documentation from here https://ghc.haskell.org/trac/ghc/wiki/Repositories, and/or somewhere else suitable? Thanks Simon Nothing on that page needs to change. The only thing that needs documenting is than any GHC dev pushing to Haddock needs to do so on the ‘ghc-head’ branch. I have made a change to the table at [1] and added a note but perhaps there's another place that I need to make a change at that's not immediately obvious. Herbert kindly updated the sync-all script that defaults to the new branch so I think we're covered. Please don't hesitate to ask if you (plural) need help with something here. [1]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/14/2014 01:43 AM, Carter Schonwald wrote: one thing I wonder about is how should we approach noting theres a new language constructor, we should figure out a good way to present it in haddock in this work flow? because the initial haddocks presentation might just be a strawman till someone thinks about it carefully right? On Wed, Aug 13, 2014 at 6:30 PM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-08-14 at 00:09:40 +0200, Mateusz Kowalczyk wrote: [...] I don't know what the GHC branch name will be yet. ‘ghc-head’ makes most sense but IIRC Herbert had some objections as it had been used in the past for something else, but maybe he can pitch in. I had no objections at all to that name, 'ghc-head' is fine with me :-) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs If there's more than one reasonable way then there's going to be strawman along the way somewhere anyway but we can at least delegate that until later. As I mention in the OP, there's at least no need for me to worry about it until it's finished on the GHC side although I'll no doubt be aware of it sooner than that. The PatternSynonyms stuff is an example where the implementor also stepped up to putting in support into Haddock for rendering. At the same time, the implementation has changed multiple times along the way creating hassle for both parties so perhaps in the future it's better to simply make sure Haddock still compiles and works but perhaps delegate everything else to closer to the release. In the end, it does not matter if Haddock can't display a bleeding edge feature until it's going out as a release. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/13/2014 11:09 PM, Mateusz Kowalczyk wrote: On 08/08/2014 06:25 AM, Mateusz Kowalczyk wrote: Hello, [snip] Transition from current setup: If I receive some patches I was promised then I will then make a 2.14.4 bugfix/compat release make sure that master is up to date and then create something like GHC-tracking branch from master and track that. I will then abandon that branch and not push to it unless it is GHC release time. The next commit in master will bring Haddock to a state where it works with 7.8.3: yes, this means removing all new API stuff until 7.10 or 7.8.4 or whatever. GHC API changes go onto GHC-tracking while all the stuff I write goes master. When GHC makes a release or is about to, I make master work with that and make GHC-tracking point to that instead. Thanks! So it is now close to a week gone and I have received many positive replies and no negative ones. I will probably execute what I stated initially at about this time tomorrow. To reiterate in short: 1. I make sure what we have now compiles with GHC HEAD and I stick it in separate branch which GHC folk will now track and apply any API patches to. Unless something changes by tomorrow, this will most likely be what master is at right now, perhaps with a single change to the version in cabal file. 2. I make the master branch work with 7.8.3 (and possibly 7.8.x) and do development without worrying about any API changes in HEAD, releasing as often as I need to. 3. At GHC release time, I update master with API changes so that up-to-date Haddock is ready to be used to generate the docs and ship with the compiler. I don't know what the GHC branch name will be yet. ‘ghc-head’ makes most sense but IIRC Herbert had some objections as it had been used in the past for something else, but maybe he can pitch in. The only thing I require from GHC folk is to simply use that branch and not push/pull to/from master unless contributing feature patches or trying to port some fixes into HEAD version for whatever reason. Thanks! The deed is done, the branch to pull/push to/from if you're doing GHC API work is ‘ghc-head’. ‘master’ is now a development branch against 7.8.3. When the time comes for 7.10, I can simply re-apply the fixes + anything from ‘ghc-head’ at that time. You only need to concern yourself with this if you ever push to Haddock. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/08/2014 06:25 AM, Mateusz Kowalczyk wrote: Hello, [snip] Transition from current setup: If I receive some patches I was promised then I will then make a 2.14.4 bugfix/compat release make sure that master is up to date and then create something like GHC-tracking branch from master and track that. I will then abandon that branch and not push to it unless it is GHC release time. The next commit in master will bring Haddock to a state where it works with 7.8.3: yes, this means removing all new API stuff until 7.10 or 7.8.4 or whatever. GHC API changes go onto GHC-tracking while all the stuff I write goes master. When GHC makes a release or is about to, I make master work with that and make GHC-tracking point to that instead. Thanks! So it is now close to a week gone and I have received many positive replies and no negative ones. I will probably execute what I stated initially at about this time tomorrow. To reiterate in short: 1. I make sure what we have now compiles with GHC HEAD and I stick it in separate branch which GHC folk will now track and apply any API patches to. Unless something changes by tomorrow, this will most likely be what master is at right now, perhaps with a single change to the version in cabal file. 2. I make the master branch work with 7.8.3 (and possibly 7.8.x) and do development without worrying about any API changes in HEAD, releasing as often as I need to. 3. At GHC release time, I update master with API changes so that up-to-date Haddock is ready to be used to generate the docs and ship with the compiler. I don't know what the GHC branch name will be yet. ‘ghc-head’ makes most sense but IIRC Herbert had some objections as it had been used in the past for something else, but maybe he can pitch in. The only thing I require from GHC folk is to simply use that branch and not push/pull to/from master unless contributing feature patches or trying to port some fixes into HEAD version for whatever reason. Thanks! -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/08/2014 10:35 AM, Herbert Valerio Riedel wrote: On 2014-08-08 at 09:42:14 +0200, Simon Hengel wrote: On Fri, Aug 08, 2014 at 09:00:21AM +0200, Herbert Valerio Riedel wrote: Just to clarify, as the last sentence contains a double-negation: GHC devs continue pushing to github.com/haddock.git's `master` branch to keep Haddock building with GHC HEAD? It's just that the Haddock development proper happens in a branch other than `master` from now on? From my perspective I would prefer to use `master` for Haddock development and use a branch with some other name for GHC development. My main motivation here is that as a contributor to Haddock I expect the latest code to be on `master`, and I would use it as a base when developing new features. Just a minor nitpick (but I agree with having `master` used for hosting active Haddock development): latest code might not be a canonical concept, as there will be latest code that works with GHC HEAD, and latest code that works with last released GHC Alternatively, maybe use `master` for both Haddock and GHC development, but push to different remotes (say use http://git.haskell.org/haddock.git for GHC development and https://github.com/haskell/haddock for Haddock development). I think this is what we already do for e.g. `containers`. I'd rather reduce the number of doubled repositories (not the least to simplify the mirroring setup) to avoid confusion about where things live/need to be pushed to. If this is just an alpha-conversion modulo thing, then let's just call the new branch for GHC HEAD simply `ghc-head` (or something like that) and keep hosting it in github.com/haskell/haddock.git, and have GHC HEAD developers push to that instead (fwiw, you can specify the default branch in .gitmodules, which some few Git tools honor). Cheers, hvr Hi, Here is what my plan was Haddock branches would be: master – Haddock devs push here, the fixes go here GHC-tracking – GHC team pushes here At GHC release master would be brought up to a state where it works with current GHC API. GHC-tracking then would be reset to master. The change in sync-all I was referring to is that ./sync-all get ./sync-all pull would not end up pointing at a master branch but after some sleep I realise that's probably not the case anyway. We simply need GHC team to push to their own branch. If I get this right, there will be a branch (`master`?) that's kept compatible with GHC HEAD, then there's a branch where new Haddock features are implemented (name?), The other way around, master is for Haddock while the other branch is for GHC. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/08/2014 10:15 AM, Johan Tibell wrote: On Fri, Aug 8, 2014 at 10:11 AM, Simon Peyton Jones simo...@microsoft.com wrote: The biggest disadvantage in my mind is that you're setting yourself up for a potentially huge merge just before the GHC release and might block the GHC release until that merge is done (assuming that haddock is still shipped with GHC). Excellent point. The merge shouldn’t block the release, though. In extremis, I guess we could always release the GHC fork of Haddock if the tip of Haddock wasn’t merged to match GHC! But I doubt it’ll come to that But as you mentioned the GHC fork of Haddock might not work (it might just type check) so at the very least Mateusz is signing up for validating that it indeed works before a GHC release. That's of course fine, I just want people to understand what we're signing up for. Well, I stick around and am usually aware of GHC release early. In the usual case Haddock will be fixed up before the actual GHC release. I don't think API changes were ever drastic enough to provide major problems especially seeing as I'll be able to refer to the GHC-tracked branch to see what patches were applied there. However let's consider I can't make it for the release because I'm not available around that time or otherwise. This should still not hold up GHC release. I would expect the GHC team to release Haddock + their fixes, it would simply be like an existing release with some patches on top to have it work with new GHC. I can then come around and once I apply any API patches, I make an actual Haddock release. People can then simply cabal install haddock and use what they get here rather than what came with GHC. Does this make sense? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Moving Haddock *development* out of GHC tree
On 08/08/2014 10:18 AM, Simon Marlow wrote: I thought this was what you were already doing :-) Anyway, this is more or less the setup we had in mind when Haddock was added to the GHC tree. The only question is which branches are used for GHC and for regular development, and where they live. As long as that's clear for everyone (both Haddock and GHC developers), then this should be fine. I think there is no problem if they both live in the existing repository (github.com/haskell/haddock) or whatever the submodule refers to today. The GHC release engineer will need to give the Haddock maintainers plenty of heads-up time before a release so that the merge can be done - Austin could you add that to the release checklist? Right, although I don't exactly plan to abandon any of the GHC information channels I'm on today: I tend to be well aware of a release coming. Cheers, Simon -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC under Wine?
On 07/16/2014 12:55 AM, Joachim Breitner wrote: 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 Perhaps this is a bit off-tangent but few months ago there were some commits landing to the nix package manager which allow you to run tests in a Windows VM. It was created to run tests for things like cross-compiled packages but it probably could be adapted. If you don't mind actually installing Windows (in a VM) and have nix already/plan on using it then that might be a more preferable workflow: create a nix expression that builds a validates GHC in the VM and spits out the result. It's just something I thought I should mention in case anyone was interested. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Moving Haddock *development* out of GHC tree
Hello, A slightly long e-mail but I ask that you voice your opinion if you ever changed GHC API. You can skim over the details, simply know that it saves me vast amount of time, allows me to try and find contributors and doesn't impact GHC negatively. It seems like a win-win scenario for GHC and Haddock. GHC team's workflow does not change and will not require any new commitment: I do all the work and I think it's a 1 line change in sync-all when transition is ready. Here it is: It is no secret that many core Haskell projects lack developer hands and Haddock is no exception: the current maintainers are Simon Hengel and myself. Simon does not have much time so currently all the issues and updates are up to me. Ideally I would like if some more people could come and hack on Haddock but there are a couple of problems with trying to recruit folk for this: 1. Interacting with GHC API is not the easiest thing. This is Haddock's problem but I thought I'd mention it here. 2. Haddock resides directly in the GHC tree and it is currently *required* that it compiles with GHC HEAD. This is a huge barrier of entry for anyone: today I wanted to make a fairly simple change but it still took me 3 validate runs to be at least somewhat confident that I didn't break much in GHC. On top of this I had help from Edward Z. Yang on IRC and information from him on what the issue exactly was. If I was to do everything alone it would have taken even more validates. A validate is not fast on machine by any means, it takes an hour or two. Here is what I want to do unless there are major objections: I want to move the active development away from GHC tree. Below is how it would work. For simplicity please imagine that we have *just* released 7.8.3. * Haddock development would concentrate on supporting the last public release of GHC: I stop developing against GHC HEAD and currently would develop against 7.8.3. * GHC itself checks out Haddock as a submodule as it does now. The only difference is that it points at whatever commit worked last. Let us assume it is the Haddock 2.14.3 release commit. The vital difference from current state is that GHC will no longer track changes in master branch. * Now when GHC API changes things proceed as they normally do: whoever is responsible for the changes, pops into the Haddock submodule applies the patches necessary for Haddock to build with HEAD and everyone is happy. What does *not* happen is these patches don't go into master: I ignore them and keep working with 7.8.3. * When a GHC release rolls around, I update Haddock to work with the new API so that people with new release can still use it. Once it works against new API, GHC can start tracking from that commit onwards and proceed as usual. Here are the advantages: * I don't have to work against GHC HEAD. This means I don't have to build GHC HEAD and I don't need to worry about GHC API changes. I don't waste 2-4 hours building before hacking and validating after hacking to make any minor changes and to make sure I haven't broken anything. * More importantly, anyone who wants to write a patch for Haddock can now do so easily, all they need is recent compiler rather than being forced to build HEAD. Building and validating against HEAD is a **huge** barrier of entry. * I only have to care about GHC API changes once a release and not twice a week. I think PatternSynonyms have changed 4 times in a month but the end result at release time is the same and that's what people care about. * It is less work for anyone changing GHC API: they only have to deal with their own changes and not my changes which add features or whatever. * If I break something in Haddock HEAD, GHC is not affected. * If Haddock's binary interface doesn't change, we may even allow more versions of GHC be compatible through CPP and other such trickery. If we were to do it today, it would be an increased burden on the GHC team to deal with those. * I can release as often as I want against the same compiler version. Currently doing this requires backporting features (see v2.14 branch) which is a massive pain. I no longer have to tell the users ‘yes, your bug is fixed but to get it you need to compile GHC HEAD or wait 6-12 months until next GHC release’. I have to do this a lot. Here are the disadvantages and why I think they don't make a big difference: * GHC HEAD doesn't get any new-and-cool features that we might implement. I say this doesn't matter because no one uses varying GHC HEAD versions to develop actual software, documentation and all. What I mean to say is that the only user of the Haddock that's developed in GHC tree is GHC itself. The only case where GHC actually used in-tree Haddock was when Herbert generated documentation for base-4.7 early for me to eye before the release. Even this doesn't matter because so close to the release I'll already have the existing GHC API integrated anyway. Again, it does not matter if GHC HEAD itself doesn't get
Re: Building GHC under Wine?
On 08/08/2014 07:21 AM, Alexander Kjeldaas wrote: Microsoft has free VMs for testing purposes. It expires after 90 days and the only relevant limitation that i see is that it's not licensed for a live operating environment. That might or might not exclude Travis, but scripting a test that developers can run personally should be allowed. https://www.modern.ie/en-us/virtualization-tools Alexander This seems to be a VM dedicated for running Internet Explorer, is it actually a fully-featured environment? The site doesn't show much info. On Aug 8, 2014 5:14 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 07/16/2014 12:55 AM, Joachim Breitner wrote: 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 Perhaps this is a bit off-tangent but few months ago there were some commits landing to the nix package manager which allow you to run tests in a Windows VM. It was created to run tests for things like cross-compiled packages but it probably could be adapted. If you don't mind actually installing Windows (in a VM) and have nix already/plan on using it then that might be a more preferable workflow: create a nix expression that builds a validates GHC in the VM and spits out the result. It's just something I thought I should mention in case anyone was interested. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: The build is broken? (Haddock parse error)
On 07/17/2014 09:05 AM, Páli Gábor János wrote:
Hello there,
I have just found the builds are failing due to this (see [1] for the full
log):
/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock
--odir=compiler/stage2/doc/html/ghc --no-tmp-comp-dir
--dump-interface=compiler/stage2/doc/html/ghc/ghc.haddock --html
--hoogle --title=ghc-7.9.20140717: The GHC API
--prologue=compiler/stage2/haddock-prologue.txt
--read-interface=../Cabal-1.20.0.1,../Cabal-1.20.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock
--read-interface=../array-0.5.0.0,../array-0.5.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/array/dist-install/doc/html/array/array.haddock
--read-interface=../base-4.7.1.0,../base-4.7.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/base/dist-install/doc/html/base/base.haddock
--read-interface=../bin-package-db-0.0.0.0,../bin-package-db-0.0.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bin-package-db/dist-install/doc/html/bin-package-db/bin-package-db.haddock
--read-interface=../bytestring-0.10.4.0,../bytestring-0.10.4.0/src/%{MODULE/./-}.html\#%{NAME},libraries/bytestring/dist-install/doc/html/bytestring/bytestring.haddock
--read-interface=../containers-0.5.5.1,../containers-0.5.5.1/src/%{MODULE/./-}.html\#%{NAME},libraries/containers/dist-install/doc/html/containers/containers.haddock
--read-interface=../directory-1.2.1.0,../directory-1.2.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/directory/dist-install/doc/html/directory/directory.haddock
--read-interface=../filepath-1.3.0.2,../filepath-1.3.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/filepath/dist-install/doc/html/filepath/filepath.haddock
--read-interface=../hoopl-3.10.0.1,../hoopl-3.10.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hoopl/dist-install/doc/html/hoopl/hoopl.haddock
--read-interface=../hpc-0.6.0.1,../hpc-0.6.0.1/src/%{MODULE/./-}.html\#%{NAME},libraries/hpc/dist-install/doc/html/hpc/hpc.haddock
--read-interface=../process-1.2.0.0,../process-1.2.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/process/dist-install/doc/html/process/process.haddock
--read-interface=../template-haskell-2.10.0.0,../template-haskell-2.10.0.0/src/%{MODULE/./-}.html\#%{NAME},libraries/template-haskell/dist-install/doc/html/template-haskell/template-haskell.haddock
--read-interface=../time-1.4.2,../time-1.4.2/src/%{MODULE/./-}.html\#%{NAME},libraries/time/dist-install/doc/html/time/time.haddock
--read-interface=../transformers-0.4.1.0,../transformers-0.4.1.0/src/%{MODULE/./-}.html\#%{NAME},libraries/transformers/dist-install/doc/html/transformers/transformers.haddock
--read-interface=../unix-2.7.0.2,../unix-2.7.0.2/src/%{MODULE/./-}.html\#%{NAME},libraries/unix/dist-install/doc/html/unix/unix.haddock
--optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o
--optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic
--optghc=-H32m --optghc=-O --optghc=-package-name
--optghc=ghc-7.9.20140717 --optghc=-hide-all-packages --optghc=-i
--optghc=-icompiler/basicTypes --optghc=-icompiler/cmm
--optghc=-icompiler/codeGen --optghc=-icompiler/coreSyn
--optghc=-icompiler/deSugar --optghc=-icompiler/ghci
--optghc=-icompiler/hsSyn --optghc=-icompiler/iface
--optghc=-icompiler/llvmGen --optghc=-icompiler/main
--optghc=-icompiler/nativeGen --optghc=-icompiler/parser
--optghc=-icompiler/prelude --optghc=-icompiler/profiling
--optghc=-icompiler/rename --optghc=-icompiler/simplCore
--optghc=-icompiler/simplStg --optghc=-icompiler/specialise
--optghc=-icompiler/stgSyn --optghc=-icompiler/stranal
--optghc=-icompiler/typecheck --optghc=-icompiler/types
--optghc=-icompiler/utils --optghc=-icompiler/vectorise
--optghc=-icompiler/stage2/build
--optghc=-icompiler/stage2/build/autogen
--optghc=-Icompiler/stage2/build
--optghc=-Icompiler/stage2/build/autogen --optghc=-Icompiler/.
--optghc=-Icompiler/parser --optghc=-Icompiler/utils
--optghc=-Icompiler/../rts/dist/build --optghc=-Icompiler/stage2
--optghc=-optP-DGHCI --optghc=-optP-include
--optghc=-optPcompiler/stage2/build/autogen/cabal_macros.h
--optghc=-package --optghc=Cabal-1.20.0.1 --optghc=-package
--optghc=array-0.5.0.0 --optghc=-package --optghc=base-4.7.1.0
--optghc=-package --optghc=bin-package-db-0.0.0.0 --optghc=-package
--optghc=bytestring-0.10.4.0 --optghc=-package
--optghc=containers-0.5.5.1 --optghc=-package
--optghc=directory-1.2.1.0 --optghc=-package --optghc=filepath-1.3.0.2
--optghc=-package --optghc=hoopl-3.10.0.1 --optghc=-package
--optghc=hpc-0.6.0.1 --optghc=-package --optghc=process-1.2.0.0
--optghc=-package --optghc=template-haskell-2.10.0.0 --optghc=-package
--optghc=time-1.4.2 --optghc=-package --optghc=transformers-0.4.1.0
--optghc=-package --optghc=unix-2.7.0.2 --optghc=-Wall
--optghc=-fno-warn-name-shadowing --optghc=-XHaskell2010
--optghc=-optc-DTHREADED_RTS --optghc=-DGHCI_TABLES_NEXT_TO_CODE
--optghc=-DSTAGE=2 --optghc=-Rghc-timing --optghc=-O2
Re: Updating Haddock submodule
On 07/15/2014 09:01 AM, Simon Peyton Jones wrote: Herbert, Austin I've just made a change to GHC that has a (trivial) knock-on effect in Haddock, so I had to update the submodule. Here is what I did, after consulting Austin. Can I humbly implore you both (or someone) to write down the workflow so that git-naïve people like me can do this with confidence, rather than (as now) in fear? Below is my draft of the workflow. It seems pretty complicated, and there are three places (in red) where I am unsure what to do. Please in writing the workflow, document every step as I have done below. Thanks! Simon 1. Starting point: · all changes made in GHC and in utils/haddock. · validate works 2. cd utils/haddock 3. git stash Keep my changes out of the way 4. git branch -av Keep the output 5. git checkout master Why 'master'? Because I know from talking to Austin that the ghc repo tracks Haddock's master branch. There is no way to get this information without talking to Someone Who Knows. There should be a wiki page that documents it. 6. Check that in the output of step 4, the current branch (which should be detatched-head) is the same commit as origin/master. I have no idea what to do if this isn't the case. 7. git pull Now Haddock's 'master' is up to date 8. git stash pop Apply the changes to the Haddock master branch 9. git add/commit to record and commit the patch as usual 10. git push Phew! At this stage we have updated Haddock. I think. 11. cd ../..Back into main ghc repo 12. git add/committo record patch as usual, but · include utils/haddock in the files you add. This will update the submodule pointer in the ghc repo · include the word submodule in the commit message 13. git push At this stage we have updated GHC too 14. to get utils/haddock back into the detached-head state. How do I do this? git submodule update doesn't ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Is https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules what you are looking for? Basically in step 12, you do your GHC hacking. Git should also show you a one line change with a commit reference which is your updated Haddock. You should commit that as well. Not sure why you have step 14, it seems to me that you should be good after 13. At step 14 you will already be pointing to the appropriate commit, it will just happen to be the same as the master branch at that point too so I think you're done. -- 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
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: 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: GHC 7.8.3 release
On 05/27/2014 10:06 AM, Austin Seipp wrote: Hello all, After a long week, I've finally gotten a little time to reply to emails, and I mainly have one question I'd like to ask. First, please direct your attention to this: https://ghc.haskell.org/trac/ghc/query?status=closedstatus=mergestatus=patchmilestone=7.8.3group=resolutioncol=idcol=summarycol=ownercol=typecol=prioritycol=componentcol=versionorder=priority This is the 7.8.3 milestone, but it only considers things that are: - 1) Fixed - 2) Going to be merged - 3) Are a patch to be still merged. That is, it is a solid representation of the difference between 7.8.2 and the 7.8 branch tip. The question is: when should we do the release? There are several bugs there that seem quite problematic for users - #9045, #7097, #9001, #8768 and #9078 in particular. If these bugs are really problematic (and I sort of feel they are) then the release can happen soon. I can do it within a week from now, and we could punt more to a 7.8.4 release. I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. PS: I apologize for the lack of status updates and brief email - my time for GHC has been in very short order the past two weeks in particular, and I've finally just returned to a computer (not mine) for right now to ask this. PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. It has been a month since and the general opinion seems to have been Real Soon Now, are there any big blockers? -- Mateusz K. ___ 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/27/2014 01:19 PM, Johan Tibell wrote: On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’d be OK with this, (it’s a bit like requiring signatures on all top level functions) but I don’t know how we’d enforce it. I think social enforcement is enough. If we agree that this is something we want to do and communicate that to ghc-devs@, put a note in our style guide, and kindly remind people to add comments when we do code reviews, we'll eventually end up with a culture of writing Haddocks. I think the most important part right now is that current contributors agree that this is something we want to do. Aside: people usually say that they find it hard to know what to document in their own code, because they don't know what others will find difficult. My advice is this: add a sentence or two about what the function does and why it exists, no matter how obvious you think that statement is. Do you think the requirement should be for all top-level functions or just exported ones? I take what I can get, but I think documenting all top-level functions makes sense in the case of GHC, as there's so much that goes on in our modules but we often only export a handful of functions. For example, compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 functions. For someone that wants to work on that module for the first time only have docs on those three functions is helpful, but likely not enough. FWIW I document all top-level functions in my projects (and when I don't I often regret it later). I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won’t be able to make much sense of it. Sure. Personally I would refer to the note from the function body if it talks mostly about the implementation, as opposed to how to use the function. Notes could be moved into the module header if necessary so that they are rendered by Haddock. Alternatively, one function can contain the note and other places can refer to it by means of an anchor. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs My personal gripe of trying to read docs for GHC modules/types is that some older modules are in .lhs format which means we have to dive out of nicely-rendered HTML and go into source. Was there ever talk of converting Literate Haskell files into more Haddock-friendly format? -- Mateusz K. ___ 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/27/2014 03:26 PM, David Fox wrote: I would counter propose a place on hackage for people to type in or modify the documentation for functions, designed in such a way that the documentation would easily find its way back into the project's source code (with developer approval.) This way the documentation can be generated by people who only recently came to understand the function, so the questions a newcomer has are fresh in their mind. Are you asking for a wiki-like thing for documentation? There were a few times where this has been proposed such as https://github.com/haskell/haddock/issues/72 but in general it turns out that there's not enough interest for anyone to sit down and implement it and make sure it all works properly. Patches should be going straight to upstream rather than lingering on Hackage until someone notices them (even with automated tools, it's a pain). I doubt many people would use it for anything but typos because if you have enough knowledge about a function to document it, you're likely to already be involved with the project in some way and have means to report it properly. On Fri, Jun 27, 2014 at 4:19 AM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’d be OK with this, (it’s a bit like requiring signatures on all top level functions) but I don’t know how we’d enforce it. I think social enforcement is enough. If we agree that this is something we want to do and communicate that to ghc-devs@, put a note in our style guide, and kindly remind people to add comments when we do code reviews, we'll eventually end up with a culture of writing Haddocks. I think the most important part right now is that current contributors agree that this is something we want to do. Aside: people usually say that they find it hard to know what to document in their own code, because they don't know what others will find difficult. My advice is this: add a sentence or two about what the function does and why it exists, no matter how obvious you think that statement is. Do you think the requirement should be for all top-level functions or just exported ones? I take what I can get, but I think documenting all top-level functions makes sense in the case of GHC, as there's so much that goes on in our modules but we often only export a handful of functions. For example, compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 functions. For someone that wants to work on that module for the first time only have docs on those three functions is helpful, but likely not enough. FWIW I document all top-level functions in my projects (and when I don't I often regret it later). I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won’t be able to make much sense of it. Sure. Personally I would refer to the note from the function body if it talks mostly about the implementation, as opposed to how to use the function. -- Johan ___ 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 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85)
On 06/24/2014 07:47 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/d8abf85f8ca176854e9d5d0b12371c4bc402aac3/ghc --- commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 Author: Johan Tibell johan.tib...@gmail.com Date: Mon Jun 9 11:43:21 2014 +0200 Add more primops for atomic ops on byte arrays Summary: Add more primops for atomic ops on byte arrays Adds the following primops: * atomicReadIntArray# * atomicWriteIntArray# * fetchSubIntArray# * fetchOrIntArray# * fetchXorIntArray# * fetchAndIntArray# Makes these pre-existing out-of-line primops inline: * fetchAddIntArray# * casIntArray# --- d8abf85f8ca176854e9d5d0b12371c4bc402aac3 compiler/cmm/CmmMachOp.hs | 19 ++ compiler/cmm/CmmSink.hs| 4 + compiler/cmm/PprC.hs | 4 + compiler/codeGen/StgCmmPrim.hs | 94 +++ compiler/llvmGen/Llvm/AbsSyn.hs| 7 + compiler/llvmGen/Llvm/PpLlvm.hs| 18 +- compiler/llvmGen/LlvmCodeGen/CodeGen.hs| 71 -- compiler/nativeGen/CPrim.hs| 50 +++- compiler/nativeGen/PPC/CodeGen.hs | 4 + compiler/nativeGen/SPARC/CodeGen.hs| 4 + compiler/nativeGen/X86/CodeGen.hs | 92 +++ compiler/nativeGen/X86/Instr.hs| 38 ++- compiler/nativeGen/X86/Ppr.hs | 8 + compiler/prelude/primops.txt.pp| 76 +- includes/stg/MiscClosures.h| 1 - libraries/ghc-prim/cbits/atomic.c | 280 + libraries/ghc-prim/ghc-prim.cabal | 1 + rts/Linker.c | 1 - rts/PrimOps.cmm| 12 - testsuite/tests/concurrent/should_run/.gitignore | 1 + .../tests/concurrent/should_run/AtomicPrimops.hs | 245 ++ .../concurrent/should_run/AtomicPrimops.stdout | 7 + testsuite/tests/concurrent/should_run/all.T| 1 + 23 files changed, 984 insertions(+), 54 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc d8abf85f8ca176854e9d5d0b12371c4bc402aac3 ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits I think the above killed compilation on 32-bit boxes. See the usually-green boxes turn red at [1], specifically validator1-linux-x86-head, freebsd-i386-head and solaris-x86-head. The error looks like: inplace/bin/ghc-stage1 -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 It'd be great if the devs would look at [1] every day or so. [1]: http://haskell.inf.elte.hu/builders/ -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85)
On 06/25/2014 07:37 AM, Johan Tibell wrote: I don't understand the error (are we out of registers in the register allocator? what can we do about that?). Simon could you please explain. As for the continuos builds, can't we have them email the list upon breakages? We could but I think there is no mechanism to tell what's meaningful breakage and how to present it. I think this should be part of the discussion in the “Offering GHC builder build slaves” thread and someone just needs to sit down and hook it up. This includes fancier things such as blaming commit ranges for specific test changes c. Short-term solution would be to subscribe to ghc-bui...@haskell.org and filter out the contents so only failing builds are shown, taking care to exclude the slaves which are failing constantly due to unrelated reasons. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Phabricator for patches and code review
On 06/07/2014 07:21 AM, Manuel M T Chakravarty wrote: So, why not put everything on GutHub and use pull requests and so on? SimonM writes that Phabricator is better than GitHub. I’m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let’s outsource the effort to GitHub. Manuel While I'm usually in favour of using GitHub for something due to the sheer amount of exposure to people with existing accounts, I have to say that there are few major deficiencies with it for this particular task: issue tracking is crap, you can do very little in ways of customisation, the TOS is pretty scary, labels are not sufficient enough for anything serious, it's very easy to miss comments on specific lines…. It's really not suited for medium/large scale issue tracking and code review. I do agree with you on the 3 disadvantages of using something like Phabricator (and I add an extra one that now a browser so for example you can't use it on X-less box although I'm not sure what the locally installed software does) but if people reading the patches (Austin, Herbert, anyone concerned at the moment) find it easier to do their job AND it becomes easier to ask for feedback then I think we should give it a go. As it stands, I'd rather use e-mail + few policies for code review c rather than GitHub which is really not suited for this task. Big downside of e-mail/Trac for this is it's hard to give iterative feedback on changing parts of patches. Simon Peyton Jones simo...@microsoft.com: At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin | Seipp | Sent: 06 June 2014 05:06 | To: ghc-devs@haskell.org | Subject: RFC: Phabricator for patches and code review | | Hello all, | | Recently, while doing server maintenance, several of the administrators | for Haskell.org set up an instance of Phabricator[1], located at | https://phabricator.haskell.org | | For those who aren't aware, Phabricator (or Phab) is a suite of tools | for software development. Think of it like a polished, semi-private | GitHub with a lot of applications and tools for all kinds of needs. | We've been using it to do issue tracking for Haskell.org maintenance and | like it a lot so far. | | One very nice aspect of Phabricator though is it has a very nice code | review tool, called 'Differential', that is very useful. For people who | have used a tool like Review Board, it's similar. Furthermore, it has a | very convenient userland tool called 'Arcanist' which makes it easy for | newcomers to post a review and get it merged when it's ready all from | the command line. | | I'd like to see if people are interested in using Phab _strictly_ for | code review of GHC patches. It is a dedicated tool specifically for | this, and I think it works much better than Trac or inline GitHub | comments. | | Also, Phab can also support post-commit reviews. So if I touch something | in the runtime system and just push, perhaps Simon or Edward
Re: GHC/cabal release procedures, and Stackage
On 06/07/2014 11:57 PM, Joachim Breitner wrote: Hi Michael, Am Samstag, den 07.06.2014, 21:06 +0300 schrieb Michael Snoyman: If there was a daily snapshot build, I would be happy to set up some kind of regular process to download that snapshot and do a Stackage run on it. I'm currently blocked on this kind of activity, since I can't get a successful GHC 7.8 build due to my system using the Gold linker. That would be great, both for GHC and for people who want to have their packages work on GHC HEAD without manually monitoring it. There is http://deb.haskell.org/ which should produce daily debian packages for Debian wheezy. I guess if you are building on that platform, such packages are easiest to use (as you need no particular tooling to update and install). http://deb.haskell.org/dailies/latest/ is currently lagging due to temporary full disk, but I hope that by tomorrow, we have a new build. There used to be daily snapshot builds at http://darcs.haskell.org/ghcBuilder/uploads/ but that is defuct (Can someone remove the link from http://www.haskell.org/ghc/download). I wonder if the “new” builder infrastructure at http://haskell.inf.elte.hu/builders/ assembles the snapshots somewhere, then you can use them. Some builders such as upload snapshots but I don't know how it's decided which. See [1] for example of such build. I think Pali makes the call. Or you can build GHC yourself as part of the stackage run. Greetings, Joachim ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs [1]: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/282.html -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: haddock in 7.8.3
On 06/06/2014 11:44 AM, Simon Peyton Jones wrote: I want to change the interface to PatSyn.patSynSig, as part of fixing a bug in 7.8.2. But Haddock calls patSynSig, so there is a (fairly trivial) knock on change to Haddock Is that acceptable in a 7.8.3 release cycle? There are already some Haddock changes going into 7.8.3 anyway so I don't see why not as long as someone can push it into the ghc-7.8 branch. The only thing to watch out for is that this branch is separate from the current master branch so the fix has to be applied on both. If not, I can program round it in the 7.8.3 branch. But if it's not a problem, it'd be a bit easier just to make the change in Haddock? (Really Haddock has to be co-released with GHC, since it depends on many internal GHC details.) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: NondecreasingIndentation ( de-tabbing several .hs files)
On 05/15/2014 12:12 PM, Herbert Valerio Riedel wrote: Hello GHC devs, While I refactored the ghc code base to declare LANGUAGE pragmas locally, rather than via -X-flags on the GHC commandline, I've noticed there were a couple of places where NondecreasingIndentation grammar was used. What's the current consensus on the use of NondecreasingIndentation? Is its use still encouraged? Moreover, I touched several files (over 300) while refactoring, would that qualify as working on this module in the sense of | While working on this module you are encouraged to remove it and detab | the module (please do the detabbing in a separate patch). or would that overreach wrt the original intent of the guideline quoted above? Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Is there a reason behind not just detabbing (and removing trailing whitespace) the whole tree in a patch? If you're going to detab in a separate patch anyway, might as well do all of it once and for all. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: NondecreasingIndentation ( de-tabbing several .hs files)
On 05/16/2014 03:35 PM, Johan Tibell wrote: On Fri, May 16, 2014 at 3:33 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: Is there a reason behind not just detabbing (and removing trailing whitespace) the whole tree in a patch? If you're going to detab in a separate patch anyway, might as well do all of it once and for all. There are two reasons: * Main reason: it will create lots of merge conflicts for people working on the code base. I suppose such action would be announced a week or so beforehand but yes, I suppose. * Minor reason: you will now be 'git blame'd for most lines of the source. It's possible to have git ignore that, but it's a source of annoyance. It does not matter I feel because you're encouraged to detab in a separate patch anyway so blaming will show that whether it's all done at once or separately. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: classP recently deleted from TH.Lib
On 05/13/2014 12:33 AM, Gabor Greif wrote:
On 5/12/14, Richard Eisenberg e...@cis.upenn.edu wrote:
This one was my fault/decision. The TH.Lib functions tend to mirror exactly
the constructors in TH.Syntax. We removed the constructors (for good reason
Hmmm, okay, I see you added `equalityT` which is just a shallow
wrapper around a new constructor.
-- predicates and types really are the same now), so I thought it best to
remove the TH.Lib function, too. In the cases where code had to be updated,
would keeping classP in be enough to prevent the breakage?
Cannot speak for many packages, but adding `classP` back would make
llvm-general-pure compilable again with HEAD. Maybe we could add it
back and mark it as deprecated?
Why not simply patch llvm-general-pure? I have done this with quite a
few packages when the TH change was made and it seems to work. If
anything, it will make the authors realise something changed upstream
and try to find out how.
We could, of course, just leave the functions there with new
implementations, but that feels like it could accumulate legacy functions
over time.
I see no serious drawbacks with an explicitly deprecated API.
Here are some ideas for this, and other similar situations, going forward:
1) Don't remove functions from TH.Lib unless absolutely necessary (which
should probably never happen).
2) Remove functions from TH.Lib, but support some other package
(th-compat) which fills in the compatibility gap. This package would not
be tied in with GHC. It would use CPP to export functions in order to remain
compatible with a range of GHC versions. In this example, the package would
export a fresh classP in 7.9+ but just re-export TH's in 7.8-.
This sounds like a good idea, but the dependent packages would need to
adopt this scheme. I.e. import `classP` from th-compat, and hiding
`classP` from import TH.Lib.
Not sure what the best practices are. Anyway, if this scheme works,
one could remove TH.Lib.classP from GHC 7.12.
3) Do what I've done -- keep TH.Lib parallel with TH.Syntax and leave it to
users to sort it out as they see fit.
This would imply that some packages need to perform preprocessor
conditional compilation to include `classP`. IMHO the worst option, as
it causes duplication.
I think this is a fair solution until TH 2.9 is phased out.
Just my few cents.
Cheers,
Gabor
It is worth noting that a change of this sort in TH.Lib corresponds to a
breaking change in TH.Syntax. But, perhaps most people rely on Lib and not
on Syntax.
I'm happy to follow what the community thinks is best here -- I don't have
any vested opinion.
Thanks -- and sorry for the breakage!
Richard
On May 12, 2014, at 10:35 AM, Johan Tibell johan.tib...@gmail.com wrote:
That would be nice. I had to fix some breakage caused by this in one of
Bryan's libraries.
On Mon, May 12, 2014 at 4:12 PM, Gabor Greif ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
removed a helper to construct applied type class constraints (`classP`).
Some packages (notably `llvm-general-pure`) though, depend on it.
Can we add back something like this:
{{{
classP :: Name - [Q Type] - Q Pred
classP cla tys
= do
tysl - sequence tys
return (foldl' AppT (ConT cla) tysl)
}}}
and export it again? Or is there such a helper with a different name
already?
Cheers,
Gabor
___
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
--
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Loading package integer-gmp ... command line: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)
On 05/12/2014 12:41 AM, Gergely Risko wrote: The following message is a courtesy copy of an article that has been posted to gmane.comp.lang.haskell.ghc.devel as well. On Sun, 11 May 2014 21:42:45 +0200, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk writes: Are there any downsides to doing this except slightly bigger binary size? There are license issues if you want to distribute the resulting stuff. Have to ask your lawyers about lgpl + gmp + shipping binary only stuff. On the technical side, there are no other downsides. Sorry, you're correct, I did not pass interactive. Find attached the strace with --interactive. [...] Actually, I'm doing this already: https://github.com/Fuuzetsu/nix-project-defaults/blob/master/ghc/default.nix At the end of your strace, I see this: Loading package integer-gmp ... [pid 10676] open(/home/shana/programming/ghc/libraries/haskeline/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/terminfo/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/compiler/stage2/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/transformers/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/template-haskell/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/hpc/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/hoopl/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/bin-package-db/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/binary/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/Cabal/Cabal/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/process/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/pretty/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/directory/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/unix/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/time/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/old-locale/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/filepath/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/containers/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/bytestring/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/deepseq/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/array/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/base/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/integer-gmp/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/libraries/ghc-prim/dist-install/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/home/shana/programming/ghc/rts/dist/build/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/run/opengl-driver/lib/tls/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/run/opengl-driver/lib/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open(/run/opengl-driver-32/lib/tls/libgmp.so, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
Re: Loading package integer-gmp ... command line: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)
On 05/12/2014 09:51 AM, Mateusz Kowalczyk wrote: On 05/12/2014 12:41 AM, Gergely Risko wrote: The following message is a courtesy copy of an article that has been posted to gmane.comp.lang.haskell.ghc.devel as well. On Sun, 11 May 2014 21:42:45 +0200, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk writes: Are there any downsides to doing this except slightly bigger binary size? There are license issues if you want to distribute the resulting stuff. Have to ask your lawyers about lgpl + gmp + shipping binary only stuff. On the technical side, there are no other downsides. Sorry, you're correct, I did not pass interactive. Find attached the strace with --interactive. [...] Actually, I'm doing this already: https://github.com/Fuuzetsu/nix-project-defaults/blob/master/ghc/default.nix At the end of your strace, I see this: Loading package integer-gmp ... [pid 10676] [...] So you can see that it tries to read libgmp from a lot of places, but not from the one you specified in build.mk, so this seems to be a build system bug. The last commit in GHC that I tried and succeeded to compile 2 weeks ago with a very similar setup as yours was this: 12332f1add3eb9615a62abb36898819b2e67e865 Can you please try that so we can rule on whether there was a change very recently that broke this. I am even running 'patchPhase configurePhase buildPhase' which should technically be exactly what nix does with the package in nixpkgs. By the way, the official nix package for HEAD isn't quite HEAD but instead a snapshot of somewhere near HEAD and in fact I'm the person that opened an issue and a PR to get that updated. The fact that it builds that but doesn't build when I'm in the source tree makes me wonder what's different. I see. I'm flying out in 10 hours for vacation, so won't have time to reproduce your issue and look into this more deeply. If you figure out what's happening, please send me a summary. Enjoy your vacation. Maybe you should move this thread to the gmane.linux.distributions.nixos mailing list from here, because I guess Peter Simons and co can help you more with this, than GHC devs. Perhaps I should. I have tried with --with-intree-gmp and DYNAMIC_BY_DEFAULT=OFF and they both fail at the same time. Next stop is to try to build from some snapshots to see whether the problem is recent. If I find the bandwidth during travels, I will try to keep an eye on this. Gergely Today I built the snapshots from 20140430[1] and 20140510[2] without a problem (just had to not build the postscript docs as those failed) which makes me think there's either something wrong with my tree or these snapshots do something that stops the problem from coming up. [1]: http://deb.haskell.org/dailies/2014-04-30/ghc_7.9.20140430.orig.tar.bz2 [2]: http://deb.haskell.org/dailies/2014-05-11/ghc_7.9.20140510.orig.tar.bz2 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Loading package integer-gmp ... command line: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)
Hi, Trying to compile GHC in the source tree on NixOS and meeting with failure with: inplace/bin/ghc-stage2 -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... command line: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory) While libgmp isn't anywhere obvious, below is my build.mk and content of the pointed-to directories. Am I missing something here? Is something ignoring the configure option maybe? [shana@lenalee:~/programming/ghc/mk]$ cat build.mk libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-libraries=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-includes=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include DYNAMIC_BY_DEFAULT = NO [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib total 604K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r-xr-xr-x 1 root nixbld 949 Jan 1 1970 libgmp.la lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so - libgmp.so.10.1.3 lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so.10 - libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 556K Jan 1 1970 libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 1.1K Jan 1 1970 libgmpxx.la lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so - libgmpxx.so.4.3.3 lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so.4 - libgmpxx.so.4.3.3 -r-xr-xr-x 1 root nixbld 30K Jan 1 1970 libgmpxx.so.4.3.3 [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include total 204K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r--r--r-- 1 root nixbld 78K Jan 1 1970 gmp.h -r--r--r-- 1 root nixbld 114K Jan 1 1970 gmpxx.h -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Adding a dependency to the build system
Hi, Today I have split Haddock up a little to allow users to use the Haddock parser without incurring the dependency on GHC. This means the Haddock tree looks like this now: haddock/haddock.cabal haddock/src/… haddock/haddock-library/haddock-library.cabal haddock/haddock-library/src/… haddock/haddock-library/… haddock/… For details see [1]. In the haddock.cabal, we now depend on haddock-library. While this works fine in a regular development scenario, GHC build system needs to be made aware that it has to build haddock/haddock-library before haddock/. I tried looking at the build system but it is far too complicated to comprehend in a reasonable amount of time. Can someone already familiar with it make the change (in a separate branch or give me the diff so I can push the Haddock changes while at the same time updating submodule + build system) or tell me what exactly needs changing? haddock-library only uses a subset of Haddock's existing dependencies so there should be no problem on that end. A workaround would be to simply include haddock-library paths as additional source locations but I don't like it this approach as it breaks the ‘haddock-library is its own package’ abstraction. For example, this would not work if we ever wanted to move haddock-library to its own repository. Thanks! [1]: https://github.com/Fuuzetsu/haddock/tree/parser-split -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
On 05/02/2014 03:50 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/b0534f78a73f972e279eed4447a5687bd6a8308e/ghc --- commit b0534f78a73f972e279eed4447a5687bd6a8308e Author: Simon Marlow marlo...@gmail.com Date: Mon Apr 28 16:55:47 2014 +0100 Per-thread allocation counters and limits This tracks the amount of memory allocation by each thread in a counter stored in the TSO. Optionally, when the counter drops below zero (it counts down), the thread can be sent an asynchronous exception: AllocationLimitExceeded. When this happens, given a small additional limit so that it can handle the exception. See documentation in GHC.Conc for more details. Allocation limits are similar to timeouts, but - timeouts use real time, not CPU time. Allocation limits do not count anything while the thread is blocked or in foreign code. - timeouts don't re-trigger if the thread catches the exception, allocation limits do. - timeouts can catch non-allocating loops, if you use -fno-omit-yields. This doesn't work for allocation limits. I couldn't measure any impact on benchmarks with these changes, even for nofib/smp. --- b0534f78a73f972e279eed4447a5687bd6a8308e compiler/cmm/CmmLayoutStack.hs |9 +- compiler/codeGen/StgCmmForeign.hs | 268 ++-- includes/CodeGen.Platform.hs |4 +- includes/rts/Constants.h |6 + includes/rts/Flags.h |8 + includes/rts/Threads.h |8 +- includes/rts/storage/TSO.h | 31 ++- libraries/base/Control/Exception.hs|1 + libraries/base/Control/Exception/Base.hs |1 + libraries/base/GHC/Conc.lhs|6 + libraries/base/GHC/Conc/Sync.lhs | 92 ++- libraries/base/GHC/IO/Exception.hs | 21 +- rts/HeapStackCheck.cmm |4 +- rts/Linker.c |4 + rts/Prelude.h |2 + rts/RaiseAsync.c | 54 rts/RaiseAsync.h |4 + rts/RtsFlags.c | 10 + rts/RtsStartup.c |1 + rts/Schedule.c | 19 ++ rts/Threads.c | 77 +++--- rts/package.conf.in|2 + rts/sm/Storage.c |6 + testsuite/tests/concurrent/should_run/all.T|7 + .../tests/concurrent/should_run/allocLimit1.hs |9 + .../tests/concurrent/should_run/allocLimit1.stderr |1 + .../tests/concurrent/should_run/allocLimit2.hs | 17 ++ .../tests/concurrent/should_run/allocLimit3.hs | 15 ++ .../tests/concurrent/should_run/allocLimit3.stderr |1 + .../should_run/allocLimit3.stdout} |1 - .../tests/concurrent/should_run/allocLimit4.hs | 31 +++ utils/deriveConstants/DeriveConstants.hs |1 + 32 files changed, 576 insertions(+), 145 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc b0534f78a73f972e279eed4447a5687bd6a8308e ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits I just tried to compile a snapshot involving this commit and got a compile failure: http://lpaste.net/103540 I was compiling with GHC 7.8.2 on a 32-bit machine. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields merge
On 04/21/2014 03:12 PM, Austin Seipp wrote: Hello all, As some of you might have seen last week, my colleague Adam took the time to get his OverloadedRecordFields back up to date with regards to HEAD. I'm now wondering: when should we pull the trigger? I am inclined to say 'soon'. In particular, the ORF changes are rather large, and Adam has hinted to me it touches a lot of components of e.g. name resolution. A large change with some fairly big impacts, in other words. I think it is perhaps best to merge soon - so that it does not get out of date and cause undue burden to Adam, but also so that we have maximal amounts of time to sort out issues in the long haul that it might expose. Simon - I believe you reviewed Adam's work in the past, yes? I am wondering what you think we should do here. I am more than willing to defer to you and let you do the merge after another review. On the other hand, if you already did review it and feel confident after a look or two, I'm more than willing to take over sometime this week. Adam - since you emailed us last week, Herbert went ahead and merged 'base' into GHC's repository. This does not invalidate the changes you gave us, it just means the two commits can be collapsed into one. Also, the performance failures seem like minor anomalies, but I have not yet directly built the ORF branch to confirm this. You're free to rebase yourself, or I can likely handle it without much issue soon. If anyone else has opinions here - please speak up, I'm all ears. For those reading, Adam's implementation is available in current form here: - https://github.com/adamgundry/ghc - https://github.com/adamgundry/packages-base - https://github.com/adamgundry/haddock I see a change to the Haddock interface file but the interface file version was not bumped (top of the file) which means that Haddock will try to read old interface file versions which will fail (I think). I would try myself but my system currently isn't really in appropriate state, perhaps I manage to do so later. It'd be great if we could default that to empty Map if we can't read it in but I don't think we can do that with existing binary (but we should be able to with the future CBOR stuff). Other than that, the Haddock patch looks good but again, I can not try it myself at the moment. I have to say I'm quite excited for overloaded records. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Offering GHC builder build slaves
On 08/04/14 02:06, Alain O'Dea wrote: Hi folks: I have successfully built Ian Lynagh's GHC builder on Ubuntu and SmartOS and I would like to offer build slaves based on Carter's mirroring of the code to https://github.com/cartazio/ghc-builder. I can offer several build slaves, but I'm not sure what the process is. How do I run multiple build slaves? Do I need a separate username for each? Is there a username convention? The suggestion at https://ghc.haskell.org/trac/ghc/wiki/Builder is that I post a username and password to ghc@. There are two issues with this: 1. ghc@ does not exist as far as I can tell 2. Posting a password to a mailing list will make it publicly accessible and allow others to impersonate my build slaves I am happy to send this information if the admins of the GHC builder infrastructure are comfortable with the risks. Alternatively, I am able to send this via GPG encrypted email given the public key and email of an admin. Feel free to contact me on or off list about this. Best, Alain ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs I can offer a 32-bit Linux slave (or 2) myself. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
On 25/03/14 06:01, kyra wrote: Will it include the latest commit to haddock? It solves this: http://trac.haskell.org/haddock/ticket/292. This can greatly improve performance of haddock in some situations (when a project is built with --split-obj flag). Cheers, Kyra Just as a follow up, as we had some more time, this is actually going into 7.8.1. Thanks -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
On 25/03/14 16:18, kyra wrote: On 3/25/2014 19:11, Mateusz Kowalczyk wrote: That commit is not in 2.14.1. Do you have any benchmarks to show the speedup? If the commit does some significant speedup, I'm not against backporting it into Haddock released with 7.8.2 (and there is at least 1 other fix I want to get into 7.8.2) but we pretty much closed the 2.14.1, it's up on Hackage and everything and that's what's planned to ship with 7.8.1. Hmm, now, when I'm trying to reproduce things I don't see haddock producing any assembly output let alone split it when using 7.8rc2 haddock. It seemed to me some time ago haddock became slow when processing a package built with --enable-split-objs and I've decided to look into things and discovered haddock wants .hi interface files and produces assembly output to produce these interface files. I was extremely surprised, rechecked things several times and saw the same picture. Now I can't reproduce this at all. If haddock never produced .hi interface files and/or assembly output then that was some mental aberration and the whole story can be dropped. Regards, Kyra ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs As far as I know (and this is mostly guessing), Haddock will ask GHC to produce .hi files when they do not already exist. I think you might have some luck if you simply try cabal configure cabal haddock but I don't know. I took the patch because I saw no harm in it and all tests were passing but I do admit that I did not check the performance gain (we don't have benchmarks, perhaps we should hook some up) or loss. I think GHC has some Haddock perf tests but I did not check the numbers and I don't think it would even fall under that. If you can come up with something then let me know. If you can't, I think we'll keep the patch just in case unless someone can show it breaks something. The only instances of Haddock becoming really slow that I can think of is some rather old ticket (#101 on Haddock Trac) in presence of Template Haskell but I have closed it a while ago due to lack of information to go on and inability to replicate without the reporter's help. Perhaps this was your use case? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
On 25/03/14 17:09, kyra wrote: On 3/25/2014 20:52, Mateusz Kowalczyk wrote: The only instances of Haddock becoming really slow that I can think of is some rather old ticket (#101 on Haddock Trac) in presence of Template Haskell but I have closed it a while ago due to lack of information to go on and inability to replicate without the reporter's help. Perhaps this was your use case? Aha, this is why I could not reproduce it! I checked it on packages which used no TH, and that slow behaviour occurred when TH was involved! I think it is TH which really triggers producing and splitting of an assembly output and in this case no-splitting gives *huge* benefit. Sadly, I have no time to check this right now. Regards, Kyra ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs There's no rush as it's not going to get into 7.8.1 anyway but I would love to see some numbers before 7.8.2 so please keep us in mind. Thanks! -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
module ‘free-4.6.1:Main’ is defined in multiple files
Greetings, First of all to people reading this at ghc-devs, I don't expect this to be a direct problem caused by GHC but who knows, so I'm CC'ing it anyway. As you might know, GHC 7.8.1 is scheduled to release Very Soon™ (later today?). We got a report at Haddock Trac few weeks ago about a strange error, see http://trac.haskell.org/haddock/ticket/284. I have asked about this on cabal-devel before and Mikhail said that maybe it's https://github.com/haskell/cabal/pull/1374 but it's unlikely because the changes aren't ran by default. Today I got new reports of this problem and so far everyone on OSX seems to be affected! This suddenly became a big problem. To replicate: 1. Find OSX machine 2. Get GHC 7.8 rc2 package (which includes Haddock at that stage) 3. git clone g...@github.com:ekmett/free.git cd free 4. cabal install --only-dependencies --enable-documentation cabal configure cabal haddock The reason I'm barking up cabal-devel and ghc-devs is because I honestly can not think of anything that has changed since Haddock 2.13.2.1 that could possibly cause this. Does anyone have any idea at all? I think it would be very bad to release now and have everyone on OSX unable to build docs. FYI I get build docs on 32-bit Linux. No idea about Windows. Thanks, I hope to hear back soon. PS: How does one go about downgrading Cabal and cabal-install? If we wanted to check whether cabal is the problem, how? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: packages/template-haskell] master: Make Pred a type synonym of Type (issue #7021) (57b662c)
On 22/03/14 20:37, Johan Tibell wrote: What's the right way to fix libraries (e.g. aeson) that break because classP was removed? I have already patched lens, aeson, free, derive and binarydefer. You can look for commits with my e-mail in those projects for how it was done. All you need to do now to get aeson to compile on 7.9 is to get Bryan to upload a new version with the relevant commit on Hackage. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Haddock strings in .hi files
On 19/03/14 11:39, Simon Marlow wrote: On 18/03/2014 18:20, Mateusz Kowalczyk wrote: Hi all, I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox and it reminded me of something I've been wondering for a while: why do we not store Haddock docstrings in the interface file? I think that if we did, we could do some great things: 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year ago, does anyone have any info?) 2. Allow Haddock to work a lot faster: the big majority of time spent when creating documentation is actually spent by Haddock calling various GHC functions, such as type-checking the modules. Only a small amount of time is actually spent by Haddock on other tasks such as parsing or outputting the documentation. If we could simply get everything we need from the .hi files, we save ourselves a lot of time. Don't you still have to run the renamer at least? And in GHC, renaming is tied up with typechecking, so it's hard to do one without the other. Furthermore, if there is a missing type signature it's useful to be able to put the inferred type in the documentation. I think I'm missing the point somewhere - how does putting docs in the .hi file let you avoid typechecking? This is a very good point and precisely why I have e-mailed ghc-devs first. I think you're correct. I suppose that idea is out of the window! I'm not really sure I see the benefit. If Haddock provided a library that we can call from GHCi to get documentation, then we could show documentation in GHCi. Considering that (as you point out), we can't really get rid of the time spent in GHC on renaming/type-checking, this does seem like the best way to go now. I think there's an old ticket somewhere about providing such a library that would let you work with Haddock interface files. I'll investigate that approach in some spare time. The current design is intended to separate Haddock from GHC as much as possible, but putting documentation in .hi files would be going in the opposite direction. There would have to be a compelling reason to do that, something that we couldn't do another way. I agree. Without being able to rip the major benefit of the idea (fast docs), it is not worth doing it now. Cheers, Simon Thanks! -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Haddock strings in .hi files
Hi all, I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox and it reminded me of something I've been wondering for a while: why do we not store Haddock docstrings in the interface file? I think that if we did, we could do some great things: 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year ago, does anyone have any info?) 2. Allow Haddock to work a lot faster: the big majority of time spent when creating documentation is actually spent by Haddock calling various GHC functions, such as type-checking the modules. Only a small amount of time is actually spent by Haddock on other tasks such as parsing or outputting the documentation. If we could simply get everything we need from the .hi files, we save ourselves a lot of time. 3. Allow Haddock to create partial documentation: a complaint I sometimes hear is if anything at all in the project doesn't type check, we don't get any documentation at all. I think that it'd be viable to generate only the documentation for the modules/functions that do type-check and perhaps skip type signatures for everything else. Points 1. and 2. are of clear benefit. Point 3. is a simple afterthought and thinking about it some more, I think that maybe it'd be possible to do this with what we have right now: is type-checking separate parts of the module supported? Can we retrieve documentation for the parts that don't type-check? I am asking for input on what people think. I am not familiar at all with what goes into the .hi file (and I can't find anything concrete! Am I missing some wiki page?) at all and why. At the very least, 1. should be easy to implement. It was suggested that I submit a proposal for this as part of GSoC, namely implementing 1. and 2.. I admit that having much faster documentation builds would be amazing and Edward K. and Carter S. seem to think that this is very do-able in the 3 month period that GSoC runs over. While I say all this, I have already submitted my proposal on a different topic. I am considering writing this up and submitting this as well but I am looking for some insight into the problem first. If there are any students around still looking for ideas, please do speak up if you want to snatch this. If there are people that are eager to mentor something like this then I suppose they should speak up too. Thanks! -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: haddock issue building ghc-7.8 from git
On 14/03/14 09:01, Matthias Fischmann wrote: Hi, When building from git (branch ghc-7.8 as of today), I run into a haddock issue because __GLASGOW_HASKELL__ appearently is not 709 on my system. Not sure whether this is a bug, and if it should go to trac/haddock or trac/ghc, so I decided to post it here. My fix is easy enough (even though I ran into other problems later, so I don't really know how well it works): | ~/src/ghc/utils/haddock/src/Haddock$ git diff | diff --git a/src/Haddock/InterfaceFile.hs b/src/Haddock/InterfaceFile.hs | index 924829d..19a742f 100644 | --- a/src/Haddock/InterfaceFile.hs | +++ b/src/Haddock/InterfaceFile.hs | @@ -76,14 +76,14 @@ binaryInterfaceMagic = 0xD0Cface | -- (2) set `binaryInterfaceVersionCompatibility` to [binaryInterfaceVersion] | -- | binaryInterfaceVersion :: Word16 | -#if __GLASGOW_HASKELL__ == 709 | +-- #if __GLASGOW_HASKELL__ == 709 | binaryInterfaceVersion = 25 | | binaryInterfaceVersionCompatibility :: [Word16] | binaryInterfaceVersionCompatibility = [binaryInterfaceVersion] | -#else | -#error Unsupported GHC version | -#endif | +-- #else | +-- #error Unsupported GHC version | +-- #endif | | | initBinMemSize :: Int thanks, matthias ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs The master branch of Haddock has that test for a reason: anyone working on Haddock will be doing so using GHC HEAD which is at 7.9. Haddock has a separate branch (named ghc-7.8) which is the candidate that will go into 7.8. If you're building GHC 7.8, you should be on that branch for Haddock and all the other libraries. IIRC you can pass some arguments to the sync-all script which will do all the switching for you but I forgot what it was. I'm sure someone else can chime in. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release
On 12/03/14 15:04, Simon Peyton Jones wrote: Friends The status of the GHC 7.8 release is here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2. Alas we are currently stalled on #8870, #8834: we are getting seg-faults on Windows. (For example, on my laptop, the stage2 compiler seg-faults when compiling some (but not all) files. Although few people develop GHC on Windows, many people *use* GHC on Windows, so we can't really release in this state. We need help! Austin is trying, but it's all working on his Windows build. He's trying to get more machines to see if he can reproduce the failure there. Does anyone feel able to help? Even git-bisecting to find the offending commit would be a huge help. In principle I can do that (at two hours per bisection) but I was defeated by an out-of-sync Haddock. I need to know how to remove Haddock from the build altogether. But others are far more skilled than me. Assuming Haddock is not the thing causing the problems here, I think it wouldn't be unreasonable to simply replace all contents of the Haddock directory with some dummy Main file, ask GHC to not build with docs and to not run any of the Haddock tests. This will only work if GHC doesn't use any of the exposed Haddock API of course. I believe I heard someone in #ghc say that Haddock is not a proper submodule of the repository (why isn't it?) so that's probably why it's going out of sync. We even have a long outstanding bug on Haddock Trac because we have no idea how to sanely bisect Haddock and GHC together to find the change! On #8834 Simon M speculates that we may have the callee-saves register wrong on Win64. Does anyone feel up to looking into that? Until we find what's going on, 7.8 is stalled. Thanks! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
On 08/03/14 07:19, Erik de Castro Lopo wrote: Mateusz Kowalczyk wrote: I'm trying to build HEAD but I'm getting libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory #include HsIntegerGmp.h ^ compilation terminated. make[1]: *** [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1 make: *** [all] Error 2 This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to build fine before. My last few versions are … drwxr-xr-x5 shana shana 4096 Feb 19 04:45 ghc-20140218 drwxr-xr-x5 shana shana 4096 Feb 22 22:04 ghc-20140220 drwxr-xr-x5 shana shana 4096 Feb 25 08:44 ghc-20140225 which means that the problem must have been introduced some time after that point. Does anyone have any ideas? What did you do that led up to this point? Erik ./sync-all get sync-all pull ./configure --prefix=/home/shana/ghc-20140308 make I also ran ‘./sync-all reset --hard’ I now ran ‘make clean ./configure --prefix=/home/shana/ghc-20140308 make’ and saved the results. You can find the log at http://fuuzetsu.co.uk/misc/ghc-20140308-gmp-log (~1.8MB). -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
On 08/03/14 08:11, Mateusz Kowalczyk wrote: On 08/03/14 07:19, Erik de Castro Lopo wrote: Mateusz Kowalczyk wrote: I'm trying to build HEAD but I'm getting libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory #include HsIntegerGmp.h ^ compilation terminated. make[1]: *** [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1 make: *** [all] Error 2 This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to build fine before. My last few versions are … drwxr-xr-x5 shana shana 4096 Feb 19 04:45 ghc-20140218 drwxr-xr-x5 shana shana 4096 Feb 22 22:04 ghc-20140220 drwxr-xr-x5 shana shana 4096 Feb 25 08:44 ghc-20140225 which means that the problem must have been introduced some time after that point. Does anyone have any ideas? What did you do that led up to this point? Erik ./sync-all get sync-all pull ./configure --prefix=/home/shana/ghc-20140308 make I also ran ‘./sync-all reset --hard’ I now ran ‘make clean ./configure --prefix=/home/shana/ghc-20140308 make’ and saved the results. You can find the log at http://fuuzetsu.co.uk/misc/ghc-20140308-gmp-log (~1.8MB). I was told in #ghc that I need to re-run ‘perl boot’ as well. I'll try it and post back if it still fails. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC for performance testing
On 06/03/14 09:50, Johan Tibell wrote: Hi, I'd like to set up a performance build bot for GHC, but before I can do that I need a script that reliably builds GHC and runs nofib. Do we have such a script? Here's a strawman proposal for one: cabal install happy alex git clone git://git.haskell.org/ghc.git cd ghc ./sync-all --nofib get perl boot ./configure make cd nofib make clean make boot make -k mode=slow Questions: * Does this look sensible? * Is there a way to only build and run a subset of the benchmarks? * Are there any tweaks to mk/build.mk we can do to make the build faster without compromising the results? * Is there a way to do this in a cheap throwaway VM like travis-ci does? Could such a VM already provide GHC and the required libs to make the whole thing hermetic? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs I think this ties in with the whole issue of not having nightlies/test bots running. I think if the infrastructure for that was in place then this would simply be a part of the functionality. re: subset of benchmarks, I believe they are just regular tests, in which case you can explicitly pass in which test cases should be ran. Correct me if I'm wrong. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields
On 25/02/14 16:18, Simon Peyton Jones wrote: Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; Plan may mean Design... I feel some rationalisation may make sense Simon | -Original Message- | From: Adam Gundry [mailto:a...@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? Hi Adam, I'm seeing that perf failure even without any of your changes. Perhaps you could try validating without your changes to confirm that the perf failure happens anyway? There are two Haddock test-suites of interest: tests ran by GHC to make sure that appropriate files parse (I updated these just yesterday so please make sure you're up to date) and Haddock's own test-suite to make sure that the output we produce is correct. To run Haddock's own tests, you can use ‘cabal test’. You'll need QuickCheck and hspec for this. Alternatively, to only run the tests ensuring our XHtml output is as expected, you can run ‘cabal test html-test’. This skips the comment parser tests (which shouldn't be relevant to you) but also doesn't force you to install the test dependencies I mentioned. I haven't checked your branch yet but I ask that you add appropriate test cases in html-test. See the README in the directory for help. You might want to check the accept.lhs file to help you doing this. Lastly, note that we have been pushed something into Haddock every day since Saturday so make sure you're up to date. I'll also be pushing something today I think. Thanks | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | | Simon | | | -Original Message- | | From: Adam Gundry [mailto:a...@well-typed.com] | | Sent: 17 January 2014 10:15 | | To: Simon Peyton Jones | | Subject: OverloadedRecordFields | | | | Hi Simon, | | | | I'm conscious that things have gone off the boil a little wrt | | OverloadedRecordFields, partially as a consequence of the delayed | | 7.8 release but also my lack of time for other projects since | | starting work for Well-Typed. With that in mind, I'd like to propose | | a plan to get back on track: | | | | 1. Revert to the three-parameter story, where we have | | | | t ~ FldTy r f = Has r f t | | | | rather than | | | | Has r f. | | | | The two-parameter version generates significantly worse error | | messages, and there are some other unresolved problems, so I'm not | | sure it is worth the minor simplification. | | | | 2. Roll back some of the refactoring that I've struggled to get | | right (in particular, trying to make the generated FldTy/UpdTy | | axioms implicitTyThings). We can always revisit this in the future | though. | | | | 3. Merge HEAD into my branch: I suspect this will be a bit painful | | by now, but presumably with 7.8 imminent there won't be many major | | changes coming for a while? | | | | 4. Review the proposed changes with you and fix any show-stopping | | problems. | | | | 5. Merge into HEAD after 7.8 is released. | | | | Does this sound plausible? I'm happy to Skype if you like. | | | | Cheers, | | | | Adam | | | | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | | Neil Ghani has got me some funding to work with them both on units | | of measure for Haskell. We are still sorting out the details, but I | | hope it might be possible to work on some kind of plugin mechanism | | for GHC's constraint solver, along the lines that Iavor has been | | investigating, if that would be of interest? | | | | -- | | Adam Gundry, Haskell Consultant | | Well-Typed LLP,
Change in rendering of [] in GADTs
While running Haddock tests today, we noticed that the output for a test
with GADTs changed. See the test file in the bottom.
We used to render ‘Nil :: Pattern '[]’ as ‘Pattern []’ but it now
renders as ‘Pattern `[]`’. The change happened within last 2 days and
I'm guessing it's d3af9807ca8a1db0bc9298ea50895ee9df55edb7 that made the
change.
Should this be something that we fix on Haddock end or should it be left
with the new rendering? I'm unsure whether the previous rendering wasn't
better or not.
The Haddock test suite is not ran as part of GHC validate process so it
the failure slipped by.
The file is:
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TypeOperators #-}
module AdvanceTypes where
data Pattern :: [*] - * where
Nil :: Pattern '[]
Cons :: Maybe h - Pattern t - Pattern (h ': t)
--
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 32-bit Linux perf failures
On 20/02/14 10:40, Joachim Breitner wrote: Hi, Am Donnerstag, den 20.02.2014, 01:39 + schrieb Mateusz Kowalczyk: I just ran validate with current HEAD (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf failures. Perhaps these need tweaking? I know that 32-bit numbers were neglected in the past. The Haddock numbers have been complaining for a few weeks now but I think everything else is fairly new. Here is the end of the log: Unexpected results from: TEST=T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal haddock.compiler haddock.base T3924 Call arity has improved T1969, T876, T7954, T3294 and T5631 (so the change for 32bit is expected, just update the numbers to what your computer says) and T3924 was added by my without 32bit numbers (so add your numbers, after adding the usual bitness-switch). Also T4267 is lacking 32-bit numbers. Generally, you might want to run git blame on the all.T-files and see if there was a recent change to the 64 bit numbers in the same direction than the change you are observing, and in that case simply update the numbers accordingly. Maybe when changing the 64-bit number we should have a way of marking the i386 as likely out of date, so that the next person on 32bit will see a message „Number changed, but that’s expected, so please just update all.T“. Greetings, Joachim ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs While I technically have the push permissions, I'm not a GHC dev. I feel like it'd be inappropriate to push in such a ‘fix’ myself. I can post a full validate log if that contains information one would need to update the numbers. Even if I wanted to, I have no idea how to go about updating the numbers! Is there a guide of some sort available? I was unable to find anything. Thanks -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pre-Master checks (Was: Nightlies)
On 04/02/14 09:41, Joachim Breitner wrote: Hi, Am Dienstag, den 04.02.2014, 08:04 + schrieb Simon Peyton Jones: I want just to say thank you for thinking about this. We badly need better nightly-builds for GHC, on a variety of platforms a) to identify regressions, preferably to the actually commit that caused it, so Austin's big red message can go to the right person I believe we can do better, so that Austin’s big red message does not have to be written in the first place. Here is what I have in mind, and I’ll volunteer to implement it if people think it is a good idea and I get the resources/permissions: Proposal Nobody gets to push to master directly. Instead, every push to master is diverted¹ to a temporary branch validating/some id. One of our servers detects the appearance of such a branch and will * check it out, * validate it, * if ok: check if master can still be fast-forward’ed to it, * if yes: push to master. If it does not validate, or if master has changed in between, the branch will be moved to failed/some id, and a message is sent to the pushing developer², including a tail of the log and a link to the full log. Systems can fail, and maybe nothing validates anymore for reasons not easily fixable. For that case, a backdoor is available: Pushes to the branch master-unchecked will be moved to master, well, unchecked. Benefits: * It is guaranteed that master has validated at least once somewhere. I.e. no need to ask on the mailing list “does master validate for you right now?” * It is now ok to do changes that are “obviously correct” (comment changes, removing dead code, code reformatting) without having to validate manually, which _saves developer time_ (our most precious resource). Downsides: * When two commits are racing for master, one will be rejected for being a non-fast-forward commit. The user will then have to merge or rebase and try again. But: The same would be true if he was validating locally (unless he does not validate the merge/rebase, in which case we are again where we don’t want to be: Unvalidated versions in master.) Is this something you would what, or could live with? If it is technically feasible (given our hardware constraints, repository structure and git’s feature) is a different question, which needs to be discussed afterwards. Greetings, Joachim ¹ Might not be possible transparently (http://stackoverflow.com/questions/21362833), but for the sake of argument and workflow design, assume it was. ² As an approximation: The committer of the latest patch. PS: I’m also considering (but not pushing hard) for a stronger variant as follows. We do not need to discuss that now and should, if at all, start the with the proposal above. I’m just adding it to show where this is going ... Stronger proposal ~ Every commit in master needs to be validated! I tend to make sure that all patches on my branch validate individually (git rebase -i -x ./validate is a great tool here, you should use it! ). Contributors who do not want to go through that trouble should then use git merge --squash to produce a single commit from their branch. This would make the git history more useful for things like bitsecting. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs You mention that it's enough for one machine to validate the patch. What if the change was for example to fix something on ARM (where builds take a long time) and has no effect on x86? The x86 machine is likely to come through first and give you the OK, pushing to master something that's effectively not checked. In fact, the fastest slave is likely to come through first every time and if it validates there (for example, I hear that 64-bit Linux is the golden platform for validate), it will be pushed to master. I think the proposal needs an enhancement: ability to specify which platform the commit needs to validate on (i.e. even if i686 comes through first, we'll wait for ARM anyway) before being pushed in. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
On 05/01/14 12:16, Dr. ERDI Gergo wrote: Hi, When I started working on pattern synonyms (#5144) back in August, it seemed the GHC 7.8 freeze was imminent, so I was planning for a first version in 7.10/8.0 (whatever it will be called). However, since not much has happened re: 7.8 since then (at least not much publicly visible), and on the other hand, my implementation of pattern synonyms is ready, I am now starting to wonder if it could be squeezed into 7.8. What are your thoughts on this? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Hi again, We've ran into some trouble over at #ghc regarding Haddock updates to do with PatternSynonyms. You have updated Haddock accordingly but at the same time, you haven't checked that you haven't broken it. This means that when we were trying to quickly fix a bug today, the Haddock tests came up as failing. There at least two faults that I've spotted: * Single space added in front of every function name. This isn't visible by the user but is visible by the test-suite and would require that we update every test file for no good reason. After a long while, I narrowed it down to the line “leader + ppTypeSig summary occnames pp_typ unicode” as it seems that ‘leader’ is empty for a lot of time and the (+) function adds a single space. It'd be an easy fix if it was only this but… * Data types using infix notations are now parenthesised Haddock now renders ‘data a :- b’ as ‘data a (:-) b’. This is a problem. I don't know what else is broken but I can't go on trying to fix this because you haven't added any tests for the features you put in! I have no idea what I'm breaking in PatternSynonyms when making changes. For now we have to revert some of the Haddock changes, namely the XHtml back-end stuff you added. The proposed revert is currently at [1] and will probably be put into the 7.8 RC very soon because the documentation for ‘base’ has to be generated. Please have a look and see what you can fix in the XHtml back-end for your feature. This includes making sure that the existing tests pass (you do this by running ‘cabal test’, just running validate for GHC is _not_ enough) and adding new tests for the things you add (you're going to be interested in adding test cases in html-test/src and adding the expected test results in html-test/ref). Thanks [1]: https://github.com/Fuuzetsu/haddock/tree/codeblockfix -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Reply etiquette
On 29/01/14 22:47, Joachim Breitner wrote: Hi, Am Mittwoch, den 29.01.2014, 23:18 +0100 schrieb Jan Stolarek: PS: I’m subscribed to the list, no need to send a copy to my private address. This is typically done to alert someone that he/she has been addressed directly in a discussion. I for example have my filters set in such a way that all ghc-devs mails are automatically marked as read unless I am CC'd. if someone really needs urgent attention from me, putting me in CC is fine: Mail directed to me will cause popups and land in my Inbox. But doing so carelessly makes this distinction useless; for example with the recent pattern synonym thread, I once made a minor comment and got a dozend mails explicitly sent to me. This is alerting thing is clearly not working – and I am tempted to the opposite of what you do: Automatically delete any mail reaching my inbox that also goes to ghc-dev (and stop whining here). But before doing that, I’ll try using the Reply-To header, let’s see if that works better. BTW, does everyone know about Reply-To-List (sometimes calle Group Reply, Ctrl-L in evolution) instead of Reply-To-All? But I heard rumors that Outlook does not support that, and – unlike in the Debian community – that would be a problem. I guess Reply-To can help then. Thunderbird has this, Reply List. I think the problem is that the reply headers sometimes get messed up: I always use Reply List but even then, Thunderbird often either replies to the person in question and CCs the list or the other way around. For this e-mail, I am only sending to the list, using Reply List. I think it adds the person by default if they address mail e-mail and similar thing probably happens for others. I try to remove such occurrences manually but I'm sure it sometimes slips by. I think that as long as you read ghc-devs, it's fine to set up your client to not show you things in your inbox. Greetings, Joachim ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Nightlies
On 26/01/14 11:16, Joachim Breitner wrote: Hi, Am Sonntag, den 26.01.2014, 02:22 + schrieb Mateusz Kowalczyk: I'd just like to query the status of the nightly builds. Is anything happening in that area? [1] is right on the front page of the GHC Trac even though no builds were ran for ~5 months. Perhaps it should be moved out of the way if there's no plan to resume these in the near future. just to clarify: For what purpose do you want the nightlies? To check whether GHC validates cleanly, to compare performance numbers, or to get hold of up-to-date binary distributions? Personally it's to see what validates that day and while we're at it, I don't see the reason to not use this to get the nightly binaries as well. I agree with pretty much everything that Páli said in his reply. If we can get the validate results from other people's machines, at the very least we have a sanity check: does it only fail for me or for everyone else too? I think that if we have a list of platforms with angry red everywhere, accessible to everyone, people are more likely to react to build failures and we're less likely to have e-mails on ghc-devs from people going ‘is it just me or is it failing for everyone?’. For the first, I’d really really like to see something that runs before a change enters master, so that non-validating mistakes like http://git.haskell.org/ghc.git/commitdiff/b26e2f92c5c6f77fe361293a128da637e728959c (without the corresponding change in http://git.haskell.org/ghc.git/commitdiff/59f491a933ec7380698b776e14c3753c2a318a89) do not reach master in the first place. I’m happy to help setting up such an infrastructure, including designing the precise workflow. I think doing a per-commit validate before something enters master would be difficult simply because one would have to wait a long time before their commit is allowed in. Even on the fast boxes, the quick validate from clean checkout seems to take about an hour at best. For the second and third, a build farm like the builders would of course be great. I actually once got a Igloo snowboall from Linaro for that purpose, but never finished setting it up properly. So once the builders are going to be revived, I’d like to finally do that. Greetings, Joachim -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Nightlies
Hi all, I'd just like to query the status of the nightly builds. Is anything happening in that area? [1] is right on the front page of the GHC Trac even though no builds were ran for ~5 months. Perhaps it should be moved out of the way if there's no plan to resume these in the near future. Does anything specific need doing to get these to run again? [1]: https://ghc.haskell.org/trac/ghc/wiki/Builder -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Nightlies
On 26/01/14 03:29, Austin Seipp wrote: As of right now, Pali's FreeBSD builds seem to be the only nightly that is still consistently running (and thanks to him for that!) The build infrastructure in its current status is mainly just 'unmaintained'. Furthermore there's not really a good roster of machines that were/were not part of the system AFAIK aside from the old list, and it's unclear what the status of many of those machines are (as you said, many haven't checked in in a while.) There is much interest in a better nightly infrastructure and people have asked me several times about setting one up on IRC. We have historically had some problems with the nightly infrastructure, mainly things like network disconnectivity or firewalling policies, since most people aren't running dedicated internet facing machines (or even a dedicated machine at all. Firewalls have been a problem for places like MSR from what I understand.) Why not simply have the clients post the results once a night? If the builds are nightly, is there really any need to have an open daemon listening? From what I can tell from http://darcs.haskell.org/ghcBuilder/builders/ it is simply the matter of building once a day/night and then posting the results in an e-mail to the list and uploading the binaries and test results elsewhere. Could we not simply have a wrapper script around GHC build process that in the end posts all these results to relevant places? The clients could simply have a nightly cron job and it'd be up to the slave owner to keep these builds going as often or as rarely as they want. The only downside is that you guys can't tell the clients precisely when to run but looking at build times, it's only once a day anyway. Several individual people run Jenkins individually, and I like it, but I'm not sure how well it does when spread across the globe in terms of networking (and realistically builders will look like that, as we can't possibly have a dedicated farm somewhere.) I was also at one point worried about the size of such a tool on systems like ARM machines where resources are at a premium, but in hindsight this looks OK. I'd like any opinions on this if people have deployed things in these highly distributed scenarios. I have had some ideas for an extremely-minimal nightly build infrastructure that would ideally require minimal setup and let clients have power over choosing how and when to build, but I have yet to find the time to finish the basic implementation to try it. On Sat, Jan 25, 2014 at 8:22 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: Hi all, I'd just like to query the status of the nightly builds. Is anything happening in that area? [1] is right on the front page of the GHC Trac even though no builds were ran for ~5 months. Perhaps it should be moved out of the way if there's no plan to resume these in the near future. Does anything specific need doing to get these to run again? [1]: https://ghc.haskell.org/trac/ghc/wiki/Builder -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Starting GHC development.
On 13/01/14 08:42, Simon Peyton Jones wrote: None seem to fail on my (Linux) box. It'd be good if someone felt able to dig into the ones that are failing. If there is a good reason we should open a ticket and mark them as expect_broken( ticket-number ). Thanks! Simon Hm. I checked a log from 6 days ago and here's the end of it: Unexpected failures: perf/compilerT1969 [stat too good] (normal) perf/compilerT3064 [stat not good enough] (normal) perf/compilerT3294 [stat not good enough] (normal) perf/compilerT4801 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat too good] (normal) We already know that the 32-bit Linux values for Haddock need updating but I have no idea about other ones. I will validate with a clean tree in the following few days and will pester the list with any failures but perhaps for the tests above, the numbers simply need updating. I do not know, I don't think there's any information anywhere about this. Perhaps there indeed aren't any problems but simply outdated tests. Can someone pitch in? Note that to a newcomer, a perf failure is still a failure especially considering that the bottom of the log tells you to fix these before sending any patches. I think fixing these is a little bit out of scope for a newcomer. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
On 13/01/14 11:06, Dr. ERDI Gergo wrote: On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote: I went ahead and pushed the preliminary work to a new branch in the official repositories. GHC, haddock and testsuite now have a 'wip/pattern-synonyms' branch, where you can test the code: https://github.com/ghc/ghc/commits/wip/pattern-synonyms https://github.com/ghc/haddock/commits/wip/pattern-synonyms https://github.com/ghc/testsuite/commits/wip/pattern-synonyms So what's the intended workflow for me from now on? Will master be regularly merged into this branch? Should I base my future work (like fixing the outstanding issues your mail detailed) on top of this branch and continue pushing to my github repo? Oh and also, how do I reword the commit message of the single squashed commit? I'm asking because there are some small fixes I'd like to do on the message. Thanks, Gergo You can do an interactive rebase and stop at the commit you want to change. Then use git commit --ammend to change the message. You probably don't want to be changing history too much though, it's a pain for anyone working on the same branch. On a somewhat related note, you should probably update your Haddock changes on top of the current master. Let me know if you have problems merging it on top. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Starting GHC development.
On 12/01/14 10:25, Daniil Frumin wrote: Does anyone actually know which tests are supposed to fail on 'validate'? AFAIK the official stance is that you should see 0 failures. Unofficially it seems that there's leniency and the tree seems to be in a state with few tests failing consistently. It might be just my machine though, but whenever I post my build logs, there seems to be no sense of urgency to investigate so it does not seem like anyone cares or the issue is known/being worked on. Unfortunately, the side effect of this (and what put me off when I tried to write some stuff for GHC months ago) was that a new developer comes, tries to build clean tree and it fails. It's pretty discouraging. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
Hi all, I have now merged in the new parser and new features onto a single branch. I'm having some issues validating with HEAD at the moment (#8661, unrelated problem) but while I get that sorted out, someone might want to try validating with Haddock changes on their own platform. The full branch is at [1]. I have squashed the changes to what I feel is the minimum number of commits until they completely stop making sense. It should apply cleanly on top of current Haddock master branch. The documentation is updated so you can read about what changed. Feel free to ask any questions. I will post again once I can confirm that the branch validates for me without any new test failures. Thanks for your patience. [1]: https://github.com/Fuuzetsu/haddock/tree/new-features -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On 10/01/14 10:01, Mateusz Kowalczyk wrote: Hi all, I have now merged in the new parser and new features onto a single branch. I'm having some issues validating with HEAD at the moment (#8661, unrelated problem) but while I get that sorted out, someone might want to try validating with Haddock changes on their own platform. The full branch is at [1]. I have squashed the changes to what I feel is the minimum number of commits until they completely stop making sense. It should apply cleanly on top of current Haddock master branch. The documentation is updated so you can read about what changed. Feel free to ask any questions. I will post again once I can confirm that the branch validates for me without any new test failures. Thanks for your patience. [1]: https://github.com/Fuuzetsu/haddock/tree/new-features This is just a simple follow up to say that the changes don't seem to break anything new on 32-bit Linux. I provide my validate logs before[1] and after[2] Haddock changes. Here's a word of warning: previously, when the mark-up wasn't 100% clear, we'd get a parse error and no documentation for the whole package. The new parser no longer does this and instead does its best to parse and present everything. This means that any Haddock parse failures should be reported as bugs. As you can see in [1], there were some parse failures in the past (look for ‘doc comment parse failed’) and they will now be rendered. This means the documentation might look bad in those places so it's probably worth while visiting those places and having a look. On an upside, at least we now have documentation for those packages. Validation was ran on commit 15a3de1288fe9d055f3dc92d554cb59b3528fa30 including #8661 fixes. Here's the relevant tail of the logs: Unexpected results from: TEST=lazy-bs-alloc T1969 T3064 T4801 T3294 T5498 haddock.Cabal haddock.compiler haddock.base OVERALL SUMMARY for test run started at Fri Jan 10 12:45:39 2014 GMT 0:17:23 spent to go through 3861 total tests, which gave rise to 15072 test cases, of which 11547 were skipped 28 had missing libraries 3432 expected passes 56 expected failures 0 caused framework failures 0 unexpected passes 9 unexpected failures Unexpected failures: deriving/should_fail T5498 [stderr mismatch] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat too good] (normal) gmake[2]: Leaving directory `/home/shana/programming/ghc/testsuite/tests' gmake[1]: Leaving directory `/home/shana/programming/ghc/testsuite/tests' == Start post-testsuite package check Timestamp 2014-01-10 12:45:36.897842164 UTC for /home/shana/programming/ghc/bindisttest/install dir/lib/ghc-7.7.20140109/package.conf.d/package.cache Timestamp 2014-01-10 12:45:36 UTC for /home/shana/programming/ghc/bindisttest/install dir/lib/ghc-7.7.20140109/package.conf.d (older than cache) using cache: /home/shana/programming/ghc/bindisttest/install dir/lib/ghc-7.7.20140109/package.conf.d/package.cache == End post-testsuite package check --- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. --- The failures are the same in both logs. Thanks! [1]: http://fuuzetsu.co.uk/misc/segfix [2]: http://fuuzetsu.co.uk/misc/segfixhaddock -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On 07/01/14 09:41, Simon Peyton Jones wrote: | Ping. I need GHC to validate. Here's what I'm trying to achieve: as you | might know, I worked on Haddock over summer, rewriting the whole parser, | adding tests, fixing bugs, adding features. As Haddock ships with GHC | however (and is technically a GHC HQ package), we can not merge it | without making sure that GHC can build and validate with the changes. | | This has been a problem for me and Simon Hengel for quite a while. We | now have a branch with preliminary changes on | https://github.com/sol/haddock/tree/new-parser . We can not even begin | to try to merge the new features if the parser they are built upon is | not merged. With the recent calls to push out a 7.8 release candidate, I | think we're running out of time to get this in (or is it too late | already?). It is not the first time we've been asking for help here! Actually I didn't know that you were asking to get something into 7.8. Haddock is maintained by David Waern and Simon Marlow, so the question of when to merge your changes into the main Haddock HEAD is up to them, not GHC HQ. We'll simply ship whatever Haddock we have when we cut the release candidate. (I know there is still some fuzz about when that will be; Austin is figuring that out now.) I'm copying David and Simon. Simon David stepped down and Simon Marlow has a long time ago too! It is now Simon Hengel who maintains it. The issue is that Simon could not get the tree to validate properly on his machine either so I'm here seeking help so that we can push up with confidence. Simon has e-mailed Austin on 22/11/2013 about it but we have been unable to verify that all is fine. Is it by now too late for 7.8? I'm afraid Simon H is away without much access to technology until the 20th. Un-CC'ing Simon M and David W and CC'ing Simon H. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On 07/01/14 10:20, Simon Peyton Jones wrote: | David stepped down and Simon Marlow has a long time ago too! It is now | Simon Hengel who maintains it. OK, well perhaps you can immediately push a change to haddock.cabal to reflect this? That's how we know. I will try later but I think I don't have permissions. I can at best push to Simon's branch where he would periodically push to the GHC hosted repository (or perhaps it would get pulled from, I do not know). | Is it by now too late for 7.8? I'm afraid Simon H is away without much | access to technology until the 20th. Realistically that would push 7.8 RC to the end of Jan. Why would that be better than pushing to head just after the 7.8 release? Will 7.8 users see a big improvement if it was in? What do others think? The changes were mostly there for user benefit. The markup can now be escaped much better. If we can validate what's on Simon's new-parser branch reasonably quickly, we might even be able to push in the new features: new mark up, nested paragraphs, better lists, headers… I'm trying to push for 7.8 because Haddock ships with GHC and 7.8 is the stable release that everyone will be using in couple of months time. If the changes don't get into 7.8, we'll have to wait for the next stable release for the users to benefit. Is this incorrect? I was always under the impression that the only Haddock releases we can reasonably make are with stable GHC releases. Of course, anyone can compile HEAD and generate the docs for their own viewing but for example, Hackage will run stable compiler and all the docs will still be using old Haddock. I'd love to hear that I'm wrong about this and that Haddock releases separate from GHC are possible but I don't think that's the case. S -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On 07/01/14 13:57, Simon Hengel wrote: Hey! Sorry for not being of much help with this right now. Regarding Haddock releases I think we updated the version used for Hackage independently of ghc before. Cheers. Oh, if that's the case then I no longer feel that it's urgent that we get it into 7.8 considering Hackage is where the bulk of the docs are. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On 07/01/14 18:21, Austin Seipp wrote: Yes, the skipped tests are normal. The testsuite has a concept of tests being built a certain 'way' - for example, you might test a piece of code by making sure it works compiled with -threaded, non-threaded, profiling, the LLVM backend, or any combination of those, etc. So a single *test* gives rise to multiple *test cases*. When you run validate, it runs it in a 'fast' mode by default as opposed to the slow mode. The fast mode only runs a subset of the overall test cases - it runs the most basic tests per file, which generally gives a pretty good indication as to what is going on. Also, the performance failures you're seeing are (I speculate) due to out of date performance numbers. Sometimes these numbers go up or down just due to code churn, but they're sometimes finnicky, because they may depend on the exact time a major GC happens or something. So a small wibble can cause them to sometimes occasionally fail. In any case, these results seem to indicate your branch looks quite OK, so I can try to merge this soon, if you think it is actually complete and ready. These are the numbers from the clean tree. I will now merge in my changes, validate again, run Haddock test suite and let you know how it went. If I see similar results, I'll assume it's fine. I greatly appreciate the help I've been getting on this thread. @Simon H. Do you think that the new features could be merged fairly soon too, if the basic parser stuff checks out? Does anything extra need doing? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On 07/01/14 20:15, Ian Lynagh wrote: On Tue, Jan 07, 2014 at 06:39:36PM +, Mateusz Kowalczyk wrote: On 07/01/14 18:21, Austin Seipp wrote: Also, the performance failures you're seeing are (I speculate) due to out of date performance numbers. Sometimes these numbers go up or down just due to code churn, but they're sometimes finnicky, because they may depend on the exact time a major GC happens or something. So a small wibble can cause them to sometimes occasionally fail. These are the numbers from the clean tree. The haddock perf numbers look pretty bad, especially the peak_megabytes_allocated: = haddock.base(normal) 429 of 3855 [0, 0, 0] peak_megabytes_allocated value is too high: Expectedpeak_megabytes_allocated: 139 +/-1% Actual peak_megabytes_allocated: 180 = haddock.Cabal(normal) 430 of 3855 [0, 1, 0] peak_megabytes_allocated value is too high: Expectedpeak_megabytes_allocated: 89 +/-1% Actual peak_megabytes_allocated: 150 = haddock.compiler(normal) 431 of 3855 [0, 2, 0] max_bytes_used value is too high: Expectedpeak_megabytes_allocated: 663 +/-1% Actual peak_megabytes_allocated: 794 I think it would be worth working out what's going on before merging more haddock changes. Thanks Ian Hi Ian, Is there any guidance on how these tests are performed? More importantly, is there any log of how the performance changed over time? Is it Haddock's fault that it has become slower or is it the cause of GHC changes? PS: If there's no performance over time log, it might be worth introducing something! -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
On 07/01/14 23:05, Dr. ÉRDI Gergő wrote: Hi, Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in 2 days all that has passed... Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs. One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound? Thanks, Gergo Hi Erdi, I'm hoping to push in some stuff for Haddock in few hours (or rather, have someone do it for me) but I know you have changed a few things in it for the pattern synonyms stuff. I looked at the changes and they weren't big and shouldn't clash. Is it fine with you to push the changes on our side and then have you merge on top of that or would you prefer to have it done another way? Thanks -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On 07/01/14 04:17, Carter Schonwald wrote: Well said points. 1) perhaps opening a ticket on ghc trac for your problem is a good next step. That way folks who are better at reading trac than email can help! I'll do so tomorrow if I don't get any replies with tips. 2) if the pattern synonyms branch gets merged in, you'll have to upstream the associated changes to haddock too right? It's not a show-stopper if Haddock can't document something. In fact there are many things it can't document already (GADT type constructors are an easy one). If someone writes the pattern synonym stuff for existing Haddock it's not a problem. The proposed changes from new-parser don't touch the parts that pattern synonyms would and if they did, it'd be easy to merge. Usually GHC HQ folk patch up Haddock when they change API so that it can still compile but everything extra tends to be a ‘if we can get it to document the new bleeding-edge feature, then great, if not, someone will make a ticket later’. I actually attempted to make Haddock work with some extra stuff that it currently can't document but because it so heavily depends on GHC, I need my GHC tree validating for that too. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Alex unicode trick
Greetings, When looking at the GHC lexer (Lexer.x), there's: $unispace= \x05 -- Trick Alex into handling Unicode. See alexGetChar. $whitechar = [\ \n\r\f\v $unispace] $white_no_nl = $whitechar # \n $tab = \t Scrolling down to alexGetChar and alexGetChar', we see the comments: -- backwards compatibility for Alex 2.x alexGetChar :: AlexInput - Maybe (Char,AlexInput) -- This version does not squash unicode characters, it is used when -- lexing strings. alexGetChar' :: AlexInput - Maybe (Char,AlexInput) What's the reason for these? I was under the impression that since 3.0, Alex has natively supported unicode. Is it just dead code? Could all the hex $uni* functions be removed? If not, why not? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Starting GHC development.
On 03/01/14 18:50, Gabor Greif wrote: On 1/3/14, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 03/01/14 13:27, Simon Peyton-Jones wrote: [snip] Thank you. We need lots of help! [snip] While I hate to interrupt this thread, I think this is a good chance to mention something. I think the big issue for joining GHC development is the lack of communication on the mailing list. There are many topics where a person has a problem with GHC tree (can't validate/build, some tests are failing), posts to GHC devs seeking help and never gets a reply. This is very discouraging and often makes it outright impossible to contribute. An easy example is the failing tests one: unfortunately some tests are known to fail, but they are only known to fail to existing GHC devs. A new person tries to validate clean tree, gets test failures, asks for help on GHC devs, doesn't get any, gives up. We should explicitly say somewhere that pinging for an answer is okay. Sometimes the key persons (for a potential answer) are out of town or too busy, and the question gets buried. Repeating the answer a few days later raises awareness and has higher chance to succeed. This is how other technical lists (e.g. LLVM's) work. Cheers, Gabor While bumping the thread might help, I don't think people missing it is always the case. Refer to Carter's recent e-mail about something very important: when is 7.8 finally happening. It was pinged 9 days later by Kazu and still no replies! In the end he had to make another thread nearly half a month after his initial one and directly CC some people to get any output… I think it's more about ‘I'm not 100% sure here so I won't say anything’ which is terrible for newcomers because to them it seems like everyone ignored their thread. For a newcomer, even ‘did you try make maintainer-clean’ might be helpful. At least they don't feel ignored. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Validating with Haddock
Greetings, I'm trying to validate HEAD and I care that Haddock is built alongside it (so --no-haddock is not an option). I get the following errors listed at the bottom of this e-mail. How can I validate so that it all builds? From what I understand, to validate I should: * Have a stable compiler in my PATH (7.6.3) * go to top level directory * run ‘sh validate’ Am I missing steps? == Start post-build package check Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache) using cache: /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache) using cache: /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache There are problems in package xhtml-3000.2.1: dependency base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76 doesn't exist There are problems in package ghc-paths-0.1.0.9: dependency base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76 doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. xhtml-3000.2.1 ghc-paths-0.1.0.9 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can't make libffi
On 23/08/13 20:13, Austin Seipp wrote: I believe this should now be fixed. On Thu, Aug 22, 2013 at 2:08 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: I started with a fresh tree today and am now getting inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -optc-DDYNAMIC_GHC_PROGRAMS -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/Linker.c -o rts/dist/build/Linker.o rts/Linker.c: In function ‘freeObjectCode’: rts/Linker.c:2073:18: error: ‘ObjectCode’ has no member named ‘symbol_extras’ rts/Linker.c:2074:16: error: ‘ObjectCode’ has no member named ‘n_symbol_extras’ make[1]: *** [rts/dist/build/Linker.o] Error 1 make: *** [all] Error 2 Help appreciated. -- I ra ‘./sync-all get’ followed by ‘./sync-all pull’ and I still get the same failure. […large snip…] inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/Linker.c -o rts/dist/build/Linker.o rts/Linker.c: In function ‘freeObjectCode’: rts/Linker.c:2062:18: error: ‘ObjectCode’ has no member named ‘symbol_extras’ rts/Linker.c:2063:16: error: ‘ObjectCode’ has no member named ‘n_symbol_extras’ make[1]: *** [rts/dist/build/Linker.o] Error 1 make: *** [all] Error 2 -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can't make libffi
On 23/08/13 21:31, Austin Seipp wrote: Ah, I see what your problem is now. I encountered this on 32bit Windows which was slightly different. While my i386 machine is spinning up, can you try the attached patch? If you haven't cleaned your build tree, you can do: $ git am ~/path/to/file.patch $ make from the root of the tree, and it should keep going normally. It seems to have worked: it's going along nicely, I think it got past the error stage. Hopefully I won't have any more problems. Much obliged. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Configure: gcc problem under mingw/i386
On 23/08/13 22:13, Niculae Ionita wrote: Hi all, I'm new to GHC Dev and I'm trying to build GHC 7.7 (the repo is about 9 days old) on a Windows machine with mingw32. I followed the very helpful article for newcomers to GHC dev ( http://ghc.haskell.org/trac/ghc/wiki/Newcomers# ) and up to configure it was easy. Now I get a problem with configure, the last few output lines are: GHC build : i386-unknown-mingw32 GHC host : i386-unknown-mingw32 GHC target : i386-unknown-mingw32 configure: Building in-tree ghc-pwd checking for path to top of build tree... j:/ghc checking for gcc... j:/ghc/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/j/ghc': configure: error: C compiler cannot create executables See `config.log' for more details From config.log it's clear that j:/ghc/inplace/mingw/bin/gcc.exe is missing (actually already the bin is missing). My gcc is in /mingw/bin, which is in PATH, but even if I try with the option --with-gcc=/mingw/bin/gcc I get the same error. So I was looking in the configure script and found out that, for mingw32 and i386, gcc must be under $hardtop/inplace/mingw/bin/, and if not, there are commands to unpack all tools from tar files like ghc-tarballs/mingw/binutils*.tar.lzma and a few others. The point is, I don't have the subdirectory ghc-tarballs under my ghc directory. Now, my questions: 1. Are there any reasons to not use the building tools coming from the mingw installation, and use the dedicated ones? 2. Where could I find those tarballs? Did I miss something when updated the repositories? Thanks, Nicu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs A lot of these questions have been answered in the recent thread by Simon titled ‘Building on windows’. http://www.mail-archive.com/ghc-devs@haskell.org/msg02094.html -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can't make libffi
On 20/08/13 11:55, Mateusz Kowalczyk wrote: Trying to build HEAD I get. inplace/bin/ghc-stage1@exeext_host@ -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/PrimOps.cmm -o rts/dist/build/PrimOps.dyn_o inplace/bin/ghc-stage1@exeext_host@ -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.dyn_o inplace/bin/ghc-pkg@exeext_host@ --simple-output field rts extra-libraries \ | sed -e 's/\([^ ][^ ]*\)/-l\1/g' rts/dist/libs.depend inplace/bin/ghc-pkg@exeext_host@ --simple-output field rts library-dirs \ | sed -e 's/\([^ ][^ ]*\)/-L\1/g' rts/dist/libs.depend make[1]: *** No rule to make target `libffi/build/inst/lib/libffi@soext_target@', needed by `rts/dist/build/libffi@soext_target@'. Stop. make: *** [all] Error 2 I know there is some repository moving shenanigans going on at the moment so I am not sure whether that's something to look out for. All I did was ./sync-all get and then ./sync-all pull without changing anything – I have the same setup as I did couple of weeks ago. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs I started with a fresh tree today and am now getting inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -optc-DDYNAMIC_GHC_PROGRAMS -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/Linker.c -o rts/dist/build/Linker.o rts/Linker.c: In function ‘freeObjectCode’: rts/Linker.c:2073:18: error: ‘ObjectCode’ has no member named ‘symbol_extras’ rts/Linker.c:2074:16: error: ‘ObjectCode’ has no member named ‘n_symbol_extras’ make[1]: *** [rts/dist/build/Linker.o] Error 1 make: *** [all] Error 2 Help appreciated. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: new pragma name ideas? (was: defunctionalization)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/07/13 23:18, Nicolas Frisby wrote: On Thu, Jul 18, 2013 at 5:10 PM, Carter Schonwald carter.schonw...@gmail.com wrote: So the idea here to make it possible to have a function that can be specialized at certain types, and explicitly inlined at specific use sites, but ghc otherwise will not inline it? Cool! one thought: might it be simpler to instead have something like EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas which seem contradictory? I like that idea. How about SPECIALISABLE? This is a nod to the possibility that GHC might someday automatically specialize an imported function. Or EXPOSE? Or EXTERNAL? Bikeshed activate! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Maybe we need a BIKESHED pragma that will let us alias any extensions within the project to anything we like. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR6G1uAAoJEM1mucMq2pqXrbYP/RXWS0yeI6Ewy6hx35rmqxPG TfCK5U9KjW9WkvWXZqJq407Z0Qluiif0UIfMFy8oujj3RnjJUKN+1Co/zVdYxyiD 0LGdS4SxDQO4aRTd1uRAjaMGzVUA4xkAp+lQNI9jKN0ZojMiSQHXr4FoThkNTV1r wWUlYwTeDJlm1HJgqcNMIjhegeG1GJrmz3i5BZgW7WBI65TL/8MfwEozFO8jjtzD R44gF0sIg7rWEfzO3jFuhr+F3w9vwZ24KzAFPLjAIJlmB/YiBK7WwiIXI0tQhdg/ /72vVgQQMGsmSauZ0j2hjfImGDU45wLZ21w26/kkn7F6k9k+6BRFsedI1qI0Bf7V UqTG4oWLaZ5+EYQhvLH4VjYtH7h3UgGacHiYHcKHnmL49rr6GjDWQqBE8pieAtkQ ckhTw+fpMPQZd6T6J5OX5VNsnWcEG4C89PPCvYL9Jvw8tq6uzcTdRbxc+Thu3Plr I6hmcM5Ibz0n+nvqWLzsY/4voQb/CtiZWQQZ+c2VbIx1HpWsKTH0NFdHX891faTn ijsm8wsO0YcyvtlFPfZxKoQfb1GiBN+ttdlYStS7i15YmDujl7GYlXeHz0nr9FYv nNpHoNkz+U+fH3Neeh4epCOGxUhkAPWG/u1tMTAxQad0JiLpedKxB/IMBen+16pb IT4deYFnfsQjp/HAQfHQ =h5Nz -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
