Recent changes in the tracing infrastructure broke the OS X build. I fixed this
by simply commenting out the offending code. It is likely broken now.
Please also validate on OS X if you change obviously cross-cutting and
OS-dependent functionality (in this case DTrace support). My commit is
"da
Paolo
Did you validate? I'm seeing these failures
Simon
Unexpected failures:
ffi/should_compile cc005 [exit code non-0] (normal)
ffi/should_compile cc008 [exit code non-0] (normal)
ffi/should_compile cc010 [exit code non-0] (normal)
=> cc005(normal) 1703 of 3260 [0, 0, 0]
cd .
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
Ian,
On Windows (msys) with these extra settings
WERROR = -Werror
GhcStage1HcOpts += -O0 -DDEBUG
GhcLibWays = v
SplitObjs = NO
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
BUILD_DOCBOOK_PDF = NO
I get validate failing just after trying to bui
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
This keeps happening with "sh validate --fast". Very annoying! My only
non-std settings are
GhcStage1HcOpts += -DDEBUG -O0
GhcStage2HcOpts += -dcore-lint
GhcLibHcOpts+= -ticky
GhcLibWays = v
BUILD_DOCBOOK_HTML=NO
BUILD_DOCBOOK_PS=NO
BUILD_DOCBOOK_PDF=NO
Simon
...
vector-0.9.1: file
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:/
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"
--with-ghc-pkg="c:/code/HEAD/inplace/bin/ghc-pkg.ex
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
=> 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 5238 5238.hs>5238.comp.stderr 2>&1
Compile f
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
David
I'm getting these new failures on Linux
safeHaskell/safeInfered Mixed01 [exit code 0] (normal)
safeHaskell/safeInfered SafeInfered01 [exit code non-0] (normal)
safeHaskell/safeInfered SafeInfered02 [exit code non-0] (normal)
safeHaskell/safeInfered SafeInfered03 [exit code no
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
Hi Max,
With
commit 5d7173f9ab8405511f75765e0541a04796d9bd07
Author: Max Bolingbroke
Date: Sat Sep 10 10:16:38 2011 +0100
Change the way IfExtName is serialized so (most) wired-in names get
validate doesn't go through for me:
utils/haddock/src/Haddock/InterfaceFile
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
I get this failure on Windows. I have not investigated. I'm guessing there's a
#define out of place. Ian?
Simon
"inplace/bin/ghc-stage1.exe" -H32m -O -Wall -Werror -H64m -O0
-package-name base-4.4.0.0 -hide-all-packages -i -ilibraries/base/.
-ilibraries/base/dist-install/build -ilibrar
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',
>
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-prim-par/dist-install/build/.depend-v.haskell&
"inplace/bin/ghc-stage1" -H32m -O -Wall -Werror -H64m -O0-package-name
base-4.4.0.0 -hide-all-packages -i -ilibraries/base/.
-ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen
-Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen
-Ili
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,
Ian
Is this caused by your recent changes?
Simon
sh validate
make -r --no-print-directory -f ghc.mk maintainer-clean CLEANING=YES
"rm" -rf inplace
"rm" -rf
"rm" -rf docs/users_guide/users_guide docs/users_guide/users_guide.pdf
docs/users_guide/users_guide.ps
"rm" -rf docs/man/ghc.1 docs/man/fla
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
> '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 flag in substitute command: 'i'
> make[1]: *** [utils/unlit/dist/build/.depend.c_
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
Ian, Simon,
today I got the following error from validate:
/Users/rl/projects/ndp/ghc-test/bindisttest/"install dir"/bin/ghc-pkg check
There are problems in package vector-0.5:
dependency "base-4.2.0.0-inplace" doesn't exist
dependency "ghc-6.13.20091124-inplace" doesn't exist
...
The proble
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
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 or directory)
make[1]: *** [libraries/index.html] Error 1
make: *** [all] Error 2
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
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/build -iincludes/dist-derivedconstants/build/
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
...with
rm -f -r docs/users_guide/users_guide/
rm -f -r libraries/Cabal/doc/Cabal/
/usr/bin/xsltproc --stringparam base.dir docs/users_guide/users_guide/
--stringparam use.id.as.filename 1 --stringparam html.stylesheet
fptools.css --stringparam toc.section.depth 3 --stringparam
section.auto
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
/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-Ieventlog -optc-
DCOMPILING_RTS -o
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
/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-Ieventlog
-optc-DCOMPILING_RTS -o
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
/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-DDEBUG -c
PrimOps.cmm -o
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
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -package-name
base-4.0.0.0 -hide-all-packages -no-user-package-conf -i -idist/build -
i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -
optP-include -optPdist/build/autogen/cabal_macros.h -#include
"HsBase.h" -odir dist/buil
> > 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
>
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
Warning: ghc-6.11.20081014:TcClassDcl: could not find link destinations
for:
TcClassDcl.TcMethInfo
Warning: ghc-6.11.20081014
t; From: Simon Peyton-Jones
> Sent: 02 June 2008 08:17
> To: Isaac Dupree; BuildBot Collator
> Cc: John Dias
> Subject: RE: head validate fails, or am I doing something wrong?
>
> Yes, John Dias will be in today and will fix this.
>
> Simon
>
> | -Original Message-
Yes, John Dias will be in today and will fix this.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isaac Dupree
| Sent: 02 June 2008 01:47
| To: BuildBot Collator
| Subject: head validate fails, or am I doing something wrong?
|
| ghc checkout
ghc checkout as of now, doesn't even get through stage1 for me. but the
buildbots seem to not be all failing...
well, "x86 Windows head fast", "x86 Windows head"... is failing with
this error, though others are succeeding (and I'm x86 Linux). Maybe it
has to do with DEBUG or other such settings
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
I get the following two failures:
Unexpected failures:
ghci024(ghci)
num009(normal)
Recently, I tend to get unexpected failures every time I pull in
patches. What happened to the policy of running validate before pushing?
I thought we agreed that was a good idea?
In any case, I have n
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.
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.Num
infixl 6 +
-data Data
Hello,
validate fails for PC Mac OS X 10.4 as follows:
> ../compiler/stage1/ghc-inplace -no-user-package-conf -Werror -H64m -Onot
-fasm -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn
-istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar
-ista
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
>
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
Simon
/home/simonmar/fp/bin/x86_64-unknow
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 -
]./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-DCOMPILING_RTS -optc-f
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
I got the following failure with validate of the HEAD from today:
Unexpected failures:
tcfail186(normal)
The diff as in the testlog is appended. Is this just a matter of test
output that was not updated?
Manuel
-=-
=> tcfail186(normal)
cd ./typecheck/should_fail && '/Users/chak/Cod
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
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-
Iparallel -optc-Ism -optc-DCOMP
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
I get
Unexpected failures:
TH_exn1(normal)
This seems to be due to a changed error message. Can we accept the
new message?
Manuel
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
TH_exn1 is failing on the HEAD at the moment (see below).
=> TH_exn1(normal)
cd ./th && '/64playpen/simonmar/testing/compiler/stage2/ghc-inplace'
-no-recomp
-dcore-lint -dcmm-lint -Dx86_64_unknown_linux -c TH_exn1.hs -v0 -fth
-package
template-haskell >TH_exn1.comp.stderr 2>&1
Actual std
[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
1 - 100 of 107 matches
Mail list logo
