Mon Sep 8 15:46:18 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Use test -f rather than test -e
Hopefully this will fix the SunOS builbot slave.
M ./Makefile -1 +1
M ./compiler/Makefile -1 +1
M ./driver/Makefile -1 +1
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/2
Mon Sep 8 11:48:29 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Make a pdf, rather than ps.gz, of teh ext-core docs
M ./docs/ext-core/Makefile -6 +12
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080908184829-3fd76-48a6dad6c9640b60a2dbbc0e2cde28a836f8b7df.gz
_
|I think you will have better luck with darcs get --hashed, which has
|better handling of case insensitive file systems.
You mean because it encrypts file names in pristine? I never
liked that idea, I must say - if the hashes are useful, why not
store them out of the way? Having a real pristin
Eric Kow <[EMAIL PROTECTED]> added the comment:
Hi,
On Mon, Sep 08, 2008 at 23:35:17 -, Claus Reinke wrote:
> $ darcs get c:/fptools/ghc
> Unapplicable patch:
> Thu Jan 11 14:26:13 GMT Standard Time 1996 partain
> * [project @ 1996-01-11 14:06:51 by partain]
I think you will have better
I just tried to use 'darcs get' to make a local copy of the
ghc repo and was surprised to see it fail, as I was sure that
this used to work (on windows locally only, of course). And
indeed:
$ export PATH=`echo $PATH | sed 's/d\/darcs/d\/darcs1/'`
$ darcs --version
1.0.9 (release)
$ darcs get
| Starting from a fresh tree everytime or searching for files manually
| don't sound realistic
>Perhaps the easiest thing is to start with a fresh link-tree.
>That's easy and fast -- but does not work on Windows.
So your recommendation for me is to 'darcs get;darcs-all
get --extra' every tim
Hello,
On Monday 08 September 2008 14:22, Simon Peyton-Jones wrote:
> Dear BDS hackers
>
> We'd like GHC to be buildable on BSD, but at the moment it isn't. We
support GHC on Linux, Windows, Mac, but we really need help with BSD.
I would like to do something about this. I have (a number of) x8
| I'm sorry to ask this, but are you sure to have an un-modified repository?
I am absolutely 100% certain that *I* made no changes. But darcs must have! Here is what 'darcs
what' says:
cd libraries/Cabal/
bash-3.2$ darcs what -ls
./Distribution/PackageDescription.hs ->
./Distribution/Packag
Mon Sep 8 08:20:43 PDT 2008 [EMAIL PROTECTED]
* tc176 works now
M ./tests/ghc-regress/typecheck/should_compile/all.T -1 +1
M ./tests/ghc-regress/typecheck/should_compile/tc176.hs +4
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080908152043-1287e-202f14431b9c7
Mon Sep 8 08:19:56 PDT 2008 [EMAIL PROTECTED]
* Test T1470 is still broken
I briefly thought I'd fixed this, but I haven't. So it stays broken.
M ./tests/ghc-regress/typecheck/should_compile/T1470.hs +2
M ./tests/ghc-regress/typecheck/should_compile/all.T -1 +1
View patch onl
[Sorry keyboard trouble made me send prematurely]
| I'm sorry to ask this, but are you sure to have an un-modified repository?
I am absolutely 100% certain that *I* made no changes. But darcs must have!
Here is what 'darcs what' says:
cd libraries/Cabal/
bash-3.2$ darcs what -ls
./Distributi
"Claus Reinke" <[EMAIL PROTECTED]> wrote:
> | Starting from a fresh tree everytime or searching for files manually
> | don't sound realistic
>
> >Perhaps the easiest thing is to start with a fresh link-tree.
> >That's easy and fast -- but does not work on Windows.
>
> So your recommendation fo
Ah interesting. I do assure you that *I* have made no changes. But I see
| -Original Message-
| From: Nicolas Pouillard [mailto:[EMAIL PROTECTED]
| Sent: 08 September 2008 15:46
| To: cvs-ghc@haskell.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL
PROTECTED];
| Simon Peyton-Jones
| S
Nicolas Pouillard <[EMAIL PROTECTED]> added the comment:
I'm sorry to ask this, but are you sure to have an un-modified repository?
Here is the checks:
$ darcs whatsnew -ls
(the purpose of -l is to be sure that no local file can conflict with some newly
added ones)
$ darcs send --dry-run
(thi
Mon Sep 8 07:24:14 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* FIX BUILD on non-Windows
M ./rts/Linker.c -4 +5
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080908142414-12142-c4296ee5b56f837d569f7bdd05947fef77001eca.gz
___
C
Mon Sep 8 03:28:55 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* make this build with GHC 6.7+
M ./utils/nofib-analyse/Makefile +3
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080908102855-12142-1e776541db3304118c739f67abeec2c9cf229d7d.gz
___
Mon Sep 8 03:28:43 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* add (c) Lennart Augustsson (part of #740)
M ./rts/StgPrimFloat.c +1
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080908102843-12142-6f502fdf8e3375141b6c4edf0f8310c7233bcb8c.gz
_
[Sending again this time with the trace as a zipped attachment, and *not*
inline; sorry. It's got through to [EMAIL PROTECTED]; this cc to cvs-ghc is
for info.]
More darcs2 woe, this time on Linux. I'm simply merging patches from the cabal
repository into my working tree. My working tree is a
Tim Chevalier wrote:
On Sat, Sep 6, 2008 at 12:24 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
Sat Sep 6 07:02:43 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Update the users guide to point at the in-tree core.ps.gz
It used to point to a file on haskell.org, which didn't necessarily
describe the
Simon Peyton-Jones wrote:
In any case, I'm hoping that John Dias's current work on the back end will mean
that GHC becomes a cross-compiler, which will make portability a lot easier.
GHC will only cross-compile to architectures for which it already has a
native code generator. So cross-comp
Ian Lynagh wrote:
Thu Sep 4 11:50:42 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Define _BSD_SOURCE in Stg.h
This means S_ISSOCK gets defined on Linux
This is highly dubious. The reason we needed these things in the past was
because when compiling via C, Stg.h is always included first, an
Excerpts from Simon Peyton-Jones's message of Mon Sep 08 07:22:15 -0500 2008:
> Dear BDS hackers
>
> We'd like GHC to be buildable on BSD, but at the moment it isn't. We support
> GHC on Linux, Windows, Mac, but we really need help with BSD.
>
> Alas, we didn't get much response to Simon's messa
Ian Lynagh wrote:
On Thu, Sep 04, 2008 at 09:45:24AM +0100, Simon Peyton-Jones wrote:
So shall we do that?
OK, let's leave extralibs in the nightly builds for now, then.
Ah, the IRC discussion that Ian is referring to happened *after* the thread
that Simon is referring to (confusion ensues)
An interesting and delicate point, as I mentioned. I believe I have now fixed
it.
Simon
| -Original Message-
| From: Claus Reinke [mailto:[EMAIL PROTECTED]
| Sent: 03 September 2008 23:22
| To: Simon Peyton-Jones; cvs-ghc@haskell.org
| Subject: Re: patch applied (ghc): Major change in c
Dear BDS hackers
We'd like GHC to be buildable on BSD, but at the moment it isn't. We support
GHC on Linux, Windows, Mac, but we really need help with BSD.
Alas, we didn't get much response to Simon's message below. (One, I think --
thank you to that person! I think it was Kili, but I'm not
I always do 'make distclean' before pulling, simply because I've
been bitten too often. But recently, I still get bitten, so this isn't
extreme enough!
There's nothing recent about libraries/base/GHC/Prim.hs; we stopped
generating it back in March:
..
You've just been lucky that it hasn't caus
On Mon, 2008-09-08 at 12:23 +0100, Claus Reinke wrote:
> > 2008/9/8 Simon Peyton-Jones <[EMAIL PROTECTED]>:
> >> The obvious solution to both is to somehow offer 'make superclean', which
> >> removes every single
> >> file and directory that is not in the source repo. That is
> >> right-by-con
On Mon, Sep 08, 2008 at 12:14:21PM +0100, Claus Reinke wrote:
>
> I always do 'make distclean' before pulling, simply because I've
> been bitten too often. But recently, I still get bitten, so this isn't
> extreme enough!
There's nothing recent about libraries/base/GHC/Prim.hs; we stopped
generat
After removing some more generated sources by trial and
error, the main build got through last night, but now 'make
binary-dist' fails with:
== make install-docs - --unix - --no-print-directory -r;
in /cygdrive/c/fptools/ghc/docs/users_guide
-
2008/9/8 Simon Peyton-Jones <[EMAIL PROTECTED]>:
The obvious solution to both is to somehow offer 'make superclean', which removes every single
file and directory that is not in the source repo. That is right-by-construction, and stays
right regardless of changes. I don't know how to impleme
| What is the correct make target to get rid of all such generated files?
|
| Starting from a fresh tree everytime or searching for files manually
| don't sound realistic - there must be some support in there for
| getting rid of all generated left-overs (distclean presumably leaves
| them there f
Wed Sep 3 03:50:18 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* sysErrorBelch: don't put an extra \n on Windows
M ./rts/RtsMessages.c +5
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080903105018-12142-19ef4b1963fef476fb36a8d49c0f4893ba1d0c2d.gz
Wed Sep 3 03:49:51 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* Windows: print an error message in addDLL
Also, look for libXXX.dll in addition to XXX.dll (see #1883, this
isn't really a proper fix, but it'll help in some cases).
And I tidied up the error message for a DLL load failure, th
2008/9/8 Simon Peyton-Jones <[EMAIL PROTECTED]>:
> The obvious solution to both is to somehow offer 'make superclean', which
> removes every single file and directory that is not in the source repo.
> That is right-by-construction, and stays right regardless of changes. I
> don't know how to
| Okay, let me rephrase this more succinctly. I think that the following
| would be a useful principle (even though it's not how things work
| right now): An External Core file that was generated by GHC cannot
| refer to any names defined in standard library files that I would not
| be allowed to r
| What is the correct make target to get rid of all such generated files?
|
| Starting from a fresh tree everytime or searching for files manually
| don't sound realistic - there must be some support in there for
| getting rid of all generated left-overs (distclean presumably leaves
| them there fo
On 9/8/08, Tim Chevalier <[EMAIL PROTECTED]> wrote:
>
> Maybe I didn't state my point clearly, or maybe it was so obvious as
> to be easily missed. An External Core file should be like a Haskell
> source file at least in the sense that it doesn't depend on any
> strange names that appear in .hi
On Mon, Sep 8, 2008 at 12:29 AM, Simon Peyton-Jones
<[EMAIL PROTECTED]> wrote:
> I think that's a separate question.
>
> I'm saying that if you want to read in a ExtCore file, you'd better not have
> recompiled any of the modules it depends on. But that's true for linking
> too! If A imports B,
Build results:
fast486 stable: fail (failed darcs)
gabor stable: fail (failed darcs)
kgardas stable: fail (failed stage1)
malcolm stable: fail (failed darcs)
mnemosyne x86-64 Gentoo stable: fail (failed darcs)
tnaur x86 Linux stable:
Build results:
x86-64 Linux head: fail (failed stage2 bindist bindisttest boottestsuite
runtestsuite nofib.boot.0 failed slave lost)
x86 Windows head:fail (failed stage2 bindist bindisttest boottestsuite
runtestsuite nofib.boot.0 nofib.boot.0_2 nofib.boot.0_3 nofib.boot.0_4
nofib.b
| I didn't try it, because I didn't know about that flag. I'll
| experiment with it at some point. But from your other comments, it
| sounds like you're confirming my suspicion that making GHC generate
| External Core files that it can read back in again entails either
| paying an optimization cost
41 matches
Mail list logo
