Hello,
On Thursday 19 July 2007 12:20, Simon Marlow wrote:
> Manuel M T Chakravarty wrote:
>
> > * If I run concio001 *manually*, I need to press
> > *twice* before it prints "parent". However,
> >
> > (sleep 0.3; echo x) | ./concio001
> >
> > still works. So, the behaviour seems to
Hello,
Running validate on my PPC Mac for the GHC HEAD that was current yesterday
afternoon reports:
> => print015(ghci)
> cd ./ghci.debugger/scripts &&
HC='/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace'
HC
Hello,
Running validate on my PPC Mac now succeeds. (Or, rather, it did, the latest
fails with a framework failure in print015.) It takes about 3.5 hours on my
slow machine.
It would be convenient if CLEANUP=1 were added to the make -C testsuite ...
command -- my machine is rather limited in d
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/ghc/nightly/HEAD-cam-02-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Thu Jul 19 19:30:01 BST 2007.
checki
On Jul 19, 2007, at 4:59 PM, Ian Lynagh wrote:
On Thu, Jul 19, 2007 at 04:17:28PM -0400, Peter Tanski wrote:
With no changes to the build system affecting Happy, I am getting
errors from compiler/parser/Parser.hs when using the Windows binary
of Happy 1.16. First, there is a parse error for t
On Thu, Jul 19, 2007 at 04:17:28PM -0400, Peter Tanski wrote:
> With no changes to the build system affecting Happy, I am getting
> errors from compiler/parser/Parser.hs when using the Windows binary
> of Happy 1.16. First, there is a parse error for the CPP #include
> statement on line 6 (g
With no changes to the build system affecting Happy, I am getting
errors from compiler/parser/Parser.hs when using the Windows binary
of Happy 1.16. First, there is a parse error for the CPP #include
statement on line 6 (ghc is given the option -cpp, of course). After
moving the statement
On Tue, Jul 10, 2007 at 12:34:07PM +0100, Simon Marlow wrote:
> Alec Berryman wrote:
> >Neil Mitchell on 2007-07-10 11:44:11 +0100:
> >
> >>First, it appears that GHC.Prim no longer exists, I can't :m it. I was
> >>using it as the import location for RealWorld and State# - I've now
> >>moved to usi
Thu Jul 19 10:33:54 EDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Add RHEL RPMs from Ronald Cole
M ./download_ghc_661.html +10
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Thu Jul 19 04:26:28 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Add a test for trac #1322 (ghc --make recompiles hs-boot files
unnecessarily)
A ./tests/ghc-regress/driver/recomp002/
A ./tests/ghc-regress/driver/recomp002/Makefile
A ./tests/ghc-regress/driver/recomp002/Q.hs
A ./te
Wed Jul 18 17:08:40 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Fix the haddock tests when going via C
We need to have a header which claims the foreign imports we do are
for entities that actually exist. Otherwise the C compiler complains.
M ./tests/ghc-regress/haddock/haddock_examples/T
Thu Jul 19 04:27:36 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Create .hi-boot and .o-boot files in --make mode; fixes trac #1322
We were recompiling the .hs-boot files each time, as we were never
writing out the compilation results.
M ./compiler/main/DriverPipeline.hs -3 +3
___
Clemens Fruhwirth wrote:
Fri Jul 6 13:24:49 CEST 2007 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Fix -split-obj on Mac OS via -fasm
Applied, thanks!
Simon
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Fri Jul 6 04:24:49 PDT 2007 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Fix -split-obj on Mac OS via -fasm
The problem of the splitter was that it re-emitted section directives
for every dynamic label found. The following was torn apart
.symbol_stubs
.indirect
L_$stub:
jmp
Manuel M T Chakravarty wrote:
* If I run concio001 *manually*, I need to press
*twice* before it prints "parent". However,
(sleep 0.3; echo x) | ./concio001
still works. So, the behaviour seems to depend on whether
stdin is connected to the terminal or a pipe.
Bizarre. I have a
Simon Marlow wrote:
I discovered why we get all those extra select() calls (see patch I just
pushed). Also we round up the delay to the next tick interval (was
50ms, now 20ms), this is necessary to ensure that we sleep at least as
long as the given delay.
It seems that select() still sleeps
Build results:
x86-64 Linux head: pass
gbesh Intel x86_64 Linux head: pass
mnemosyne x86-64 Gentoo head: pass
tnaur PPC OSX head:pass
tnaur x86 Linux head: pass
x86-64 Linux head unreg: pass
Dropping unexpected test passes reports from builders not seen in 7
17 matches
Mail list logo
