Hi,
On May 10, 2010, at 17:20 PM, Simon Marlow wrote:
> Here's the fix, I'm just validating before I push:
>
> --- old-ghc-testing/rts/Updates.cmm 2010-05-10 16:20:22.0 +0100
> +++ new-ghc-testing/rts/Updates.cmm 2010-05-10 16:20:25.0 +0100
> @@ -95,5 +95,5 @@
> // high w
ook into it.
Cheers,
Simon
-Original Message-
From: David Terei [mailto:davidte...@gmail.com]
Sent: 10 May 2010 14:58
To: Andy Georges; cvs-ghc@haskell.org; Simon Marlow
Subject: Re: GHC Head broken when TNTC not used
Hi all and Simon,
OK this is the patch that breaks GHC when Ta
10 14:58
> To: Andy Georges; cvs-ghc@haskell.org; Simon Marlow
> Subject: Re: GHC Head broken when TNTC not used
>
> Hi all and Simon,
>
> OK this is the patch that breaks GHC when TablesNextToCode isn't used:
>
> Tue Mar 30 01:44:56 EST 2010 Simon Marlow
> * New
Hi all and Simon,
OK this is the patch that breaks GHC when TablesNextToCode isn't used:
Tue Mar 30 01:44:56 EST 2010 Simon Marlow
* New implementation of BLACKHOLEs
Specifically this patch causes anything compiled by the ghc-stage1
compiler to segfault in 'stg_bh_upd_frame_info ()'.
Cheers
Hi all,
Sometime in the last month or so a change in GHC head broke the
compiler when 'TablesNextToCode' isn't used. E.g, build GHC with this
line in your build.mk:
GhcEnableTablesNextToCode = NO
When compiling ghc, the first stage will build but then anything
compiled with ghc-stage1 simply seg
On Mon, Feb 15, 2010 at 01:54:31PM +1100, Ben Lippmeier wrote:
>
> cat libraries/integer-gmp/gmp/tarball/gmp-4.2.4-nodoc-patched.tar.bz2 | bzip2
> -d { cd libraries/integer-gmp/gmp && /usr/bin/gnutar -xf - ; }
> /bin/sh: -c: line 0: syntax error near unexpected token `}'
Should be fixed now. Ple
Unpulling the following patch from libraries/integer-gmp fixes it:
Sun Feb 14 14:05:56 PST 2010 Ian Lynagh
* Don't rely on tar supporting -j; trac #3841
M ./gmp/ghc.mk -1 +1
On 15/02/2010, at 13:54 , Ben Lippmeier wrote:
>
> echo "libraries/base_dist-install_depfile_c_asm_EXISTS = YES"
echo "libraries/base_dist-install_depfile_c_asm_EXISTS = YES" >>
libraries/base/dist-install/build/.depend-v.c_asm.tmp
mv libraries/base/dist-install/build/.depend-v.c_asm.tmp
libraries/base/dist-install/build/.depend-v.c_asm
"inplace/bin/mkdirhier" libraries/base/dist-install/build/System//.
rm
On 04/11/2009, at 21:13, Simon Marlow wrote:
I'm getting this from validate even without the DPH patch:
/Users/rl/projects/ndp/ghc-test/bindisttest/installed/bin/runghc
HelloWorld > output
GHCi runtime linker: fatal error: I found a duplicate definition for
symbol
_base_GHCziConc_ioManager
> I'm getting this from validate even without the DPH patch:
>
> /Users/rl/projects/ndp/ghc-test/bindisttest/installed/bin/runghc
> HelloWorld > output
>
>
> GHCi runtime linker: fatal error: I found a duplicate definition for
> symbol
> _base_GHCziConc_ioManagerThread_closure
> whilst proce
Simon,
I'm getting this from validate even without the DPH patch:
/Users/rl/projects/ndp/ghc-test/bindisttest/installed/bin/runghc
HelloWorld > output
GHCi runtime linker: fatal error: I found a duplicate definition for
symbol
_base_GHCziConc_ioManagerThread_closure
whilst processing
Hi Roman,
On Wed, Apr 23, 2008 at 02:30:51PM +1000, Roman Leshchinskiy wrote:
>
> along with your FSLIT-related changes, you've removed includes of
> HsVersions.h from various source files. This broke the build at least on
Sorry, you are right. I've just been through them all, and I think the
Ian,
along with your FSLIT-related changes, you've removed includes of
HsVersions.h from various source files. This broke the build at least on
OS X (but I'm fairly sure this applies to other OS as well) because the
*_TARGET_OS and *_TARGET_ARCH macros (and, possibly, others) are no
longer de
On 3/25/08, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 25, 2008 at 08:56:31PM +, Ian Lynagh wrote:
> > On Tue, Mar 25, 2008 at 11:02:27AM -0700, Tim Chevalier wrote:
> > >
> > > GHC/Word.hs:668:17: Not in scope: data constructor `S#'
> >
> > Sorry, my fault. I'll push shortly.
>
>
On Tue, Mar 25, 2008 at 08:56:31PM +, Ian Lynagh wrote:
> On Tue, Mar 25, 2008 at 11:02:27AM -0700, Tim Chevalier wrote:
> >
> > GHC/Word.hs:668:17: Not in scope: data constructor `S#'
>
> Sorry, my fault. I'll push shortly.
Pushed; please yell if something still doesn't work for you.
Than
On 3/25/08, Don Stewart <[EMAIL PROTECTED]> wrote:
> Yeah, see Ian's emails from yesterday,
>
> http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/26792
> and
> http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/26793
>
The first message says to use "remake" instead of "rebuil
catamorphism:
> On 3/25/08, Don Stewart <[EMAIL PROTECTED]> wrote:
> > The integer package is needed to build base now.
>
> Are you saying that I need to do something other than running
> darcs-all get and darcs-all pull (as well as sh boot, configure,
> make)? If so, what?
>
Yeah, see Ian's ema
On Tue, Mar 25, 2008 at 11:02:27AM -0700, Tim Chevalier wrote:
>
> GHC/Word.hs:668:17: Not in scope: data constructor `S#'
Sorry, my fault. I'll push shortly.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/list
On 3/25/08, Don Stewart <[EMAIL PROTECTED]> wrote:
> The integer package is needed to build base now.
Are you saying that I need to do something other than running
darcs-all get and darcs-all pull (as well as sh boot, configure,
make)? If so, what?
Thanks,
Tim
--
Tim Chevalier * http://cs.pdx.e
catamorphism:
> Hi all,
>
> After pulling patches in the HEAD, I get the following while building
> the libraries (after doing ./darcs-all get, ./darcs-all pull, sh
> validate):
>
> GHC/Word.hs:577:38: Not in scope: `word2Integer'
>
> GHC/Word.hs:668:17: Not in scope: data constructor `S#'
>
>
Hi all,
After pulling patches in the HEAD, I get the following while building
the libraries (after doing ./darcs-all get, ./darcs-all pull, sh
validate):
GHC/Word.hs:577:38: Not in scope: `word2Integer'
GHC/Word.hs:668:17: Not in scope: data constructor `S#'
GHC/Word.hs:669:17: Not in scope: da
Clemens Fruhwirth wrote:
Wed Jan 16 14:04:20 PST 2008 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Use runPhase_MoveBinary also for generating a dynamic library wrapper
main/DriverPipeline.hs:1100:24: Not in scope: `splitFilename'
main/DriverPipeline.hs:1101:64: Not in scope: `joinFileExt'
Has t
dons:
>
> The change to use remap in Linker.c has broken the mmap Linker.c
> implementation on OpenBSD, and other BSDs.
>
> #ifndef linux_HOST_OS /* mremap is a linux extension */
> #error ocAllocateSymbolExtras doesnt want USE_MMAP to be defined
> #endif
>
> Do we know why this
The change to use remap in Linker.c has broken the mmap Linker.c
implementation on OpenBSD, and other BSDs.
#ifndef linux_HOST_OS /* mremap is a linux extension */
#error ocAllocateSymbolExtras doesnt want USE_MMAP to be defined
#endif
Do we know why this was done? USE_MMAP worke
Judah Jacobson wrote:
IIUC, the NS* stuff is deprecated in OS X 10.4 and dlsym should be used
instead. This is a change from 10.3 and below, where NS* is better.
I'm not that familiar with those functions, but from the following
page it looks like dlsym will work on 10.3 and later:
http://deve
On 9/2/07, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> when building the current HEAD on OS X 10.4, I get the following error:
>
> Linker.c:1065:0:
> warning: 'NSIsSymbolNameDefined' is deprecated (declared at
> /usr/include/mach-o/dyld.h:150)
>
> Linker.c:1066:0:
> warn
Hi all,
when building the current HEAD on OS X 10.4, I get the following error:
../compiler/ghc-inplace -optc-O -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. -opt
Ian Lynagh wrote:
Hi Roman,
On Mon, Aug 13, 2007 at 02:15:48PM +1000, Roman Leshchinskiy wrote:
when forking. With the current HEAD on OS X, I get a lot of testsuite
failures of the following form:
Compile failed (status 256) errors were:
i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual
Hi Roman,
On Mon, Aug 13, 2007 at 02:15:48PM +1000, Roman Leshchinskiy wrote:
> when forking. With the current HEAD on OS X, I get a lot of testsuite
> failures of the following form:
>
> Compile failed (status 256) errors were:
> i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expi
Hi all,
there seems to be something wrong with the way the RTS handles signals
when forking. With the current HEAD on OS X, I get a lot of testsuite
failures of the following form:
Compile failed (status 256) errors were:
i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expired
(p
The HEAD now has a 'validate' script at the top level, which you can use for
testing that patches in your tree pass minimal testing. It won't work on
Windows yet (no args are passed to configure), and parallelism is fixed at -j2.
'make fast' in the testsuite now runs with zero failures on x86-
i'm not a fan of cpp, but two things it was good for in other
projects was
..
I'm immediately suspicious of any plan involving more CPP use - the
existing CPP we have (for platform-specific code, mostly) is one of the
causes of build problems, as the compiler can't spot that modifying
import list
On Wed, Jul 04, 2007 at 01:10:05PM +0100, Claus Reinke wrote:
>
> i'm not a fan of cpp, but two things it was good for in other
> projects was
>
>- to have many branches evolving in one code base,
>with an easy way to switch between and test all
>
>- to let new code grow inside
obvious issues:
- cpp or similar is needed everywhere :-(
- should the TEST macro include a test identifier?
- how to generate the list of TEST(X)s? can this be automated?
the third issue (not hardcoding all available or anticipated variants/
platforms/buildbots) and the second issue can be addr
this would work better for new features than for modifications.
developers on OSX would -after testing- check in something like:
#if (OSX || TEST(WIN) || TEST(LINUX) ..)
.. new feature ..
#endif
..
depending on build/test outcome. TEST(X) would be false for
any non-X variant, true fo
i don't have the feeling that most of the recent breakage is due to
negligence, nor do i think that asking contributors to be more
responsible will solve the main issues. yes, there have been a few
cases where typos or incomplete commits caused breakage and,
yes, re-building, *after* pull, *bef
Manuel M T Chakravarty wrote:
Right now the fast testsuite doesn't have zero failures (it has about
20), we'll need to get that down to zero first. The fast testsuite
currently runs in about 8 minutes on a fast Linux machine; it was
about 5 minutes when I first did it, so we probably need som
Simon x 2,
I've just been chatting with Simon about this, and basically we're
willing to try a more rigorous testing regime for changes to the HEAD.
Yesterday Ian and I uncovered a problem with the "known buildable"
repositories idea: the build slave has a partial repository, so it can't
nec
Simon,
| I think its a matter of scalability. The "testing by pushing to head"
approach | that you seem to advocate worked well enough when few people were
hacking GHC. | However, it seems that the number of GHC developers has been
growing quite a bit | in recent times
I agree completely. It's
I've just been chatting with Simon about this, and basically we're willing to
try a more rigorous testing regime for changes to the HEAD.
Yesterday Ian and I uncovered a problem with the "known buildable" repositories
idea: the build slave has a partial repository, so it can't necessarily push
Manuel
| I think its a matter of scalability. The "testing by pushing to head"
approach
| that you seem to advocate worked well enough when few people were hacking GHC.
| However, it seems that the number of GHC developers has been growing quite a
bit
| in recent times
I agree completely. It's
chak:
> Simon Marlow wrote,
> >Personally, I think requiring a complete bootstrap/testsuite on two
> >platforms for every patch is still prohibitively expensive: up to 2
> >hours for each build plus the time and effort to set them up - that's if
> >you even have access to 2 different platforms.
Simon Marlow wrote,
Personally, I think requiring a complete bootstrap/testsuite on two
platforms for every patch is still prohibitively expensive: up to 2
hours for each build plus the time and effort to set them up - that's if
you even have access to 2 different platforms. If the developer d
Simon Marlow wrote:
As you know, so far we've been resistant to adding significant amounts
of "process" to modifying the HEAD, because it'll necessarily slow down
development. Instead, we've added lots of other measures:
Yes, but IMO this is only true if the number of developers is very
sm
Roman Leshchinskiy wrote:
To be entirely honest, I don't see why I can't have both most of the
time (I wouldn't mind too much if head was broken *occasionally*). I
think simply testing potentially destabilising patches on multiple
architectures before submitting/pushing them and clearly statin
Simon Peyton-Jones wrote:
Our current plan (were you in the loop when we discussed this?) is to have a
snapshot darcs repo, that is the last known clean build. (Question: do we need
one per architecture?)
Definitely one per architecture (and there doesn't seem to be a nightly
build for OS
Simon Peyton-Jones wrote:
| 4. Trying to maintain a branch is still frustrating. I've just spend 4
| hours (and had to rebuild ghc 6 or 7 times) trying to sync ghc-ndp with
| head. Even worse, in the last couple of months, we would have problems
| with building head itself more often than not. I
| 4. Trying to maintain a branch is still frustrating. I've just spend 4
| hours (and had to rebuild ghc 6 or 7 times) trying to sync ghc-ndp with
| head. Even worse, in the last couple of months, we would have problems
| with building head itself more often than not. I think we lost *weeks*
| tryi
Hi all,
today, I tried to sync the ghc-ndp branch with head. Again, I'll
describe the problems I've encountered in the hope that it will be helpful.
First, I tried
darcs pull http://darcs.haskell.org/ghc
./darcs-all pull
make distclean
This failed with
Registering filepath-1.0...
49 matches
Mail list logo
