On Fri, Feb 17, 2012 at 09:22:29PM +, Simon Peyton-Jones wrote:
>
> HADDOCK_DOCS = NO
>
> I get validate failing just after trying to build a distribution. Tail of
> log below.
> Linking Setup.exe ...
> Configuring mtl-1.1.1.1...
> Setup.exe: Cannot find the program 'haddock' at
> 'c:
On Fri, Feb 17, 2012 at 04:02:33PM +, Simon Peyton-Jones wrote:
> This keeps happening with "sh validate --fast".
>
> Configuring dph-base-0.5.2.0...
> ghc-cabal: At least the following dependencies are missing:
> base ==4.4.*
> make[1]: *** [libraries/dph/dph-base/dist-install/package-data.mk
On Fri, Feb 17, 2012 at 04:39:29PM +, Simon Peyton-Jones wrote:
> pushed now.
Thanks!
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sorry; turned out to be my fault. (I was on a branch.)
S
From: Ben Lippmeier [mailto:b...@ouroborus.net]
Sent: 03 January 2012 02:48
To: Simon Peyton-Jones
Cc: cvs-ghc@haskell.org
Subject: Re: Validate fails on Windows
On 03/01/2012, at 3:52 AM, Simon Peyton-Jones wrote:
Validate fails on
On 03/01/2012, at 3:52 AM, Simon Peyton-Jones wrote:
> Validate fails on Windows (msys) thus. I have no idea what is going on, but
> it would be great if someone could fix it
>
> Simon
>
> "inplace/bin/ghc-cabal.exe" configure
> --with-ghc="c:/code/HEAD/inplace/bin/ghc-stage1.exe"
> --wit
On 17/11/2011 08:10, Simon Peyton-Jones wrote:
=> 5238(normal) 405 of 3102 [0, 0, 0]
cd ./concurrent/should_run &&
'/64playpen/simonpj/builds/HEAD-2/bindisttest/install dir/bin/ghc'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output
-no-user-package-conf -rtsopts -fno-ghci-history -o 52
Yes that's expect as Ian reversed a commit of mine because it caused
build problems. I'll update the testsuite to disable those tests until
I recommit the path Ian reversed.
On 28 October 2011 14:28, Simon Peyton-Jones wrote:
> David
>
>
>
> I’m getting these new failures on Linux
>
> safeHask
On Tue, Sep 27, 2011 at 02:56:23PM +0100, Max Bolingbroke wrote:
> On 27 September 2011 14:47, Ian Lynagh wrote:
> > Did you forget to record/push in the haddock repo?
>
> This is exactly what I did. Please try again now.
Looks good, ta.
Thanks
Ian
___
On 27 September 2011 14:47, Ian Lynagh wrote:
> Did you forget to record/push in the haddock repo?
This is exactly what I did. Please try again now.
Max
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Tue, Sep 13, 2011 at 02:17:24PM +0100, Ian Lynagh wrote:
> On Mon, Sep 12, 2011 at 09:58:23PM +, Simon Peyton-Jones wrote:
> > I get this failure on Windows. I have not investigated. I'm guessing
> > there's a #define out of place. Ian?
>
> I can reproduce it. I'll take a look.
Fixed.
On Mon, Sep 12, 2011 at 09:58:23PM +, Simon Peyton-Jones wrote:
> I get this failure on Windows. I have not investigated. I'm guessing there's
> a #define out of place. Ian?
I can reproduce it. I'll take a look.
Thanks
Ian
___
Cvs-ghc mailing
On 05/09/2011, at 18:12 , Simon Peyton-Jones wrote:
> My 'validate' fails thus, fairly early. Does anyone have any ideas?
>
> make[1]: *** No rule to make target
> `libraries/dph/dph-prim-par/dist-install/build/Data/Array/Parallel/Unlifted/Distributed/USegd.hs',
> needed by `libraries/dph/dph-
On Thu, Aug 19, 2010 at 08:12:43AM +, Simon Peyton-Jones wrote:
>
> Is this caused by your recent changes?
>
> make[1]: *** No rule to make target `clean_libraries/dph/dph-base', needed by
> `clean_libraries/dph'. Stop.
I guess you have GhcProfiled=YES in your tree? This was disabling DPH,
On Tue, Dec 22, 2009 at 09:08:54PM +0100, Matthias Kilian wrote:
> On Tue, Dec 22, 2009 at 06:26:16AM +, Duncan Coutts wrote:
> > > GNUisms, it's not Linux' fault, although I neither like Linux do I
> > > know any Linux distribution not using the GNU tools.
> >
> > I don't think this was a GNU
On Tue, Dec 22, 2009 at 06:26:16AM +, Duncan Coutts wrote:
> > GNUisms, it's not Linux' fault, although I neither like Linux do I
> > know any Linux distribution not using the GNU tools.
>
> I don't think this was a GNUism. I think this change was in response to
> a bug I reported where the pr
On Mon, 2009-12-21 at 20:50 +0100, Matthias Kilian wrote:
> On Mon, Dec 21, 2009 at 02:46:41PM +1100, Manuel M T Chakravarty wrote:
> > > 'tr' -d '\t' < compiler/main/DynFlags.hs | '/usr/bin/sed'
> > > '/^xFlags/,/]/s/^ *( *\("[^"]*"\)[^"]*/ [\1] ++/p;d' >>
> > > utils/ghc-cabal/dist-dummy-ghc/b
On Mon, Dec 21, 2009 at 02:46:41PM +1100, Manuel M T Chakravarty wrote:
> > 'tr' -d '\t' < compiler/main/DynFlags.hs | '/usr/bin/sed' '/^xFlags/,/]/s/^
> > *( *\("[^"]*"\)[^"]*/ [\1] ++/p;d' >>
> > utils/ghc-cabal/dist-dummy-ghc/build/dummy-ghc.hs
> > sed: 1: "s|/Users/chak/Code/ghc- ...": bad f
Yes, seems reasonable.
-Original Message-
From: Roman Leshchinskiy [mailto:r...@cse.unsw.edu.au]
Sent: 25 November 2009 07:26
To: Ian Lynagh; Simon Marlow
Cc: cvs-ghc@haskell.org list
Subject: validate fails if packages installed
Ian, Simon,
today I got the following error from validate
On Fri, Nov 13, 2009 at 02:44:33PM +1100, Manuel M T Chakravarty wrote:
> Documentation created: dist-install/doc/html/dph-par/index.html
> cd libraries && sh gen_contents_index --inplace
> haddock: internal Haddock or GHC error: directory-version:: openBinaryFile:
> does not exist (No such file o
On 06/08/2009 03:14, Manuel M T Chakravarty wrote:
I guess this broke during the recent RTS cleanup...
"/usr/bin/ghc" -optc-O -optc-Wall -optc-Werror
-optc-DTABLES_NEXT_TO_CODE -optc-Iincludes -optc-Irts -H32m -O -Wall
-Werror -H64m -O0 -fasm -i -iincludes/.
-iincludes/dist-derivedconstants/buil
Ian Lynagh:
On Sat, May 09, 2009 at 01:09:55PM -0400, Daniel Peebles wrote:
For what it's worth, I'm getting the same error (with a partial get
from this morning) on Mac OS X. Here's a paste of the output of those
make show VALUE you asked for:
Ah, thanks, I see the problem. Should be fixed no
On Sat, May 09, 2009 at 01:09:55PM -0400, Daniel Peebles wrote:
> For what it's worth, I'm getting the same error (with a partial get
> from this morning) on Mac OS X. Here's a paste of the output of those
> make show VALUE you asked for:
Ah, thanks, I see the problem. Should be fixed now.
Thank
For what it's worth, I'm getting the same error (with a partial get
from this morning) on Mac OS X. Here's a paste of the output of those
make show VALUE you asked for:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=4748#a4748
Thanks,
Dan
On Sat, May 9, 2009 at 9:27 AM, Ian Lynagh wrote:
> On Sa
On Sat, May 09, 2009 at 12:16:38PM +1000, Manuel M T Chakravarty wrote:
> Ian Lynagh:
> >On Tue, May 05, 2009 at 10:05:54AM +1000, Manuel M T Chakravarty
> >wrote:
> >>
> >> Building DocBook documentation : no
> >>
> >>So, I think, it shouldn't build docs at all
> >
> >It should not do so now. L
Ian Lynagh:
On Tue, May 05, 2009 at 10:05:54AM +1000, Manuel M T Chakravarty
wrote:
Building DocBook documentation : no
So, I think, it shouldn't build docs at all
It should not do so now. Let me know if you still have problems.
Unfortunately, it still seems to fail with the same error.
On Tue, May 05, 2009 at 10:05:54AM +1000, Manuel M T Chakravarty wrote:
>
>Building DocBook documentation : no
>
> So, I think, it shouldn't build docs at all
It should not do so now. Let me know if you still have problems.
Thanks
Ian
___
Cvs-gh
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -optc-Werror -optc-Wall
-optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-Ieventl
Manuel M T Chakravarty wrote:
I am fixing that for Mac OS right now.
The comment above setThreadAffinity() says,
// Schedules the thread to run on CPU n of m. m may be less than the
// number of physical CPUs, in which case, the thread will be allowed
// to run on CPU n, n+m, n+2m etc.
I am
Bryan O'Sullivan wrote:
On Thu, Mar 19, 2009 at 10:52 PM, Manuel M T Chakravarty
mailto:c...@cse.unsw.edu.au>> wrote:
The comment above setThreadAffinity() says,
// Schedules the thread to run on CPU n of m. m may be less
than the
// number of physical CPUs, in w
On Thu, Mar 19, 2009 at 10:52 PM, Manuel M T Chakravarty <
c...@cse.unsw.edu.au> wrote:
> The comment above setThreadAffinity() says,
>
> // Schedules the thread to run on CPU n of m. m may be less than the
>> // number of physical CPUs, in which case, the thread will be allowed
>> // to run on
I am fixing that for Mac OS right now.
The comment above setThreadAffinity() says,
// Schedules the thread to run on CPU n of m. m may be less than the
// number of physical CPUs, in which case, the thread will be allowed
// to run on CPU n, n+m, n+2m etc.
I am not convinced that this is a g
Matthias Kilian wrote:
[sent to ian only by accident; resending to the list]
On Sun, Jan 18, 2009 at 12:17:28PM +, Ian Lynagh wrote:
In fact, looking at pthread.h on Linux:
#ifdef __USE_UNIX98
,
PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RE
[sent to ian only by accident; resending to the list]
On Sun, Jan 18, 2009 at 12:17:28PM +, Ian Lynagh wrote:
> In fact, looking at pthread.h on Linux:
>
> #ifdef __USE_UNIX98
> ,
> PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
> PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
>
On Sun, Jan 18, 2009 at 11:04:53AM +0100, Matthias Kilian wrote:
> On Sat, Jan 17, 2009 at 11:21:03PM +, Ian Lynagh wrote:
> > OK, that mostly worked, but ffi014 timed out.
> >
> > It turns out that "hello world" linked with -threaded -debug deadlocks
> > at:
> > ASSERT_LOCK_HELD(&sched_mu
On Sat, Jan 17, 2009 at 11:21:03PM +, Ian Lynagh wrote:
> OK, that mostly worked, but ffi014 timed out.
>
> It turns out that "hello world" linked with -threaded -debug deadlocks
> at:
> ASSERT_LOCK_HELD(&sched_mutex);
> at the start of newBoundTask. This is doing
> ASSERT(pthread_mute
On Sat, Jan 17, 2009 at 02:42:28AM +, Ian Lynagh wrote:
>
> I think I've found the problem: file_lock_mutex wasn't initialised. I'll
> validate etc tomorrow.
OK, that mostly worked, but ffi014 timed out.
It turns out that "hello world" linked with -threaded -debug deadlocks
at:
ASSERT_LO
On Sat, Jan 17, 2009 at 02:42:28AM +, Ian Lynagh wrote:
> > I still don't understand why this failure does happen at all.
> > Running a build with -DLOCK_DEBUG may help to discover what's going
> > on, but you'll need a lot of disk space for the build log. I can't
> > help here much, because I'
On Sat, Jan 17, 2009 at 10:46:38PM +1100, Manuel M T Chakravarty wrote:
> Thanks for writing the patch. Nobody assumed you did that for no
> reason. However, a patch that fixes one and breaks another
> architecture ultimately does not fix the problem. From what you are
> writing, it doesn'
Matthias Kilian:
On Fri, Jan 16, 2009 at 03:20:59PM +, Simon Marlow wrote:
Configuring installPackage-1.0...
ghc: internal error: RELEASE_LOCK: I do not own this lock:
posix/FileLock.c 90
(GHC version 6.11.20090115 for i386_apple_darwin)
Please report this as a GHC bug:
http://www.hask
Simon Marlow:
Manuel M T Chakravarty wrote:
Simon Marlow:
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -
O0 -fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -
package-name rts -static -I../gmp/gmpbuild -I../libffi/build/
include -I. -
On Fri, Jan 16, 2009 at 09:35:53PM +0100, Matthias Kilian wrote:
> On Fri, Jan 16, 2009 at 03:20:59PM +, Simon Marlow wrote:
> > >Configuring installPackage-1.0...
> > >ghc: internal error: RELEASE_LOCK: I do not own this lock:
> > >posix/FileLock.c 90
> > >(GHC version 6.11.20090115 for i
On Fri, Jan 16, 2009 at 03:20:59PM +, Simon Marlow wrote:
> >Configuring installPackage-1.0...
> >ghc: internal error: RELEASE_LOCK: I do not own this lock:
> >posix/FileLock.c 90
> >(GHC version 6.11.20090115 for i386_apple_darwin)
> >Please report this as a GHC bug:
> >http://w
Manuel M T Chakravarty wrote:
Simon Marlow:
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -O0
-fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS
-package-name rts -static -I../gmp/gmpbuild
-I../libffi/build/include -I. -dcmm-lint -hisuf
Simon Marlow:
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -O0
-fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-
name rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -
dcmm-lint -hisuf debug_hi -hcsuf debug_hc -os
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -O0
-fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name
rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint
-hisuf debug_hi -hcsuf debug_hc -osuf debug_o -optc-D
On Mon, Jan 05, 2009 at 03:41:01PM +1100, Manuel M T Chakravarty wrote:
>
> System/Posix/Internals.hs:38:0:
> Warning: Module `System.IO.Error' is imported, but nothing from
> it is used,
>except perhaps instances visible in `System.IO.Error'
> To suppress this w
> > Yes, I don't have the test suite. The "testsuite" directory
> does not
> > exist.
> >
> > How do I get the test suite? I would have expected the
> details to be
> > at the top of this page:
> > http://hackage.haskell.org/trac/ghc/wiki/Building/RunningTests
>
> ./darcs-all --testsuite get
2008/10/15 Mitchell, Neil <[EMAIL PROTECTED]>:
>
> Yes, I don't have the test suite. The "testsuite" directory does not
> exist.
>
> How do I get the test suite? I would have expected the details to be at
> the top of this page:
> http://hackage.haskell.org/trac/ghc/wiki/Building/RunningTests
./da
t; Sent: 15 October 2008 9:22 am
> To: Mitchell, Neil
> Cc: cvs-ghc@haskell.org
> Subject: Re: Validate fails on Windows
>
> Ignore the documentation errors. You seem to simply have no
> testsuite.
>
> 2008/10/15 Mitchell, Neil <[EMAIL PROTECTED]>:
> > Hi,
&
Ignore the documentation errors. You seem to simply have no testsuite.
2008/10/15 Mitchell, Neil <[EMAIL PROTECTED]>:
> Hi,
>
> Using GHC Head from yesterday afternoon, Validate fails on Windows:
>
> Warning: ghc-6.11.20081014:VectType: could not find link destinations
> for:
>VectType.Repr
>
I hacked ghci024 to work, by having GHCi sort the output of :show packages,
and fixing ghci024.py to match. Please shout if I've done something bogus.
it would be easy enough to put 'rts' at the right place without
sorting everything but, as i said, the bogus thing is that 'rts' is
not quite l
Ian Lynagh wrote:
On Tue, May 20, 2008 at 02:50:24PM +1000, Roman Leshchinskiy wrote:
In any case, I have no idea what happened to num009.
Doh, we now have 2 num009 tests.
Hmm, is that even supported?
I suspect the new lib/Numeric/num009 is
the one that is failing? What is the output of it
On Tue, May 20, 2008 at 02:50:24PM +1000, Roman Leshchinskiy wrote:
>
> In any case, I have no idea what happened to num009.
Doh, we now have 2 num009 tests. I suspect the new lib/Numeric/num009 is
the one that is failing? What is the output of it?
Thanks
Ian
__
Claus Reinke wrote:
Unexpected failures:
ghci024(ghci)
num009(normal)
on ghci024:
the issue is that 'rts' is the only package not appearing in the output
of 'ghci -package ghc'. originally, the test tacked it on to the
packagelist
where it would be expected to appear in the output of ':
Unexpected failures:
ghci024(ghci)
num009(normal)
on ghci024:
the issue is that 'rts' is the only package not appearing in the output
of 'ghci -package ghc'. originally, the test tacked it on to the packagelist
where it would be expected to appear in the output of ':show packages'.
now
Yes, that's right thanks. Sorry about that.
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roman
Leshchinskiy
| Sent: 10 March 2008 00:13
| To: Don Stewart
| Cc: cvs-ghc@haskell.org
| Subject: Re: Validate fails
|
| Don Stewart wrote:
| >
Don Stewart wrote:
Hey, I wonder if that's a tab difference in the info code, hard coded in?
Doesn't look like it to me:
>> -data Data.Complex.Complex a = !a Data.Complex.:+ !a
>> +data (RealFloat a) => Data.Complex.Complex a
>> + = !a Data.Complex.:+ !a
After a bit of searching, I guess it
rl:
> I get:
>
> Actual stdout output differs from expected:
> --- ./ghci/scripts/ghci008.stdout.normalised 2008-03-10
> 10:49:59.0 +1100
> +++ ./ghci/scripts/ghci008.run.stdout.normalised 2008-03-10
> 10:49:59.0 +1100
> @@ -8,10 +8,12 @@
>...
> -- Defined in GHC.
On Fri, 2008-01-18 at 14:09 +, Simon Peyton-Jones wrote:
> Please validate before committing. (Yes I know I sometimes don't too.)
>
> Two current problems:
> * Warning in FastBool
> * Warning in cabal:Distribution.Simple.Program
> (see below)
>
> Both kill validation since we use -Werror
>
Isaac Dupree wrote:
]./validate #compiling ghc HEAD
...
../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-I../includes -optc-I. -optc-Iparallel -optc-Ism
-optc-D
oops, probably should have given a bit more context given parallel make,
here's the next-to-last compile command, that looks like it was the one
that failed
../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -
Sorry! I validate the patch and then failed to push it. Pushed now.
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manuel M T
Chakravarty
| Sent: 07 November 2007 00:23
| To: cvs-ghc@haskell.org
| Subject: validate fails
|
| I got the following f
Simon Marlow:
Manuel M T Chakravarty wrote:
Trying to validate the HEAD on MacOS 10.5 fails with
../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W -optc-
Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-
declarations -optc-Winline -optc-Waggregate-return -optc-I../
includes -
Manuel M T Chakravarty wrote:
Trying to validate the HEAD on MacOS 10.5 fails with
../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-I../includes -optc-I. -optc-Ipa
sorry fixing
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manuel M T
| Chakravarty
| Sent: 18 October 2007 01:25
| To: cvs-ghc@haskell.org
| Subject: validate fails
|
| I get
|
| Unexpected failures:
| TH_exn1(normal)
|
|
| This seems to be due
[EMAIL PROTECTED] wrote,
On my PPC Mac OS X, validate fails with:
Unexpected passes:
simpl019(normal)
Unexpected failures:
TH_runIO(normal)
divbyzero(normal)
outofmem(normal)
outofmem is just a matter of PPC MacOS X giving a different error
message than the default one. Have a l
See previous messages re simpl019 and TH_runio. I have no idea about divbyzero
and outofmem.
S
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: 11 October 2007 06:54
To: Manuel M T Chakravarty
Cc: cvs-ghc@haskell.org
Subject: Re: validate fails!
Hello
Sorry. I pushed the patch that fixes simpl019 but failed to mark it as passing
now. Thanks Manuel.
Meanwhile TH_runIO should pass, because I added it yesterday. I'll investigate.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manuel M T
| Ch
Hello,
On my PPC Mac OS X, validate fails with:
Unexpected passes: simpl019(normal)
Unexpected failures: TH_runIO(normal) divbyzero(normal) outofmem(normal)
(But at least I was able to complete the validation and getting to the
testsuite, not least thanks to your fixing the additional warnings in
g
Roman Leshchinskiy wrote:
This is caused by this patch:
Sun Jul 8 12:44:23 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* Fix the +RTS -V0 option introduced recently; it didn't work at
all, now it does.
Also, I documented it. +RTS -V0 disables the internal RTS timer
completely, which
Manuel, Simon,
Manuel M T Chakravarty wrote:
I just tried the new validate script on MacOS/Intel and it fails when
linking the stage2 compiler with the appended error messages. Any idea
what could be the problem?
This is caused by this patch:
Sun Jul 8 12:44:23 PDT 2007 Simon Marlow <[E
71 matches
Mail list logo
