Mitchell, Neil wrote:
FWIW, I had some validate failures under windows dependening
on which shell I used. I have to check again which one it
was, though.
For information, my shell is:
[EMAIL PROTECTED] /cygdrive/c/ghc-build/ghc
$ help
GNU bash, version 3.2.39(20)-release (i686-pc-cygwin)
> FWIW, I had some validate failures under windows dependening
> on which shell I used. I have to check again which one it
> was, though.
For information, my shell is:
[EMAIL PROTECTED] /cygdrive/c/ghc-build/ghc
$ help
GNU bash, version 3.2.39(20)-release (i686-pc-cygwin)
And I now am down
FWIW, I had some validate failures under windows dependening on which
shell I used. I have to check again which one it was, though.
2008/10/22 Mitchell, Neil <[EMAIL PROTECTED]>:
> Hi
>
>
>> > Could it be that buffering has a different default on Windows?
>>
>> 2228 is now an expected failure on
Hi
> > Could it be that buffering has a different default on Windows?
>
> 2228 is now an expected failure on Windows. See #2628.
Fair enough.
> > As a secondary issue, it appears that the failure reports
> are occuring
> > after the script has started to print out information about
> the n
Mitchell, Neil wrote:
Thanks Thorkil, more information:
=> 2228(normal)
cd ./ghc-e/should_run && $MAKE --no-print-directory -s 2228
2228.run.stdout 2>2228.run.stderr
=> 2636(normal)
cd ./ghc-e/should_run && $MAKE --no-print-directory -s 2636
2636.run.stdout 2>2636.run.stderr
Actual stdo
Hi Neil,
On Friday 17 October 2008 17:56, Mitchell, Neil wrote:
> Hi,
>
> Thanks Thorkil, more information:
>
> => 2228(normal)
> cd ./ghc-e/should_run && $MAKE --no-print-directory -s 2228
> 2228.run.stdout 2>2228.run.stderr
> => 2636(normal)
> cd ./ghc-e/should_run && $MAKE --no-print-
breakpoint.
+Perhaps no modules are loaded for debugging?
+[]
*** unexpected failure for break008(ghci)
And a GHCi debugger issue.
As a secondary issue, it appears that the failure reports are occuring
after the script has started to print out information about the next
test.
Thanks
Neil
>
Hello,
On Friday 17 October 2008 17:41, Mitchell, Neil wrote:
> Hi,
>
> Doing validation under Windows XP, using HEAD from a few hours ago, I
> get the results:
>
> OVERALL SUMMARY for test run started at The current date is: 17/10/2008
> Enter the new date: (dd-mm-yy)
> 2221 total tests, wh
On Fri, Oct 03, 2008 at 06:13:02PM +0100, Simon Peyton-Jones wrote:
> sorry. I had -Werror switched off because I was compiling extralibs too,
> which aren't warning free. I don't know if I can say "-Werror for all except
> extralibs" can I?
No, currently we build the extralibs and bootlibs in
sorry. I had -Werror switched off because I was compiling extralibs too, which
aren't warning free. I don't know if I can say "-Werror for all except
extralibs" can I?
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mitchell,
| Neil
| Sent: 03 O
Simon Marlow wrote:
But not these:
Unexpected failures:
GADT11(normal)
Simple13(normal)
derefnull(normal)
divbyzero(normal)
equal(normal)
set(normal)
syn-perf(normal)
tc(normal)
tc095(normal)
termination(normal)
while(normal)
Linux i686 dual-core, happening wi
Isaac Dupree wrote:
these are the current set of validation failures for HEAD on my machine,
(the same just before and after committing my portability cleanup.)
They've all been around for quite a while, except list001(ghci) is a
little more recent, as listed in some previous e-mail I sent. Do
Simon Marlow:
Simon Marlow wrote:
Duncan Coutts wrote:
On Wed, 2007-11-21 at 11:36 +1100, Manuel M T Chakravarty wrote:
On Mac OS X, 10.5, I get with todays head
Unexpected failures:
openFile008(normal)
Details appended.
Tue Nov 20 03:47:57 PST 2007 Simon Marlow <[EMAIL PROTECTED]>
*
Simon Marlow wrote:
Duncan Coutts wrote:
On Wed, 2007-11-21 at 11:36 +1100, Manuel M T Chakravarty wrote:
On Mac OS X, 10.5, I get with todays head
Unexpected failures:
openFile008(normal)
Details appended.
Tue Nov 20 03:47:57 PST 2007 Simon Marlow <[EMAIL PROTECTED]>
* test repeated
Duncan Coutts wrote:
On Wed, 2007-11-21 at 11:36 +1100, Manuel M T Chakravarty wrote:
On Mac OS X, 10.5, I get with todays head
Unexpected failures:
openFile008(normal)
Details appended.
Tue Nov 20 03:47:57 PST 2007 Simon Marlow <[EMAIL PROTECTED]>
* test repeated open/close of 1000 f
Mac OS X has a default limit of 256 files, though it can be increased
via ulimit.
Richard
--- Begin Message ---
On Wed, 2007-11-21 at 11:36 +1100, Manuel M T Chakravarty wrote:
> On Mac OS X, 10.5, I get with todays head
>
> Unexpected failures:
> openFile008(normal)
>
> Details appended.
On Wed, 2007-11-21 at 11:36 +1100, Manuel M T Chakravarty wrote:
> On Mac OS X, 10.5, I get with todays head
>
> Unexpected failures:
> openFile008(normal)
>
> Details appended.
Tue Nov 20 03:47:57 PST 2007 Simon Marlow <[EMAIL PROTECTED]>
* test repeated open/close of 1000 files
M .
On Thu, Sep 06, 2007 at 01:52:06PM +0100, Simon Peyton-Jones wrote:
> | > Incidentally, just to confirm, I never have to even look in validate.mk
> do I? It's 100% validate's
> | responsibility.
> |
> | validate.mk is to validate what build.mk is to make, i.e. if you want
> | the default settings
| > Incidentally, just to confirm, I never have to even look in validate.mk do
I? It's 100% validate's
| responsibility.
|
| validate.mk is to validate what build.mk is to make, i.e. if you want
| the default settings then you can ignore validate.mk, but if you want to
| change something then tha
On Thu, Sep 06, 2007 at 07:44:39AM +0100, Simon Peyton-Jones wrote:
>
> That may be fine for you, but we are asking *everyone* to run validate
Good point, I'll make it set GhcBootLibs=YES by default.
> Incidentally, just to confirm, I never have to even look in validate.mk do I?
> It's 100% va
| > 1. If you have lots of libraries in your tree, 'sh validate' will
| try to compile them. But they are not -Wall clean, so the -Werror
| kills the validation.
| >
| > Solution: we should say what libraries validate will validate; and
| validate should make build.mk compile only them.
| >
| > T
Hi Simon,
On Wed, Sep 05, 2007 at 04:08:23PM +0100, Simon Peyton-Jones wrote:
>
> 1. If you have lots of libraries in your tree, 'sh validate' will try to
> compile them. But they are not -Wall clean, so the -Werror kills the
> validation.
>
> Solution: we should say what libraries validate
22 matches
Mail list logo