On 05/06/11 05:15, Simon Peyton-Jones wrote:
So I think merging the master onto the branch must be done regularly not as a
big bang at the end.
If someone would like to write a duffers guide describing how to do that, I'm
happy to follow it. But the only way I understand is to merge master on
On 01/26/11 06:22, Simon Marlow wrote:
No - as soon as the thread enters foreign code via a safe foreign call,
GC can happen at any time.
(Which is a very good thing: if you *want* to call a long-running, or
running forever, piece of foreign code, there is a way to do it without
breaking the
On 01/13/11 08:42, Eric Kow wrote:
On Wed, Jan 12, 2011 at 15:49:31 -0500, Isaac Dupree wrote:
What if "pull" could (maybe given a flag that you'd use with your
upstream) re-order all patches from upstream, new or old, as far
back in your history as possible?
I'm
On 01/12/11 02:52, Alexander McPhail wrote:
Hi,
I have a couple of branches of ghc off of HEAD.
I found that I had some difficulty _finding_ my patch submissions after
weeks of 'darcs_all pull -a'. And I understand that one complaint is the
need to create 'megapatches'.
How is this flow:
1)
On 12/14/10 01:55, José Pedro Magalhães wrote:
...given that Ubuntu (for instance) only has ghc-6.10.4 I
guess that is no longer true...
You should upgrade your Ubuntu. Both the latest Long-Term-Support
release (Lucid, 10.04) and latest release (Maverick, 10.10) have
versions of GHC 6.12 as
On 09/22/10 03:26, Simon Peyton-Jones wrote:
I think we are making a bit of a mountain out of a mole hill here. It's not
even as if 'vector' was in a terrible state; we intend to kick off the HP
process for it shortly, so it soon will be a HP package.
I suggest that it might be simpler just t
On 06/01/10 04:47, Simon Marlow wrote:
On 01/06/2010 09:35, Ben Lippmeier wrote:
Is there any reason not to just enable -std=c99?
Yes - we stray outside C99 and use GNU extensions in a few places, so I
don't think it would work.
Isn't that what -std=gnu99 is for? (sorry if i'm too out-of-con
On 03/15/10 05:42, Simon Marlow wrote:
On 13/03/2010 20:14, Ian Lynagh wrote:
Sat Mar 13 07:45:55 PST 2010 Ian Lynagh
* Add a link-time flag to en/disable the RTS options
If RTS options are disabled then:
* The ghc_rts_opts C code variable is processed as normal
* The GHCRTS environment variable
On 02/23/10 10:21, Simon Marlow wrote:
+Flag unreg
+ Description: Build an unregistered version.
it's called
"unregisterized", is it not? (vs.
"unregistered"
). Yes,
"unregisterised"
is not a word outside the world of GHC (and I'm not sure if we use "s"
or "z")
-Isaac
__
Malcolm Wallace wrote:
Out of interest, without trying it, what do you think this program
should print (the only difference between the 3 functions is the
indentation of the "where" line)?:
main = do print $ f1 1
print $ f2 1
print $ f3 1
I reckon it would be "layout error" at
Ian Lynagh wrote:
On Mon, Nov 30, 2009 at 11:12:36AM +, Duncan Coutts wrote:
On Mon, 2009-11-30 at 09:16 +, Simon Marlow wrote:
On 29/11/2009 19:40, Duncan Coutts wrote:
Here's the main one it cannot cope with that bothers me:
foo x = case bar x of
Pattern1 -> ...
Pattern1 ->
Ian Lynagh wrote:
On Tue, Aug 11, 2009 at 11:16:49PM -0400, Isaac Dupree wrote:
Although it turned out that in my Synify code there wasn't much actually
valid srcloc information, it might still be generally useful to put
these convenience functions I invented, into GHC:
What's
Simon Peyton-Jones wrote:
| > Declaration-level splices with no "$"
| > ~~
| > This change simply allows you to omit the "$(...)" wrapper for
| > declaration-level TH splices. An expression all by itself is
| > not legal, so we now treat it as a TH s
Simon Marlow wrote:
The GHC patches look fine, with one wibble: HsDocString should be a
newtype.
I'm happy for this to go into 6.12.1, if we can get everything aligned.
I can't actually apply your patch, because you have various patches
called things like IDRAFT1 in the context - what are th
- which is the latest GHC patch that we need?
The ghc-patch that I sent you a couple days ago. It's a relatively
simple patch; you should review it and tell me if I should amend it
somehow.
Alternatively, if we wanted to integrate the Haddock work but not change
GHC for this release, we c
Simon Marlow wrote:
Hi guys,
So we want to get these patches into Haddock/GHC before the 6.12.1
release. I'm unfamiliar with the current state, could someone summarise
for us?
- which patches are in Haddock upstream?
right now, the latest release doesn't have much of my work at all, and
Isaac Dupree wrote:
* Patch to GHC
* Patch to Haddock
* Everything works now
I'll send the patches themselves in separate emails (they're 100-200 KB
apiece, I want to try and make the mailing-list not swallow them).
well, "awaiting moderator approval" swallowed them f
* Patch to GHC
* Patch to Haddock
* Everything works now
I'll send the patches themselves in separate emails (they're 100-200 KB
apiece, I want to try and make the mailing-list not swallow them).
details:
* Patch to GHC:
** will need review (it might be okay but you GHC people will know
bette
Here's the code I wrote for Haddock to convert TyThing to HsSyn, in a
module (attached)... did you want to include this in GHC? Does it have
any little things you wanted me to clean up first? I removed all the
srcloc information because it was mostly wrong and definitely incomplete.
-Isaac
Although it turned out that in my Synify code there wasn't much actually
valid srcloc information, it might still be generally useful to put
these convenience functions I invented, into GHC:
combineSrcSpanss :: [SrcSpan] -> SrcSpan
combineSrcSpanss [] = noSrcSpan
combineSrcSpanss ss = foldr1 co
tches to improve the problematic cases would (most likely)
be welcome.
2009/7/20 Isaac Dupree :
is a confusing mess!
The most important module is named SrcLoc, which is acceptable.
It contains three types,
SrcLoc,
SrcSpan, which approximately is two SrcLocs (begin and end),
and Located, which combi
is a confusing mess!
The most important module is named SrcLoc, which is acceptable.
It contains three types,
SrcLoc,
SrcSpan, which approximately is two SrcLocs (begin and end),
and Located, which combines a SrcSpan (not a SrcLoc!) with an arbitrary
other type.
In practice (well, in my case at
Simon Marlow wrote:
foreign import prim "has_side_effects commutable foo#" :: ...
note, FFI spec defines lack-of-"safe/unsafe" to mean "safe" (and it's
*not* unsafe in the typical FFI ways, so I think that makes a bit more
sense to me than "unsafe")
If there are features like "can_fail" and
validate has been failing for me in another way!
http://hackage.haskell.org/trac/ghc/ticket/3253#comment:3
-Isaac
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Simon Peyton Jones wrote:
Just for the record, below are the changes required in the boot
libraries -- ie the places where. Not quite as minimal as I'd hoped,
but the changes fall into a few standard patterns, and most represent
(in my opinion) sytlistic improvements. I will not push t
Maybe validate needs to check and warn you about this? e.g. maybe if `darcs
whatsnew -l` finds anything then it gives a big fat warning and asks if you
want to go on anyway. (Only because testing in non-clean trees like this has
been a pitfall multiple times in the past.)
-Isaac
David Waern
Ian Lynagh wrote:
On Fri, Sep 26, 2008 at 06:25:53PM +0100, Simon Peyton-Jones wrote:
|
| But then you wouldn't be able to write the current meaning of
| Chan (Int ? Bool ! Emp)
| with infix type variables.
I am proposing a *change* from current behavior
I realise that, I'm just not convi
Malcolm Wallace wrote:
As a package author (rather than a user), I would see this as a primary
benefit of having my packages added to the Platform. And as a package
user (rather than author), there is the corresponding antibenefit of
removing a package like HOpenGL from the Platform: a diminishe
Neil Mitchell wrote:
Hi
Might help if library author and user are related?-)
Yes :-) I'd like to think that anyone can use Uniplate in a very
high-level manner, but someone other than me needs to argue that.
That was also my sense when I used Uniplate, but I didn't really use it
enough t
Claus Reinke wrote:
However, until this fundamental issue is addressed, is there any
way to make GHC Api clients less dependent on the details of a specific
GHC Api version? In the scenario given above, if T,
despite being built with GHC V1, was able to work with GHC
V2's Api, then it could use
Neil Mitchell wrote:
Hi
While I was away last week I jotted down a list of priorities for 6.10. Some
of these are in the bug tracker and some aren't, but I think it'd be a good
idea for us to first discuss what we really want to see happen in the 6.10 time
frame and then update the ticket
Simon Marlow wrote:
Fortunately you caught me in a "just fix it" mood, so I just fixed it.
We now have a flag -dno-debug-output that suppresses the traces emitted
by a DEBUG compiler from time to time, and the testsuite passes this
flag by default. I'm validating with -DDEBUG right now to che
for example here is my result of running indexed-types/GADT11 test
explicitly:
=> GADT11(normal)
cd . &&
'/Users/me/modified/ghcAlexSpeedTest/compiler/stage1/ghc-inplace'
-no-recomp -dcore-lint -dcmm-lint -Di386_unknown_linux -c GADT11.hs
>GADT11.comp.stderr 2>&1
Actual stderr output di
many of these HEAD validation test failures are the same as I saw months
ago in http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/25738
(though many are different ones too). Maybe I should look at the tests
personally, since I'm the one with the machine that can reproduce them?
OVERALL
Isaac Dupree wrote:
This seems to be the most common way that validate is accidentally
broken, these days -- not testing with both DEBUG defined and undefined.
or maybe I'm wrong. Not sure -- I haven't been compiling GHC for a few
months
This seems to be the most common way that validate is accidentally
broken, these days -- not testing with both DEBUG defined and undefined.
Rather than double the testing time, I suggest validate is modified to
either:
- Compile one of stage1 and stage2 with DEBUG and the other without.
- But
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 guess this change is orthogonal to #835
http://hackage.haskell.org/trac/ghc/ticket/835 , which involves what
information goes into interface-files in the first place (rather than
fixing it or making it worse)?
Simon Marlow wrote:
Wed May 28 05:52:58 PDT 2008 Simon Marlow <[EMAIL PROTECTED]
Is there any particular reason to use let vs. case e.g.
case e of !x -> ... x ...
? As far as I can tell, the main difference is the layout rule affecting
following code...
the point being that you don't want those thunks floating around being
used, and strict-binding makes it obvious to th
x27;s always possible a little extra help
will be needed
-I.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isaac Dupree
| Sent: 06 May 2008 02:05
| To: BuildBot Collator
| Subject: Re: patch applied (ghc): replace Cmm 'hint' with '
(oops, forgot "reply to all" the first time and also left something out)
Is there documentation (e.g. on the GHC Commentary somewhere I can't
find) an explanation of what C-- "kinds" are or how they're useful/used?
When I was portabilizing that code area a while ago I had ignorantly
changed
to be very precise, I think that the entire distribution is licensed
under the intersection of BSD3-for-GHC and GPL-for-everything. Now,
this only affects what copyright notices need to stay included (any
further restriction would obviously violate the GPL).
Also, as far as I can tell, as lo
Simon Marlow wrote:
Do you think it's plausible to apply for this as haskell.org Summer of
Code project (I'm a U.S. college student now, which explains why I've
been too busy to work on GHC stuff, and in the fall) ; I don't know
much about the process, and of course there's lots of competition,
here are some of the things that might need or want to be done,
extending from my task of making GHC code more portable (which
thankfully other people are helping with too, e.g. by cleaning up warnings!)
- not just ghc/compiler Haskell code; at least the makefile system needs
not to use specif
Twan van Laarhoven wrote:
I some cases Applicative is a huge win. Simon's argument is that it is not
possible to use consistently everywhere. I agree that we should strive
to have a
single style for different cases in a single function. However, there
are a lot
of functions that become signific
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
Ian Lynagh wrote:
now, if you think that's too much of a hack to put in the official repo,
just say so :-)
In my opinion it is. Also, if we manage to separate GHC.* into a
separate package to the portable base names then it will be redundant.
yes, if possible, that would be good
~Isaac
Simon Marlow wrote:
Isaac Dupree wrote:
/* This makes it easier to test building without GHC extensions,
* used in import statements such as "import GHC_EXTS.IOBase", to
* provide distinguishment from the GHC API's module GHC */
#ifdef __GLASGOW_HASKELL__
#define GHC_EXTS GHC
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 you
need any more in
Wed Jan 16 17:13:12 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* lots of portability changes (#1405)
re-recording to avoid new conflicts was too hard, so I just put it
all in one big patch :-( (besides, some of the changes depended on
each other.) Here are what the component p
specialise/SpecConstr.lhs:529:46: Not in scope: `extendSubst'
well, I'll commit as soon as I can validate, because I don't want to
assume that my changes would validate against a non-broken HEAD
~Isaac
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
ht
what do you think of removing the implicit qualified FastString import,
so you have to explicitly import FastString?
currently about 86 modules using F/SLIT already import FastString
[EMAIL PROTECTED] /U/m/u/ghc-HEAD> grep -rl '\\|\' compiler/|xargs
grep -l 'import.*FastString'|wc -l
86
and
er, I replied, attaching an amended patch, and it told me the message
awaited moderator approval? what's this?
Isaac
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Isaac Dupree wrote:
Isaac Dupree wrote:
oh, darnit, you wanted to panic for invalid FastBools... which seems
reasonable and hard to work around.
although if they're really supposed to be Fast, I question putting any
extra checks than "is it equal to zero or not" for example,
Isaac Dupree wrote:
oh, darnit, you wanted to panic for invalid FastBools... which seems
reasonable and hard to work around.
although if they're really supposed to be Fast, I question putting any
extra checks than "is it equal to zero or not" for example, even to
panic.
Ian Lynagh wrote:
Hi Isaac,
On Sat, Jan 05, 2008 at 07:38:34PM -0500, Isaac Dupree wrote:
okay, this is a bunch but not all of the work. I'd like to have another
set of eyes look over it before committing, is all.
Great stuff! Looks good to me, feel free to push (assuming it
vali
"It encodes any string into a string that is acceptable as a C name."
this isn't true, I noticed. It's under- and over- specified.
- input starting with a digit 0..9 still starts with a digit
- the empty string becomes the empty string
Neither are acceptable as C names (though they're fine as
HsVersions.h, included in all source-files, already imports FastString
(except when COMPILING_FAST_STRING), to make its own SLIT and FSLIT
macros work. This generates a lot of "unused import" warnings in
modules that don't happen to use any of those macros (or "_unused"
definitions in the modu
I just wanted to check that my documentation was correct and my ifdef
reasonable; it validates fine. Then I'll commit, if it's fine.
Fri Dec 28 11:02:55 EST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* document BreakArray better
Fri Dec 28 11:39:22 EST 2007 Isaac Dupree &
Ian Lynagh wrote:
On Thu, Jan 03, 2008 at 07:07:56AM -0500, Isaac Dupree wrote:
even have memory leaks. To partially remedy this, What if in data types
everywhere
data Foo = Foo FastInt
becomes
data Foo = Foo !FastInt
(the strictness annotation simply has no additional effect when FastInt
Simon Marlow wrote:
Ian Lynagh wrote:
On Mon, Dec 31, 2007 at 09:14:04AM -0500, Isaac Dupree wrote:
I guess boxed types are too risky for efficiency reasons in some
parts of the code
Again, I'd hope that that isn't true for modern GHC, and I personally
would love to see less unbox
Fri Jan 4 09:37:07 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* ghci can't run unboxed tuples currently
M ./tests/ghc-regress/parser/should_run/all.T -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/l
Fri Jan 4 05:48:43 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* add test for curried unboxed-tuple constructors
M ./tests/ghc-regress/parser/should_run/all.T +1
A ./tests/ghc-regress/parser/should_run/read004.hs
A ./tests/ghc-regress/parser/should_run/read004.
Simon Peyton-Jones wrote:
Thanks Isaac, that's great. I've simplified your last two patches quite a bit,
> and pushed the lot.
Thanks! for the GenIface one, you understand what the data structure is
doing enough that you were able to change it;
and for DebugNodes, hmm. You may have reduced
:
--- /dev/null 2007-12-30 14:48:00.0 -0500
+++ ./read063.comp.stderr.normalised2008-01-04 08:55:51.0 -0500
@@ -0,0 +1 @@
+NOTE: Simplifier still going after 4 iterations; bailing out. Size = 26
*** unexpected failure for read063(optc)
Fri Jan 4 08:48:43 EST 2008 Isaac Dupree <[EMAI
Isaac Dupree wrote:
oops, one of the four "Rank2Types" is actually "PolymorphicComponents"
(I hadn't realized there existed a separate name for it, and LANGUAGE
Rank2Types was sufficient to compile it -- is that latter a bug?)
Rank2Types was sufficient *for ghc-6.8.2
oops, one of the four "Rank2Types" is actually "PolymorphicComponents"
(I hadn't realized there existed a separate name for it, and LANGUAGE
Rank2Types was sufficient to compile it -- is that latter a bug?)
~Isaac
___
Cvs-ghc mailing list
Cvs-ghc@has
Simon Peyton-Jones wrote:
Hmm. I'm not sure you are done yet! What happens if you say
map ((#,#) True) xs
?
You'll probably end up with a link error, because there is no curried function
(#,#). With a regular data type, we inject the (rather odd-looking) function
(,) = \a \b
Malcolm Wallace wrote:
It simply contains type signatures for exported functions, together with
datatype, class, and instance decls. A signature for function 'foo' is
preceded by a {-# NEED foo #-} pragma; a datatype or class decl is
preceded by a similar pragma listing precisely the exported
co
Malcolm Wallace wrote:
Module cycles have supported in nhc98 since forever, by simply providing
a bootstrapping .hi file. (Probably best stored in a different
directory, referenced by a -Pdir flag, to avoid it being overwritten by
the real generated .hi file.)
yay! Is the format of this .hi fi
while it isn't really relevant to the ghc porting work itself...
For compilers in which FastInt = Int, _there is less strictness_ because
of special treatment of unboxed types. Therefore it may be slower or
even have memory leaks. To partially remedy this, What if in data types
everywhere
d
Simon Marlow wrote:
Agreed. It's very difficult to test whether a particular change
degrades performance, as it might only do so on certain examples.
well, my other plan was to see if I could get -ddump-simpl to come out
about the same... but looking at that is a little tricky with GHC's
bui
Neil Mitchell wrote:
Hi Isaac,
Or will I have to
#define UTopen (#
#defined UTclose #)
and (UTopen x, y UTclose)
Yuk! There is a ticket on adding a prefix form of (#,#), which is
currently lacking. Perhaps adding that first, then moving to the
unboxed thingy would be best. Also your use of #
Wed Jan 2 05:28:24 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* add test for prefix unboxed tuples
M ./tests/ghc-regress/parser/should_compile/all.T +1
A ./tests/ghc-regress/parser/should_compile/read063.hs
___
Cvs-ghc mailing list
C
Wed Jan 2 04:40:01 PST 2008 Isaac Dupree <[EMAIL PROTECTED]>
* implement prefix unboxed tuples (part of #1509)
M ./compiler/parser/Parser.y.pp +5
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
te has had some testsuite errors for a while
Isaac
New patches:
[implement prefix unboxed tuples (part of #1509)
Isaac Dupree <[EMAIL PROTECTED]>**20080102124001] {
hunk ./compiler/parser/Parser.y.pp 30
+ unboxedSingletonTyCon, unboxedSingletonDataCon,
hunk ./compiler/pa
Neil Mitchell wrote:
Hi Isaac,
Or will I have to
#define UTopen (#
#defined UTclose #)
and (UTopen x, y UTclose)
Yuk! There is a ticket on adding a prefix form of (#,#), which is
currently lacking. Perhaps adding that first, then moving to the
unboxed thingy would be best.
that sounds like
Neil Mitchell wrote:
Hi Isaac,
Or will I have to
#define UTopen (#
#defined UTclose #)
and (UTopen x, y UTclose)
Yuk! There is a ticket on adding a prefix form of (#,#), which is
currently lacking. Perhaps adding that first, then moving to the
unboxed thingy would be best. Also your use of #
I guess boxed types are too risky for efficiency reasons in some parts
of the code (close examination of -ddump-simpl would be needed I guess),
so I'll expand utils/FastTypes and put all the #ifdefs in there.
Unboxed tuples that are used in little areas of GHC code solely for the
efficiency of
a revised patch-set that fixes / cleans up some of my comments. I added
a patch instead of amend-recording because I already darcs-sent the
patches to the list (or is amend-recording better anyway?)
Isaac
Wed Dec 26 11:47:49 EST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* change Cmm
Fri Dec 28 09:57:27 PST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* import ord that alex secretly imported
M ./compiler/parser/Lexer.x -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Isaac Dupree wrote:
Simon Peyton-Jones wrote:
Isaac
Thanks for your work on this.
However, can you hold off committing until Simon and I have been back
at work for a few days? I'm not back at all until 4 Jan.
sure thing! Make that 10 January then.
or maybe I should have looked
Simon Peyton-Jones wrote:
Isaac
Thanks for your work on this.
However, can you hold off committing until Simon and I have been back at work
for a few days? I'm not back at all until 4 Jan.
sure thing! Make that 10 January then.
Isaac
___
Cvs-gh
Dec 27 07:57:38 EST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* bugfix: allow multi-word token-type using parentheses everywhere needed
Thu Dec 27 11:54:46 EST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* refactor HappyReduction-generating code (no semantic change)
Thu Dec 27 12:04:54 EST
Thu Dec 27 09:13:35 PST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* add missing import that happy -agc secretly provided
M ./compiler/cmm/CmmParse.y +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Dec 26 06:07:43 PST 2007 Isaac Dupree <[EMAIL PROTECTED]>
* correct type mistake, hidden by happy -agc coercions!
M ./compiler/parser/Parser.y.pp -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listin
as usual I forget to mention something: I'll get to cleaning up the
LANGUAGE pragmas in the files later -- I've already been messing with
them in my own copy (ghc-6.8 makes it so much easier to find out exactly
what extensions a file really uses, by trial and error!)
Isaac
___
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
Ian Lynagh wrote:
Hi Sven,
On Sun, Sep 23, 2007 at 06:18:01AM -0700, Sven Panne wrote:
Sun Sep 23 05:06:36 PDT 2007 [EMAIL PROTECTED]
* Fix bug #1725 (Haddock links between packages)
Resolving this bug is a bit tricky, it boils down to the question: Should the
Haddock links between packa
Ian Lynagh wrote:
On Wed, Aug 22, 2007 at 12:12:51PM -0300, Isaac Dupree wrote:
runghc -- -- -fglasgow-exts
would be needed to run a file named "-fglasgow-exts", compared to
I don't think we should worry too much about making it easy for people
to call their sources -fglas
Ian Lynagh wrote:
On Wed, Aug 22, 2007 at 09:34:32AM -0300, Isaac Dupree wrote:
Hmm, ghc doesn't take '-f' as an argument alone... the odd '--'
interpretation
It's actually a standard way to separate groups of arguments, e.g.
touch -- -a
rm -- -a
will c
Neil Mitchell wrote:
Hi
Thanks for the tips, Isaac. I fixed my Ord decl. Too bad about the
run-time time & space overhead. I guess that's not fixable. Perhaps Simon
will decide to follow Pepe's suggestion of liberal deriving when
UndecidableInstances enabled.
If you implement compare, isn
Ian Lynagh wrote:
Hi Magnus,
On Sun, Jul 29, 2007 at 05:55:05PM -0400, Magnus Jonsson wrote:
Previously runghc only supported "runghc -fpath-to-ghc Main.hs".
With this patch it also supports "runghc -f path-to-ghc Main.hs", as it
claims in its syntax help message.
Thanks again for the patch.
Conal Elliott wrote:
Thanks, Simon. The manual deriving is easier than I expected, by
boilerplate delegation of constraints & methods, as below. You may want to
give such an example when you document the change. Cheers, - Conal
-- | Pairing of type constructors
newtype (f :*: g) a = Prod {
Simon Peyton-Jones wrote:
So the deriving mechanism works in straightforward cases, and for
> more complicated cases you have to write the instances yourself.
Since the standalone deriving requires one to write the instance context
explicitly (I believe that was the final decision...) perhaps
About a 0.5% penalty on speed and bytes allocated. This is with
replacing the internal FastString hashtable with a (Data.Map.Map PtrStr
FastString)
where data PtrStr = PtrStr {-#UNPACK#-}!ForeignPtr {-#UNPACK#-}!Int
with the inefficiency of copying bytes to a ForeignPtr in order to do
the Map-
Stefan O'Rear wrote:
Anyway, I have no more ideas, other than the obvious (you have a bug
that results in sporadic failure to hashcons, thus corrupting the
interfaces).
My mistake was: To put it approximately, I was storing Ptrs as map keys
when I should have been using persistent ForeignPtrs.
Isaac Dupree wrote:
Stefan O'Rear wrote:
You patched GHC, so the version number (which is extracted from darcs)
automatically went up. GHC assumes (incorrectly) that this broke the
interface format, and is trying to stop you from shooting yourself in
the foot.
But this was from a
Stefan O'Rear wrote:
You patched GHC, so the version number (which is extracted from darcs)
automatically went up. GHC assumes (incorrectly) that this broke the
interface format, and is trying to stop you from shooting yourself in
the foot.
But this was from a clean checkout that only containe
1 - 100 of 155 matches
Mail list logo
